来源
- 原始链接：https://www.youtube.com/watch?v=am_oeAoUhew
- 来源类型：视频逐字稿
- 来源标题：OpenAI的Ryan Leopo谈Harness Engineering：当代码免费时，如何构建软件
【代码免费之后，稀缺资源发生迁移】
背景：Ryan Leopo 的核心判断很直接：编码 Agent 已经让实现本身变得不再稀缺。工程师的工作重心从亲手写代码，迁移到调度大量 Agent、设计约束、管理注意力与上下文。
实现已经不再是软件工程里的稀缺资源。代码是免费的。我们拥有大量代码能力，可以用来解决日常团队、软件和用户问题中的各种需求。
每个工程师现在都可以获得相当于 5 个、50 个，甚至 5000 个工程师的全天候能力。我们的角色变成：如何把这些资源有效部署到代码和团队中。
这个世界里的稀缺资源有三个：人的时间，人与模型的注意力，以及模型的上下文窗口。
兴趣匹配度高。它把 AI coding 的问题从工具效率改写成资源配置问题：实现能力充裕以后，真正需要设计的是人类注意力、模型注意力和上下文预算的分配机制。
【Harness 的本质：在正确时刻把正确文本交给模型】
背景：这组摘录解释了 Harness Engineering 与普通 prompt 或工具封装的差别。好的 harness 不是把所有规则一股脑塞进上下文，而是把成功标准、约束和修复方向在合适节点暴露给 Agent。
重要的不是代码本身，而是把你带到那份代码的提示词和护栏。
一个好的 harness，本质上是在正确的时间把正确的文本交给模型，让它能看到自己已经完成的工作，以及什么才算完成得好。模型被训练来遵循指令，harness 要做的就是在合适时机把指令呈现出来。
你不应该一开始就加载所有指令，那会压垮 Agent。关于什么是好工作的要求，需要在整个 PR 生命周期里持续被关注。好的 harness 要能延迟暴露或即时暴露这些指令。
兴趣匹配度高。这里和你的上下文工程主题高度贴合：上下文不是越多越好，而是要变成按时机、按角色、按失败类型注入的运行时机制。
【把经验从人脑迁移到仓库，让 Agent 能继承团队判断】
背景：Ryan 强调，团队过去依靠 code review、口头经验和资深工程师直觉维持质量。Agent 时代需要把这些非功能性要求写成文档、测试、lint、review agent 和可复用技能，让每条 Agent 轨迹都继承团队里最强的人类判断。
做好软件工程很难。一个高质量、可维护、可靠、能让队友继续叠加价值的 patch，背后可能包含 500 个关于非功能性需求的小决策。模型在训练中见过各种选择，所以我们的工作是把这些要求写下来，让 Agent 看得见什么叫可接受、可合并的工作。
让团队成员把各自的判断写下来，意味着每个驱动 Agent 的工程师都能获得团队里每个人最好的部分。我不需要靠低信号的 code review 才学会什么是好的 QA 计划；只要一个同事把它沉淀成持久文档，每条 Agent 轨迹都能拥有好的 QA 计划。
当我们看到 Agent 或人类在代码库里反复犯同类错误时，需要退后一步，找出为什么我们总在这里花时间，设计一个方案系统性消灭这类坏行为，然后继续观察、精炼，再为这些非功能性要求做出更多选择。
兴趣匹配度高。这是 skill、AGENTS.md、lint、CI reviewer 的统一解释：它们不是外围文档，而是把团队判断编译进工程系统的载体。
【代码库本身也是 Prompt：结构一致性会提高 Agent 可控性】
背景：Ryan 给出的实践很具体：为了让 Agent 更好工作，代码库要变得局部化、结构化、一致化。文件系统、包边界、重复模式和错误信息都会成为模型读取到的隐性 prompt。
代码在文件系统里也是文本，这意味着它实际上是在给编码 Agent 的提示词。让代码尽可能一致，可以让 Agent 无论查看仓库的哪个位置，都形成大量可迁移的上下文。
你应该只有一种有界并发 helper，一种可观测的副作用命令写法，一种对象模型，一种编程语言，一种 CI 脚本写法，一种增加 lint 规则的方式。这样模型要生成的 token 更容易预测，并且在不同位置都更稳定。
如果我们知道上下文有限，就可以写一个测试，限制文件不能超过 350 行。我们是在让代码库适配 harness 和模型，通过一点工程设计提升上下文效率，榨出当前模型能力的更多价值。
兴趣匹配度高。它把代码架构和上下文工程打通了：架构不只是给人看的边界，也是给 Agent 的检索空间、注意力路径和生成先验。
【从人工 review 到自动自愈：把反馈闭环工程化】
背景：高并发 Agent 开发会让 PR 数量暴涨，人的 review 成为瓶颈。Ryan 的解法不是让人更努力 review，而是把每周看到的 slop 归因到上下文失败，再转成文档、lint、测试和 reviewer agent。
每个工程师每天产出 3 到 5 个 PR 时，即使团队只有 3 个人，合并冲突也会非常痛苦。我们向两个方向调整：一是把代码树拆开，减少冲突；二是缩短 PR 打开的时间，因为 PR 开太久的原因往往是需要人工 code review，而人在这个场景里成了阻塞点。
我让团队每周五做垃圾回收日：把这一周观察到的、导致 PR 难以合并的所有 slop 拿出来，思考如何从类别上彻底消灭它们。人类在 PR 中给出的反馈，说明 Agent 的上下文发生了失败。我们把这些反馈放回仓库，再用失败测试或 reviewer agent 自动注入给 Agent，让它下次能自我修复。
我们让团队把 review 反馈按角色归类，比如前端架构师、可靠性工程师、可扩展性工程师。然后为每个角色启动一个 review agent，在每次 push 时检查：这段代码是否足够好，是否有 P2 以上、会阻塞合并的问题。
兴趣匹配度高。这套方法非常适合你的 agent workflow 实践：把一次次人工纠偏变成自动化验收与上下文注入，才能承受多 Agent 并发带来的吞吐量。
【计划、协作与未来形态：人类上移为排序者和验收标准设计者】
背景：Q&A 部分有几个反常识判断：不盲目依赖 plan mode，不把所有 reviewer 反馈都强制执行，把 token 更多花在 CI 和验收上。Ryan 描述的未来是：人类给出优先级、成功指标和可靠性指标，机器持续推进产品。
如果你使用计划，并且在没有真正阅读的情况下批准它，你实际上是在编码一堆自己未必想遵循的指令。如果要用计划，我建议把计划作为单独 PR 提交，让人逐行审阅，并在批准后再启动执行。
不要规定每条反馈都必须处理。这样可能产生灾难性失败：编码 Agent 被所有 reviewer 欺负。我们真正想要的是偏向接受代码，而不是追求完美，也不是淹没在细枝末节里。
我想构建的未来是：给定一个 token 预算和一个季度、半年或一年的工作，人类输入最重要事项的排序、成功指标和可靠性指标，然后把它交给机器，让它们持续工作并推动产品前进。
兴趣匹配度高。这里的重点是组织形态变化：人类从实现者上移为排序者、约束设计者、验收标准设计者。代码逐渐变成可丢弃的构建产物，而 harness、文档、测试和指标成为更持久的资产。