智能体可观测与评测指标实战清单

智能体上线问题常不在单次回答，而在链路失控：工具误调、检索污染、上下文溢出、预算抖动、人工审核缺位。可观测负责发生什么，评测负责做得好不好，发布门禁负责还能不能继续。据行业观察，三者串起来才能把模型输出变成可维护的产品行为。

一、背景：可观测与评测不是两件事

据公开资料，通用可观测规范正在把请求、响应、错误、耗时等基础字段扩展到大模型和智能体场景，重点是把 prompt、模型调用、工具执行、检索、人工节点串成同一条 trace。若链路标识不统一，排障时只能看到模型返回，看不到它为什么调这个工具、是否命中缓存、是否因超时重试。

评测也在从最终答案对不对扩展到过程质量：是否选对工具、参数是否有效、引用是否一致、是否触发安全策略、是否产生高成本重试。线上可观测提供真实样本，离线评测提供回归基线；没有前者，评测集容易脱离任务；没有后者，线上指标容易变成噪声看板。

更现实的问题是组织边界：模型团队看生成质量，业务团队看任务完成率，平台团队看延迟和成本。如果指标不统一，会议会变成各说各话。可观测与评测需要共享同一套字段和版本号，才能把故障定位、质量回归和发布决策放在同一条链路上。

配图·江水竹影

二、指标定义：最小观测集与评测指标分层

最小观测集：先采四类字段

建议先围绕一次任务采集四类字段：调用链路标识、模型与上下文用量、工具或检索执行状态、错误与重试信息。字段不在多，关键要能定位哪一步、输入是什么、输出落到哪里、失败发生在哪类边界。

trace_id, session_id, agent_id, step_id, parent_step_id, model_name, prompt_version, input_hash, output_ref, tool_name, tool_status, search_query_hash, doc_ref, usage_input, usage_output, usage_cached, reasoning_usage, latency_ms, timeout, retry_count, error_code, cost_bucket, safety_label, human_action, env, release_version

如果当前系统只能先采基础版，保留 session_id, agent_id, step_id, tool_name, input_hash, output_ref, usage_total, latency_ms, error_code。这组字段已能支撑延迟分布、工具失败归因、成本异常和简单回归。

系统层指标：先看链路是否稳

系统层指标关注服务是否可运行。延迟不要只看平均值，应分别观察首步耗时、完整任务耗时、工具等待耗时和人工审核等待耗时。超时、重试、队列积压、并发和吞吐要按任务类型拆开，否则一个批量任务会掩盖一个实时问答的退化。

成本也要分层看：输入输出 token 用量、缓存命中比例、工具重试次数、检索次数、模型路由升级和人工审核成本都应进入观测集。据行业实践，成本异常常常不是单轮变贵，而是 agent 在错误工具或错误上下文上反复循环。

质量层指标：再看任务是否好

质量层指标关注结果和过程。任务完成率不能只按是否有返回判断，还要看是否满足验收条件。工具参数有效率用于发现 schema 漂移，引用一致性用于校验答案是否来自可追溯文档，安全拦截率用于发现边界策略是否过松或过严，人工修改率用于观察自动输出与业务标准之间的差距。

所有指标应带版本维度。至少记录 prompt_version、model_version、tool_schema_version、release_version。没有版本字段，就无法比较两次上线；无法比较，评测分数和线上异常都只能成为孤立事件。

观测指标与评测指标要对应动作

看板指标必须映射到门禁动作，否则数据多但无法处理。下表把观测、评测与上线动作对应起来。

配图·秋色温黄

三、读者可照做步骤：从埋点到发布门禁

第一步：选一个真实高频任务并定义风险边界

不要从全业务开始，选一个有用户反馈、有明确输入输出、能判断好坏的任务，例如文档问答、工单分类、数据查询或内容草稿生成。据行业实践，任务越单一，评测指标越容易落地，后续扩展到多 Agent 协作也更有基线。

按动作风险分层：只读查询可自动通过但保留采样审计；写操作必须记录 before 与 after 摘要并要求人工确认；跨系统动作如发信、下单、改权限要设置双签或临时禁用开关。SLA 可写可回答率、最大等待、可接受错误类型，不急着追绝对数值，先把常态分布记录下来。

第二步：建立统一事件日志或 trace schema

每个 agent 步骤写入结构化事件，至少关联 session、step、工具、模型、用量、错误码和版本。日志字段命名要跨服务一致，避免模型调用叫 model、工具执行叫 function、检索叫 retrieval，排障时无法拼接。建议把工具调用与检索调用都建模成同一类 span，便于统一统计超时和失败。

敏感字段处理要前置：prompt、文档片段、用户资料不要整段落盘，使用 input_hash、output_ref、doc_ref 做引用，必要时加密或脱敏。评测采样也应基于引用取原文，避免把密钥、身份证号、合同细节写入观测面板。

第三步：接入离线评测与线上采样

离线评测用固定小样本回归，覆盖正常、边界、异常三类用例。样本不必一开始很大，但必须有可重复评分方式：pass、fail、score、label 中至少选一种，并记录原因字段。原因字段比分数更重要，因为团队下一步要修的是原因，不是平均数。

线上采样从真实日志中按任务类型抽取：失败样本全采，高危动作全采，普通成功样本按低比例采。把线上漂移转成评测用例，避免上线后出现的新错误只停留在日志里。采样策略要版本化，防止某个工具突然错误暴增时评测集被异常样本冲淡。

第四步：把指标接到发布门禁

发布前固定三道门禁：过程错误率、成本预算、安全拦截。任一越界则阻断或降级，并保留回滚开关。门禁阈值来自基线，而不是拍脑袋：先运行基线期，记录常态分布，再设告警线和阻断线。高风险动作可单独设线，不要和普通问答共用阈值。

门禁不是分数低就不发，而是可执行动作：工具参数错误率上升时关闭某工具；引用一致性下降时强制检索重排；重试成本飙升时限制递归步数；安全标签命中时停止写操作并转人工。每个动作都要能被日志验证，避免门禁只有告警没有处置。

四、工具动态与选型：别只盯一个面板

三类工具分别解决什么问题

据公开资料与行业实践，工具可分为三类：通用链路观测，擅长请求、错误、耗时、部署版本，适合接入 trace 与告警；生成式 AI 专用观测，通常更关注 prompt、模型、token、工具调用、检索片段；评测或标注平台，用于构建回归集、打分、版本比较和人工反馈。

三者能力重叠但不互替。链路观测能告诉你慢在哪里，不一定知道答案为什么错；AI观测能展示模型和工具怎么调用，不一定能管理测试集与标注流程；评测平台能比较版本质量，但不一定承担线上告警和预算熔断。选型目标不是买齐，而是补齐缺口。

选型决策：按强需求优先接入

常见坑与修复

五、延伸：从看板走向控制回路

可观测指标的价值不是展示，而是驱动控制策略。常见控制包括超时降级、预算熔断、路由到更强模型、触发人工审核、自动关闭高风险工具、限制 agent 最大步数。据行业实践，成熟团队会把观测、评测、决策和回滚做成固定回路，而不是每次事故临时开会。

多智能体协作会增加不确定性。除单 agent 字段外，还应观察 handoff 次数与原因、权限边界传递、消息总线积压、共享状态一致性、子任务结果覆盖率。否则每个 agent 指标正常，整体仍可能因重复委派、状态覆盖或权限错配而失控。跨 agent 观测的关键不是追踪每一个内部想法，而是追踪责任转移和可验证结果。

持续评测也要版本化：prompt、模型、工具 schema、检索索引、路由器规则都要有版本号。每次变更保留 diff、评测报告、线上采样对比和回滚记录，让团队能回答到底改了什么，证据是什么。只有把证据沉淀进发布流程，评测才不会退化为演示材料。

六、今天就能执行的检查清单

☐ 选一个真实高频任务，写出三类风险动作：只读、写操作、跨系统动作，并指定审核方式。

☐ 补齐最小字段：session_id, agent_id, step_id, tool_name, input_hash, output_ref, usage_total, latency_ms, error_code。

☐ 建立一批小样本评测集，覆盖正常、边界、异常，并固定评分口径。

☐ 设定三道上线门禁：过程错误率、成本预算、安全拦截；写操作必须保留回滚开关。

☐ 对工具调用增加参数有效性与重试计数；对检索任务增加引用一致性和文档来源字段。

☐ 每周从线上失败日志抽一批样本回填评测集，让评测分数贴近真实任务分布。