跨国深谈← 返回←Harness 工程：让智能体零人工写代码的实操

Harness 工程：让智能体零人工写代码的实操

关联

人物 Ryan Lopopolo · Guy Fajani

公司 Codex · OpenAI · Symfony

概念 harness 工程 · 智能体 · 提示词注入 · 护栏 · 规范 · 测试时计算 · 异步循环

这一集是 OpenAI 的 Ryan Lopopolo 在 AI Native DevCon 2026 大会上聊” harness 工程”(harness engineering)——一种让编码智能体在你的代码库里自主完成高质量工作的方法体系。最颠覆的一点是：他的团队做到了零人类编写代码、大部分情况下零人工代码审查，而且当 Codex 悄悄把底层实现从 MCP 协议换成完全不同的 TypeScript 守护进程时，他竟然毫不知情，工作流零中断 。

什么是 harness 工程

harness 工程的核心思路是：光有聪明的模型不够，你要把”什么是好代码”的所有非功能性需求——测试怎么写、lint 怎么跑、重构循环怎么转——全部写下来，在正确的时间喂给智能体，让它在没有你干预的情况下也能闭环产出可合并的代码 。

和之前说的上下文工程(context engineering)相比，harness 工程是把”给什么上下文”和”给什么工具”两个杠杆组合起来用，而且独特之处在于——它用工具调用本身来做提示词注入，让智能体自己管理上下文窗口 。比如测试和 lint 的报错信息，给人类看你会列一份详尽的失败清单让人去翻日志；但给智能体，你要压缩成一段语义清晰的文字：“你在这个文件里这样搞砸了，请打开它，按 XYZ 文件里的运行手册去修，因为你之前犯过同样的错” 。

从零开始：怎么走到”不写代码”

Ryan 在 2025 年 6 月就开始用这种不插手的方式工作，那时候连像样的推理模型都没有，只有早期版本的 Codex CLI，模型能力差得多，过程非常痛苦 。一开始他自己不得不充当”笨重工具”——智能体卡住了只能叫他帮忙，比如用 cargo 装依赖这种 Codex 当时做不好的事 。

关键转折是：他开始密切观察自己花时间在哪些地方，然后为每个”叫 Ryan”的场景造一个工具调用来自动化。第一步就是自动化依赖安装，然后逐步给智能体越来越多、越来越大的工具块 。

从零开始的好处是你会发自内心地体验智能体在哪里失败，同时也能看到它哪里做得好——它特别擅长遵循指令、写测试、调用测试 。把工程流程大量折叠成这些”铺好的路”，就是建立信任的过程。

团队扩张时，他只招公司新人，新员工直接被扔进这个环境，大约两周就能适应这种运作方式 。因为所有人通过 Codex 作为代码库的唯一入口，每个新成员贡献的最佳实践自动被所有人共享——新人不用花一两个月吸收团队规范，入职两周后 PR 吞吐量就能提升 5% 到 15% 。

反垃圾代码：不用审查代码，改审查计划

他们的做法不是逐行审代码，而是把人类审查集中在”上游”：高度复杂的计划和跨一周的里程碑。因为这些计划本身就是给智能体的提示词，如果你在开头把任务描述错了，产出的就是垃圾 。日常代码则走零人工审查，直接合并。

但”不审查”不等于”不管”。他们经历了一个关键阶段：招到第三个工程师时，PR 吞吐量上去了但审查跟不上，垃圾代码开始渗入 。

他们的应对是每周五做”垃圾收集”——整理一周内不满意的地方，但核心原则是”永远不给出两次同样的反馈” 。这些反馈逐渐堆叠成程序化的护栏，加上一个长时间运行的外循环——自动化 CI 任务扫描代码库，对照”黄金原则”找偏差，自动提 PR 修复 。

具体实现很朴素：一个 GitHub issue，工程师和智能体在上面记录良好软件开发的原则——怎么写 React 快照测试、什么是可靠的网络代码、怎么构建 lint。最后累积到 100 多条评论，智能体就根据这个去扫描代码库、排名违规项、提 PR 。初期还有专人 on call 监督这些智能体产出，给通过或不通过的反馈，而这些反馈会被下一次运行吸收——智能体会对比上次的会话日志，问自己”犯了什么错、错过了什么优先级”，然后把学到的内容保存为 artifact，下次运行时就有额外上下文 。

Ryan 强调，让错误进 main 分支其实是有价值的——错误可以被学习。一旦识别到重复模式，就把它往前拉到流水线更早的位置：先改提示词(最便宜)，再改文档、加审查智能体，最后才写确定性测试 。

代码变成可丢弃物，规范才是持久资产

当代码生产变得极其便宜，Ryan 发现一个反直觉的做法：先写代码实现，再从中提炼规范，而不是传统的先写规范再写代码 。原因很简单——代码是信息密度极高的产物，包含了大量隐性决策，先让智能体扔出一个”稻草人”实现，团队在此基础上打磨，然后蒸馏出规范，比从空白文档开始写规范容易得多。

他们做了一个叫 Symfony 的”幽灵库”(ghost library)——发布的东西是规范，但起点是一个在 monorepo 里的 TypeScript 凭感觉实现 。验证规范的流程是三阶段流水线：第一个智能体从原始实现生成规范 markdown；第二个智能体只看规范、不看原始代码，从零实现一遍；第三个智能体当法官，对比原始实现和衍生实现，找不一致，然后修改规范让下一次尝试更好 。最终得到的是一个高度精炼的规范——对业务逻辑关键部分指定得很细，但对具体实现留足灵活性，让使用者能适配自己的仓库和工具链 。

什么时候还需要人看代码

Ryan 画了一个二维图：模糊度和复杂度。他只在”双高”区域亲自看代码 。

两种情况：一是从零开始做全新东西，接口形状、体验都还不清楚；二是最困难的重构，需要打破或重新定义接口，甚至删代码，但最终形态还不明确 。而且即使在这些场景，他的做法也不是小心翼翼地写，而是让智能体先即兴生成一个 5 万行 diff 的 PR，直接扔掉——目的是摸清智能体会在哪里失败、在哪里挣扎，然后再拆成 15 个小 PR 做准备和暂存工作 。

至于日常代码，他越来越不看实现细节。他说如果只能选一样东西读，他选系统的参考文档、接口定义、以及渲染成 mermaid 图的实体关系图和序列图 。具体用什么语言写、怎么实现，他可能都不知道——就像开头那个故事，Codex 把 MCP 实现悄悄换成了 TypeScript 守护进程，同样的依赖关系和实体关系都在，但他几乎不需要知道底层怎么实现的 。

每天烧十亿 token 不是吹牛

Ryan 说过”不每天用十亿 token 是近乎疏忽”这句话，他的逻辑是：我们从模型中提取的智能量和 token 消耗基本是线性关系，测试时计算(test time compute)存在的意义就是让模型通过更多推理变得更聪明 。但要用到十亿 token，你必须跳出”和模型结对编程”的思路——必须并行、必须建立异步循环、必须让智能体对整个组织产生副作用而不是只服务你一个人 。

这需要一套全新的模式——从仓库上下文播种的自动化，团队所有人都能用，而不是单人模式。Ryan 把这个阶段类比成 CI/CD 刚被发明的时候：大家都在摸索，要 15 年后才标准化 。

工程师的角色变了吗

Ryan 的团队现在是全栈配置，因为当他一个人时，写出的 React 代码很糟糕——6000 行的组件、糟糕的重渲染、四个重叠闭包的 use effect 。但更重要的是技能重心的转移：代码生产作为技能不再那么重要，系统思维才是——怎么为团队搭建成功的环境、怎么把目光投向来解决问题、怎么提高交付吞吐量 。

他现在的时间大致三等分：最困难的重构、从零到一的产品构思与客户沟通、优先级排序和人员调度。以前他 50% 到 70% 的时间在写代码，现在退后一步，专注跨职能高优先级工作，为智能体团队解除阻塞 。他也提醒一个常见陷阱：因为编码太便宜了，人们容易陷入”什么都能建”的幻觉，但决定不建什么反而更重要 。

本集带走

• 从”叫 Ryan”开始自动化：观察智能体在哪些地方卡住需要你帮忙，为每个场景造一个工具调用，逐步把你自己从循环中移除
• 永远不给两次同样的反馈：垃圾代码出现后，不要只修，要把它提炼成可程序化执行的规则（他们用 GitHub issue 积累了 100 多条），让智能体下次自动遵守
• 让错误进 main，但要从中学：允许错误合并，用异步循环扫描模式、吸收人工反馈、把学到的内容存为 artifact 供下次运行使用；识别到重复模式后，按”改提示词→加文档→加审查智能体→写确定性测试”的顺序逐级左移
• 先实现再提炼规范：代码生产便宜了，先让智能体扔出稻草人实现，团队打磨后蒸馏成规范；用”实现→生成规范→从规范重实现→对比差异修正规范”的三阶段流水线验证规范的完备性
• 人只看”双高”区域的代码：高模糊度×高复杂度（全新东西、困难重构）才亲自介入；日常代码只关心接口定义和系统架构图，具体实现可以不看
• 代码生产不再是核心技能：工程师的重心转向系统思维——决定建什么、不建什么、怎么为智能体团队搭环境，而不是自己写代码

使用这些工具保持高速度的一个很大部分，就是不允许垃圾代码进入代码库。
A big part of maintaining high velocity with these tools is just not permitting slop to enter the code base.
—— Ryan Lopopolo · [11:36]

因为如果你在开头 misspecify 任务，你会得到垃圾。
Because if you misspecify the task up front, you are gonna get garbage.
—— Ryan Lopopolo · [15:32]

我们永远不想给出两次同样的反馈，就像你希望一个新加入团队的工程师真正内化什么意味着做好工作一样。
We never wanted to give the same feedback twice in the same way that you want a new engineer you’re onboarding to the team to actually internalize what it means to do a good job.
—— Ryan Lopopolo · [20:08]

我实际上发现先生成代码会容易得多，让那段代码有点像是一个关于世界可能样子的草案，作为团队与之互动来完善它，然后从中提炼出规范。
I’ve actually found it is much easier to produce the code first, to have that code sort of like present a straw man for what the world could look like, engage with that as a team to refine it, and then distill the spec out of that.
—— Ryan Lopopolo · [28:20]