核心摘要：
随着 Prompt Engineering 和 Context Engineering 逐渐触及能力天花板，AI 圈在 2025 年初迸发出一个新概念——Harness Engineering。它不再执着于“对大模型说什么话”，而是站在系统层面，为大模型设计一整套稳定、可控、可自动化的工作环境。本文从马具比喻切入，梳理 Harness 的定义与公式，深度拆解 OpenAI 的百万行代码实战以及 Anthropic 的 Planner‑Generator‑Evaluator 经典架构，并围绕“是噱头还是范式的跃迁”进行全面讨论，最后给出对 AI 工程化未来走向的思考。

---

目录

1. Harness Engineering 的兴起背景
   • 关键词：Harness Engineering、Agent、系统架构
2. 前传：从 Prompt Engineering 到 Context Engineering
   • 关键词：提示词、上下文压缩、对话历史、上下文窗口
3. 什么是 Harness Engineering
   • 关键词：Harness 的定义、Agent‑Model 公式、约束与框架
4. 实战一：OpenAI 的 Harness Engineering 实践
   • 关键词：知识治理、代码仓库单一事实源、工具集成、验证闭环、技术债清理
5. 实战二：Anthropic 的 Planner‑Generator‑Evaluator 架构
   • 关键词：任务规划、质量评估、多 Agent 协作、模型能力进化
6. Harness Engineering 的争议与真实位置
   • 关键词：概念溯源、新瓶旧酒、过渡期技术、AI 工程化
7. 总结与思维导图

---

本节视频最想表达的核心观点

1. Harness Engineering 是一种系统级的工程方法，它不再只关注如何编写提示词或管理上下文，而是聚焦于“围绕大模型搭建一整套让它稳定运行的框架”。
2. Agent 的力量并不完全来自模型本身——OpenAI 在 5 个月内用 AI 写出近 100 万行生产级代码，真正的功夫在于精心设计 Harness（信息供给、验证反馈、技术债清理等）。
3. Anthropic 的实践展示了多 Agent 分工的价值：把任务规划、代码生成、质量评估分别交给不同的 Agent，显著提升了长周期任务的可靠性和产品质量。
4. Harness Engineering 所用的技术大多不是全新的，但它第一次把这些分散的能力组织成了一套可系统设计、可持续优化的工程方法论。
5. 随着模型能力的增强，一部分 Harness 设计会被模型“吃掉”，因此它可能是一个过渡期的关键角色，但在当前模型仍会犯错、仍有幻觉的现实下，其重要性不容忽视。

---

1. Harness Engineering 的兴起背景

2025 年 2 月之后，“Harness Engineering”在 AI 圈高频出现。OpenAI 专门发文讲述他们如何靠 Harness Engineering 在五个月内用 AI 生成近 100 万行代码；Anthropic 紧接着分享了它利用精心设计的 Harness 架构驱动 Agent 开发的实践；就连 Martin Fowler 的技术网站也开始公开讨论这个新词。与此同时，也有不少人质疑这不过是换汤不换药的噱头。那么，Harness Engineering 到底是什么？它和 Prompt Engineering、Context Engineering 又有怎样的关系？

---

2. 前传：从 Prompt Engineering 到 Context Engineering

在谈 Harness Engineering 之前，有必要先厘清它的两位“前任”。

2.1 Prompt Engineering：把话说清楚

Prompt 就是用户发送给大模型的话，而 Prompt Engineering 是一门研究如何精准表达需求的技术。举个例子，只问“帮我的猫起个名字”，模型可能会给出“花花”“小白”，但如果你的猫是橘色的，这两个名字就不贴切了。按照 Prompt Engineering 的理念，我们应该把 Prompt 改写为：“帮我的橘色小猫起名，两个字，需要体现它活泼爱玩的性格。”这样模型就能给出“橘宝”“橙豆”等更合适的答案。

不过如今 Prompt Engineering 很少被单独提起——一方面门槛太低，另一方面模型自身变强了，很多时候不需要费心调 Prompt 也能给出不错的结果。

2.2 Context Engineering：管理好给模型的信息

当你接着问“那它平时吃什么好呢？”，大模型必须知道“它”指代什么。这时发给模型的不仅包含这条新 Prompt，还包含之前的对话历史、工具列表、技能列表等，所有这些接收到的信息统称为 Context。然而 Context 有容量上限，不能无限制塞入内容。因此我们需要精心设计 Context 里放什么、怎么放，这就叫 Context Engineering。

经典的 Context Engineering 实践包括：上下文压缩（把过长的对话历史总结成一两段摘要）、动态检索外部资料、分步披露信息等。即便如此，很多人发现 Context Engineering 的效果终究有限，为了进一步压榨大模型潜力，AI 圈终于翻开了新的一页——Harness Engineering。

---

3. 什么是 Harness Engineering

3.1 从马具到系统约束

“Harness”的原意是马具——缰绳、头套这些套在马身上的器械。马虽然强壮，但如果没有马具，它就是一匹脱缰的野马，不可能为人所用。放到 AI 领域，大模型就像那匹马，如果任由它自由发挥，它会发散思维，产生严重幻觉，根本无法稳定地交付结果。因此我们必须像用马具控制马一样，用一套系统驾驭大模型，而这套系统就被称为 Harness。

3.2 Harness 的公式

由此可以推导出目前圈内比较认同的公式：

转化成文字：Harness = Agent − Model，即一个完整的 Agent 去掉大模型，剩下的所有部分都属于 Harness。例如在 Claude Code 中，那些写在 CLAUDE.md 里的规则、可用的工具、定时调度机制等，都属于 Harness。

而当我们将“Harness”加上“Engineering”，就自然得到了 Harness Engineering——一门专门研究如何构建与设计这套驾驭系统的技术。它不再盯着 Prompt 怎么写或 Context 怎么喂，而是站在系统层面，思考怎样为模型搭建一个可靠、可验证、可演进的运行环境。

三个概念的递进关系可以直观表示为：

---

4. 实战一：OpenAI 的 Harness Engineering 实践

2025 年 8 月，OpenAI 启动了一个实验：从零开始，让 AI 写一个真实的软件产品，包含业务逻辑、测试、CI 配置、文档等，全部由 AI 生成。最终项目达到近 100 万行代码，线上有真实用户，开发效率大约是纯人工的十倍。但实验初期的关键痛点并不在于模型智力，而在于 Harness 没搭好——Agent 经常走错方向、重复犯错。经过大量优化后，OpenAI 在 Harness Engineering 上的实践可以归纳为三大类：

4.1 信息供给：让 Agent 知道该知道的一切

新工程师需要了解代码规范、模块划分和历史决策才能开工，Agent 也一样。最初 OpenAI 试图把所有规范塞进一个超大 AGENTS.md 文件，结果发现内容过多会让模型迷失，且文件会逐渐腐化为过时信息的垃圾堆。后来他们把 AGENTS.md 压缩到约 100 行，仅作为一个目录，把真正的文档分门别类放在文件系统里，按需阅览。同时他们强制要求把所有重要决策和约定都搬进代码仓库，让仓库成为单一事实来源，Agent 才能“看见”那些曾散落在 Slack、Google Doc 甚至老员工脑子里的信息。

4.2 验证与反馈：闭环自愈的生成流水线

有了信息后，Agent 开始写代码。关键在于写完代码必须能够验证自己是否正确。OpenAI 为 Codex 配备了充分的工具：接入了 Chrome DevTools，让它能截图、检视 DOM、模拟用户操作来自行验证 UI；接入了完整的可观测性技术栈（日志、指标、链路追踪），代码跑在隔离环境中，任务结束后可自动销毁，这样 Codex 甚至能进行性能调优（如确保服务启动时间 ≤800ms）。

同时，为了保证代码符合架构规范，他们为项目划分了严格的分层依赖关系（UI→Runtime→Service→Raffle→ConfigTypes），并使用 Linter 和测试 构成自动化闭环：

通过几次循环，Agent 就能交出一份符合架构要求的代码。

4.3 技术债清理：自动维护代码与文档质量

Agent 大规模生成代码会不可避免地引入重复代码、偏离规范的写法。OpenAI 设置后台 Codex 任务定期扫描全仓库，自动修正问题并提交。同样，他们还用后台任务扫描文档，找出过时内容并自动修复。这样代码和文档都有了持续的“垃圾回收机制”，质量始终维持在高水平。

4.4 人与 AI 的新边界

通过五个月的实验，OpenAI 提炼出一条核心理念：Humans steer, agents execute（人类掌舵，Agent 干活）。软件工程师不再一行行写代码，而是为 Agent 构建稳定可靠的系统支撑框架，让重复、琐碎的开发任务在 Harness 里自动运行。这重塑了整个软件工程的开发流程。

---

5. 实战二：Anthropic 的 Planner‑Generator‑Evaluator 架构

Anthropic 通过两篇文章系统阐述了其 Harness 设计，核心集中在任务规划和质量评估两个维度。

5.1 任务规划：从一股脑到拆解执行

早期直接让 Agent 克隆整个 Claude.ai 聊天界面。需求太大，Agent 急于求成，想一口气做完所有功能，结果跑到一半上下文爆满，留下一堆烂摊子。后续接手 Agent 不清楚已完成度，草草收工。于是 Anthropic 引入了 Initializer Agent，专门负责拆解用户需求成详细功能列表，并编写启动脚本。后来的文章中，他们进一步把“需求拆解”这一核心职责独立为 Planner Agent。Planner 负责把用户的一句模糊需求扩展为完整清晰的功能清单，后续的执行 Agent 只需按功能点逐个完成。

5.2 质量评估：引入独立的第三方评估者

让 Agent 自我评估产出（王婆卖瓜）效果极差。人工评估效率又太低。Anthropic 的最终方案是：将生成代码与质量评估完全分离。负责生成代码的叫 Generator，负责评估的叫 Evaluator。工作流程如下：

这套方案被称为 Full Harness 方案，与之对应的是靠单个 Generator 独立完成的 Solo 模式。在制作一个游戏制作工具的任务对比中，Full Harness 在布局、产品逻辑、Bug 控制上明显优于 Solo，但耗时（6小时 vs. 20分钟）和费用（200美元 vs. 9美元）也远高于 Solo。这恰好印证了一个道理：精雕细琢需要付出更多代价。

5.3 模型能力进化对 Harness 的“侵蚀”

有意思的是，随着模型从 Sonnet 4.5 升级到 Opus 4.6，很多 Harness 设计变得不再必要。例如，Sonnet 4.5 在上下文过长时会出现“上下文焦虑”，急于结束任务，Anthropic 曾用“上下文重置”等 Harness 技巧来缓解；Opus 4.5 则大幅缓解了这个问题。再比如，早期强制 Generator 每次只做一个功能点的约束，在 Opus 4.6 中也被移除，因为模型自身的全局统筹能力已经足够强。这揭示了一个趋势：模型越强，需要的 Harness 越少，但 Anthropic 官方认为 Harness 只会变形而不会消失。

---

6. Harness Engineering 的争议与真实位置

6.1 概念溯源：从私人说法到行业热词

“Harness”本身并非新词，测试领域早就有 Test Harness，AI 圈也有 LM Evaluation Harness 等用法。但“Harness Engineering”这个组合真正被引爆，可以追溯到 2025 年 2 月 5 日 Mitchell Hashimoto 发表的博文《My AI Adoption Journey》，他自我调侃“姑且叫它 Harness Engineering 吧”。随后 2 月 11 日 OpenAI 发表了同名词文章，标题信息量极大，迅速引爆讨论。6 天后 Martin Fowler 网站发表相关文章，3 月 10 日 LangChain 明确给出了 Harness 的公式，3 月 24 日 Anthropic 的经典三 Agent 架构彻底将 Harness Engineering 推至教科书级案例。

6.2 批评的声音：新瓶旧酒与注定被淘汰

质疑者指出两个核心论点：

1. 没有新技术：Linter 检查、任务拆解、质量评估这些都早已存在，Harness Engineering 只是把老技术打了个包。特意造新词宣传，有炒作之嫌。
2. 所有 Harness 迟早会被模型“吃掉”：随着模型能力持续增强，今天用来约束、兜底、引导的 Harness 设计会被模型自身的能力逐步吸收，最终变得不再必要。

6.3 我的观点：不是噱头，但很可能只是过渡

Harness Engineering 并不是噱头，因为 OpenAI 和 Anthropic 确实通过它大幅提升了 Agent 的稳定性和生产力，这是可验证的工程成果。工程领域的真正进步往往不在于发明单点新技术，而在于能否用一套统一的框架将零散的能力组织成可持续优化的方法论——Harness Engineering 恰恰完成了这一步。

但我也认同，Harness Engineering 大概率不是终局。模型越强，需要的“人工 Harness”就越少，它可能会逐步退化为一个基础环境接口。然而，在今天这个模型仍然会犯错、会产生幻觉、会在复杂任务中偏航的阶段，谁把 Harness 搭得更稳，谁就能更早把 AI 能力转化为真正的生产力。因此，它是一种当下的最现实解，也是通往更遥远的未来 AI 工程化的必经渡口。

---

7. 总结与思维导图

从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering，人们对 AI 的控制方式完成了从“说什么话”到“给什么信息”再到“建什么系统”的三级跳。Harness Engineering 将工程师的角色从代码生产者转变为系统设计者，让 AI 在精心设计的环境中高效、稳定地工作。尽管它所用的许多技术并非全新，也可能随着模型进化而改变形态甚至部分消亡，但它在当前 AI 工程化的进程中，扮演着不可替代的角色。

思维导图：Harness Engineering 全景

---

说明：本文提炼自视频《Harness Engineering 到底是什么？概念、实战与争议，一次全部讲清楚》，在保留核心信息与技术逻辑的基础上做了书面化梳理与图表补充。对文中提到的 OpenAI 和 Anthropic 详细文章感兴趣的读者，强烈建议阅读原文，以获取更深入的技术细节。