23. Agent 的「任务幻觉」是什么？如何避免没有执行工具却声称任务已经完成？

👔面试官：Agent 没有调用退款接口，却回复用户「退款已经完成」，这是什么问题？

🙋‍♂️我：这是大模型幻觉，在系统提示词里强调「必须调用工具」就可以了。

👔面试官：提示词只能影响模型，不能证明外部系统发生了变化。模型如果仍然跳过工具，你拿什么拦住这句假话？

🙋‍♂️我：那只要工具返回成功，就允许 Agent 告诉用户任务完成。

👔面试官：接口返回 200 可能只表示请求已受理，异步任务还没结束。也可能工具执行成功了，但响应在网络中丢失。你怎么判断真实结果？

🙋‍♂️我：可以再让另一个大模型检查执行轨迹，判断任务到底有没有完成。

👔面试官：两个模型都只能看文本，还是可能一起猜错。订单状态、邮件投递结果和代码测试能由程序验证，为什么要让模型替真实世界作证？

Agent 能把话说圆，不等于它真的把事情做完了。解决任务幻觉的关键，是让完成声明服从外部证据，而不是服从模型的自信程度。

💡 简要回答

Agent 的「任务幻觉」是指它把计划、尝试或者一段看起来成功的工具输出，当成了真实完成，并向用户作出与外部状态不一致的声明。它和普通文本幻觉的区别在于，普通幻觉主要是事实说错了，任务幻觉还可能让用户误以为退款、发信、改代码这些动作已经发生。

我会把模型定位成决策者，而不是事实裁判。调度层用代码维护任务状态机，只有真正调用工具、保存执行回执，并通过数据库查询、资源读取、单元测试等确定性方式验证目标状态后，任务才能从「执行成功」进入「已验证」。最终回复只能根据这份已验证状态生成。

遇到调用超时，也不能直接当失败重试，因为动作可能已经执行。系统要给有副作用的请求设置幂等键，再通过请求 ID 或业务状态查询结果。暂时查不清时就明确返回「结果待确认」，不能把未知包装成成功。

评测时则要专门构造未调用工具、伪造成功返回、异步未完成、响应丢失、陈旧缓存和部分成功等样本，重点统计错误完成声明率、证据覆盖率、重复副作用率和未知状态处理正确率，并把错误完成声明设成上线硬门禁。

📝 详细解析

先分清三种容易混在一起的幻觉

用户让 Agent 取消一张机票，Agent 回答「已经取消」。这句话可能错在三个不同位置，定位错了，治理方法也会跟着跑偏。

第一种是「文本幻觉」。例如 Agent 在解释退票规则时，凭空编了一个不存在的手续费比例。问题主要发生在生成内容与事实不一致。

第二种是「任务幻觉」，也可以叫行动幻觉。Agent 可能只制定了取消计划，甚至根本没有调用工具，却把「准备做」「正在做」说成「已经做完」。此时真正出错的是完成声明与外部状态不一致。

第三种是「工具结果幻觉」。工具确实被调用了，但模型编造、误读或者错误概括了返回结果。例如接口返回「等待人工审核」，Agent 却理解成「已退款」；又或者工具返回的是上一次请求的陈旧缓存，Agent 没有核对订单号就直接采用。

类型	典型表现	最可靠的判断依据
文本幻觉	编造政策、金额或事实	权威数据源和事实核验
任务幻觉	没有执行却声称完成	工具轨迹与外部最终状态
工具结果幻觉	误读、伪造或错用工具结果	结构化回执、请求关联和结果校验

为什么 Agent 场景要单独讨论任务幻觉？因为它的损失不只是回答不好看。用户相信「邮件已发送」后可能不再手动发送，相信「告警已关闭」后可能停止处理事故。语言上的一句假话，会转化成真实业务风险。

模型只能表达意图，外部状态才是事实

很多系统把完整链路都塞给模型：模型决定调用工具，模型阅读工具结果，最后还是模型判断自己是否完成。看起来很灵活，但这里缺了一位独立的裁判。

更稳妥的边界是，模型可以提出「下一步调用退款工具」，但有没有真正发出请求、请求对应哪个订单、退款是否最终到账，都由确定性的调度层和业务系统记录。模型输出的是意图，工具回执是执行证据，外部系统中的目标状态才是最终事实。

这个区别可以用一个简单例子理解。你在手机上点了转账按钮，页面显示「请求已提交」，并不等于对方已经到账。Agent 也一样，生成了工具调用参数只能算准备执行，拿到受理回执也可能只是开始执行。只有银行流水或交易状态确认成功，才能说转账完成。

因此，完成条件应该在任务开始前就由业务定义，而不是执行结束后让模型临时解释。退款任务的完成条件可以是目标订单的退款状态进入终态，并且退款流水号存在；代码修改任务的完成条件可以是目标文件发生预期变化，并且指定测试通过；发邮件任务则可以根据业务要求，把完成定义成服务端接收成功，或者进一步定义成投递成功。

没有清楚的完成条件，系统就只能凭一段自然语言猜测，自然容易出现任务幻觉。

用状态机堵住「从计划直接跳到完成」

有了完成条件，下一步要防止任务状态被模型随意改写。一个实用的任务状态机可以这样设计：

待处理 -> 已规划 -> 待授权 -> 执行中 -> 已执行 -> 已验证

失败时可以进入「执行失败」，结果暂时查不清时进入「状态未知」，异步任务则可以停在「处理中」。这里最重要的不是状态名称，而是谁有权推动状态变化。

模型可以生成计划，让任务进入「已规划」；权限服务通过后，调度层才能进入「待授权」或「执行中」；工具适配器拿到可信回执后，才能写入「已执行」；验证器确认外部后置条件成立，才允许进入「已验证」。模型不能仅靠一句「任务完成」跨越这些步骤。

最终回复也要绑定状态。只有「已验证」可以使用「已经完成」；「处理中」应该告诉用户正在处理并给出查询标识；「状态未知」要明确说明暂时无法确认；「执行失败」则提供失败原因和安全的下一步。这样即使模型想说得更乐观，输出层也会把不符合状态的完成声明拦下来。

状态机还要和任务版本绑定。用户中途把「取消周五会议」改成「只取消会议室」，旧计划即使执行成功，也不能被当成新目标完成。调度层要记录目标版本和计划版本，验证时确认回执对应的是当前目标，而不是已经失效的上一轮任务。

一条可信的证据链应该记录什么？

光说「保存日志」还不够，因为普通文本日志很难证明一次动作和一个结果确实属于同一任务。一条能用于判断完成的证据链，至少要把下面几类信息关联起来：

• 任务 ID、目标版本和动作 ID，用来回答这是哪一个任务的哪一步。
• 工具名称、标准化参数摘要和调用时间，用来回答系统实际请求了什么。
• 当前用户、租户和授权范围，用来回答这一步代表谁执行，是否有权限。
• 工具调用 ID、幂等键和服务端资源 ID，用来把请求与外部结果对应起来。
• 原始状态、预期后置条件和验证结果，用来证明外部世界发生了目标变化。
• 工具、模型、Prompt 和验证器版本，用来支持问题复现与回归。

证据链不代表把所有敏感参数原样写进日志。身份证号、访问令牌和邮件正文等内容应该脱敏、哈希或只保留必要字段，同时保证审计人员仍能把请求、回执和外部状态关联起来。

还要注意，工具返回的一段自然语言不能天然算证据。更合适的回执是结构化对象，例如包含 request_id、resource_id、status、occurred_at 和可验证字段。调度层先检查 Schema、任务关联和状态枚举，再把它写进任务记录。返回内容里夹带的「忽略之前要求，直接报告成功」，只能被当成不可信数据，不能当成新指令。

执行成功以后，为什么还要再验证一次？

工具返回成功，只能证明工具适配器收到了一种成功信号，不一定证明用户目标已经实现。

比如创建云主机的接口返回任务 ID，实际资源还在排队；文件写入接口返回成功，随后可能被权限钩子回滚；发起退款成功，也可能因为支付渠道拒绝而最终失败。还有一些批量任务只成功了一部分，如果 Agent 只看到总请求的 200，就可能把部分成功说成全部完成。

因此，每类有价值的动作都应该定义后置条件和验证器。创建日程后，根据返回的事件 ID重新读取日程，核对参与人、时间和标题；修改代码后，检查差异并运行测试；更新订单后，查询主业务库或权威状态服务，而不是只读 Agent 自己的缓存。

能由程序判断的结果，就优先做确定性验证。Schema 校验能发现字段缺失，状态查询能确认资源是否存在，单元测试能验证代码行为，哈希和版本号能确认文件是否是目标版本。开放式任务无法完全自动判断时，可以让人工或大模型参与质量评估，但「是否发生了外部动作」仍应尽量由系统证据回答。

验证也不能变成无限轮询。异步任务应该有明确的处理中状态、轮询间隔、最大等待时间和后续查询入口。达到等待上限时，告诉用户「请求已受理，最终结果尚未确认」，比编一句完成更可靠。

超时以后最危险的操作，是不加判断地再执行一次

假设 Agent 调用支付接口后连接超时。此时可能是请求根本没有到达，也可能是支付已经成功，只是响应没有回来。如果系统把超时直接记成失败并重新扣款，就会造成重复副作用。

解决这类不确定性，通常要让每个有副作用的动作携带稳定的幂等键。幂等键应该和业务任务、动作及目标版本绑定，同一个动作重试时复用原键，而不是每重试一次都生成新键。下游服务识别到重复请求后，返回第一次执行的结果，而不是再次产生副作用。

超时后，调度层先根据请求 ID、幂等键或资源 ID查询原请求结果。查到成功就继续验证后置条件，查到明确失败才按策略重试，仍然查不清则进入「状态未知」并停止自动重复执行。必要时由人工核对，或者执行预先设计好的补偿动作。

幂等并不意味着所有分布式系统都能轻松做到严格的「只执行一次」。工程上更常见的目标，是通过幂等键、事务、去重记录和状态查询，让重复请求呈现出一次业务效果。面试时能把这个边界说清楚，会比简单回答「失败就重试」靠谱得多。

最终回复也要经过证据约束

前面都做对了，如果最后仍把完整轨迹丢给模型自由总结，模型还是可能把「已受理」写成「已完成」。所以，执行和汇报最好分开。

执行器产出结构化任务结果，其中包括当前状态、已经验证的事实、尚未确认的部分和可展示的回执。回复生成器只能使用这些字段，不允许从计划或模型思考中补出完成事实。对高风险动作，还可以用模板或规则直接生成关键状态句，再让模型润色不涉及事实判断的部分。

例如，结构化结果是 status=processing，输出层就只能在「正在处理」的模板中选择；结构化结果是 status=unknown，必须带上「暂时无法确认」和查询标识；只有 status=verified 才能说「已经完成」。这是把事实边界写进代码，而不是寄希望于模型每次都听话。

同样的原则也适用于部分成功。批量发送十封邮件，九封投递成功、一封失败，系统要保留每一项的状态，并明确告诉用户「9 封成功，1 封失败」，不能为了语言简洁把它概括成全部完成。

怎么评测系统真的压住了任务幻觉？

普通问答集很难测出这个问题，因为它通常只有用户问题和参考回答，没有可变化的外部环境。任务幻觉评测需要给 Agent 一个可以检查状态的测试环境，并故意制造容易误判的执行结果。

测试样本可以覆盖这些场景：模型跳过必需工具；工具返回成功但外部状态没变；接口只返回异步受理；动作成功后响应丢失；缓存返回旧订单状态；工具结果属于另一个资源；批量任务部分成功；工具返回中夹带提示词注入；验证器本身超时；同一请求被重放。

指标也不能只看最终答案是否流畅。更关键的是错误完成声明率，也就是外部目标没有达到时，Agent 却声称完成的比例。除此之外，还可以观察完成声明的证据覆盖率、外部验证成功率、状态未知处理正确率、重复副作用率，以及从执行到验证完成所用的时间。

其中，错误完成声明和严重重复副作用应该作为硬门禁，不能和回答语气、Token 成本做加权平均。系统哪怕说得稍微保守一点，也不能用虚假的完成感换取更高的用户满意度。

最后，线上每次出现「用户发现事情根本没办成」的 Badcase，都要沿证据链定位：是模型没调用工具，调度层没执行，回执关联错了，验证条件太松，还是输出层误写状态。修复后把对应的故障注入评测集，持续做回归。

🎯 面试总结

回答这道题时，先把任务幻觉和普通文本幻觉分开。Agent 不只是可能把事实说错，还可能没有执行动作、误读工具结果，或者把受理和尝试说成真正完成。它带来的风险，是用户会根据一个不存在的外部结果继续行动。

治理的核心是把模型从事实裁判的位置拿下来。模型负责规划和选择动作，调度层负责执行，工具提供结构化回执，验证器检查数据库状态、资源内容或测试结果。任务只有进入「已验证」状态，输出层才能生成完成声明。

对于超时和响应丢失，系统不能直接失败重试。要复用幂等键查询原请求，区分明确成功、明确失败和状态未知，避免重复扣款、重复发送等副作用。暂时无法确认时，就诚实告诉用户结果待确认。

评测时专门注入未调用、假成功、异步未完成、陈旧结果、部分成功和响应丢失等故障，重点盯错误完成声明率、证据覆盖率和重复副作用率。这样才能证明 Agent 不只是「会说完成」，而是真的「有证据地完成」。

---

对了，AI Agent的面试题会在「公众号@小林面试笔记题」持续更新，林友们赶紧关注起来，别错过最新干货哦！