模型错还是系统错？智能体故障归因的“法医”指南-育师

凌晨的生产日志里，一个负责生成财报摘要的Agent，连续输出了三遍几乎相同的段落。团队里爆发了争论：一半人认为是“模型又抽风了”，另一半人坚持“肯定是我们的流程有bug”。而我知道，在打开代码之前，我已经有了九成把握。

在智能体系统的运维战场上，最昂贵的成本往往不是机器，而是时间——浪费在错误方向上的调试时间。“模型问题”与“系统问题”的误判，会轻易地将一个下午引向徒劳的提示词调整，或一次毫无必要的架构重构。

作为与这些“数字生命”朝夕相处的老兵，我逐渐形成了一套基于证据链的归因方法论。它无法100%精确，但能帮你用最短路径逼近真相。

在开始之前，我们必须清晰定义战场：

模型错（Model Hallucination/Bias/Incompetence）：指大语言模型自身能力边界或概率性缺陷导致的问题。其核心特征是 “即使给予完美的输入和上下文，也会产生错误或不合规的输出”。
- 典型症状：事实性错误（胡编日期、数据）、逻辑断裂、无法遵循清晰的指令、输出无关内容、陷入无意义的语言模式循环。
系统错（Orchestration/Pipeline Bug）：指我们构建的智能体框架、工作流、状态管理或工具集成中的缺陷。其核心特征是 “模型没有得到它本该得到的信息、或上下文，或被错误地驱动”。
- 典型症状：丢失历史记忆、错误调用工具、状态跳转混乱、陷入死循环、传递了污染或矛盾的上下文。

一个精辟的比喻：模型是剧团里才华横溢但偶尔忘词的演员。系统是剧本、导演、舞台调度和提词器。演出垮了，你需要判断：是演员突然发疯（模型错），还是提词器给了错误的台词、或导演让他从第三幕直接跳到了第一幕（系统错）？

当警报响起，不要急着翻代码或改Prompt。按顺序执行这三个动作。

这是你的第一现场取证。一个设计良好的智能体系统，必须记录每一轮交互的“认知现场”：

抓取“意图轨迹”：查看Agent在最终错误输出前，它的内部思考链（Chain-of-Thought）是什么？它认为自己正在执行什么任务？
1. 如果思考链清晰、逻辑连贯，但最终结论错误：这强烈指向模型错。例如，思考链显示：“用户问特斯拉Q3营收。我需要查财报。财报显示为233亿美元。所以答案是233亿美元。”但实际输出却写成了“333亿美元”。系统正确传递了任务和资料，是模型在最后一步“口误”了。
2. 如果思考链本身就开始混乱、偏离主题、或重复：这可能是系统错导致的上下文污染。例如，思考链中出现大量与当前任务无关的上轮对话片段。
审查“输入快照”：在调用模型的瞬间，系统实际喂给模型的完整Prompt和上下文是什么？
1. 关键检查点：
  - 系统指令（System Prompt）是否被意外覆盖或截断？
  - 工作记忆（Working Memory）是否正确注入了？是否包含了矛盾的信息？
  - 工具返回结果是否被正确格式化并放入上下文？例如，一个计算工具返回了{"result": 0.5}，但系统却传给了模型{"result": 0.5, "error": null}这个字符串，模型可能困惑。
2. 如果输入快照本身就是混乱、残缺或错误的：那么模型只是在“垃圾进，垃圾出”。这是典型的系统错。

实战案例：那个重复输出摘要的Agent。我们调取它的意图轨迹，发现它每轮的思考链都是：“我已生成摘要。用户未反馈。根据指令，我需要继续完善摘要。” 再查输入快照，发现系统指令中有一条被错误配置的规则：“若用户未明确说‘停止’，则继续优化”。结论：模型忠实地执行了一个错误的系统指令。这是系统错。

如果第一斧无法断定，进行这个黄金实验：绕过你的整个智能体框架，手动构造一个你认为绝对理想的输入（清晰的指令、干净的上下文、必要的知识），直接调用底层模型API。

操作：在Playground或简单脚本中，还原“案发现场”该有的完美输入。
判断：
- 如果模型在最小化测试中表现正常：那么问题几乎肯定出在你的系统层。是你的框架引入了噪声、错误的状态或逻辑。
- 如果模型在最小化测试中仍然复现了错误：恭喜（或许不该恭喜），你找到了一个模型能力边界问题或顽固的幻觉。接下来可以尝试简化指令、调整格式，如果错误依旧，可能需要切换模型或设计规避策略。

这一步用于诊断复杂的、与环境交互相关的问题，特别是工具调用和多Agent协作场景。

场景：一个电商Agent调用库存查询工具失败。
- 固定模型，替换环境：用同一个模型（如GPT-4），在你的测试环境（Mock工具）和生产环境（真实工具）分别运行。如果测试环境成功而生产环境失败，问题在于生产环境的工具接口、网络或认证（系统错）。
- 固定环境，替换模型：用同一个工具，让GPT-4和Claude分别尝试。如果GPT-4失败而Claude成功，问题可能在于模型对工具返回结果的解析能力（模型错/需要优化提示词适配）。

根据高频故障，我总结了一份快速对照清单：

典型症状	优先怀疑方向	关键证据与排查动作
事实性错误、数据捏造	模型错	检查输入快照中是否提供了正确数据。若已提供，则是模型幻觉。
完全偏离任务主题	先系统，后模型	检查系统指令是否被覆盖；检查上下文是否被其他任务污染。
循环重复执行同一操作	系统错	检查状态机是否卡在同一个状态；检查循环终止条件是否被错误满足。
工具调用参数错误	先系统，后模型	检查工具的描述（Schema）是否准确；检查模型是否被正确提示了参数格式。
忘记之前的对话内容	系统错	检查工作记忆的存储与检索机制；检查上下文窗口是否已满或被清理。
在多Agent中“角色混乱”	系统错	检查消息路由是否正确；检查Agent的专属指令是否在对话中被混淆。
处理长文档时质量骤降	需具体分析	可能是系统未正确分段或摘要（系统错），也可能是模型长上下文注意力衰减（模型局限）。

真正的归因能力，不是事后的侦探游戏，而是事前的架构设计。你必须将以下三点融入系统的骨髓：

完整的溯源日志：每一次模型调用，都必须关联一个唯一ID，并记录其完整输入、完整输出和触发此次调用的系统状态。这是你的“黑匣子”。
意图与执行的差分对比：像之前提到的，记录Agent“计划做什么”和“实际做了什么”的对比。任何偏差都是系统的责任。
健康度指标分离：定义并监控两类独立指标：
1. 模型健康度：困惑度、拒绝回答率、内部一致性得分。
2. 系统健康度：任务完成率、工具调用成功率、状态转换异常率、上下文污染警报。