Harness Engineering：超越模型之争，5个关键节点提升AI编程效率实践

最近读到Nav Toor一篇关于AI工程实践的长文，其中提出了一个引人深思的观点：模型能力的上限，很大程度上取决于你为它设计的“缰绳”系统，也就是 Harness Engineering。

这个概念基于一个令人印象深刻的实验结果。

同一个模型，同一套测试，成绩翻了将近一倍

研究人员用同一个AI模型执行同一套编程基准测试，第一次得了42分，第二次却得了78分。模型没换，测试没变，所有参数都保持原样。唯一的变量，是包裹在模型外部的那套控制与引导系统，也就是所谓的 harness。

Harness 直译是“挽具”，就好比套在马身上用来控制方向的那套装备。Nav Toor做了一个形象的比喻：模型是马，充满力量；但如果没有缰绳、马鞍和嚼子，马就会肆意奔跑。Harness 就是让这匹“马”按照你的意图去工作的那一整套装备。

具体来说，harness 包括注入给AI的规则文件、工具配置、技能模块、记忆文件以及各种反馈回路。它决定了AI在接到任务后如何理解需求、拆解步骤、避免犯错，以及在出错后如何进行自我纠正。

LangChain 的团队也独立验证了类似的结论。他们的编程智能体在Terminal Bench 2.0基准测试上，排名从30名开外一举冲进了前5。模型同样没换，提升完全来自于harness的优化。更夸张的是，OpenAI的Codex团队曾利用AI编写了一个超过一百万行代码的生产级应用，全程没有一行代码由人工撰写。工程师们所做的工作，就是设计和调试harness。

这些案例指向一个清晰的结论：模型的选择远没有大家想象的那么重要，真正决定AI编程质量的，是你围绕模型构建的那套系统工程。

Harness Engineering 到底在做什么？

Mitchell Hashimoto（Terraform的创造者）为harness engineering下了一个精辟的定义：每当你发现AI犯了一个错误，你就花时间设计一个解决方案，确保它再也不会犯同样的错误。

这就是harness engineering的全部哲学。与其祈祷下一个模型版本会更好，不如立刻动手去修复模型周围的系统。

Nav Toor的文章详细拆解了AI编程智能体工作流中的五个可配置节点，每一个都是工程师可以拉动并优化的杠杆。

1. 系统指令文件

这是一个放在代码仓库根目录的Markdown文件，AI每次启动新会话时都会读取它。它明确告知AI你的代码库是做什么的、遵循哪些规范、有哪些绝对禁止的行为。很多人会跳过这个文件，或者直接让AI自己生成一个。这两种做法都是错误的。苏黎世联邦理工学院的测试表明，AI生成的系统指令反而会降低性能，并多消耗约20%的token。人工编写的指令有帮助，但前提是简洁且具体。Nav Toor的建议是将其控制在60行以内，只写全局通用指令，不要放目录结构（AI自己能发现），也避免写复杂的条件逻辑（例如“如果做X就按Y来”），这会让AI感到困惑。

2. 技能模块

与其把所有领域知识都塞进冗长的系统提示词里，不如将它们拆分成一个个聚焦的独立模块。AI在遇到特定任务时，自动加载对应的技能文件。例如，你可以有一个“数据库迁移”技能、一个“API端点创建”技能、一个“前端组件模式”技能。AI遇到迁移任务就只加载迁移技能，其他无关知识不被载入。这被称为“渐进式披露”，让AI从最少的上下文开始，按需拉取更多信息，从而保持主上下文的洁净与高效。

3. MCP服务器

MCP（Model Context Protocol）服务器可以将AI连接到外部系统，例如用Linear进行任务追踪、用Sentry监控错误、或直接查询数据库获取实时数据。但Nav Toor也特别警告：每连接一个MCP工具都会增加AI系统提示词的认知负担。连接太多会导致“工具抖动”——AI把时间浪费在选择使用哪个工具上，而不是专注于解决问题。建议从两到三个最核心的工具开始，遇到真实瓶颈时再逐步添加。

4. 子智能体

这里有一个重要的认知纠偏：子智能体的正确用法并非按角色分工（比如一个负责前端、一个负责后端），HumanLayer团队尝试过这种方式后选择了放弃。子智能体的核心价值在于充当上下文防火墙。当主智能体遇到一个会生成大量中间过程、从而塞满并污染上下文窗口的任务时，就将其委派给一个子智能体。子智能体在完全隔离的独立上下文中完成任务后，只将最终结果传回主线程，中间所有的“思考噪音”都被隔离。Chroma的研究显示，AI模型在过长的上下文窗口下表现会显著下降。子智能体的作用正是将大问题拆解为多个小而聚焦的会话，让模型始终保持在最佳工作状态。

5. 钩子

钩子（Hooks）是在AI工作流的特定节点自动运行的脚本，旨在为非确定性的AI系统添加确定性的控制逻辑。例如：提交前的钩子可以运行代码风格检查和单元测试；任务完成前的钩子可以强制AI对照原始需求做最终验证；循环检测钩子可以在AI反复进行同一处无效修改时及时中断它。LangChain开发了一个名为 PreCompletionChecklistMiddleware 的钩子，它在AI声称完成任何任务前，强制其执行一次需求核验。仅这一个钩子，就为他们的整个harness系统带来了巨大的性能提升。

为什么模型之争可能是一个误区？

许多开发者花费大量时间争论Claude、GPT或Gemini哪个更好，追逐每一次新模型的发布，相信“下一个版本会解决所有问题”。然而数据给出了不一样的答案。同一个模型通过优化harness，性能可以从42%跃升至78%，这几乎是翻倍的提升。历史上没有任何一次模型迭代能带来2倍的性能飞跃，但一个设计精良的harness却可以常规性地做到这一点。

OpenAI的Codex团队对此直言不讳：当智能体表现不佳时，我们将其视为一个信号，去寻找系统缺失了什么——是工具、护栏还是文档？然后将其补回代码仓库。他们不更换模型，他们修复和增强harness。

Nav Toor的总结非常精辟：模型是引擎，harness是方向盘、刹车和铺设好的路面。你可以拥有世界上最强大的引擎，但如果没有方向盘，它只会径直撞向墙壁。

这个观点与我们此前讨论的许多趋势不谋而合。Ryo Lu说品味和判断力是AI时代的护城河，Aaron Levie说知道该构建什么比构建本身更有价值，Zack Shapiro说输入层才是真正值钱的东西。Harness Engineering 本质上就是这些理念在工程实践中的具体落地：你为AI构建的系统，直接决定了AI的产出质量。

一套可以立刻开始的实践方法

Nav Toor在文末给出了一套极具操作性的起步方案：

1. 创建核心指令文件：在你的代码仓库根目录创建一个系统指令文件（例如 SYSTEM.md），控制在60行以内。清晰地写明你的技术栈、测试命令、不可违反的硬性规则（例如“永远不要删除数据库迁移文件”、“提交前必须通过所有测试”、“使用TypeScript严格模式”），除此之外不要添加任何无关内容。

2. 沉淀模式化技能：审视你的代码库，找到那些反复出现的开发模式，例如“创建RESTful API端点”、“生成数据库迁移脚本”、“搭建新的React组件”。为每一种模式编写一个聚焦的技能文件，内容包括标准做法、边界情况处理和常见错误提醒。

3. 植入自动化钩子：添加一个提交前（pre-commit）钩子，自动运行代码检查（如linter）和测试套件。如果AI试图提交无法通过检查的代码，钩子会在其进入版本库之前将其拦截。一个简单的钩子，往往能带来巨大的质量保障收益。

4. 善用上下文防火墙：当你发现AI在处理复杂长任务时开始失去逻辑连贯性，就将该任务拆解为多个子任务，委派给子智能体去执行。确保主智能体的上下文保持干净、聚焦。

5. 建立每周复盘习惯：这是最关键的一步。每周五花些时间回顾这一周AI犯下的错误或产生的低质量输出。每一个失败案例，都对应地在你的harness系统中增加一条规则、一个技能提示或一个校验钩子。每个修复可能只需五分钟。随着时间的推移，你的harness会不断积累“经验”，你的AI助手也会一周比一周更可靠。这不是因为模型变强了，而是因为你为它设计的系统变得更聪明了。

这对我们的职业发展意味着什么？

Nav Toor在结尾做了一个有说服力的论证：AI模型正在快速商品化。任何公司都可以调用同样顶尖的Claude、GPT或Gemini模型，模型本身已很难构成长期的竞争优势。

然而，一个精心设计、与你的业务深度绑定的harness系统，却是独一无二的竞争力。它与你特定的代码库结构、团队协作模式、业务领域的边界情况紧密结合。它无法通过下载一个模型权重来复制，它需要通过数周甚至数月的时间，将真实世界中的失败一个个“编码”进系统里，慢慢沉淀而成。

能够设计这种高效harness的工程师，将成为团队中难以替代的核心角色。并非因为他们亲自编写的代码最好，而是因为他们设计了能让AI持续产出高质量代码的系统。

OpenAI对此表述得非常明确：未来工程师的核心工作不再是手动编写代码，而是设计环境、明确意图、构建反馈回路，从而让智能体能够可靠、自主地工作。

最后，Nav Toor梳理了一个简要的技能演进时间线：2023年是提示工程（Prompt Engineering）年，2025年是上下文工程（Context Engineering）年，而2026年将是驾驭工程（Harness Engineering）年。这项技能的学习成本几乎为零，不需要新的工具，任何已经使用AI编程工具的开发者今天就可以开始实践。

唯一的问题是：你是选择今天就开始设计和优化属于你的harness系统，还是继续等待下一个“万能”模型的发布？数据已经给出了清晰的答案。

如果你对这类前沿的人工智能工程实践和开发趋势感兴趣，欢迎来云栈社区与更多开发者一起交流探讨。

原文地址：https://x.com/heynavtoor/status/2037200578842157462