给 AI 做减法:上下文工程的四把手术刀
Agent 表现不好,直觉反应是换更强模型、加更多工具、写更长提示词——但加法常是负优化。代码替代对话链、Sub-Agent 空间隔离、压缩做时间隔离、Skill 按需加载,四把手术刀给模型更精准的而不是更多的。
我们的直觉是错的
大多数人遇到 AI Agent 表现不好,第一反应是:
- 换个更强的模型?
- 加更多工具?
- 写更长的系统提示词?
这三个方向,听起来都很合理——模型更强、工具更多、提示更详细,看起来就是「加法即进步」。
但事实是:在上下文工程这件事上,加法常常是负优化。
反方会说:模型窗口已经 200K、1M 了,塞满又怎样?
这是最常见的反驳,也是最危险的误解。
窗口大 ≠ 注意力均匀。
研究反复证实了 Lost in the Middle:当上下文塞到中后段,模型对中间部分的召回率会断崖式下跌。塞 100K 不等于读 100K,更不等于「用好」100K。
更现实的代价是三件事同时发生:
- 成本:推理费用随 token 线性甚至超线性上涨;
- 延迟:首 token 延迟变慢,用户体感变差;
- 质量:噪音越多,幻觉与误调用工具的概率越高。
所以真正的瓶颈不在模型,在上下文。
一个典型的企业级 Agent:
- 系统提示词超过 2 万 token
- 预加载 20 ~ 40 个工具的完整 Schema
- 每一轮对话都把所有历史塞进窗口
这不是在帮 AI 思考,这是在让 AI 在噪音里打转。
Harness 本质上是一个分布式的上下文管理系统。
四把手术刀
① 代码替代对话链
以前的 Agent 是这样工作的:
调用工具 → 等结果 → 再调用工具 → 再等结果 …… × 20
20 次工具调用 = 20 轮 LLM 往返,每一轮都要把前面所有的中间结果塞进上下文。
现在的做法:
让 Agent 直接写一段 Python,在沙箱里一次性执行完。
同样一个任务,两种方式的差距是这样的——
- LLM 往返:从
20 次压到1 次 - 中间状态:从「全塞上下文」变成「留在变量 / 文件里」
- 协调器看到:从「全部噪音」变成「最终摘要」
🗣️ 反方会说:让 LLM 写代码再去执行,不是更不可控吗?万一代码报错呢?
确实如此——但这恰恰是沙箱要解决的问题。代码出错可以重试、打日志、拿 stack trace 让模型自我修正;而 20 轮工具调用中间断裂,整个对话链就废了。
可控性不是「少做一步」,而是「失败可观测、可重放」。
✅ 结果:延迟下降,可靠性上升,上下文干净了。
② Sub-Agent 做空间隔离
需要分析 500 个客户?不要把所有信息堆在一个 Agent 的上下文里。
让协调器 Agent 启动 500 个 Sub-Agent,每个只处理一个客户,用自己独立的上下文窗口。协调器只收汇总结果。
🗣️ 反方会说:500 个 Sub-Agent,成本不是爆炸了吗?
短期看 token 总量确实会上升,但要算两笔账:
- 质量账:单个 Agent 塞 500 个客户,要么超窗口直接失败,要么质量塌方需要反复重跑——表面省钱,实际更贵;
- 延迟账:Sub-Agent 之间天然并行,端到端延迟从「线性叠加」变成「取最大值」,对用户而言是几十倍的速度差。
✅ 每个 Sub-Agent 专注、干净、不受干扰——分析深度反而提升了。
③ 压缩做时间隔离
长任务执行到后期,早期的原始对话已经没有价值,但模型还是要带着它走。
解法:把早期轮次压缩成一段摘要——
"用户要求了什么、尝试了什么、什么有效、下一步是什么"
原始来回全部丢弃。大型工具输出写进文件系统,上下文里只留一个文件路径。
🗣️ 反方会说:压缩会丢信息,万一丢的恰好是关键细节呢?
这是真问题,但解法不是「什么都不丢」,而是分层留存:
- 摘要留在上下文里 —— 让模型记得「发生过什么」(决策 + 状态);
- 原文沉到文件系统里 —— 需要时可以精确检索。
不可逆压缩才危险,可回溯压缩是工程化的常规操作——和数据库的冷热分层是一个道理。
Sub-Agent 从空间维度管理上下文,压缩从时间维度管理上下文,两者相互强化。
④ Skill 按需加载
把所有工具的 Schema 预加载进上下文,即使大多数根本用不到——这是另一种常见的浪费。
正确的姿势:
- 用索引搜索相关 Skill(只返回名称和描述)
- Agent 从精准候选列表里选
- 选定后才加载完整 Schema
🗣️ 反方会说:多一次检索,不是反而增加了延迟和复杂度吗?
一次轻量检索(毫秒级、几十 token)换掉每轮都背着几万 token 的工具 Schema——无论从延迟、成本还是模型选择准确率看,都是稳赚不赔的交易。
真正复杂的不是「按需加载」,而是「什么都预加载」——后者把代价摊给了每一次调用,且永远在为最坏情况付费。
✅ Agent 永远不需要浏览完整能力列表,每一层细节只在需要时才出现。
什么时候这套方法不适用
为了不夸大,必须坦白说清楚边界:
- ❌ 任务极短、单轮就能解决 —— 上这套架构是过度工程,直接 prompt 即可;
- ❌ 强一致性、强顺序依赖的工作流 —— Sub-Agent 并行反而引入协调难题,传统编排更稳;
- ❌ 调试期、需要完整可观测的链路 —— 压缩反而会让排错变难,应在生产环节再开启。
承认边界,才显得方法本身可信。
这对你意味着什么
如果你在构建或使用 AI Agent,这里有三个可以立刻检验的问题:
- 你的系统提示词有多长?
- 你预加载了多少工具?
- 你的对话历史里,有多少 token 是「上一轮已经无关」的内容?
这个行业正在经历一次认知转变:
AI 工程的核心竞争力,不是给模型更多,而是给模型更精准的。
模型不需要看到所有东西,它只需要——
在正确的时刻,看到正确的信息。
这,才是 Harness 真正在做的事。