一日一技：读 OpenAI 的 Harness Engineering，我学到的几件事

发表于 2026-03-04 更新于 2026-04-20 分类于一日一技阅读次数：本文字数： 2k 阅读时长 ≈ 7 分钟

最近 OpenAI 发了一篇文章叫 Harness Engineering，讲的是他们内部团队如何用 Codex（基于 GPT-5 的编码 Agent）从零构建一个真实产品的经验。

我读完以后觉得很有启发，不是因为它讲了什么高深的理论，而是因为它非常诚实地记录了一个团队在”让 AI 写全部代码”这条路上踩过的坑和总结出的经验。以下是对我触动最大的几个点。

实验的前提：人类一行代码都不写

这个实验的硬约束非常极端——工程师不直接写代码。从 2025 年 8 月一个空仓库开始，3 个工程师（后来扩到 7 个）花了 5 个月，全部通过 prompt 驱动 Codex 来产出代码，最终合并了大约 1,500 个 PR，产出了约 100 万行代码，构建了一个有真实用户的内部产品。

这个设定本身就很有意思。当 Agent 搞不定某个任务的时候，团队的规则不是”算了我来写”，而是去问：”缺了什么工具、文档或能力？”然后让 Codex 自己去补。

这让我想到我自己使用 AI 编程的习惯——很多时候遇到 Agent 搞不定的地方，我的第一反应就是自己上手改。但如果换一个思路，把”为什么 Agent 搞不定”这个问题本身当成一个需要解决的工程问题，长期来看收益是更大的。

这是全文对我触动最大的一个点。

他们一开始也是搞了一个巨大的 AGENTS.md 文件，把所有规则、约束、规范全塞进去。结果发现效果很差，原因有四个：

他们的解法叫渐进式披露（Progressive Disclosure）：把 AGENTS.md 精简到约 100 行，只充当目录和地图，指向仓库内结构化的 docs/ 目录。

这个思路跟我自己的经验完全对得上。我在用 OpenClaw 和 Claude Code 的时候，也发现 AGENTS.md 越长效果越差，Agent 经常顾此失彼。”给 Agent 一张地图，而不是一本百科全书”——这句话值得反复品味。

文章里有一句话很直白：

Agent 在上下文中访问不到的东西，对它来说就不存在。

Slack 讨论、Google Docs、你脑子里的想法——如果没有落到仓库里，对 Agent 来说这些信息就是零。Agent 就像一个三个月后入职的新人，只能看到仓库里有什么。

这个观点推导出来的结论很有趣：

偏好”无聊”的技术。 可组合、API 稳定、在训练集中被充分覆盖的技术对 Agent 更友好。
有时候宁可自己重写，也不用外部库。 他们举了一个例子：不用通用的 p-limit 包做并发控制，而是自己实现了一个——与内部的 OpenTelemetry 紧密集成，100% 测试覆盖，行为完全可预测。因为对 Agent 来说，透明的内部代码比不透明的外部依赖有更高的”杠杆”。

这一点跟传统的软件工程观念有冲突。我们通常说”不要重复造轮子”，但在 Agent 时代，外部依赖的”不透明性”反而成了负担。Agent 不能像人一样去翻 npm 文档或者 Stack Overflow，它只能看到仓库里的代码。如果一个库的行为不可预测，Agent 就会在上面反复碰壁。

这又是一个反直觉的结论。

他们从第一天就建立了非常严格的架构约束——每个业务域内，代码只能沿固定方向依赖：

Types → Config → Repo → Service → Runtime → UI

违反方向的依赖直接被 linter 拦住。而且这些 linter 的报错信息被刻意设计成可以直接注入 Agent 上下文的修复指令——Agent 看到报错就知道怎么改。

更巧妙的是执行方式：确定性 linter + LLM 审计 Agent 双管齐下。 确定性的规则用工具强制（不可协商），需要判断的约束用另一个 Agent 来审计。

他们的哲学是：中央强制边界，局部允许自治。 在边界内，Agent 可以自由发挥。输出不一定符合人类的审美偏好——“只要正确、可维护、对未来 Agent 可读，就算达标。”

想想也合理。人类写代码追求”优雅”，很多时候是主观偏好。但 Agent 不在乎代码好不好看，它只在乎规则是否清晰、边界是否明确。约束越严格，解空间越小，Agent 反而越不容易跑偏。

当 Agent 的产出速度远超人类审查能力的时候，很多传统的工程最佳实践反而成了反生产力的东西：

他们提出了一个原则：**”纠错成本低，等待成本高。”** 在低吞吐的人类团队中，这种做法是不负责任的。但在 Agent 高吞吐的环境下，让一个 PR 排队等人审查的成本远大于合并后发现问题再修复的成本。

这让我联想到制造业的区别——手工作坊追求”一次做对”，因为返工成本高；但流水线追求”快速检测、快速修复”，因为产量大到返工的边际成本很低。Agent 编程正在把软件开发从”手工作坊”推向”流水线”。

Agent 会复制仓库中已有的模式——包括坏的模式。时间一长，代码质量会漂移。

他们最初的做法是每周五花 20% 的时间手动清理”AI slop”（AI 生成的低质量代码）。毫不意外，这种做法不可持续。

最终方案是把”黄金原则”编码进仓库，然后定期运行后台 Codex 任务：扫描偏差 → 更新质量评分 → 开针对性重构 PR。大部分清理 PR 一分钟内可审完，自动合并。

文章里有一句话我很喜欢：

技术债像高息贷款：持续小额偿还，远好过让它复利积累后痛苦地一次性解决。

而更妙的是后面那句：人类品味只需捕获一次，然后在每一行代码上持续强制执行。

这才是 Harness Engineering 的精髓——把人类的判断标准”固化”进系统，让机器去执行，而不是每次都依赖人类肉眼去 Review。

读完这篇文章，我最大的感受是：未来的软件工程师核心竞争力不是写代码的能力，而是设计”驾具”的能力。 定义约束、构建反馈循环、管理文档结构——这些以前被视为”辅助工作”的事情，正在变成主要工作。

而那些我们曾经认为最不起眼的东西——AGENTS.md、linter 配置、CI 流程、目录结构——恰恰是决定 Agent 产出质量的关键。

模型是马，驾具是缰绳。马越强壮，缰绳越重要。