Agent 上线之后，最让业务方抓狂的不是它偶尔报错——报错至少知道出事了。真正难受的是「不稳定」：同一个问题今天答得对、明天答得偏；测试环境跑十遍都好好的，上线后质量往下掉；同一批任务里，有的处理得漂亮，有的像换了个人。
这类问题最麻烦的地方在于，它没法用「成功率」这类指标反映出来。你去看监控，成功率 96%，看着挺好；可业务方体感是「这玩意不靠谱」。区别在于：报错是确定性的失败，不稳定是不确定的成功。
这篇按排查顺序写：先把不稳定分成三类定位，再分别从模型层、上下文层、工具数据层找原因，然后是让结果可复现的做法和评测回归，最后说清哪些环节反而要保留随机性。
第一步：先分清是哪种不稳定，三类要分开查
第一类：同类问题不同答。同一个意思的几种问法，回答的风格、详细程度、结论都不太一样。这通常是采样随机性带来的，属于「正常波动」，但波动幅度超过业务能接受的范围就变成了问题。
第二类：同一输入前后不同答。完全一样的输入，今天和上周的答案不一样，或者上午和下午不一样。这类最值得警惕，因为它意味着有什么东西在背后悄悄变了——模型版本、检索到的资料、上下文里累积的历史。
第三类：同一流程不同结果。流程没改，但外部条件变了：数据源更新了、工具返回的字段改了、下游接口开始限流。这类问题的根因不在模型，而在依赖。
三类的排查路径完全不同。用查第一类的方法去查第二类，会一直找不到原因；把第三类当成模型问题，就会去反复调提示词，白折腾。所以第一件事是：拿五个典型失败样本，把它们归到三类里，看哪一类占比最高。
第二步：模型层的确定性控制
（1）把采样参数显式固定下来。temperature、top_p、seed 这类参数，默认值往往是「不固定」。要么显式写进配置，要么接受它的波动、并只在关键环节要求一致。最忌讳的是依赖默认值，因为你不知道哪天它会变。
（2）锁模型版本，别用浮动别名。很多平台提供的是「指向最新版」的模型名，模型一升级，你的效果就跟着漂。生产环境应该锁定具体版本号，升级走测试与比对的流程。这套做法在 OpenClaw 模型版本管理 里讲得比较细，有完整的回放验证流程。
（3）同一个环节别在不同模型间随机分流。为了省钱做负载均衡可以理解，但至少要保证「同一个用户、同一条业务线的同一个环节」稳定走同一个模型。来回切模型，用户看到的就是前后两套人格。
第三步：上下文层的稳定，比参数更容易被忽略
这是最容易被漏掉的一层。模型参数没变、版本没变，答案还是会变，因为喂进去的上下文变了。
（1）检索结果的顺序。同样的检索词，命中的片段顺序一换，模型的注意力分配就变了，结论可能跟着变。稳妥做法是给检索结果一个固定的排序规则，不要依赖底层搜索引擎返回的原始顺序。
（2）历史消息的累积。同一个会话聊到第二十轮，上下文里已经堆了大量早期内容，模型的行为会和第一轮明显不同。会话该截断就截断，该摘要就摘要，不要把整段历史无脑带下去。具体做法见 AI Agent 上下文管理怎么做。
（3）系统提示里的变量。这是个特别隐蔽的坑：系统提示里塞了「当前时间」「本次请求 ID」「剩余额度」这类每次都变的字段。看着无害，实际会改变模型的输出倾向，还会让提示词缓存完全失效。跟业务无关的动态变量，别往系统提示里放。
顺带说一句缓存：同一个请求两次都命中缓存，结果自然一致；但缓存命中与否会带来「有时一致、有时不一致」的错觉。缓存怎么分层配置，可以对照 AI Agent 缓存怎么用，注意语义缓存本身就是一类「看起来一样、其实不一样」的误差源。
第四步：工具与数据层，最常被误判成模型问题
（1）外部数据真的变了。价格、库存、政策条款每天都在变，答案跟着变其实是对的。这时要检查的不是模型，而是回答里有没有带上数据的时间戳和来源——没有时间戳的答案，用户没法判断它是不是过期的。
（2）工具返回结构变了。上游接口加了字段、改了字段名、把空值从 null 改成空字符串，模型就得临场猜，猜法每次可能不同。所以工具返回要做校验，字段不符合预期就直接报错，别让模型拿到脏数据硬编。工具返回怎么设计，见 AI Agent 工具怎么设计才好用。
（3）重试带来重复执行。超时重试如果没做幂等，会写出两条记录；数据写重了，后续查询结果自然变得不可预期。这类「不稳定」的本质是数据被写坏了。幂等与重试的关系，可以参考 AI Agent 死循环怎么治 里的预算熔断部分。
（4）用格式校验挡掉一大半波动。如果输出要求是结构化的，就让 Schema 去判，不符合就重试一次，而不是把格式对错交给模型自觉。做法见 AI Agent 结构化输出怎么做。
第五步：能不能复现，决定你能不能修
一条硬标准：修不了的问题，都是复现不了的问题。所以每一次执行都必须留够信息，否则你只能在事后猜。
至少要留五样：模型名与版本号、采样参数、系统提示与提示词版本、实际检索到的片段（含顺序）、工具调用序列与返回摘要。有了这五样，才能把一次失败原样重放出来。留痕字段怎么设计，参考 AI Agent 审计查询字段怎么设计；完整留证思路见 AI Agent 证据包怎么留。
再补一条实操建议：把提示词纳入版本管理。提示词改了却没记版本号，等于把最关键的变量弄丢了。
第六步：用固定评测集把「不稳定」变成可量化指标
光靠人工感觉判断稳定与否，最后一定会吵不清。做法是建一个小而准的评测集：三十到五十个真实任务，每个任务有人工认可的标准答案或判定规则。
然后固定轮次跑：同一批任务连跑五次，看两个指标——通过率（平均有几成对）和波动幅度（五次之间的最大差异）。通过率一样但波动幅度差很多的两套配置，体感完全不同。判断标准怎么定，参考 AI Agent 评测怎么做。
这个方法还有个副作用：模型升级、提示词改动、上下文策略调整，都能用同一批任务快速验证有没有变差，不用等线上出问题。
第七步：哪些环节反而要保留随机性
追求稳定不等于追求死板。有些环节天生就该有多样性：候选生成——让它多出几个思路，人再挑；创意类内容——风格完全固定反而难看；探索性问题——第一次问就把答案锁死是浪费。
正确的做法是分层：关键结论、金额、对外承诺、写库操作要求严格一致；中间过程的思考、候选方案允许发散。一刀切追求「每次都一样」，代价是牺牲掉模型最值钱的那部分能力。
优缺点说清楚
优点：业务方能对结果有预期，才敢把它接进真实流程；问题定位速度明显提升，不用再靠「重启试试」；模型升级有了安全网，敢做迭代。
缺点：参数固定和版本锁定会让「尝新」变慢，升级要走流程；完整留痕会占存储，也增加一点延迟；评测集需要人维护，业务任务变了评测集也得改，否则会变成过期考卷。
适合人群
适合：Agent 已经进到真实业务流程、业务方开始抱怨「时好时坏」的团队；结果会被写进数据库、发给客户或用于决策的场景；做过一轮评测，但发现结论不稳定、复现不出来的团队。不适合：还在做效果验证、任务本身还没定型的阶段——这个阶段的重点应该是先摸到能力上限，不必过早锁死自由度。
六个坑
坑一：把不稳定当幻觉治。幻觉是说了不存在的事，不稳定是同一件事说法不同，两者的排查路径不一样，混着治只会白忙，幻觉那条线的治法见 AI Agent 幻觉怎么治。坑二：参数靠默认值。哪天平台改了默认值，你会毫无察觉。坑三：用浮动模型别名上生产。升级即漂移，且漂得悄无声息。坑四：系统提示里塞动态字段。看着无害，实际让输出和缓存一起不稳定。坑五：不留痕就开始讨论原因。没有可复现的证据，讨论会变成猜谜。坑六：追求 100% 一致。把探索能力一起锁死，最后做出一个稳定但没用的东西。
总结
Agent 输出不稳定，一条主线：先把不稳定分成「采样波动、版本与上下文漂移、外部依赖变化」三类分开定位；模型层固定采样参数并锁定版本；上下文层固定检索排序、控制历史长度、清理系统提示里的动态字段；工具层做返回校验与幂等；用五样留痕保证可复现；用固定评测集连跑五次量出通过率和波动幅度；最后只对关键结论要求一致，探索环节保留随机性。一句心法：稳定不是让 Agent 每次都说得一模一样，而是让每一次差异都能被解释。
