Agent可观测性与评测:指标清单与落地路径

Agent 不是单轮问答。它会把模型、工具、上下文、外部系统拼成多步任务。最终答复看起来正常，中间仍可能调用错工具、重试过多、漏掉引用、产生高额成本。

据公开资料与行业观察，近期工具动态集中在把 trace、评测、仪表盘、告警、成本和人工反馈放到同一条链路里。单独看日志不够，单独做离线评测也不够。更实际的目标是：让每一次 Agent 运行都能被复盘，也能被纳入版本迭代的判断。

你可以把这套东西当成上线后的质量闭环。拿到一组可采集字段、可写进仪表盘的指标、可每周复盘的评测任务，以及今天就能启动的选型路径。

1 背景：观测与评测为何必须一起看

观测回答刚刚发生了什么。评测回答这类任务是不是持续做得好。两者缺一，Agent 上线后的质量判断都会失真。

没有观测，评测集很容易脱离真实流量。没有评测，仪表盘上的数字只能描述异常，不能说明是否该回滚、降级或补知识库。

你可以先接受一个原则：凡是不影响决策的指标，暂缓上线。先搭最小可观测集，再让指标进入评测、告警和动作流程。

配图·江水竹影

2 指标定义：最小可观测集与评测指标

2.1 最小观测字段

不要一开始就采集完整提示词、完整工具返回、所有中间变量。先采足够复盘的最小字段，后续再按场景扩展。

字段可以扩展。第一版要能回答：谁发起了什么任务，走了哪些步骤，哪步错，是否人工兜底，花了多少时间，成本是否异常。

2.2 过程指标

过程指标看路径。它不判断最终输出是否漂亮，但能暴露 Agent 在工具链上的不稳定性。

每个指标都要有口径。工具选择错误率不是简单看模型日志，需要预先标注该任务的正确工具集合。参数错误率需要 schema 校验或动作结果回读。

2.3 结果指标

结果指标看任务是否完成。你可以把它们写成仪表盘上的一列，但不要只靠用户看起来不错。

任务成功率必须拆。一个可写入口径是：答案可交付、动作已执行、未越权、未泄露敏感信息、必要引用齐全。

2.4 定义口径

评测样本要分层。正常问题、边界问题、应拒答问题、工具失败问题，不能混成一个成功率。混在一起，指标越高越容易掩盖风险。

据公开资料/行业实践，评测分层是避免指标虚高的常见做法。模型答得顺，不等于动作链正确。

你可以给每类样本写一条失败定义。失败定义要能落到动作：是改提示词，还是修工具 schema，还是回滚版本，还是进人工复核。

配图·秋色温黄

3 实操步骤：用一周搭起观测与评测闭环

3.1 第1步：列真实任务与判据

找 10 到 20 个真实任务。不要挑 demo。优先挑线上高频、出错代价明显、用户会投诉的场景。

成功判据要能由系统或人复核。工单摘要可以写成包含问题、影响、建议动作、下一步责任人。失败可以写成缺字段、引用错误、把未授权动作写成已完成。

3.2 第2步：在调用链记录最小字段

给 Agent 调用链打时间戳。至少覆盖四类事件：trace、tool call、LLM call、guardrail。这四类事件要共用同一任务标识。

trace_id task_id step_id event_type status start_time end_time latency_ms cost_est

trace 是任务级事件。tool call 记录工具名、参数摘要、返回摘要、重试次数。LLM call 记录模型标识、token 用量估算或输入输出规模估算。guardrail 记录拦截原因与放行原因。

留意：参数摘要不要直接落明文。可用哈希、字段名列表、长度、枚举值、敏感字段脱敏标记。完整原文只在受控回放中短暂存在。

3.3 第3步：建离线评测集

评测集不是测试脚本。它是可重复运行的判据集。建议从线上真实案例里抽，按任务类型分层，容量从数十条起步，再逐步扩到稳定集。

每条样本至少包含输入、期望工具或动作、禁止动作、评分口径。若无法自动判断，要保留人工评分字段与备注，避免评测变成主观聊天。

3.4 第4步：上线仪表盘与告警

仪表盘不要堆满曲线。第一版只看四类：失败步骤、尾延迟、成本估算、人工介入率。先让团队每天能看到它们，再扩展结果指标。

告警要接回动作。新版本导致工具选择错误率升高，先降级到只读模式。某工具尾延迟过高，先切备用工具或限流。人工介入率异常，触发任务回放和人工复盘。

3.5 一周落地检查清单

完成度可以用下面的 ☐ 清单自查。没有勾满，不急于接入自动修复。

• ☐ 已列 10 到 20 个真实任务，并写清成功、失败、需人工介入三档判据。
• ☐ 所有调用链事件已共享 task_id、step_id、时间戳和结束状态。
• ☐ tool call 已记录工具名、参数摘要、返回摘要、重试次数，敏感参数已脱敏。
• ☐ guardrail 事件已记录拦截原因、放行原因和关联任务。
• ☐ 成本估算至少覆盖模型 token、外部 API、长上下文或高频重试场景。
• ☐ 离线评测集已覆盖正常、边界、拒答、工具失败四类样本。
• ☐ 仪表盘只保留失败步骤、尾延迟、成本估算、人工介入率四项第一版指标。
• ☐ 每条异常告警都已接回动作：回放、降级、只读、切备用工具、人工复核或知识库修订。
• ☐ 原始事件可导出，自定义指标可配置，人工反馈可关联。

4 工具动态与选型对比：先定栈，再选平台

据公开资料与行业观察，常见路线有三类：统一可观测协议栈、自托管观测与评测平台、商业一体化平台。没有万能选择，先明确数据、成本和协作约束。

个人开发者可以用轻量协议栈或一体化平台先跑通。小团队更看重接入速度和导出能力，不宜一开始自建大平台。企业多智能体场景则需要统一 trace、离线评测、权限隔离和回放能力。

已有 OpenTelemetry、微服务治理或统一日志体系的团队，可以优先走协议栈。它的价值是把事件先标准化，再决定后端存储和查询工具。

数据敏感、行业合规要求高的团队，自托管更稳。代价是部署、权限、留存策略和评测任务都要自己维护。你可以从单 Agent 链路起步，再逐步扩展到多 Agent。

小团队想快速上线，商业一体化能节省时间。但要提前验证数据导出、事件格式、自定义指标、人工反馈关联能力，避免后面迁不动。

4.1 决策路径

你可以按四问选型。问题越靠近数据、成本和退出，越应该优先回答；问题越靠近界面，越应该往后放。

4.2 选型红线

三条红线要守住。一，能导出原始事件，不只是导出聚合报表。二，能定义自定义指标，尤其是工具选择和人工介入口径。三，能关联人工反馈，把评测结果、投诉、修复动作串起来。

如果平台只能展示漂亮面板，但导不出字段、改不了指标、接不了回放，不要让它成为唯一真相源。你可以先用它做快速试点，但本地保留一份可回放事件。

5 常见坑：指标不等于质量，观测不等于合规

只看最终成功率，会掩盖路径问题。工具误用、过度重试、提示注入、人工兜底，都可能藏在一次成功里。你可以把一次成功拆开看。

它是否经过最小必要步骤，是否调用正确工具，是否触发过安全拦截，是否由人工接管后才完成。拆开以后，指标才能指导工程改进。

5.1 过度采集

完整提示词、完整工具返回、完整用户信息，不一定都要长期保存。据公开资料/行业实践，字段最小化、脱敏、采样和访问控制是常见建议。

更稳的做法是默认采摘要和元数据。需要复盘时按权限回放，敏感字段单独走加密与审计，保留周期按任务风险定。

5.2 只测答案，不测动作链

Agent 的质量不只是文本正确。它还要选对工具、传对参数、处理失败、守住边界。离线评测如果只比对最终文本，会漏掉高风险动作。

建议在评测集里加动作评分：该调用哪个工具，不该调用哪个工具，失败后是否停止，是否询问用户确认，是否避免越权写操作。动作评分比文本评分更重要。

5.3 把仪表盘当终点

仪表盘的价值是触发动作。没有动作的指标，只会制造焦虑。团队每周复盘时，要带着异常样本来自哪里去查，而不是只看颜色是否变绿。

收束：今天先做三件事

1 把 20 个真实任务写成成功、失败、需人工介入三档判据。不要写抽象口号，写可复核字段。这样评测才有共同语言。

2 给调用链补上 task_id、step_id、tool_name、error_type、cost_est。先从日志字段开始，再谈平台。字段统一后，后续迁移和回放都会轻松。

3 选 5 个指标做成每周评测报告。建议用任务成功率、失败步骤占比、工具选择错误率、人工介入率、成本估算。报告不需要长，关键是能暴露本周最影响质量的变化。

你可以对照上面的 ☐ 清单做一次上线前自查。也可以转发给负责 Agent 工程、质量或运营的人，让指标口径先统一。下一步不是买大平台，而是跑一个只读试点：先记录，再评测，再接告警和降级。

随手记，慢慢看 · 观山时和

起居、指标、用药提醒——不必一次写完整，随手记一笔，趋势会慢慢清晰。适合自己，也适合帮家人建立可回看的健康记录。

https://guanshanshuyuan.cn/#/mp/chronic-mp