Harness Engineering：当 AI 光速写代码，人类工程师还剩什么？

## 一、一个疯狂的实验 OpenAI 最近做了一个实验： **从空 Git 仓库开始，5 个月内构建一个真实可用的软件产品，全程 0 行人工手写代码。** 这个产品： - 有内部日活用户 - 有外部 alpha 测试者 - 会部署、会崩溃、会被修复 - 累计约 **100 万行代码** - 约 **1500 个 PR** - 仅 **3 名工程师**驱动 Codex 估算交付速度约为传统手写的 **1/10**。 这不是科幻小说，这是 OpenAI 内部正在发生的事。 ## 二、Harness Engineering：当 AI 光速写代码 这个实验催生了一个新概念：**Harness Engineering（Harness 工程）**。 传统软件工程：人类写代码，AI 辅助。 Harness Engineering：**人类设计环境，AI 执行**。 工程师的角色彻底转变： - 不再是"写代码的人" - 而是"设计环境、指定意图、构建反馈循环的人" ## 三、核心原则 ### 1. 没有手动代码 这是实验的核心约束。 从第一行代码到 CI 配置、测试、文档、可观测性、内部工具——全部由 Codex 生成。 甚至最初的 `AGENTS.md` 文件（指导 Agent 如何在仓库中工作）也是 Codex 写的。 ### 2. 工程师的新工作 当 AI 写所有代码时，工程师做什么？ **深度优先工作法：** 1. 将大目标分解为小构建块（设计、代码、审查、测试等） 2. 提示 Agent 构建这些块 3. 用它们解锁更复杂的任务 当失败时，修复方式不是"再试一次"，而是问："缺少什么能力？如何让它对 Agent 既可理解又可执行？" ### 3. 渐进式披露 OpenAI 最初尝试了"一本大 AGENTS.md"的方法——把所有知识塞进一个文件。 **失败了。** 原因： - 上下文是稀缺资源，大文件挤占了任务空间 - 太多指导等于没有指导，Agent 开始局部模式匹配 - 单体手册瞬间腐烂，Agent 无法分辨什么还成立 - 难以验证，漂移不可避免 **解决方案：** 把 `AGENTS.md` 当作**目录**，而不是百科全书。 ``` AGENTS.md ARCHITECTURE.md docs/ ├── design-docs/ ├── exec-plans/ ├── generated/ ├── product-specs/ ├── references/ ├── DESIGN.md ├── FRONTEND.md ├── PLANS.md ├── PRODUCT_SENSE.md ├── QUALITY_SCORE.md ├── RELIABILITY.md └── SECURITY.md ``` Agent 从小的、稳定的入口点开始，被教导去哪里找下一步信息，而不是被信息淹没。 ### 4. 让应用对 Agent 可读 随着代码吞吐量增加，瓶颈变成了人类 QA 容量。 解决方案：**让应用 UI、日志、指标直接对 Codex 可读**。 - 让每个 git worktree 都能启动应用实例 - 将 Chrome DevTools Protocol 接入 Agent 运行时 - 创建处理 DOM 快照、截图、导航的技能 - 日志、指标、追踪通过本地可观测性栈暴露给 Codex - Agent 可以用 LogQL 查询日志，用 PromQL 查询指标 这让提示如"确保服务启动在 800ms 内完成"或"关键用户旅程中没有 span 超过 2 秒"变得可行。 ### 5. 强制执行架构和品味 仅靠文档无法保持全 Agent 生成代码库的一致性。 **通过强制执行不变量，而不是微观管理实现。** 例如： - 要求 Codex 在边界解析数据形状，但不规定如何实现（模型喜欢用 Zod，但没有指定具体库） - 每个业务域分为固定层集，严格验证依赖方向 - 代码只能"向前"通过固定层集（Types → Config → Repo → Service → Runtime → UI） - 跨切面关注点（auth、connectors、telemetry）通过单一显式接口 Providers 进入 这些约束通过自定义 linter（当然是 Codex 生成的！）和结构测试强制执行。 ### 6. 吞吐量改变合并哲学 随着 Codex 吞吐量增加，许多传统工程规范变得适得其反。 - 最小化阻塞合并门 - PR 短生命周期 - 测试 flaky 通常用后续运行解决，而不是无限期阻塞进度 在 Agent 吞吐量远超人类注意力的系统中，**修正是廉价的，等待是昂贵的**。 ### 7. 熵与垃圾回收 全 Agent 自主也引入了新问题。Codex 复制仓库中已存在的模式——包括不均衡或次优的模式。随着时间推移，这不可避免地导致漂移。 最初，人类每周五花 20% 时间清理"AI slop"。 unsurprisingly，这无法扩展。 **解决方案：编码"黄金原则"并构建定期清理流程。** 例如： 1. 优先使用共享工具包而不是手写 helper，保持不变量集中 2. 不"YOLO 风格"探测数据——验证边界或依赖类型化 SDK 定期让后台 Codex 任务扫描偏差、更新质量等级、打开针对性重构 PR。大多数可以在 1 分钟内审查并自动合并。 这像垃圾回收。技术债务像高息贷款：**持续小额偿还几乎总是比让复利积累然后痛苦地一次性解决更好。** ## 四、Agent 可读性是关键 因为仓库完全由 Agent 生成，它首先针对 Codex 的可读性优化。 从 Agent 的角度看，**运行时无法访问的上下文实际上不存在**。活在 Google Docs、聊天线程或人们头脑中的知识对系统不可访问。 仓库本地、版本化制品（代码、markdown、schema、可执行计划）是它能看到的全部。 **那个对齐团队的 Slack 讨论？** 如果对 Agent 不可发现，它就像 3 个月后加入的新员工不知道一样不可读。 给 Codex 更多上下文意味着组织和暴露正确信息，让 Agent 能够推理，而不是用临时指令淹没它。 ## 五、工程师角色的重新定义 Sherwin Wu（OpenAI API 与开发者平台工程负责人）描述了这个转变： > "IC 工程师正在变成技术负责人，基本就像是管理者一样。他们在管理一整支又一整支的 agent'舰队'。" OpenAI 的工程师现在： - 同时处理 **10 到 20 条并行线程** - 不断查看进度、调整方向、给 Agent 提反馈 - 工作从"写代码"变成了"管理" **95% 的工程师每天使用 Codex，100% 的 PR 被 Codex 审查。** 使用 Codex 更多的工程师，提交的 PR 数量比同事高出 **70%**，而且这个差距还在扩大。 ## 六、代码审查的革命 Codex 审查 100% 的 PR。 这让代码审查从 **10-15 分钟** 的任务，变成很多时候 **2-3 分钟** 就能搞定——因为 Codex 已经提前把一堆建议"烤"在里面了。 人类对 PR 的注意力从 **100% 降到 30%**。 **但谨慎很重要。** 大多数工程师仍会自己看一眼 PR，不是说人类审查彻底归零了。 ## 七、自主性的层级提升 随着更多开发循环被编码进系统——测试、验证、审查、反馈处理、恢复——仓库最近跨过了有意义的阈值： **给定单个提示，Agent 现在可以：** 1. 验证代码库当前状态 2. 复现报告的 bug 3. 录制视频演示失败 4. 实现修复 5. 通过驱动应用验证修复 6. 录制第二个视频演示解决 7. 打开 PR 8. 响应 Agent 和人类反馈 9. 检测和修复构建失败 10. 仅在需要判断时升级给人类 11. 合并变更 这依赖于仓库的特定结构和工具投资，不应假设能泛化——至少，还不是。 ## 八、我们还在学习什么 这个策略在内部发布和 OpenAI 采用方面效果很好。构建真实产品给真实用户帮助锚定投资在现实中，并指导长期可维护性。 **还不知道的：** - 全 Agent 生成系统的架构一致性如何随年演进 - 人类判断在哪里增加最大杠杆，如何编码那种判断让它复利 - 随着模型能力继续提升，系统如何演进 **已经清楚的：** 构建软件仍然需要纪律，但纪律更多体现在**脚手架**而不是代码上。保持代码库一致性的工具、抽象和反馈循环越来越重要。 最困难的挑战现在集中在设计环境、反馈循环和控制系统，帮助 Agent 完成目标：**大规模构建和维护复杂、可靠的软件**。 ## 九、给开发者的建议 当 Agent 像 Codex 承担软件生命周期更大部分时，这些问题会更重要。 OpenAI 的早期教训： 1. **从简单开始** —— 不要构建庞大的控制流 2. **构建可删除的** —— 架构模块化，新模型会取代你的逻辑 3. **Harness 即数据集** —— 竞争优势不再是提示，而是捕获的轨迹 4. **让 Agent 可读** —— 仓库知识是系统记录 5. **强制执行不变量** —— 不是微观管理实现 6. **接受熵** —— 建立垃圾回收机制 ## 十、结语：巫师与魔法帽 Sherwin Wu 用《幻想曲》里的《魔法师学徒》作比喻： 你戴上魔法帽开始施法，力量强得离谱，但前提是：**你得清楚自己在做什么**。 米老鼠让扫帚去干活，自己转身就睡，结果扫帚越干越多、洪水失控、屋子直接被淹——这几乎就是 vibe coding 的极限形态：**愿望实现得太快，失控也来得太快**。 当工程师同时跑着 20 个 Codex 线程时，想到的不是"爽"，而是这背后其实需要**技能、资历和大量判断力**。 你不能彻底放手不管，也不能假装一切都会自动变好。 但它的杠杆率也确实高得惊人。一个真正把这些工具用顺了的资深工程师，现在能完成过去根本不可能完成的工作量。 **我们真的开始有一种很具体的感觉——自己像个巫师在施法，而软件在替我们跑腿、替我们干活。** 那种"魔法感"，前所未有地接近现实。 --- ## 参考 - 原文：[Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/) - 作者：Ryan Lopopolo (OpenAI) - 发布时间：2026年2月11日 - 相关播客：Latent Space 采访 Sherwin Wu --- *你觉得 Harness Engineering 会改变软件工程的本质吗？工程师的角色会如何演变？欢迎在评论区分享你的看法。*