1.4 Harness为什么比模型更重要

本节通过实证数据和具体案例说明，在生产应用中Harness工程层的影响力往往超过单纯的模型能力提升。

1.4.1 问题的由来

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

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

1.4.2 实证数据

本小节通过OpenAI Codex、提示词优化、Anthropic Constitutive AI等多个真实案例，量化说明系统工程的关键影响。

案例1：OpenAI Codex团队的观察

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

在完全允许模型输出任意代码的设置下（即没有任何Harness层的干预），模型的原始准确率只有约40-50%。这包括了：

• 代码语法错误（模型无法完全遵守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（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（martinfowler.com，2026-04-02）一文中将这套实践归纳为：在机器可读的工件中编码“上下文工程、架构约束、以及对漂移的‘垃圾回收’式定期扫描”三类能力。

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

LangChain的Deep Agents团队进行了一项突破性的实验，完全专注于Harness层级的改进，完全不涉及模型微调或升级。他们的成果再次有力证明：系统工程层的优化空间往往大于模型能力提升的空间。

LangChain Deep Agents 的研究

团队专注于以下三个纯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就是这样的“底盘和悬挂”——它不会成为新闻头条，但是它决定了你是否能够到达目的地。