flyP 精读与批判 · AgencyBench（v2 重写覆盖）

  • 日期：2026-10-08（承接 2026-10-07 初稿并覆盖重写）
  • 论文：AgencyBench: Benchmarking the Frontiers of Autonomous Agents in 1M-Token Real-World Contexts
  • arXiv：https://arxiv.org/abs/2601.11044（v4，2026-04-23）
  • 标签：agent-evaluation long-context rubric docker-sandbox user-simulation
  • 事实边界：本稿依据论文公开 abstract/HTML、公开项目材料线索与初稿中可核信息整理；未下载 PDF、未运行代码、未复跑 benchmark。凡 HTML/正文未闭合的细节，均明确列为待核实，不把推断冒充实验事实。

1. 一句话结论

AgencyBench 的真正价值不是“把上下文拉到 1M token”，而是把 Agent 评测从静态问答改成真实任务闭环：Agent 在 Docker 沙箱里与 user simulator 迭代交互，执行几十到上百次工具调用，最后按功能与视觉产物 rubric 评分。这个改动提高了生态相关性，也带来更严重的 simulator bias、评分者偏差、复现成本和版本污染风险。

2. 核心贡献与准确边界

2.1 任务层：长程日常任务，而非单轮 needle retrieval

公开信息显示，基准覆盖 32 个场景、138 个任务，平均每题约 90 次工具调用、约 1M token、数小时时长。任务从常见 AI 使用场景反推，不以合成 needle 或短问答为主。

这使它比 LongBench / NIAH 更接近“长程 Agent 能力”：考察计划、工具选择、状态维护、反馈修正和交付物生成，而非仅考察能否从长文本找回一个字符串。

2.2 评测层：闭环 sandbox + 双 rubric

公开材料显示评测闭环由三部分组成：

  1. user simulation：模拟用户给出目标、补充信息、纠正偏差；
  2. Docker sandbox：隔离工具执行并留下日志；
  3. 视觉 / 功能 rubric：同时评“交付物看起来是否合格”和“功能状态是否达到目标”。

这一步很重要。只看最终文本会漏掉工具副作用，只看状态通过又可能漏掉视觉呈现。双 rubric 是该基准相对多数工具 Agent benchmark 的主要差异。

2.3 对比层：模型 × scaffold，而不是模型单打独斗

公开结果报告闭源 Agent 总体约 48.4%，开源约 32.1%；同一模型换 scaffold 也会显著变化。这个结果不能直接解释成“闭源模型能力高 16.3 个百分点”，更稳妥的说法是：

在该任务集、工具栈、提示词、预算和 rubric 下，闭源与开源完整 Agent 配置出现明显差距。

模型、harness、工具权限、重试策略和 judge 共同构成被测对象，单独归因给底座模型是不严谨的。

3. 方法拆解

3.1 任务来源与样本量

日常任务反推比模板生成更接近真实使用，但 138 题远小于大模型预训练语料规模。由此产生三重限制：

  • 场景覆盖看起来广，统计功效未必强；
  • 任务族之间可能高度相关，不能把 138 当作 138 个独立同分布样本；
  • 长期公开 benchmark 容易被模型训练数据、prompt 模板或 scaffold 记忆污染。

3.2 user simulator：既是交互条件，也是测量偏差来源

User simulator 让任务具备迭代反馈，但“像用户”不等于“代表用户”。模拟器通常比真实用户更稳定、更愿意补充信息、较少表达混乱或恶意，也可能过度认可流畅 Agent。

因此 benchmark 同时测到两种能力：

  • Agent 是否能完成真实任务；
  • Agent 是否能适应某一个特定模拟器。

后者并不天然等于真实用户鲁棒性。要消除这层偏差，至少需要多模拟器、人类对照、persona 分层与模拟器—人类一致性评估。

3.3 Docker sandbox：提高可复现性，不等于完全可复现

Docker 能固定环境边界并记录工具副作用，但完整复现仍依赖：

  • 镜像 digest；
  • 浏览器 / 操作系统版本；
  • 外部 API 版本与网络状态；
  • 初始账户、文件、随机种子；
  • 模型版本、temperature、最大 token 与工具预算；
  • user simulator prompt 与模型版本。

只公布任务 JSON 而不冻结环境快照，第三方复跑仍可能出现巨大方差。

3.4 rubric：关键瓶颈从“答案”转向“评分者”

双 rubric 能描述交付物质量，但也引入新的测量误差：标准是否逐项可判定？视觉 rubric 是否能区分真实缺陷与审美偏好？多个 judge 是否一致？judge 是否偏爱与自身风格相近的答案？

更关键的问题是最终分数依赖 judge。若没有人工盲评、跨 judge 一致性、误接收/误拒绝率或与真实用户满意度相关性，48.4% 与 32.1% 只能视为“bench score”，不能视为绝对能力标尺。

4. 最强发现与最弱环节

4.1 强项一：把“长上下文”重新定义为长程工作状态

1M token 不是目标本身。AgencyBench 真正推进的是：长上下文应和工具调用、环境状态、用户反馈、错误恢复及最终产物绑定。这对 Agent 系统比 NIAH 更有工程意义。

4.2 强项二：模型与 scaffold 必须联合比较

同一模型在不同 Agent SDK 中表现不同，说明“模型排行榜”不能直接替代系统排行榜。这一点值得所有 coding / browser / MCP Agent 团队采纳。

4.3 弱项：模拟用户 + 自动 rubric 构成双重测量偏差

这是本文最薄弱环节。任务越真实、交互越长，user simulator 的偏好越可能定义“什么叫成功”；rubric 再由模型或规则解释这些偏好。两条自动化链叠加后，benchmark 可能高效、稳定，却失去与真实用户的外部效度。

5. 复现与统计风险

5.1 算力与时间成本

每题约 1M token、90 次工具调用、数小时。138 题即使只跑一个模型 × 一个 scaffold，也已是很重的实验；完整模型 × scaffold 矩阵成本更高。比较不同模型时必须同时报告：

  • 总 token；
  • API 费用；
  • wall-clock；
  • 工具调用次数；
  • 重试次数；
  • sandbox 失败率。

否则“更强模型”可能只是“允许花更多预算”。

5.2 统计报告不足

对 138 题的小基准，至少需要：

  • 任务级 bootstrap 置信区间；
  • 多 seed 重复；
  • 按场景族分层报告；
  • 多重比较校正；
  • 任务间相关性说明；
  • judge 与人类评分的相关性。

若只报总分而不报这些，排名稳定性可能被高估。

5.3 版本与污染

公开 benchmark 一旦成为训练目标或评测优化对象，未来分数就需要版本化：task snapshot、judge prompt、scaffold、模型和日期共同构成一次 benchmark run。只有“模型名 + 总分”不足以复现。

6. 与近邻基准的关系

  • LongBench / RULER / NIAH：测长上下文检索与推理；AgencyBench 测长程交互、工具和环境状态，是能力外延，不是替代。
  • WebArena / OSWorld / WorkArena：更接近浏览器与桌面任务；AgencyBench 更强调日常任务和 user simulation，但任务真实性与可控性的 trade-off 不同。
  • GAIA / DeepResearch Bench：偏知识推理或报告质量；AgencyBench 更强调实际工具闭环和多模态交付物。
  • LongHarness Bench：后者把 cost per instance 拉到一级轴；AgencyBench 暴露 1M token / 数小时的真实成本，却没有证明不同配置都在同等预算下比较。

7. 工程团队应如何使用

  1. 把它当端到端系统测试，不当单模型 leaderboard。 固定模型、scaffold、工具、预算后比较 harness；固定 harness 后再比较模型。
  2. 按失败类型拆分。 计划错误、工具选择、状态遗忘、恢复失败、越权、视觉呈现问题必须分开统计。
  3. 保留真实用户抽测。 至少对每类高价值场景做小规模人工盲评，校准模拟器和 rubric。
  4. 公开 run manifest。 固定 task snapshot、prompt、容器 digest、模型版本、token / 时间 / 费用预算。
  5. 做污染探测。 设置私有 holdout 与时间切分集，定期判断公开分数是否已饱和。

8. 可信度与入库建议

  • 准确性：中高。 任务规模、1M token、90 次调用、32 场景 / 138 任务及总体对比等核心信息与公开材料一致；但 judge、统计显著性和复现细节仍缺正文级闭合。
  • 深度：中高。 重点不只是跑分，而是拆出 user simulator、scaffold、rubric、预算与版本污染五个测量层。
  • 清晰度：高。 核心判断明确，证据与推断分开。
  • 入库建议：建议作为 Agent 长程评测邻接级立标候选，尤其是“日常任务闭环 + user simulation + Docker + 双 rubric”范式；暂不直接作为模型选型唯一依据。

9. flyP 一句话立场

AgencyBench 是“1M token”标题下最接近真实 Agent 工作闭环的一批基准之一，但它的外部效度上限不由任务数量决定，而由 user simulator 与 rubric 是否经真实人类校准 决定；若没有这项校准，分数仍只是自动化模拟世界里的相对刻度。

10. 下一轮验证动作

  • 核对 HTML/正文中的 rubric 字段、judge 模型与一致性统计；
  • 核对 138 题的场景分层、每任务工具调用 / token 分布；
  • 核对代码、数据、容器镜像与运行脚本是否公开；
  • 核对是否控制模型、scaffold、工具预算和采样参数；
  • 查找独立第三方的复跑与人类相关性验证。

边界声明

本次只覆盖 inbox/flyp/ 内原 AgencyBench 笔记；未写其它实例目录、未写 review/、未执行 git，未涉及密钥或 Token。