Agent Harness 是性能变量，不只是模型外壳

论文把 Harness 视为可训练、可测量系统的一部分。

很多 Coding Agent 对比把模型名称当作唯一变量，其余都叫“封装”。实际并非如此：上下文选择、Tool Schema、Compaction、重试、仓库记忆、验证与权限都会改变模型看到什么，以及哪些动作能够完成。

先说结论

• Agent 性能属于模型、Harness 与环境组成的系统。
• 更高分可能来自更多 Token、隐藏重试、更好工具或更宽权限。
• 比较必须固定模型、任务、环境、预算和完成标准。
• Harness 每次发布也要回归，不能只在模型升级时评测。

近期研究把 Code 视为 Agent Harness，并探索跨环境训练 Harness-native Agent，可参考 Code as Agent Harness和 OpenForgeRL。价值在评测方法，不是再造排行榜。

应分别测量：文件选择和 Compaction；Tool Schema、延迟与并发；重试、规划与停止条件；仓库指令与历史记忆；测试、Lint、浏览器检查和独立 Review；网络、凭证、审批与可写范围。

隐藏重试三次的 Harness 与只展示第一次结果的 Harness 预算不同；无限制联网可能提高解题率，却违反原本安全边界。能力与权限必须一起报告。

公平实验应固定模型快照、Reasoning Effort、容器镜像、仓库 commit、任务文本、时间/Token/成本预算、网络政策与 Pass 条件，并保存 Event Trace 和 Patch。失败再按上下文、推理、工具、环境、验证或政策分类。

每次 Harness 改动都做 paired trial。一次看似微小的 Compaction 或文件搜索更新，可能在没有模型变化时让一个仓库提升、另一个仓库退化。

为什么“外壳”会改变答案

该综述与 OpenForgeRL 从不同角度说明 Harness 如何改变可执行、可验证与有状态的 Agent 系统。

模型并不直接看仓库。Harness 决定哪些文件变成 Token、Tool Result 如何摘要、错误是否完整显示、旧上下文何时消失，也决定模型有哪些动作词汇。精准的 search_symbol 与通用 Shell 即使最终能拿到相同内容，也会诱导出不同计划。

Loop Policy 同样关键：编辑前是否规划？测试失败后能否继续？看到的是完整错误还是截断 Tail？何时申请审批？生成 Patch 就算完成，还是必须通过测试并检查页面？这些系统实际上在解决不同任务。

变量之间还会交互。更多上下文可能帮助理解仓库，也可能淹没关键约束；激进 Compaction 省 Token，却可能丢掉用户修正；并行工具降低延迟，却可能读取不同 Workspace 状态；隐藏重试提高成功率，却掩盖真实成本。

先定义实验单位

最干净的单位是“在全新、固定环境中完成一次任务”。任务顺序随机化，存在采样随机性时多次运行，禁止一次 Attempt 的文件和 Memory 泄漏到下一次。

结果应记录模型、Reasoning 与采样参数；Harness Commit 与完整配置；仓库 Commit、容器与依赖；初始指令和人工 Steering；网络、Secret、文件与审批政策；工具调用、延迟、错误和截断标记；Token、时间、计算与费用；最终 Patch、测试、副作用和独立评分。

如果一个 Harness 得到仓库专属说明，另一个没有，这本身就是实验变量。人工救活卡住的 Run，也要计入干预次数和时间。

一个不容易作假的 Scorecard

指标	揭示的问题
验证后的任务成功	请求行为是否真的工作
非请求修改率	Scope Creep 与误改
人工干预	最终成功背后的运维负担
成本和延迟分布	Tail，而不只是平均值
安全政策合规	能力是否留在权限边界内
可复现性	第三方能否解释结果
故障恢复	工具、测试或网络失败后的行为

尽量使用 Agent 未见过的测试，再加安全与可维护性 Review。只跑公开测试容易让系统迎合样例；完全不透明的评分又无法告诉 Harness 团队为什么失败。样本量和不确定性必须公开，并按 Bug Fix、Feature、Refactor、Frontend、Dependency、Operations 分组。

把失败归到正确层

Context Failure 是需要的文件或约束缺失、过期或被 Compaction 丢失；Reasoning Failure 是证据齐全但判断错误；Tool Failure 是 Schema、实现或错误信息阻断；Environment Failure 是依赖、凭证、服务或 Fixture 不可用；Verification Failure 是没有检查目标行为；Authority Failure 是政策错误阻止必要动作或放过危险动作；Interaction Failure 则来自 Steering 与审批时机。

分类不是甩锅，而是选择下一项改进。换更大模型修不好空 Error；增加重试也修不好永久缺服务的测试环境。成功样本也要抽查，有些 Pass 依赖偶然环境状态、过宽凭证或覆盖不足的测试。

性能与权限必须同时报告

给 Harness 开互联网、扩大可写目录、保存凭证或自动批准，可能提高解题率，但这不是免费提升。应在等价 Authority Envelope 下比较成功率。使用任务级短期凭证与明确目标域，把 Deny 事件也记录为数据。

测试本身也有权限风险：运行仓库脚本可能执行不可信代码。成熟 Harness 应隔离推理、执行和 Secret，并把安全政策写进 Benchmark 配置，而不是当作噪声。

怎样改进而不自欺

从真实失败建立脱敏 Regression Suite，每项改动先写预期机制。例如 Symbol Search 应减少 Context Miss，更完整 Tool Error 应改善恢复。针对目标失败和广泛 Holdout 做 Paired Trial。

Prompt、Tool Schema、Compaction、Repo Memory 与 Grader 都像代码一样版本化，逐步 Rollout 并保留 Trace 对比。还要防止只对一个模型快照过拟合：适合模型 A 的工具描述和上下文策略，可能让模型 B 退化。

Harness 和模型谁更重要？

没有统一答案。弱推理不能永远靠编排补救，强模型也会被糟糕 Harness 限制；应测量真实部署组合。

两家厂商的 Benchmark 能直接比较吗？

只有任务版本、预算、权限、环境、验证与人工干预都相当时才可以，否则是在比较两个不同实验。

结论

这些指标在架构中的位置，可结合生产级 Agent 为什么需要 Runtime 层理解；权限维度则应对照生产级 Agent Guardrails，不能成为未披露的 Benchmark 优势。

Harness 没有模型权重，却在实践中构成产品智能的一部分。这不代表模型质量不重要，而是单变量营销对比不可信。应选择能在权限与预算边界内正确完成工作、且成功失败都可解释、可复现、可改进的系统。