OpenAI最近发表了一篇开创性的文章，详细介绍了他们为期五个月的”Harness Engineering”实验——构建一个完全没有人工编写代码的完整软件产品。本文将对这项实验进行全面分析，从空仓库到百万行代码库的旅程，揭示智能体优先开发、上下文管理以及AI驱动世界中软件工程未来的关键洞察。
AI 生成内容声明： 本文的内容由生成式 AI 研究、编写和审查。由于大型语言模型可能存在”幻觉”，信息可能包含一些不准确之处。建议读者自行判断技术信息的准确性和相关性。
- 引言：软件工程的范式转移
- 实验概况：从零到百万行的旅程
- 智能体优先开发的核心理念
- 上下文管理：最大的挑战
- 为智能体设计的架构：约束赋能速度
- 质量保证的演化
- 开发工作流程的革命
- 技术债务与AI”残渣”管理
- 关键教训与最佳实践
- 智能体优先开发的未来
- 结论
引言：软件工程的范式转移
OpenAI进行了一项为期五个月的实验，从根本上挑战了我们对软件工程的理解。他们的团队构建并交付了一个内部测试版软件产品，其中没有任何一行代码是由人类编写的。从应用逻辑、测试、CI配置、文档、可观测性到内部工具——所有内容都是由Codex生成的。
核心哲学
- “不手动编码”：成为团队的核心原则
- 人类为架构师，智能体为构建者：工程师专注于设计环境、澄清意图和构建反馈回路
- 10倍加速：估计只用了手工编码所需的大约1/10的时间
实验概况：从零到百万行的旅程
数据讲述的故事
| 指标 | 数值 | 意义 |
|---|---|---|
| 时间跨度 | 5个月（2025年8月-2026年1月） | 完整的产品生命周期 |
| 代码库大小 | 约100万行 | 从空仓库到生产系统 |
| 拉取请求 | 约1,500个打开和合并的PR | 高速度开发 |
| 团队规模 | 从3人开始，增长到7名工程师 | 可扩展的方法 |
| PR吞吐量 | 每位工程师每天处理3.5个PR | 卓越的生产力 |
| 活跃用户 | 数百名内部测试用户 | 真实世界验证 |
开发速度洞察
- 初始架构（仓库结构、CI配置、格式化规则、包管理器设置、应用框架）由Codex CLI使用GPT-5生成
- 初始的AGENTS.md文件本身也是由Codex编写的
- 零预先存在的人工编写代码：仓库从一开始就由智能体塑造
- 吞吐量增加：随着团队从3人增长到7人，与传统团队扩展挑战相反
智能体优先开发的核心理念
重新定义工程角色
实验揭示了软件工程角色的根本性转变：
传统工程 → 智能体优先工程
- 编写代码 → 设计环境
- 调试问题 → 澄清意图和约束
- 代码审查 → 构建反馈回路
- 实现 → 系统和架构设计
深度优先的工作方法
当进展缓慢时，解决方案从来不是”再努力一点”。相反，工程师们问：
“究竟缺少什么能力，我们如何使它既清晰可读又对智能体可强制执行？”
这导致了深度优先的工作风格：
- 将更大的目标分解为更小的构建块
- 提示智能体构建这些块
- 使用完成的块解锁更复杂的任务
- 持续识别并解决缺失的能力
人-智能体交互模型
- 人类几乎完全通过提示交互：工程师描述任务，运行智能体，并允许它们打开拉取请求
- 智能体驱动的PR完成：Codex在本地审查自己的更改，请求额外的智能体审查，回应反馈，并迭代直到所有审查者满意
- 智能体对智能体审查：随着时间的推移，几乎所有审查工作都转移到了智能体对智能体的处理
- 直接工具集成：Codex使用标准开发工具（gh、本地脚本、仓库嵌入的技能）而无需人工复制粘贴
上下文管理：最大的挑战
失败的”大型AGENTS.md”方法
OpenAI团队最初尝试创建一个全面的AGENTS.md文件，由于以下几个原因而失败：
| 问题 | 描述 | 影响 |
|---|---|---|
| 上下文稀缺 | 大型指令文件挤占了任务、代码和文档 | 智能体要么错过关键约束，要么针对错误的约束进行优化 |
| 无效的指导 | 当一切都”重要”时，一切都不重要 | 智能体在本地进行模式匹配，而不是有意识地导航 |
| 即时腐坏 | 综合手册变成了陈旧规则的坟场 | 智能体无法确定哪些信息仍然有效 |
| 验证困难 | 单个blob不适合进行机械检查（覆盖率、新鲜度、所有权） | 漂移变得不可避免 |
成功的方法：地图而非手册
他们没有创建百科全书，而是创建了一个内容目录：
知识库结构
1
2
3
4
5
6
docs/
├── architecture/ # 领域和包层地图
├── design-docs/ # 经过验证的设计决策
├── execution-plans/ # 带有进度日志的版本控制计划
├── technical-debt/ # 已知问题和债务跟踪
└── principles/ # 核心智能体优先操作原则
AGENTS.md作为导航
- 简短（≈100行）：作为地图注入上下文
- 渐进式披露：智能体从一个小而稳定的入口点开始，并被告知下一步该去哪里看
- 结构化验证：专职的linter和CI作业验证知识库的新鲜度、交叉链接和结构
- 自动维护：”文档园丁”智能体扫描过时文档并创建修复PR
关键洞察
“从智能体的角度来看，它在运行时无法在上下文中访问的任何东西都是不存在的。”
这导致了将更多上下文推送到仓库中的原则：
- 关于架构模式的Slack讨论
- 产品原则和工程规范
- 团队文化（包括表情符号偏好）
- 所有内容都必须版本化并可在仓库中访问
为智能体设计的架构：约束赋能速度
严格的分层架构
OpenAI发现，智能体在具有严格边界和可预测结构的环境中最为有效：
业务领域层
1
类型 → 配置 → 存储库 → 服务 → 运行时 → UI
关键架构规则
- 固定的依赖方向：代码只能”向前”依赖层
- 横切关注点：认证、连接器、遥测、功能标志通过单一明确接口（提供者）进入
- 机械执行：自定义linter和结构测试（由Codex生成）执行所有约束
架构悖论
“这通常是等到有数百名工程师时才推迟的架构。对于编码智能体来说，这是一个早期的前提条件：约束使速度不会降低，架构不会漂移。”
实践实施
- 自定义linter：静态强制执行结构化日志记录、命名约定、文件大小限制、特定平台的可靠性要求
- “品味不变式”：错误消息被编写为在智能体上下文中注入修复指令
- 边界内的本地自治：类似于领导一个大型工程平台组织 - 在中心层面强制执行边界，在本地层面允许自主
质量保证的演化
演化的QA实践
传统工程规范演变为匹配智能体吞吐量：
| 传统实践 | 智能体优先适应 |
|---|---|
| 阻塞合并门 | 最小化阻塞；PR寿命短 |
| 调查不稳定的测试 | 后续重跑解决不稳定失败 |
| 错误的高成本 | 纠正的低成本，等待的高成本 |
| 人类密集型审查 | 智能体对智能体审查，仅在需要时进行人类监督 |
QA瓶颈的转移
随着代码吞吐量增加，瓶颈从代码生成转移到人工QA能力。解决方案：使更多的系统方面能够直接被Codex读取：
可观测性集成
- 应用UI：Chrome DevTools协议集成到智能体运行时
- 日志和指标：本地可观测性栈暴露给Codex
- 临时环境：Codex运行在完全分离的应用程序版本上，任务完成后删除
- 查询能力：LogQL用于日志，PromQL用于指标
实践示例
- “确保服务启动在800ms内完成”
- “这四个关键用户旅程中的任何跨度都不应超过两秒”
- “复现此错误并验证修复”
开发工作流程的革命
端到端智能体能力
仓库跨越了一个重要的门槛，现在Codex可以端到端地驱动新功能：
完整的功能开发流程
- 验证代码库的当前状态
- 复现报告的漏洞，录制故障视频
- 实施修复措施
- 通过运行应用程序验证修复
- 录制解决方案演示视频
- 打开拉取请求
- 回应智能体和人类反馈
- 检测并修复构建故障
- 仅在需要判断时交由人类处理
- 合并更改
智能体生成的工件
由Codex智能体生成的代码库包括：
- 产品代码和测试
- CI配置和发布工具
- 内部开发工具
- 文档和设计历史
- 评估框架
- 审查评论和回复
- 管理仓库本身的脚本
- 生产仪表板定义
人类角色的演化
人类仍然参与但处于不同的抽象层次：
- 优先处理工作
- 将用户反馈转化为验收标准
- 验证结果
- 识别缺失的能力（工具、指导、约束、文档）
技术债务与AI”残渣”管理
“AI残渣”问题
Codex复制仓库中已存在的模式 - 包括不均匀或不理想的模式。随着时间的推移，这不可避免地导致漂移。
初始（失败）方法
- 手动清理：团队每周五（一周的20%）花费时间清理”AI残渣”
- 不可扩展：人类密集型方法无法跟上智能体吞吐量
成功的策略：”黄金原则”
他们没有进行手动清理，而是将主观但机械的规则编码到仓库中：
示例黄金原则
- 偏好共享的实用工具包而不是手写的辅助工具，以集中不变式
- 不使用”YOLO式”数据探测 - 验证边界或依赖类型化SDK
- 定期后台Codex任务扫描漂移，更新质量评级，并创建有针对性的重构PR
技术债务的类比
“技术债务就像高息贷款：最好通过持续的小额分期付款来偿还债务，而不是让它不断累积，然后痛苦地一次性解决。”
持续质量改进
- 每日模式发现：不良模式每天被发现和解决，不被允许传播数天或数周
- 自动化重构：大多数重构PR可以在几分钟内自动审查和合并
- 类似垃圾回收的功能：定期清理防止积累
关键教训与最佳实践
实验中的主要教训
| 教训 | 描述 | 含义 |
|---|---|---|
| 上下文为王 | 给智能体一张地图，而不是一本手册 | 渐进式披露优于信息过载 |
| 约束赋能速度 | 严格的边界防止架构漂移 | 早期的架构纪律会带来回报 |
| 人类判断的可扩展性 | 将人类品味编码为机械规则 | 主观偏好成为客观约束 |
| 工具集成至关重要 | 使系统可直接被智能体读取 | 消除人类翻译层 |
| 纠错与预防 | 在高吞吐量系统中，纠正比预防更便宜 | 为速度优化，而非完美 |
智能体优先开发的最佳实践
- 从架构开始
- 早期定义严格的层和依赖规则
- 从第一天开始机械地执行约束
- 为智能体可导航性而构建，而不仅仅是为人类可读性
- 结构化你的知识
- 创建一个docs/目录作为记录系统
- 保持AGENTS.md简短（≈100行）作为导航地图
- 实现信息的渐进式披露
- 编码人类判断
- 将主观偏好转化为客观规则
- 创建可机械执行的”黄金原则” - 在错误消息中使用自定义linter和修复指令
- 深度集成工具
- 使可观测性工具可直接被智能体访问
- 使智能体能够与UI、日志和指标交互
- 允许智能体直接使用标准开发工具
- 持续管理技术债务
- 实施定期的”垃圾回收”周期
- 使用后台智能体扫描漂移并创建修复PR
- 通过持续的小额分期付款偿还技术债务
智能体优先开发的未来
未解答的问题
实验为未来提出了几个重要问题：
- 随时间推移的架构一致性
- 架构将如何在完全由智能体生成的系统中演化？
- 哪些模式将作为主导或有问题出现？
- 人类判断优化
- 人类判断在哪里提供最大价值？
- 我们如何更好地编码这种判断以获得更大的杠杆作用？
- 模型演化的影响
- 越来越强大的模型将如何改变系统？
- 哪些新能力将变得可能或必要？
纪律的转移
“构建软件仍然需要纪律，但纪律更多地体现在支撑结构上，而不是代码上。”
现在最具挑战性的问题集中在：
- 设计环境 以帮助智能体实现目标
- 构建反馈回路 以在规模上保持质量
- 创建控制系统 用于复杂、可靠的软件
结论
OpenAI的harness engineering实验代表了软件开发的一个分水岭时刻。通过证明一个完整的软件产品可以在没有任何人类编写代码的情况下构建，他们验证了软件工程的新范式。
关键要点
-
智能体优先是可行的：实验证明智能体优先开发不仅是可能的，而且可以具有很高的生产力（10倍加速）。
-
上下文管理至关重要：成功的智能体协作需要通过结构化知识库和渐进式披露仔细管理上下文。
-
架构赋能规模：通常推迟到大团队规模的严格架构约束成为有效智能体协作的先决条件。
-
人类角色的演化：工程师从编写代码转向设计环境、澄清意图和构建反馈回路。
-
持续质量管理：技术债务和”AI残渣”需要持续、自动化的管理策略，而不是定期的手动清理。
前进的道路
随着像Codex这样的AI智能体在软件生命周期中占据越来越重要的位置，这项实验提出的问题将变得越来越重要。软件工程的未来不在于编写代码，而在于设计使智能体能够有效构建软件的系统、环境和反馈回路。
软件工程学科正在从工艺演变为编排——从编写代码行到设计编写代码的系统。这种转变代表了软件行业的一个深刻挑战，也是一个前所未有的机遇。
参考链接：
