摘要：OpenAI 的一个 3 人团队，5 个月内在不手写任何代码的情况下，用 AI Agent 构建了一个百万行级别的真实产品。这个实验揭示了"驾驭工程"的核心逻辑——不优化模型，而是优化模型运行的环境。
2025 年 8 月，OpenAI 的一个工程师团队在 GitHub 上建了一个空仓库。接下来的 5 个月里，这个仓库里出现了大约 100 万行代码、约 1500 个合并请求（PR），以及一个拥有数百名真实用户的内部 Beta 产品。但这些代码里，没有一行是人类手写的。
这场实验由 OpenAI 的 Codex 团队执行，团队初期只有 3 名工程师，后期扩展到 7 人。他们给自己定了一条硬约束：禁止手动编写任何源代码，所有代码、测试、CI 配置、文档和可观测性工具，全部由 Codex 自主生成。2026 年 2 月，OpenAI 将这场实验背后的经验沉淀为一套全新的工程方法论，并正式将其定名为——Harness Engineering（驾驭工程）。
不改模型，改环境
"Harness" 在工程领域的原意是线束、安全带——它连接并保护各个组件，但不替代组件本身的工作。LangChain 团队用一个公式概括了 Agent 和 Harness 之间的关系：Agent = Model + Harness。模型本身只是能力底座，若没有外围工程系统将其接入真实环境，它充其量只是一个“文本进、文本出”的孤立函数。
这正是驾驭工程与前两代 AI 工程方法论的关键区别。Prompt Engineering 解决的是“如何下达指令”，Context Engineering 解决的是“给模型喂什么上下文”。两者始终在模型的输入端打转，而驾驭工程的着眼点则是模型外围——通过构建约束机制、反馈回路与自动化纠错流程，让原本充满随机性的 AI，在确定的工程脚手架中稳定交付结果。
HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月的博客中最早用了 "Harness Engineering" 这个说法，他给出了朴素的定义："每当你发现 Agent 犯了一个错，就花时间设计一套解决方案，让 Agent 以后不再犯同样的错"。几乎同一周，OpenAI 的 Codex 团队发布了实验报告，用 100 万行代码证明了这套方法的可行性。
六条被验证过的原则
在这份实验报告中，OpenAI 并没有抛出宏大抽象的理论框架，而是直接提炼出了六条在实战中被反复验证的工程原则。
1. Agent 看不到的知识等于不存在
这句话看上去近乎常识，但在真实研发里却往往最容易被忽视。团队发现，大量关键信息散落在 Google Docs、Slack 对话和工程师的脑子里，对 Codex 来说，这些信息等同于不存在。就像一个新员工入职三个月，没人告诉他项目的隐性规则，他自然会犯错。
OpenAI 的做法是把所有决策、设计理由、架构约束全部编码进代码仓库。他们在仓库里维护了一个结构化的文档目录，包含架构说明、设计文档、执行计划、产品规格等。Agent 能读到的，才是真实存在的。
2. 给地图，不给百科全书
这是整个实验中最关键的认知转折。团队最初写了一份巨型的指导文档，把所有规则、约束和注意事项都塞进一个文件，结果 Agent 表现反而变差了——上下文被指令挤占，留给任务和代码的空间所剩无几。当所有内容都"重要"时，就没有重要的了。
最终方案是把入口文档 AGENTS.md 压缩到约 100 行，只充当一张"地图"，指向结构化的 docs/ 目录。Agent 从一个小而稳定的入口开始，按需深入。这和人类的学习方式类似：先看目录，再翻需要的章节，而不是一次啃完一整本教科书。
3. 用机械约束代替文档说教
要维持 Agent 生成代码库的连贯性，单靠文档是远远不够的。OpenAI 团队建立了一套严格的分层架构规则：在每个业务域内部，代码只能按固定方向依赖——Types → Config → Repo → Service → Runtime → UI。跨层调用被完全禁止。
通常这种严格的架构约束，只有在团队扩展到数百人时才需要。但在 Agent 驱动的开发中，它成了早期先决条件：Agent 的吞吐量远超人类，如果没有机械约束，架构漂移的速度会远超人类所能修复的速度。这些约束规则通过自定义的 Linter 和结构测试来强制执行，而这些 Linter 本身也是由 Codex 生成的。
4. 给 Agent 装上"眼睛"
Agent 写完代码后，怎么知道自己写得对不对？OpenAI 的答案是让它自己去看。团队把 Chrome DevTools Protocol 接入了 Agent 的运行时，让 Codex 能直接获取 DOM 快照、截图和页面导航。每次修改后，Agent 启动一个独立的浏览器实例，验证 UI 行为是否符合预期，并录制视频作为证据。
除了前端可视化，他们还为每个代码变更启动一套可观测性堆栈——日志、指标和追踪记录。Agent 可以直接用查询语句检查"服务启动时间是否在 800ms 以内"这类具体指标。有了这套能力，Agent 经常在单个任务上连续自主工作超过 6 小时，在人类睡觉的时候完成闭环。
5. 纠错而不是等待
当代码产出速度被 Codex 拔高到传统方式的数十倍后，团队发现，真正拖慢进度的已经不是写代码，而是审核代码。
过去几十年里，“代码合并前必须经过审核”被奉为圭臬。但在 Agent 时代，这种流程成了让整个研发管道阻塞的瓶颈。背后的逻辑很简单：Agent 修改代码速度很快，出错后重写的成本趋近于零；但如果让几百个 PR 堆在主干外排队等审批，这种“等待”本身就构成了极大的资源浪费。
为此，团队做了一次彻底的工程文化转向：拆除硬性卡点、极限缩短 PR 生命周期、用低成本的“重跑”代替高成本的“阻塞”，让代码像水一样快速流过主干。
6. 像 GC 一样清理技术债务
极高的代码产出率也伴随着一个极易被忽视的代价：Codex 会无差别地模仿仓库中的既有模式，连同那些次优的实现也一并照搬。随着代码规模的爆炸式增长，架构漂移与代码质量的整体劣化，正以远超传统人工开发的速度迅速累加。
实验初期，团队每周五要花 20% 的工作时间手动清理 Agent 产出的"垃圾代码"。这显然不可持续。最终的解决方案是引入一种类似"垃圾回收"的机制：后台 Codex 任务定期扫描偏离质量标准的代码，自动发起针对性的重构 PR。大多数清理 PR 可以在 1 分钟内完成。团队把这一经验形象地总结为：应该不断以小额贷款方式偿还技术债务，而不是等它复利后再痛苦地一次性清算。
这套方法真的有用吗？
尽管数据震撼，但驾驭工程并不是一个被普遍接受的范式。AI 工程社区 latent.space 在 3 月就提出了一个尖锐的问题："Is Harness Engineering real?"——Agent 取得的成绩，到底有多少是 Harness（工程框架）的功劳，又有多少仅仅是因为底层模型本身变强了？
一方面，在 METR 的测试中，Claude Code 和 Codex 并没有与基础脚手架拉开明显差距；Scale AI 的 SWE-Atlas 测试进一步表明，不同模型在两种 Harness 下的得分甚至会出现反转。这暗示在某些维度上，Harness 带来的性能波动可能只是误差范围内的噪声。
另一方面，LangChain 团队的实验发现：在 GPT-5.2-Codex 模型完全固定的前提下，仅通过优化 Harness，就能将 Terminal Bench 2.0 的成绩从 52.8% 提升至 66.5%，排名从 30 名开外跃升至前 5。
这种数据层面的冲撞，本质上反映了当前 AI 应用开发的核心路线分歧：资源投入的重心，究竟是寄希望于底层模型能力的自然涌现，还是通过外围工程去挖掘现有的能力杠杆。OpenAI 实验的真实贡献，或许不在于证明了"驾驭工程是唯一出路"，而在于展示了一种在当前模型能力下切实有效的工程方法，以及这种方法目前需要付出的代价。
当工程师不再写代码
让 Agent 深度接管开发流程，正在成为一线团队的共识。Stripe 公开的内部系统 Minions，每周能产出超过 1300 个完全由 Agent 生成、无人工干预的 PR。Anthropic 则将这种能力推向了更底层的工程：他们用 16 个并行 Agent 耗时两周生成了 10 万行 Rust 代码，完成了一个 GCC torture test 核心测试通过率达 99% 的 C 编译器。
这些案例的一个共性是：工程师的角色正在从"写代码的人"变成"设计规则的人"。OpenAI 在报告直言："构建软件仍然需要纪律，但纪律更多体现在脚手架的搭建上，而不是代码本身"。人类负责定义边界、编码品味、维护知识结构，Agent 负责在边界内高速执行。
但这并不意味着传统工程技能变得不重要。恰恰相反，OpenAI 团队认为驾驭工程对工程师的要求其实更高了——需要更强的架构判断力、对系统边界的直觉，以及把隐性经验显性化的能力。只是这些能力不再直接转化为代码行数，而是转化为 Agent 能理解的规则和约束。
写在最后
OpenAI 的这场实验，核心结论可以浓缩为一句话：在 Agent 优先的开发模式下，工程重心从代码实现转移到了环境设计。给 Agent 一张精简的地图而不是一本百科全书，用机械约束代替文档说教，让 Agent 自己看到运行结果等等。这些原则朴素到不像是技术创新，但它们确实让 3 个人在 5 个月内完成了通常需要数十人团队的工作量。
驾驭工程目前仍然面临质疑，它的适用边界也没有被充分验证。但在模型能力仍待提升的当下，它至少提供了一种务实的思路：与其等待 AI 变得更聪明，不如先想办法让现有的 AI 在一个更可靠的环境里工作。对正在接触 AI 编码的开发者而言，这可能是比追求更强模型更实际的一步。
