大家好，我是金全。
上一篇我们讨论的是：
Agent 评测通过以后，为什么仍然不能直接进入生产。
评测通过，只能证明 Agent 在已知条件下表现不错。
进入生产以后，企业面对的是持续变化的任务、上下文、运行环境和业务环境。
所以，Agent 进入生产以后，质量评估首先要帮助企业发现质量变化。
它可以告诉企业：
某类任务的完成率下降了。
某个 Agent 版本的准确性变差了。
某些越界行为开始增加。
但发现这些变化以后，问题并没有自动得到解释。
这就像过去做可观测性。
告警响了，只说明有一项指标越过了阈值。
至于为什么越过阈值、影响了什么、下一步该查哪里，仍然要回到生产现场。
AI 进入生产以后也是一样。
而且问题更复杂了。
因为很多 AI 问题发生时，系统并没有报错。
模型返回正常。
工具调用成功。
接口状态是 200。
任务甚至显示已经完成。
但客户的问题没有解决，业务状态被错误修改，
或者 Agent 在一条看似合理的路径上作出了错误判断。
这时，企业可能发现一项质量异常。
如果这项异常触发了告警，告警也只能告诉企业：
这里出现了差异。
它不会自动告诉企业：
这次差异是怎样形成的。
所以我越来越觉得：
告警是 AI 生产调查的入口，不能成为生产问题的归宿。
这里说的 AI 生产调查，不是重新定义事故处理，
而是围绕一次 AI 行为，还原问题形成过程。
为什么 AI 进入生产以后，告警必须继续走向调查？
传统可观测性通常围绕系统状态、请求链路和变更展开调查。
团队常用的分析单位，是一个服务、一个接口、一次请求或者一条 Trace。
AI 的很多生产问题，还发生在一次业务行为的形成过程里。
任务怎样被理解。
哪些信息影响了判断。
为什么选择这个动作。
最终怎样改变了业务状态。
AI 生产调查并不抛弃服务、接口和 Trace。
但它必须把这些分散的系统对象，重新组织到一次完整业务行为里。
所以，它的基本调查单位不是一条告警，也不是某一个 Span。
而是：
一次业务行为为什么没有得到预期结果。
调查对象开始从系统状态扩展到业务行为形成过程。
调查单位也从服务、接口、请求和 Trace，扩展到一次退款、一次审批、一次发布或者一次自动处置。
这也是 AI 生产调查为什么会成为 AI Runtime 中的一项关键能力。
它依赖的大量关键事实，需要在 AI 运行过程中被保留下来。
任务、上下文、证据和动作产生于运行过程，版本、配置和业务状态则可能来自不同系统。
AI 运行现场要做的，是把这些分散事实围绕同一次业务行为关联起来。
缺少这些事实，事后仅凭告警和日志，很难还原一次行为是怎样形成的。
这就是第 19 篇想讨论的问题。
每一步都正常，为什么还会收到投诉？
先看一个很常见的 Agent 场景。
一家企业让客服 Agent 处理订单退款。
某天，一位客户申请退款。Agent 识别了用户意图。
查询了订单。
检索了退款规则。
调用了业务接口。
最后拒绝了这次申请。
从技术记录看，整个过程很正常。
没有模型错误。
没有接口超时。
没有工具调用失败。
没有权限异常。
工单也被正常关闭。
但第二天，客户投诉了。
人工复核发现，这笔订单属于刚刚生效的一项特殊退款政策，原本应该通过。
问题可能来自很多地方。
Agent 没有检索到新规则。
检索到了，却采用了旧规则。
新规则已经进入知识库，但索引还没有更新。
也可能是 Agent 版本升级以后，选择规则的方式发生了变化。
如果企业只看技术告警，这次问题甚至不会被发现。
如果企业已经开展线上质量评估，就可能发现：
这一类退款任务的通过率突然下降。
或者客户投诉率、人工接管率开始上升。
这已经比没有发现问题好得多。
但企业接下来仍然要问：
到底是哪一个环节改变了这次判断？
这不是一条告警能够回答的问题。
告警记录异常，AI 生产调查还原行为
过去，告警主要围绕系统状态建立。
错误率升高。
接口延迟增加。
CPU 使用率异常。
数据库连接耗尽。
它们把复杂系统里的异常暴露出来，让团队知道哪里值得关注。
这个价值没有变化。
Agent 进入生产以后，企业还要关注行为质量的变化。
任务完成率下降。
事实准确性变差。
人工接管增加。
越界动作增多。
客户反馈恶化。
这些变化，都说明 AI 的行为质量出现了异常，也可以进一步触发告警。
但无论技术指标触发的告警，还是行为质量异常触发的告警，它们首先回答的都是：
什么地方出现了异常？
AI 生产调查要继续回答：
这次异常是怎样形成的？
两者不能混在一起。
告警需要快。
它要及时发现差异，把注意力拉到值得调查的问题上。
可以说，告警负责叫醒团队。
调查需要完整。
它要把任务、行为、证据、版本、环境和业务后果重新组织起来，形成可以核验的解释。
调查负责让团队知道，醒来以后应该查什么。
告警是一条信号。
调查面对的是一次完整的生产问题。
同一条告警，背后可能是完全不同的问题
为什么不能根据告警直接下结论？
因为同一种质量差异，可能由完全不同的原因形成。
还是退款 Agent。
“退款判断准确率下降”这条告警，背后可能是：
知识库没有及时更新。
检索召回了错误版本。
业务接口缺少关键字段。
Prompt 调整改变了规则优先级。
工具返回超时以后，Agent 走了降级路径。
某一类新订单超出了原有评测集的覆盖范围。
表面看，都是准确率下降。
处理方式却完全不同。
更新知识库，解决不了接口字段缺失。
调整 Prompt，解决不了数据同步延迟。
重新评测，也不能代替对线上运行环境的核验。
反过来也一样。
同一个原因，可能同时触发多条告警。
一次知识更新失败，可能造成准确率下降、人工接管增加、任务耗时变长和客户投诉上升。
如果每条告警各自处理，团队看到的是四个问题。
回到同一次 AI 运行现场，才可能发现它们来自同一个变化。
所以，告警数量增加，并不等于解释能力增强。
如果缺少 AI 生产调查，企业很容易得到更多信号，却仍然不知道该改什么。
一次 AI 生产调查，至少要关联哪些事实？
回到一次 AI 运行现场，企业需要围绕同一个生产问题，同时核验四类事实。
第一：行为事实。
任务是什么？
Agent 实际执行了哪些步骤？
调用了哪些工具？
是否发生过重试、降级、中止或者人工接管？
最终改变了什么业务状态？
第二：证据关系。
Agent 当时看到了哪些信息？
哪些信息实际影响了判断？
哪些规则支持这个结果？
是否存在没有被采用的反向证据？
第三：版本与环境。
当时使用了哪个模型、Prompt、知识库和工具版本？
接口、权限、数据同步和运行依赖是否发生变化？
同类成功任务和失败任务之间，差异出现在哪里？
第四：业务后果。
问题影响了哪些客户、订单或者流程？
影响是一条错误回答，还是已经改变了真实业务状态？
是否触发了人工返工、客户投诉或者风险事件？
这些事实原本可能分散在不同系统里。
Agent Trace 里有执行记录。
知识系统里有检索结果。
业务系统里有状态变化。
评估系统里有质量分数。
工单和客服系统里有用户反馈。
AI 生产调查的价值，不是再增加一种日志。
而是围绕同一个生产问题，把这些事实组织成一份可以核验的解释。
AI 生产调查，要围绕一次业务行为展开
很多生产问题之所以越查越乱，不是因为没有数据。
而是因为团队从一开始就把每条告警当成了一个独立问题。
一条任务完成率下降的告警进入 AI 平台。
一次接口超时进入可观测性平台。
一条客户投诉进入工单系统。
一次知识更新失败留在内容平台。
四个系统里，出现了四条记录。
但它们可能属于同一次退款失败。
如果调查围绕告警展开，团队会分别追四条线。
如果调查围绕一次生产问题展开，这些信号才会重新回到同一个 AI 运行现场。
AI 生产调查最大的变化，
不是多了一种分析工具。
而是调查对象和调查单位同时发生了变化。
企业调查的，不应该是某一条告警为什么出现。
而应该是：
一次业务行为为什么没有得到预期结果。
这次业务行为，可以是一次退款。
也可以是一次审批、一次代码发布、一次配置变更，或者一次自动处置。
企业要调查的，是这件事为什么没有按预期完成。
告警、Trace、质量分数、用户反馈和版本变化，
都是这次调查的入口和材料。
它们都不是调查本身。
只有围绕同一次生产问题组织起来，企业才能继续核验：
哪些是现象？
哪些是原因？
哪些变化与这次结果有关？
哪些可能原因已经被事实排除？
这也是 AI 运行现场的价值。
它不是把更多告警堆在一起。
而是让原本分散的信号，重新指向同一次业务行为。
告警关闭，不等于问题已经解决
生产问题还有一个很容易被忽略的环节。
告警消失了，问题是否就结束了？
未必。
指标恢复，可能只是流量下降了。
投诉减少，可能只是人工团队临时接管了。
准确率回升，可能是评估样本发生了变化。
即使团队已经完成修复，也还要继续验证：
同类任务是否恢复正常？
原来的失败是否还会出现？
修复有没有带来新的行为偏差？
真实业务后果是否得到改善？
所以一次完整的生产问题，不能停在“告警已关闭”。
它至少要经过三步：
质量评估发现差异。
AI 生产调查解释差异。
改进验证确认差异是否消失。
这三步连接起来，告警才不只是一次通知。
它开始成为企业持续改进 AI 的入口。
生产问题还要留下什么？
传统事故处理结束以后，企业通常会留下告警记录、工单和复盘报告。
这些仍然需要。
但 AI 生产问题还应该多留下几类可以复用的资产。
这次失败对应的行为事实和业务结果。
支持和反对判断的证据关系。
发生问题时的模型、Prompt、知识、工具和环境版本。
可以复现问题的任务样本。
修复前后的质量差异。
只有这样，线上问题才能继续进入下一轮评测和验证。
否则，团队可能完成了一次复盘，
却没有改变下一次上线前的检查方式。
同一类问题换一个用户表达、换一个工具返回、换一个 Agent 版本，仍然可能再次发生。
运行数据不会自动让 Agent 变得更好。
生产问题也不会因为进入工单就自动成为经验。
它需要经过筛选、核验、归因和验证，
才能从一次异常变成下一次改进的依据。
从 2026 年行业产品的变化看，这个方向已经越来越清楚。
线上评估开始从生产 Trace 中发现异常。
失败的生产任务开始被加入离线数据集。
修复后的版本再通过评测和线上运行验证。
行业正在尝试把“发现问题、解释问题、验证改进”连接成一个闭环。
但对企业来说，重点不在某个产品叫什么。
重点在于：
生产里的问题，能不能沉淀成下一次可以复现、可以核验、可以验证的事实。
从告警，走向 AI 生产调查
过去十几年，可观测性首先解决的是：
让问题被看见。
告警是这项能力里非常重要的一环。
它把异常从海量运行数据里提取出来，让企业及时采取行动。
AI 进入生产以后，告警仍然重要。
但企业不能停在告警。
因为 AI 的很多生产问题，不只是某个系统状态发生异常。
它们涉及一次任务怎样被理解，一条证据怎样影响判断，一个动作怎样改变业务状态，以及最终为什么造成了这样的后果。
这些问题只能回到 AI 运行现场，通过 AI 生产调查得到解释。
过去，可观测性首先让异常可见，让问题可以沿着系统状态和请求链路被定位。
AI 进入生产以后，它的观察边界还要继续扩展。
企业不仅要调查系统哪里出了问题，还要调查一次业务行为为什么没有得到预期结果。
调查对象变了，可观测性的边界也就变了。
所以最后我想说：
告警负责告诉企业，哪里出现了差异。
AI 生产调查负责解释，这次差异是怎样形成的。
改进验证继续确认，同类问题是否还会发生。
生产里的问题，不能只留在告警里。
它必须进入 AI 运行现场，成为一次可以还原、解释和改进的 AI 生产调查。
下一篇，我想继续讨论：
模型没有变，AI 的行为为什么一直在变？
#AI系统 #AI可观测性 #因果AI #AgentOps #AI运行系统
行业参考：Google SRE – Anatomy of an Incident、LangSmith Evaluation、LangSmith Engine。
