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 层主要做三件事：
语法验证：在执行代码前，用 Python/JavaScript 解析器验证语法
类型检查：确保函数调用的参数类型正确
结果验证：运行代码，检查输出是否符合预期
关键是：即使没有任何模型改进，系统工程也能显著改变最终可用率。
案例 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-下午"实验
更直接、对照更严格的证据来自一项公开对照实验（原文标题作“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，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 组件：不是所有的系统工程都等值。优先级应该是：
工具层：确保工具调用的格式正确和权限合规
结果验证：检查输出是否符合预期
重试策略：对失败进行智能重试
可观测性：日志和追踪，以便快速定位问题
(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 小时以上（原文：“upwards of six hours”，且常发生在工程师睡觉时）。
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 层级（模型固定为 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 从相反角度补强了上述结论：他们固定模型，只改变基础设施配置，测量 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（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 就是这样的“底盘和悬挂”——它不会成为新闻头条，但是它决定了你是否能够到达目的地。
最后更新于