AI Agent 上线后看什么？一张生产运行监控表
把业务结果、执行轨迹、工具调用、人工接管、版本和成本关联起来，让 AI Agent 上线后的异常可发现、可定位、可改进。本文提供生产可观测性的信号设计、排查顺序与运营闭环。
本文目录
AI Agent 的一次运行可以在技术上显示”成功”，业务任务却没有完成。回复草稿需要大幅重写，CRM 字段写错，工具调用反复重试——还有的时候，人工在最后一步接管了流程。
如果监控只记录接口是否报错、调用了多少 Token，这些问题很容易被算进成功请求。团队看到服务在线，却说不清结果为什么变差，也不知道该改模型、知识库、工具，还是流程规则。
生产监控需要把一次运行的业务结果、执行轨迹、人工介入、版本和成本连在一起。技术团队用它排查故障，业务负责人则用它判断：这条工作流是否仍在产生预期结果。
监控告诉你”哪里异常”，轨迹解释”为什么”
传统应用通常用日志记录事件，用指标观察错误率、吞吐和时延。Agent 还多了一条动态执行路径：模型可能先检索资料，再选择工具，因为参数不完整重新规划，最后转给人工。只看最终输出，无法还原中间发生了什么。
Google Cloud 的 Agent 可观测性文档把生产信号分成日志、指标、轨迹以及用于质量评估的提示词和响应数据。日志说明发生了哪些事件，指标反映总体变化，轨迹把一次任务中的模型调用、工具执行和前后依赖串起来。
目前，不同框架记录 Agent 的方式仍有差异。OpenTelemetry 的生成式 AI 语义约定正在尝试统一模型、Token、时延和工具调用等字段。OpenTelemetry 是一套统一记录日志、指标和调用轨迹的开放标准，但相关的生成式 AI 约定仍在持续发展。工程上不必等待所有标准稳定，先统一自己系统中的一次运行标识和关键业务字段更重要。
先给每次运行一张可追踪的”身份证”
这是最基础的一步。
用一个 trace_id（一次任务的唯一追踪标识）贯穿任务进入、检索、模型判断、工具调用、人工确认和最终写入，团队才能从错误结果反查整条执行链。
每次运行至少记录下面几组信息：
| 字段组 | 最低记录内容 | 用途 |
|---|---|---|
| 任务信息 | trace_id、流程名称、任务类型、开始和结束时间 |
聚合同类任务，定位单次运行 |
| 版本组合 | 应用、模型、提示词、知识库、工具和策略版本 | 判断异常是否与变更有关 |
| 执行轨迹 | 每一步状态、耗时、重试、工具选择和参数校验结果 | 找到失败、循环或等待的位置 |
| 业务结果 | 完成、部分完成、转人工、失败，以及实际写入或发送状态 | 区分“生成了内容”和“完成了任务” |
| 复核反馈 | 人工接受、修改、拒绝的结果和原因 | 识别质量问题，积累评测样本 |
| 用量与成本 | 模型请求、Token、工具调用、基础设施和人工修正 | 计算一次合格结果的实际成本 |
版本组合不能只记模型名称。提示词、知识库和工具规则中的任何一项变化，都可能改变行为。站内的AI 工作流变更管理指南讨论了如何把这些内容纳入同一个发布和回滚记录；生产轨迹应能反查当时使用的具体组合。
看板至少覆盖五层信号
看板要回答的是什么问题？
一张只有请求量、平均时延和 Token 的看板，可以说明系统有多忙，却不能证明流程做得好。生产看板应从业务结果向下展开，遇到异常时再钻取到具体轨迹。
| 层级 | 建议观察 | 它回答的问题 |
|---|---|---|
| 业务结果 | 端到端完成率、处理周期、积压、人工接管率 | 工作流是否真的改善了业务 |
| 任务质量 | 字段通过率、引用支持率、人工修改率、严重错误数 | 结果是否达到使用标准 |
| 执行行为 | 步骤数、工具选择、参数失败、循环、回退路径 | Agent 是怎样完成或偏离任务的 |
| 运行效率 | P50/P95 时延（中位数/95 分位）、超时、重试、单次合格结果成本 | 系统能否稳定且经济地运行 |
| 风险控制 | 越权拦截、敏感信息命中、高后果动作审批、异常外发 | 风险有没有在产生后果前被截住 |
这里的“单次合格结果成本”比单纯的模型单价更有用。一个低价模型如果频繁重试，或者留下大量人工修正，最终成本可能更高。计算时应把模型、工具和必要的人工复核放在同一任务口径下，而不是分散在几个部门的报表里。
上线前的AI 工作流验收指标可以直接作为生产基线。看板不必重新发明一套成功标准，但要加入真实环境才会出现的输入变化、工具故障、人工接管和异常成本。
告警要对应动作，不要只制造通知
一条有效的告警，要让人知道该做什么。
并非所有波动都需要叫醒负责人。告警应该同时写明触发条件、处置动作、负责人和恢复标准。
| 信号 | 触发后先做什么 |
|---|---|
| 高后果动作出现严重错误 | 暂停相关自动执行，保留只读或草稿能力 |
| 某个工具失败或超时持续升高 | 切换降级路径，检查接口、权限和参数变化 |
| 人工拒绝或大幅修改突然增加 | 抽样查看轨迹，比较输入分布和最近版本 |
| 单次任务成本明显偏离基线 | 检查循环、长上下文、重复检索和重试策略 |
| 新任务类型集中转人工 | 补充分流规则，决定扩充能力还是明确拒绝 |
阈值应来自流程基线和错误后果。客服回复草稿与付款指令承受的风险不同，不适合共用一套告警数字。对不可逆写入、外发和权限变化，可以结合人工确认点的设计方法，让系统在风险扩大前暂停，而不是等到日报里出现异常。
把真实失败送回评测集
监控发现问题只是起点。
真正能持续改善的系统，会把生产中的失败转成可复现的测试样本。
Anthropic 的 Agent 评测实践把自动评测、生产监控、用户反馈和人工轨迹审查视为互补方法：离线评测适合在发布前检查已知问题，生产监控用于发现真实分布中的新失败，人工复核则帮助理解自动指标没有解释清楚的质量问题。
可以把闭环做成六步：
- 从失败、人工接管、高成本和风险拦截中抽样；
- 判断问题来自输入数据、检索、模型、工具、权限还是流程规则；
- 脱敏并补充期望结果，形成可重复运行的样本；
- 把样本加入回归集，修复时同时检查相邻能力是否退化；
- 通过离线回归后进入影子运行，使用真实输入验证新版本；
- 小范围发布，继续观察相同的业务和风险指标。
不要把所有人工修改都直接当成模型错误。有些修改只是个人表达偏好，有些来自业务规则更新，还有些是输入本身缺少关键信息。进入评测集前需要先确定失败定义，否则样本数量增加了，质量标准却会越来越混乱。
轨迹数据本身也需要治理
记录得越全，泄露风险也越大。
为了方便排查而完整保存提示词、模型响应和工具参数，可能把客户资料、内部文档或系统标识复制到新的观测平台。OpenAI Agents SDK 的追踪文档也提醒，模型和工具的输入输出可能包含敏感数据，并提供了关闭相关内容采集的配置。
因此，记录轨迹前要先确定：
- 哪些字段只保留状态、长度或哈希，不保存原文；
- 哪些内容需要脱敏后才能进入日志；
- 谁可以查看完整轨迹，访问是否留痕；
- 不同风险等级的数据保留多久；
- 调试结束后，临时提高的采集范围怎样恢复。
可观测性不等于把所有上下文永久保存。很多排查只需要版本、步骤、状态、耗时和错误分类；确实需要查看内容时，再通过受控抽样和限时权限完成。
第一版先做到能回答五个问题
不必好高骛远。
刚开始建设生产监控，不必先做一套庞大的平台。只要每次运行有统一标识，版本组合可以追溯，业务结果有明确状态，人工接管有原因分类，并且团队能定期抽查失败轨迹，第一版就已经具备运营价值。
它至少要能回答：任务完成了吗，在哪一步偏离，使用了什么版本，为什么转给人工，这个失败是否已经进入回归测试。
当这些问题能从同一条记录中得到答案，监控才不只是展示系统在线。它开始把生产里的异常变成下一次改进的证据。