OpenAI: Harness Engineering — 在智能体优先的世界中利用 Codex
来源：https://openai.com/zh-Hans-CN/index/harness-engineering/ 收录时间：2026-05-18
核心实验
5 个月，约 100 万行代码，0 行人工编写。 3 名工程师（后扩至 7 名）用 Codex 从零构建一个有内部日常用户的软件产品，效率约为手工编码的 1/10 时间。
人类掌舵。智能体执行。
六大经验
1. 仓库即记录系统
AGENTS.md 不是百科全书，是内容目录。 ~100 行入口文件，指向 docs/ 中更深层的知识。
巨型指令文件三个死因：
- 挤占上下文 — 任务、代码、相关文档被挤出
- 过度指导 = 无效 — 一切都"重要"= 一切都不重要
- 立即腐烂 — 变成陈旧规则的坟场
- 无法核实 — 不适合机械检查，漂移不可避免
实现渐进式披露：智能体从小的稳定入口开始，被指导下一步看什么。专职 linter 和 CI 作业验证知识库的更新状况和结构。一个"doc-gardening"智能体定期扫描过时文档并发起修复 PR。
2. 地图而非手册
知识库布局：
docs/
├── 设计文档（含验证状态）
├── 核心理念（智能体优先操作原则）
├── 架构文档（域和包分层地图）
├── 执行计划（含进度和决策日志）
├── 活跃计划 / 已完成计划 / 已知技术债务
└── 每个产品领域的质量评分
3. 智能体可读性优先
- 仓库外的知识对智能体不存在 — Slack 讨论、Google Docs、人脑中的知识 = 不可见
- 选"枯燥"技术 — API 稳定、训练集覆盖好、可组合性强
- 有时重新实现比包装更便宜 — 如自己写并发 map 辅助函数而非引入 p-limit
- 智能体无法发现的设计决策 = 不存在
4. 规范架构与品味
每个业务域分为固定层：Types → Config → Repo → Service → Runtime → UI
横切关注点（认证、遥测、功能标志）通过单一显式接口 Providers 进入。
通过自定义 linter 机械强制执行：
- 结构化日志
- 命名约定
- 文件大小限制
- 平台可靠性要求
- lint 错误信息内嵌修复指令 — 智能体可以自纠正
中央层面强制执行边界，本地层面允许自主权。
5. 吞吐量改变合并理念
- PR 生命周期很短
- 测试偶发失败通过后续重跑解决
- 纠错成本低，等待成本高
- 低吞吐量环境中不负责任的做法，在高吞吐量中是正确选择
6. 熵管理 = 垃圾回收
智能体会复现代码库中已有的模式——包括坏模式。
解决方案：
- 将"黄金原则"编码到代码库
- 定期后台 Codex 任务扫描偏差、更新质量评分、发起重构 PR
- 大多一分钟内审查并自动合并
技术债是高息贷款：不断小额偿还 > 让它累积后痛苦一次性解决
人类品味一旦被捕获 → 持续应用于每行代码 → 每天发现并解决不良模式。
工程师角色重新定义
不再写代码，而是：
- 设计环境 — 让智能体有能力完成有用的工作
- 明确意图 — 将目标拆解为更小的构建模块
- 构建反馈回路 — 当智能体卡住时追问："还需要什么能力？如何让它对智能体清晰可读且可强制执行？"
自主化程度里程碑
给定一个 prompt，智能体现在可以：
- 验证代码库当前状态
- 复现 bug
- 录制故障演示视频
- 实施修复
- 运行应用验证修复
- 录制解决演示视频
- 打开 PR
- 回应智能体和人类反馈
- 检测并修复构建故障
- 仅在需要判断时才交由人工
- 合并更改
关键数据
| 指标 | 数据 | |------|------| | 代码量 | ~100 万行 | | PR 数量 | ~1,500 个 | | 团队规模 | 3→7 人 | | 人均日 PR | 3.5 个（扩展后仍增长） | | 单次运行时长 | 6+ 小时（通常在人类睡眠时间） | | 效率 | 手工编写的 ~1/10 时间 | | 人工编写代码 | 0 行 |