Agent 可观测概述4：从数据到判断

这是 Agent 可观测性系列的最后一篇文章。前面三篇我们聊了”为什么难”、“观测什么”、“怎么采集”，这一篇来聊最终极的问题：有了数据，然后呢？

从”能看到”到”能判断”

可观测性的目的，从来不是为了”收集数据”，而是为了做出判断：

  • 这个 Agent 的行为正常吗？
  • 这笔成本花得值吗？
  • 这次任务失败的根因是什么？
  • 这个 Agent 值得信任吗？

如果数据不能转化为判断，那采集再多也只是在堆积”数据债务”。

这篇文章，就来聊聊从数据到判断的几个关键场景。

一、成本归因：钱花到哪儿去了？

LLM 是按 Token 计费的。一个 Agent 跑起来，Token 消耗可能非常惊人。

我见过的真实案例：

  • 一个”智能客服”Agent，一天消耗了价值几千美元的 Token
  • 一个”代码助手”Agent，因为陷入循环，几分钟内吃掉了一个月的预算
  • 多个 Agent 协作的场景，账单来了，不知道哪个 Agent 该背锅

为什么成本归因很难？

表面上看，成本归因很简单：统计每个 Agent 的 Token 消耗不就行了？

实际上远没那么简单：

问题 1：Token 消耗不均匀

一次 LLM 调用的成本 = Input Token × 单价 + Output Token × 单价

但不同调用的 Token 消耗差异巨大：

  • 简单问答：几十个 Token
  • 带上下文的对话：几千个 Token
  • 长文档分析：几万个 Token

只统计”调用次数”是不够的，必须精确到 Token 级别。

问题 2：成本跨越多个环节

一次用户任务的成本可能分布在：

  • 主 Agent 的推理
  • 调用 RAG 检索（Embedding 也要钱）
  • 多 Agent 协作中的中间推理
  • 失败重试

用户只看到”一次任务”，但背后可能是十几次 LLM 调用。

问题 3：无效成本难以识别

最痛的是无效成本——Agent 做了很多事，但最终没有产生有效结果。

比如：

  • Agent 陷入工具调用循环，反复尝试同一个失败的操作
  • Agent 的推理”跑偏了”，花了大量 Token 讨论无关话题
  • Agent 请求了过多的上下文，但只用到其中一小部分

成本归因的落地实践

我在实践中的做法是分阶段计量：

一次任务的 Token 消耗 =
  Input(用户输入)
+ Context(RAG 检索 / 历史对话)
+ Reasoning(推理 / CoT)
+ Tool_Output(工具返回)
+ Response(最终响应)

每个阶段单独计量，好处是：

  • 可问责：如果 Context 阶段 Token 爆炸，说明 RAG 检索策略有问题
  • 可优化：如果 Reasoning 阶段 Token 过高，说明 Prompt 设计需要改进
  • 可预警：设置每个阶段的阈值，超过就告警

一个有用的指标是 Token 效率比：

Token 效率比 = 有效输出 Token / 总消耗 Token

如果这个比值很低，说明 Agent 的”思考”很多，“产出”很少——可能在空转。

二、行为基线与异常检测

安全场景下，另一个核心需求是异常检测：Agent 的行为是否偏离了正常模式？

为什么传统异常检测对 Agent 不太管用？

传统服务的异常检测，通常基于统计指标：

  • 延迟 P99 突然升高 → 异常
  • 错误率超过阈值 → 异常
  • QPS 突然下降 → 异常

但 Agent 的”异常”往往不体现在这些指标上：

  • 一个 Agent 可能延迟正常、没有报错，但做出了错误的决策
  • 一个 Agent 可能执行成功，但访问了不该访问的数据
  • 一个 Agent 可能调用了”合法”的工具，但调用序列暴露了恶意意图

Agent 的异常是语义层面的异常，不是性能层面的异常。

建立行为基线

我的实践是为每个 Agent 建立多维度的行为基线：

维度 1：语义基线

将 Agent 的历史 Prompt 和 Response 通过 Embedding 模型转化为向量，计算向量分布的”正常范围”。

正常状态：Agent 讨论的话题在向量空间中聚集在某个区域
异常信号：新的交互向量突然偏离这个区域

比如，一个”代码助手”Agent 平时讨论的都是技术话题。如果某天它开始频繁谈论”公司财务”、“人员信息”，向量空间中会体现为显著的”语义漂移”。

维度 2：工具调用基线

统计 Agent 的工具调用模式：

  • 常用的工具集合
  • 工具调用的频率分布
  • 工具调用的顺序模式（用马尔可夫链建模）

异常信号包括：

  • 调用了从未用过的工具
  • 调用频率异常（突然高频调用某个工具）
  • 调用序列异常（出现罕见的工具组合）

维度 3：资源消耗基线

统计 Agent 的资源消耗模式：

  • Token 消耗速率
  • API 调用频率
  • 任务完成时间

异常信号包括：

  • Token 消耗突然激增（可能陷入循环）
  • 任务耗时异常延长（可能被攻击或遇到问题）

综合风险评分

多个维度的异常信号需要综合起来。我用的是一个加权评分模型：

Risk Score = α × 语义漂移分数
           + β × 工具调用异常分数
           + γ × 资源消耗异常分数
           + δ × 高危操作权重

其中，高危操作权重 是针对特定危险行为的硬编码规则。比如：

  • 执行 rm -rf → 直接拉高风险分
  • 访问凭据文件 → 直接拉高风险分
  • 向外部发送大量数据 → 直接拉高风险分

基于风险分数，设置分级响应：

  • 低风险（0-30）：记录日志，纳入长期画像
  • 中风险（30-70）：触发人工审核
  • 高风险（70-100）：自动隔离 Agent，触发告警

三、从可观测性到可运营

可观测性的最终目标，不是”看清系统状态”，而是让系统可运营。

什么叫”可运营”？我的理解是：能够基于数据做出决策，并形成闭环。

闭环 1：调试闭环

当 Agent 出问题时，能快速定位根因：

异常告警 → 查看执行链路 → 定位到具体步骤 → 分析推理过程 → 发现 Prompt 问题 → 修改 Prompt → 验证修复

这个闭环需要：

  • 完整的执行链路追踪
  • Prompt 和 Response 的可查询
  • 能够”重放”历史任务

闭环 2：成本闭环

当成本超出预期时，能快速找到原因并优化：

成本告警 → 分解到 Agent/任务/阶段 → 发现 RAG 检索返回过多 → 优化检索策略 → 成本下降

这个闭环需要：

  • 细粒度的成本归因
  • 成本与业务指标的关联（每单位产出的成本）
  • 优化前后的对比分析

闭环 3：安全闭环

当检测到异常时，能快速响应并加固：

异常检测 → 判断风险等级 → 自动/人工处置 → 事后分析 → 更新基线/策略 → 预防同类问题

这个闭环需要：

  • 实时的异常检测能力
  • 自动化的处置手段（隔离、阻断）
  • 基线的动态更新机制

可运营的关键：数据 → 洞察 → 行动

把这三个闭环串起来，可以看到一个共同的模式：

数据采集 → 数据处理 → 洞察生成 → 决策支持 → 行动执行 → 反馈学习

可观测性系统的价值，体现在这个链条的每一环：

  • 数据采集：之前几篇聊的内容
  • 数据处理：关联、聚合、降噪
  • 洞察生成：基线对比、异常检测、归因分析
  • 决策支持：风险评估、优化建议
  • 行动执行：告警、阻断、审批
  • 反馈学习：基线更新、策略优化

只有走通这个闭环，可观测性才能真正”可运营”。

系列总结

写到这里，Agent 可观测性系列就告一段落了。回顾一下四篇文章的核心观点：

第一篇：为什么 Agent 会让”看得见”变难

  • Agent 的执行路径是概率性的，无法预测
  • 传统监控只能回答”做了什么”，无法回答”为什么做”
  • 审计、运行时、网络各自为战，缺乏关联

第二篇：我如何理解 Agent 的关键对象

  • 四类核心对象：Agent、Model Source、Tool、Agent-to-Agent Link
  • 两个观测维度：资产拓扑（静态）+ 执行链路（动态）
  • 三种链路类型：A2L、A2T、A2A

第三篇：采集与还原的现实选择

  • 三种采集范式：SDK 埋点、网络代理、运行时观测
  • 审计与运行时的错位需要关联机制来弥合
  • 可还原性 > 全量采集

第四篇：从数据到判断

  • 成本归因需要分阶段计量和效率分析
  • 异常检测需要多维度行为基线
  • 可观测性的目标是”可运营”，需要闭环

Agent 时代的可观测性，确实比传统微服务时代更复杂。但好消息是，很多基本原理是相通的——只是需要针对 Agent 的特点做适配。

希望这个系列能给正在做 Agent 可观测性的朋友一些启发。如果你有不同的想法或实践经验，欢迎交流。

上一篇：Agent 可观测概述3: 采集与还原的现实选择

评论