跳到主要内容

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

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的智能体完成了十二步工作流中的第三步,并自信地报告目标 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)之前,捕获完整的智能体状态。这不仅仅是上下文,更是智能体认为真实事物的结构化表示。如果后续步骤发现数据损坏,你可以回滚到上一个干净的快照。

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates