> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/harness_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/harness_engineering_guide/di-yi-bu-fen-harness-gong-cheng-ji-chu/01_harness_intro/1.4_harness_over_model.md).

# 1.4 Harness 为什么比模型更重要

本节通过公开案例和教学算例说明，在生产应用中 Harness 工程层的影响力往往超过单纯的模型能力提升。

## 1.4.1 问题的由来

在 AI 领域，有一种常见的错觉：模型的能力决定了系统的能力。因此，“如何获得更强的模型”成为了许多团队的首要关注。这个观点在学术界和模型开发者中普遍存在。

但在实际的生产应用中，情况更加复杂。我们可以通过几个案例和示意算例来说明这个问题。

## 1.4.2 公开案例与教学算例

本小节通过 OpenAI Codex、提示词优化、Anthropic Constitutional AI 等案例和算例，说明系统工程的关键影响。

### 案例 1：OpenAI Codex 团队的观察

OpenAI 在开发 Codex（基于 GPT-3 的代码生成特化模型）和后续的代码生成工具时，遇到了一个出乎意料的现象。

在完全允许模型输出任意代码的设置下（即没有任何 Harness 层的干预），模型更容易出现多类不可直接上线的问题。这包括：

* 代码语法错误（模型无法完全遵守 Python 或 JavaScript 的语法规则）
* 逻辑错误（模型的算法步骤不正确）
* API 调用错误（模型调用了不存在的函数、参数格式错误）

但当引入一个相对简单的 Harness 层后，许多错误会在执行前或执行后被发现并修正。这个 Harness 层主要做三件事：

1. **语法验证**：在执行代码前，用 Python/JavaScript 解析器验证语法
2. **类型检查**：确保函数调用的参数类型正确
3. **结果验证**：运行代码，检查输出是否符合预期

关键是：**即使没有任何模型改进，系统工程也能显著改变最终可用率。**

### 案例 2：提示词 vs 系统设计

考虑一个 A/B 测试对比（示意场景，数字用于说明相对关系，非某项公开研究的实测值）：

**组 A**：使用较弱的模型，精心优化的提示词（Chain-of-Thought、Few-shot examples 等） **组 B**：使用更强的模型（能力提升约 20%），简单的提示词

在复杂的推理任务上，两组的成功率差不多。但：

**组 A + 系统工程层** （权限管理、结果验证、失败重试）：成功率 73% **组 B + 系统工程层**：成功率 89%

但最有趣的是： **组 A + 更复杂的系统工程层** （更智能的重试策略、执行隔离、多轮验证）：成功率 91%

这个教学算例说明：在多步任务里，系统工程改进可能超过单次模型升级带来的边际收益。

### 案例 3：生产环境的真实成本

考虑一个金融科技场景下 Agent 执行财务操作的成本结构（示意拆分，按典型生产部署的量级构造）：

* **模型调用成本**：10%
* **工具调用成本**（API、数据库等）：30%
* **系统工程成本** （日志、追踪、审计、重试）：40%
* **故障恢复成本** （修复失败、回滚操作）：20%

换句话说，模型之外的投入（工具执行、系统工程、故障恢复合计 90%）约为模型调用成本的 9 倍。但对应的收益呢？如果没有这些倍数级的投入，系统就根本无法上线——因为无法满足合规性和可靠性要求。

### 案例 4：Bölük 的"16-LLM-下午"实验

更直接、对照更严格的证据来自一项[公开对照实验](https://blog.can.ac/2026/02/12/the-harness-problem/)（原文标题作“15 LLMs”，但其基准正文明确为“Sixteen models, three edit tools”，本书按正文口径取 16）。

实验设计：

* 从 React 源码中随机挑选文件，注入 5 类典型 bug（操作符交换、布尔翻转、off-by-one、移除可选链、重命名标识符）
* 用自然语言描述 bug，让 **16 个不同的 LLM** 修复
* 同一组模型在同一组 bug 上跑 3 轮 × 180 个任务

唯一变量：将“让模型重现行的完整文本”改为“让模型引用行级内容哈希”（Hashline 技法，如 `11:a3` 引用第 11 行哈希前缀 a3）。 **模型权重、提示词、温度、模型本身全部未动。**

结果跨 16 个模型一致提升，最极端的几个：

* **Grok Code Fast 1**：6.7% → 68.3%（**+61.6pp，约 10×**）
* **MiniMax**：成功率翻倍以上
* **Gemini**：+8pp
* **平均输出 token**：下降约 20%（成本同步降低）

这是一个公开的严格对照实验：同模型、同任务，唯一变量是工具表征。它证明 **编辑工具的接口设计对编码 Agent 的可靠性可以产生一个数量级影响**。Bölük 据此提出后来被学术综述命名为 **binding-constraint 论题**（binding-constraint thesis）：可比模型上的基准方差，其驱动力可以来自执行 harness 本身，与模型能力的驱动力同等量级（见 [Agent Harness Engineering: A Survey](https://openreview.net/pdf?id=eONq7FdiHa)，TMLR 投稿中，2026-05）。

## 1.4.3 为什么会这样？

理解为什么 Harness 比模型更关键，需要回到 Agent 系统的本质。

### 大语言模型的本质是概率机器

大语言模型，无论有多聪明，其本质都是一个概率生成模型。给定一个上下文，它生成最可能的下一个 token。这导致：

(1) **不可能完全消除错误**：即使是最强大的模型，偶尔也会产生语法错误、逻辑矛盾或事实性错误。这不是模型“不够聪明”，而是这种架构的内在特性。

(2) **确定性需求无法满足**：在许多生产场景中，我们需要确定的、可重复的执行——比如金融转账、医疗诊断、法律文件生成。LLM 本身无法提供这种保证。即使使用 `temperature=0`（贪心采样），也只是让输出更稳定，但不能保证 100%的正确性。

(3) **实时学习困难**：LLM 的权重在训练后就固定了。虽然有少样本学习(in-context learning)，但长期适应和个性化学习能力有限。系统工程层才是让 Agent 能够真正学习和改进的基础。

### 应用的本质是系统性

一个 Agent 应用涉及数百甚至数千个决策点：

* 选择使用哪个工具？
* 参数该如何设置？
* 如果工具返回了错误怎么办？
* 用户的实际意图是什么？
* 这个操作是否安全？
* 操作完成后是否需要确认？

单个 LLM 调用，即使成功率达到 99%，由于决策点众多，整个系统的可靠性会迅速下降：

* 10 个决策，每个 99%准确：总准确率 99%^10 = 90%
* 100 个决策：总准确率约 37%
* 1000 个决策：总准确率约 0.004%

这说明 **系统级别的可靠性无法仅通过提升单个 LLM 调用的准确率来实现**。必须在系统工程层面进行干预。

### 成本和规模的考量

随着 Agent 系统的规模增长，模型成本的影响反而会减少：

假设我们要用 Agent 自动处理 1000 个客户支持工单：

* 模型成本：与问题复杂度有关，可能是$0.01-0.10/工单
* Harness 成本：与可靠性要求有关，日志、追踪、验证可能是$0.05-1/工单

当系统规模扩大到 100 万个工单时，Harness 的绝对投入会很大，但 **每单位的成本会下降** （因为可以共用基础设施）。而模型成本会按比例增长。此时，优化 Harness 的效率，比优化模型的成本效益更好。

## 1.4.4 行业实践的验证

让我们看看业界领先的实践者是如何看待这个问题的。

### 缩放定律的启示

OpenAI 与 Google DeepMind 等机构对缩放定律（scaling laws）的系列研究反复确认了同一个事实：模型能力随训练计算量呈幂律式增长——早期的投入带来显著收益，但之后的边际效益迅速递减。相比之下，系统工程的优化直接作用于应用的真实表现，不受这条收益曲线的约束。

由此可以得出一个工程判断：在模型已经足够强大的情况下（能够完成基本的推理和规划），增量投入应该从模型优化转向系统工程。

### Anthropic 的设计哲学

Claude 的设计中，Harness 组件（他们称之为“guardrails”和“tool use framework”）占据了核心地位。在 Claude Code 中：

* 系统提示词缓存：确保一致的行为
* 工具执行流(StreamingToolExecutor)：保证工具调用的可靠性
* 权限和隔离机制：防止危险操作

这些都不是模型的改进，而是系统工程的投入。

### OpenAI 的工具使用框架

从 Function Calling 到现在的 Structured Output，OpenAI 的方向很清晰：让模型更好地与外部系统交互。这实际上是在说：**我们的模型可能无法完美地调用工具，所以我们需要一个 Harness 层来保证**。

## 1.4.5 定量的论证

让我们用一个数学模型来量化这个直觉。

假设一个 Agent 系统有 N 个任务步骤，每步的 LLM 调用成功率是 p，系统工程的干预可以提高单步成功率到 p'。

**不使用系统工程的情况**：

* 整体成功率：p^N
* 为了维持目标成功率 R，需要 p^N ≥ R
* 如果 R = 0.95，N = 100，则需要 p ≥ 0.95^(1/100) ≈ 99.95%

这意味着每一步都需要接近完美的成功率。这通常需要使用最强大（也最昂贵）的模型。

**使用系统工程的情况**：

* 原始 LLM 成功率：p = 90%
* 系统工程干预：每步引入结果验证，失败后最多重试 3 次（每步至多 4 次近似独立的尝试）
* 有效成功率：p' = 1 − (1−p)^4 = 1 − 0.1^4 = 99.99%
* 整体成功率：(p')^N = 0.9999^100 ≈ 99% ≥ R

即使使用较弱的模型(p=90%)，通过系统工程的干预，我们也能实现高可靠性。这会省去大量成本。

## 1.4.6 实战建议

基于以上分析，对实际项目的建议是：

(1) **不要过度优化模型**：在模型准确率达到 85%以上后，继续追求模型能力的提升面临递减边际效应。此时应该把重点转向系统工程。

(2) **优先投入高效益的 Harness 组件**：不是所有的系统工程都等值。优先级应该是：

1. **工具层**：确保工具调用的格式正确和权限合规
2. **结果验证**：检查输出是否符合预期
3. **重试策略**：对失败进行智能重试
4. **可观测性**：日志和追踪，以便快速定位问题

(3) **把模型的“最后一英里”交给 Harness**：使用一个“足够聪慧”的中等能力模型（如 Claude Sonnet），配合完善的 Harness 设计，往往比使用最强模型配置简单系统更具成本效益。

(4) **提前规划故障处理**：在设计之初，就考虑“如果这一步失败了怎么办”。这些故障处理逻辑，往往是整个 Harness 的核心价值所在。

## 1.4.7 行业验证：OpenAI 系统阐述 Harness Engineering

OpenAI 的 Codex 团队通过官方博客和工程实践，系统阐述并推广了“Harness Engineering”这个术语，并用一个大规模实验验证了其核心价值。

来源：Ryan Lopopolo, [Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/)（OpenAI Engineering，2026）。

### 实验规模

OpenAI 团队在 5 个月内通过纯代码生成方式构建了一个内部产品，代码规模达到 **约 100 万行**， **零人工代码编写**。这个规模相当于一个中等规模的企业级系统。

### 关键发现

**1. 系统工程焦点的决定性转变**

Lopopolo 在文章中指出，团队的工程重心从“写代码”转向“为 agent 设计可读、可验证、可枚举的环境”。在这一约束下，仅由 **3 名（后扩至 7 名）工程师**驱动 Codex，平均吞吐量达到 **3.5 PR / 工程师 / 天**，整个项目以“**1/10 的人工耗时**”完成（原文：“1/10th the time it would have taken to write the code by hand”），单个 Codex run 可在无人值守状态连续工作 **6 小时以上**（原文：“upwards of six hours”，且常发生在工程师睡觉时）。

**2. 范式演进**

业界实践阐述的 AI 辅助开发的三层范式演进：

* **Prompt Engineering** （提示词工程）：单轮交互，无持久化
* **Context Engineering** （上下文工程）：RAG/记忆机制
* **Harness Engineering** （驾驭工程）：系统级执行控制与验证

Birgitta Böckeler 在 [Harness engineering for coding agent users](https://martinfowler.com/articles/harness-engineering.html)（martinfowler.com，2026-04-02）一文中将这套实践归纳为：在机器可读的工件中编码“上下文工程、架构约束、以及对漂移的‘垃圾回收’式定期扫描”三类能力。

**3. 无模型改进的性能突破：LangChain Deep Agents 案例**

LangChain 的 Deep Agents 团队进行了一项实验，完全专注于 Harness 层级的改进，完全不涉及模型微调或升级。他们的成果提供了另一条证据：**在同一模型上，系统工程层也能带来可观提升**。

### [LangChain Deep Agents](https://blog.langchain.com/improving-deep-agents-with-harness-engineering/) 的研究

团队的改进全部落在纯 Harness 层级（模型固定为 gpt-5.2-codex，原文明确“只调整了 harness，模型保持不变”）：

**1. 自我验证循环(Self-Verification Loop)**

* Agent 在宣告完成前必须构建、测试、验证并修复自己的方案，而不是一次性给出答案
* 配套的 PreCompletionChecklistMiddleware 会在 Agent 试图退出时拦截，强制走完验证清单

**2. 环境感知与循环检测中间件**

* LocalContextMiddleware 在启动时绘制目录结构、发现可用工具，让 Agent 先了解环境再行动
* LoopDetectionMiddleware 跟踪文件编辑次数，在同一文件被反复无效修改时提示 Agent 重新考虑思路

**3. 推理预算的“三明治”分配(Reasoning Sandwich)**

* 在规划与验证阶段分配更高的推理预算，在中间的机械执行阶段降低预算
* 把思考集中在最需要判断力的环节，而不是平均分摊，并辅以提示词引导与时间预算提醒

### 实验结果

在 Terminal Bench 2.0（终端任务能力基准）上的性能：

* **基线（无优化）**：52.8% 通过率
* **应用 Harness 改进后**：66.5% 通过率
* **性能提升**：+13.7 个百分点（相对提升 26%）

这个提升完全来自 Harness 层级， **没有使用更新的模型、没有模型微调**。仅仅通过改进系统工程的执行方式（验证循环、中间件、推理预算分配与提示词引导），就实现了与小模型升级相当的性能收益。

### 更重要的排名变化

在 Terminal Bench 2.0 的全球排行榜上：

* 优化前：排名在 30 名之外
* 优化后：进入全球前 5

这说明 LangChain Deep Agents 的 Harness 优化，使其在 Terminal Bench 2.0 排行榜进入前 5——且提升来自工程层面的改进。

### Anthropic 的反向验证：基础设施差异会被误读为模型差异

Anthropic 2026 年的研究 [Quantifying infrastructure noise in agentic coding evals](https://www.anthropic.com/engineering/infrastructure-noise) 从相反角度补强了上述结论：他们固定模型，只改变基础设施配置，测量 Terminal-Bench 2.0 上的成绩漂移。

* 从严格资源限制（1x）切换到完全无限制：成功率提升 **+6 个百分点** (p < 0.01)
* 从严格资源限制切换到 3x 余量：基础设施错误率从 5.8% 降至 2.1% (p < 0.001)
* 1x 与 3x 之间的成功率差异落在噪声范围内 (p = 0.40)

Anthropic 的直接建议是： **排行榜上低于 3 个百分点的差距值得怀疑**——它很可能反映的是基础设施配置，而非模型能力差异。换言之，对一篇宣称“模型 X 比 Y 强 2pp”的报告，正确的反应不是“模型有差距”，而是“先问 harness 是否一样”。

这与前面 Bölük、OpenAI Codex、LangChain Deep Agents 三个案例一起，从正反两个方向收紧了同一结论： **在 agent 系统里，模型与 harness 共同决定可观测的表现，无法把任何一方单独剥离来归因。**

### 学术验证：自动化 Harness 演进反超人工设计

复旦大学团队 2026 年 4 月的论文 [Agentic Harness Engineering](https://arxiv.org/abs/2604.25850)（arXiv 2604.25850）把上述结论推进到了自动化层面：他们固定底座模型，只让系统依据可观测性信号，自动迭代模型外围的工具、中间件与长期记忆。

* 从一个通过率 69.7% 的初始 harness 出发，经过 10 轮自动进化，Terminal-Bench 2 上的 Pass\@1 提升到 77.0%；
* 更关键的是，这个自动搜索出的 harness 反超了人工精心设计的 Codex-CLI harness（71.9%）——底座模型全程未变，仅靠外围系统的自动演进就超过了人手打磨的结果；
* 迁移到另外三个模型家族上，仍带来 5.1 到 10.1 个百分点的增益；消融实验显示，收益主要来自工具、中间件与长期记忆，单纯改写系统提示词几乎没有贡献。同一套改进还让 SWE-bench Verified 上的 token 消耗下降约 12%。

这条证据的分量，在于它来自可复现的学术实验而非单一产品博客，并指向一个更强的命题：Harness 不只是“比模型重要”，它的设计空间本身已经大到值得用自动化方法去搜索。这与本书第十三章的评估方法论、以及“把 Harness 当作一等工程对象”的整体主张相互印证。

### 对实践的启示

OpenAI 的大规模实验验证了前文第 1.4.2-1.4.4 节的分析并非理论猜想，而是生产级别系统的现实。这意味着：

* 对大规模或高风险 AI 系统，Harness 工程通常不再只是可选最佳实践，而是基础设施的一部分
* 投入强大 Harness 设计往往比投入更强的模型更有 ROI
* 标准化的 Harness 框架（如本书所述的架构约束、文档系统、验证体系）已被行业领先者验证为可行且高效

## 1.4.8 结论

模型的重要性不是被夸大了，而是需要放在系统里理解。模型提供候选行动；Harness 将候选行动纳入验证、权限、观测、恢复和交付闭环。

真实 Agent 应用的表现由模型与 Harness 共同决定。越接近生产环境，Harness 的权重越高；这不是说模型不重要，而是说 Harness 是让模型能力真正创造价值的关键。

正如一个高性能赛车的发动机很重要，但没有底盘、刹车、悬挂系统的工程，再强大的发动机也无法安全地行驶。Harness 就是这样的“底盘和悬挂”——它不会成为新闻头条，但是它决定了你是否能够到达目的地。