Harness Engineering 总结概要
约 4 分钟 · 更新于 2026-09-01 ·
原文Harness Engineering 总结概要
原文信息
- 标题： Harness engineering: leveraging Codex in an agent-first world
- 作者： Ryan Lopopolo | 日期： 2026-02-11
- 来源： OpenAI Engineering Blog
- 原文： Harness-Engineering-原文-20260211
一句话总结
OpenAI 内部团队用 5 个月时间，完全不手写代码，仅通过 Codex 代理生成了约 100 万行代码的产品，开发效率约为传统方式的 10 倍，并总结出一套"Harness Engineering"（驾驭工程）方法论。
核心数据
| 指标 | 数值 |
|---|
| 手写代码行数 | 0 行 |
| 总代码量 | 约 100 万行 |
| 开发周期 | 5 个月（2025.08 - 2026.01） |
| 合并 PR 数 | 约 1,500 个 |
| 初始团队规模 | 3 人 -> 后扩展至 7 人 |
| 人均日 PR 产出 | 3.5 个 PR/人/天 |
| 效率提升 | 约 10 倍 |
核心理念
人类引导，代理执行（Humans steer. Agents execute.）
工程师的角色从"写代码"转变为三项核心工作：
- 设计环境 — 构建代理能理解和操作的结构化环境
- 声明意图 — 通过 prompt 描述任务目标和验收标准
- 构建反馈循环 — 建立让代理自我验证和改进的机制
关键实践总结
1. 从空仓库开始，一切由代理生成
- 第一次提交就是由 Codex CLI + GPT-5 生成的项目脚手架
- 甚至 AGENTS.md（指导代理工作的文件）本身也由 Codex 编写
- 代码、测试、CI 配置、文档、可观测性工具、内部工具 — 全部由代理生成
2. 重新定义工程师角色
- 早期进展比预期慢，原因不是代理能力不足，而是环境规范不足
- 工程师的首要工作变成"让代理能做有用的工作"
- 核心方法：深度优先 — 将大目标拆解为小模块，逐步解锁复杂任务
- 出错时不是"更努力"，而是问："缺了什么能力？如何让它对代理可读且可执行？"
3. 提升应用的可读性（Agent Legibility）
核心原则
从代理视角看，上下文中无法访问的信息等同于不存在。
- 每个 git worktree 可独立启动应用，代理可在隔离环境中工作
- 接入 Chrome DevTools Protocol，代理可直接操作 DOM、截图、导航
- 可观测性工具（日志/指标/追踪）对代理可用，支持 LogQL/PromQL 查询
- 单次 Codex 运行可持续工作 6 小时以上（人类睡觉时代理继续工作）
4. 仓库知识作为唯一信息源（System of Record）
给代理一张地图，而非一本千页手册
大型 AGENTS.md 失败的原因：
- 上下文是稀缺资源，巨型指令文件挤占任务和代码的空间
- 当一切都"重要"时，什么都不重要
- 单体文档迅速腐化，难以维护和验证
正确做法 — 渐进式披露（Progressive Disclosure）：
- AGENTS.md 仅作为目录（约 100 行），指向结构化的 docs/ 目录
- 设计文档、执行计划、产品规格、架构文档分门别类存放
- 专门的 linter 和 CI 任务验证知识库的时效性和交叉链接
- 定期运行"文档园艺"代理，清理过时文档
5. 通过强制架构约束保持一致性
- 强制不变量，而非微管理实现方式
- 每个业务域严格分层：Types -> Config -> Repo -> Service -> Runtime -> UI
- 依赖方向严格单向，通过自定义 linter（由 Codex 生成）机械化强制执行
- "品味不变量"：结构化日志、命名规范、文件大小限制等
- 自定义 lint 的错误消息中注入修复指导，直接成为代理的上下文
在人类优先的工作流中，这些规则可能显得苛刻；在代理场景下，它们成为乘数效应**。**
6. 高吞吐改变合并策略
- 最小化阻断式合并门控，PR 生命周期短
- 测试不稳定用后续运行修复，而非无限期阻塞
- 在代理吞吐远超人类注意力的系统中，修正成本低，等待成本高
7. 熵增与"垃圾回收"
- 代理会复制仓库中已有的模式，包括不理想的模式 — 导致渐进漂移
- 早期靠人工每周五清理 "AI slop"（占 20% 工时），不可持续
- 解决方案：将"黄金原则"编码进仓库 + 定期清理流程
- 后台 Codex 任务定期扫描偏差、更新质量评分、提交重构 PR
- 大部分重构 PR 可在 1 分钟内审核并自动合并
- 类比：像垃圾回收一样持续小幅偿还技术债，而非积累后痛苦地集中处理
代理自主能力的阶梯
文章描述了代理从单一任务执行到端到端特性交付的能力进化。给定一个 prompt，Codex 现在可以：
- 验证代码库当前状态
- 复现报告的 Bug
- 录制展示故障的视频
- 实现修复
- 通过驱动应用验证修复
- 录制展示修复结果的视频
- 提交 Pull Request
- 回应代理和人类的反馈
- 检测并修复构建失败
- 仅在需要判断时升级给人类
- 合并变更
对我们的启示
与 VariFlight 当前实践的关联
可直接借鉴的实践
| OpenAI 实践 | 我们的对应 | 行动建议 |
|---|
| AGENTS.md 作为目录而非百科 | CLAUDE.md | 保持 CLAUDE.md 精简，重要细节分散到专题文档 |
| 结构化 docs/ 目录 | Skills + CLAUDE.md | 继续维护分层的知识体系 |
| 渐进式披露 | Skill 按需加载 | 与当前 Skill 架构理念一致 |
| 自定义 linter 强制架构约束 | - | 考虑为代码生成项目引入类似机制 |
| "文档园艺"自动维护 | - | 可考虑定期检查 CLAUDE.md 和 Skills 的时效性 |
| 执行计划作为一等工件 | CBD 协议 | CBD 已是类似实践，可进一步对齐 |
核心洞察
- 环境设计 > 直接编码 — 投入精力让代理能理解和操作环境，比直接写代码更有杠杆效应
- 约束是加速器 — 严格的架构约束不是限制，而是让代理高速运转的前提
- 持续小幅清理 > 集中大扫除 — 技术债的"垃圾回收"模式更可持续
- 知识必须在仓库中 — 对代理而言，不在仓库中的知识等于不存在
- 原文全文
- Anthropic官方AI与Agent最佳实践汇总-20260302