当 AI Agent 能端到端写出百万行代码，程序员的角色不是消失了，而是被推向了更高的维度。
这篇文章在讲什么
OpenAI 发布了一篇来自内部团队的实战复盘，讲述了他们如何用 Codex Agent（而非人工手写代码）从零构建一个百万行级别的全新产品。文章提出了一个核心范式——Harness Engineering（驾驭工程），即软件工程师的核心工作从”写代码”变成”为 AI Agent 搭建环境、定规则、建反馈循环”。
这个术语最早由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月提出，核心理念是：不去调模型参数，而是设计解决方案让”Agent 再也不犯同样的错误”。OpenAI 团队在实践中将这一理念系统化了。
一组惊人的数据
这组数字值得反复咀嚼：
- 团队规模： 3 人起步，后扩至 7 人
- 开发周期： 5 个月
- 代码产出： 约 100 万行（覆盖应用、测试、CI、文档）
- 合并 PR： 约 1,500 个，人均每天 3.5 个
- 效率提升： 耗时约为手动编写的 1/10
- 自治能力： Codex 可端到端开发完整特性，单次运行最长持续 6 小时
方法论的五根支柱
一、人类角色转型
工程师不再一行行写代码，而是做三件事：搭系统脚手架、精确描述意图、补全 Agent 缺失的能力。交互方式变成了通过 Prompt 描述任务，Agent 自动执行、自查、互查并提交 PR。
二、提升”可读性”（Legibility）
让 Agent 能”看见”系统的真实状态。团队接入了 Chrome DevTools Protocol，Agent 可以截图、操作 DOM、重现 Bug 并验证修复；在本地部署了日志/指标栈（LogQL/PromQL），Agent 可以直接查询性能数据并做优化——比如启动时间调优。
三、上下文与知识管理
这是最具实操价值的一部分。团队明确拒绝把所有规则塞进一个巨大的指令文件——信息会过时，关键要点会被淹没。取而代之的是”目录化策略”：AGENTS.md 只充当地图，指向结构化的 docs/ 目录，实现”渐进式披露”。所有知识（架构、计划、技术债）都必须版本控制在仓库内，原则是——”Codex 看不到的就不存在”。他们甚至专门设了一个”文档园丁”Agent，定期扫描并修复过时文档。
四、架构与品味的机械化执行
团队定义了严格的分层架构（Types → Config → Repo → Service → Runtime → UI），禁止跨层依赖，并通过自定义 Linter 和结构测试来机械执行这些约束——而非依赖人工代码审查。技术选型上倾向”无聊”但稳定的方案，甚至会重写第三方库来确保行为完全可控和 100% 测试覆盖。
五、熵管理与垃圾回收
Agent 会模仿它在仓库中看到的模式，包括不好的模式。如果不加管理，代码腐烂会以 Agent 的速度扩散。对策是：编码”黄金原则”（共享工具包、强类型边界），运行后台清理任务扫描偏差，通过自动化重构 PR 每日清除不良模式。文章的比喻很好——技术债务要像高息贷款一样，不断小额偿还。
实践建议
- 最小化阻断： 采用低门槛合并策略，快速迭代，纠正错误的成本低于等待的成本。
- 渐进式披露： 让 Agent 从稳定切入点开始，按需获取深层信息。
- 闭环反馈： 将人类审查意见、重构需求直接编码为工具规则或文档更新，由 Codex 自行实施修复。
这个转变对程序员意味着什么
这是一个对程序员要求提高而非降低的转变。
从蒸汽机的离心调速器（Governor），到 Kubernetes 的声明式控制器，再到今天的 Harness Engineering，本质上都是同一件事——你不再直接操控过程，而是设计一个系统去控制过程。但每一次这样的抽象层跃迁，对人的要求都是升高的。
写 Kubernetes spec 的人，需要比手动重启服务的人理解更多——你得懂网络模型、资源调度、状态收敛的原理，才能写出一份真正可靠的声明。同样的道理，Harness Engineering 时代的工程师，需要比”只写代码”的工程师拥有更高维度的能力：你得能设计分层架构并用 Linter 机械化执行，得理解熵增在代码库中如何扩散并建立自动对抗机制，得把隐性的工程经验显性化为 Agent 可消费的结构化知识。
过去一个程序员可以凭手感和经验写出”还行”的代码。但现在你要把这些手感和经验编码成规则、约束和反馈循环——这要求你先真正理解它们，才能形式化表达出来。能做的人和只能说的人之间的差距，会被这个范式急剧放大。
文章里那句”Codex 看不到的就不存在”其实很残酷。它意味着工程师脑子里那些”不言自明”的默会知识，如果你无法将其外化为文档、测试或工具链约束，在 Agent 眼中就等于零。这对工程师的系统思维和表达能力提出了极高的要求。
更宏观的视角：智能体工程的 8 个层级
Harness Engineering 并非孤立存在，它处于一个不断攀升的工程范式阶梯之中：
- Tab Complete — 基础的代码补全
- Chat IDE — 在 IDE 中与 AI 对话
- Context Engineering — 为 AI 精心组织上下文
- Compounding Engineering — 复合式工程能力
- MCP & Skills — 模型获得工具调用能力
- Harness Engineering — 为 Agent 设计环境与控制系统
- Background Agents — 后台持续运行的 Agent
- Agent Teams — 多 Agent 协作
从第 1 级到第 8 级，人类的角色从”自己写代码”逐渐过渡到”设计和管理一个 Agent 生态”。Harness Engineering 处于第 6 级，是从”使用 AI 工具”到”管理 AI 系统”的关键转折点。
核心结论
在 Agent-first 的世界里，软件工程的核心挑战不再是”怎么写代码”，而是”怎么设计一个控制系统，让 Agent 可靠地替你工作”。这包括构建可观测的环境、清晰的知识结构、机械化的架构护栏，以及持续对抗熵增的自动化流程。
对于工程团队而言，最直接的启发是：投资于环境和工具链（Linter、结构测试、文档自动化、可观测性），比投资于更好的 Prompt 回报更高。
这不仅仅是一篇技术文章，更像是对软件工程下一个十年的一份宣言。这个转变淘汰的不是程序员，而是那些只会”在键盘上把想法翻译成代码”的程序员。留下来的人，更像是控制系统的设计师。