# 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层后，准确率迅速上升到80-90%。这个Harness层主要做三件事：

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

关键是：**没有任何模型改进，只是通过系统工程，准确率提升了30-40个百分点。**

### 案例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%

换句话说，Harness层的成本几乎是模型成本的10倍。但对应的收益呢？如果没有这10倍的投入，系统就根本无法上线——因为无法满足合规性和可靠性要求。

## 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 行业实践的验证

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

### Google DeepMind的观点

在 Google Gemini 系统的官方文档中，Google 强调：

> “模型能力的提升遵循对数规律——早期的改进带来显著收益，但之后的边际效益迅速递减。而系统工程的优化往往能够线性地提升应用的真实性能。”

他们的建议是：在模型已经足够强大的情况下（能够完成基本的推理和规划），投入应该从模型优化转向系统工程。

### 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%
* 系统工程提升倍数：k = 1.5（假设值，通过验证、重试等）
* 有效成功率：p' = min(1, p × k) ≈ 0.95（通过足够的重试和验证，可以大幅降低错误率）
* 整体成功率：(p')^N ≈ 1

即使使用较弱的模型(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 小时**。

**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层级的改进：

**1. 失败检测(Failure Detection)**

* 实现了主动监测：在每个Agent步骤后检查是否真正完成了预期的操作
* 检查工具调用是否成功、API返回是否有效、结果是否满足预条件
* 使用编译器式的检查点(checkpointing)，记录每一步是否“真正”成功

**2. 执行隔离(Execution Isolation)**

* 为每一次尝试创建独立的执行环境（如Docker容器、沙箱）
* 防止一次失败的执行污染后续尝试的状态
* 确保Agent可以安全地尝试多条不同路径，而无需担心副作用

**3. 多轮验证(Multi-Round Verification)**

* 在Agent自动提交答案前，要求它进行自动验证
* Agent不仅要产生答案，还要主动检查答案的正确性
* 如果自动验证失败，Agent会重新尝试，而不是直接返回错误的答案

### 实验结果

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

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

这个提升完全来自Harness层级， **没有使用更新的模型、没有模型微调、没有提示词优化**。仅仅通过改进系统工程的执行方式，就实现了与小模型升级相当的性能收益。

### 更重要的排名变化

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

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

这说明LangChain Deep Agents的Harness优化，使其性能达到了业界最强智能体系统的水平——仅通过工程层面的改进。

### 对实践的启示

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

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

## 1.4.8 结论

模型的重要性不是被夸大了，而是被理解错了。模型提供的是 **最初的、相对粗糙的想法**。Harness才是将这个想法 **精细化、可靠化、生产化** 的工程基础。

在一个真实的Agent应用中，模型层可能占15-20%的决定因素，而Harness层占80-85%。这不是说模型不重要，而是说Harness是让模型能够真正创造商业价值的关键。

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET 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?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.