SkillForgeBench 1.0

为什么重要

Agent 评测长期卡在一个两难里：专家手工 curated 的基准有流程深度，但做不大；众包基准铺得开领域，但执行上不严。前者如 Terminal-Bench 2.0（89 个任务），后者如各类”真实使用场景”集。要测”Agent 能不能严格满足一堆复杂程序性要求”，两者都不够。

SkillForgeBench 的解法是拿 Agent 技能文件（skill specification） 同时当两样东西：既当合成任务的流程蓝本，又当评分 rubric 的来源。一份技能文件天然就写着”做这件事要经过哪些步骤、产出什么、遵守什么约束”，于是任务深度和领域广度可以从同一个源头长出来，不需要二选一。

它带来的最直接冲击是：一个看起来已经很强的 Agent，在”必须全部满足”的口径下会塌掉一半以上。

构建方式

三阶段共设计（co-designed），而不是先造题后补 rubric：

1. Resource Preparation：用领域均衡的技能文件指导真实工件（artifact）检索，先把工作流的覆盖面铺开；
2. Skill-driven Task Synthesis：以技能为流程锚点，切分工件角色（哪些是输入、哪些是待修改的中间态、哪些是最终交付物），合成自然语言任务指令，并打包成可执行的沙箱场景；
3. Holistic Evaluation Design：把技能内嵌的要求翻译成完成 rubric 与过程 rubric 两套细粒度标准，支持需求级别的严格判分。

领域构成

值得注意的是 Harness Behavior 占了 14.8%：这个基准有相当一部分任务是让 Agent 去写技能、改提示、造 MCP 工具——被测对象本身就是”造 Agent 的 Agent”。这与本站记录过的 AgentSWE（让 builder 优化已有 Agent，三家平均分为负）形成有趣对照。

判分：loose 与 strict 是两把尺子

对 k 条 rubric：

• S_loose = (1/k) Σ r_i —— 平均通过率；
• S_strict = Π r_i —— 连乘，也就是要求所有约束同时成立。

论文明确指出：单条 rubric 的通过率（loose）是 70.0% 到 85.7%，而要求全部满足后的 strict 通过率只剩 12.6% 到 40.9%。这 30–73pp 的落差就是本卡存在的理由。

评分单元的可靠性方面，1,711 条单元经双专家标注，整体人类一致率 95.9%（任务质量 98.0%、完成 rubric 96.1%、过程 rubric 95.4%），并把 GPT-5.6-sol 作为第三方评分者对照（整体 4.27 分，专家 4.46 / 4.53 分，5 分制）。

关键发现

严格口径下的能力层级非常陡

八个 Agent 的 loose 完成分挤在 70.0–85.7（极差 15.7pp），看起来是”都还行”。换成 strict 之后变成 12.6–40.9（极差 28.3pp），而且次序都变了：GLM-5.2 的 loose（84.1）高于 Sonnet 4.6（81.5）与 HY3（80.9），strict 也一样居第二；但 Gemini 3.6 Flash 的 loose（79.2）高于 Kimi K2.6（78.1），strict 却反过来（18.4 > 20.1 是 Kimi 更高）。

这正好是本站反复记录的”部分分 vs 全完成率”落差的又一条证据：读 loose 会得到”前沿 Agent 都完成了八成”，读 strict 才知道最好的那个也只有四成。（同类读数参见 MatToolBench 的 Score ≈50% / SR ≈20%，以及 Haiku 5.5 在 OSWorld 2.1 上 Partial 72.4% / 全完成 37.1%。）

技能注入让强者更强，不是普惠

给 Agent 注入对应的技能文件后，strict 完成分的增益：

论文原话：top-tier agents obtain larger gains than low-tier agents。这与本站此前观察到的”小模型的工具增益比旗舰大 3 倍、工具抹平档位差”（HLE no-tools/with-tools）方向相反——那里工具抹平的是”参数化知识”，这里技能放大的是”遵循复杂流程的能力”。不同类型的外部输入，对档位差的作用是相反的，引用时不能混为一谈。

过程合规率远低于完成率，低到接近为零

最刺眼的一列是 strict 过程分：头名 Opus 4.8 也只有 27.7，而 Haiku 4.5 是 2.38（论文原文直接写 “under 3%”）。也就是说，弱档位模型基本从来没有一次把过程要求全部走对。

论文的结论很硬：只检查最终产出的评测会系统性高估 Agent 的真实可靠性。这一条与 AgentSWE 那句”静态八维 rubric 无法区分 0 分交付”是同一个方向的不同证据。

效率与合规没有必然关系

GLM-5.2 的助手轮数（42.6）与工具调用数（58.0）都是全场最高，strict 也确实是第二；但 Sonnet 4.6 的轮数最少（15.5），strict 过程分却只有 10.2，低于轮数几乎是它三倍的 HY3（34.7 轮 / 21.6）。动作少不等于合规好，动作多也不等于更接近完成——这与 Incident-Arena 上”反复检查的通过率反而更低”是同一现象。

局限与未决

• 被测模型偏旧。八个 Agent 里最新的是 Opus 4.8（2026-05 档），没有 2026-09 之后的 Opus 5.5 / GPT-6 Astra / Gemini 4 Argon 一代。论文 10-10 提交时这些模型已经发布，因此本榜的绝对分数不能直接与本站其它 2026-10 卡片横向比较。
• strict 是连乘，任务内 rubric 条数越多、单条通过率相同的情况下 strict 必然越低。论文未逐域给出 k 的分布，跨任务比较 strict 时存在这个未控制的混淆变量。
• Harness Behavior 域占 14.8%，其中相当一部分任务是”写技能 / 改提示 / 造工具”。这类任务的 rubric 与其它域的可比性未在论文中单独验证。
• 论文未给出人类基线。在”专业软件 / 复杂流程”类基准上缺少熟练操作员对照时，低分不能简单解释为能力缺失（这一点在 MatToolBench 上已经踩过一次）。
• 截至 2026-10-24 未见公开代码与数据集链接，第三方暂无法复现。

与同类基准的关系

论文自己的对比表把 WebArena、AppWorld、Terminal-Bench 2.0、ClawBench、LiveClawBench、RealClawBench、Claw-Eval、SkillsBench、Agentic Skills at Scale 九个基准按”真实需求 / 真实环境 / 细粒度 rubric / 过程评估 / 使用技能”五项打了分，SkillForgeBench 是唯一五项全中的：

需要提醒的是：这张表是论文自评，除 SkillForgeBench 外的”✓/✗“是按各论文自述打的，不是统一实测。