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
• 作者：Ryan Lopopolo (OpenAI)
• 发布时间：2026年2月11日
• 相关播客：Latent Space 采访 Sherwin Wu

---

你觉得 Harness Engineering 会改变软件工程的本质吗？工程师的角色会如何演变？欢迎在评论区分享你的看法。