智能体上线之后，最贵的不是推理费用，是你说不清它为什么这么干。可观测性解决的就是这件事：把一次运行拆成结构化的步骤时间线，让你能看清发生了什么、按什么顺序、在哪一步跑偏。行业调研里 89% 的团队已经上了某种形式的可观测性，其中 62% 做到了能逐步查看工具调用的细粒度追踪——这已经不是加分项，是入场券。
和传统监控的三点不同
| 维度 | 传统服务监控 | 智能体可观测性 |
|---|---|---|
| 度量单位 | 单次请求 | 整段会话（thread） |
| 关注指标 | 延迟、错误率、可用性 | 目标完成率、升级/转人工频率、轨迹是否合理 |
| 故障定位 | 看堆栈和日志 | 看推理过程、工具调用序列与上下文变化 |
关键区别在第二条：单次请求成功不代表用户目标达成。智能体可能每一步都没报错，但绕了八圈最后没解决问题。所以指标要从”调用成功率”换成”会话级目标完成率”。
一条 trace 里该记什么
- 完整的步骤树：每一次模型调用、每一次工具调用，带父子关系与顺序。
- 每一步的输入输出：包括发给模型的上下文摘要和工具返回的原始内容（注意脱敏）。
- 耗时与 token 数：按步骤统计，才能定位到底是哪一步又慢又贵。
- 会话标识：把多轮交互串成 thread，否则跨轮次的问题根本看不出来。
- 结构化元数据：用户 ID 、会话来源、模型版本、提示词版本号、工具版本号——没有这些，跑回归时无法归因。
一个常被忽略的刚需：把提示词版本号和模型版本号写进 trace 元数据。否则某天指标突然下滑，你连”是不是换了提示词导致的”都无法确认，只能靠猜。
评估：两类方法都要有
- 代码化评估：客观可判定的部分用程序判——路径收敛度、是否调用了预期工具、输出是否符合 schema 、是否包含敏感信息。
- LLM 作为评判者：语气、准确性、是否真正帮到用户这些主观维度，用模型打分才能规模化。
- 多轮评估：一轮跑完整个会话后再打分，看语义意图是否达成、轨迹是否合理，而不是只看单步。
- 在线评估：对生产流量的抽样子集持续打分，作为质量漂移的早期预警。
数据集要主动造边界样本：罕见输入、对抗性提示、长上下文。典型流量永远触发不到这些失败模式，但它们往往是上线事故的主因。
把 trace 变成改进的闭环
- 采集：生产全量 trace 入库，按会话聚合。
- 聚类：用自动分析把失败归成若干类（如”检索到过期文档””陷入循环””工具参数缺失”）。
- 转数据集：把典型失败 trace 一键加入评测集，变成永久回归测试。
- 针对性改进：改提示词、改工具描述、改检索策略——每类失败对应不同动作。
- 回归验证：改进后跑全量评测，确认老问题没复发。
这个闭环的价值在于让每个线上问题都变成一条不可回退的测试用例。做多智能体时尤其重要，可以参考多智能体编排里的责任划分，把 trace 的边界和子智能体的边界对齐；更完整的评测与风险视角见AI 智能体评测与上线后监控；如果还在搭第一个智能体，先看LangChain 入门教程跑通最小闭环再谈观测。
可观测性落地检查清单
- 每一次模型调用与工具调用都有 span，带父子关系
- 输入输出已记录且对敏感字段脱敏
- token 与耗时按步骤可下钻
- 多轮交互按 thread 聚合，支持会话级打分
- trace 元数据含：提示词版本、模型版本、工具版本、来源渠道
- 同时具备代码化评估与 LLM 评判
- 失败 trace 可一键转入回归数据集
- 关键指标有阈值告警（幻觉率、 PII 泄漏、循环次数）
只记日志不够吗，为什么一定要 trace？
日志是平铺的事件流，看不出因果和顺序。智能体的问题常常是”第 3 步检索错了导致第 7 步答错”，只有把步骤组织成带父子关系的时间线，才能定位到具体是哪一步跑偏。
该先看哪些指标？
先看会话级的目标完成率、转人工/升级频率、每会话成本与 P95 时长；再看循环次数异常、工具调用失败率和幻觉/相关性评分。前三个决定用户体验和成本，后几个决定稳定性。
评估该在线做还是离线做？
都要，但顺序通常是先离线。上线前用测试集拦回归，上线后用在线评估盯生产漂移。两者都做的团队约占两成，但一旦智能体面对真实用户，在线评估几乎是必需的。
数据留存和合规怎么处理？
trace 里含用户输入，属于敏感数据。先做字段级脱敏再入库，按业务要求设定留存期（短期调试与长期改进通常是两档），有数据 residency 要求的场景要考虑本地或同区域部署。
评论 (0)