2023 年，所有人在学怎么写 prompt。
2025 年，前沿的人开始讲 context engineering。
2026 年，一个新词出现了：Harness Engineering。
这不是营销概念。它来自一个真实的工程实验——OpenAI 的一个七人团队，用 Codex 智能体写了一个完整的生产级产品。零行手写代码，1500 个 Pull Request，一百万行代码，历时五个月。
这篇文章讲的就是：他们是怎么做到的，以及这件事对所有用 AI 写代码的人意味着什么。
三个时代
Prompt Engineering（2023-2024）：你怎么问
这是最早的阶段。你学会了用”请扮演一个高级工程师”开头，学会了 few-shot、chain of thought、角色扮演。你精心雕琢每一个词，测试不同的措辞，搜集别人分享的”万能 prompt”。
核心问题是：怎么用一段文字让模型给出最好的回答。
它有效，但有天花板。因为你只在优化一个变量——输入的那段文字。模型的上下文窗口就那么大，你的 prompt 写得再好，模型看不到项目的全貌，它的回答就是无根之木。就像你面试一个候选人，只给他看了一道题，却指望他理解你整个系统的设计哲学。
Context Engineering（2025）：你给模型看什么
Andrej Karpathy 在 2025 年提出了一个关键观点：与其优化 prompt，不如优化送给模型的上下文。不只是你的问题，还包括相关文档、代码库结构、工具定义、历史对话、甚至实时的运行指标。
这就是从”怎么问老师一个好问题”进化成了”怎么给老师一份完整的背景材料”。
这个转变带来了实实在在的能力跃升。RAG（检索增强生成）成了标配，MCP（Model Context Protocol）让模型可以动态连接外部工具和数据源，长上下文窗口让你可以把整个代码库塞给模型。
但当 AI 智能体开始真正自主执行任务时——自己读代码、自己跑命令、自己提 PR、自己决定下一步做什么——光给好的上下文就不够了。因为上下文解决的是”看见”的问题，不是”行为”的问题。一个智能体可以看见你所有的架构文档，但它照样可能写出违反架构的代码。看见规则和遵守规则，是两件事。
Harness Engineering（2026）：整个系统怎么运作
2026 年 2 月，HashiCorp 联合创始人 Mitchell Hashimoto 给了这个实践一个名字：”Engineer the Harness”——工程化那个套在 AI 外面的缰绳。
几天后，OpenAI 发布了那篇报告。再几天，Martin Fowler 跟进了分析文章。一篇 arXiv 论文对其做了形式化定义。这个概念在几周内从一个口头说法变成了一个有严肃工程实践支撑的学科方向。
Harness 不是 prompt，不是 context，而是包裹在 AI 智能体周围的整个运行环境：它能用什么工具，不能碰什么东西，犯错了怎么被纠正，人类怎么监控它，以及最关键的——它的错误如何被系统性地消灭，而不只是被个案修复。
OpenAI 的实验：零行手写代码造产品
这是目前最有说服力的案例。
OpenAI 的一个小团队——三名核心工程师——用 Codex 智能体从零构建了一个内部软件产品。五个月，大约 1500 个 PR，超过一百万行代码。没有一行是人手写的。
这个数字本身已经足够震撼。但真正值得关注的不是”AI 写了多少代码”，而是”人类做了什么让 AI 能写这么多代码”。
他们的 harness 包含三层：
第一层：增强的知识库。 不是简单的 README，而是一整套持续更新的项目文档——架构约定、命名规范、模块边界、数据结构定义。智能体每次开始工作前都会读取这些文件，就像新员工入职第一天先读公司 wiki。类似于 CLAUDE.md、.cursorrules 这些配置文件的高级版本。而且，他们让智能体也能访问生产环境的可观测性数据和浏览器——不只是读代码，还能看到代码跑起来的样子。
第二层：架构约束的强制执行。 这是最关键的一层。他们不靠”请遵守我们的架构”这种 prompt 来约束智能体，而是用确定性工具——自定义 linter、结构化测试（类似 Java 里的 ArchUnit）、pre-commit hook。智能体生成的代码必须通过这些门槛才能合入。通不过就打回，没有商量。
为什么这一层如此重要？因为他们发现了一个反直觉的事实：限制解空间反而让智能体更高效，而不是更低效。 当智能体可以生成任何代码时，它会浪费大量 token 探索死胡同。当 harness 定义了清晰的边界——只能用这些模式、只能依赖这些模块、接口必须长这样——智能体反而收敛得更快，产出质量更高。
这就像写十四行诗：格律的约束不是枷锁，而是让诗歌成其为诗歌的东西。
第三层：熵管理。 这是最有意思的部分。他们发现，AI 写代码时间长了会产生”熵”——文档和实际代码不一致、架构边界逐渐模糊、命名风格漂移、死代码累积。人类代码库也有这个问题，但 AI 生成的代码因为速度太快，熵的积累速度也快得多。
于是他们专门跑”垃圾回收”智能体，定期扫描项目，找出不一致的地方并修复。本质上，这是用 AI 来清理 AI 造成的混乱——一种自我维护的生态系统。
Mitchell Hashimoto 的原话：”每次你发现智能体犯了一个错误，你就花时间把解决方案工程化进系统里，让它永远不能再犯同样的错。”
这就是 harness 的核心哲学：把经验教训编码进环境本身，而不是编码进 prompt。 Prompt 是一次性的嘱咐，harness 是永久性的制度。
为什么 Prompt 不够用了
一个核心发现：模型不能可靠地评估自己的输出。
这和人类的盲点一样——你写了一段代码，你自己觉得没问题，但 code review 时同事一眼就看出了 bug。AI 也是如此。它生成的代码可能通过了功能测试，但违反了你团队的架构约定；可能风格一致，但引入了微妙的性能退化；可能单看每个 PR 都没问题，但连续一百个 PR 之后，系统的整体一致性已经悄悄崩塌了。
Anthropic 的研究也证实了这一点：模型在自我评估上存在系统性盲区。
Harness 的解决方案借鉴了 GAN 的思路：生成器和评估器分离。 一个智能体写代码，另一个智能体审查。审查者有不同的指令、不同的关注点、不同的检查清单。再加上确定性工具（linter、测试）作为最后一道防线。
这个模式意味着一个根本性的转变：你不再试图造一个完美的 AI 程序员，而是造一个有组织架构的 AI 编程团队——有人写、有人查、有制度兜底。
对你意味着什么
如果你现在用 Claude Code、Cursor 或者 Copilot 写代码，你可能已经在无意识地做 harness engineering 的初级版本了：
你写的 CLAUDE.md 或 .cursorrules？那是 harness 的知识库层。
你设的 pre-commit hook 和 lint 规则？那是 harness 的约束层。
你偶尔手动检查 AI 生成的代码是否偏离了架构？那是 harness 的熵管理层（只是手动的）。
三个时代不是替代关系，而是嵌套关系。Harness 包含 context，context 包含 prompt。你学会的东西都没浪费，只是需要一个更大的框架来组织它们。
但核心认知的转变是：停止优化 AI 本身，开始优化 AI 运行的环境。
这就像管理团队。你不会通过反复教一个实习生”请写好代码”来提升团队产出——你会建立代码规范、CI/CD 流程、code review 制度、架构文档、新人入职手册。好的管理者不创造依赖，创造系统。
AI 智能体，就是你的新队友。能力极强，产出惊人，但需要体系化的工程环境来保证质量。
Harness，就是那套工程环境。
而现在，这个学科才刚刚开始。