AGENT开发
🧪Harness-Bench 深度分析 - 2026-07-05
00 分钟
2026-7-5
2026-7-5
type
status
date
slug
summary
tags
category
icon
password
一句话判断：Harness-Bench 不在问“哪个模型更聪明”，而是在问“同一个模型被不同 agent 运行外壳包起来，结果会差多少”。这个问题很硬。今天很多榜单把模型、工具、上下文、权限、恢复策略混在一起算分，最后却把功劳或问题都记到模型头上。

原始资料

论文在 arXiv 的提交日期是 2026-05-27，作者来自 Peking University 和 Qiyuan Tech。arXiv 页面写明它有 16 页、4 张图、11 张表，核心实验覆盖 106 个沙箱任务和 5,194 条执行轨迹。

为什么今天选它

我对比了几个近期对象。Agent Lightning 热度高，GitHub 页面显示 17.4k stars，重点是让不同 agent 接入强化学习训练；Meta-Harness 更像“自动搜索 harness 代码”的研究线，论文报告了文本分类、数学检索、TerminalBench-2 上的提升；Memory for Autonomous LLM Agents 是一篇系统综述，把 agent memory 拆成 write-manage-read loop。
今天我选 Harness-Bench，是因为它补上了一个更基础的洞：如果没有办法测 harness，很多 agent 讨论都会停在“换模型”“换提示词”“加工具”的经验层。Harness-Bench 直接把 harness 作为评测变量。这个角度和最近的 agent 工程实践贴得很近，也能解释为什么同一个模型在不同产品里表现差得很远。

它到底解决什么问题

论文把 harness 定义为模型外面那层运行系统：它负责组织上下文、工具、状态、权限、约束、追踪和失败恢复。这个定义很实用。用户看到的是 agent 完成任务，但真正决定任务能不能落地的，往往是这些看不见的环节。
普通评测容易混淆三件事：模型本身强不强，运行外壳设计得好不好，任务环境是不是公平。Harness-Bench 的做法是固定任务、沙箱、预算、超时和评测器，只改变 model-harness 配对，并保留每个 harness 原本的运行方式。这样得到的不是“某个模型的裸能力”，而是“某个模型加某个运行外壳”的能力。
Figure 1: Harness-Bench 的评测流水线，来自 arXiv HTML 版论文。
Figure 1: Harness-Bench 的评测流水线，来自 arXiv HTML 版论文。
图 1 说明了它的主流程：任务先被放进沙箱，agent 在模型和 harness 的组合下执行任务；系统记录最终产物、执行轨迹、用量统计和验证器输出；最后合成 completion、process、security 三类信号。这里的关键不是多了一个分数，而是把“过程有没有乱跑”也放进评测，而不是只看最后答案像不像。

任务设计：不是孤立问答，而是可执行工作流

Harness-Bench 有 106 个离线沙箱任务，官网也把它拆成 8 类：workspace/tool use、office communication、long-running autonomy、software engineering、knowledge retrieval、SRE/DevOps、data/BI/finance、vertical workflows。论文强调这些任务都经过人工检查，标准包括 realism、solvability、oracle-checkability 和 integrity。
Figure 2: 106 个任务的类别分布，来自 arXiv HTML 版论文。
Figure 2: 106 个任务的类别分布，来自 arXiv HTML 版论文。
这张图比论文摘要更能说明它的野心。它不是只测写代码，也不是只测浏览器点击。它把 agent 常见的落地场景拆成文件、终端、本地网页、表格、证据引用、部署检查、长任务状态变化等更细的压力点。这样做的好处是，harness 的问题会暴露出来：上下文拼错、工具选错、状态没跟上、权限边界没守住，都会留下痕迹。

关键机制

第一，任务环境固定。每个 agent 从同样的沙箱状态开始，面对同样的任务、预算、超时和评测器。这样可以减少“外部服务今天变了”“网页加载不一样”这类干扰。
第二，harness 不被强行改造成同一种接口。论文没有把所有系统塞进一个统一框架，而是保留它们自己的 prompt、action format、tool interface、state policy、retry 和 recovery。这个选择很重要，因为真实产品里的差异恰好就在这些地方。
第三，记录证据。每次运行留下 final workspace state、execution trace、usage statistics 和 validator outputs。没有这些记录，评测只能说“成了”或“没成”；有了这些记录，才可以追问：是工具没用对，还是状态对不上，还是看似合理的推理脱离了文件和验证器。
第四，分数不只看完成度。论文的综合分由 completion、process 和 security gate 组成。completion 看产物是否通过验证；process 看 tool use、consistency 和 robustness；security gate 处理权限或安全违规。这个设计偏保守，但符合 agent 的真实风险：一个 agent 如果越权、泄露信息或绕过约束，就算最后答案漂亮，也不该拿高分。

结果怎么看

主实验用了 6 个可配置 harness、8 个 API model backend，组合出 5,088 条轨迹；另外把 Codex 作为绑定模型的 coding agent 单独跑了 106 条，总计 5,194 条。论文附录列出的 harness 包括 OpenClaw、ZeroClaw、Hermes、Moltis、NullClaw、NanoBot；模型后端包括 Claude、Gemini、Qwen、GLM、Kimi、OpenAI GPT 和 DeepSeek 系列。
Figure 3: 平均分与方差，以及不同 agent 的平均分，来自 arXiv HTML 版论文。
Figure 3: 平均分与方差，以及不同 agent 的平均分，来自 arXiv HTML 版论文。
图 3 给出一个直观信号：在这套协议下，NanoBot 的平均分最高，Codex 紧随其后，ZeroClaw 最低。论文正文写到，在可配置 harness 中，NanoBot 的 aggregate score 是 76.2，OpenClaw 是 52.4，两者差 23.8 分。这个差距不能简单解释成“模型差”。因为模型池、任务、预算和评测协议是固定的，差异很大一部分来自 model-harness 配对。
更值得注意的是左图的方差。它暗示某些模型对 harness 更敏感。也就是说，买到强模型不等于得到强 agent；强模型如果被放进差的工具、状态和恢复机制里，还是会掉分。
Figure 4: 不同任务类别的 harness 依赖程度，来自 arXiv HTML 版论文。
Figure 4: 不同任务类别的 harness 依赖程度，来自 arXiv HTML 版论文。
图 4 把问题拆得更细。Data/BI/Finance、Workspace/Tool Use、Software Engineering 的跨 harness 方差更高；Office & Business Communication 最低。这个结果符合直觉：越依赖结构化数据、工具顺序、工作区修改和中间状态追踪，harness 越重要。纯语言生成任务里，模型本身的影响更容易盖过运行外壳。

真正新在哪里，哪里只是工程包装

真正新的地方有三点。
第一，它要求报告 model-harness configuration，而不是只报告模型名。这会改变 agent 榜单的写法。以后说“某模型在某任务上多少分”不够，至少要说明它被什么运行外壳包起来、给了哪些工具、如何管理状态和权限。
第二，它把 execution alignment 明确拿出来分析。论文说常见失败是“看似合理的推理”和工具反馈、工作区状态、证据、可验证输出契约脱节。这个说法很准确。很多 agent 失败不是不会想，而是想完以后没有被环境事实拉回来。
第三，它承认 harness 是完整配置，不假装能一次拆出单个机制的因果贡献。这一点反而让结论更可信。现实里的 prompt、工具 schema、上下文、重试、权限通常是耦合的，硬拆会得到干净但不真实的结果。
工程包装也有。沙箱、oracle grader、trace、LLM judge 都不是新概念；把任务分成 8 类也不是理论突破。Harness-Bench 的价值在于把这些东西组合成一个专门测 harness 差异的协议，而不是发明了某个全新的 agent loop。

对产品和研发的启发

第一，别再只做“模型 A vs 模型 B”的内部评测。产品里真正该比较的是模型、工具、权限、上下文、恢复策略的组合。一个小模型配上更稳的 harness，可能比大模型配上松散执行层更适合上线。
第二，每个高频任务都应该有自己的小型离线沙箱。不要等线上用户报错才知道 agent 会乱改文件、漏读表格、忘掉约束。把典型输入、期望产物、隐藏校验和越权规则提前写清楚，agent 的改动才有回归测试。
第三，trace 不是调试附属品，而是产品资产。没有 trace，就无法判断失败来自模型、工具、状态、权限还是恢复机制。没有这个判断，团队只会不停换模型和加提示词。
第四，process score 可以比最终答案更早暴露风险。尤其是办公、财务、DevOps、客服这些场景，最终产物看起来对，不代表过程合规。是否引用了正确证据、是否访问了允许的数据、是否在工具失败后重试，应该单独计分。

风险和局限

这篇论文自己也讲得比较克制。Harness-Bench 是离线沙箱任务，减少了外部漂移，但也牺牲了真实在线服务、用户反馈、长期生产记忆和多天任务状态。它能说明 harness 差异存在，不等于能覆盖所有真实部署场景。
第二，它评估的是完整 harness 配置，不是单个机制的因果贡献。NanoBot 分数更高，不代表“轻量 agent loop”必然优于“长运行 runtime”；也可能是任务集、默认工具、提示、状态策略、失败恢复一起作用。
第三，process score 里有 LLM-assisted rubric。这个做法能扩大可评测范围，但会带来评审稳定性问题。正式采用时，最好把可确定的 oracle、隐藏测试和人工抽查结合起来。
第四，公开 benchmark 会被适配。只要任务、评分器和样例轨迹足够公开，harness 可以逐步针对它优化。长期看，它需要版本化任务、隐藏集和更严格的防投机设计。

今日沉淀

  1. Agent 能力不能只写模型名，要写模型 + harness + 任务环境。
  1. 越依赖工具、文件、状态和可验证产物的任务，harness 越重要。
  1. 好的 agent 评测要看过程，不只看最终答案。
  1. Trace 是定位 agent 失败的基础材料，不是可有可无的日志。
  1. 上线前先做离线沙箱和 oracle，别把真实用户当测试集。
上一篇内容
ForesightNews的Web3中AI项目全盘点
下一篇内容
Hermes Agent 深度分析 - 2026-07-04