模型不是瓶颈，你搭的"壳"才是。

---

一、一个让所有 AI 从业者沉默的数据

2026 年初，研究者 Nate B Jones 发表了一项看似平淡无奇的研究：

同一个 AI 模型，同样的提示词，只更换它运行的"环境"，编程基准测试的成功率从 42% 跳到了 78%。

模型没换。数据没换。提示词也没换。

只是改了模型外面包裹的那层"壳"，性能翻了将近一倍。

这层壳，现在有了一个正式的名字：Harness（马具）。

而围绕它展开的工程实践，叫 Harness Engineering（驾驭工程），是 2026 年 AI 工程圈最热门、也最被误解的话题。

---

二、Harness 到底是什么？

2.1 一个通俗的比喻

把 AI 模型比作一匹千里马。

Harness 就是驾驭这匹马所需要的一切：缰绳、马鞍、路线规划、围栏、训练规则。

你要做的，不是让这匹马"更聪明"，而是让它跑得更稳、更快、更安全。

可能说马相关的东西比较遥远不好理解，咱们把大模型理解成发动机，古早的Agent就好比是給发动机装上地盘轮子方向盘和刹车，让这辆车能跑，但是早期汽车跑不远，想让汽车正常跑在路上你要为汽车安装好多东西，减震系统，汽车喇叭，车灯转向灯，顶棚，雨刮等，后来又安装了GPS导航，自动驾驶传感器，这些就属于Harness，以后肯定还有更多的功能。

具体来说，Harness 就是：

• 你给 AI 写的项目规则文件（AGENTS.md）
• 你配置的各种工具（终端、文件系统、浏览器）
• 你安排的任务拆分和执行顺序
• 你设计的测试和检查流程

这些统统都算 Harness。

2.2 核心公式

整个行业达成了一个共识公式：

Agent = Model + Harness

模型提供智能，Harness 让这个智能能被实际使用。

---

三、为什么是 2026 年？

3.1 三代进化

要理解 Harness 为什么现在火了，得先看它是怎么一步步"长"出来的。

阶段	时间	核心关注	比喻
Prompt Engineering	2022-2024	怎么写好单次指令	写一封好邮件
Context Engineering	2025	动态构建上下文环境	带上相关附件
Harness Engineering	2026 年 2 月起	设计完整控制系统	搭建整个办公室

三层关系是层层包含的：

• Prompt 是最内层：关注"怎么给 AI 下指令"
• Context 包裹着 Prompt：关注"怎么给 AI 提供信息"
• Harness 把它们全部包在里面：关注"怎么让 AI 持续靠谱地干完一整件事"

3.2 引爆点：两篇博文

2026 年 2 月，两篇几乎同时发布的技术文章，把 Harness 推上了风口浪尖。

第一篇，来自 OpenAI 的 Codex 团队：

从一个空的 git 仓库开始，5 个月，大约 100 万行代码，1500 个 PR，全部由 Agent 生成，人类一行代码都没写。

团队一开始只有 3 个工程师，后来扩到 7 个。平均每位工程师每天合并 3.5 个 PR。

他们估算，如果用传统方式手写，这个项目的工期应该是现在的10 倍。

第二篇，来自 Mitchell Hashimoto（HashiCorp 联合创始人、Terraform 的缔造者）：

他把自己的 AI 采纳之旅分成六个阶段，第五个阶段给了一个名字：

Engineer the Harness

每当你发现 Agent 犯了一个错误，你就花时间去工程化一个解决方案，让它再也不会犯同样的错。

他在项目中实践了这个理念：AGENTS.md 文件里的每一行规则，背后都对应着 Agent 曾经犯过的一个错。

---

四、Harness 的五个核心模块

这是本文的重点。理解了这五个模块，你就理解了 Harness 的骨架。

4.1 上下文架构：让 AI 了解项目背景和规矩

做项目的第一步是什么？

了解需求、项目背景和开发规范。用 AI 做项目也一样。

常见做法：

• 写 AGENTS.md 规则文件，告诉 AI 技术栈、代码规范、禁止事项
• 但注意：OpenAI 团队踩过一个坑——把几千行规则塞进一个大文件，AI 反而更容易忽略关键信息

正确做法：把 AGENTS.md 当成目录来用，只写大约 100 行的摘要和索引，然后在 docs/ 目录下放详细的设计文档。

AGENTS.md（目录，约 100 行）
├── "前端规范看 docs/FRONTEND.md"
├── "安全相关看 docs/SECURITY.md"
└── "API 文档看 docs/API.md"

ETH Zurich 的一项研究发现：CLAUDE.md / AGENTS.md 文件应该控制在 60 行以内。过长的指令文件反而会降低 Agent 的表现。

4.2 执行能力：给 AI 装上手脚和工具

AI 模型本身只能输出文本。要让它真正帮你干活，得给它配工具。

工具清单：

• Bash 终端：执行命令
• 文件系统：读写代码
• 浏览器：测试网页（Browser Use）
• MCP（Model Context Protocol）：扩展能力，如读写数据库、联网搜索
• Skills 技能包：把复杂工作流封装成技能

一个反直觉的发现：工具越多，不一定越好。

Vercel 的经验：把 Agent 的工具从 15 个砍到只剩 2 个，准确率反而从 80% 升到了 100%。

Stripe 有大约 500 个 MCP 工具，但给每个 Agent 的只是精心筛选过的子集。

4.3 任务编排：给 AI 安排好工作计划

如果你丢给 AI 一个大需求，它可能会一把梭全部搞定。但 AI 的上下文空间是有限的，开发到一半信息就装不下了，前面定好的方案和约束慢慢被冲淡。

怎么解决？

基本做法：

1. Plan Mode：先让 AI 出方案，人工确认后再动手
2. 任务拆分：大任务拆成小任务，每次只做一个功能点
3. 增量开发：每做完一个功能，沉淀文档（实现了什么、用了什么方案、还有哪些待办）
4. SubAgents 并行：多个互不依赖的小任务，可以让子代理并行执行

4.4 反馈机制：让 AI 自己检查自己的工作

AI 写完代码之后，可能会自信满满地说任务完成了，结果你一点运行，全是 Bug。

所以得让 AI 自己检查：

• 跑 Linter：查语法和规范问题
• 跑自动化测试：验证功能是否正确
• Browser Use：自己打开浏览器实际操作一遍
• Agent 互审：让另一个 AI 来审查代码

如果测试没通过，AI 可以自动读取报错信息，分析原因并尝试修复。

4.5 架构护栏：防止代码越改越乱

AI 生成代码有个特点：它会模仿仓库里已有的代码风格，哪怕是烂代码。

比如同样的页面代码写了好几遍，也不知道要拆分成可复用的组件。时间一长，技术债就越滚越大。

怎么防止？

• 架构约束 Linter：查的不是代码风格，而是架构规则（如"UI 层不能直接调用数据库层"）
• Pre-commit Hooks：提交前自动拦截不合规的代码
• 垃圾回收机制：定期让 AI 扫描代码库，检查有没有偏离架构规范的地方，自动提交修复 PR
• Git 检查点：每完成一个功能就提交一次，相当于打存档点

---

五、七个可以立刻上手的配置杠杆

说完了理论，来点实际的。以下是你今天就能用的 Harness 技巧：

杠杆	做法	备注
AGENTS.md	每次 AI 犯错加一条规则	控制在 60 行以内
确定性约束	Linter、类型检查、结构化测试	硬约束比软指令更可靠
工具精简	只给 AI 最必要的工具	多了反而不知道该用哪个
Sub-Agent 隔离	复杂任务拆分	防止中间噪声累积
反馈循环	AI 自己跑测试、查日志	别让什么都靠人工盯
CI 限速	最多两轮 CI	失败就转人工
垃圾回收	定期扫描技术债	尤其代码量大了之后

---

六、行业两大阵营：Big Model vs Big Harness

Harness Engineering 也不是没有人唱反调。而且反对者的来头都不小。

6.1 Big Model 阵营

核心观点：模型能力的增长才是主旋律，Harness 只是权宜之计。

OpenAI 的 Noam Brown 在访谈中直接表态：

Harness 就像一根拐杖，我们终将能够超越它。

他的论据：在推理模型出现之前，开发者搭建了复杂的 Agentic 系统来模拟推理能力。推理模型一出来，这些基础设施一夜之间就不需要了。

他的建议：别花六个月搭建一个可能六个月后就被淘汰的东西。

6.2 Big Harness 阵营

核心观点：模型是引擎，Harness 是方向盘和刹车。引擎再强，没有方向盘你也到不了目的地。

LlamaIndex 创始人 Jerry Liu 的话代表了这一派的立场：

Model Harness 就是一切。从 AI 那里获取价值的最大障碍，是你自己为模型做上下文工程和工作流工程的能力。

6.3 护栏悖论

我觉得两边都对了一半。

护栏悖论：车速越快，护栏越重要。

• 时速 30 公里的自行车道可以没有护栏
• 时速 120 公里的高速公路，护栏是标配
• 时速 300 公里的磁悬浮列车？不仅有护栏，整个轨道都是封闭的

模型就是引擎。引擎越强，速度越快，你就越需要精心设计的约束系统来确保它跑在正确的方向上。

Noam Brown 说得对，很多脚手架确实会随着模型进化而被淘汰。但架构约束、反馈循环、熵管理这些东西，本质上不会消失，只会换一种形态。

就像从马车到汽车，马鞭消失了，但方向盘和刹车不会消失。

---

七、一个更深层的洞察

写到这里，我忽然意识到一件事。

Harness Engineering 说的这些——上下文管理、架构约束、反馈循环、定期清理——这不就是管理吗？

想想看，一个好的技术 leader 是怎么带团队的？

管理行为	Harness 对应
给新人写 onboarding 文档	AGENTS.md
定代码规范和架构原则	Linter 和结构测试
做 Code Review 确保质量	CI/CD 检查
定期技术债清理	垃圾回收
工具选型和精简	工具链管理
反复出现的问题写进 Wiki	反馈循环

AI Agent 越强，就越像一个能力很强但需要管理的员工。

你不会把一个刚入职的天才工程师扔进一个没有文档、没有规范、没有 CI 的项目里，然后指望他写出完美的代码。

同样的道理，你也不该把一个强大的 AI 模型扔进一个没有 Harness 的环境里，然后抱怨它不好用。

---

八、未来会怎样？

几个值得关注的趋势：

1. Harness 会成为新的"服务模板"：未来的组织可能会从一组预制的 Harness 模板中选择，然后根据自己的需求定制
2. 技术栈会收敛：当写代码本身不再是瓶颈时，团队会更偏向选择那些"有好 Harness 可用"的技术栈
3. Harness 会反哺模型训练：Harness 捕获的 Agent 失败轨迹，可以成为模型训练的高质量数据
4. "旧代码"问题：OpenAI 的实验是从空仓库开始的。但对于那些已经有几十万行代码的老项目呢？给老代码加 Harness，可能就像给一个从不跑测试的项目补测试一样痛苦
5. 学科化：AIE Europe 已经设立了全球第一个 Harness Engineering 专题赛道。arxiv 上也有了专门的论文

---

九、写在最后

有人发了个"暴论"：

大模型开发将是最后的程序员，下来是 Harness Engineering 开发，所有纯码农，将在 2028 年前消失。

2028 这种预言有点太没依据。但方向大概没错：

写代码正在变得像打字一样廉价。

而在模型之外，设计让 Agent 持续、稳定、高质量工作的那套系统，正在变成最值钱的技能。

未来最稀缺的，可能不是训练模型的人。

而是管理模型的人。

---

参考资料：

• OpenAI 博文：Harness engineering: leveraging Codex in an agent-first world
• Mitchell Hashimoto 博客：My AI Adoption Journey
• Martin Fowler 站点分析：Harness engineering for coding agent users
• Latent Space 分析：Is Harness Engineering Real?
• Stripe Dev Blog：Minions: Stripe's One-Shot End-to-End Coding Agents