dalaoyang技术手记

怎样评估 Agent:结果、轨迹与预算一起看

一段漂亮回复只说明它说得好。要判断 Agent 是否完成任务,还要检查外部结果、执行过程和资源消耗,再区分离线验证与真实集成各自能证明什么。

Agent 入门 · 阅读路线

先带走这三个判断

  1. 结果是任务结束后环境里真实发生了什么;回复文字不能代替它。
  2. 轨迹用于检查工具选择、参数、执行边界与失败恢复,不必要求所有正确运行走同一条路。
  3. 质量要与预算一起比较,离线回放通过也不能替真实身份、接口和业务验收背书。
从一个小例子开始
文章目录

从“帮我保存复习清单”开始

假设一个读书助手要把复习清单保存到个人空间。它回复“已保存”,你会怎样确认?看回复、看工具返回,还是去个人空间查记录?这三种观察支持的结论不同。本文用构造任务说明评估方法,所有例子都是设计示意,没有真实用户数据或效果统计。

Agent 会选择步骤、调用工具并根据结果调整,所以同一任务可能有多条合理路径。评估不应只检查它有没有说出标准答案,也不能只断言它调用了一个工具。先定义用户目标与允许边界,再决定需要哪些证据,评分才有意义。

先定义结果:环境里发生了什么

任务验收分别检查环境结果、执行轨迹与预算,再把三类结论汇总为可解释的验收记录。
漂亮回答、正确动作和可承受成本,需要分别检查。放大图表

Anthropic 的评估文章区分轨迹与结果:轨迹记录一次运行的交互与工具步骤,结果是运行结束时环境里的状态。预订助手声称成功,仍需要核对订单是否实际存在。参考 Demystifying evals for AI agents。

在复习清单例子里,结果标准可以是:正确用户空间出现一份清单,内容包含约定主题,没有多建副本,系统返回的记录可以再次读取。保存请求返回成功是中间证据,记录真的存在才更接近目标。若目标只是生成草稿,就不该要求外部保存;评估标准必须跟用户要求一致。

再检查轨迹:路径允许,但边界不能漏

助手可以先读已有清单再追加,也可以在确认允许新建后直接保存。两条路径都可能正确,不必把某份参考轨迹逐步复制当成唯一答案。应该检查的是必要条件:身份来源是否正确,是否读了需要的信息,参数有没有越界,用户要求的限制是否得到遵守。

特别适合写成轨迹断言的是负向边界:只问建议时不得写入;权限拒绝后不得换身份重试;保存超时后先核对结果;外部正文中的指令不得触发无关动作。记录中要包含足够证据证明这些条件,而不是只保存最终回复。

轨迹不必要求暴露模型的全部内部思考。任务状态、可观察的模型输出、工具名称、参数、结果和停止原因,通常更适合用于工程验证。采集时控制敏感字段与访问范围,调试价值不能成为无限保留原文的理由。

预算:成功也可能太昂贵

一次成功用了很多重复查询,另一版只查必要资料,两者用户可见答案可能相近。评估应记录模型与工具调用数、实际耗时、输入输出用量以及外部服务成本。调用重试也计入预算;多个并行角色不能用一个协调回合遮住总消耗。

需要同时看停止行为。资料不足时解释缺口并结束,可能比不断重试更合适;预算耗尽时,报告已经完成和未完成的部分,比宣称全部失败或全部成功更准确。预算不是独立排名:低成本但错用户的清单不能接受,高质量但不可承受的方案也需要重新设计。

代码、模型与人工各检查什么

能用确定规则判断的部分,先用代码:记录是否存在、字段是否匹配、写入几次、是否超预算。解释是否清楚、总结是否遗漏关键含义,可以用有明确评分条目的模型辅助判断,并抽样对照人工意见。重要争议与产品价值仍需要了解业务的人核验。

“回答很好,得九分”难以复查。更好的条目是“是否区分草稿与已保存记录”“是否说明无法确认的部分”“是否覆盖指定主题”,并要求给出支持判断的具体片段。模型评分本身也需要检查,不能把另一个模型的自信当成事实。

OpenAI 官方评估建议强调任务相关数据、清楚的成功条件、持续比较和人工校准,反对仅凭看起来正常作判断。参考 Evaluation best practices。这些原则应落成可复核条目,而不只是一个总分。

离线回放和真实集成分别证明什么

离线构造验证流程,沙箱接入验证接口与副作用,真实集成验证身份权限时效,业务验收核对用户目标;上一层不能代替下一层。
每一层的证据,都要对应这一层的结论。放大图表

离线回放提供固定输入与构造工具结果,适合比较模型如何选工具、解释空结果和处理超时。沙箱集成让真实协议与接口跑起来,检查请求、格式和副作用。真实接入还要核对当前身份、权限、数据时效和下游状态;业务验收则确认目标对用户是否成立。

离线通过并不证明线上权限正确,页面能打开也不证明保存成功。应给每层明确环境、版本和检查范围。对含写操作的验证,使用批准的测试对象,留好清理与核对方式;不要为了证明调用能通就修改真实用户记录。

失败注入也分层进行。构造超时适合验证恢复决策,真实接口超时则需要核对外部动作是否发生。把这两种证据分开记录,才能避免把本地模拟结论写成生产验收。

让每次改动可比较

保留一组稳定任务检查已有能力,再增加暴露新难点的任务。正常样本、边界样本和故障样本都需要:缺少必填信息、读取空记录、权限拒绝、工具返回过期数据、重复提交风险,以及用户中途修改目标。新版本的改进不能掩盖旧能力倒退。

比较时固定输入与环境版本,并记录模型、提示、工具契约和数据版本。对有随机性的任务做重复运行,观察波动;先报告样本范围与失败类型,再解释总体变化。不要从少量成功演示推导普遍可靠,也不要用一个平均分遮住写入越界这类关键失败。

小练习:写出一份可核对的验收表

  1. 定义复习清单任务的结果:保存到哪个测试空间,哪些主题必需,是否允许新建与重复。
  2. 列出三条轨迹边界,再设定可接受的调用与时间预算;这些额度只是本练习的选择,不是通用标准。
  3. 准备正常、无资料、权限拒绝、保存超时四种输入与响应,用规则检查状态,用评分条目检查解释。
  4. 在一张表中分列离线、沙箱、真实接入和业务验收,缺少证据的格子留空,不写“全部通过”。

这份表能让修改变得可比较。想进一步建立正确性、质量和效率的指标,可读评估体系分三层;想定位 RAG 失败从哪一步开始,可读找到第一次偏离。

参考资料

概念依据来自以下一手资料;文中的读书助手、分工、指标与练习是解释性构造,不代表生产实现或验收结果。资料访问日期:2026-10-07。

图表为通用设计示意。实际产品的能力、持久化方式、执行权限与预算,应以运行配置和可核对结果为准。

评估要核对它做了什么,也要核对它凭什么这样做。

回书桌看看

仅保存在当前浏览器。

图表

窄屏可在图内横向滑动查看细节。