文章目录
- 1. 先定义评测对象：到底在测谁？
- 轨迹与结果为什么都要看？
- 2. 评分器分工：哪些交给代码，哪些需要判断？
- 部分得分和任务通过，应分别报告
- 模型评分器也需要被检查
- 3. 四类 Agent，需要不同的成功证据
- 4. pass@k 与 pass^k：找到一次答案，和每次都成功
- 先看一个理想化例子
- 有限次运行，怎样估计？
- 5. 任务质量：先确保题目和判卷标准一致
- 给每个任务准备一个能通过的参考解
- 正例与反例要一起设计
- 6. 环境与评分：防止测量本身制造假象
- 隔离运行，还要保护裁判
- 看轨迹时，先定位证据断在哪里
- 7. 能力集与回归集：给不同阶段留下信号
- 从第一批任务，到持续维护
- 8. 离线分数之外，还缺哪些证据？
- 9. 一份小示例：为什么“只看状态”会漏判？
- 框架解决执行，任务定义决定测量价值
- 参考文献
摘要：本文围绕 Agent 评测展开一套可检查的设计方法。先区分任务、尝试、轨迹与结果，明确评测对象；再按证据类型划分代码、模型与人工评分器，并强调部分得分与任务通过应分别报告。随后按编码、对话、研究、电脑操作四类 Agent 给出不同的成功证据，并对比 pass@k 与 pass^k 两种指标的含义与估计方式。文章还讨论了任务质量（参考解、正反例）、环境隔离与评分防假象、能力集与回归集的维护，以及离线分数之外的线上证据。最后通过一个退款评分小示例，说明“只看状态”为何会漏判，并给出可落地的执行顺序与工具选型建议。
任务确实完成了吗？换一种对话还能完成吗？分数下降时，出错的是智能体还是评测器？
假设一个售后智能体需要为订单退回 80 元。它查了规则，解释得体，最后说：“退款已完成。”如果数据库里没有退款记录，这次任务仍然失败。另一条轨迹真的退了款，却跳过了用户确认；只检查最终余额，又会把它判为成功。
这两个例子暴露了 Agent 评测的困难：一句回答、一次工具调用、一个最终状态，分别只能提供一部分证据。系统还可能在相同任务的下一次尝试中走出另一条路径。
Anthropic 于2026 年 1 月 9 日发表的Demystifying evals for AI agents提供了一个起点：分清任务、尝试、轨迹和结果；组合评分方法；分别衡量能力与回归；持续把真实失败变成测试。[1] 本文沿着这些问题，结合 τ-bench、HumanEval 和官方评测文档，展开一套可检查的设计方法。退款场景、评分组合与数值例子均为原创教学示例。
先看一轮评测如何产生证据，再讨论该怎样解释分数：
图 1｜一次 Agent 评测的结构。中心表示评测阶段，左侧给出任务条件与运行配置，右侧区分过程记录和环境结果。组合评分需要明确各类证据的用途。概念与布局为原创，参考文献 [2]、[3]、[11]。
1. 先定义评测对象：到底在测谁？
给大模型一段文字、检查返回答案，通常可以把测试对象理解为一次模型调用。Agent 会读取信息、调用工具、改变环境、接收返回，再继续行动。此时，一个最终分数包含了多个组件共同工作的结果。
同一个模型，换一套工具描述、重试机制或上下文整理方式，完成率可能改变。因此，要区分两套框架：
- Agent harness，智能体运行框架：组织模型输入、工具调用、上下文、执行状态与恢复。
- Evaluation harness，评测框架：准备任务和环境，启动尝试，收集证据，调用评分器，汇总结果。
前者属于被测系统，后者负责测量。评测框架可能复用生产运行框架，但二者的职责不能混在一起。Harbor 将任务组织为指令、环境与验证脚本，并把一次执行称为 trial；LangSmith 则将指定应用版本在数据集上的运行及评分记录为 experiment。[3][11]
| 概念 | 在退款例子中指什么 | 记录时应保留什么 |
|---|---|---|
| Task，任务 | 为指定订单处理一次符合规则的退款 | 输入、规则、初始状态、成功条件 |
| Trial，一次尝试 | 从规定初始状态开始的一次完整运行 | 尝试编号、配置、预算与终止原因 |
| Transcript / trace，轨迹 | 用户消息、模型输出、工具调用及真实返回 | 接口实际可见的过程记录 |
| Outcome，结果状态 | 退款是否创建，金额、对象及次数是否正确 | 权威数据源的状态或已保存的产物 |
| Grader，评分器 | 核验退款记录，检查授权，评价解释质量 | 标准版本、证据与判定理由 |
| Suite，评测集 | 正常退款、超期拒绝、重复申请等用例集合 | 覆盖范围、来源、分组与版本 |
轨迹与结果为什么都要看？
结果回答“世界最后变成了什么样”，轨迹帮助回答“怎样变成这样的”。二者不能互相替代。
τ-bench 使用最终数据库状态和必要回复信息判定任务完成，但论文明确指出：某些状态正确的尝试仍可能违反过程规则，例如未经确认就操作。[2, §3] 这是一条很实用的边界：状态验证强于口头承诺，但状态正确仍可能不足以证明完整成功。
回到本文的假设任务，至少要分开检查三个条件：款项是否正确退回，操作是否得到有效授权，回复是否准确反映执行结果。礼貌的解释不能抵消未授权操作；失败后的诚实说明也不能被记为退款成功。
2. 评分器分工：哪些交给代码，哪些需要判断？
一个任务可以有多个评分器，每个评分器也可以包含多个检查项。选评分器时，先问证据是否明确，再问判断是否需要理解语义。LangSmith 官方文档区分代码、模型和人工等评价方式，并说明模型评分可以使用或不使用参考答案。[3]
| 评分方式 | 本文示例中的工作 | 能直接提供的证据 | 需要防范的失效 |
|---|---|---|---|
| 代码评分 | 检查退款金额、订单、重复支付、测试结果 | 明确条件是否满足，可定位到具体断言 | 条件写错、数值容差不合理、只接受一种合法输出 |
| 模型评分 | 判断回复是否解释了处理结果，是否与工具证据矛盾 | 对开放表达作语义判断 | 偏好长答案、忽略反证、评分随提示和模型变化 |
| 人工评分 | 裁决复杂规则争议，校准模型评分 | 领域判断与分歧解释 | 人员标准不一致、成本高、覆盖有限 |
这三类方法之间没有统一的优劣排名。检查refund.amount == 80不需要另一个模型猜；判断用户是否听懂解释，则很难只靠关键词。
可以把评分过程拆成以下层次：
图 2｜组合评分的职责划分。代码规则与模型判断并行提供维度结果，虚线将人工校准关联到评分面板，不要求每次运行都执行。硬性条件参与最终裁决，不能被其他维度的高分抵消。布局与组合规则为原创，参考文献 [3]、[4]。
部分得分和任务通过，应分别报告
假设一次尝试完成了身份核验，也找到了正确规则，但退款工具返回失败。它比一开始就选错用户更接近目标，这个进展可以作为诊断分数保留；对用户而言，钱仍未退回。
本文为该示例定义：
任务通过 = 结果正确 ∧ 授权有效 ∧ 无重复操作 ∧ 回复与证据一致。
解释质量、轮次数和成本另外记录。若产品还要求必须完成通知，可以将通知加入硬性条件。哪些条件能够加权、哪些不能补偿，要由任务要求决定，不能在看到分数后临时更改。
对于能够补偿的质量维度，可以按预先约定的权重汇总；二值判定则要求必要检查全部通过。也可以采用混合方式：先通过硬性条件，再达到质量阈值。三种汇总方式测量的目标不同，报告时要明确规则。
这个设计避免一种常见误读：平均质量分升高，不一定意味着更多任务可靠完成。报告多个维度的价值，是让失败原因可见，而不是让错误被平均掉。
模型评分器也需要被检查
Judging LLM-as-a-Judge在对话评价设置中研究了位置、冗长和自我偏好等偏差。[4] 这些结果不能直接给出某个业务评分器的误差率，但说明“换一个强模型打分”不足以建立信任。
一个可操作的校准办法，是先建立人工裁决的小型证据集，包含以下对照：短而正确的回复，长而错误的回复，措辞漂亮但违背工具返回的回复，以及证据不足的回复。然后逐项比较模型判定与人工理由。
评分提示要说明每个等级所需的证据，并允许“证据不足”。对于信息缺失的轨迹，评分器不能根据智能体的自述补出并不存在的退款记录。多个评分维度可以分别判断，防止语气、完整性和事实正确性互相干扰；这些是本文的评分设计建议。
3. 四类 Agent，需要不同的成功证据
评测对象的分类应该跟工作产物有关。代码、对话、研究和电脑操作都可能经过很多轮，但各自的成功证据不同。
| Agent 类型 | 一份明确的任务 | 核心结果证据 | 额外需要看的过程 |
|---|---|---|---|
| 编码 | 修复空密码仍可登录的漏洞 | 新测试通过，既有行为未被破坏 | 是否改坏接口，是否删除或绕过测试 |
| 对话 | 处理退款，或解释为何不能退款 | 与规则一致的业务状态和必要回复 | 是否确认授权，是否提供了错误承诺 |
| 研究 | 查证某项指标并形成分析 | 事实、来源、关键问题覆盖 | 引用是否支持对应主张，是否忽略冲突证据 |
| 电脑操作 | 修改应用设置并保存文件 | 实际配置、文件或后台状态 | 操作是否落在正确对象上，是否留下无关修改 |
编码任务的验证通常可以运行测试。SWE-bench 的评测基础设施在规定环境中执行代码并生成结果报告；在自己的任务里，还要确认测试真正覆盖需求。[5] “测试全绿”可能说明测试充分，也可能说明没有测到漏洞。可以加入独立的反例输入，检查失败条件是否被修复。
对话任务除了工具结果，还包含信息收集和用户协作。τ-bench 模拟用户与 API 交互；τ²-bench 进一步研究用户与智能体都能修改共享环境的双控制场景。[2][6] 例如远程排障时，客服给出正确指令，用户却没有执行，环境仍然没有修好。评测不能把“指导说得对”直接当成“问题已解决”。
研究任务要把查找事实与形成可靠综合判断分开。BrowseComp 面向难以检索、答案容易验证的问题，不能代表所有研究报告的质量。[7] 对本文假设的指标分析，还应预先列出必须覆盖的问题，并逐条检查来源、时间口径和相互矛盾的信息。命中一个正确数字，并不保证推导出的趋势成立。
电脑操作尤其需要检查保存后的产物。WebArena 强调网页任务的功能性完成，OSWorld 提供桌面任务的初始化与执行验证。[8][9] 点到了“保存”按钮，是动作证据；正确目录里出现可打开的目标文件，才是结果证据。本文讨论这些基准的验证思路，不比较不同版本的榜单分数。
浏览器操作还需要记录工具选择与成本。Anthropic 原文讨论了文档结构读取和截图之间的令牌、延迟取舍；这个例子不能推出一种接口在所有任务上更高效。[1] 在自己的评测中，可以将同一任务、相同预算下的耗时和令牌数，与完成条件一起记录。
4. pass@k 与 pass^k：找到一次答案，和每次都成功
某个任务运行三次，结果是成功、失败、成功。这个智能体能做成任务，但它的服务是否足够稳定，还需要另一个问题来衡量。
pass@k问：k 次尝试里，至少一次成功的概率是多少？
pass^k问：k 次尝试，全部成功的概率是多少？τ-bench 用后一指标研究重复运行的一致性。[2, §3] HumanEval 的官方实现提供了 pass@k 的有限样本估计。[10]
图 3｜同一组运行结果可以回答不同问题。“独立尝试”要求每轮按协议重置；中央表示收集与统计过程，不表示后一次尝试继承前一次的答案。候选选择是产品实现需要额外解决的问题。指标定义参考文献 [2]、[10]，布局为原创。
先看一个理想化例子
设单个任务每次成功概率固定为 p，k 次尝试独立且同分布，则：
pass@k = 1 − (1 − p)ᵏ，pass^k = pᵏ。
令 p = 0.75，得到下表。数字由公式计算，是教学示例，未测量任何模型。
| 尝试次数 k | 至少一次成功：pass@k | 全部成功：pass^k |
|---|---|---|
| 1 | 75.00% | 75.00% |
| 3 | 98.44% | 42.19% |
| 5 | 99.90% | 23.73% |
| 10 | 约 100.00% | 5.63% |
“约 100.00%”只是显示精度下的四舍五入。随着 k 增大，一个指标更容易达标，另一个更难达标。只有在这个单任务、固定 p 的假设下，才可以直接用上述幂次计算。
若某些任务总能成功、另一些从不成功，平均 pass@1 也可能是 75%。这时增加尝试，并不会让整体 pass@k 像表中那样上升。不同任务应先分别统计，再按约定口径汇总；不能先取整体平均 p，再套非线性公式。
有限次运行，怎样估计？
对于同一任务，设已运行 n 次，其中 c 次成功，且 1 ≤ k ≤ n。用 C(a, k) 表示从 a 个元素里选出 k 个的组合数；当 a < k 时取零。
pass@k 的估计 = 1 − C(n − c, k) / C(n, k)。
pass^k 的估计 = C(c, k) / C(n, k)。
第一式排除“挑出的 k 次全部失败”，第二式计算“挑出的 k 次全部成功”。在独立同分布的采样假设下，它们是相应概率的无偏估计。[2][10]
例如 n = 4、c = 3、k = 2，共有六种两次尝试的组合。每一组至少有一次成功，所以 pass@2 的估计为 100%；只有三组全部成功，所以 pass^2 的估计为 50%。它与直接代入(3/4)² = 56.25%不同。配套计算脚本给出了这个例子与上表。
估计值不是精确的未来成功率。运行次数少时，应一并报告任务数、每任务的 n 与 c，以及估计的不确定性，避免让一个显示为100%的数值承诺超出证据的可靠性。
还要区分统计指标与产品交付。pass@k 很高，只说明候选中可能有正确解；产品仍需可靠验证器选出它，并支付额外计算成本。pass^k 则衡量对同一底层任务的重复表现，不等于连续业务流程中 k 个不同步骤都成功。共享缓存、前次答案或一起发生的工具故障，会破坏独立性假设。
5. 任务质量：先确保题目和判卷标准一致
一个低分可能来自三处：系统不会做，题目没有讲清楚，或者评分器拒绝了合法结果。需要通过可复查的证据把它们分开。
假设任务要求“写一个解析脚本”，评分器却只在一个未告知的固定路径下找文件。智能体把脚本写到了另一个合理位置，失败是规格与验证不一致造成的。若路径很重要，应写进任务；若不重要，评分器应按合理方式发现产物。
给每个任务准备一个能通过的参考解
参考解的作用是验证题目可完成、环境能运行、评分器能接受正确产物。它不要求智能体复制同一条工具路径。Harbor 的任务结构将参考解决方案、环境与测试分开保存，适合把这些检查变成可重复运行的资产。[11]
本例可以同时准备四类参考结果：合法退款、正确拒绝、证据不足时请求补充、执行失败后准确说明。它们都是合理业务行为，是否算“成功”取决于各自的任务定义；不能把全部任务都设成必须退款。
正例与反例要一起设计
只测试“需要检索时是否检索”，无法惩罚不必要的搜索。本文建议以同一业务边界成对构造用例：应退款与不应退款，应继续自动执行与应请求确认，证据足够与证据不足。
| 检查维度 | 正例 | 反例揭示的问题 |
|---|---|---|
| 触发行为 | 满足条件时执行退款 | 不满足条件时仍执行，说明过度触发 |
| 用户授权 | 明确确认后操作 | 模糊回应被当成确认 |
| 幂等与重复 | 一次请求只产生一笔有效退款 | 重试导致重复支付 |
| 结果说明 | 根据真实返回解释结果 | 工具失败后仍声称已完成 |
Anthropic 给出的早期起步建议是从20–50 个真实失败相关任务开始；大量尝试仍为零分时，应检查任务和评分器。[1] 这不是所有阶段都足够的样本量，也不是“零分必然是假题”。接近版本选择时，要看任务覆盖、效果大小和运行方差，小幅提升尤其需要更多证据。
不能只积累失败：保留典型成功场景，才能知道修复某个难例是否破坏了其他行为。难例集用于暴露边界，代表真实流量的集合用于估计产品表现，两者应有不同标签和汇总口径。
6. 环境与评分：防止测量本身制造假象
一次尝试结束后，工作目录、数据库、会话记忆和缓存都可能变化。下一次运行若继续读取它们，测到的就可能是“上一轮留下的帮助”，而不是规定起点下的能力。
在本文的退款示例中，第二轮读取第一轮已经完成的退款记录，就可能不需要再执行任何动作。若任务仍被算作从零处理成功，指标会虚高。反过来，多轮共用限额和资源，也可能制造一批相关失败。
**应固定并记录模型版本、运行框架、提示与规则版本、工具权限、初始状态、预算、评分标准，以及外部服务的状态。**比较两版模型时，尽量让其他条件一致；改变运行框架时，固定模型。否则分数变化很难归因。
隔离运行，还要保护裁判
智能体可以编辑项目文件，不代表它应能修改隐藏评分器或权威业务账本。本文建议把被测产物与评分依据分开管理，并记录被评分的确切版本。
Harbor 官方文档提供可选的独立验证环境；默认验证器仍在共享容器中运行，分离需要显式配置。[12] 分离环境也不自动等于安全或正确：哪些产物被传入、验证器读取什么、数据是否完整，仍要检查。
某个失败来自工具服务不可用，不能悄悄丢掉；某个智能体导致环境异常，也不能自动算作基础设施故障。可以单列原因，并在报告中说明重跑和剔除规则。规则应在比较前固定，避免分数因选择性过滤而改变。
看轨迹时，先定位证据断在哪里
对于退款失败，依次问：用户请求是否理解正确？读取了哪一版规则？工具参数是否对应目标订单？返回是成功、失败还是超时？最终状态与返回是否一致？回复有没有越过证据作承诺？
这些问题分别指向意图、信息、决策、执行、验证与表达。只把失败写成“推理不够”，无法知道该改数据、工具还是运行框架。评分结果也应保留具体失败断言，方便在标准更新后重新评分。
7. 能力集与回归集：给不同阶段留下信号
能力评测用于暴露系统还做不好的工作；回归评测用于守住已承诺的行为。原文强调两者应分开，成熟的能力任务可以转入回归集。[1]
以退款系统为例，常规单订单处理已经稳定后，继续只测这类任务，分数可能接近满分。下一版更擅长理解复杂请求，也未必能在这套集合上表现出来。可以保留常规集，再添加多订单、信息冲突、需要用户协作或恢复工具异常的任务。
| 评测集 | 本文示例 | 主要使用方式 |
|---|---|---|
| 能力探索集 | 多个请求交织，部分信息要澄清 | 比较新方案，并读取失败轨迹寻找边界 |
| 回归保护集 | 常规退款、正确拒绝、重复申请 | 检查修改有没有破坏稳定行为 |
| 保留验证集 | 未用于反复改提示的独立任务 | 降低反复调同一批题造成的过拟合 |
能力集接近满分，应增加能区分新能力的任务；旧题不必删除，仍可保留为回归保护。任务、规则和评分器版本一旦变化，旧分数与新分数也不能直接混用。LangSmith 的文档支持数据集分组和版本管理，为这种组织提供了具体工具。[3]
从第一批任务，到持续维护
下面是本文将前述原则落成的一份执行顺序。它是可调整的工程安排，不是任何框架的必填规范。
- 收集现有人工检查、用户反馈和失败轨迹，按影响整理第一批任务。
- 写清输入、成功条件、参考解，补上行为不该触发的反例。
- 固定运行配置，重置环境，选择并验证评分器。
- 多次运行，保留分维度结果、预算与失败原因。
- 人工阅读代表性轨迹，检查误判与不公平失败。
- 把修复后的用例转为回归保护；当能力集饱和时扩展难度。
- 明确基础设施、业务用例和规则版本的维护负责人，保留独立验证集。
图 4｜本文建议的评测维护流程。它连接线上反馈、离线比较与人工复核；发布复核后的反馈可以继续补充用例。两侧卡片表示各阶段的检查职责，连线不表示已经自动解决这些问题。参考文献 [3]、[13]，流程与布局为原创。
8. 离线分数之外，还缺哪些证据？
固定任务集便于比较版本，却不可能预先包含所有用户行为。LangSmith 和 Langfuse 都将离线实验与线上运行评分作为互补工作流。[3][13] 实际设计中，还可以结合以下观察方式：
| 方式 | 在示例产品中回答什么 | 解释时的边界 |
|---|---|---|
| 自动离线评测 | 新版本在同一批退款任务上是否改善 | 用例覆盖不足时，结果不能代表所有用户 |
| 生产监控 | 工具错误、耗时或任务分布是否发生变化 | 指标异常帮助发现问题，但未必直接指出原因 |
| A/B 测试 | 新版本是否改善真实任务完成和用户体验 | 需要明确实验单位、流量与统计方案 |
| 用户反馈 | 哪些失败是设计时没有想到的 | 主动反馈的人群和场景可能有选择偏差 |
| 人工轨迹复查 | 系统为什么成功或失败，评分是否公平 | 少量案例解释机制，不能直接给出整体发生率 |
| 系统化人工评价 | 开放质量标准能否得到稳定共识 | 应记录评审标准、分歧与裁决方式 |
有反馈就立即改提示，可能只修好一个场景。更有用的动作，是把它变成可复现的任务，说明它为何失败，比较改动前后，并检查相关回归用例。离线改进后，再用合适的线上证据验证影响；线上分数上升，也需要排查任务分布是否变了。
9. 一份小示例：为什么“只看状态”会漏判？
配套素材提供了一段可直接运行的 Python 评分演示。它没有调用真实模型，而是检查八条手工构造的轨迹与结果。目标订单为R-017，授权退款 80 元；每条记录都明确标注为合成示例。
| 合成情况 | 只检查最终结果 | 加入授权与一致性检查后 |
|---|---|---|
| 得到有效确认，正确退款 | 通过 | 通过 |
| 回复称已完成，实际无退款 | 失败 | 失败 |
| 正确退款，但未经确认 | 通过 | 失败 |
| 退款后才获得确认 | 通过 | 失败 |
| 正确退款，但回复称没有退款 | 通过 | 失败 |
| 金额错误、重复退款或对象错误 | 失败 | 失败 |
“只看结果”的评分接受了四条，“组合评分”仅接受一条。这个差异是我们刻意构造的，用来展示漏判机制；不能把 4/8 或 1/8 当作真实 Agent 的成功率，也没有验证模型评分器在自然语言授权识别上的效果。
演示只规定必要关系：有效确认必须早于退款事件。它允许额外的只读查询，并未锁死完整工具调用顺序。完整程序、输入和实际运行输出都保存在素材包中。
框架解决执行，任务定义决定测量价值
选择工具时，可以按现有系统缺口比较，而不必先追求功能最多的平台。下表依据各自官方页面整理，不包含价格比较或性能排名。
| 工具 | 官方文档中可用于评测的部分 | 采用前先明确什么 |
|---|---|---|
| Harbor | 任务环境、参考解、验证器与尝试执行 [11][12] | 是否需要可控环境，产物怎样交给验证器 |
| LangSmith | 数据集、实验、代码/模型/人工评分与线上评测 [3] | 怎样接入现有轨迹，怎样固定数据集版本 |
| Langfuse | 轨迹评分、数据集实验与人工校准 [13] | 哪些线上记录进入离线用例 |
| Braintrust | 轨迹、数据集实验与评分工作流 [14] | 是否要统一实验与生产问题分析 |
| Phoenix | 轨迹、评价、数据集与实验 [15] | 已有观测数据与评价标准如何复用 |
回到开头的退款任务，一份可靠的评测报告应让我们看到：目标是否实现，必要规则是否遵守，重复运行怎样变化，成本是什么，以及失败能否被公平地解释。没有这些证据，“看起来更好”很难转化成可验证的产品改进。
参考文献
- Grace, M., Hadfield, J., Olivares, R., De Jonghe, J.Demystifying evals for AI agents.Anthropic 原文，2026-01-09。本文的问题起点与补充阅读入口；本文为独立中文技术解读，未逐段翻译。
- Yao 等。τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains.arXiv:2406.12045v1，2024。核对 §3 的奖励条件、过程规则限制与 pass^k、pass@k 估计式。
- LangChain。Evaluation concepts / LangSmith Evaluation.评价概念、工作流。核对评分方式、实验、数据集与线上/离线评价。
- Zheng 等。Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.arXiv:2306.05685，2023。摘要用于核对评分偏差类型，不用于推断本文示例的准确率。
- SWE-bench。Evaluation guide.官方文档。核对运行环境、执行验证与结果报告。
- Barres 等。τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment.arXiv:2506.07982v1，2025。摘要用于核对双控制与用户协作的任务范围。
- BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents.arXiv:2504.12516，2025。摘要用于核对查找难、验证相对容易的基准定位。
- Zhou 等。WebArena: A Realistic Web Environment for Building Autonomous Agents.arXiv:2307.13854，2023。摘要用于核对功能性网页任务评价。
- Xie 等。OSWorld.原版项目页面。核对初始化与执行验证思路；页面已提示后续版本，本文不提供最新榜单比较。
- Chen 等。Evaluating Large Language Models Trained on Code.HumanEval 论文，2021；官方评价实现。pass@k 估计按官方实现核对，未复现模型实验。
- Harbor。Tasks overview.官方文档。核对任务结构、参考解决方案、试验和验证脚本。
- Harbor。Separate verifier.官方文档。核对默认共享与可选独立验证环境。
- Langfuse。Evaluation overview.官方文档。核对线上评分、离线实验与人工校准入口。
- Braintrust。Observability and evals.官方页面。仅核对轨迹、数据集、评分和实验工作流。
- Arize。What is Arize Phoenix?官方文档。核对观测、评价与数据集实验功能。
