可观测性
智能体 AI 的可观测性已超出传统 APM 的范畴。你需要对 LLM 调用、工具调用、推理链路、Token 成本和输出质量保持全面的可视化——而不仅仅是延迟与错误率。
概述
来源：Portkey - The Complete Guide to LLM Observability
智能体可观测性的四大支柱：链路追踪（Traces）（包含 LLM 调用、工具调用、记忆读取的完整执行路径）、指标（Metrics）（用于仪表盘与告警的时间序列聚合数据）、日志（Logs）（用于调试与审计的结构化事件记录），以及评测（Evaluations）（通过 LLM 充当评审、幻觉检测和回归测试实现的自动化质量评分）。
最佳实践
| 核心挑战 | 描述 | 经验教训与备选方案 | 采用的解决方案 |
|---|---|---|---|
| 事后补装可观测性 | 部署后再添加监控代价高且不完整 | 尝试过事后日志抓取，发现会遗漏中间推理步骤 | 从第一天起就使用兼容 OpenTelemetry 的 SDK 对智能体架构进行埋点 |
| 多智能体系统的链路关联 | 请求跨越多个智能体、工具和服务，难以调试 | 尝试过按服务分别记录日志，无法还原完整执行路径 | 在每个智能体和工具调用中传播统一的 trace ID——这是将日志关联成单一执行图的唯一方式；使用分布式链路追踪（Jaeger、Langfuse、Amazon CloudWatch Traces） |
| 多智能体成本归因 | 在多智能体系统中，难以确定哪个智能体消耗了大部分推理成本 | 只跟踪每个工作流的总成本，无法找出需要优化的智能体 | 使用 LangFuse 跨智能体追踪 Token 成本——可显示每个智能体的成本归因，便于做优化决策 |
| 全量链路采集成本 | 在生产规模下全量链路追踪费用高昂 | 评估过始终开启追踪的方案，发现存储与出口流量费用难以承受 | 智能采样——错误请求 100% 采集，成功请求采集 10–20% |
| 链路中的个人信息（PII） | 原样记录用户输入会暴露敏感数据 | 曾考虑不记录输入，但损失了太多调试价值 | 在写入可观测性存储前实施 PII 检测与脱敏 |
| Token 成本可视化 | 成本在多个会话和模型间悄然累积 | 依赖每月账单报告，发现超支时已为时太晚 | 在每条链路中实时追踪 Token 用量；分别在 70% 和 90% 阈值处设置预算告警 |
| 本地编程智能体的链路审查 | 命令行编程智能体通常在本地生成有价值的链路，但这些链路位于托管可观测性栈之外 | 只依赖最终答案或原始 JSONL 日志，遗漏了缓慢的工具调用、重试和 Token 消耗高的会话 | 使用以本地为优先的链路分析工具（如 agenttrace），在变更推广前汇总会话成本、延迟、工具失败情况和健康状态 |
| 幻觉检测 | 难以判断智能体输出何时存在事实错误 | 人工抽检无法规模化 | 对采样输出集成 LLM 充当评审；将幻觉率作为 KPI 追踪 |
| 工具调用失败可视化 | 工具失败会悄然降低智能体质量 | 只检查最终输出质量，遗漏了上游工具错误 | 记录每次工具调用，包括输入、输出、延迟及成功/失败状态 |
| 业务指标关联 | 技术指标无法反映智能体的实际业务价值 | 只追踪 P99 延迟，却未发现任务完成率在持续下滑 | 定义业务 KPI（任务完成率、升级率、解决率）并与技术链路关联分析 |
链路字段参考
追踪可操作事件，而非内部隐藏的推理过程。每次智能体运行应记录以下字段：
| 类别 | 字段 |
|---|---|
| 身份 | run_id、session_id、用户/租户、模型与提供商 |
| 上下文 | 调用时的上下文大小、加载的指令、可见工具列表 |
| 工具活动 | 工具调用、工具参数（已哈希或脱敏）、权限决策、审批请求/结果、工具结果摘要 |
| 错误 | 错误与重试、上下文压缩边界 |
| 成本 | Token 用量（输入/输出/缓存）、费用、延迟 |
| 结果 | 最终状态、停止原因 |
一条链路应能回答以下问题： - 智能体试图做什么？ - 它使用了哪些数据？ - 哪个工具改变了状态？ - 谁批准了该操作？ - 哪里出错了？ - 为什么停止运行？ - 这次运行能够重放吗？
链路评分
每次运行结束后，对特定事件进行评分： - 智能体是否使用了正确的工具？ - 该工具调用是否必要？ - 参数是否有效？ - 在产生副作用前是否检查了权限？ - 审批是否在正确的时机发起？ - 最终答案是否有工具结果作为依据？ - 上下文压缩是否保留了当前活跃的目标？
链路评分是一种反馈机制，能将生产观测转化为智能体运行框架（harness）的改进。
工具生态
| 平台 | 开源 | 成本追踪 | 评测 | 适用场景 |
|---|---|---|---|---|
| Langfuse | ✅ | ✅ | ✅ | 自托管、注重成本的团队 |
| Openlit | ✅ | ✅ | ✅ | 原生 OpenTelemetry 技术栈 |
| LangSmith | ❌ | ✅ | ✅ | LangChain/LangGraph 生态 |
| Galileo | ❌ | ✅ | ✅ | 多智能体可靠性；图/链路/时间线视图；洞察引擎 |
| Braintrust | ❌ | ✅ | ✅ | 基于真实用户数据的回归检测 |
| W&B Weave | ❌ | ✅ | ✅ | 研究型和实验密集型团队 |
| AgentOps | ❌ | ✅ | ✅ | 智能体专项监控与分析 |
| agenttrace | ✅ | ✅ | ✅ | 本地优先的 AI 编程智能体日志与 CI 回归门禁 |
Galileo 智能体可观测性指标框架
摘自 Mastering Multi-Agent Systems（Galileo，2026），这是一套适用于多智能体生产系统的三级追踪体系：
三级追踪体系
| 级别 | 追踪内容 | 核心指标 |
|---|---|---|
| 会话级 | 智能体是否完成了用户目标？ | 行动完成率、行动推进率 |
| 步骤级 | 单个决策是否正确？ | 工具选择质量、上下文遵循度 |
| 系统级 | 跨会话存在哪些规律性模式？ | 错误数、API 延迟、Token 消耗、循环检测 |
生产性能基准
| 指标 | 优秀 | 良好 | 需要改进 |
|---|---|---|---|
| 行动完成率 | > 95% | 85–95% | < 80% |
| 工具选择质量 | > 90% | 85–90% | < 85% |
| 平均响应时间 | < 2s | 2–4s | > 4s |
| 主管路由准确率 | > 95% | 90–95% | < 90% |
行动完成率衡量智能体是否真正完成了任务，而非仅仅应答了请求。一个说"我去查一下账单"的智能体得分低；能够检索账单、找出具体费用条目并给出说明的智能体得分高。
工具选择质量衡量是否以正确参数选用了正确工具。常见的两类失败模式：(1) 工具选择完全错误；(2) 工具选对了但参数错误。
上下文遵循度检查响应是否使用了提供的上下文，而非凭空捏造。
持续改进循环
| 阶段 | 追踪内容 | 重要性 |
|---|---|---|
| 监控 | 智能体选择、工具调用、响应延迟、Token 用量、智能体间通信流 | 建立基线；揭示瓶颈与优化机会 |
| 调试 | 路由错误、工具执行失败、格式错误的 API 响应、切换过程中的上下文丢失 | 通过完整执行链路进行根因分析 |
| 改进 | 提示词工程有效性、检索准确性、智能体响应质量、工具可靠性评分 | 基于数据驱动迭代优化 |
监控例程
- 每日：查看 12 小时视图，捕捉夜间回归问题
- 每周：在迭代规划时回顾周视图，按频率优先排序修复任务
- 每月：验证改进是否切实有效（例如，引入结构化反馈后修订轮次从 4 次降至 2 次）
告警配置
需要配置的关键告警类型： - 行动完成率跌破阈值（例如从 95% 降至 85% 时应立即介入排查） - 工具选择质量低于 85% - 平均响应时间超过 4s - API 失败率高于 0%
闭环处理
应用修复后，持续监控相同指标 24–48 小时。对每次事件做好记录： - 现象：触发了哪个告警 - 根因：排查后发现的问题 - 解决方案：做了哪些变更
这些事件记录将成为故障排查与培训的参考资料。
自定义业务指标
除标准指标外，还应定义能反映具体业务目标的自定义指标。示例：suggested_unlimited_plan——追踪智能体是否在用户数据快用完时正确识别并推荐升级套餐的机会。由 LLM 评审（如 GPT-4o）对每次交互判定为：成功 / 失败 / 无关。
核心指标参考
运营类：请求量、响应延迟（P50/P95/P99）、错误率、资源利用率
AI 专项：Token 消耗与成本、工具调用成功率、上下文窗口利用率、检索相关性评分（RAG）、幻觉检测率
业务类：任务完成率、人工升级率、用户满意度评分、每次交互 ROI
监控健康度：MTTD、MTTR、CFR（Huyen, 2025）
《AI Engineering》（Chip Huyen, O'Reilly, 2025）指出，三个源自 DevOps 的指标能清晰反映你可观测性基础设施的健康状况：
| 指标 | 定义 | 揭示了什么 |
|---|---|---|
| MTTD（Mean Time to Detection，平均检测时间） | 从故障发生到被检测出来的时间 | 你告警与监控覆盖的质量 |
| MTTR（Mean Time to Response，平均响应时间） | 从检测到故障到解决问题的时间 | 你调试工具与运维手册（runbook）的质量 |
| CFR（Change Failure Rate，变更失败率） | 导致需回滚故障的部署占全部部署的百分比 | 你投产前评测流水线的质量 |
关键原则：评测与监控必须紧密耦合。一个在离线评测中表现良好的模型，在生产环境中也应表现良好。如果 CFR 偏高，这是一个信号——说明你的评测流水线没能在部署前捕捉到问题，而不只是监控问题。
监控中发现的问题必须作为新的测试用例回馈给评测流水线，从而闭合质量闭环。
观测 → 行动 → 演进生产循环（Google AgentOps）
在生产环境中管理自主智能体，需要的是持续的运营循环，而非静态监控：
- 观测（Observe）：通过日志、链路追踪和指标实时了解系统行为。这是所有下游环节的感知系统。
- 行动（Act）：拉动实时控制杆，维持性能、安全性与成本。将其理解为系统的自动反射机制——而非战略性改进。
- 演进（Evolve）：利用生产洞察从根本上提升智能体能力。将原始可观测性数据转化为架构、逻辑和行为上的持久改进。
关键区别："行动"是战术层面（熔断器、流量重路由、人在回路（HITL）升级）；"演进"是战略层面（提示词优化、新增工具、通过 CI/CD 流水线部署更新后的护栏）。
演进工作流
生产数据成为改进的驱动引擎： 1. 分析生产日志中的规律——用户行为、任务成功率、安全事件 2. 更新评测数据集——将生产中出现的失败转化为测试用例，持续丰富黄金数据集 3. 优化并部署——提交改进内容（提示词变更、新增工具、护栏更新），触发自动化流水线
这形成了一个良性循环——每次用户交互都是潜在的改进信号。有了成熟的 CI/CD 流水线，从观测到部署改进的周期可以缩短到数小时或数天，而非数周。
通过生产循环演进安全性
安全性不是一次性设置。观测 → 行动 → 演进循环同样直接适用于安全态势的演进： 1. 观测：监控发现新的威胁向量（例如新型提示词注入技术） 2. 行动：通过熔断器 / 功能开关立即禁用受影响的功能进行隔离 3. 演进：将新的攻击手法作为永久测试用例纳入；提示词/AI 工程师优化过滤规则或系统提示词；变更经过完整 CI/CD 流水线，并在扩展后的评测集上验证
每一次生产事件都会让智能体的防御能力更强。
Google Cloud 可观测性技术栈
适用于在 Google Cloud（Vertex AI Agent Engine、ADK）上运行的智能体： - Cloud Trace：每个用户请求获得唯一的 trace ID，将 Agent Engine 调用、模型调用和工具执行关联起来，并显示各环节耗时 - Cloud Logging：记录每次工具调用、错误和决策的详细日志 - Cloud Monitoring：当延迟超过阈值时触发仪表盘告警 - ADK：内置 Cloud Trace 集成，自动对智能体操作进行埋点
AWS 多智能体可观测性技术栈
针对 AWS 上的多智能体系统，需要分层部署可观测性方案：
| 工具 | 职责 |
|---|---|
| Amazon CloudWatch Traces | 跨 Lambda、Amazon Bedrock 智能体调用和 Step Functions 的分布式链路追踪，将完整执行图渲染为单一可导航的链路视图 |
| LangSmith | 专为 LLM 设计的链路追踪——从编排者到各工具调用的层级树状视图；支持按智能体和多智能体维度管理评测数据集 |
| LangFuse | 跨智能体的 Token 成本追踪——显示哪个智能体消耗了大部分推理成本，为优化决策提供强大的成本归因能力 |
多智能体系统的分层评测策略：单智能体评测（隔离数据集）+ 完整工作流评测（Builtin.GoalSuccessRate）+ 将单智能体评分与系统级结果关联的差异化分析。
参见
参考资料
- agents-best-practices — DenisSergeevitch (2025) — 链路字段分类、链路评分问题与诊断框架的来源