长期运行 AI 智能体中的上下文毒化

你的智能体完成了十二步工作流中的第三步，并自信地报告目标 API 返回了 200 状态。实际上并没有 —— 这个结果来自第一步，仍然停留在上下文窗口中。到第九步时，智能体已经基于一个从未真实存在过的事实进行了四次下游调用。工作流“成功”结束。没有记录任何错误。

这就是上下文污染（context poisoning）：它不是一种安全攻击，而是一种可靠性故障模式，即智能体自身积累的上下文变成了错误信息的来源。随着智能体运行时间变长、交互工具增多、管理状态增加，这种故障的发生概率会急剧上升。而且，与崩溃或异常不同，上下文污染对标准监控来说是不可见的。

为什么长会话中的上下文会退化

Transformer 注意力机制有一个公开的秘密：在长序列中，它并不平等地对待所有 token。对前沿模型的研究显示出一种一致的 U 型模式 —— 模型对上下文窗口开头和结尾的 token 关注度很高，而对埋在中间的内容关注度较低。一旦上下文超过其窗口容量的 50% 左右，性能就会开始出现明显的退化，而且这种情况在达到标称的最大上下文长度之前很久就会发生。

对于智能体来说，四种复合机制将这一特性演变成了一场可靠性危机：

上下文污染发生在幻觉事实嵌入上下文并随后被视为既定事实（ground truth）时。智能体询问工具某个文件是否存在，误读了响应，并在其运行记录中写入了“确认文件存在”。现在，每一个涉及该文件的下游步骤都会基于错误的前提进行推理。

上下文干扰出现在高 token 计数时。随着会话历史的增长，模型开始针对过去的步骤进行模式匹配，而不是合成新的计划。一个正在处理第一百次工具调用的智能体开始变得像前五十次调用一样，系统在强化历史模式，而不是响应当前状态。

上下文混淆源于工具定义泛滥。添加到系统提示词中的每个工具定义都会消耗 token 并引入决策开销。研究表明，当智能体拥有超过一个工具时，准确率会明显下降，而在较小的模型上故障率会更高，且随着工具数量超过 30 个，故障率呈非线性增长。

上下文冲突是破坏性最强的。当智能体在任务中途走错路时，错误的推理会留在上下文窗口中，并继续影响所有后续步骤。基准数据显示，当早期的错误持久存在于上下文中时，平均性能会下降 39% —— 模型检测不到矛盾；它会围绕错误进行合理化。

级联失效模式

上下文污染的危险属性不在于最初的错误事实，而在于下游的放大效应。

一个库存智能体幻觉出了一个不存在的 SKU。这个错误的值被传递给定价工具计算成本。成本被传递给物流预估工具。物流预估触发了客户通知。当人类发现异常订单时，原始错误已经通过四个系统进行了“洗白”，并呈现出完全合法的样子。智能体并没有发生灾难性的失败 —— 它在每一个步骤上都成功了，只是基于被损坏的输入在运行。

这种模式在多智能体流水线（multi-agent pipelines）中尤为明显。当智能体 A 的输出喂给智能体 B，智能体 B 再喂给智能体 C 时，智能体 A 工作流第三步中的一个污染事实就能产生一个看起来完全合理但微妙错误的最终输出。错误不会触发任何异常处理器，因为从技术上讲没有任何环节发生故障。

结论是：标准错误监控捕获的是二进制式的故障。它对于智能体运行到完成并返回错误答案这类故障完全是盲目的。

会话健康状况的真实表现

大多数团队认为会话健康就是“智能体是否在没有崩溃的情况下完成任务”。生产经验揭示了一组值得关注的不同信号：

工具输出陈旧性：当智能体在第二步获取资源并在第十一步引用它时，它是重新查询了还是依赖于九步之前的旧值？陈旧读取在跨度为几分钟或几小时的工作流中尤为危险，因为外部状态可能会在运行中的智能体下方发生变化。

推理连贯性漂移：逐渐与早期步骤相矛盾的中间推理步骤是一个早期指标。如果一个智能体在第四步说“文件不存在”，但在第七步说“正在处理文件内容”，那么它经历的是上下文损坏，而不是目标达成。

工具调用冗余：承受上下文压力的智能体会频繁地重新调用已经调用过的工具，通常会得出略有不同的结果。重复工具调用的激增标志着智能体已经失去了对已知信息的追踪。

指令遵循度衰减：初始系统提示词通常是最重要的输入，但随着会话增长，它变成了受关注度最低的内容。最初遵循格式和约束规则的智能体，随着上下文填满，会逐渐偏离这些规则。针对固定不变量的合规性监控是衡量整体上下文健康状况的一种廉价且有效的方法。

检查点机制：为恢复而设计，而不仅仅是为了成功

检查点-恢复模式（checkpoint-restore pattern）借鉴自分布式系统，是防御上下文污染（context poisoning）最可靠的结构性手段。其核心理念是：在定义的里程碑处，持久化足够的智能体状态，以便从已知的良好位置重新启动，而不是从头开始重放。

对于智能体工作流，有效的检查点机制包含三个要素：

决策点的状态快照：在执行任何不可逆的操作（发送消息、写入数据库、调用外部 API）之前，捕获完整的智能体状态。这不仅仅是上下文，更是智能体认为真实事物的结构化表示。如果后续步骤发现数据损坏，你可以回滚到上一个干净的快照。

阶段边界的事实核查：与其信任中间上下文，不如让智能体在阶段边界重新查询权威数据源。一个已经运行了 40 步的智能体应该重新验证关键实体的当前状态，而不是依赖第 2 步的读取结果。虽然这增加了成本，但比在不可逆操作后才检测到污染要划算得多。

混合无状态/有状态检查点：对于短时间中断（工具超时、瞬时错误），有状态恢复（从智能体中断的确切位置恢复）可以保持执行的保真度。对于重大故障或疑似污染，从更高级别检查点进行无状态恢复更安全，即使这意味着需要重复一些工作。

选择性上下文修剪

检查点负责恢复，而选择性修剪则负责预防。

幼稚的方法——保留完整的对话历史——注定会导致上下文腐化。更好的方法是主动维护：在陈旧内容变成负担之前将其删除或压缩。

先总结后修剪：在从上下文窗口丢弃内容之前，将其压缩为结构化摘要。在进行五轮对话后，将第 1 步到第 3 步压缩为一个摘要块。这样可以保留决策依据，而无需保留耗费 Token 的完整原始记录。做得好的话，这可以将上下文大小减少 30–40%，同时比原始截断保留更多有用的信号。

工具结果外部化：大型工具输出（API 响应、数据库查询结果、文档内容）在立即使用之后不应留在上下文窗口中。内存指针模式（memory pointer pattern）将它们存储在外部状态中，并替换为一个简短的引用键。下游工具根据需要检索完整数据，而不是在陈旧且具有误导性的上下文嵌入副本上操作。

基于近况加权的保留：并非所有上下文的衰减速度都相同。较新的工具输出更有可能反映当前状态。简单的衰减策略可以降低旧交互的有效权重，使最近的输入在智能体的推理中产生更大影响，同时又不完全丢弃历史背景。

定期会话重置：对于运行时间极长的智能体，没有任何修剪策略能完全消除累积的噪声。最可靠的干预是受控重置：生成当前状态的结构化摘要，以此摘要作为系统提示词开启新的上下文，并从那里继续。这类似于连接池回收——虽然不是免费的，但可以防止缓慢的性能下降演变成灾难性的失败。

不变量检查：让智能体立足于现实

除了上下文管理，处理高风险工作流的智能体还能从显式的不变量检查（invariant checking）中获益。这些是关于世界状态的断言，在工作流的任何点都应该是可验证的：

• 正在处理的文件仍存在于预期路径
• API 资源在最近的 N 步内返回了 200，而不是仅在开始的 N 步
• 累计的操作成本仍在授权预算内
• 结构化状态对象中没有出现矛盾的事实

违反不变量并不一定要停止工作流——它们可以触发重新验证、升级到人工检查点，或启动到上一个有效快照的受控回滚。关键特性是，这些检查是根据外部事实真相（ground truth）评估的，而不是根据智能体自身的上下文。

Chandy-Lamport 分布式快照原理在此同样适用：一致的全局状态意味着流水线中的所有智能体都对共享事实的相同版本达成共识。在多智能体工作流的合并点运行不变量检查，可以在上下文污染造成下游损害之前捕捉到分歧。

总结：一个实践架构

一个能够抵御上下文污染的智能体架构结合了以下层级：

首先，保持上下文精简。外部化大型工具输出，修剪不再与行动相关的内容，并总结旧步骤而不是逐字累积。一个精炼的 300 Token 上下文优于一个充满噪声的 100,000 Token 上下文——这是经过测量的，而非理论。

其次，在产生后果前设置检查点。每一个具有外部副作用的操作之前，都应该对智能体状态进行快照，并验证支撑该操作的关键事实。这相当于智能体版本的数据库预提交检查（pre-commit check）。

第三，监控健康信号，而不仅仅是完成情况。跟踪工具调用的冗余度、指令遵循的漂移以及跨步骤的推理连贯性。这些信号会在工作流产生错误答案之前很久就暴露上下文污染。

第四，为重置而设计。极长的会话应该有计划的重置点，从结构化状态摘要开始全新的上下文。这不是失败，而是刻意的生命周期管理。

为什么这没有得到足够的重视

上下文污染（Context poisoning）作为一种生产环境中的隐患常被低估，因为演示（demos）通常不会暴露这个问题。展示中的十步工作流很少运行足够长的时间来累积受损状态。而一个在不断变化的环境中，每天运行数百步、持续数周的生产环境智能体（Agent）——该智能体最终会虚构出一个事实，并因未能检测到它而将其传播到整个系统中。

那些构建旨在后台长时间自主运行智能体的团队将会遇到这种情况。那些为此进行了设计的团队——通过设置检查点（checkpoints）、修剪（pruning）、不变性检查（invariant checks）和会话健康监测——将能及早发现问题。而那些没有设计的团队，只有在下游系统根据一个从未真实存在过的事实采取行动后，才会察觉到问题。

长期运行的智能体可靠性，本质上是一个披着“模型问题”外衣的“上下文卫生（context hygiene）”问题。模型完全是在按设计工作。它只是在一个不再反映现实的上下文中忠实地进行推理。