日志、指标与告警

一句话理解：Trace 看“这一次为什么”，指标看“整体怎么样”，日志记“发生过什么事”；看板用来发现趋势，告警只留给需要有人立刻行动的事。

上一课我们读懂了一条 Trace。但客服 Agent 每天要跑几千次，你不可能逐条去读。你需要知道：今天的任务成功率是不是在下降？是所有客户都受影响，还是只有某个租户？单任务成本有没有突然翻倍？某个工具是不是在大面积超时？

很多团队上线 Agent 时只接了模型厂商的用量面板，结果是：账单涨了才发现某个版本陷入了重复调用；用户投诉集中爆发才发现退款查询服务已经挂了两个小时。这一课讲怎么设计 Agent 的指标体系、看板和告警。

三种信号的分工

信号	形态	回答的问题	Agent 场景例子
日志 / 事件	带时间戳的结构化记录	发生过什么？	“用户拒绝了创建工单的审批”
指标	按时间聚合的数字	整体趋势如何？是否异常？	过去 1 小时工具错误率 7%
Trace	带父子关系的操作树	这一次为什么这样？	第 4 步工具返回空导致误判

三者要能互相跳转：看板上发现错误率飙升 → 点进去看是哪个工具 → 抽出几条对应的 Trace → 在 Trace 里看到具体的错误日志。实现上的关键是所有信号都带上同一组维度：trace_id、Agent 版本、Prompt 版本、租户、任务类型。

图 1 画出了三种信号的分工和这条下钻路径：

图 1 · 三种信号的分工：看板发现异常，下钻到 Trace，再落到具体日志事件

日志要写成结构化事件，而不是一句自然语言：

{
  "event": "approval.decided",
  "trace_id": "7f3a…",
  "agent_version": "[email protected]",
  "action": "create_ticket",
  "risk_level": "write",
  "decision": "rejected",
  "wait_seconds": 184,
  "tenant": "tenant_042"
}

这样才能统计“审批拒绝率”“平均审批等待时长”，而不是只能全文搜索。

Agent 的四层指标

指标的定义和离线评测方法在指标体系一课已经讲过，这里关注的是 线上运行时 要持续监控哪些数。建议分四层：

层	指标	说明
业务结果	任务完成率、人工接管率、用户采纳率、负反馈率	老板最关心，但滞后，需要用户行为或抽检才能得到
运行质量	工具错误率（按工具）、验证失败率、护栏拦截率、达到步数上限的比例	最早暴露问题的先行指标
效率	每次运行的步数与工具调用数分布、端到端耗时 P50 / P95、首个输出时间	发现死循环、步数膨胀和慢工具
成本	单任务成本 P50 / P95、每日总花费、缓存命中 Token 占比	发现成本异常和缓存失效

几个设计原则：

看分布，不只看平均。 单任务成本平均 1 元，可能是 90% 的任务 0.5 元、10% 的任务陷入循环花了 5 元。P95 和最大值往往比平均值更有信息量。
按版本切分。 每次发布新 Prompt 或换模型，都要能把新旧版本的指标并排对比。
按任务类型切分。 “查询订单状态”和“多系统售后诊断”的成功率与成本天然不同，混在一起会掩盖问题。

OpenTelemetry 的 GenAI 语义约定也定义了一批标准指标，例如 gen_ai.client.token.usage（Token 用量）、gen_ai.client.operation.duration（模型调用耗时）、gen_ai.execute_tool.duration（工具执行耗时），以及统计单次 Agent 调用中模型调用次数、工具调用次数的 gen_ai.invoke_agent.inference_calls 与 gen_ai.invoke_agent.tool_calls。这些约定仍处于开发状态，但按它们命名能减少后续迁移成本。

一个看板长什么样

下面是客服 Agent 运营看板的线框：

图 2 · 运营看板线框：第一屏只放 8 个核心数字，异常数字都能下钻到 Trace

看板第一屏只放 8 个左右的核心数字，其余下钻。每个异常数字都要能点进去，最终落到具体的 Trace。

告警：只叫醒需要行动的人

告警太多，大家就会静音；告警太少，问题会在用户投诉后才被发现。给每条告警写清楚“触发条件、严重程度、谁处理、怎么处理”：

告警	示例条件（阈值需按业务校准）	级别	动作
越权写操作	出现任何一次未经审批的写入或发送	P0	立即停用相关工具，排查权限
工具大面积失败	某工具错误率连续 10 分钟超过 5%	P1	通知工具负责人，必要时降级为只读
疑似死循环	同一运行中同一工具、同一参数被调用 3 次以上	P1	自动终止运行，记录 Trace
成本异常	近 1 小时单任务成本 P95 超过基线 2 倍	P2	检查是否有新版本发布或缓存失效
完成率下滑	新版本发布后完成率比上一版本低 3 个百分点	P2	评估是否回滚
模型服务异常	限流或服务端错误比例突增	P2	切换备用模型或排队重试

注意第一条：有些事件在正常情况下 应该永远是 0。对这类“不变量”，出现一次就告警，比统计比例更重要。

另一个常被忽略的问题是采样。Trace 数据量大时可以按比例采样，但 所有失败、被拦截、触顶和负反馈的运行必须全量保留，否则最需要排查的恰恰被丢掉了。

把告警规则和采样策略放在一起看（图 3）：

图 3 · 告警路由：不变量出现一次就告警，阈值告警按级别对应处置动作

常见误区

“模型厂商的用量面板就是监控。” 它只能看到 Token 和费用，看不到工具失败、审批、验证和业务结果。
“指标越多越好。” 没有负责人、没有处理动作的指标只会制造噪音。每个看板指标都应该对应一个“如果异常我会做什么”。
“成功率稳定就说明没问题。” 成功率可能被“结果碰巧对、过程有问题”的运行撑着。质量指标（验证失败率、触顶率）要一起看。

产品经理检查清单

业务结果、运行质量、效率、成本四层指标是否都有定义和数据来源？
所有指标能否按 Agent 版本、Prompt 版本、租户、任务类型切分？
看板上的异常数字能否一路下钻到具体 Trace？
哪些事件是“应该永远为 0”的不变量？它们有没有即时告警？
每条告警是否写明了阈值、级别、负责人和处置动作？
采样策略是否保证失败与异常运行被全量保留？

练习

为「订单售后处理 Agent」设计一份监控方案（30–45 分钟）：

按四层各列出 2–3 个指标，写出计算公式和数据来源（Trace、业务系统还是用户反馈）。
画出看板第一屏的文字线框，只允许放 8 个数字。
写 5 条告警规则，至少包含 1 条“不变量”告警和 1 条成本告警，并说明每条由谁处理。

下一步

看板上的“单任务成本”是怎么算出来的？下一课「成本模型」会拆开 Token、工具、重试和人工兜底，教你在上线前估算、上线后核算每个任务花多少钱。

日志、指标与告警