AI Agent 为什么会跑偏：目标漂移、上下文污染和工具诱导

摘要： Agent 跑偏不是简单的“模型幻觉”。在一个会读上下文、会拆任务、会调用工具、会把工具结果继续写回上下文的系统里，小误差会沿着行动链不断放大。本文用目标漂移、上下文污染和工具诱导三个概念，解释为什么 Agent 明明一开始听懂了，却会在执行过程中慢慢偏离原始意图。

你应该见过这种情况：

你让一个 Agent “帮我整理这几篇资料，看看它们对 Agent Memory 的理解有什么差别”。它一开始看起来很正常，先读文件，再总结主题，再补充检索。问题是，执行到一半，它开始把重点放到某个资料里反复出现的 “RAG” 上；再往后，它主动扩展成“RAG 和 Agent Memory 的关系”；最后交付的文章结构完整、语气自信、表格也漂亮，但它已经不是在回答最初那个问题了。

更麻烦的是，它不是从第一句就错。

它的每一步都“有理由”：

• 因为资料里确实提到了 RAG。
• 因为检索结果确实补充了相关背景。
• 因为工具返回确实给了它新的上下文。
• 因为它自己总结出来的中间结论看起来也能自洽。

这就是 Agent 跑偏最难识别的地方：它不是突然胡说，而是在一个看似合理的行动链里，慢慢偏离了原始目标。

先区分：幻觉和跑偏不是一回事

普通聊天模型的错误，常常是“一次性”的。

你问一个事实，它答错了；你让它解释一个概念，它编了一个不存在的论文；你让它写代码，它用了不存在的 API。这类问题当然严重，但它大多停留在“这次回答错了”。

Agent 的问题更像一个循环系统里的误差放大。

Anthropic 在讨论可信 Agent 时，把 Agent 和普通聊天机器人的区别放在了一个关键点上：Agent 会自我指导过程和工具使用，会计划、行动、观察结果、调整，再继续下一步。OpenAI Agents SDK 的 tracing 文档也把一次 Agent 运行拆成 LLM 生成、工具调用、handoff、guardrail 等一串事件，而不是只看最后回答。

也就是说，Agent 的输出不是一次生成，而是一条行动链。

所以它的错误也不是一个点，而可能是一条路径：

原始目标
  -> 任务拆解
  -> 读取上下文
  -> 选择工具
  -> 工具返回
  -> 写入新的上下文
  -> 再次解释目标
  -> 下一步行动

如果某一步出现偏差，下一步不是自动纠正它，而是可能把这个偏差当成新的事实、新的目标或者新的行动依据。

这就是本文对“Agent 跑偏”的定义：

Agent 跑偏不是一次性的事实错误，而是目标、上下文和工具调用在循环中相互影响之后，逐步偏离用户原始意图的过程。

为了讲清这个现象，可以把 Agent 跑偏拆成三层：

1. 目标漂移：它追的目标变了。
2. 上下文污染：它相信的材料脏了。
3. 工具诱导：它理解问题的方式被工具改变了。

这三个词不一定是业界统一术语，但很适合作为理解 Agent 行为的框架。

第一层：目标漂移

用户给 Agent 的通常是一个目标，而不是一个完全展开的执行脚本。

比如：

帮我比较 A、B、C 三种 Agent Memory 方案的差异。

这句话里真正的目标是“比较差异”。但 Agent 执行时会把它拆成很多局部任务：

1. 先理解 A。
2. 再理解 B。
3. 再理解 C。
4. 抽取维度。
5. 生成对比。

问题出在：局部任务一旦变得足够具体，它就可能反过来压过原始目标。

Agent 先读 A 的资料，发现 A 里面有很多关于长期记忆、语义索引、用户偏好的内容，于是开始展开解释。展开越多，它越容易把“讲清 A”当成当前目标。等它再去读 B、C 时，比较维度已经被 A 的叙事方式污染了。

最后你得到的不是“三者对比”，而是“A 的体系 + 顺带提一下 B 和 C”。

这就是目标漂移。

它不一定来自恶意输入，也不一定来自模型能力不足。很多时候，它来自一个很自然的执行机制：Agent 必须把大目标拆成小目标，而小目标会争夺注意力。

可以把目标漂移看成三种常见形态。

1. 子任务替代原任务

这是最常见的一种。

原始目标是：

比较 A 和 B 的差异。

中间子任务是：

先收集 A 的资料。

跑偏结果是：

输出一篇 A 的介绍，B 只在结尾出现。

这里 Agent 并不是完全忘了 B，而是它在执行过程中把“收集 A 的资料”当成了主要任务。它完成了一个局部正确的动作，却丢掉了全局问题。

2. 手段变成目的

很多 Agent 会先建立计划，计划本来只是手段。

但执行一段时间后，它可能开始服务于计划本身，而不是服务于用户目标。

例如用户只是想“快速了解一个概念”，Agent 却把任务改写成：

需要先查资料、再做分类、再生成表格、再给出最佳实践。

表面上看更完整，实际上已经偏离了“快速了解”的原始意图。

这类跑偏尤其容易出现在“越努力越跑偏”的场景里：Agent 不是偷懒，而是过度执行。

3. 成功标准被 Agent 自己改写

还有一种更隐蔽：Agent 自己创造了一个成功标准。

比如用户要的是：

指出这段方案哪里不合理。

Agent 可能在中间总结成：

目标：优化这段方案，使其更完整。

于是它开始补充优点、修正文案、扩展结构，最后避开了真正的问题：批判。

这种时候，Agent 看起来很有建设性，但它完成的是自己改写后的任务。

目标漂移的关键不在于“模型没有理解用户”，而在于：理解会在执行过程中被重新解释。

用户说的目标在第一轮被理解一次；工具返回后被理解第二次；上下文压缩后被理解第三次；每次理解都可能损失一点东西，也可能多长出一点东西。

当这些变化积累起来，Agent 就开始偏航。

第二层：上下文污染

如果说目标漂移回答的是“它为什么追错了方向”，上下文污染回答的是“它为什么相信了不该相信的东西”。

这里的“污染”不只指恶意 prompt injection。

它可以是很普通的东西：

• 旧对话里残留的目标。
• 检索结果里质量很低的网页。
• 工具返回里的错误状态。
• Agent 自己压缩历史时写错的摘要。
• 用户随手贴进来的不完整材料。

Anthropic 在 context engineering 文章里强调，到了 Agent 阶段，需要管理的不只是 prompt，而是整个上下文状态：系统指令、工具、外部数据、消息历史等都会进入模型推理时看到的 token。它也明确提到，长任务会遇到 context pollution 和信息相关性问题。

这点非常重要。

很多人还把上下文理解成“多给点资料”。但对 Agent 来说，上下文不是资料仓库，而是工作现场。工作现场里如果混进了过期信息、错误摘要、低可信网页、工具残留，它们不会安静地躺在那里，它们会参与下一轮决策。

上下文污染的五个入口

来源	污染方式	典型后果
历史对话	旧目标残留在新任务里	Agent 把上一次的约束带进这一次
检索结果	低质量资料被当成证据	结论被搜索噪声带偏
网页内容	外部文本夹带指令或偏见	模型混淆资料和指令
工具返回	错误结果写入工作记忆	后续步骤基于错误状态继续执行
压缩摘要	细节在总结中丢失或变形	Agent 以为“已确认”，其实只是“被概括”

最极端的上下文污染，就是间接 prompt injection。

Greshake 等人在 2023 年的 “Not what you’ve signed up for” 中提出，LLM 集成应用会模糊数据和指令之间的边界。攻击者可以把指令嵌入到将被检索的外部数据里，让应用在处理这些数据时受到操控。BIPIA 相关研究也指出，模型难以区分“信息性上下文”和“可执行指令”，这是间接 prompt injection 成功的重要原因之一。

但即使没有攻击者，普通上下文也会污染。

比如一个 Agent 做资料整理：

用户目标：比较三种方案的差异。
检索结果：某篇博客强烈推荐方案 A。
Agent 摘要：方案 A 是目前更主流的选择。
后续写作：以 A 为主线组织全文。

这里没有人攻击它，但“某篇博客的倾向”已经从外部资料变成了 Agent 的内部判断。

再比如一个 Agent 做代码分析：

工具返回：没有找到相关文件。
真实原因：搜索路径写错了。
Agent 结论：项目里没有这个模块。
后续动作：建议从零新增模块。

工具返回并不是最终事实，它只是某次查询的结果。但如果 Agent 把它写进上下文，当成“已经确认”，后面的行动就会越来越偏。

这就是上下文污染最危险的地方：

它让“来源不明的信息”变成“下一步推理的前提”。

第三层：工具诱导

工具调用让 Agent 从“会说”变成“会做”。

但工具不仅扩展能力，也改变问题本身。

OpenAI 的 function calling 文档里说，工具让模型访问外部功能和数据；模型在生成响应时，可能判断自己需要某个工具来完成指令。这个描述看起来中性，但背后有一个很容易被忽略的点：

一旦工具出现在 Agent 的行动空间里，它就不只是一个能力列表，也是一个问题解释框架。

有搜索工具，Agent 更容易把问题理解成“需要先搜一下”。

有文件编辑工具，Agent 更容易把建议理解成“直接改文件”。

有数据库查询工具，Agent 更容易把分析理解成“查表就能解决”。

有发消息工具，Agent 更容易把沟通问题理解成“需要发一条消息”。

工具像一组“行动暗示”。它们会告诉模型：这个世界里哪些动作是可用的，哪些路径是顺手的，哪些结果可以被快速获得。

这就是工具诱导。

工具越多，不一定越聪明

很多人直觉上会觉得：给 Agent 更多工具，它就更强。

这只说对了一半。

更多工具确实扩大了行动空间，但也扩大了误选空间。Anthropic 在关于工具设计的文章里提到，工具要有清晰定义，要谨慎使用 Agent 上下文，工具描述、schema、实现方式都会影响 Agent 表现。

换句话说，工具不是普通 API。

普通 API 是人看文档后调用；Agent 工具是模型在不确定状态下选择调用。工具名字、描述、参数、返回值都会进入模型的判断。一个含糊的工具描述，不只是“文档写得差”，它会直接改变 Agent 对任务的理解。

比如两个工具：

search(query)

和：

search_public_web(query)
仅用于查找公开网页资料；不能用于确认用户私有数据、内部项目状态或未经验证的事实。

它们看起来都是搜索工具，但对 Agent 的诱导完全不同。

第一个工具会让模型觉得“任何不确定都可以搜一下”；第二个工具会提醒它“搜索只适合公开资料，不适合确认内部事实”。

工具描述越宽，Agent 越容易把问题工具化。

工具边界越模糊，Agent 越容易把“可以调用”误解成“应该调用”。

工具返回也会继续诱导

工具诱导不只发生在调用前，也发生在调用后。

例如搜索工具返回了十条结果，其中八条都在讲某个热门概念。Agent 可能会误以为这个热门概念就是用户问题的核心。

再比如一个代码搜索工具返回了某个旧目录，Agent 可能开始围绕旧目录分析系统结构，即使真正的代码已经迁移到了新目录。

工具返回不是中立事实，它是一次查询在特定条件下的观察结果。

但 Agent 很容易把观察结果写成世界状态：

没有搜到 -> 不存在
返回很多 -> 很重要
工具报错 -> 任务不可行
某路径出现 -> 主路径就在这里

这些推断未必可靠，却会影响后续行动。

所以工具诱导和上下文污染经常连在一起：

1. 工具引导 Agent 选择某条路径。
2. 工具返回提供一批局部信息。
3. 局部信息被写入上下文。
4. 上下文反过来强化下一次工具选择。

一旦形成循环，Agent 就会越走越像“有逻辑”，但这个逻辑可能已经不属于原始任务。

为什么 Agent 时代更容易暴露这个问题

聊天模型当然也会跑题。

但 Agent 让跑题变得更有后果。

可以用一张表看差异：

形态	错误主要停在哪里	典型表现
Chatbot	最终回答	编事实、答非所问、解释错误
RAG	引用材料	检索噪声、错引资料、证据不足
Tool Use	单次动作	调错工具、参数错误、结果误读
Agent	行动链	目标变形、上下文污染、工具路径自我强化

Agent 时代的问题不只是“模型会不会答错”，而是“错误会不会进入下一步行动”。

这就是为什么只看最终回答越来越不够。

OpenAI Agents SDK 的 trace 设计会记录一次运行里的模型生成、工具调用、handoff、guardrail 等事件，正是因为 Agent 的行为需要看中间过程。最终答案可能很顺，但中间路径已经暴露出偏航：它可能用了错误资料，可能调用了不必要的工具，可能把某个临时结论当成事实。

从知识理解上讲，Agent 的可靠性至少有三层：

1. 答案层：它最后说了什么。
2. 路径层：它中间看了什么、想了什么、调了什么。
3. 状态层：它把哪些信息带进了下一步。

普通问答主要看答案层。

Agent 必须看路径层和状态层。

因为跑偏往往不是最后一句才发生的，而是在中间某个不起眼的“观察”里开始的。

四种常见偏航轨迹

为了更具体一点，可以把 Agent 跑偏看成四种轨迹。

轨迹一：模糊目标被过度解释

用户说：

帮我看看这个方案有没有问题。

这句话很自然，但目标不够明确。

Agent 可能把“看看有没有问题”理解成：

• 找语病。
• 补结构。
• 做风险评估。
• 改成更完整的方案。
• 输出一份优化版。

如果它选择了最后一种，就可能从“指出问题”变成“帮你重写”。它越努力，越偏离用户想要的批判视角。

轨迹二：检索噪声变成叙事中心

用户问的是：

Agent Memory 和普通 RAG 的差别是什么？

Agent 检索后发现大量文章都在讲向量数据库、知识库、embedding。于是它开始沿着 RAG 资料组织全文，最后写成“RAG 如何增强 Agent Memory”。

这不是完全错误，但问题被换掉了。

原题是“差别”，输出变成“关系”。

轨迹三：工具路径替代思考路径

用户问：

这段日志说明系统哪里可能出了问题？

Agent 看到有日志检索工具，就不断扩大检索范围，从当前错误码查到历史任务，再查到部署记录，最后输出一堆环境信息。

但它没有真正解释最初那段日志。

工具给了它一种“继续查”的冲动。查得越多，越像认真；但推理反而被推迟了。

轨迹四：压缩摘要制造“虚假确定”

长任务里，Agent 经常需要压缩上下文。

压缩本身很有用。Anthropic 提到，compaction 可以把接近上下文窗口上限的对话总结后重新进入新上下文，让 Agent 继续工作。

但压缩也会制造风险。

原始上下文可能只是：

方案 A 可能更适合长周期任务，但证据还不充分。

压缩后变成：

方案 A 更适合长周期任务。

“可能”和“证据不充分”丢了。

下一轮 Agent 看到的是一个更确定的结论，于是继续沿着这个结论展开。跑偏就这样被摘要固化了。

一个更有用的判断框架

如果只问“Agent 有没有答对”，很容易漏掉跑偏。

更好的问题是三组：

问题	对应风险
它现在追的目标，还是用户最初给的目标吗？	目标漂移
它相信的信息，来源和可信度清楚吗？	上下文污染
它调用工具，是因为必要，还是因为工具刚好存在？	工具诱导

这不是一个操作清单，而是一个观察 Agent 的视角。

当你看一个 Agent 的输出时，不要只看它最后写得是否流畅，还要反过来看：

• 它有没有把比较题写成介绍题？
• 它有没有把外部网页当成事实来源？
• 它有没有因为工具存在而过度搜索、过度编辑、过度执行？
• 它有没有把一次失败查询当成“事实不存在”？
• 它有没有在摘要里把不确定说成确定？

这些细节，比“最后答案看起来是否合理”更能说明 Agent 有没有跑偏。

最后：Agent 越强，越要看它如何偏离

Agent 的吸引力在于，它不只是回答问题，还能自己规划、调用工具、观察反馈、继续行动。

但也正因为如此，它的问题不再只是“知识是否正确”，而是“行动链是否还围绕原始意图”。

普通模型答错了，你看到的是一个错误答案。

Agent 跑偏了，你看到的可能是一套完整、流畅、自洽、甚至看起来很努力的结果。

它最危险的地方不是荒谬，而是合理。

合理的局部动作，连在一起，不一定通向正确的整体目标。一个小的目标改写，一段低质量上下文，一个过于顺手的工具，都可能让 Agent 从“帮你完成任务”变成“完成它自己理解出来的任务”。

所以理解 Agent 跑偏，不是为了否定 Agent。

恰恰相反，只有把目标漂移、上下文污染和工具诱导看清楚，才更能理解 Agent 这种新形态到底和聊天机器人有什么不同。

它不是更长的 prompt。

也不是多几个工具。

它是一个会在循环中改变自己状态的系统。

而凡是会改变自己状态的系统，都要认真看它偏离的方式。

参考资料

1. Anthropic, Trustworthy agents in practice
2. Anthropic, Effective context engineering for AI agents
3. Anthropic, Writing effective tools for AI agents
4. OpenAI, Function calling
5. OpenAI Agents SDK, Tracing
6. Greshake et al., Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection
7. Yi et al., Benchmarking and Defending Against Indirect Prompt Injection Attacks on Large Language Models