Harness Engineering案例复盘OpenAI团队如何用Codex 5个月产出100万行代码【免费下载链接】harness-engineering Ryan Lopopolo’s anthology, field guide, and agent context bundle for harness engineering项目地址: https://gitcode.com/gh_mirrors/har/harness-engineeringHarness Engineering马具工程 / 环境工程是当下 AI 编程领域最热的实践之一不更换模型和 Agent而是通过精心搭建周围的上下文、工具与反馈环境让固定 worker 产出可交付的成果。本文复盘 OpenAI 团队一个真实案例——3 个人、一个空仓库、零行人工手写代码5 个月让 Codex 生成约100 万行代码、合并约1,500 个 PR。这份 harness-engineering 仓库 正是该领域的案例集与行动手册我们把其中的关键论点和证据整理成一篇新手友好的复盘。背景一次人类绝不写代码的完整实验先看实验设定来源docs/fixed-worker/README.md维度内容团队规模3 人起步起点一个空仓库时长5 个月产品在公司内部作为 Beta 使用产出约 100 万行代码约 1,500 个合并的 PR代码归属全部由 Codex 生成人类从未直接贡献任何代码工程师们做的不是写代码而是持续改进仓库、浏览器、可观测性、评审和交付面直到 Codex 能够自己启动应用、观察行为、响应评审、交付经过验证的变更。这个约束非常关键它把环境里缺什么能力变成了看得见摸得着的故障而不是模糊的AI 不够聪明。核心概念把模型当黑盒改造环境Harness Engineering 的核心主张可以用一句话概括见 README.md把选定的模型和编程 Agent 当作黑盒保持不变只优化两个外部杠杆——上下文context和工具tools并围绕它们策展整个环境。在 docs/README.md 的 12 条论点中与本案例直接相关的有固定 workerHold the worker constant模型或 Agent 每次大版本更新算一次新的epoch需要重新校准环境、人的先验和任务雄心给一个 Agent 完整工作whole job人类提供方向与判断一条主轨迹负责分解、执行、集成、证明和收尾让仓库教会 AgentMake the repository teach the agentAgent 读的代码就是提示词素材仓库里的非功能需求要可恢复、可检索以可衡量的有效性为目标Optimize for measured effectivenesstoken 数、行数只是输入真正的目标是单位稀缺人类注意力换多少可用结果。复盘要点 1前期慢是因为环境还没长出来案例中最容易被忽略的细节是前期进度比预期慢因为仓库缺少 Agent 需要的工具、抽象和结构见 docs/effectiveness/README.md。换句话说100 万行代码不是一开始就喷涌出来的而是环境和吞吐互相喂养的结果早期工作把判断和基础设施沉淀进仓库后期工作直接继承这些杠杆——团队和 harness 一起长大吞吐随之上升。这对新手最重要的启示是⚡别把慢归因于模型——先问环境缺什么上下文权限反馈速度 记录每一次干预前后的可比任务表现用纵向数据而不是单次感觉来判断环境是否变好了。复盘要点 2把内循环压到 1 分钟以内固定 worker 的一个著名操作细节来源docs/fixed-worker/README.mdGPT-5.2 时期 Codex 没有后台 shell只能阻塞式等待构建脚本GPT-5.3 支持后台 shell 后Agent 又不愿意阻塞等待了。团队用一周时间把构建系统从自制 Makefile → Bazel → Turbo → Nx一路迁移直到完整构建在 1 分钟内完成。1 分钟被定为硬性上限一旦超标就停下当前工作拆分构建图直到循环重新达标。这条经验可以直接抄作业构建、测试、预览的反馈延迟是 Agent 可用能力的一部分。反馈越慢Agent 的耐心和专注损耗越大有效利用率越低。复盘要点 3产出不是目标可证明的结果才是docs/effectiveness/README.md 提出了四个时钟来防止团队自嗨时钟衡量什么为什么重要worker 反馈延迟从动作到可用的测试/构建/评审信号决定迭代速度worker 墙钟时长从开始到跑完占用执行容量同步人类注意力人必须亲自指导/评审/救火的时间决定能监督多少工作到可接受结果的时长从请求到被证明、被接受、被部署覆盖排队、返工与交付PR 数量、行数、token 总量都可能在价值不动的情况下持续上涨。案例里约 1,500 个 PR 之所以成立是因为每个变更都走到了真实环境中的证明这一步——浏览器旅程、部署健康、金丝雀而不仅仅是一个绿色对勾见 docs/proof/README.md。新手行动清单从案例到你能做的事挑一个固定 Agent先冻结它。一周之内不改模型、不换运行时观察它缺什么来源论点docs/fixed-worker/。给 Agent 完整的工作而不是一个函数。它要能启动、观察、修复、交付缺哪段就补哪段环境。把反馈循环压快本地构建/测试目标 1 分钟内超过就拆分。让仓库说话把质量标准、验收方式、历史决策写成 Agent 能检索的上下文AGENTS.md就是这种入口参考本仓库的 AGENTS.md。把反馈变成基础设施重复出现的失败类问题沉淀成上下文、工具、测试或评审规则docs/feedback/README.md。用 playbook 执行一次改进观察一条代表性轨迹 → 找到最早的失败交接点 → 做最小授权干预 → 用全新重跑验证playbooks/improve-harness.md。延伸阅读本仓库内总纲与定义README.md、ARCHITECTURE.md案例论证层docs/fixed-worker/README.md固定 worker 与 epoch、docs/effectiveness/README.md五个月的纵向证据与四时钟方法论索引docs/README.md12 条论点、playbooks/行动手册一手资料库sources/OpenAI 原文与 Latent Space 访谈的元数据、归档与抓取脚本如 sources/scripts/fetch_openai.py全部索引导入见 sources/sources.json一句话总结100 万行代码不是提示词魔法而是 3 个人 5 个月持续把环境做到位的结果——慢的时候补环境快的时候防自嗨。这套方法不贵今天就能在你的仓库上开始。【免费下载链接】harness-engineering Ryan Lopopolo’s anthology, field guide, and agent context bundle for harness engineering项目地址: https://gitcode.com/gh_mirrors/har/harness-engineering创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Harness Engineering案例复盘：OpenAI团队如何用Codex 5个月产出100万行代码
Harness Engineering案例复盘OpenAI团队如何用Codex 5个月产出100万行代码【免费下载链接】harness-engineering Ryan Lopopolo’s anthology, field guide, and agent context bundle for harness engineering项目地址: https://gitcode.com/gh_mirrors/har/harness-engineeringHarness Engineering马具工程 / 环境工程是当下 AI 编程领域最热的实践之一不更换模型和 Agent而是通过精心搭建周围的上下文、工具与反馈环境让固定 worker 产出可交付的成果。本文复盘 OpenAI 团队一个真实案例——3 个人、一个空仓库、零行人工手写代码5 个月让 Codex 生成约100 万行代码、合并约1,500 个 PR。这份 harness-engineering 仓库 正是该领域的案例集与行动手册我们把其中的关键论点和证据整理成一篇新手友好的复盘。背景一次人类绝不写代码的完整实验先看实验设定来源docs/fixed-worker/README.md维度内容团队规模3 人起步起点一个空仓库时长5 个月产品在公司内部作为 Beta 使用产出约 100 万行代码约 1,500 个合并的 PR代码归属全部由 Codex 生成人类从未直接贡献任何代码工程师们做的不是写代码而是持续改进仓库、浏览器、可观测性、评审和交付面直到 Codex 能够自己启动应用、观察行为、响应评审、交付经过验证的变更。这个约束非常关键它把环境里缺什么能力变成了看得见摸得着的故障而不是模糊的AI 不够聪明。核心概念把模型当黑盒改造环境Harness Engineering 的核心主张可以用一句话概括见 README.md把选定的模型和编程 Agent 当作黑盒保持不变只优化两个外部杠杆——上下文context和工具tools并围绕它们策展整个环境。在 docs/README.md 的 12 条论点中与本案例直接相关的有固定 workerHold the worker constant模型或 Agent 每次大版本更新算一次新的epoch需要重新校准环境、人的先验和任务雄心给一个 Agent 完整工作whole job人类提供方向与判断一条主轨迹负责分解、执行、集成、证明和收尾让仓库教会 AgentMake the repository teach the agentAgent 读的代码就是提示词素材仓库里的非功能需求要可恢复、可检索以可衡量的有效性为目标Optimize for measured effectivenesstoken 数、行数只是输入真正的目标是单位稀缺人类注意力换多少可用结果。复盘要点 1前期慢是因为环境还没长出来案例中最容易被忽略的细节是前期进度比预期慢因为仓库缺少 Agent 需要的工具、抽象和结构见 docs/effectiveness/README.md。换句话说100 万行代码不是一开始就喷涌出来的而是环境和吞吐互相喂养的结果早期工作把判断和基础设施沉淀进仓库后期工作直接继承这些杠杆——团队和 harness 一起长大吞吐随之上升。这对新手最重要的启示是⚡别把慢归因于模型——先问环境缺什么上下文权限反馈速度 记录每一次干预前后的可比任务表现用纵向数据而不是单次感觉来判断环境是否变好了。复盘要点 2把内循环压到 1 分钟以内固定 worker 的一个著名操作细节来源docs/fixed-worker/README.mdGPT-5.2 时期 Codex 没有后台 shell只能阻塞式等待构建脚本GPT-5.3 支持后台 shell 后Agent 又不愿意阻塞等待了。团队用一周时间把构建系统从自制 Makefile → Bazel → Turbo → Nx一路迁移直到完整构建在 1 分钟内完成。1 分钟被定为硬性上限一旦超标就停下当前工作拆分构建图直到循环重新达标。这条经验可以直接抄作业构建、测试、预览的反馈延迟是 Agent 可用能力的一部分。反馈越慢Agent 的耐心和专注损耗越大有效利用率越低。复盘要点 3产出不是目标可证明的结果才是docs/effectiveness/README.md 提出了四个时钟来防止团队自嗨时钟衡量什么为什么重要worker 反馈延迟从动作到可用的测试/构建/评审信号决定迭代速度worker 墙钟时长从开始到跑完占用执行容量同步人类注意力人必须亲自指导/评审/救火的时间决定能监督多少工作到可接受结果的时长从请求到被证明、被接受、被部署覆盖排队、返工与交付PR 数量、行数、token 总量都可能在价值不动的情况下持续上涨。案例里约 1,500 个 PR 之所以成立是因为每个变更都走到了真实环境中的证明这一步——浏览器旅程、部署健康、金丝雀而不仅仅是一个绿色对勾见 docs/proof/README.md。新手行动清单从案例到你能做的事挑一个固定 Agent先冻结它。一周之内不改模型、不换运行时观察它缺什么来源论点docs/fixed-worker/。给 Agent 完整的工作而不是一个函数。它要能启动、观察、修复、交付缺哪段就补哪段环境。把反馈循环压快本地构建/测试目标 1 分钟内超过就拆分。让仓库说话把质量标准、验收方式、历史决策写成 Agent 能检索的上下文AGENTS.md就是这种入口参考本仓库的 AGENTS.md。把反馈变成基础设施重复出现的失败类问题沉淀成上下文、工具、测试或评审规则docs/feedback/README.md。用 playbook 执行一次改进观察一条代表性轨迹 → 找到最早的失败交接点 → 做最小授权干预 → 用全新重跑验证playbooks/improve-harness.md。延伸阅读本仓库内总纲与定义README.md、ARCHITECTURE.md案例论证层docs/fixed-worker/README.md固定 worker 与 epoch、docs/effectiveness/README.md五个月的纵向证据与四时钟方法论索引docs/README.md12 条论点、playbooks/行动手册一手资料库sources/OpenAI 原文与 Latent Space 访谈的元数据、归档与抓取脚本如 sources/scripts/fetch_openai.py全部索引导入见 sources/sources.json一句话总结100 万行代码不是提示词魔法而是 3 个人 5 个月持续把环境做到位的结果——慢的时候补环境快的时候防自嗨。这套方法不贵今天就能在你的仓库上开始。【免费下载链接】harness-engineering Ryan Lopopolo’s anthology, field guide, and agent context bundle for harness engineering项目地址: https://gitcode.com/gh_mirrors/har/harness-engineering创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
