大家好，我是金全。
上一篇讲质量评估。
我们讨论的是，
Agent Trace 很完整不等于企业已经知道一次 AI 行为做得好不好。
行为链回答：
发生了什么？
证据链回答：
为什么这样判断？
质量评估回答：
这次行为做得怎么样？
但到这里，还有一个更现实的问题会出现。
如果一次 Agent 的评测结果不错，任务完成率也不低，安全检查也通过了，企业是不是就可以把它放进生产？
很多时候，答案仍然是否定的。
不是因为评测不重要。
恰恰相反，评测是 Agent 进入生产前必须具备的能力。
但评测能够度量和验证已知条件下的表现，
不能单独证明它已经具备生产能力。
所以我越来越觉得：
评测通过，不等于生产就绪。
评测证明的是已知条件下的表现。
生产考验的是变化环境中的稳定性。
越来越多企业开始关注的，也不再只是 Agent 能不能通过评测，而是进入真实生产以后，质量差异能不能被发现，形成原因能不能被解释。
这就是第 18 篇想讨论的问题。
Demo 证明它会做，评测证明它做得不错
很多 Agent 项目，最早都从 Demo 开始。
给它一个清晰任务。
提供固定上下文。
接入几个工具。
看它能不能完成一次完整流程。
如果 Demo 成功，企业会得到第一个信心：
它会做。
但 Demo 成功，并不代表它真的可靠。
所以企业会继续做评测。
准备一组测试任务。
定义正确答案或者评分标准。
比较不同模型、Prompt、工具流程和 Agent 版本。
看任务完成率、事实准确性、工具选择、格式合规、安全边界和成本表现。
如果评测结果不错，企业会得到第二个信心：
它在这些已知条件下做得不错。
这一步非常重要。
没有评测，企业只能凭感觉相信 Agent。
有了评测，企业至少可以知道：
在当前数据集、当前版本、当前标准下，它大概表现如何。
但生产环境并不是一组固定测试题。
生产环境每天都在变化。
评测通过，证明的到底是什么
评测容易被误解成一张通行证。
好像只要通过了，就可以上线。
但严格说，评测通过只证明几件事。
第一：它证明 Agent 在某一组任务上表现不错。
这些任务可能来自历史案例、人工构造、典型流程或者线上问题沉淀。
但它不可能覆盖所有未来任务。
第二：它证明 Agent 在某一套版本下表现不错。
模型版本、Prompt、知识库、工具接口、业务规则、工作流，只要其中一项变化，评测结果就可能变化。
第三：它证明 Agent 在某一套评估标准下表现不错。
标准关注事实准确，它可能忽略业务后果。
标准关注格式合规，它可能忽略客户体验。
标准关注安全边界，它可能忽略任务是否真正完成。
所以，评测结果一定有适用范围。
它不是永久有效的质量证明。
它更像是一次阶段性判断：
在这些任务、这些数据、这些版本和这些标准下，它表现不错。
这已经很有价值。
但它还不是生产就绪。
上线前，评测是质量门禁。
生产中，评测是质量信号。
完成改进以后，评测又是验证结果的手段。
生产环境改变了四件事
Agent 一旦进入生产，企业面对的就不再是固定测试集，而是真实的 AI 运行现场。
这里至少有四件事会持续变化。
第一：任务在变化。
用户表达更复杂。
业务请求更含混。
同一个问题，可能夹杂着投诉、补偿、权限、历史订单和人工记录。
测试集里看起来简单的分类任务，在线上可能变成多轮判断。
第二：上下文在变化。
知识库会更新。
规则会调整。
用户状态会变化。
系统里的数据可能刚刚同步，也可能还没有同步。
Agent 看到的上下文，并不总是评测时那一份稳定材料。
第三：运行环境在变化。
接口可能超时。
字段可能调整。
第三方服务可能返回异常。
一个工具在测试环境里表现正常，到了生产环境可能因为权限、数据规模、网络和并发变得不可预测。
第四：业务环境在变化。
同一个动作，在不同客户、金额、流程、风险等级下，后果完全不同。
在评测里，错误答案只是一个低分。
在生产里，错误动作可能意味着客户权益被误处理、订单状态被修改、配置被错误发布，或者人工团队被迫返工。
这就是为什么很多企业明明已经完成了评测，仍然不敢直接上线。
企业需要验证的，从来不是 Agent 能不能做对一次。
而是在环境持续变化时，它还能不能持续做对。
生产就绪，不是一次评测通过
如果说第 17 篇讨论的是行为质量，那么第 18 篇要往前推一步：
企业怎样判断一个 Agent 是否具备生产就绪能力？
我不建议把这个问题一上来讲成治理、审批或者授权。
那会太快。
在这个阶段，企业首先要回答的仍然是可观测性问题：
-
它上线以后，AI 运行现场能不能被还原？
-
线上任务和评测任务的差异能不能被识别？
-
质量下降能不能被发现？
-
低质量行为能不能追到具体任务、版本、工具、知识和业务后果？
-
发现问题以后，能不能回到当时的行为、证据、版本、环境和业务后果，解释差异是怎样形成的？
-
问题修复以后，能不能重新验证它是否真的改好了？
这些问题如果回答不了，即使完成了评测，Agent 也很难真正具备生产能力。
所以我更愿意把生产就绪理解为四件事：
在真实运行中仍然可观察。
在变化环境中仍然可评估。
在出现质量差异以后仍然可调查。
在完成改进以后仍然可验证。
这四件事都不是一次评测报告可以完成的。
它们要求企业把质量信号和 AI 运行现场连接起来。
评测发现差异，AI 运行现场解释差异
过去很多软件系统上线以后，企业会重点看稳定性。
错误率。
延迟。
资源消耗。
告警数量。
这些仍然重要。
但 Agent 进入生产以后，企业还必须持续观察另一类信号：
真实任务里的行为质量有没有下降？
某些任务类型是否开始频繁失败？
新知识上线以后，判断依据是否发生偏移？
工具接口变化以后，Agent 是否开始选择错误路径？
某个版本的 Prompt 是否让它更容易越过边界？
质量评估可以帮助企业发现这些差异。
它可以告诉企业：
某类任务的完成率下降了。
某个版本的事实准确性变差了。
某些行为开始频繁越过边界。
但一个分数、一条质量告警或者一次失败标签，仍然不能自动说明原因。
发现这些差异以后，企业要做的已经不只是重新评测，而是启动一次生产调查，进入当时的 AI 运行现场。
企业接下来要核验的是：
任务是什么？
Agent 看到了哪些上下文？
哪些证据实际影响了判断？
使用了什么模型、Prompt、知识和工具版本？
运行环境发生了什么变化？
最终造成了什么业务后果？
只有这些事实被关联起来，企业才可能解释：
这次质量差异到底是怎样形成的。
所以，评测不是生产调查的答案。
它更像是生产调查的入口。
评测负责发现质量差异。
AI 运行现场负责提供解释差异所需的事实。
生产调查要做的，是进入 AI 运行现场，把行为、证据、版本、环境和业务后果组织起来，形成一条可以核验的解释。
这正是可观测性进入 AI 运行现场以后，需要继续往前走的一步。
生产问题还要回到下一次验证
生产调查解释了问题为什么发生，还不代表问题已经解决。
企业还要把修复后的版本重新放回同类任务和真实环境中，确认质量是否恢复，新的问题有没有出现。
生产里的失败也应该进入下一轮评测。
但它不能只留下一条失败样本。
它还要带着当时的行为、证据、版本、环境和业务后果一起回来，才能指导下一次改进。
否则，评测可能仍然通过，线上却在重复发生同一类问题。
上线的，不只是模型
很多人会本能地认为：
只要模型更强，Agent 进入生产的问题自然会减少。
模型能力当然重要。
但强模型本身，并不自动等于稳定生产系统。
一个长期运行的 Agent，周围一定还有很多东西：
任务说明。
上下文组织。
工具协议。
权限边界。
异常处理。
记忆和状态。
评估标准。
反馈循环。
这些东西共同决定了它在生产环境里能不能持续做对。
换句话说，企业上线的，从来不只是一个模型。
而是一整套围绕模型持续运行的工作系统。
模型只是其中最核心的一部分。
质量评估只是其中必须具备的一层。
如果周围的运行机制不清楚，质量信号无法回到真实现场，生产问题也无法被解释和验证，那么模型再强，企业仍然很难放心把真实任务交给它。
从质量信号，到生产能力
第 14 篇开始，我们一直在讨论 AI 运行现场。
行为链让企业知道：
发生了什么。
证据链让企业知道：
为什么这样判断。
质量评估让企业知道：
这次行为做得怎么样。
生产调查继续回答：
质量差异为什么会形成。
第 18 篇继续往前走一步。
企业还要知道：
这种质量能不能在真实变化中持续保持。
这些能力不是一条从前到后的固定流水线。
行为事实、证据关系、版本环境和业务后果共同构成 AI 运行现场。
质量评估从中发现差异。
生产调查进入 AI 运行现场解释差异。
改进完成以后，企业再通过评测和真实运行验证结果。
Demo 证明它会做。
评测证明它在已知条件下做得不错。
生产要求它在变化环境中持续做对。
AI 进入生产以后，评测不再只是一张上线前的成绩单，而开始成为持续发现质量差异、验证改进结果的一种基础能力。
至于差异为什么形成，仍然需要启动一次生产调查，进入 AI 运行现场寻找答案。
最后我想说：
生产就绪，不是一次评测通过。
而是在真实变化中，企业仍然能够发现差异、解释原因，并验证问题是否得到改善。
下一篇，我想继续讨论：
生产里的问题，为什么不能只留在告警里？
#AI系统 #AI可观测性 #因果AI #AgentOps #AI运行系统
行业参考：OpenAI Evaluation best practices、LangSmith Evaluation concepts、Anthropic Effective harnesses for long-running agents。
