一日一技：读 OpenAI 的 Harness Engineering，我学到的几件事
内容提要
OpenAI团队利用Codex从零构建产品，全程无需编写代码，并总结出关键经验：AGENTS.md应精简为地图而非百科全书；仓库是唯一真相来源，偏好透明内部代码；严格架构约束和linter提升Agent效率；高吞吐下缩短PR生命周期；技术债需持续小额偿还。核心是设计“驾具”能力，定义约束和反馈循环，比写代码更重要。
延伸解读
从“自己改”到“让Agent自己补”
OpenAI团队在实验中坚持“人类不写代码”，遇到Agent搞不定的任务时，不是直接上手，而是追问“缺了什么工具、文档或能力”，然后让Codex自己补齐。这种思路把“Agent为什么搞不定”本身当作工程问题，长期收益更大。对习惯自己动手的开发者来说，这提醒我们：在Agent时代，修复“Agent的短板”可能比修复具体代码更有价值。
AGENTS.md：地图而非百科全书
文章指出，巨大的AGENTS.md文件效果很差，原因包括上下文稀缺、规则过多导致“什么都不重要”、文档腐烂快、难以机械化验证。OpenAI的解法是“渐进式披露”：将AGENTS.md精简到约100行，只作为目录和地图，指向仓库内结构化的docs/目录。这提示我们，给Agent的指令应像地图一样引导，而非像百科全书一样堆砌，否则Agent会顾此失彼。
仓库是唯一真相来源
文章强调“Agent在上下文中访问不到的东西，对它来说就不存在”，因此Slack讨论、Google Docs等未落入仓库的信息对Agent无效。这导致两个反传统结论：偏好“无聊”的技术（可组合、API稳定、训练集覆盖充分），以及宁可自己重写也不用外部库（如自实现并发控制而非用p-limit）。在Agent时代，外部依赖的不透明性成为负担，透明内部代码的“杠杆”更高。
约束与反馈：Agent时代的工程哲学
文章提出“约束越严格，Agent越高效”，通过确定性linter强制架构方向，并用LLM审计Agent处理需要判断的约束，实现“中央强制边界，局部允许自治”。同时，在高吞吐下，传统工程规范（如长PR生命周期、阻塞性合并门禁）反而阻碍效率，原则是“纠错成本低，等待成本高”。技术债则通过持续小额偿还，将人类品味编码进系统，定期运行后台任务自动清理。
Q&A
OpenAI 的 Harness Engineering 实验具体是怎么做的？
OpenAI 团队从 2025 年 8 月一个空仓库开始，3 个工程师（后来扩到 7 个）花了 5 个月，全程通过 prompt 驱动 Codex 来产出代码，不直接写代码。最终合并了约 1,500 个 PR，产出了约 100 万行代码，构建了一个有真实用户的内部产品。
为什么 AGENTS.md 文件不能太长？OpenAI 是怎么解决的？
AGENTS.md 太长会导致上下文稀缺、规则失效、文档腐烂、难以验证等问题。OpenAI 的解法是采用渐进式披露：把 AGENTS.md 精简到约 100 行，只充当目录和地图，指向仓库内结构化的 docs/ 目录。
为什么说仓库是唯一的真相来源？这对技术选型有什么影响？
因为 Agent 只能看到仓库里的内容，无法访问 Slack、Google Docs 等外部信息。所以团队偏好可组合、API 稳定、在训练集中被充分覆盖的“无聊”技术，甚至宁可自己重写外部库，以保证代码的透明性和可预测性。
OpenAI 团队如何通过架构约束和 linter 提升 Agent 效率？
他们从第一天就建立了严格的架构约束，例如每个业务域内代码只能沿固定方向依赖：Types → Config → Repo → Service → Runtime → UI，违反方向的依赖会被 linter 拦截。linter 的报错信息被设计成可直接注入 Agent 上下文的修复指令，同时采用确定性 linter 和 LLM 审计 Agent 双管齐下，中央强制边界，局部允许自治。
在高吞吐的 Agent 开发环境下，传统工程规范有哪些需要调整？
传统工程规范如长 PR 生命周期、测试 flake 阻塞、阻塞性合并门禁等会变成反生产力。他们提出“纠错成本低，等待成本高”的原则，尽量缩短 PR 生命周期，测试 flake 不阻塞进度，最小化阻塞性合并门禁。
OpenAI 团队如何处理技术债？
他们最初每周花 20% 时间手动清理 AI 生成的低质量代码，但不可持续。最终方案是把“黄金原则”编码进仓库，定期运行后台 Codex 任务扫描偏差、更新质量评分、开针对性重构 PR，大部分清理 PR 一分钟内可审完并自动合并。
从 Harness Engineering 中，作者认为未来软件工程师的核心竞争力是什么？
作者认为未来软件工程师的核心竞争力不是写代码的能力，而是设计“驾具”的能力，即定义约束、构建反馈循环、管理文档结构等。这些以前被视为辅助工作的事情，正在变成主要工作。
