文章目录 / 点击展开
AI Agent 上线后只看“最终成功或失败”远远不够。一次任务可能经历检索、多个模型、工具调用、重试和人工审批。可观测性的目标是回答：请求在哪一步变慢、费用花在哪里、失败能否恢复、输出质量是否下降，以及哪类任务应该停止自动化。
先定义一次任务的追踪边界
为每个用户请求生成唯一 trace_id，每个模型、检索、工具和审批步骤生成 span_id。记录父子关系，才能还原完整链路。异步队列、Webhook 和人工审批继续传递同一个追踪标识。
日志不应保存密钥、完整个人信息、原始 Cookie 或未经脱敏的文档。先定义允许记录的字段、保留时间、访问权限和删除流程。
第一步：记录统一事件结构
每个事件至少包含工作流版本、节点类型、模型或工具版本、开始结束时间、状态、重试次数、输入输出量、估算成本、错误类型和人工接管情况。模型文本可根据风险保存摘要或哈希，而不是默认保存全文。
trace_id
span_id
workflow_version
node_name
provider_and_model
started_at / ended_at
status / error_type
input_units / output_units / cost
retry_count / human_handoff字段名称和单位必须统一，否则不同工作流无法比较。
第二步：分解延迟和等待时间
分别统计排队、检索、模型首个结果、完整生成、工具网络、重试和人工审批耗时。平均值会掩盖少量极慢请求，应同时观察中位数和高分位延迟。
用户可感知的等待与后台总耗时也要分开。对于长任务，可以先展示进度或阶段结果，但不能用虚假进度掩盖未知状态。
第三步：把成本归因到任务和结果
成本应按用户、业务、工作流、模型、工具和任务类型拆分，并关联最终结果。单独统计重试、升级模型、重复检索和失败任务消耗，通常能发现最直接的优化点。
不要只优化单次调用价格。若轻模型导致更多返工和人工修改，总成本可能更高。具体选型可以参考 AI 模型选型与成本控制 的质量底线方法。
第四步：建立失败分类和恢复策略
将失败分为输入校验、鉴权、限流、网络、模型拒绝、结构解析、检索为空、工具错误、业务冲突、审批超时和未知错误。每类失败定义是否重试、最多次数、退避时间、降级方式、告警对象和人工恢复步骤。
重试必须考虑副作用。发送消息、创建订单和修改权限等操作应使用幂等键并先确认上次结果，避免超时后重复执行。
第五步：持续观察质量而非只看可用性
服务返回 HTTP 200 不代表任务成功。为不同场景建立离线评测、线上抽检、用户反馈和人工修改率。监控结构合规、引用支持、拒答正确、工具选择和最终业务结果。
模型、提示词、知识库或工具变更时保留版本，并比较变更前后的固定样本。质量指标下降时应能回滚，而不是等用户集中投诉。
第六步：配置告警和预算护栏
告警围绕可行动事件设计，例如失败率持续升高、特定节点高分位延迟异常、每任务成本突增、重试循环、人工接管堆积或高风险工具被频繁调用。短暂抖动可以聚合，避免通知疲劳。
预算护栏可按日、业务和用户设置。接近预算时暂停低优先级任务，异常超支时阻断新请求并保留人工通道。不可逆动作始终保留审批，具体编排可参考 n8n AI 审批工作流。
运营看板检查清单
- 每个请求是否有贯穿异步节点的追踪标识。
- 是否能分解模型、检索、工具、重试和审批耗时。
- 成本是否能归因到任务类型和最终结果。
- 失败是否分类并具有明确恢复策略。
- 日志是否脱敏、限权并设置保留时间。
- 模型与工作流变化是否可比较和回滚。
- 是否设置预算、限流、告警和人工接管。
常见问题
需要保存完整提示词和回答吗
不一定。应根据调试需要和数据风险决定，可保存模板版本、结构化指标、脱敏样本或哈希。敏感内容不应默认长期保留。
为什么有日志仍然找不到失败原因
常见原因是异步节点没有传递追踪标识、错误被统一包装、工具版本缺失或日志只记录最终状态。需要使用统一事件结构连接链路。
哪个指标最值得先做
先确保请求成功率、失败类型、总耗时、总成本和人工接管可见，再逐步增加质量和业务结果指标。