2026 年 2 月，OpenAI 发了一篇工程博客 Harness Engineering: Leveraging Codex in an Agent-First World，讲了一个三人团队用 Codex 从空仓库开始、零人工编码、五个月长出百万行代码产品的故事。文章标题用了”Harness Engineering”，但正文只提了一次”harness”这个词，更像是事后起的名字。Martin Fowler 的评论文章猜测灵感可能来自 Mitchell Hashimoto 的博客。不管出处如何，这个词迅速被社区接受，因为它精确地命名了一件大家已经在做但还没有好名字的事。
什么是 Harness
Harness 的本义是马具——缰绳、鞍具、嚼子——一整套用来驾驭强壮但不可预测的动物的装备。隐喻很直白：
- 马是 AI 模型，力量大，速度快，但自己不知道该往哪跑
- 马具是基础设施——约束、护栏、反馈回路，把力量引向有用的方向
- 骑手是人类工程师，给方向，不亲自跑
没有 harness 的 Coding Agent 就是一匹在空旷草原上撒欢的纯血马：跑得漂亮，但哪儿也到不了。
Harness Engineering 的正式定义可以拆成四件事：
- 约束——Agent 能做什么（架构边界、依赖规则）
- 告知——Agent 该做什么（上下文工程、文档）
- 验证——Agent 做对了没（测试、lint、CI）
- 纠正——做错了怎么办（反馈回路、自修复机制）
和 Prompt Engineering 的区别在于层级：prompt engineering 关注单次交互的输入质量，harness engineering 关注整个系统——环境、约束、反馈、生命周期管理。上下文工程（context engineering）是 harness 的子集，不是全部。
模型是通用品，Harness 才是护城河
一个有说服力的数据点来自 LangChain：他们的 Coding Agent 在 Terminal Bench 2.0 上从 52.8% 跳到 66.5%，排名从 Top 30 蹿进 Top 5——模型没换，只改了 harness。加了启动时的目录结构映射、循环检测、完成前的自检清单、推理强度分层（规划和验证用高推理，实现用中推理）。同一匹马，换套马具，表现判若两人。
OpenAI 的实验是更极端的证据：3 名工程师（后扩到 7 人）、5 个月、约 1500 个 PR、约 100 万行代码、零人工编写。效率大约是手写的 10 倍。产品有几百个内测用户在日常使用。工程师的全部工作就是设计 harness——定义意图、提供反馈、而不是写代码。
三根支柱
综合 OpenAI 的实践和 Martin Fowler 的归纳，Harness Engineering 的核心结构可以分为三层。
上下文工程
从 Agent 的视角看，运行时访问不到的东西就不存在。Google Docs 里的决策、Slack 里的讨论、人脑中的共识——全在 Agent 视野之外。仓库里版本化的文件才是它的全部世界。
OpenAI 团队早期犯过一个典型错误：把所有规则塞进一个巨大的 AGENTS.md。失败原因很直觉——上下文窗口是稀缺品，指令文件太大会把任务描述和代码挤出去；什么都标”重要”等于什么都不重要；大文件迅速腐烂，过时规则堆成坟场。
最终方案：AGENTS.md 压到约 100 行只当目录，指向 docs/ 下的细分文档。Agent 从一个小入口进来，被一步步引向该看的地方。给 Agent 一张地图，别给千页说明书。
静态上下文之外，动态上下文同样关键。OpenAI 让应用支持按 git worktree 启动独立实例，把 Chrome DevTools 协议接进 Agent 运行时（Agent 能自己操作浏览器复现 bug），给每个 worktree 部署临时可观测性栈（Agent 用 LogQL 查日志、PromQL 查指标）。有了这些，“服务启动在 800ms 内”这类要求就不再是人肉验收，而是 Agent 自主验证的指标。
架构约束
光靠文档维持不了全 Agent 生成的代码库的一致性。核心策略：约束不变量，不管实现细节。
OpenAI 的做法是严格的分层架构——每个业务域按 Types → Config → Repo → Service → Runtime → UI 分层，依赖方向单向，横切逻辑（认证、遥测、功能开关）统一走 Providers 接口。这些约束通过自定义 linter 和结构测试强制执行，linter 本身也是 Codex 生成的。一个巧妙的细节：lint 规则的报错信息里直接写修复指令，Agent 看到报错的同时就拿到了怎么改的指南。
这类架构治理通常是几百人的大团队才会做的事。对 Coding Agent 来说是早期前提——没有约束，速度越快漂移越严重。在人的工作流里这些规则可能显得迂腐，对 Agent 来说是乘数效应：写一次，处处生效。
举个具体例子：团队要求在数据边界处做校验（Parse, don’t validate），但不指定用哪个库。模型自己偏好 Zod，那就 Zod。约束的是”什么必须做”，不是”怎么做”。
熵管理
Agent 会忠实复现仓库中已有的模式——包括不好的。时间一长，命名惯例分歧、文档与代码脱节、死代码堆积，熵增不可避免。
OpenAI 最初每周五花 20% 时间手动清理”AI 残渣”，很快扛不住。替代方案：把”黄金原则”编码进仓库，用后台 Codex 任务定期扫描偏差、更新质量评分、提重构 PR。大多数一分钟内审完自动合并。像垃圾回收一样，持续小额还技术债，永远好过攒到爆。
Martin Fowler 指出这是最被低估的一环。没有熵管理的 harness 会随时间衰败，Agent 开始复制越来越多的坏模式，形成恶性循环。
OpenAI 实验中的几个有趣细节
以上三根支柱是系统性的总结，OpenAI 原文中还有一些值得单独拎出来的观察：
- 吞吐量改变合并哲学。PR 生命周期很短，偶发测试失败靠重跑解决，不无限期阻塞。Agent 产出速度远超人类审查带宽，纠错成本低，等待成本高。低吞吐量环境下这么做不负责任，这个系统里通常是对的。
- 技术选型偏好”无聊”的技术。API 稳定、组合性好、在训练数据里充分出现的库对 Agent 更友好。有时让 Agent 自己重写一个功能子集，比引入外部库再绕过黑箱行为更划算。
- 单次 Codex 运行经常超过 6 小时，通常在人睡觉的时候。人类掌舵，Agent 执行——包括在深夜。
- Agent 已经能端到端完成一个功能：检查代码库 → 重现 bug → 录演示视频 → 修复 → 验证 → 再录视频 → 开 PR → 回应反馈 → 修构建 → 只在需要判断时升级给人 → 合并。但团队诚实地说，这高度依赖特定仓库的结构和工具，别指望开箱即用复制。
Martin Fowler 的延伸思考
Martin Fowler 在评论文章里提了几个有意思的推演：
Harness 会不会变成新一代服务模板？ 大多数组织只有两三个主要技术栈。未来团队可能从一组针对常见应用拓扑的 harness 模板起步，再根据自己的场景逐步调整——就像今天的 golden path service template，但包含了自定义 linter、结构测试、基础上下文文档和动态上下文接入。
技术栈会不会加速收敛？ 当写代码变成”引导 Agent 生成代码”，框架和 SDK 的人体工学依然重要（对人好用的东西对 Agent 通常也好用），但开发者的个人偏好会越来越不重要。团队可能会优先选择”AI 友好”的技术栈——有现成 harness、训练数据充足、API 稳定的那些。
Pre-AI 代码库 vs. Post-AI 代码库会分化吗？ 好的 harness 技术能回溯应用到老代码库吗？还是只对从零开始、一开始就按 harness 思路搭建的项目有效？老代码库通常非标准化、熵值高，硬套 harness 可能像对一个从没跑过静态分析的项目首次开启 linter——告警淹没一切。
被忽略的缺口：Fowler 指出 OpenAI 的文章几乎没涉及功能和行为层面的验证。他们讲了架构约束、文档一致性、代码风格，但”这个功能是否真的按预期工作”这个问题没有系统性回答。
一句话
OpenAI 团队自己说得最到位：最棘手的挑战不再是写代码，而是设计环境、反馈回路和控制系统。Harness Engineering 给这件事起了个名字。