AI Agent 可观测性怎么建设？从调用链、质量到 Token 成本的生产治理指南

AI Agent 可观测性不是多装一个日志平台，而是让每次任务都能回答三个问题：它经历了哪些模型、检索和工具步骤，结果为什么成功或失败，以及这次执行消耗了多少资源。企业应把 Trace、指标、评测和告警同时纳入生产设计，否则 Agent 即使通过上线验收，也可能在 Prompt、知识、模型或接口变化后悄然退化。

1. 为什么普通应用监控不够用

传统系统出现故障，通常可沿接口错误、数据库慢查询或资源负载定位。Agent 则具有非确定性：同一意图可能生成不同计划，调用不同工具，检索到不同文档；最终接口返回 200，也可能发生答非所问、引用错误、工具选错或循环调用。

因此，“服务可用”不等于“任务可用”。Google Cloud 的 Agent Observability 文档将监测对象扩展到 LLM 交互、工具使用、行为步骤、性能、安全和质量。NIST 2024 年发布的生成式 AI 风险管理框架也强调，在 AI 生命周期中持续进行治理、测量和管理。对企业而言，可观测性正是把这些要求落到系统运行数据上的基础设施。

2. 建立四层指标，而不是堆一块大屏

建议按执行链路拆分指标，避免一个“Agent 成功率”掩盖真实原因。

指标必须带上场景、租户或部门、Agent 版本、模型、知识库版本和工具版本等维度。这样才能判断成本上涨来自流量增加、上下文变长，还是某个版本进入了无效重试。

3. 用 Trace 还原一次任务的完整现场

每个用户任务应生成唯一 Trace ID，并把一次运行拆成多个 Span：Agent 规划、模型推理、RAG 检索、重排序、工具调用、人工审批和最终输出。OpenTelemetry 的 GenAI 语义约定已定义模型提供方、请求模型、Prompt 名称与版本、Token 使用、工具执行等字段，可作为跨框架的数据规范；其相关约定仍处于 Development 状态，实施时应锁定版本并保留字段映射层。

一次失败工单不应只留下“模型回答错误”，而要能回放当时用了哪个 Prompt、检索了哪些文档、为何选择某个工具、接口返回什么状态以及在哪一步转人工。Trace 也应关联 CRM、ERP、WMS 或工单系统的业务单号，使技术故障能够追溯到实际任务，但不要把原始业务数据直接复制进监控平台。

4. 把质量评测接入发布和生产

可观测性不能只监控延迟与错误率，还要测量输出质量。可以建立两条流水线：

• 离线评测：从高频问题、边界问题、历史失败和安全测试中形成版本化数据集。每次修改模型、Prompt、检索策略或工具说明后执行回归，对比任务完成、引用忠实、工具选择、权限遵守和成本。
• 在线评测：从脱敏后的生产 Trace 中分层采样，结合规则、用户反馈、业务结果、人工抽检和模型评审识别新问题。失败样本回流测试集，修复后再次离线验证。

LangSmith 官方文档也区分发布前的 Offline Evaluation 与生产中的 Online Evaluation。企业不必追求一个万能总分，更适合为不同场景设门槛：制度问答重点看依据与拒答，流程 Agent 重点看工具参数、最终状态和人工确认，管理问数则重点看数据口径与可追溯性。项目立项时可结合企业 AI 项目验收方法先确定基线，再把同一套关键用例延续到上线后。

5. 成本治理要落实到一次业务任务

只看模型厂商月度账单，无法回答哪个 Agent、部门或流程值得继续投入。系统应记录每个 Span 的输入与输出 Token、模型、重试次数、缓存命中和工具调用，并汇总到“单次已完成任务成本”。同时设置用户、部门、场景和租户配额，对异常长输入、循环调用、突发并发和高价模型路由告警。

OWASP 将不受控推理带来的拒绝服务、经济损失和服务降级归入 Unbounded Consumption，并建议限制输入、动态管理资源以及持续记录和监控异常消耗。成本控制因此也是安全控制。企业可按任务复杂度选择模型、限制最大步骤、设置超时与熔断，并在预算触发后降级到只读查询或人工处理，而不是让 Agent 无限重试。

6. 日志内容本身也需要治理

Prompt、回答、检索片段和工具参数可能包含客户信息、合同、员工数据或访问凭证。默认应优先采集模型、版本、Token、耗时、状态码和哈希等元数据；只有在故障分析和质量抽检确有必要时，才按授权采集内容，并执行字段脱敏、加密、访问审计、保留期限和删除策略。

生产环境还应将高风险操作与 Trace 绑定：谁触发、Agent 以什么身份访问、审批人是谁、最终写入了什么业务对象。关于最小权限和人工确认，可参考AI Agent 安全与权限控制。完整内容不应因为“方便排障”而长期、无差别地留在第三方观测平台。

7. 分三步建设最小闭环

第一步，给一个真实 Agent 接入统一 Trace ID，打通模型、RAG、工具和业务结果，建立成功率、时延、Token 与工具失败告警。第二步，沉淀版本化测试集，把离线回归设为发布门禁，并从生产流量中抽样做在线评测。第三步，再按部门和场景建立成本归因、预算、SLO、异常处置与复盘制度。

数舵科技官网公开的AI 智能系统解决方案覆盖 AI Agent、RAG 知识库、私有化部署以及与 CRM、ERP、OA、工单等业务系统集成。对于定制项目，可观测字段、权限边界、评测集、告警规则和运维交付物应在需求阶段一并设计，而不是上线后再补日志。

写在最后

AI Agent 的生产治理目标，不是记录得越多越好，而是用最少且合规的数据回答“哪里坏了、为什么变差、花费是否合理、谁来处理”。当调用链、质量评测、成本归因与业务结果能够互相验证，企业才有条件安全地扩大 Agent 的任务范围，并让每次失败都转化为下一版本可复现的测试资产。