# 一个让所有 AI 从业者沉默的数据 2026年初，研究者Nate B Jones发表了一项研究，表面上看起来平淡无奇，但细想之下，让人脊背发凉。 同一个AI模型，同样的提示词，唯一的变化是换了个运行“环境”——猜怎么着？编程基准测试的成绩，从42%直接飙到了78%。 模型没换。数据没换。提示词也没换。 就是改了模型外面那层“壳”，性能几乎翻了一番。 这层壳，现在有了正式的名字：**Harness**（马具）。而围绕它展开的工程实践，叫做**Harness Engineering**（驾驭工程），这大概是2026年AI工程圈最火、也最容易被误解的话题。 --- ## Harness到底是什么？ ### 一个通俗的比喻 把AI模型想象成一匹千里马。 Harness就是驾驭这匹马所需要的所有东西：缰绳、马鞍、路线规划、围栏、训练规则。你要做的，不是让马“更聪明”，而是让它跑得更稳、更快、更安全。 换个更贴切的比喻——大模型就是发动机。早期那些Agent，好比给发动机装上底盘、轮子、方向盘和刹车，让这辆车能动起来。但要让车真正跑在路上，还得装减震、喇叭、车灯、雨刮、GPS导航、自动驾驶传感器……这些，就是Harness。而且可以肯定，未来还会有更多。 具体来说，Harness包括： - 你给AI写的项目规则文件（比如AGENTS.md） - 你配置的各种工具（终端、文件系统、浏览器） - 你安排的任务拆分和执行顺序 - 你设计的测试和检查流程 全部算在内。 ### 核心公式 行业里已经有一个共识公式： **Agent = Model + Harness** 模型提供智能，Harness让这个智能真正派上用场。 --- ## 为什么偏偏是2026年？ ### 三代进化 Harness为什么现在火了？得看看它是怎么一步步“长”出来的。 | 阶段 | 时间 | 核心关注 | 比喻 | |------|------|----------|------| | Prompt Engineering | 2022-2024 | 怎么写好单次指令 | 写一封好邮件 | | Context Engineering | 2025 | 动态构建上下文环境 | 带上相关附件 | | Harness Engineering | 2026年2月起 | 设计完整控制系统 | 搭建整个办公室 | 这三层是层层包含的： - **Prompt** 在最内层：关注“怎么给AI下指令” - **Context** 包裹着Prompt：关注“怎么给AI提供信息” - **Harness** 把它们包在里头：关注“怎么让AI持续靠谱地干完一整件事” ### 引爆点：两篇博文 2026年2月，几乎同时发布的两篇技术文章，把Harness推上了风口浪尖。 第一篇，来自OpenAI的Codex团队。团队最初只有3个工程师，后来扩到7个。平均每人每天合入3.5个PR。他们估算，如果用传统方式手写，这个项目的工期应该是现在的10倍。 第二篇，来自Mitchell Hashimoto——HashiCorp联合创始人、Terraform的缔造者。他把自己的AI采纳之旅分成了六个阶段，第五阶段他给了一个名字：**痛苦和驾驭**。他的项目实践了一个理念：AGENTS.md文件里的每一行规则，背后都对应着Agent曾经犯过的某个错误。 --- ## Harness的五个核心模块 以下才是重点。理解了这五个模块，Harness的骨架就摸清了。 ### 上下文架构：让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的表现。 ### 执行能力：给AI装上手脚和工具 AI模型本身只能输出文本。要让它真干活，得配工具。 工具清单包括：Bash终端（执行命令）、文件系统（读写代码）、浏览器（测试网页，比如Browser Use）、MCP（扩展能力，读写数据库、联网搜索等）、Skills技能包（把复杂工作流封装起来）。 但有一个反直觉的发现：工具越多，不一定越好。Vercel的经验是，把Agent的工具从15个砍到只剩2个，准确率反而从80%升到了100%。Stripe有大约500个MCP工具，但给每个Agent的，只是精心筛选过的子集。 ### 任务编排：给AI安排好工作计划 丢给AI一个大需求，它可能会一把梭全部搞定。但AI的上下文空间是有限的——开发到一半信息装不下了，前期定好的方案和约束慢慢被冲淡。 怎么解决？ 基本做法分几步：第一，Plan Mode——先让AI出方案，人工确认后再动手。第二，任务拆分——把大任务拆成小任务，每次只做一个功能点。第三，增量开发——每做完一个功能就沉淀文档（实现了什么、用了什么方案、还有哪些待办）。第四，SubAgents并行——多个互不依赖的小任务，可以让子Agent并行执行。 ### 反馈机制：让AI自己检查自己的工作 AI写完代码后，常常自信满满地说“完成了”，结果一运行，全是Bug。 所以得让AI自己检查：跑Linter查语法和规范问题，跑自动化测试验证功能是否正确，用Browser Use自己打开浏览器实际操作一遍，甚至让另一个AI来审查代码。如果测试没通过，AI可以自动读取报错信息、分析原因并尝试修复。 ### 架构护栏：防止代码越改越乱 AI生成代码有个特点：它会模仿仓库里已有的代码风格——哪怕是烂代码。同样的页面写了好几遍，也不懂得拆分成可复用组件。时间一长，技术债越滚越大。 怎么防止？ 用架构约束Linter——查的不是代码风格，而是架构规则，比如“UI层不能直接调用数据库层”。配置Pre-commit Hooks，提交前自动拦截不合规的代码。定期做“垃圾回收”，让AI扫描代码库，检查有没有偏离架构规范的地方，自动提交修复PR。还有Git检查点——每完成一个功能就提交一次，相当于打存档点。 --- ## 七个可以立刻上手的配置杠杆 理论说完了，来点实际的。这些技巧今天就能用： | 杠杆 | 做法 | 备注 | |------|------|------| | AGENTS.md | 每次AI犯错就加一条规则 | 控制在60行以内 | | 确定性约束 | Linter、类型检查、结构化测试 | 硬约束比软指令更可靠 | | 工具精简 | 只给AI最必要的工具 | 多了反而不知道该用哪个 | | Sub-Agent隔离 | 复杂任务拆分 | 防止中间噪声累积 | | 反馈循环 | AI自己跑测试、查日志 | 别什么都靠人工盯 | | CI限速 | 最多两轮CI | 失败就转人工 | | 垃圾回收 | 定期扫描技术债 | 代码量大了之后尤其重要 | --- ## 行业两大阵营：Big Model vs Big Harness Harness Engineering也不是没人唱反调——而且反对者来头不小。 ### Big Model阵营 核心观点很直接：模型能力的增长才是主旋律，Harness只是权宜之计。 OpenAI的Noam Brown在访谈中明确表态：**“千万别过度优化那些可能被下一轮模型进步淘汰的基础设施。”** 他的论据是：推理模型出现之前，开发者搭建了复杂的Agentic系统来模拟推理能力；推理模型一出来，这些基础设施一夜之间就不需要了。他的建议是：别花六个月搭建一个可能六个月后就被淘汰的东西。 ### Big Harness阵营 另一派的观点是：模型是引擎，Harness是方向盘和刹车。引擎再强，没有方向盘也到不了目的地。 LlamaIndex创始人Jerry Liu的话代表了这个立场：**“我们需要的是‘Engineer’，也就是真正能够组装和调试完整系统的人，而不仅仅是‘Prompter’。”** ### 护栏悖论 两边其实都对了一半。 这里有个有意思的观察：**车速越快，护栏越重要。** 时速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上也有了专门的论文。 --- ## 写在最后 有人发了个“暴论”：**“到2028年，Harness Engineering的重要性会超过模型训练。”** 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