引言
把一个智能体（Agent）从演示环境推到生产环境，只是工作的开始。传统微服务的可观测性三板斧——日志、指标、链路追踪——在 Agent 场景下依然必要，但远远不够。Agent 的行为是非确定性的：同样的输入可能产生不同的推理路径；它会自主调用工具、拆解任务、多轮迭代；它的"故障"往往不是抛出异常，而是安静地给出错误答案——一次调用返回 200，链路没有任何报错，但结果完全不可用。
这意味着面向 Agent 的可观测性体系，必须在传统 APM 的基础上多回答几个问题：它为什么这么决策？每一步推理质量如何？输出是否符合预期？成本是否失控？本文从日志与链路追踪的差异讲起，再到在线评估指标和线上护栏，给出一套可落地的框架。
Agent Trace 与传统 APM 追踪的差异
传统 APM（如 Jaeger、Zipkin 的分布式追踪）追踪的是确定性的服务调用链：一个 HTTP 请求进来，经过网关、服务 A、服务 B、数据库，每个 Span 记录的是延迟、状态码、调用关系。Span 的语义是"哪个函数/服务被调用了，花了多久"。
Agent Trace 追踪的是一条认知决策链。一次用户请求在 Agent 内部展开的 Trace，典型结构是：
Run (一次完整会话/任务)
└─ LLM Call (规划: 决定下一步动作)
└─ Tool Call (检索知识库)
└─ LLM Call (分析检索结果)
└─ Tool Call (调用业务 API)
└─ LLM Call (生成最终回复)
两者的核心差异体现在四个方面：
1. Span 的语义不同。 Agent Trace 的关键 Span 类型是 LLM 调用、工具调用、检索、子 Agent 委派，而不是 RPC 和 SQL。每个 LLM Span 需要记录完整上下文：模型名、prompt（或消息序列）、生成参数、token 用量、成本、输出原文。这些数据量远超传统 Span 的属性，通常需要把 payload 放在对象存储里，Span 只存引用。
2. 结构是动态的。 传统调用链拓扑相对固定，可以提前画出架构图；Agent 的 Trace 结构在运行时由模型决策决定——一次请求可能是 3 步，也可能是 30 步，还可能包含循环和自我修正。追踪系统必须支持任意深度和分支的树形结构，并能展示"为什么走了这条路"。
3. "成功"无法由状态码判断。 HTTP 200 + 无异常 ≠ 任务成功。Agent Trace 需要挂载质量信号：这一步的输出是否被后续步骤采纳？工具返回是否为空？最终答案是否回答了用户问题？这些信号来自评估器而非框架本身。
4. 需要会话级关联。 Agent 往往是多轮对话，单条 Trace 之外还需要 Session 维度：把整个会话的多条 Run 串起来，才能分析"第几轮开始跑题""上下文膨胀曲线"这类问题。
工程实践上，OpenTelemetry 的 GenAI 语义约定（gen_ai.* 属性）已经成为事实标准，Langfuse、LangSmith、Phoenix、Braintrust 等工具都围绕这套模型构建。建议直接用 OTel SDK 埋点，避免被单一平台锁定。
日志：从"事件记录"到"决策快照"
Agent 场景的日志要解决的核心问题是可回放。当线上出现一次坏回答，你需要能完整重建当时的决策现场：输入是什么、检索到了什么文档、模型在第几步选择了哪个工具、中间推理（如果有）是什么。
几条实践原则：
- 全量记录 LLM 输入输出，但做好脱敏。PII、密钥在进入日志管道前必须过滤，prompt 里经常携带用户数据，这是合规红线。
- 结构化优先于文本。每条日志带 trace_id、span_id、session_id、user_id、模型版本、prompt 模板版本，否则事后无法做聚合分析。
- 记录配置快照。线上行为是"代码 + 模型版本 + prompt 版本 + 温度等参数 + 可用工具列表"的函数，任何一项变化都会改变行为。日志里缺了配置快照，回放就没有意义。
- 控制采样成本。LLM payload 很大，高流量场景下全量落盘不现实。常见做法是元数据全量、payload 按比例采样，但对低分评估结果和告警触发的样本强制全量保留。
在线评估：指标分层
离线评估（benchmark、golden dataset）回答的是"这个版本能不能上线"，在线评估回答的是"上线后表现是否如预期"。在线指标建议分四层：
第一层：系统指标（传统 APM 沿用）。 延迟（P50/P95/P99，注意 Agent 任务延迟天然是长尾，P99 可能是 P50 的几十倍）、错误率、吞吐量、可用性。这一层不可或缺但最不特殊。
第二层：成本与效率指标。 每次任务的 token 消耗、工具调用次数、LLM 调用轮数、单任务成本。Agent 的一个典型线上事故是"循环失控"——模型反复调用工具不收敛，成本爆炸。监控轮数分布比监控均值有效得多。
第三层：质量指标（Agent 特有）。
- 任务完成率：由规则或 LLM-as-judge 判定最终输出是否完成了用户意图。
- 工具调用正确率：工具选择是否正确、参数是否合法、失败后是否做了合理重试或降级。
- 幻觉/忠实度：RAG 场景下答案是否被检索内容支撑（faithfulness）。
- 相关性：输出与用户问题的相关程度。
第三层指标大多依赖 LLM-as-judge：用一个独立评审模型对线上流量（通常采样 1%–10%）打分。要注意评审模型本身会漂移，需要定期用人工标注校准 judge 的准确率。
第四层：业务指标。 用户采纳率（回答是否被复制/点赞/追问）、人工接管率、会话完成率。这是质量指标的兜底——judge 再准也不如用户行为真实。
告警与线上护栏
Agent 的告警设计和传统服务有一个关键区别：不能只告警"硬故障"，必须告警"质量漂移"。
硬故障告警与传统一致：错误率突增、延迟分位数越界、依赖的模型 API 大面积超时。
质量告警基于第三层指标：任务完成率滑动窗口跌破阈值、幻觉率上升、judge 分数分布发生显著偏移。这类告警的难点是噪声——建议用足够长的窗口（如 1 小时以上）和统计检验（如 PSI 分布漂移检测）代替简单的阈值判断，避免被正常流量波动骚扰。
成本护栏是 Agent 特有的刚需：
- 单任务硬上限：LLM 轮数、token 总量、工具调用次数超过上限即强制中断并降级（返回兜底话术或转人工）。
- 预算熔断：小时级/天级成本超过预算时，自动切换到更便宜的模型或降低采样评估比例，而不是让账单失控。
- 循环检测：相同的工具调用以相同参数连续出现 N 次，判定为死循环并终止。
安全护栏在观测链路中也要有位置：prompt 注入检测、输出内容合规过滤、工具调用的权限校验（Agent 不应因为被诱导而执行越权操作）。这些拦截事件本身就是重要的可观测信号，要进入统一的 Trace 和告警管道，而不是散落在安全网关的日志里。
最后强调一个组织层面的实践：评估样本回流。线上被 judge 打低分、被用户点踩、触发护栏的样本，应当自动汇入离线评估集，成为下一次版本迭代的回归用例。观测体系的终点不是仪表盘，而是让系统持续变好的数据飞轮。
总结
Agent 上线后的可观测性，核心是把传统 APM 的"确定性调用链"思维，升级为对"非确定性决策链"的观测：Trace 要记录认知过程而不只是服务调用，日志要支持决策回放而不只是事件排查，指标要从延迟和错误率扩展到质量与成本，告警要覆盖质量漂移而不只是硬故障，护栏要在循环失控和成本爆炸发生前就拦住。
落地路径可以是渐进的：先用 OTel GenAI 语义约定打通 Trace 和日志，跑通"坏 case 可回放"这一条链路；再引入 LLM-as-judge 建立质量基线；最后补齐成本护栏和样本回流。可观测性不是一次性的建设工程，而是 Agent 系统持续进化的基础设施——看不见的系统，谈不上可控，更谈不上可靠。