长程 Agent 怎么评测：Task、Trial、Grader、Outcome 与 Evaluation Harness

👤 个人主页：zzz_2368

🧪 系列主题：Agent 评测｜从结果、轨迹到持续迭代

📚 本系列内容：评测体系、Rubric、Good Case、Bad Case、Trace 与长程 Agent

系列第 5 篇｜｜上一篇：Trace 是 Agent 评测的地基

本文参考：《Agent 评测漫谈》、Anthropic 的 Agent 评测说明、OpenAI Evals 和 Arize 的 Agent Evaluation 文档。长程 Agent 的具体能力会随框架和任务变化，本文给出的是通用评测模型，不对某个产品当前能力做判断。

文章目录

[长程 Agent 怎么评测：Task、Trial、Grader、Outcome 与 Evaluation Harness](#长程 Agent 怎么评测：Task、Trial、Grader、Outcome 与 Evaluation Harness)
- [一、短程 Agent 和长程 Agent 的差别](#一、短程 Agent 和长程 Agent 的差别)
- 二、先统一五个基本对象
- - Task：任务
  - Trial：试验
  - Grader：评分器
  - [Transcript 或 Trace：执行记录](#Transcript 或 Trace：执行记录)
  - Outcome：最终结果
- 三、长程任务的评分器设计
- [四、为什么需要多次 Trial](#四、为什么需要多次 Trial)
- [五、Evaluation Harness 应该负责什么](#五、Evaluation Harness 应该负责什么)
- [六、长程 Agent 的安全边界](#六、长程 Agent 的安全边界)
- [七、Skill 评测应关注生命周期](#七、Skill 评测应关注生命周期)
- 八、结论：从"能不能回答"到"能不能可靠完成"
- [一个简化 Harness 的实际运行](#一个简化 Harness 的实际运行)
- [八、长程 Agent 的最小验收矩阵](#八、长程 Agent 的最小验收矩阵)
- 参考资料

一、短程 Agent 和长程 Agent 的差别

短程任务通常可以抽象成：

text 复制代码

Query -> Answer

长程任务更接近：

text 复制代码

Prompt
  -> 任务拆解
  -> 多轮工具或 Skill 调用
  -> 读取中间结果
  -> 动态调整计划
  -> 修改外部环境
  -> 验证最终状态

两者没有绝对的产品边界，但评测重点不同。短程任务主要关注回答质量；长程任务还要关注是否完成了目标、是否遵守约束、是否留下可解释轨迹、是否在有限预算内收敛。

二、先统一五个基本对象

Task：任务

具有明确输入和成功标准的测试单元。例如"在测试数据库中创建一条订单，并返回订单号"。

Trial：试验

Agent 对同一 Task 的一次实际运行。由于模型和工具链具有随机性，同一任务多次运行可能产生不同轨迹。

Grader：评分器

判断任务某个方面是否满足要求的逻辑。一个 Task 可以有多个 Grader，例如最终状态、权限、工具调用和响应质量。

Transcript 或 Trace：执行记录

包含模型交互、工具调用、中间结果和错误的完整记录。

Outcome：最终结果

任务结束时外部环境的真实状态。它可能是数据库记录、文件系统状态、工单状态或模拟环境中的变量。

Anthropic 的 Agent 评测文章对这些概念有较清晰的拆分，并强调评测 Agent 时实际上是在评测模型与 harness 的组合。参考原文。

三、长程任务的评分器设计

不建议只设置一个"任务完成率"。可以拆成以下评分器：

Grader	判断问题	适合的方式
Outcome Grader	最终环境状态是否正确	数据库、文件或 API 检查
Constraint Grader	是否违反权限和操作约束	规则检查、审计日志
Tool Grader	工具调用是否有效	参数校验、调用结果分析
Trajectory Grader	路径是否出现异常循环或无效步骤	Trace 规则、人工或模型判断
Response Grader	最终说明是否准确完整	Schema、人工或 LLM Judge
Efficiency Grader	是否超过成本和时间预算	计数器、阈值检查

不同评分器可能出现冲突。例如 Agent 最终完成了任务，但执行时间超过预算；或者回复很漂亮，但环境状态没有改变。此时不要简单平均，而要按业务风险定义优先级。

四、为什么需要多次 Trial

单次运行只能说明"这次发生了什么"，不能充分说明稳定性。对于有随机性的系统，可以对同一 Task 运行多次，并记录：

成功次数；
失败类别；
平均和最大工具调用次数；
最长耗时；
是否出现高风险动作；
不同轨迹是否都满足成功标准。

多次 Trial 也有局限：运行成本更高，环境可能被前一次运行改变，结果之间不一定独立。因此，重复试验需要隔离环境、重置状态或使用可控的测试夹具，不能只在生产数据上反复执行。

五、Evaluation Harness 应该负责什么

Evaluation Harness 可以理解为端到端运行评测的基础设施。它不等同于 Agent Harness：

Agent Harness 负责让模型执行任务；
Evaluation Harness 负责提供任务、环境、并发运行、记录、评分和汇总。

一个最小的评测 Harness 应支持：

text 复制代码

加载 Task
  -> 初始化隔离环境
  -> 运行一个或多个 Trial
  -> 保存 Trace 和 Outcome
  -> 执行多个 Grader
  -> 汇总结果与失败原因
  -> 输出可回归的报告

OpenAI Evals 项目提供了运行评测和编写自定义评测的开源框架思路；具体使用时仍需按照自己的任务、模型接口和环境改造。

六、长程 Agent 的安全边界

长程任务往往拥有更强的工具权限，因此评测环境至少应区分：

只读任务；
可写但可回滚任务；
需要人工确认的高风险任务；
禁止在真实生产环境执行的任务。

对于删除、支付、发信、发布、权限变更等动作，不能只观察 Agent 最终是否"说得合理"，而应核对：

是否在正确时机请求确认；
是否只使用授权工具；
是否留下审计记录；
失败时是否能回滚；
重试是否可能造成重复副作用。

这些内容属于安全和工程约束，不应被一个较高的文本质量分掩盖。

七、Skill 评测应关注生命周期

当 Skill 可以被频繁创建和修改时，评测对象就不只是单次 Agent。建议至少覆盖：

Skill 是否能被正确发现和加载；
输入条件不满足时是否安全退出；
是否调用了正确工具；
输出是否满足约定格式；
与其他 Skill 组合时是否产生冲突；
新版本是否破坏历史任务。

原文将 Skill 生态扩大后对评测系统的简单化、标准化和自动化要求作为重要观察。这个方向可以作为工程推测，但具体用户规模、发布日期和行业趋势仍应以可达的一手资料为准，不宜把原文中的内部调研数字泛化。

八、结论：从"能不能回答"到"能不能可靠完成"

长程 Agent 的评测至少需要同时看：

text 复制代码

任务定义
  + 隔离环境
  + 多次试验
  + 完整轨迹
  + 多维评分器
  + 最终环境状态
  + 回归与发布门禁

它的核心变化可以概括为：

短程 Agent 主要评估输出质量；长程 Agent 还要评估任务完成、过程稳定、成本约束和安全边界。

这也是本系列五篇文章的共同结论：评测不是一次打分动作，而是连接观测、研发、回归和发布的基础设施能力。

一个简化 Harness 的实际运行

本系列附带的本地 Demo创建模拟 Task，运行多个确定性 Trial，执行 Outcome、Safety、Efficiency 和 Rubric Grader，再汇总回归结果。实际运行中 3 次 Trial 有 2 次通过，成功率为 0.67；失败样本被归因为 tool-error-handling。

这只是教学模拟，不是任何真实 Agent 的稳定性指标。真实 Harness 还需要隔离环境、状态重置、权限控制、审计日志和可回滚副作用。

八、长程 Agent 的最小验收矩阵

一个长程评测 Harness 至少应在测试环境验证以下组合：

场景	必须检查
正常完成	Outcome、Response、Trace 均可保存
工具失败	Agent 能停止、重试或转人工，不能无限循环
环境重置	每次 Trial 从相同初始状态开始
高风险动作	权限、确认、审计和回滚均有效
版本升级	历史 Task 可重放并产生可比较报告

多 Trial 的成功率只能描述当前 Task 集合和当前环境，不能外推成 Agent 的普遍能力。报告还应保留失败类别和运行配置，否则不同版本之间的数字不可直接比较。

如果任务会产生真实副作用，应优先使用沙箱、模拟服务或可回滚测试夹具；不要为了获得"真实结果"直接在生产系统反复执行。

参考资料

感谢阅读，记得点赞、关注、收藏，欢迎各位评论区交流！！！