Agent上线后怎么观测？三仪表盘监控成功率/接管率/成本

Agent 通过上线验收后，问题不会自动消失。到了第二周，上游接口可能开始超时，知识库已经换过版本，模型路由也许发生了切换，用户输入则从演示样例变成了缺字段的真实资料。回答看起来还算顺，后台的人工补录、重试和工具调用却可能一起增加。

只统计“有没有生成回答”，这些变化很容易被漏掉。上线后的记录至少要回答三件事：任务有没有完成，为什么转给了人，这次执行花掉了多少时间和资源。本文不绑定某个平台；字段和阈值仍要按任务风险、样本量和日志能力调整。

一、先把观测目标写成决策问题

先别急着画图。每个指标都应对应一个决定：谁看它，看到什么变化后要做什么。

以内部工单摘要 Agent 为例，可以先把决定写出来：关键字段遗漏、人工大改或转人工连续升高，就停止自动进入下游；工具错误集中在某个版本后，先回滚工具；单任务成本突然上升，先查重试和上下文长度，再考虑换模型。

二、三个仪表盘分别看什么

1. 任务结果仪表盘：不要只看“有输出”

先把任务终态定下来，而且状态要互斥。否则成功率的分母从一开始就不稳定。

completed：输出符合任务约定，进入规定的后续步骤。
completed_with_review：输出生成，但必须由人确认或修改后使用。
handed_off：Agent 主动停止并把任务交给人。
failed：未得到可用结果，或运行中断。
blocked：因权限、审批、风险规则或输入条件被阻止。
cancelled：用户或系统主动取消。

“completed”和“completed_with_review”要分开统计。前者表示当前范围内可以自动完成，后者表示结果仍有用，但必须经过人工。handed_off 也不一定是坏结果；资料不足时及时交给人，通常比硬编一个答案更好。

至少按任务类型、版本、数据来源和风险级别拆开看。把所有任务压成一个总成功率，高风险写入和低风险摘要之间的差异就会被抹平。

2. 人工接管仪表盘：量化“人到底补了多少”

人工接管率可以先这样算：

人工接管率 = 需要人介入的任务数 / 已开始任务数

“介入”这个词太宽，报表里要继续拆分。至少区分四类事件：

只记录“接管/未接管”还不够。修改程度可以用 none、minor、major、unusable 四档，没必要把每次编辑硬换算成百分比。评审人还要看到原输出、修改结果和修改原因，才能分清是模型、输入还是业务标准出了问题。

3. 资源仪表盘：把成本、延迟和重试放在一起

单独看每任务成本，通常看不出原因。成本升高可能来自更长的输入、重试循环、检索异常或模型路由变化。下面几项最好放在同一张表里：

端到端耗时：从任务接收至完成或转人工。
分段耗时：检索、模型、工具、审批等待分别记录。
调用次数：模型、搜索、数据库和外部写入各自计数。
重试次数：区分系统重试、工具重试和人工重新提交。
资源用量：令牌、请求、媒体生成额度或计算时间。
估算成本：按实际账单规则或内部计价公式计算，并标记版本。

平均耗时不够。少数长尾任务就可能让用户放弃，所以还要看分位数和超时列表。成本如果是估算值，同时记录价目表版本和估算方法，避免把不同时间的数据硬放在一起比较。

三、先定义一条任务的事件链

没有统一事件链，后面的指标只能靠手工拼。可以先采用下面这套与供应商无关的最小结构：

task_received
  -> context_prepared
  -> tool_called / tool_returned
  -> model_called / model_returned
  -> approval_requested / approval_resolved
  -> result_produced
  -> result_reviewed
  -> task_completed | task_handed_off | task_failed | task_blocked

每条事件至少包含下面字段：

{
  "event_id": "evt-...",
  "task_id": "task-...",
  "run_id": "run-...",
  "occurred_at": "2026-08-13T09:20:00+08:00",
  "event_type": "tool_called",
  "agent_version": "git:ab12cd3",
  "model_route": "reasoning-default",
  "tool_name": "internal-search",
  "attempt": 1,
  "risk_class": "read_only",
  "outcome": "started"
}

task_id 表示用户的一次业务请求，run_id 表示一次实际执行，二者不能混用。同一个任务被重试或恢复时应产生新的 run_id，否则会把反复失败的尝试错误地算成一次顺利完成。

日志中不要直接存储完整客户资料、密钥或未脱敏的模型上下文。可保存引用 ID、长度、哈希、权限标签、错误类别和经过审批的摘要；原始内容按既有数据政策处理。观测系统本身不应成为新的敏感信息仓库。

四、让每个指标都有口径卡

指标多不代表口径清楚。更常见的情况是，大家都在用同一个词，却各算各的。为每个指标建立一张口径卡：

分母不能随心情变化。如果因为数据缺失把失败任务从分母里排除，趋势会显得更好，却失去了发现系统问题的能力。正确做法是单独统计“终态缺失率”，并把它作为日志质量问题处理。

五、从日报到告警：先做小，后做自动化

刚上线时没必要先做一套复杂平台。用任务表或事件仓库生成一张日表，已经足够开始观察：

日期：
任务类型：
开始任务数：
自动完成：
人工确认后完成：
主动转人工：
失败：
阻止：
人工重大修改：
超时任务：
重试异常：
单任务资源用量异常：
版本与已知变更：
待调查项：

告警也不要直接对单次失败报警。更可行动的触发器是“同一任务类型在固定窗口内的异常变化”，并附带可定位的样本。例如：某工具错误在新版本后集中出现；人工重大修改连续高于自身基线；同一任务的重复调用突然增加。具体阈值必须由风险、样本量和历史基线决定，不能照搬别人的数字。

六、一次异常如何沿着三个仪表盘排查

假设团队看到“自动完成率下降”，可以按下面顺序查：

1. 确认分母是否变化：是否接入了新任务类型，是否有终态事件缺失。
2. 按版本和任务类型切分：变化是否从某次发布或某一种输入开始。
3. 查看人工接管原因：是资料不足、事实纠错、权限审批还是系统救援。
4. 查看资源链路：是否出现工具超时、重试增加、上下文膨胀或路由变化。
5. 抽取可复现任务：固定输入、版本和权限重跑，不用生产数据上的偶然结果下结论。
6. 将确认的失败写入回归任务集，再决定修复、回滚或缩小范围。

最后一定要回到具体运行记录：版本、输入和证据都要能对上。没有样本链接的红色曲线，无法指导修复。

七、避免四个常见误读

把回复生成率当成功率。 系统发出一段文字不代表任务完成，也不能代表没有越权。

把人工确认都算失败。 对合同、支付、对外发送等高风险动作，人工确认是正确控制点；应该关注确认前信息是否充分、是否总在同一处卡住。

用平均值掩盖长尾。 少数超时和高成本任务会伤害实际工作流，应保留可逐条查看的异常队列。

只记录模型，不记录环境。 Prompt、Skill、知识快照、工具版本、权限和路由都可能造成行为变化。缺少这些字段，就无法做可信比较。

八、上线后第一周检查清单

[ ] 已定义任务的开始、终态和取消状态。
[ ] task_id 与 run_id 可以区分重试和恢复。
[ ] 已记录 Agent、模型、Prompt、工具、知识和权限版本。
[ ] 自动完成、人工接管、失败和阻止没有混为一个成功率。
[ ] 人工接管包含原因与修改程度，而不是只有一个布尔值。
[ ] 耗时、调用、重试和资源用量可回到同一 run_id。
[ ] 敏感输入没有直接复制到运行分析系统。
[ ] 异常指标能够链接到最小可复现样本。
[ ] 每日或每周有人负责解释趋势和处理数据质量缺口。
[ ] 监控结论会进入回归任务集与发布记录。

结论与资料

Agent 的可观测性要帮助团队发现质量、人工负担、成本或安全边界的变化，并回到具体任务复现和修复。任务结果、人工接管和资源消耗要一起看，不能让一条漂亮但单薄的指标替团队下结论。

• OpenAI：Agents SDK tracing：参考 Agent 执行过程中的 trace、span 与敏感数据处理说明。
• OpenTelemetry：Semantic Conventions：参考跨服务事件和属性的一致记录思路；字段应按本系统的风险与数据政策裁剪。
• Anthropic：Demystifying evals for AI agents：参考以任务、轨迹和结果共同评估 Agent 的方法。