# 给 AI 做减法:上下文工程的四把手术刀

> Agent 表现不好,直觉反应是换更强模型、加更多工具、写更长提示词——但加法常是负优化。代码替代对话链、Sub-Agent 空间隔离、压缩做时间隔离、Skill 按需加载,四把手术刀给模型更精准的而不是更多的。

- 原文链接: https://laojin.blog/blog/20260512_context_engineering_four_scalpels
- 作者: 老金
- 发布日期: 2026-05-12
- 标签: AI Agent, 上下文工程, Harness, 工程实践

---

![给 AI 做减法:上下文工程的四把手术刀](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260512/00_cover.png)

## 我们的直觉是错的

大多数人遇到 AI Agent 表现不好,第一反应是:

- 换个更强的模型?
- 加更多工具?
- 写更长的系统提示词?

这三个方向,听起来都很合理——模型更强、工具更多、提示更详细,看起来就是「加法即进步」。

**但事实是:在上下文工程这件事上,加法常常是负优化。**

---

## 反方会说:模型窗口已经 200K、1M 了,塞满又怎样?

这是最常见的反驳,也是最危险的误解。

> **窗口大 ≠ 注意力均匀。**

研究反复证实了 *Lost in the Middle*:当上下文塞到中后段,模型对中间部分的召回率会断崖式下跌。塞 100K 不等于读 100K,更不等于「用好」100K。

更现实的代价是三件事同时发生:

1. **成本**:推理费用随 token 线性甚至超线性上涨;
2. **延迟**:首 token 延迟变慢,用户体感变差;
3. **质量**:噪音越多,幻觉与误调用工具的概率越高。

所以真正的瓶颈不在模型,**在上下文**。

一个典型的企业级 Agent:

- 系统提示词超过 **2 万 token**
- 预加载 **20 ~ 40 个**工具的完整 Schema
- 每一轮对话都把所有历史塞进窗口

这不是在帮 AI 思考,这是在让 AI 在噪音里打转。

> Harness 本质上是一个**分布式的上下文管理系统**。

---

## 四把手术刀

### ① 代码替代对话链

![代码替代对话链:从 20 轮 LLM 往返压到 1 次](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260512/01_code_vs_chat.png)

**以前的 Agent 是这样工作的:**

```
调用工具 → 等结果 → 再调用工具 → 再等结果 …… × 20
```

20 次工具调用 = 20 轮 LLM 往返,每一轮都要把前面所有的中间结果塞进上下文。

**现在的做法:**

让 Agent 直接写一段 Python,在沙箱里一次性执行完。

同样一个任务,两种方式的差距是这样的——

- **LLM 往返**:从 `20 次` 压到 `1 次`
- **中间状态**:从「全塞上下文」变成「留在变量 / 文件里」
- **协调器看到**:从「全部噪音」变成「最终摘要」

> 🗣️ **反方会说**:让 LLM 写代码再去执行,不是更不可控吗?万一代码报错呢?

确实如此——但这恰恰是沙箱要解决的问题。代码出错可以**重试、打日志、拿 stack trace 让模型自我修正**;而 20 轮工具调用中间断裂,整个对话链就废了。

**可控性不是「少做一步」,而是「失败可观测、可重放」。**

✅ 结果:延迟下降,可靠性上升,上下文干净了。

---

### ② Sub-Agent 做空间隔离

![Sub-Agent 空间隔离:每个子 Agent 拥有独立上下文](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260512/02_subagent_parallel.png)

需要分析 500 个客户?**不要把所有信息堆在一个 Agent 的上下文里。**

让协调器 Agent 启动 500 个 Sub-Agent,每个只处理一个客户,用自己独立的上下文窗口。协调器只收汇总结果。

> 🗣️ **反方会说**:500 个 Sub-Agent,成本不是爆炸了吗?

短期看 token 总量确实会上升,但要算两笔账:

- **质量账**:单个 Agent 塞 500 个客户,要么超窗口直接失败,要么质量塌方需要反复重跑——表面省钱,实际更贵;
- **延迟账**:Sub-Agent 之间天然并行,端到端延迟从「线性叠加」变成「取最大值」,对用户而言是几十倍的速度差。

✅ 每个 Sub-Agent 专注、干净、不受干扰——分析深度反而提升了。

---

### ③ 压缩做时间隔离

![压缩做时间隔离:摘要留在上下文,原文沉到文件系统](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260512/03_compress_timeline.png)

长任务执行到后期,早期的原始对话已经没有价值,但模型还是要带着它走。

**解法**:把早期轮次压缩成一段摘要——

> "用户要求了什么、尝试了什么、什么有效、下一步是什么"

原始来回全部丢弃。大型工具输出写进文件系统,上下文里只留一个文件路径。

> 🗣️ **反方会说**:压缩会丢信息,万一丢的恰好是关键细节呢?

这是真问题,但解法不是「什么都不丢」,而是**分层留存**:

- **摘要**留在上下文里 —— 让模型记得「发生过什么」(决策 + 状态);
- **原文**沉到文件系统里 —— 需要时可以精确检索。

**不可逆压缩才危险,可回溯压缩是工程化的常规操作**——和数据库的冷热分层是一个道理。

> Sub-Agent 从**空间维度**管理上下文,压缩从**时间维度**管理上下文,两者相互强化。

---

### ④ Skill 按需加载

把所有工具的 Schema 预加载进上下文,即使大多数根本用不到——这是另一种常见的浪费。

**正确的姿势:**

1. 用索引搜索相关 Skill(只返回名称和描述)
2. Agent 从精准候选列表里选
3. 选定后才加载完整 Schema

> 🗣️ **反方会说**:多一次检索,不是反而增加了延迟和复杂度吗?

一次轻量检索(毫秒级、几十 token)换掉**每轮都背着几万 token 的工具 Schema**——无论从延迟、成本还是模型选择准确率看,都是稳赚不赔的交易。

真正复杂的不是「按需加载」,而是「什么都预加载」——后者把代价摊给了每一次调用,且**永远在为最坏情况付费**。

✅ Agent 永远不需要浏览完整能力列表,每一层细节只在需要时才出现。

---

## 什么时候这套方法**不适用**

为了不夸大,必须坦白说清楚边界:

- ❌ **任务极短、单轮就能解决** —— 上这套架构是过度工程,直接 prompt 即可;
- ❌ **强一致性、强顺序依赖的工作流** —— Sub-Agent 并行反而引入协调难题,传统编排更稳;
- ❌ **调试期、需要完整可观测的链路** —— 压缩反而会让排错变难,应在生产环节再开启。

> 承认边界,才显得方法本身可信。

---

## 这对你意味着什么

如果你在构建或使用 AI Agent,这里有三个可以立刻检验的问题:

1. 你的**系统提示词**有多长?
2. 你**预加载**了多少工具?
3. 你的对话历史里,有多少 token 是「**上一轮已经无关**」的内容?

---

这个行业正在经历一次认知转变:

> **AI 工程的核心竞争力,不是给模型更多,而是给模型更精准的。**

模型不需要看到所有东西,它只需要——

**在正确的时刻,看到正确的信息。**

这,才是 Harness 真正在做的事。