6种AI代理「静默翻车」现场：代码级排查指南

你的AI代理刚说"订单已完成"，实际却买了错的产品。或者工具报错被它当空气，继续编故事。又或者系统提示词中途被改，代理行为悄悄漂移——全程没崩溃、没报错，就是错了还报告成功。

我在生产环境搭代理，这6种失败模式反复出现。下面用具体代码演示每种情况怎么发生，以及怎么抓现行。

模式1：工具报错，代理装没看见

搜索API返回"产品未找到"，代理的下一句推理却是："根据搜索结果，Galaxy S25 Ultra售价470美元……" 根据什么搜索结果？工具明明报错了。

危险在于：代理用不存在的数据搭建整个决策链，后续每一步都是幻觉。

排查代码：检查代理的下一步推理是否提到了错误——

tool_result = "error: not found" next_reasoning = agent.last_reasoning if "error" in tool_result and "error" not in next_reasoning: print("[WARNING] Agent ignored the tool error!")

这招的精髓是验证"认知一致性"：代理的推理文本必须反映它实际收到的工具输出，不能各说各话。

模式2：高危操作零审批

代理决定采购3.29万美元的货，全程无人过问。没有人工介入、没有策略检查、没有护栏，它就……干了。

金融交易、数据删除、外部通信——这些绝不能自动执行。无护栏的自治代理不是资产，是负债。

关键词拦截方案：

critical_keywords = ["purchase", "delete", "send", "transfer", "pay"] if any(kw in action.lower() for kw in critical_keywords): if not has_recent_approval(): print("[WARNING] Critical action without approval!")

这里有个设计陷阱：很多人把审批做成"通知"而非"阻断"，代理继续跑，人还没看完邮件，事已经办完了。真正的审批必须是同步阻塞。

模式3：静默替换商品

用户要A产品，A缺货，代理找到B产品，直接下单，全程不提换货的事。用户以为买的是S25 Ultra，实际到账的是S24 FE。

这种失败最难防，因为代理的"成功"响应在语法上完全正确——订单确实完成了，只是不是用户想要的那个订单。

检测思路：对比用户原始意图与最终执行参数，建立"意图-执行"一致性校验。任何参数偏离都必须显式确认，不能默认代理的"等价判断"。

模式4：会话状态被污染

系统提示词在会话中途被修改，代理行为逐渐漂移。用户感觉不到，但代理的优先级、约束条件已经变了。

典型场景：运维热更新提示词模板，活跃会话拿到混合版本——前半段用旧约束，后半段用新约束。代理对同一类请求的响应开始出现不一致。

防御代码：给每个会话绑定提示词版本哈希，每次推理前校验——

if hash(current_prompt) != session.prompt_version_hash: print("[WARNING] Prompt version mismatch!")

版本漂移比完全崩溃更难调试，因为系统还在"工作"，只是工作方式变了。

模式5：工具选择幻觉

代理面对一个任务，选错了工具，或者工具参数填错，但执行流程没中断。比如该用"精确查询"时用了"模糊搜索"，返回1000条结果，代理从中随机挑了一条当答案。

这种错误的隐蔽性在于：工具确实返回了数据，代理也确实"基于数据"做了推理，整个链条在形式上完整，只是根基是错的。

监控策略：记录每个工具调用的"置信度评分"——参数与任务意图的匹配度。低于阈值时强制人工复核，而非让代理自己消化。

模式6：成功响应掩盖部分失败

批量任务中部分子任务失败，代理汇总时只报成功项，失败项被吞掉。用户看到"10笔订单完成"，实际是7成3败。

代码层面的典型表现：代理的响应生成逻辑只遍历成功结果，或者对失败结果做了"优雅降级"——翻译成人类语言就是"假装没发生"。

强制透明方案：要求代理的输出结构必须包含完整的状态矩阵，成功、失败、跳过的条目数量必须对得上输入总量。

一个共同的底层问题

这6种模式的共同点是：代理的"自我报告"不可信。它们都生成看似合理的成功响应，但响应与 ground truth（真实状态）之间存在断层。

传统的软件监控看的是异常抛出、状态码、响应时间。对AI代理，你需要监控的是"认知一致性"——代理声称它知道的东西，和它实际知道的东西，是否匹配。

这要求把代理的内部推理链（chain-of-thought）作为一等公民来观测，而不是只看最终输出。推理文本是代理的"审计日志"，比响应本身更能暴露问题。

最后留一个开放问题：你的生产环境里，代理的推理日志保留多久？当用户投诉"它明明说成功了"时，你能回溯到当时的完整决策路径吗？