上下文工程揭秘：AI智能体四大陷阱与修复方案

引言：为什么信息越多，智能体越不可靠？

AI智能体的上下文窗口已经从几千token膨胀到百万级别，理论上应该能处理更复杂的长期任务。但现实却给出了相反的答案。据IBM Technology在B站分享的视频内容，一项针对18个前沿模型的研究发现：随着上下文窗口增大，所有模型的可靠性都在下降。研究者将这一现象命名为"上下文腐化"（context rot）——窗口里的token越多，模型对其中任何信息的利用都越不可靠。

这正是上下文工程（context engineering）要解决的问题：决定在智能体运行的每一步，究竟哪些信息应该进入上下文窗口。视频中梳理了四种典型的上下文失败模式，并给出了一个反直觉的结论——修复方案的核心都是主动丢弃信息。

上下文窗口（context window）指语言模型在一次推理调用中能够同时“看到”的 token 总数，包括输入提示、历史对话、工具返回结果以及模型即将生成的输出。它由模型的注意力机制决定：模型对窗口内每个 token 计算注意力权重，再据此生成下一个 token。早期模型窗口多为 4K–32K token，如今主流模型已扩展到 128K、200K 乃至百万级。需要区分的是“窗口容量”与“有效容量”：窗口能装下多少 token，并不等于模型能同等可靠地利用其中每个 token。业界常说的“大海捞针”测试只能证明模型能从长文中找回某个孤立事实，却无法反映多信息交织、需要推理时的真实表现，这正是“上下文腐化”容易被忽视的原因。

上下文窗口里到底装了什么？

以一个"代码库数据库迁移"智能体为例，窗口的构成大致如下：

• 系统提示词：智能体运行的基本指令，通常位于窗口最前端。
• 任务提示：可能只有几行，描述具体要做什么。
• 项目说明：如agents.md文件，解释项目如何构建。
• 工具定义：智能体可调用的每个工具的描述。
• 消息历史：智能体每一步操作的运行日志，运行一小时后会变得非常庞大。
• 工具结果：文件内容、测试输出、错误日志、schema导出等，往往是占比最大的部分。

你可能没注意到，任务描述只占窗口开头几行，其余绝大部分都是智能体在运行过程中自行堆积的"副产品"。其中一个典型例子是：智能体自己写了一条笔记，声称"新驱动会自动重试失败连接，旧的重试代码可以删除"——而这条笔记后来被证明是完全错误的。

为什么填满上下文窗口会成为问题？

模型并不是像数据库检索行那样查找上下文中的信息。窗口中的每个token都在竞争一份有限的"注意力预算"。窗口或许能容纳一百万token，但分摊到这些token上的注意力是有限的。这是理解所有上下文失败模式的出发点。

四大上下文失败模式

陷阱一：上下文中毒（Context Poisoning）

一个错误进入上下文窗口，随后被当作事实对待。前文提到的那条"驱动自动重试"笔记就是典型：智能体从驱动文档中误读信息，写下了错误结论。对模型而言，自己写下的笔记看起来就像是"基准真相"，于是它开始逐个文件删除本应保留的重试代码。错误一旦被固化，就会持续污染后续决策。

上下文中毒与另外三种失败模式的关键区别在于“不可逆性”。分心、混淆、冲突大多会随窗口刷新或信息修剪而缓解，但中毒是错误信息被模型当作前提写回上下文，形成自我强化的循环：模型基于错误笔记做出删除决策，删除结果又作为新的“证据”进入窗口，进一步坐实原判断。这类错误极难被模型自身发现，因为模型倾向于信任自己此前生成的文本（一种“自我一致性偏差”）。实践中常见的触发源包括：误读文档、工具返回被截断或格式错乱、模型对报错信息的过度归纳。防御思路除了文中提到的“先验证再写入”，还包括给关键结论标注来源与置信度、对高风险操作设置人工确认环节，以及定期用外部事实源交叉核对上下文中的断言。

陷阱二：上下文分心（Context Distraction）

语言模型的本质是模式延续机器。当上下文里积累了一小时的自身操作历史，这段历史就成了最强的模式——强过训练中获得的推理能力。模型不再问"任务下一步需要什么"，而是倾向于重复已经做过的事，陷入原地打转。

陷阱三：上下文混淆（Context Confusion）

智能体接入的工具越多，选择正确工具的难度就越大——无论工具是否被实际使用，其定义都占据着窗口空间。视频引用了一项基准测试：同一个任务，提供46个工具时模型失败，仅提供19个工具时则成功通过。这就是"工具蔓延"的代价。

陷阱四：上下文冲突（Context Clash）

窗口内出现自相矛盾的信息。智能体后来发现重试并未发生，意识到笔记有误，于是又把更正写进消息历史。结果是新旧两个版本同时存在于窗口中，呈现相互冲突的信息，模型不得不在矛盾中做判断。

四种修复方案：学会"扔东西"

验证：对抗上下文中毒

在结论被写入上下文之前先做验证，对照真实情况检查。只需一次简单的连接测试，智能体就不会写下"无需重试代码"这条错误笔记。

压缩：对抗上下文分心

历史过长时进行压缩（compaction）：丢弃完整日志，从摘要重新开始。但压缩是有损的——摘要的摘要会像复印件的复印件一样逐渐漂移。因此应尽可能把详细信息移出窗口，存入永久文件，仅在真正需要时再拉回窗口。

压缩（compaction） 借鉴了数据库与操作系统中的思路：当活跃数据超出容量时，把冷数据序列化到外部存储，只保留索引或摘要。在智能体场景中，常见实现包括滚动摘要（定期把早期消息历史总结成一段短文本）、分层记忆（把细节写入文件或向量库，窗口只保留指针），以及“检查点重启”（在新窗口中重述当前任务状态）。需要注意的是，摘要本身也是一次模型生成，会引入新的失真风险，因此摘要应尽量保留可验证的硬信息（文件路径、错误码、已确认的结论），而把叙述性内容压缩掉。业界一些编码智能体正是采用“摘要 + 外部文件”的混合策略，在长任务中维持较低的窗口占用。

精选：对抗上下文混淆

数据库迁移任务不需要46个工具，只给任务真正需要的少数几个，其余工具按需获取即可。这是策展问题，而非能力问题。

工具蔓延（tool sprawl）指智能体可调用工具数量随功能扩张而不断膨胀的现象。每个工具的名称、描述、参数 schema 都要占用窗口 token，而且相似工具之间语义重叠会显著抬高选择难度。这与软件工程中的“接口隔离原则”异曲同工：与其提供一个包罗万象的大接口，不如按当前任务暴露最小必要集合。工程上的常见做法包括：按任务阶段动态加载工具子集、用一层“工具路由器”先做粗筛再暴露具体工具、以及把低频工具的调用封装成一个通用执行入口。这些手段的共同点都是把“选择成本”从模型推理中移出，交给确定性的代码逻辑处理。

修剪：对抗上下文冲突

信息被取代时，直接删除旧版本，而不是让两个版本并存。更进一步，可以开启全新窗口，仅重述任务当前已修正的状态，把旧的、被污染的内容全部留在身后。

核心洞察：少即是多

四种失败模式与四种修复方案可以这样对应记忆：

失败模式	症状	修复方案
上下文中毒	错误结论被当作事实	验证
上下文分心	历史模式压过任务推理	压缩
上下文混淆	工具过多，选择困难	精选
上下文冲突	窗口内信息自相矛盾	修剪

所有修复方案的本质都是主动丢弃信息。智能体在长期任务中表现更好，靠的不是塞进更多上下文，而是持有更少的上下文。这一结论对正在构建AI智能体的开发者具有直接的实践意义：上下文工程不是关于"能装多少"，而是关于"该留什么"。