演示与生产面对的是不同分布
演示可能使用整理过的问题、单一账号和固定文档，生产用户则会省略条件、混用术语、连续追问，并上传质量不一的资料。一个漂亮的成功路径，只能证明该路径在当时条件下可运行。
排查时应先保留问题原文、用户权限、知识版本、模型版本和接口结果。缺少这些上下文，团队往往只能反复修改提示词，无法判断真正的问题发生在哪一层。
知识错误不一定是模型错误
先看正确资料是否存在，再看是否允许当前用户访问，然后检查解析、切分、检索和排序。若有效资料根本没有进入候选上下文，换更大的模型也未必改善答案。
对表格错位、旧版本混入或同名产品混淆，应修正数据与元信息。将失败样本分类为资料缺失、检索遗漏、证据不足和生成错误，有助于把改进措施落实到具体责任人。
工具链路需要处理真实故障
接口可能超时、限流、返回空值或在写入后丢失响应。模型不能仅凭调用已发出就宣布成功。查询工具应返回明确状态；写入工具需要幂等标识、结果查询与人工处理路径。
生产流量还会暴露并发和资源瓶颈。一次任务多轮调用模型、检索和业务接口，总耗时可能远高于单步演示。应分别测量各阶段，而不是只看最终页面加载时间。
过度自由的编排会放大波动
工具过多、职责相近、参数含糊或缺少停止条件，都可能使Agent反复尝试。可以减少工具范围、明确输入输出结构，将确定步骤放回工作流，并限制任务步数和重试预算。
会话长度、历史记忆和缓存也会改变结果。需要明确哪些状态可以复用，用户切换后是否隔离，缓存何时失效。一次成功并不表示后续长对话仍能保持相同效果。
用一次失败还原整条链路
若用户问某型号保修期限，系统答错，先确认查询时的型号、购买日期与权限，再查看有效政策是否入库、正确片段是否召回，以及答案是否遗漏适用条件。若证据已经正确而输出仍错误，再检查生成策略。这样可以明确修复属于资料、检索还是模型，不必同时更换所有组件，也便于通过同一问题验证修复。
- 失败能否在相同条件下复现。
- 是否保存必要版本与来源标识。
- 修复是否进入固定回归测试。
- 是否检查对其他问题的副作用。
用回归与灰度逐步建立稳定性
把生产问题脱敏后加入固定回归集，保留失败类型和业务影响。每次修改知识策略、提示词或模型，先比较任务成功、越权、延迟和费用，再决定是否扩大流量。
稳定性不应只以平均准确率衡量。一个偶发越权或重复写入可能比普通答错更严重，需要单独设置上线门槛。最终目标不是消除所有不确定性，而是让错误可发现、可停止、可恢复并可持续改进。