PawBench v1.0：给通用智能体一把可复现的尺

过去一年，通用智能体已经从演示场景走进了很多真实工作流。它可以帮人写代码、整理资料、操作网页、处理文件，也可以在更长的链路里调用工具、读写工作区、完成多步骤任务。

但问题也随之变得更具体：同一个模型，放进不同的智能体运行框架里，表现会不会差很多？一次任务失败，到底是模型没想明白，还是工具没给对、工作区没配置好、完成判定太宽松？如果只看最后的成功率，我们很难回答这些问题。

这正是 PawBench 想解决的事情。

PawBench 面向个人助理和通用智能体场景，评估的不只是底座模型，也包括承载模型运行的 Harness。这里的 Harness，可以理解为智能体的“运行框架”：它负责给模型装配 prompt、提供工具、管理工作区、隔离环境、注入技能，并决定什么时候继续执行、什么时候收尾。

换句话说，模型决定智能体的能力上限，Harness 决定这些能力能不能稳定落到真实任务里。PawBench 希望把这两件事放到同一张评测表里看清楚。

[!NOTE] PawBench 是 OpenJudge 生态的一部分。它沿用了 OpenJudge“评测驱动优化”的核心理念，并专注于评估 LLM × Harness 这一垂直维度的联合效果。

PawBench v1.0 是怎么构建的

PawBench v1.0 不是单纯做一个模型排行榜，而是把“模型、Harness、任务”三者放在一起做交叉评测。

这次评测从 6 个高质量 Agent 评测集中抽取了 150 道任务，包括 claweval、qwenclawbench、pinchbench、qwenpawbench、skillsbench 和 wildclawbench。每道题都会按照 5 个维度打标：

• 应用场景：例如办公协同、软件工程、自动化脚本、多模态内容生成。
• 原子能力：例如工具调用、Skill 使用、规划、逻辑推理、自我校验。
• 复杂度：L1 / L2 / L3，避免只靠简单题刷高分。
• 输入模态：区分纯文本任务和图像、音频、视频等多模态任务。
• 运行环境：区分离线沙箱任务和需要联网的 Web 搜索 / 网页获取任务。

评测矩阵是 9 个模型 × 3 个 Harness × 150 道任务，一共 4,050 个测试单元。三家 Harness 分别是 Hermes、OpenClaw 和 QwenPaw。所有任务都在 Docker 沙箱中运行，执行轨迹、grader 产物和环境快照都会被保留下来，方便后续按切片复盘。

最终得分由两部分组成：一部分来自自动评分器，包括规则和子项断言；另一部分来自 LLM-as-judge，用于评估更偏语义的结果质量。本期评测采用混合权重计算最终分数，分数范围为 0 到 1。

1. 效果矩阵：模型与 Harness 协同决定表现

先看文本任务矩阵。

它最直接地回答两个问题：同一个模型换 Harness，分数能差多少；同一个 Harness 下换模型，能力上限又会怎么变。

从本次结果看，有两个结论比较明显。

• 模型和 Harness 会共同影响结果：模型能力是基础，claude-opus-4.6 在三家 Harness 上都保持在 76 分以上，说明强模型换到不同运行框架里依然很强；但弱一些的模型对 Harness 更敏感，qwen3.6-35b-a3b 从 Hermes 的 57.9 到 QwenPaw 的 70.4，差距被明显拉开。
• Harness 效果差距堪比一次模型升级：在文本任务上，QwenPaw 75.4、OpenClaw 74.8、Hermes 70.0，最高和最低差 5.5 分。更典型的是 qwen3.6-plus + QwenPaw 得到 76.5，高于 qwen3.6-max-preview + Hermes 的 70.2。这说明好 Harness 能让模型“以下克上”，但本质上是模型能力和 Harness 支撑共同作用的结果。

2. 模型之间差异在哪：从切片看优点和缺点

如果故事到这里结束，PawBench 就只是一个 Harness 评测。但 4,050 个 cell 还揭示了另一件事：模型之间的失败指纹并不一样。

为了先看清模型侧差异，我们把 Harness 固定为 QwenPaw，再按任务标签切片分析同一批提交。这样可以先去掉上一章里最大的环境变量，让模型画像更容易解释。

要选择适配任务类型的模型。claude-opus-4.6 是总分最高的一档，平均能力和稳定性都很强；但拆到一级场景后，它只在 4/11 个场景拿到第一。制造工程和软件工程由 qwen3.6-max-preview 领先，数据分析由 qwen3.7-max 领先。总分适合做第一层筛选，真正选型还是要看任务落在哪类场景里。

Qwen3.6 35B/A3B vs. Max：差距更多体现在长链路任务上。以 Qwen 系列内部为例，size 提升后，拉开差距的不是简单问答，而是 Math Computation、Planning、Tool Use 这类需要多步执行和持续规划的能力。固定 QwenPaw 后，qwen3.6-max-preview 在能力标签上最完整；qwen3.7-max 则更偏开放环境和数据分析。

多模态仍然是共同短板。去掉没有原生多模态能力的 text-only 模型后，所有可比模型在 QwenPaw 下的 multimodal 分数都低于 text 分数：claude-opus-4.6 低 6.1 分，deepseek-v4-pro 低 8.0 分，qwen3.6-35b-a3b 低 12.4 分。多模态不是某个模型的个别问题，而是图片理解、信息抽取、跨模态推理和工具链衔接共同带来的难点。

固定 Harness 能把模型差异看清楚，但真实使用时模型不会单独运行。下一步要看的是：这些能力差异放回不同 Harness 之后，哪些会被放大，哪些能被更好的工具、状态和校验机制接住。

3. 模型 × Harness 配合：三个交互切片

PawBench 的切片能力可以把 4,050 个测试单元按模型规模、模态、任务类型、技能领域等维度拆开，再对照执行轨迹，定位模型能力和 Harness 行为之间的配合关系。模型负责理解目标、规划动作和判断结果，Harness 负责把工具、技能、状态和环境约束转成模型能稳定使用的外部结构。

发现一：小模型更依赖 Harness 把执行链路托住

先看两个模型的对比。claude-opus-4.6 在三家 Harness 上都比较稳，最高和最低只差 2.3 分；但 qwen3.6-35b-a3b 只换 Harness，分数差距就达到 11.5 分。

这说明大小模型对 Harness 的敏感度并不一样。大模型通常更能自己补齐上下文缺口：路径没说清楚时还能推断，工具列表变长时也更能筛选，产物有没有真的生成也更容易回头检查。小模型的问题在于执行链路更脆，它更容易忘记当前工作目录，误判文件是否写入成功，也更容易在工具列表过长时选错第一步。

对执行轨迹做复盘后，我们看到 Harness 没有配合好的地方主要有三个。

(1) 缺乏“产物级”硬校验：导致“虚假完工”。目前的 Harness 多依赖模型的自我声明，缺少对工作区（Workspace）产物的实质性校验（如文件是否真正落盘、diff 是否生成、测试是否通过或路径是否正确）。这导致模型极易过早宣布完成，从而在此类任务中严重掉分。

(2) 路径感知与约束宽松：比如 Hermes 未在 Prompt 中明确当前工作目录，也未在 write_file 等工具层强约束写入路径。这导致模型“自以为”写入成功，但评测程序在标准工作区却扫描不到产物。

(3) 工具表体量过大，增加模型决策负担：不同 Harness 默认装载的工具数量差异显著（Hermes 约 65 个，OpenClaw 约 30 个，QwenPaw 约 15 个）。工具并非越多越好，庞大的工具 Schema 不仅挤占上下文，还会显著增加小模型的首轮决策负担。

所以，这个切片不是在说“小模型不行”，也不是在说“Harness 可以替代模型能力”。更准确的结论是：小模型更需要 Harness 把外部结构搭好。cwd、路径约束、工具选择和产物校验这些细节，对大模型可能只是加分项，对小模型却是能否稳定完成任务的前提。

发现二：Skill 使用需要 Harness 主动发现，也需要模型真正用好

很多用户会将 Skills 放在项目 workspace 中，作为项目专属 Skills。本次评测模拟的就是这种情况：每个 task 专属的 Skills 会复制到 workspace 中，来测试 Harness 主动发现和应用 skills 的能力。从结果来看，相比于工具调用、规划或逻辑推理等其它能力切片，三家 Harness 在 17 道 Skill 任务上的表现都较为吃力。

这暴露出两个核心问题。首先是 Harness 的主动发现能力不足。除了 OpenClaw 外，另外两个 harness 都不会主动加载 workspace 中的 skills。如果 Harness 只扫描全局预装 Skill，而不扫描当前工作区，就会漏掉这份关键指南，让模型只能自行摸索。

其次是 模型自身的长链路推理瓶颈。即使 Harness 成功注入了 Skill 并立好了“路标”，模型在执行复杂推理和精细计算时依然容易出错。Harness 能指路，但能不能走通，最终仍考验底座模型的能力。

所以，Skill 任务的关键不只是 Skill 是否存在，而是这条链路有没有完整跑通：Harness 要先主动发现 workspace 里的 Skill，并把名称、说明、适用条件和调用方式放到模型看得见的位置；模型拿到这些路标后，还要能判断什么时候该用、怎么按步骤执行。两边只要有一边没接上，最终都会表现成同一种失败：模型绕过 Skill，用通用推理硬做任务。

发现三：Web 搜索任务很依赖默认可用性

这里说的 Web 搜索任务侧重考察模型的网页检索、内容抓取与深度调研能力。本次评测不追求“配齐所有搜索服务 API Key 的理论上限”，而是还原开发者第一次 clone 后的默认体验：拉固定版本源码，写入 LLM 密钥，然后直接跑。

在这类任务中，Hermes 表现偏低，核心原因是其核心工具在零配置下被“锁死”。虽然源码内置了 web_search 和 web_extract，但必须配置外部搜索 API Key 才能启用。在仅配置 LLM 密钥的评测环境下，模型拿不到这些工具，只能降级使用基础 browser 工具硬做。

相比之下，OpenClaw 提供了更好的体验，它的 web_search 支持 DuckDuckGo 等免密服务，web_fetch 依赖内置 HTTP 抓取，真正实现了零配置直连；QwenPaw 虽无专属搜索工具，但通过 browser_use 结合模型知识储备，也能有效完成基础的 Web 访问。

这说明，Web 搜索任务的评测结果不只反映模型搜索和阅读能力，也反映 Harness 是否把关键工具做成了“默认可用”。

但这不是纯 Harness 问题。强模型在这里有一层明显的兜底能力：当专用 search 路径不可用时，它会把任务改写成“用现有通用工具拿到证据”。参考 Hermes open 环境下的轨迹复盘，强模型通常会先识别搜索链路退化，再改用 terminal + curl 抓原始 HTML、用浏览器控制台抽 DOM、从长页面里提取表格和价格字段。遇到网页打不开、摘要太短、路径 404 时，它们也更容易换第二条、第三条路径，而不是停在第一次失败上。

弱模型的失败模式就更直接：拿不到稳定 search 后，容易反复 browser_navigate 同一批 URL，或者把工具失败判断成任务本身不可做。也就是说，强模型能靠计划重写、工具替代和 HTML 抽取补一部分 Harness 缺口；中小模型则更需要 Harness 把 search / fetch 做成默认可用，并给出清楚的失败反馈。这个切片的核心不是“强模型不需要工具”，而是：模型越弱，越需要 Harness 把搜索链路托住；模型越强，越能在 Harness 缺口上多绕一段路。

4. 模型和 Harness 的协同设计原则

把上面的切片合起来看，PawBench 给出的不是“某家 Harness 最好”这种单点结论，而是一组协同设计原则。每条原则都对应一个模型短板。

1. Inform Fully：充分告知

模型看不见的东西，对它来说就不存在。Harness 应该明确告诉模型当前运行环境：cwd 在哪、workspace 在哪、输出目录在哪、工作区里有没有 SKILL.md，以及有哪些可用资源。

这条原则主要补偿模型的工作目录感知缺失和资源发现不足。Hermes 不提供 cwd 时，弱模型更容易把文件写到 /home/user/ 或 /root/；OpenClaw 把 Skill 描述渲染进 prompt，则能让模型至少知道先读专家流程。

2. Equip on Demand：按需装备

工具要装得对，也要装得精。“装得对”指关键工具应该在默认配置下可用，例如 keyless web search、内置 HTTP fetch、Skill helper 自动注册。“装得精”指工具数量要匹配目标模型的上下文和注意力预算。

小模型不适合面对过大的工具表。长上下文脆弱模型也不适合一次性接收过重的 system prompt 和工具 schema。工具不是越多越好，过多的选择会把模型的执行链路拖散。

3. Monitor Actively：主动监控

不要只听模型说了什么，要看它做了什么。Harness 应该检查任务产物是否真的落地：文件是否存在、是否非空、是否包含必填字段、工具调用是否合法、exit code 是否正常。

这条原则主要补偿模型的“虚假完工”和自查不足。很多任务不是模型说“完成了”就真的完成了，它可能没有写出文件，也可能把文件写到了 grader 看不见的目录。产物级校验比一句“我完成了”可靠得多。

4. Recover Gracefully：弹性恢复

一次异常不一定代表任务失败。当 Harness 发现模型空响应、只画计划、工具调用异常或产物缺失时，可以给它一次更有信息量的续推机会，例如注入当前状态、说明缺少什么产物、保留中间结果，并设置合理的 retry budget。

这条原则主要补偿过早退出、死循环和 fallback 弱。qwen3.6-35b-a3b 这类模型在工具失败两三次后容易放弃；kimi-k2.6 这类模型又容易重复相同动作。Harness 需要在异常时把状态讲清楚，并推动模型换策略。

PawBench 能帮谁

如果你是智能体用户，PawBench 可以帮你选择更合适的模型和 Harness 组合。面对纯文本任务、多模态任务、Skill 任务或 Web 搜索任务，不同组合的表现并不一样。不要只看模型总分，也要看你关心的场景在哪个 Harness 下更稳定。

如果你是 Harness 开发者，PawBench 不只是一个榜单。它提供了 4,050 个 cell 的对照矩阵和切片分析能力，可以帮助你做三件事：

1. 横向自检：把你的 Harness 跑到同一组模型上，看在哪些任务类型上落后。
2. 失败画像：锁定可疑切片，对比 trace，找到具体的 Harness 行为问题。
3. 回归验证：每次修复后重新切片，看分数变化是否真的对应到问题上。

如果你是模型开发者，PawBench 也能暴露更具体的训练目标：工作目录感知、工具失败后的策略切换、重复动作检测、长任务分步写盘、web search 后的事实保持、安全拒答边界。这些能力在普通聊天评测里不一定显眼，但在真实 Agent 任务里会直接决定成败。

这类评测对通用智能体尤其重要。真实用户不会只问模型一个问题就结束，他们会让智能体操作文件、调用工具、跑脚本、读网页、跨步骤完成任务。PawBench 希望把这些复杂链路拆开，让模型能力和 Harness 能力都能被看见、被诊断、被持续改进。

欢迎贡献

PawBench v1.0 已开源。我们欢迎社区一起参与：

• 接入新的 Harness，例如 CoPaw、Cursor Agent 或其他社区框架。
• 提交新的模型评测结果。
• 贡献更多任务，并按照五维标签体系完成标注。
• 基于 slice 能力分析你关心的任务切片，反馈诊断报告。

PawBench 站在开源 Agent 评测社区的肩膀上，包括 Claw-Eval、QwenClawBench、WildClawBench、PinchBench 和 skillsbench。