3人5个月零代码完成百万行项目！揭秘OpenAI的颠覆开发！|agent|openai|代码|电子表格|调用|颠覆开发

3 个工程师、5 个月、100 万行代码、零手写代码。

可能你会觉得很离谱

但是后来和几个朋友聊，有个朋友在公司就他 1 个人，2 周，3 万块钱，用 Claude Code 做了一个产品上线到了 App Store。

他怎么做到的？，他只是学会了 Harness Engineering。

先说一个真实的对话。

我跟朋友解释 Harness Engineering，说这是”人给 AI 搭建好运行环境，来驾驭 AI 更高效地工作”。

她听完点点头，问我：那我给电脑插电源、按开机键，也算给 AI 搭环境了？

我愣了一秒。

字面上讲，插电源确实是”让 AI 能运行”的前提。但如果插电源也算，那”做任何准备工作”都叫 Harness Engineering，这个词就没有意义了。

这个对话帮我把概念的边界逼清楚了：

Harness Engineering 不是给人用电脑的基础设施，而是专门为 AI Agent 自主工作而设计的运行环境。

区别在”自主”两个字。

你开机，是为了让自己能干活。Harness Engineering 要解决的问题是：当你不在旁边的时候，AI Agent 也能把任务干好，干对，干完。

这需要三件事到位。

说白了，Harness Engineering 就是给 AI Agent 造一个”能干活的工作间”。工具备齐、信息有序、标准明确，它才能自主工作。

这跟之前流行的 Prompt Engineering 和 Context Engineering 不是同一层次的事。Prompt Engineering 解决的是怎么跟 AI 说话，Context Engineering 解决的是喂给 AI 什么信息，而 Harness Engineering 解决的是给 AI 造一个什么样的工作环境。

前两个是对话层，后一个是系统层。

有个类比我觉得挺贴切的。一个新员工入职，你可以教他怎么跟你汇报（Prompt Engineering），你可以把相关背景材料发给他看（Context Engineering），但这两件事加起来，并不等于他能独立工作。他还需要一个东西：一个配好了工具、定好了流程、说清楚了评判标准的工作环境。他知道该去哪里找资料，知道手边有什么工具可以用，知道做完一件事对不对的判断标准是什么。

这个”工作环境”，才是 Harness Engineering 做的事。

地图告诉它方向在哪、路径怎么走。说明书把每一步都写死，Agent 读完要么照本宣科，要么被信息量压垮。一个真正能自主工作的 Agent，需要的是地图。

我看完这句话的时候，想到了自己之前在项目里踩的坑。

我们当时也做了一份”说明书”，一份超长的 System Prompt，把所有情况都试图覆盖，结果 Agent 一方面会漏看重要约束，另一方面又会在不重要的细节上纠结太久。

后来才明白，信息不是越多越好，关键是在对的时候给到对的信息。

我在真正把 Harness 搭好之前，也经历过那个阶段。

用 AI Agent 做项目，到处是坑。跑一半突然偏，输出时好时坏，人根本离不开。我当时以为是模型不够好，换了几个底模，发现换完还是一样的问题。后来才意识到，真正的问题不是模型，是环境。

模型就像一个能力很强的人。但能力强，不等于给他一个乱成一团的工作环境，他也能干好活。

没做好 Harness 的时候，AI Agent 会卡在三个地方。

我遇到过一个很典型的情况。一个 Agent 跑到中途，把最开始给它的格式要求”忘了”，开始按自己的理解输出，输出的结果结构完全不对，但它自己不知道，还以为任务完成了。你如果不在旁边盯着，等它最终输出以后，你会发现，根本不能用。

很多任务，Agent 光靠想做不到。要查系统日志，得有查询接口；要验证页面效果，得能打开浏览器；要跑自动化测试，得有测试框架。工具没有提前备好，Agent 就会陷入一种尴尬的状态：知道下一步要做什么，但没有手段执行，只调用llm直接回复应付或者干脆跳过。

这是最隐蔽的问题，也是我觉得最值得认真对待的一个。

Agent 完成一个子任务，它自己判断”好了”，但这个判断依据是什么？没有明确定义的话，它可能把一个有明显 bug 的输出交给你，因为它认为”能跑起来就算完成”。或者反过来，它会因为某个无关紧要的细节没处理好，一直在那里反复跑，浪费了大量时间。

搭好 Harness 之后，这三个困境都有了对应的解法。

Ryan 团队的 Codex，单次运行可以在一个任务上持续工作超过六个小时，通常是在人类睡觉的时候。它自己打开浏览器验证 UI，自己查日志找 bug，自己跑测试，自己修了再验证，最后打开一个 Pull Request，附上执行记录。整个过程，人类不在场。

这不是因为它用的模型有多特别。是因为它有一个搭得足够好的 Harness。

对比一下就很清楚了。同样是 AI Agent，同样是复杂任务，有 Harness 的跑六个小时自主完成，没有 Harness 的跑半小时就得人来救火。差距不在模型，在环境。

说完理论，讲点实际的。

去年我在公司做过一个 Multi-Agent 项目，叫 product_demo_video_agent。目标是让用户上传一张商品图，AI 自动生成一条产品展示视频。听起来很直接，但实现起来是一个完整的多 Agent 协作系统。

整个系统的设计是这样的。

用户输入进来之后，先经过一个主 Agent（product_demo_video_agent）做路由规划，子Agent_1（pdv_proposal_agent）这个 Agent 负责理解用户的商品，分析适合的视频风格和镜头语言，输出一个完整的视频制作方案。然后把这个方案交给子 Agent_2（pdv_generate_agent）生成产品分镜图，子 Agent_3（pdv_generate_video_agent）根据分镜图产出分镜片段视频，并调用合并工具、音频生成工具合成最终大约20s的视频。

四个 Agent 各司其职，理论上跑得很顺。但只是理论上。

实际跑起来，卡了很久，踩了两个很典型的坑。

比如两个 Agent 之间需要传数据。主 Agent 把分析好的方案传给子 Agent，子 Agent 再根据用户需求生成方案。听起来很自然，但主 Agent 输出的”方案”是什么格式？是自然语言描述？还是结构化的 JSON？字段名是什么？必填项是哪些？视频时长、镜头数量、风格关键词，这些子 Agent 需要的信息，主 Agent 有没有都输出？

这些问题如果没有提前定义，就会出问题。

我们遇到的情况是，主 Agent 有时候输出一整段自然语言描述，有时候是半结构化的数据，字段名也不固定，有时候叫style，有时候叫video_style，有时候这个字段直接不出现。子 Agent 拿到这个”方案”，不知道该读哪里，只能自己猜。猜对了还好，猜错了就生成出偏差的结果，甚至直接报错停掉。

排查起来特别痛苦。因为你不知道是主 Agent 的问题、子 Agent 的问题，还是中间传递的问题，全链路都得看一遍，找那个到底是哪里断了。

做完之后，两个 Agent 之间的传递几乎不再出错了。更重要的是，一旦出错，我们能很快定位是哪个字段的问题，排查时间从几小时缩短到几分钟。

这其实就是一种 Harness Engineering 的实践。把 Agent 之间的接口定义清楚，让每个 Agent 只需要关注自己负责的那一段，输入是什么、输出是什么，不需要猜，不需要兼容各种可能的格式变体。

字段问题解决之后，下一个问题来了：输出质量忽高忽低。

同样的输入，有时候主 Agent 给出的视频方案很精准，描述清晰，镜头逻辑合理，子 Agent 照着做出来的效果很好。有时候同样的输入，主 Agent 给出的方案很模糊，关键信息缺失，子 Agent 只能靠猜，最终生成的视频就差很多。

这种不稳定在 Multi-Agent 项目里最让人头疼，因为很难复现，你很难找到一个确定的原因说”因为 XX 所以这次质量差”。

我们试了两个方向。

一个是模型选型调整。换了更强的底模跑主 Agent，稳定性确实提升了不少，输出质量的方差明显缩小了。但成本也跟着上去了，而且强模型也不是万能的，在某些特定场景下还是会飘。

另一个是 System Prompt 微调。这是更精细的调法，也是我觉得更治本的方向。我们把主 Agent 的 Prompt 拆开来分析，哪些指令它容易理解、哪些容易误解、哪些场景下容易生成质量差的方案。然后针对性地改，把模糊的指令写具体，把容易出错的边界情况加进去，把期望的输出格式用示例说明，用几个好的样本告诉它”这种质量才算及格”。

有时候基本上是按照日期来定义版本名，System Prompt需要不断微调。

两个方向结合起来用，效果明显好了很多。

这个过程让我意识到一件事：输出质量不稳定，本质是因为 Agent 对”什么是好输出”没有明确认知。它不知道什么叫合格，只能靠自己的理解猜测，而不同的请求里这个猜测的结果就会波动。

Prompt 优化，其实就是在做 Harness，把验收标准提前编码进 Agent 的工作指令里，给它一个更清晰的参照系。让它在生成内容的时候，有一个具体的”对”的标准可以对照，而不是凭感觉。

字段定义是在规范接口，Prompt 微调是在规范品质。前者解决数据怎么传，后者解决内容怎么对，合在一起，整个 Multi-Agent 系统才跑得稳，才能真正减少人工介入的频率。

讲完坑，讲方法。

但实际结果是，Agent 一打开就被淹没，重要信息找不到，过时信息删不完，维护成本高得离谱。而且更关键的是，当你什么都告诉它，它反而不知道什么重要。模型在处理超长 Prompt 时会出现注意力分散的问题，早期的信息容易被后面的覆盖，重要的约束可能就这样被漏掉了。

他们后来的做法是把AGENTS.md瘦身到大约 100 行，只做一件事：告诉 Agent”你需要的信息在哪里”

AGENTS.md 是一张地图，不是一本书。Agent 需要什么，自己去对应位置读取，不是一次性消化所有内容。

他们团队意识到，当 Agent 的吞吐量增加之后，人工 QA 成了瓶颈。人的时间和注意力有限，每次 Agent 跑完都要人来验证，这件事本身就不可扩展。规模上不去，不是因为 Agent 能力不够，是因为人类的验证能力跟不上。

解决方案是把验证能力也交给 Agent。

这意味着什么？

像”确保服务启动在 800ms 内完成”、”这四个核心用户旅程的请求耗时不得超过 2 秒”这样的指令，Agent 自己就能跑完验证，不需要人来盯着看。

对我们做产品的人来说，迁移过来的逻辑是：你给 Agent 的任务，要让它有能力自己检验结果。

如果 Agent 只能生成内容，却无法验证内容是否符合要求，那验收这一环就永远压在人身上。你的 Agent 系统的吞吐量天花板，就是你能做 QA 的速度上限。

想突破这个天花板，就要把验证能力也设计进去，把”对不对”的判断权交给 Agent 自己。

这一点听起来最反直觉，但我觉得也是最值得细说的一条。

Ryan 团队给代码库设计了一套严格的分层架构。每个业务域有固定的层级结构，依赖方向经过验证，什么模块可以调用什么、什么不行，都有明确规定，并且用自定义 linter 强制执行。违反了规则的代码，直接报错，不让合并。

为什么要早做？因为 Agent 在有严格边界和可预测结构的环境里，才能跑得最快、跑得最稳。约束越清晰，它越不会往错误方向试探，越不会引入不一致的写法，整个代码库也越不会随着吞吐量增加而悄悄腐烂。

而且有一个细节特别聪明：他们在自定义 linter 的错误信息里，直接写上修复指令。Agent 触发了一条规则，错误信息不只告诉它”这里违规了”，还告诉它”你应该这样改”。

这样的约束对 Agent 来说不是束缚，是引导。它不需要猜测”这里怎么做才对”，规则本身就包含了答案。一旦规则到位，Agent 的速度和质量都会提升，而不是因为被约束变慢。

这和我做 Multi-Agent 时候的逻辑是一样的，给字段下定义、给 Prompt 写清楚期望格式和示例，都是在做规则化，把本来需要 Agent 自己猜测的东西，变成清晰可执行的约束。

规则越清晰，Agent 越自由。这句话听起来矛盾，但确实是真的。

对了，还有一件容易被忽略的事：垃圾要定期回收。

Ryan 提到一个有趣的现象，Agent 会复现代码库里已有的模式，包括那些不够好的模式。因为 Agent 在生成新代码时，会参考已有的代码风格和写法，如果里面有坏的写法，它就会把坏的写法继续用下去，甚至传播开来。随着时间积累，不好的写法越来越多，代码库会慢慢腐烂。

他们一开始靠人工清理，每周五花 20% 的时间专门处理”AI 残渣”。显然不可扩展，而且这本身就是一种讽刺，用人力去清理 AI 制造的垃圾。

后来的做法是，定期跑一组后台 Agent 任务，专门扫描偏差、更新质量评分、发起针对性的重构 PR。大多数 PR 可以在一分钟内审完自动合并，人工几乎不需要参与。

技术债像利息，每天还一点，好过攒着等崩。这个道理大家都懂，但真正做到的很少。有了 Agent 做垃圾回收，这件事终于变得可执行了。

说到这里，想聊一个更大的问题：这一切最终走向哪里？

人类的角色，已经从”写代码的人”变成了”设计系统的人”。

他用一句话总结：人类掌舵，智能体执行。

我觉得这不是遥远的未来，是正在发生的现在。而且不只是在软件工程领域，任何依赖 AI Agent 协作的工作，都在经历这个转变。

我自己在做 Multi-Agent 项目的过程中，也明显感受到了这个变化。我花在”写 Prompt、定规范、搭结构”上的时间，比写任何具体内容都多。有时候一天都在改 System Prompt，在想怎么让 Agent 更稳定，在设计字段定义，在写 Benchmark 用例。工作重心已经从”产出”移到了”搭环境”。

一开始我有点不适应，觉得自己好像没在”干活”。后来才想明白，这本来就是更重要的工作。环境搭好了，Agent 跑起来，产出是指数级的。环境搭不好，Agent 再强，也是一个需要人工辅导的实习生。

所以我对人和 AI 协同的最终状态，有三个判断。

这是最直接的分工变化。写代码、生成内容、跑流程、处理数据，这些执行层面的事 Agent 会越来越擅长，越来越快，越来越准。而人的工作，是把环境准备好：信息结构、工具集合、验收规则，这些是 Agent 能不能干好活的地基。

地基搭得越好，Agent 干得越稳，你能解放的时间就越多。

这个分工不是”人监督 AI”，那样依然很累。而是”人设计系统，AI 运行系统”，设计是一次性的工作，运行是持续自动的。

给定一个模糊的目标，Agent 可以比任何人更快地探索可能性，发散方案，生成选项。它不会累，不会说”这个方向我没试过，不确定”，它可以同时跑十个方向，把每个方向的结果都摆在你面前。

但方向对不对，目前还是人来判断。

人提方向，AI 铺开所有可能性，然后人从里面挑。这个节奏，已经是很多团队现在的工作模式了。产品经理给一个方向，Agent 生成十个方案，PM 挑选并调整，Agent 继续细化。这个循环跑起来，效率比任何传统方式都高。

这条说的是更深层的东西，也是我认为最核心的一条。

Agent 在执行任务时，本质上是在一套规则和约束下运作的。这套规则，要人来定。什么能做，什么不能做，什么算好，什么算坏，什么情况下输出达标，什么情况下要人介入，这些判断目前都是人的责任。

AI 能非常严格地执行规则，但它不能自己判断这套规则是否合理，是否适合当前的场景，是否需要在某个特殊情况下灵活处理。这个判断力，是人类目前仍然不可替代的核心能力。

所以未来的工程师，或者更广义地说，未来依靠 AI 协作工作的人，核心能力会变成：搭好环境的能力、定义清晰规则的能力、在关键节点做方向判断的能力。