AgentWork：借鉴 APEX-Agents 的多任务评测平台思路

状态：RFC / 产品与研究设计，尚非已实现功能。 版本 0.1；资料核验日期：2026-10-16。
定位：一个跨领域的 Agent 工作评测平台，而不是租房助手。 租房只是 Personal Services 中的一个任务族。
本文区分外部已核验事实、我们建议采用的设计，以及当前代码实际具备的能力。没有导入 APEX 数据、没有运行 APEX 评测，也没有替用户接受其访问条件。

0. 一页结论

我们要做的是：用户提出不同类型的工作，Agent 进入相应工作区执行；网站展示交付物、操作证据和验收结果，让人判断它是否真正完成了工作。

三个参考对象解决三个不同问题：APEX-Agents 提供项目世界与任务构造的参考；SWE-bench 提供可复现执行及检验的参考；Design Arena 提供多类别入口与比较体验的参考。它们不是三个名称拼接后就自动构成研究创新。[1][2][4][5]

本项目采用以下方向：

最小产品不是“5 个租房关卡”，而是共享评测底座下的多个真实工作类型。 但不要为了首页热闹，就把没有运行器和验收器的类别标成可评测。

1. 从 APEX-Agents 借鉴什么

1.1 已核验的设计事实

以下是公开资料的简要核验，不是对受限数据文件的检查。

依据：数据卡、论文第 3–4 节及表 1。[1][2]

两个重要限定：发布博客的“Pass@1 不到 25%、Pass@8 最好 40%”属于发布时的结果，不作为今天的排行榜描述。[3] 同时，论文描述的主评分 judge 读取输出及变更信息，而不读取完整执行轨迹；我们不能据此声称 APEX 不记录轨迹。[2]

1.2 借鉴方法，而不是照搬题目

第一，项目先于题目。 先让一个工作区里的材料、时间线、角色职责彼此一致，再定义需要完成的工作。不要先让模型写一道难题，再堆 200 个不相关文件制造“长上下文”。

第二，参考交付物不是唯一表述。 Gold output 用来验证题意是否可完成、标准是否合理；评分应允许不同排版、措辞和多种有效解，不能要求和参考答案逐字相同。

第三，任务作者与验收者分离。 原作者知道文件在哪，不代表陌生执行者能够发现。我们需要独立完成任务的人，检查材料是否充分、工具是否可用、成功条件是否可观察。

第四，评分对象必须明确。 任务让 Agent 更新工作簿，就检验修改后的工作簿；让它发送邮件，就检查发送系统状态；让它提交分析结论，则检查结论、数值与证据。不能只读最后一句“已完成”。

1.3 基础设施的可借鉴边界

Mercor 的 Archipelago 将环境、Agent 运行器、评分服务分离，使用容器、MCP 接口及执行前后快照。公开仓库列出 Apache-2.0 代码许可；这与 APEX 数据的使用条件不是一回事。[6]

建议先做兼容性评估，而不是直接 fork 后宣布平台完成。 检查我们需要的虚拟时钟、第三方状态机、权限事件、重放记录和交付物校验是否能够接入。能复用的组件保留归属及许可，必须新增的模块单独维护。

2. 我们的定位与差异化

2.1 产品定位

工作名称继续使用 AgentWork。面向三个群体：想选工具的用户、开发 Agent 的团队、研究可靠性的评测者。

用户问题不是“哪个模型总分最高”，而是：

对我的这类工作，在这些工具、权限、预算和时间限制下，哪个 Agent 能给出可以接受的交付物，并且没有谎报完成或越权操作？

平台不承诺所有任务都具有同一种 oracle。它承诺：每种任务公开说明如何验收、证据在哪、评分的限制是什么。

2.2 不能继续声称的创新点

依据各项目公开说明。[1][4][5][7][8] 这是有针对性的初步对照，不是穷尽式文献综述。

2.3 值得验证的研究命题

我们建议检验的不是“更多类别一定更好”，而是：

当任务要求 Agent 在变化的工作区里维持事实、约束、行动状态和交付物的一致性时，单看最终答案会漏掉多少重要失败？这些失败能否跨领域重复测量？

可操作的研究问题包括：

• 一个选择在发布时正确，后来证据变化，Agent 会不会更新受影响的表格、邮件和最终建议？
• 工具超时后，Agent 能否区分“确认未执行”与“执行结果未知”，避免漏执行或重复提交？
• 看似合格的最终交付物，需要多少次用户纠错才能得到？
• 同一 Agent 在采购、调研和办公中，是否复现相同的证据归因或假完成错误？

这是待检验的研究定位，不是已证明的独家贡献。若与现有工作高度重叠，应把贡献收窄到跨领域测量、数据质量与评测可靠性，而不是换名包装。

3. 多任务目录：Domain、Workflow、Artifact 三个轴

3.1 不按“租房问题变体”充当多领域

任务至少有三个正交标签：

• Domain：在哪个领域工作。 如研究、采购、旅行、办公协调、数据分析、个人事务。
• Workflow：需要做什么。 如检索与核验、比较与推荐、编辑与交付、沟通与协调、监控与更新。
• Artifact：最后交付什么。 如简报、工作簿、日程、邮件状态、网站或演示文稿。

“PDF”“Excel”“邮件”是工具或输出形式，不应被当作三个职业世界。“停车候补”“隐藏费用”“资格不符”是租房任务的机制变体，不应被计为三个领域。

3.2 首批六个领域的建议任务

下表是任务开发计划，未表示已经实现。

这些任务不能全变成“挑最便宜的三个商品”。必须包含信息综合、修改现有产物、安排事件、提交获授权行动等不同终止状态。

软件开发、设计创作、金融和法律可进入扩展目录，但待相应环境和专家验收完成后再进正式榜。职业题的难度不等于质量；第一版不需要假装拥有金融或法律专家验证。

3.3 数据规模与切分建议

先做 18 个开发试点：6 个领域 × 1 个 world × 3 个任务。 这批用于验证工具、任务契约和评分，不进入隐藏测试集。

通过试点后，目标为 120 个独立任务：6 个领域 × 4 个新 worlds × 5 个任务。每个领域 1 个 world 做公开开发，3 个 worlds 做受控评测，即 30 个开发任务与 90 个评测任务。

这是规划规模，不是当前数据规模。不同随机种子、预算变体和同题多次运行不计作新增独立任务。切分按 world 及共享实体/模板族进行；不能让同一邮件库的不同问题同时出现在开发与测试两侧。

4. World：有一致状态的项目，而不是文件袋

一个 world 包含：角色、初始事实、文件版本、工具可见范围、外部参与者、可执行动作、事件规则、权限及可接受终态。

建议采用以下目录，但带 private 的内容只存在评测服务器，不进入公开仓库或前端 bundle：

worlds/procurement_launch_04/
  manifest.yaml                 # 版本、应用、资产哈希、时间设置
  public/
    project_brief.md
    files/                      # 报价、会议纪要、历史订单
    mail_seed.json              # 初始可见邮件
    calendar_seed.json
  private/                      # evaluator-only，禁止打包给 Agent
    canonical_state.json
    actor_rules.yaml
    event_rules.yaml
  tasks/
    compare_suppliers/task.yaml
    revise_order/task.yaml
    prepare_handoff/task.yaml
  evaluation/                   # 服务端验收；公开开发 world 可另行公开
    rubrics/
    reference_outputs/
    tests/

4.1 三种世界要区分

不能为了可复现性把所有事件写成不响应 Agent 行为的影片。供应商只有收到有效询价才应回复；报价是否包含安装费，应取决于实际条款及问题，而不是看到了某个魔法关键词就奖励 Agent。

对同一任务比较两个 Agent 时，分别克隆世界。共享外生条件和随机化协议，不共享可写数据库、邮件线程或库存。事件时间由虚拟时钟和行动触发规则决定，模型响应速度不应偷偷改变模拟任务难度。

4.2 可观测性底线

评测器知道真相，不代表 Agent 能知道。每个必须判断的事实都要有可达的证据路径；不可获取的信息不能被设为必须猜中的隐藏要求。

不确定性本身可以成为正确答案。例如没有可验证车位时，允许“暂无可确认选项，说明缺口并按任务要求继续或终止”，而非强迫推荐。只有任务本身要求且条件支持时，才将未做选择计为失败。

5. 统一任务契约与验收

5.1 每个 task 的必需字段

任务契约的示例（原创方案，不是从 APEX 复制的样本）：

task_id: procurement.compare-implementation-partners.v1
world_ref: vendor-launch-04@1.0.0
domain: procurement
workflow: compare-and-recommend
artifact_types: [spreadsheet, memo]
mode: interactive-world
prompt: >
  Compare implementation partners for the project.
  Include one-time and recurring charges, confirm delivery dates,
  and prepare a recommendation. Do not place an order.
visible_constraints:
  first_year_budget_usd: 24000
  required_delivery_date: '2027-03-15'
  mandatory_features: [data_export, audit_log]
allowed_actions: [files.read, files.write, mail.read, mail.send_inquiry]
forbidden_actions: [orders.submit, payments.charge, files.delete_source]
expected_deliverables:
  - {path: /deliverables/vendor_comparison.xlsx, must_open: true}
  - {path: /deliverables/recommendation.md, must_cite: true}
clock_policy: action-triggered-virtual-time-v1
limits: {tool_calls: 160, virtual_days: 5, wall_minutes: 25}
grading_contract_ref: evaluator://procurement-comparison-v1

示例阈值是待试点校准的工程参数，不是已证实合理的标准。时限和费用上限应对所有参赛者公开，并在运行前固定。

5.2 三层验收，而非一个万能 LLM judge

程序验收： 预算计算、时区转换、日历冲突、文件存在与打开、单元格公式、消息去重、收件人和提交状态。可精确判断的事实优先用程序。

语义标准验收： 是否回答了任务的关键问题、对条款的解释是否受来源支持、是否遗漏重大风险。明确每条 criterion 的输入对象、支持证据、失败例和允许变体。LLM judge 的分数需要独立人工标注校准，且记录模型、提示词和版本。

偏好评价： 清晰度、易用性、设计感、表达质量。盲评优先比较产物，轨迹是否展示作为独立实验设置；不要先展示谁“通过了”再让人投票。

不规定标准操作路径。Agent 通过不同但合法的方法完成任务也应该通过。只有任务明确要求证据来源、审批或特定系统状态时，才把对应过程设成必要条件。

6. 一个不依赖租房的完整例子

企业服务采购：三个报价，两个版本，一次延迟回复

以下公司、数据和规则均为原创合成示例。

用户要求比较三家实施服务商：第一年总支出不超过 24,000 美元，3 月 15 日前上线，必须有数据导出与审计日志。允许询价和生成采购建议，不允许签约下单。

Agent 需要找到报价版本、问清缺项、等待 Cedar 回答、修订工作簿并给出有条件的推荐。不能因 Cedar 不回复就假设原价有效，也不能因 Aster 宣传月费最低就选它。

验收不是要求一定推荐 Birch。 如果世界后续为 Cedar 提供另一份合格报价，多种推荐可以成立；只要满足硬条件、正确计算并解释偏好。若要测最优性，必须事先定义公开的目标函数，而不是让作者事后挑喜欢的供应商。

核心必要标准：第一年成本口径正确；使用有效报价及交期；满足强制功能；交付表格与 memo 一致；引用正确文档；未越权下单。

过程诊断另行记录：是否重复询价、是否误称发送成功、是否在新报价出现后保留了旧数字、是否需要用户指出错误。一个简短而正确的过程不能因为工具调用少而被扣分。

这一个 world 可以派生“首次比较”“报价更新后修订”“准备项目交接”三个任务；每个独立评测任务从自己的指定快照开始，不继承上一名 Agent 的改动。

7. 评分与排行榜协议

7.1 主榜：可验证完成率

每次运行的严格成功定义为：

success = required_deliverables_valid
          AND all_required_task_criteria_pass
          AND no_critical_authorization_violation

同时报告逐条标准通过率，避免全或无评分失去诊断能力。不得用漂亮排版抵消超预算、错误收件人或未经批准的提交。

单次任务成功与跨任务汇总分开。按任务等权计算域内成功率，再报告各域结果；跨域主分数按预先公开的权重汇总。需要按 world 聚类估计不确定性，避免同一世界的相似任务被当成独立样本。

7.2 不混在一个总分里的指标

预算统计使用运行时锁定的价格版本，缓存、工具和模型成本分别记录。缺失项显示 unknown，不填 0。

7.3 三张榜与两个接入轨道

Verified Results： 受控世界、服务端验收、固定任务版本。

Arena Preference： 匿名成对比较，记录相同任务、左右位置随机化、投票数量与不确定性。不把真人偏好自动解释成可靠性。

Efficiency： 在给定质量或成功率门槛下比较费用和时效；不奖励低成本但未完成的运行。

另分 标准 Harness 轨道 与 自带 Agent 轨道。模型名不足以定义参赛项，需要保存模型快照、Harness 提交、工具协议、资源上限及重试策略。跨轨道不能混榜。

人工救援允许的轨道与完全自主轨道分别发布。Pass@k 的“多次至少一次成功”不是部署时的成功率；不能后台挑最佳结果再标成单次表现。

8. Trace：一等数据，而不是 UI 动画

8.1 记录可观察行为，不编造内部思维

正式记录由工具网关生成，而不是要求 Agent 自己总结“我做了什么”。至少保存：

{
  "run_id": "run_example",
  "event_id": "evt_017",
  "sequence": 17,
  "world_version": "vendor-launch-04@1.0.0",
  "actor": "agent",
  "tool": "mail.send_inquiry",
  "request_id": "request_12",
  "idempotency_key": "vendor-b-inquiry-v1",
  "wall_time": "2027-03-01T10:00:00Z",
  "virtual_time": "2027-03-01T09:00:00Z",
  "input_ref": "private-object://run_example/evt_017/input.json",
  "output_ref": "private-object://run_example/evt_017/output.json",
  "status": "accepted",
  "effect_ids": ["mail_007"],
  "evidence_refs": [],
  "state_before_hash": "<hash>",
  "state_after_hash": "<hash>",
  "usage": {"model_tokens": null, "tool_cost_usd": null},
  "provenance": "gateway-captured"
}

accepted、delivered、replied 分别记录。“请求报错”也不总能推出“对方没收到”；工具应显式返回 unknown 状态，并提供查询及幂等恢复路径。客户端数据只是显示层，不是成绩权威来源。

只记录工具调用、返回、公开消息及供应商确实暴露的元数据。不要求或补造模型隐藏思维链。用户上传的源材料、密钥、联系方式与未授权正文不能进入公开轨迹。

8.2 历史对话不能冒充完整执行记录

原始事件日志、事后重建、演示合成必须明确标注：gateway-captured、reconstructed、synthetic-demo。没有原始搜索结果时显示缺失，不能根据最后答案编造过去的工具响应。

对价格争议应分别标注：基础金额读错、房号配错、费用范围混淆、算术错误、证据归因错误、表达歧义。不能因为用户说“价格错了”，就将算式正确的例子硬标成 arithmetic error。 有争议的标签保留审核状态及依据。

原始记录追加保存，错误标注另外存储并版本化。纠错不能擦掉先前失败。公开前先去标识化，再检查重识别风险；真实邮件全文和用户资料默认不进入这个公共仓库。

9. 网站应该长什么样

9.1 首页：通用入口，不是租房表单

参考 Design Arena 的多类别入口，但围绕工作而非仅围绕创作媒介组织。[5]

AgentWork

What do you want to get done?
[ Describe a task, or choose a benchmark below... ]

Research   Procurement   Travel   Office   Data   Personal Services

[Compare vendors] [Audit a spreadsheet] [Plan an offsite]
[Research a market] [Coordinate interviews] [Find an apartment]

通用部分只有任务描述、任务/世界选择、轨道、允许工具和资源上限。金额、出发日期、租房面积、停车、数据列、时区等由 TaskSpec 动态加载。租房字段只能在租房场景里出现。

自由输入有两种用途： 已注册任务加载受控评测；新任务作为 workspace draft 保存。未经过环境构建和 rubric 审核的自由 Prompt 不能一键变成官方 benchmark，也不能在没有模型接入时显示“Agent 正在理解任务”。

9.2 页面与跨领域呈现

交付物预览使用类型插件：工作簿展示关键单元格与公式；报告展示正文与引用；日历展示时间差异；网站展示沙箱预览；操作任务展示应用状态 diff。不是每个领域重新复制一个页面。

9.3 任务成熟度必须可见

采用互不混淆的标识：Concept → Runnable Demo → Reviewed Dev Task → Verified Evaluation。允许一个漂亮的多任务目录中同时存在这些状态，但不能把 Concept 算进可评测任务数。

视觉上保留当前米白、橙色、侧边栏和留白的设计方向；修改的是信息结构与通用组件，而不是又换一套配色。默认首页应同时露出多个领域的任务示例，租房不占据唯一主视觉。

10. 当前仓库与必须完成的迁移

检查基线：BaikunLeng/baikunleng.github.io 的提交 4d6c896df0668b4055abdef05bf0d11c3a49628e。[9]

当前不是已经支持六个领域，也不是已经接入 APEX。 本次思路文档本身不改变上述实现状态。

建议后续代码布局：

agentwork-bench/
  index.html
  styles.css
  app.js                       # 前端入口逐步变薄
  docs/
  catalog/                     # 公开领域、任务元数据；不含隐藏答案
  viewers/                     # 表格、文档、网站、状态变化
  api-contracts/

# 以下为未来评测服务，不随 GitHub Pages 发布私密内容
services/
  gateway/                     # 工具访问、权限、审计与隔离
  runner/                      # 模型/Harness adapters
  worlds/                      # 重置、事件、快照
  graders/                     # 程序与语义验收
  registry/                    # 版本、任务、运行、评分

正式评测后端需要独立运行环境；不要为了让 GitHub Pages 看起来“全栈”而把隐藏状态、grader 答案或模型密钥写进 JavaScript。对开放 Agent 容器按不可信代码处理：限制网络、文件和资源访问，禁止读取 grader、其他运行及服务端凭据。

11. 实施顺序与发布门槛

这是建议里程碑，不是工期承诺。

11.1 如何检验 benchmark 自己

不只测 Agent，也要测任务和评分器。人为构造错误解：漏计固定费用、错误日期、错误文件版本、重复发送、未获授权执行、损坏的工作簿、引用不支持结论。检查每种错误能否被对应标准捕捉。

也要构造正确但不同的解：不同工具路径、等价计算、替代可行方案、合理弃答。防止 grader 只奖励作者写出的答案。

每域抽取独立人工执行样本，记录完成时间与争议；对关键条件和模型 judge 的 false positive 单独审核。指标不稳定时暂缓排名，而不是用更多小数位掩盖问题。

11.2 预算估算方式

先做小样本试跑，再定规模：

评测预算 = 独立任务数 × Agent配置数 × 重复数 × 平均每次运行成本
          + grader成本 + 环境成本 + 人工审查成本

例如规划的 120 题、4 个 Agent 配置、每题 3 次，是 1,440 次运行；这只是工作量算式，不是已发生实验。API 单价、等待策略和输出大小未试跑前，不给“几百美元肯定能做完”的承诺。

12. 数据许可、公开范围与下一次评审

APEX 数据卡既标注 CC-BY 4.0，也明确给出 evaluation-only、禁止训练/微调/参数拟合及抓取的使用限制，并要求访问者接受条件和共享联系信息。[1] 我们不自行把其中一个标签解释为豁免另一组限制。 转载、托管或自动化评测其数据前，取得适用授权或向作者确认。本项目当前只参考公开说明，不下载受限文件，不将 APEX 题目、gold outputs 或 worlds 纳入自己的数据。

Archipelago 的代码许可单独核验并遵守。[6] 采用其代码不等于获得 APEX 数据的再分发权。我们的原创数据将单独制定公开开发和受控评测的条款。

真实对话和真实邮件默认只作为私有案例研究素材。公开任务使用原创合成身份、材料与规则；没有完整原始轨迹的历史事件只标记为重建，不伪装成逐步精确重放。

下次评审需要回答四件事：

1. 六个领域是否都有足够真实、可验收且非换皮的任务？
2. 首个非租房 world 是采购、办公协调还是数据交付，哪个最能检验共享底座？
3. Archipelago 哪些组件可复用，哪些关键机制需自己实现？
4. 选用何种工具协议、Agent 配置和预算，才能做公平的第一轮试点？

建议先做“企业服务采购”与“月度数据交付”两个非租房 worlds：前者验证沟通、时序和决策；后者验证真实文件产物。 不是在首页加两个标签，而是让它们拥有不同的状态、工具效果和验收目标。其余领域在同一任务契约下推进。

参考资料与核验边界

下列为本次实际查阅的官方说明、论文和项目代码。没有开展完整竞争格局调查，也没有重新跑任何外部 benchmark。

[1] Mercor APEX-Agents 数据卡：规模、任务结构、评测用途、访问与使用限制。公开卡片可读；受限任务文件未访问。

[2] APEX-Agents 论文，arXiv:2601.14242v3：第 3 节的 worlds、tasks、rubrics、输出形式；第 4 节的 judge 输入与成功率定义。表 1 及评分页已对照版面。

[3] Mercor：Introducing APEX-Agents（2026-01-21）：发布时定位、构造方法及结果；不当作当前模型排名。

[4] SWE-bench 官方文档：真实软件问题、容器化执行与可复现评测。

[5] Design Arena：多类别创作入口与类别化榜单。本文借鉴入口组织，不声称复现其完整产品或排名方法。

[6] Mercor-Intelligence / Archipelago：环境、运行器、评分、快照与代码许可；本轮未集成代码。

[7] τ²-bench，arXiv:2506.07982：用户与 Agent 共同操作环境的评测。

[8] SentinelBench，arXiv:2606.05342v2：时间演化、事件监控、响应与资源使用，约束本项目的创新性表述。

[9] 当前实现基线：app.js；index.html。对实现状态的描述绑定此提交，后续代码变更需同步修订。