AI Agent 可观测性：追踪、指标与审查实用指南

AI Agent 可观测性是指重建 Agent 尝试了什么、使用了哪些工具和数据、每一步返回了什么、整次运行花费多少，以及最终结果是否可接受的能力。只显示延迟和错误的仪表板远远不够。Agent 的行为具有可变性，因此团队还需要追踪记录、评估、业务结果，以及针对敏感内容的审查路径。

研究与披露: 本指南参考了 OpenTelemetry 的 Agent 可观测性工作、OpenTelemetry 语义约定和 NIST AI 风险管理框架，资料复核日期为 2026 年 9 月 4 日。下文的运行模型为原创编辑框架，并非 Ottermind 性能基准。

Agent 可观测性必须回答什么

一套有用的系统应该能够回答以下六个问题，而不需要工程师从互不关联的日志中重建整次运行：

1. 哪个目标、指令、模型和输入启动了这次运行？
2. 运行中发生了哪些模型调用、检索、工具调用和审批？
3. 每一步接收并返回了什么？
4. 运行在哪些位置重试、停滞、分支或失败？
5. 结果是否达到了该任务特有的质量阈值？
6. 审查者能否在不暴露受限数据的前提下复核证据？

传统应用监控依然重要。可用性、延迟和错误率可以说明服务是否正常运行。Agent 可观测性则补充任务层面的上下文，用来判断服务是否完成了正确的工作。

四层可观测性模型

不要把这些层级压缩为一个分数。一次快速运行可能生成糟糕的报告；一份证据充分的报告可能来得太迟；一项已被接受的交付物也可能暴露本不应该进入追踪记录的数据。

最小事件模式

先建立一份每个 Agent 和工具都能发送的小型事件契约：

{
  "run_id": "run_123",
  "step_id": "step_07",
  "parent_step_id": "step_03",
  "operation": "tool.call",
  "tool": "document_search",
  "started_at": "2026-09-04T09:00:00Z",
  "duration_ms": 842,
  "status": "ok",
  "input_classification": "confidential",
  "content_recorded": false,
  "tokens": 0,
  "cost_usd": 0,
  "evaluation_refs": ["eval_19"]
}

稳定的运行标识符和父级标识符使整个序列可以重建。记录提示词、模型、工具和政策的版本，以便把回归问题关联到具体变更。原始提示词和输出应保持可选：元数据通常足以支持运行分析，而捕获完整内容会带来隐私与保留义务。

区分四种标识符

• workflow_id 表示长期存在的产品流程或业务流程。
• workflow_version 表示经过测试的提示词、工具、模型和规则配置。
• run_id 连接单次执行中的每一个步骤。
• thread_id 连接一次对话或长期任务中相互关联的多次运行。

不要重复使用用户 ID 作为线程 ID 或运行 ID。把身份信息保存在单独受控的字段中；如果分析不需要直接识别个人，就使用假名化引用。只有政策允许时，才附加交付物或业务记录 ID。

同时添加部署、环境、实验和来源集版本。这些维度可以回答故障是否从某次发布后开始、是否只影响特定群体，或者是否依赖过期的知识集合。

揭示 Agent 行为的指标

在增加几十张图表之前，先跟踪一组精简指标：

• 按任务类型划分的完成率和放弃率；
• 整次运行及每个工具的中位延迟和尾部延迟；
• 工具失败率、重试率和回退率；
• 每个已接受结果的步骤数、token 数和成本；
• 对证据敏感的工作所需的依据充分性或引用覆盖率；
• 人工修正时间和拒绝原因；
• 政策阻止、审批请求和权限拒绝情况。

按工作流版本和代表性任务细分指标。汇总平均值可能掩盖某种文档类型或某个工具集成反复失败的问题。

从目标到结果追踪一次运行

假设某个研究 Agent 被要求根据十个已批准来源制作竞品简报，但最终文档中的一个竞品价格有误。一条有用的追踪记录应该让审查者沿运行过程向后定位：

1. 结果记录显示简报被拒绝，并把问题标记为价格错误。
2. 最终综合 span 指出是哪一条已提取的价格记录生成了该句子。
3. 检索 span 显示，一篇归档帮助文章的排序高于当前价格页面。
4. 来源元数据显示没有生效日期字段，也不存在优先选择当前官方页面的规则。
5. 工作流版本显示，近期一次检索变更移除了日期筛选器。

修正措施不应该只是“换一个更好的模型”。团队应恢复来源优先级规则，把被拒绝的运行加入评估集，测试其他时效性强的声明，并监控归档页面的检索情况。当可观测性能够把可见缺陷连接到可测试的变更时，它才真正产生价值。

如果没有相互关联的追踪记录，团队可能只修改那个价格、重新运行任务或调整提示词，却无法知道底层检索故障是否依然存在。

围绕决策设计 span

如果每个辅助函数都是一个 span，追踪记录会变得无法阅读；如果整次运行只有一个 span，记录又会不完整。应对有意义的工作单元进行检测：

• 目标接收和政策分类；
• 计划创建或路线选择；
• 每一次模型调用；
• 每一次检索查询及返回的来源集；
• 每一次外部工具调用和结果；
• 状态或记忆的读取与写入；
• 重试、回退和停止决策；
• 人工审批请求和响应；
• 交付物创建与验证；
• 最终交付和用户结果。

对嵌套工作使用父子关系；对于具有共同原因但不属于直接调用栈的异步任务，则使用链接。为每个 span 设置稳定的操作名称。把工具名称、工作流版本和文档分类等变量值放入属性，以便筛选，同时避免生成成千上万个指标名称。

记录足够的上下文，而不是隐藏推理

目标是捕获可观察的输入、输出、决策和状态转换。不要依赖私有思维链或冗长的内部推理。类似 selected_tool=document_search 的路由字段，加上允许的替代方案和工具结果，比不受限制的推理文本更有用，也更容易治理。

对于失败的决策，记录本应约束它的政策或评估器、当时可用的证据，以及最终采取的动作。这样既能支持调试，也不会把每条追踪记录都变成敏感叙事。

从真实失败模式建立评估

流畅度和有用性等通用指标通常并不足够。应根据工作流契约定义评估维度。

对于研究简报，可以使用以下维度：

使用三个评估阶段：

1. **发布前回归：**工作流版本上线前运行固定案例。
2. **生产抽样：**对一定比例的真实运行进行自动或人工审查。
3. **失败升级：**把被拒绝、被修正或异常的运行转为带标签的回归案例。

对评估提示词、评分模型、量表和数据集进行版本控制。评判器变更后，不要把新分数与旧基线直接比较，好像测量方式从未改变。

为工作流定义服务目标

应用正常运行并不能说明 Agent 是否完成了有用的工作。应加入任务层面的服务指标：

• 符合条件的运行中生成交付物的比例；
• 无需重大修正即可接受的比例；
• 从请求到生成可审查结果所需的时间；
• 正确升级给对应负责人的比例；
• 每个已接受结果的最高成本；
• 来源型工作所需的引用或证据覆盖率；
• 符合政策的完成率。

按工作流类型建立目标。五分钟的研究备忘录和十秒钟的客服回答不应该使用同一个延迟目标。只有依据成文规则才能排除无效输入，否则团队可能通过重新分类困难故障来美化可靠性。

针对可操作的症状发出警报

不要因为每一个较低的评估分数就通知值班人员。警报应该对应明确、有限的运行响应。

用仪表板观察趋势，用工单跟踪缺陷，用紧急通知处理严重事故。如果每次评估波动都会唤醒操作人员，警报疲劳就会掩盖真正需要介入的事件。

选择抽样策略

为每次运行捕获完整元数据的成本可能足够低，但完整保留内容并执行模型评估通常并非如此。可以组合以下抽样规则：

• 随机抽样估计日常质量，避免只选取戏剧性的失败；
• 风险抽样提高对后果性工作流的审查比例；
• 事件抽样保留错误、政策阻止、高成本循环和用户拒绝；
• 变更抽样在模型、提示词、检索或工具发布后提高覆盖率；
• 细分抽样确保少数语言、文档类型、用户角色和边缘案例得到覆盖；
• 追踪一致抽样保留完整多步骤运行，而非彼此断开的 span。

记录分母。如果仪表板只根据成功完成的运行显示 95% 通过率，那么被放弃和被阻止的工作已经从测量中消失。

检查样本是否存在盲点。只保留缓慢或失败运行的规则无法估计日常质量，而纯随机抽样可能错过罕见的高影响事件。已确认事故应按照相关记录政策独立于常规抽样保留。

将遥测与用户反馈对齐

把明确的拒绝、修正、重试、升级、支持工单和交付物接受信号连接到对应运行。不要因为用户结束对话就推断其满意，他们也可能只是放弃了任务。

建立结构化反馈原因，例如来源错误、遗漏要求、信息过期、不安全操作、格式不佳、速度太慢或成本太高。可以保留可选自由文本作为上下文，但不要让每次分析都依赖人工阅读。

当反馈与自动评估器冲突时，应检查具体案例。可能是用户有误，可能是评估器定义不佳，也可能是工作流优化了不符合真实结果的技术量表。这些分歧都是宝贵的评估案例。

执行 Agent 事故复盘

事故复盘应该不追责且可追溯：

用户影响和受影响的运行：
检测时间和信号：
工作流、提示词、模型、工具和政策版本：
预期行为：
观察到的序列：
涉及的来源、状态或权限：
现有评估未发现问题的原因：
即时遏制措施：
纠正变更及负责人：
新增回归案例：
监控变更：
后续复核日期：

区分触发错误与系统性促成因素。模型可能生成无效参数，但工具契约也可能接受它，重试循环可能反复执行它，而评估又可能忽略工具结果。只修复最先看到的故障会让系统继续保持脆弱。

分四个阶段上线可观测性

阶段 1：重建单次运行

对一个范围明确的工作流进行端到端检测。确认工程师和领域审查者都能独立根据追踪记录解释一次失败运行。

阶段 2：连接质量结果

附加确定性验证、审查者标签以及接受或拒绝结果。根据观察到的失败建立小型回归集。

阶段 3：在生产规模下运行

定义抽样、保留、脱敏、仪表板和可操作警报。测量遥测成本，并确认追踪过程不会暴露受限数据。

阶段 4：系统性改进

使用失败聚类确定变更优先级，在固定数据集上比较版本，并在生产环境确认效果。审查过期指标，移除不再影响决策的遥测数据。

每周审查模板

工作流和版本：
预期用户结果：
具有代表性的成功运行：
具有代表性的失败或已修正运行：
主要失败模式：
自上次审查以来的变更：
延迟和成本变化：
评估变化：
隐私或权限事件：
下周的一项实验：
负责人和审查日期：

不要只看平均值，还要抽样失败案例。至少审查一次正常运行、一次高成本运行、一个被拒绝结果，以及一次需要人工介入的运行。这组样本能够揭示全绿状态面板遗漏的行为。

隐私与安全边界

可观测性数据可能包含提示词、文件名、检索段落、工具参数、凭据、个人数据和业务决策。应像处理生产数据一样对其分类。在导出前对秘密信息脱敏，把内容与元数据分离，限制访问，定义保留期限，并记录谁查看过敏感追踪内容。

至少建立三种捕获模式。仅元数据模式记录时间、状态、版本、分类和哈希值；脱敏模式在自动过滤后保留有限内容；受限诊断模式在短时间内捕获已批准内容，并只允许指定人员访问。应由工作流根据数据分类选择模式，而不是由单个开发者决定。

在遥测离开进程之前测试脱敏。后端设置无法保护已经传输的秘密信息。还要检查派生数据：即使主提示词被删除，文档标题、工具参数、嵌入、错误消息和评估解释仍可能泄露敏感内容。

成熟度检查清单

[ ] 每次生产运行都有稳定的工作流和版本标识符。
[ ] 模型、检索、工具、状态、审批和交付物步骤相互连接。
[ ] 敏感内容捕获遵循成文分类规则。
[ ] 已接受、已修正、已拒绝和已放弃结果与追踪记录关联。
[ ] 评估反映任务契约并进行版本控制。
[ ] 失败的生产运行可以转为回归数据集。
[ ] 警报具有负责人和明确的第一响应。
[ ] 保留、访问、导出和删除均经过测试。
[ ] 成本包括遥测存储和评估，而不只是模型 token。
[ ] 领域审查者无需工程师协助即可重建结果。

如需更完整的威胁模型，请使用 AI Agent 安全清单。如需了解组件边界和编排契约，请参阅 AI Agent 架构指南。

常见问题

AI Agent 监控与可观测性有什么区别？

监控报告故障、延迟和成本等已知信号。可观测性提供足够且相互关联的证据，用来调查没有预料到的行为，包括工具选择、重试、上下文、评估和人工修正。

是否应该存储每个提示词和响应？

不应该。只存储满足运行和审计目的所需的最少数据。尽可能优先使用元数据和哈希值，对秘密信息脱敏，根据任务分类限制内容捕获，并设置保留期限。

新团队应该从哪个指标开始？

从一个范围明确的工作流入手，测量已接受完成率和修正时间，再围绕该结果增加成本、延迟和失败模式指标。

可观测性可以替代离线评估吗？

不能。离线评估在发布前测试已知案例；生产可观测性则显示真实输入、工具和用户在发布后的表现。可靠的团队会同时使用两者。

应该抽样多少生产流量？

不存在通用比例。可以广泛捕获低风险元数据，再根据数据量、风险、成本和失败频率选择内容及评估抽样。已确认的高影响事故必须按照政策保留。

追踪记录应该保留多久？

只保留满足调试、评估、审计或合同目的所需的时间。原始内容使用较短期限，汇总指标可以保留更久，已确认事故则使用有记录的保留措施。

谁应该审查 Agent 追踪记录？

工程师审查执行和集成故障，领域负责人审查任务质量，安全和隐私团队审查相关事故。基于角色的访问控制应防止人员广泛浏览敏感内容。

可观测性能够自动改进提示词吗？

它提供证据，而不是自动修复。根据失败聚类提出变更，在版本化案例上测试，并确认改进没有在其他位置引入回归。

首先应该构建哪张仪表板？

针对一个工作流显示符合条件的运行、已接受完成、拒绝原因、修正时间、延迟、成本、升级情况和当前工作流版本。每个汇总结果都应该链接到可检查的运行。

仅靠用户反馈足以衡量质量吗？

不足以。反馈很有价值，但并不完整，而且是自我选择的样本。应将其与任务验证、代表性抽样、领域审查和观察到的结果结合。

失败运行是否都应该保留？

应保留调查和满足政策所需的证据，但仍需遵守数据最小化、访问和保留规则。失败并不自动成为无限期存储敏感内容的理由。

在 Ottermind 中运行一个范围明确、以来源为依据的工作流，审查生成的交付物，并记录修正内容，把它们转化为第一批评估案例。