转载说明：本文基于 OpenAI 文章《Harness engineering: leveraging Codex in an agent-first world》（Ryan Lopopolo，2026-02-11）进行完整中文翻译与整理。原文地址：https://openai.com/index/harness-engineering/Harness 工程：在 Agent-First 世界中驾驭 Codex 作者：Ryan Lopopolo（OpenAI Technical Staff） 过去五个月，我们团队做了一个极端实验：在0 行人工手写代码的约束下，构建并持续交付一个真实的软件产品（内部 beta）。 这不是演示项目。它有内部日活用户，也有外部 alpha 测试者；它会发布、会出故障、会被修复。真正不同的是，代码库中的几乎所有内容都由 Codex 生成，包括应用逻辑、测试、CI 配置、文档、可观测性能力和内部工具。我们估算，交付速度大约是传统手写模式的 10 倍。 人类负责掌舵，Agent 负责执行。 我们故意给自己加这个约束，是为了逼出“数量级提速”真正需要的工程能力。我们只有几周时间，要做出最终接近百万行代码的系统。于是问题变成了：当软件工程团队的主要工作不再是写代码，而是设计环境、定义意图、构建反馈回路时，工程实践到底会怎么变。 这篇文章总结的，就是我们在“由 Agent 驱动、从零构建新产品”过程中得到的经验：什么会坏、什么会复利，以及如何把唯一真正稀缺的资源（人的时间和注意力）用在最有杠杆的地方。我们从一个空仓库开始 这个仓库的第一条提交，发生在 2025 年 8 月下旬。 最初的脚手架（仓库结构、CI、格式化规则、包管理器设置、应用框架）由 Codex CLI + GPT‑5 在少量模板引导下生成。甚至最早那份指导 Agent 协作的 AGENTS.md，也是 Codex 写的。 换句话说，系统从第一天起就没有“人工手写代码”的锚点，仓库本身就是由 Agent 逐步塑形出来的。 五个月后，仓库规模达到百万行量级，覆盖应用逻辑、基础设施、工具链、文档和内部开发工具。期间大约有 1500 个 PR 被打开并合并。早期只有 3 名工程师驱动 Codex 时，平均吞吐约为每人每天 3.5 个 PR；扩展到 7 人后，吞吐反而继续提升。更重要的是，这些产出不是“刷产量”：产品已经被数百位内部用户使用，并出现稳定高频用户。 在整个开发过程中，人类没有直接提交手写业务代码。这逐渐成为团队的核心原则：不手写代码。重新定义工程师角色 “人不直接敲代码”并不意味着工程工作减少。变化在于：工程工作的重心从“实现”转向“系统设计、脚手架建设和杠杆构建”。 早期进展比预期慢，不是因为 Codex 做不到，而是环境信息不充分：工具不全、抽象不够、结构不清。于是工程团队的主要任务变成“让 Agent 更容易做对事”。 我们的做法是深度优先拆解：把大目标拆成可组合的构件（设计、编码、评审、测试等），让 Agent 逐块完成，再组合成更复杂能力。任务失败时，修复方式几乎从来不是“再把提示词写猛一点”，而是回到系统问题：到底缺了什么能力，怎样把它变成 Agent 可读、可执行、可验证的机制。 人类与系统的交互几乎完全通过 prompt：工程师描述任务，运行 Agent，让它开 PR。为了把 PR 推进到可合并状态，我们会要求 Codex 做本地自审、发起更具体的额外 Agent 评审（本地与云端），并对人类和 Agent 的反馈持续迭代，直到评审通过（这本质上接近 Ralph Wiggum Loop）。Codex 直接使用标准开发工具（gh、本地脚本、仓库内 skill）获取上下文，不需要人类反复复制粘贴。 人类可以审 PR，但不再是每条改动都必须人工逐行兜底。随着流程成熟，评审工作越来越多转向 agent-to-agent。提升应用可读性（application legibility） 当代码吞吐提高后，瓶颈很快从“写代码能力”转移到“人类 QA 容量”。既然固定上限是人的时间和注意力，我们就持续把更多运行时信号做成 Codex 可直接理解的对象：UI、日志、指标，都要“对 Agent 可见”。 例如，我们让应用支持按 git worktree 启动，让 Codex 能为每次改动启动独立实例；同时把 Chrome DevTools Protocol 接入 Agent 运行时，并提供 DOM 快照、截图、页面导航技能。这样 Codex 可以直接复现 bug、验证修复、推断 UI 行为，而不是只靠静态阅读代码。 Codex 通过 Chrome DevTools MCP 驱动应用并闭环验证。 可观测性同样如此。日志、指标、追踪通过本地可观测性栈暴…