OpenAI 工程博客：Harness Engineering — Agent-First 时代的软件工程实践 https://t.co/cdu3Psf5sp OpenAI 内部团队用五个月时间，从空仓库开始构建了一个真实的内部产品，全程零行人工手写代码。3 名工程师驱动 Codex 产出约 100 万行代码、合并约 1,500 个 PR，人均日吞吐 3.5 个 PR，估计效率约为手写的 10 倍。产品已有数百名内部用户日常使用。
核心一句话：人类掌舵，Agent 执行。
工程师角色的转变 早期进展比预期慢，瓶颈不在 Agent 的能力，而在环境的规范程度不足——Agent 缺乏正确工作所需的工具、抽象和结构。
工程师的工作因此从"写代码"变成了"让 Agent 能写好代码"：拆解目标、构建模块、搭建反馈回路。当出了问题，解决方案从来不是"再试一次"，而是追问：Agent 缺什么能力？如何让它可见且可强制执行？
这是一种元能力的转移——从生产者变为环境设计师。
知识管理：地图，而非百科全书 团队试过"一个大 AGENTS. md 装一切"，失败了。原因直白：大文件难以验证、即时过时、过多指导等于没有指导、还挤占宝贵的上下文窗口。
最终做法是把 AGENTS. md 控制在约 100 行，仅充当目录和导航。真正的知识存储在结构化的 docs/ 目录中——设计文档、执行计划、产品规格、架构描述、质量评分——全部版本化、可索引。
设计原则是渐进式披露：Agent 从一个小而稳定的入口出发，按需向深层导航，不被一次性淹没。文档健康度由自动化 lint 和 CI 守护，还有一个"文档园丁"Agent 定期扫描过时内容并提交修复。
Agent 可读性 提出一个锐利的观点：从 Agent 视角看，凡是它在运行时无法访问的信息，等同于不存在。 Slack 对话、Google Doc、人脑中的共识——对 Agent 来说与对三个月后的新人一样不可见。
因此团队持续将上下文推入仓库。技术选型上偏好"无聊技术"——API 稳定、可组合、在训练数据中有充分表征。某些场景下，让 Agent 自行实现一个功能子集比依赖行为不透明的第三方库更划算。
为提升 QA 能力，团队还把应用 UI、日志、指标直接暴露给 Agent——接入 Chrome DevTools Protocol 让 Codex 能自行截图、操控 DOM、复现 Bug；接入本地可观测性栈让 Agent 可以用 LogQL 和 PromQL 查询日志和指标。单次 Codex 运行可以持续超过 6 小时，往往在工程师睡觉时工作。
架构约束作为速度的前提 每个业务领域被分为固定层次（Types → Config → Repo → Service → Runtime → UI），依赖方向严格单向，跨切关注点通过唯一的 Providers 接口注入。违规代码被自定义 lint 直接拦截，错误信息中嵌入修复指引，让 Agent 能自行纠正。
文章强调：这种通常在数百人团队才引入的架构纪律，在 Agent 模式下是早期前提——约束本身就是速度的来源。 同时，约束不是无处不在的：集中管控边界，局部充分自治。Agent 生成的代码未必符合人类风格偏好，但只要正确、可维护、对未来 Agent 可读，就达标。
熵的治理 Agent 会复制仓库中已有的模式，包括不理想的模式。早期团队每周五花 20% 时间手动清理"AI slop"，无法持续。
最终方案是编码"黄金原则"并建立自动化循环：后台 Codex 任务定期扫描偏差、更新质量评分、提交定向重构 PR，大部分可在一分钟内审查并自动合并。文章的类比精准：技术债像高息贷款，持续小额偿还几乎总比让它复利累积后痛苦清偿要好。
自治里程碑 文末描述了一个标志性节点：给定单一提示，Codex 已能端到端完成——复现 Bug、录制失败视频、实现修复、验证修复、打开 PR、回应反馈、检测并修复构建失败、合并变更，仅在需要人类判断时升级。 但文章也审慎地说：这高度依赖特定仓库的结构和工具链投入，不应假设可直接泛化。
