你的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）作为一等公民来观测，而不是只看最终输出。推理文本是代理的"审计日志"，比响应本身更能暴露问题。
最后留一个开放问题：你的生产环境里，代理的推理日志保留多久？当用户投诉"它明明说成功了"时，你能回溯到当时的完整决策路径吗？
热门跟贴