本文是最新的OpenAI Coding实践：Harness engineering: leveraging Codex in an agent-first world 的深度解读。这篇文章探讨了在“智能体优先”的时代，工程师如何通过定义环境与设定意图而非手动编写代码来重塑软件开发。核心理念在于人类负责舵向，智能体负责执行，即通过 Codex 驱动整个开发生命周期，从而实现开发效率的指数级提升。为了维持系统的长期稳定，团队将仓库知识视为事实标准，并建立了严格的机械化架构约束与自动化清理机制，以确保代码的易读性与一致性。该实验揭示了未来工程工作的重心将转向设计反馈回路与控制系统，利用智能体的高度自治来处理复杂的规模化软件维护。
欢迎来到智能体优先（Agent-first）的新世界。在过去的五个月里，OpenAI 的工程团队进行了一项极其疯狂且颠覆性的实验：他们发布了一款包含约一百万行代码的内部软件产品，而这其中没有一行代码是由人类手工编写的。这款产品并非玩具，它拥有内部的日常活跃用户和外部的 Alpha 测试者，经历了完整的发布、部署、崩溃和修复周期。今天，我们将深度揭秘这场彻底改变软件开发范式的实验背后的核心策略。
这组数据足以说明这种新范式的生产力爆发：在短短5个月的研发周期内，团队实现了人类手工编写代码量为 0 的创举，完全由智能体生成了上百万行的代码量。OpenAI 团队估计，采用这种方式的开发时间仅仅是传统手工编码的十分之一。最初只有3名工程师的团队，在几个月内处理了大约1500个Pull Request（代码合并请求），平均每位工程师每天产出3.5个PR，并且随着团队扩展到7人，这个吞吐量还在持续增长
为了实现这种数量级的效率提升，团队确立了一个核心限制条件和理念：“人类掌舵，智能体执行”（Humans steer. Agents execute.）。在这套模式下，软件工程师的角色被重新定义了。传统工程师的瓶颈在于手工编写每一行代码的时间；而在新模式下，工程师的核心任务变成了设计环境、说明意图，以及构建反馈闭环。由于人类不能直接写代码，工程师们必须专注于提供工具和脚手架，让 Codex 智能体能够可靠地完成工作
这个项目在2025年8月底从一个完全空白的代码仓库起步。没有任何预先存在的人类代码作为系统的锚点。最初的脚手架——包括目录结构、CI 配置、格式化规则、包管理器设置等，全部是由 Codex CLI 结合 GPT-5 生成的。甚至连指导智能体如何在这个仓库中工作的基础指南文件 AGENTS.md 也是由 Codex 自己编写的。团队定下了一条铁律：决不手动编写任何代码
随着代码吞吐量的飙升，人类的 QA（质量保证）能力成为了最大的瓶颈。为了突破这一点，团队决定大幅提升智能体对应用程序的“可读性”（Legibility），赋予它们感知能力。他们为每个 Git 工作树配置了独立的沙盒实例供 Codex 启动测试，甚至将 Chrome DevTools 接入了智能体运行环境，使其能够直接操作 DOM、截图和导航，从而让智能体能够自己复现 Bug 并验证修复。在深度观测方面，团队为 Codex 提供了短暂的本地观测栈，赋予其通过 LogQL 和 PromQL 查询日志与指标的权限。这种感知能力让单个 Codex 任务能够独立且持续地运行长达6个小时以上
在大型复杂任务中，上下文管理是最大的挑战之一。团队最初尝试写一个长达1000页的超长 AGENTS.md 文件，但很快就失败了：这会导致上下文挤兑、规则失效，并迅速沦为无人维护的僵尸文档。正确的做法是：给 Codex 一张地图，而不是一本说明书。团队将知识库放在结构化的 docs/ 目录中，而 AGENTS.md 被缩减到大约100行，仅仅作为一个目录，指向更深层的事实来源。这是一种“渐进式披露”策略，让智能体从一个小而稳定的入口开始，按需索取上下文，而不是开局就被信息淹没
要想让智能体高效工作，就必须明白一点：对于智能体而言，凡是它在运行时无法访问的内容，就不存在。外部的 Google Docs、Slack 讨论记录或人类大脑里的记忆，对智能体都是隐形的。因此，必须将所有的执行计划、架构决策记录等全部推送进 Git 仓库中，使其对智能体完全可读。在技术栈的选择上，团队倾向于使用“枯燥”但高度标准化的技术，为了让智能体拥有 100% 的上下文控制权，他们甚至会让智能体在仓库内重新实现特定功能（例如并发控制库），而不是引入不透明的外部第三方库
文档本身无法让全自动生成的代码库保持连贯。团队的策略是：不微操具体实现，只捍卫系统边界。他们建立了一个极其严格的“单向依赖法则”（Forward-Only Dependency Rule），要求代码只能按照固定的层级（Types → Config → Repo → Service → Runtime → UI）向前依赖，任何交叉引用都必须通过统一的 Providers 接口进入。这些边界约束是由 Codex 自行生成的定制 Linter 和结构化测试来强制执行的。这种机器检查使得架构规则能够在全量代码中瞬间、无情地被执行，从而防止了架构漂移
在智能体主导的高速环境中，代码产出的吞吐量远超人类注意力的极限，这迫使团队改变了传统的工程规范。在过去，设置严格的代码合并门槛是负责任的表现；但在这里，团队采用了非阻塞式关卡，大幅减少了合并的阻碍。Pull Request 的生命周期变得非常短，团队甚至容忍早期的测试波动（Flakes），因为在智能体环境中，修复错误的成本极低，而无休止地等待反而成本极高
当我们说代码库是由 Codex 智能体生成时，指的是仓库里的每一行代码和每一个组件。这不仅包括核心产品代码与测试，还覆盖了 CI/CD 自动化配置、发布工具、内部开发者工具、文档、生产环境监控大盘配置，甚至还包括代码审查评论与自动回复。人类的作用被提升到了一个全新的抽象层：主要负责定义验收标准、验证结果，以及在智能体遇到困难时识别缺失的工具和护栏
随着测试、验证、反馈等开发环节被直接编码到系统中，项目跨越了一个极其重要的里程碑：Codex 现在能够端到端地全自主开发新功能或修复 Bug。仅需人类提供一条提示词，智能体就能自动校验代码库状态、复现已报告的 Bug、录制失败情况的视频、实现代码修复、驱动应用验证修复结果、录制成功视频、提交 PR、自动处理人类或机器的审查反馈，直至最终合并代码。它只有在需要人类进行价值判断时才会进行升级求助
当然，完全的智能体自治也带来了前所未有的新问题：智能体会本能地复制仓库中已存在的模式，甚至包括那些不佳的模式。随着时间推移，这种微小的妥协会积累成巨大的代码熵增，产生大量的“AI废料”（AI Slop）。一开始，团队试图通过人力来解决，每周五耗费 20% 的时间手动清理这些废料。但事实证明，在智能体级别的产出速度面前，人力清理根本无法扩展，这套方案很快就失效了
为了彻底解决“AI废料”问题，团队将人类品味转化为了机器可读的机械规则，即“黄金原则”。他们设置了后台巡检智能体，这些 Codex 任务会在后台持续扫描偏离规则的代码。一旦发现问题，它们会自动生成极小粒度、几乎无需复杂审查即可自动合并的“微型重构 PR”。团队认识到，技术债就像高息贷款，不要等积累到爆雷才去痛苦地集中处理，而是应该像垃圾回收机制一样，通过智能体在后台每天进行极其高频的微调和持续清理
这5个月的实验带来了一个极具启发性的结论：构建复杂的软件依然需要极高的工程纪律，但这种纪律已经不再体现在手写代码的过程中，而是转移到了脚手架的搭建和工具链的设计上。随着大模型能力的不断增强，未来软件工程的核心竞争力将变成：如何设计优质的开发环境、构建高效的反馈闭环、以及打造稳健的控制系统。只有做好了这些基础设施，才能确保智能体不仅能快速产出，更能维持长期、大型系统的架构连贯性
在智能体优先的世界里，生产力的瓶颈已经被彻底打破。就像 OpenAI Codex 团队在实战中所感悟到的那样：在这个新时代，我们必须学会最大化我们唯一真正稀缺的资源——那就是人类的时间与注意力。将繁重的执行工作交给智能体，让人类的大脑回归到最纯粹的创造、系统设计和价值判断中去。感谢观看！
