当前位置：首页 > news >正文

Agent 为什么会「幻觉」或「乱调工具」？如何缓解？

news 2026/6/15 18:59:42

如果你用过 ChatGPT、Claude Code、Cursor 这类 Agent 产品，大概率遇到过这种场景：你让它搜个文件，它跑去调了 git commit；你让它改个 bug，它开始编造不存在的 API；甚至你让它"别动那个文件"，它转头就给你删了。
这些行为背后，本质上是两个问题：幻觉（Hallucination）和工具误用（Tool Misuse）。本文从原理层面拆解原因，并给出可落地的缓解方案。

一、幻觉和乱调工具，其实是同一个根因的两个表现

很多人把"幻觉"和"乱调工具"当成两个独立问题，但本质上它们共享同一个底层机制：

幻觉：模型生成了与事实不符的内容（编造函数名、虚构 API、捏造数据）
乱调工具：模型在错误的时间、用错误的参数、调用了错误的工具

两者都是模型在生成 token 时，概率分布偏离了正确路径的结果。区别只在于——幻觉发生在"文本空间"，乱调工具发生在"动作空间"。

二、为什么会发生？5 个核心原因

2.1 训练数据的「时间错位」

模型训练数据存在截止日期。当你让它调用一个 2025 年才发布的 SDK 时，模型根本没见过这个 SDK 的真实 API。但它不会说"我不知道"，而是基于见过的类似库（比如旧版本、竞品库）去"推测"——这就是幻觉的起点。

对于 Agent 来说，这种推测会直接体现在工具调用上：它可能用旧版参数格式去调新版 API，或者调用一个它"觉得应该存在"但实际不存在的函数。

2.2 上下文窗口的「注意力稀释」

现代 LLM 动辄支持 200K token 的上下文，但这不代表它们能同等关注窗口内的每一个 token。研究表明，模型对开头和结尾的内容关注度最高，中间部分会出现明显的"注意力衰减"。

Agent 场景下这个问题尤为严重：

系统提示词（system prompt）几百行
工具定义（tool definitions）几十个，每个都有详细描述
对话历史可能长达数万 token
中间夹杂的错误信息、无关输出会进一步干扰注意力

当模型"看不清"某个工具的描述时，它就会基于工具名称去"猜"这个工具的用途——猜错就是乱调工具。

2.3 工具定义的「语义冲突」

一个典型 Agent 往往挂载 20-50 个工具。当多个工具的功能描述存在重叠时，模型很难做出正确选择。

举个例子：search_code和find_files和grep_content，在模型眼里可能"差不多"，但它必须精确选一个。这种模糊边界是工具误用的高发区。

更隐蔽的问题是参数层面的语义冲突——两个工具都有path参数，但一个期望绝对路径，一个期望相对路径。模型如果混淆了这两个工具的参数语义，调用的结果就会出错。

2.4 自回归生成的「误差累积」

LLM 是逐 token 生成的，每个 token 都依赖前面所有 token。这意味着：

如果模型在生成工具名的 token 时就偏了（比如选了Write而不是Read），后续的参数 token 会在这个错误的基础上继续生成
模型不会"回头检查"自己的工具选择是否正确——它只会让后续 token 与错误选择保持自洽
这就是为什么有时候你会看到 Agent 用一个完全不合适的工具，但参数却填得"有模有样"

2.5 强化学习中的「奖励黑客」

很多 Agent 系统使用 RLHF 或基于反馈的微调。在这个过程中，模型可能学到了一些"捷径"：

发现调用更多工具 = 人类评分更高（因为显得"努力"）→ 开始无意义地堆叠工具调用
发现输出更长 = 评分更高 → 开始冗余操作
发现"做了总比不做好" → 即使不确定也会强行调用工具

这种行为模式在训练数据中被强化后，就会在生产环境中表现为"乱调工具"。

三、怎么缓解？6 个可落地的方向

3.1 工具设计的「极简原则」

少即是多。每多一个工具，模型的决策空间就指数级膨胀。具体做法：

合并同类工具：ReadFile+ReadJSON+ReadYAML不如一个Read工具，通过参数或文件扩展名区分行为
砍掉"便利性"工具：只为高频、不可替代的操作创建工具。一个"用不到 1% 场景"的工具，对模型的干扰远大于它的价值
工具名即契约：工具名应该精确描述它做什么，避免模糊动词。Analyze就是坏名字，RunStaticAnalysis才是好名字

3.2 工具描述的「强制区隔」

当多个工具存在语义重叠时，在描述中明确标注边界：

Tool: SearchCode Description: Search for code PATTERNS (regex) in file CONTENTS. Use this when you know WHAT code you're looking for. DO NOT use this to find files by name — use Glob instead.  Tool: Glob Description: Find files by NAME pattern (glob). Use this when you know the FILE NAME or PATH pattern. DO NOT use this to search inside file contents — use SearchCode instead.

关键技巧：在每个工具描述中显式写出"不要用这个工具做什么"。模型对否定句的注意力往往高于肯定句。

3.3 分阶段提示（Chain-of-Thought for Tool Selection）

在 system prompt 中强制模型在选择工具前先做推理：

Before calling any tool, you MUST: 1. State WHAT you need to accomplish (one sentence) 2. State WHICH tool best matches that need (one sentence) 3. State WHY other similar tools are NOT appropriate (one sentence) 4. THEN call the tool

这相当于给模型一个"思考缓冲区"，避免它直接从意图跳到工具调用。额外的推理 token 会显著提高工具选择的准确率。

3.4 工具调用前的「护栏校验」

在 Agent 框架层面加校验层，而不是完全依赖模型的判断：

参数校验：必填参数缺失？参数类型不对？→ 直接拦截，返回错误描述让模型重试
危险操作拦截：rm -rf、DROP TABLE、force push→ 二次确认或直接拒绝
冲突检测：刚创建的文件 2 秒后就要删除？→ 标记为可疑，要求确认
循环检测：同一个工具+同一组参数在 N 次内反复出现？→ 中断并提示

3.5 让模型「看到」工具调用的结果再做下一步

很多 Agent 框架允许模型在一次响应中连续调用多个工具。这看起来高效，但实际上模型是在"盲猜"——它不知道第一个工具的结果，就开始规划第二个工具的调用。

更稳妥的做法是严格交替：模型调一个工具 → 系统执行并返回结果 → 模型看到结果后再决定下一步。Claude Code 采用的正是这种模式。虽然多了一轮往返延迟，但大幅降低了级联错误。

3.6 明确告诉模型「你可以拒绝」

大多数 system prompt 都在告诉模型"你能做什么"，很少告诉它"你可以不做什么"。增加类似以下的指令可以显著减少幻觉：

If you are unsure which tool to use, or if no tool matches the user's request, say so explicitly rather than guessing. It is better to ask for clarification than to call the wrong tool.

这听起来简单，但在实际测试中，仅这一条指令就能将工具误用率降低 10-20%。

四、一个实操框架：防御性 Agent 设计

把上面的点串起来，可以形成一个防御性 Agent 设计清单：

层级	措施	解决的问题
工具层	精简工具数量、合并同类、明确边界	决策空间过大、语义冲突
提示层	分阶段推理、否定边界描述、拒绝许可	注意力稀释、盲目猜测
框架层	参数校验、危险拦截、循环检测	误差累积、奖励黑客
流程层	严格交替执行、单步确认	级联错误、盲猜后续