什么是 Agent 可观测性？
Agent 可观测性关注可记录的执行轨迹、工具调用、Token 消耗和输出质量。本文说明数据维度、埋点、授权采样与落地方法。
直接回答：Agent 可观测性是采集并分析智能体执行数据的实践，涉及模型调用、工具调用、用量、延迟与结果评估。可记录的轨迹不等于模型隐藏思维，覆盖程度取决于埋点、上下文传播与采样；敏感输入输出需先明确授权和保留策略。
为什么 Agent 是可观测性的新难题
传统应用监控看三件事：请求成不成、快不快、资源够不够。Agent 应用这三件全都不够用：
- 决策路径不透明：Agent 自主决定"先查数据库还是先调搜索"，失败时你需要知道它可见的工具选择与执行结果，而非读取模型隐藏思维
- 错误不抛异常：Agent 既可能发生接口错误，也可能在 HTTP 200 时给出错误答案——HTTP 200 掩盖了质量问题
- 成本随行为漂移：同接口不同请求可能差 10 倍 Token，账单异常需要定位到具体会话
- 多组件串联：LLM + 检索 + 工具 + 记忆，任何一环劣化都会污染最终结果
Agent 可观测性的核心数据维度
1. 轨迹（Trace）
以 OpenTelemetry Trace 为骨架，把一次 Agent 执行展开成树：LLM 调用 → 工具调用 → 检索 → 再推理。每个 Span 记录模型名、输入输出摘要、耗时、Token 数。
2. 指标（Metrics）
- Token 消耗（按模型/功能/租户拆分）
- 首 Token 延迟、端到端耗时
- 工具调用成功率、重试率
- 会话完成率、任务成功率
3. 日志与内容（Logs）
默认记录摘要与关联 ID；在授权、采样和保留策略允许时记录脱敏内容，用于质量抽查。日志能还原已记录的步骤，不保证确定性重放。
4. 评估信号（Evaluation）
在线抽样打分（人工或 LLM-as-a-Judge）与离线回归评测结果，作为"质量指标"与性能指标并列展示。
落地三步
第一步：埋点。Agent 框架（LangChain/LlamaIndex/自研）普遍支持 OpenTelemetry 或回调钩子，把 LLM 与工具调用接入 Trace 采集。
第二步：建看板。按业务维度（功能、租户、模型版本）聚合成本与质量指标，异常一目了然。
第三步：闭环告警。Token 突增、工具失败率升高、评估分数下滑都要能触发告警，而不是等用户投诉。
选择一个带工具调用的测试任务，分别记录模型请求与工具执行的 Span，再通过 DataKit OpenTelemetry 接入送入观测云。用同一 Trace ID 核对步骤顺序、耗时和失败位置；会话 ID、模型名及 Token 用量应由应用明确记录，避免把未埋点的执行过程当作已被采集。
常见问题（FAQ）
Q：Agent 可观测和 LLM 可观测有什么区别？
A：LLM 可观测聚焦单次模型调用（Prompt、Token、输出质量）；Agent 可观测范围更大，还要覆盖多步推理轨迹、工具调用链、会话级任务成功率。单调用场景两者基本等同，真正的 Agent 系统需要后者。
Q：记录完整 Prompt 会不会有隐私合规问题？
A：会，因此完整记录不是默认要求。先判断是否有必要与合法授权，再在采集前脱敏、最小化采样并限制访问与留存；仅靠正则遮蔽无法覆盖所有敏感内容。
Q：没有专业工具能先手工做起来吗？
A：可以：把 LLM 调用的模型、Token 数、耗时、错误与关联 ID 结构化写入日志，就是最小可用的 Agent 可观测。后续接平台只是把这份日志升级为 Trace + 指标。
参考资料
资料核对日期：2026 年 9 月 29 日。本文基于公开文档整理，代码片段和评估方案未作独立运行或性能验证；厂商测试结果已注明来源。
