概述

Agent 的决策过程是「黑盒」且多步骤的，比传统应用更难调试。可观测性让每次 Agent 运行的内部决策、工具调用、成本耗费都可见；评估体系则回答「Agent 到底做得好不好」。两者共同构成 Agent 中台的运营底座。

1. 为什么 Agent 需要专门的可观测性

传统应用 Agent 应用
逻辑确定，可复现 非确定性，每次可能不同
单层调用栈 多步推理链条
看请求日志即可 需记录「思考了什么、为什么选这个工具」
行为可预期 行为边际不可控

2. 端到端链路追踪（Tracing）

对一次 Agent 运行，关键要能回放完整执行链：

1
2
3
问题 → 意图理解 → Planner → [工具:检索] → [工具:代码执行] → 反思 → 最终输出
  │        │         │          │              │            │        │
  └────────┴─────────┴──────────┴──────────────┴────────────┴────────┴→ 统一 trace_id

核心采集字段：

  • 输入/输出：每次 LLM 调用的 prompt、响应
  • 决策轨迹：Thought / Action / Observation 序列
  • 工具调用：参数、耗时、状态、结果摘要
  • Token 用量：每次调用的输入/输出 token、成本
  • 元数据：模型版本、温度、Agent 版本、租户

3. 决策日志与回放

除了指标，Agent 还需要「可解释的决策留痕」：

  • 记录每一步为何选择该动作（依据的观察与推理）
  • 支持按 trace_id 重放一次运行的完整决策
  • 失败场景自动打标，方便事后分析根因
1
2
3
4
5
6
一次失败的回放示例:
Trace: 用户要求"删除昨天创建的订单"
T1: 意图=订单管理，调用 list_orders(user)
T2: 工具返回空列表 → Agent 误判"无订单"
T3: 实际原因是过滤器写错(created_at 时区问题)
[根因]: 工具参数时区未归一化

4. 成本与性能监控

Agent 的 Token 消耗与延迟会随推理步数放大，必须持续监控：

  • 单次成本：每次调用/每个会话的 Token 与费用
  • 步数分布：成功任务的平均工具步数与延迟
  • 瓶颈定位：找出耗时最高的工具或 LLM 调用
  • 预算告警：超过阈值触发降级（模型分级、限制推理轮次）

5. 评估体系（Evaluation）

评估是持续提升 Agent 质量的关键。分三层：

层级 方法 指标
在线评估 线上真实流量 完成率、用户反馈、转人工率
离线评估 标准测试集 准确率、忠实度、相关性、格式合规
单元评估 单步/单模块 工具选择命中率、检索召回率

评估要点：

  • 构建评测集：覆盖正常/边界/对抗三类用例，聚焦易错场景
  • LLM-as-judge：用更强模型给输出打分，但要校准与抽检
  • 回归测试：每次改动（Prompt/工具/检索）跑回归，防止质量回退
  • 人工抽检：定期抽样人工评审，校准自动评估的偏差

6. 迭代闭环

可观测性与评估要形成优化闭环：

1
2
3
采集(Tracing) → 分析(定位问题) → 评估(量化差距) → 优化(Prompt/工具/检索/记忆)
      ↑                                                     │
      └────────────────── 回归验证 ←────────────────────────┘

常见优化杠杆： Prompt 措辞、工具描述、检索切片、记忆策略、模型选择、推理轮次上限。

7. 落地小结

  1. 全链路溯源：统一个 trace_id，回放每次运行的决策与调用
  2. 留痕决策：「为什么选这个工具」比「调了什么」更有价值
  3. 量化成本：把 Token 与延迟监控当业务指标
  4. 三层评估：在线 + 离线 + 单元，缺一不可
  5. 持续回归：任何改动都跑评测集，防止质量回退
  6. 闭环优化：观测发现的问题要能反哺 Prompt/工具/检索策略
快来参与讨论吧