AI Agent 的自主工作能力正在颠覆传统开发流程。从 OpenAI 团队 3 人 5 个月零代码完成百万行项目，到个人开发者两周上线 App Store 产品的真实案例，背后都离不开 Harness Engineering 的突破性实践。本文深度解析如何为 AI 搭建'能自主工作'的环境，揭秘清晰信息结构、工具准备与验收标准三大核心要素，以及作者在 Multi-Agent 项目中的实战踩坑经验。

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

这件事来自于上个月 OpenAI 的工程师 Ryan Lopopolo 写的一篇文章，《Harness engineering: leveraging Codex in an agent-first world》

可能你会觉得很离谱

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

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

一、Harness Engineering 是什么

先说一个真实的对话。

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

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

我愣了一秒。

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

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

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

区别在”自主”两个字。

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

这需要三件事到位。

• 清晰的环境。Agent 工作时需要找信息，当前代码库的架构是什么、规范文件在哪、遇到 X 情况该怎么处理。这些信息如果散落在各处，Agent 要么找不到，要么被淹没。好的信息环境是有结构的，Agent 能快速定位，按需读取，不需要一次性消化所有东西。
• 工具与技能。Agent 要干活，光靠想不行，得有手。查日志得有查询接口，验证 UI 得能控制浏览器，跑测试得有脚本。这些工具不是 Agent 临时发明的，是人提前备好、放在它触手可及的地方的。
• 验收标准。这条最容易被忽略。Agent 完成一件事，它自己怎么知道做对了？没有明确标准的话，它要么反复跑，要么直接交差，哪种结果都不对。好的 Harness 会把”完成”的定义写清楚，让 Agent 能自我校验。

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

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

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

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

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

Ryan 在文章里有一句话说得特别准：

给 Agent 的是一张地图，而不是一本 1000 页的说明书。

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

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

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

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

二、有和没有，差在哪里

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

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

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

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

上下文有限，任务一长就忘事。

大模型的上下文窗口是有上限的。任务越复杂，需要参考的信息越多，窗口越快撑满。撑满之后 Agent 会开始忘掉早期的信息，可能忘了最开始的任务目标，忘了某个约束条件，然后往错误的方向一路跑下去。

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

没有工具，不知道怎么干。

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

更糟糕的情况是，Agent 会自己编一个解决方案。它没有直接查日志的工具，但它知道日志文件大概在哪里，于是它去读文件，读到一半又遇到权限问题，然后开始绕路，越绕越远，最终输出一个偏差很大的结果，但过程看起来还挺”努力”的。

没有验收标准，不知道做完了没。

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

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

有一次我们让 Agent 生成一段文案，没有定义”好文案”的标准。它生成了一版，自己觉得可以了，就结束了。但那版文案有几个明显的表达问题，完全不能用。重点是，它不知道哪里不对，因为我们从来没告诉它”对”应该是什么样子。

三个困境叠在一起，结果就是人类需要全程守着。Agent 一出错，人来修；跑偏了，人来拉回来；不确定做完了没，人来审。AI Agent 变成了一个需要全程辅导的实习生，而不是协作者。这就是为什么很多人试了 AI Agent 之后说”没什么用”，不是 Agent 不行，是运行的环境太差了。

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

清晰的信息结构让 Agent 按需读取，上下文始终聚焦在当前任务上，不会被无关的背景信息撑满。工具和脚本提前备好，Agent 需要什么直接调用，不需要自己临时想办法。验收规则写清楚，完成后自动检查，达标才算收工，不达标就继续。

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

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

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

三、我自己做 Multi-Agent 时踩的坑

说完理论，讲点实际的。

去年我在公司做过一个 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 再根据用户需求生成方案。听起来很自然，但主 Agent 输出的”方案”是什么格式？是自然语言描述？还是结构化的 JSON？字段名是什么？必填项是哪些？视频时长、镜头数量、风格关键词，这些子 Agent 需要的信息，主 Agent 有没有都输出？

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

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

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

解决方法是给每一步的输入输出做字段定义。把用户输入的所有信息统一封装成一个input对象，明确定义每个字段：图片链接是image_url，文字描述是text_desc，风格偏好是style_pref，必填项、可选项、数据类型全部写清楚，不允许歧义。主 Agent 的输出也做同样处理，定义成proposal对象，里面有固定的字段结构，子 Agent 只读这个对象，不接受其他格式的输入。

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

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

第二个坑：Agent 输出质量不稳定。

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

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

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

我们试了两个方向。

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

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

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

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

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

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

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

四、怎么真正搭好这个环境

讲完坑，讲方法。

把 Ryan 文章里的实践和我自己踩坑的经验放在一起，怎么真正把 Harness 搭好，我认为有三个关键动作。不是什么特别高深的东西，但每一条都容易被忽略。

索引而非百科，信息按需读取。

Ryan 的团队一开始也犯过一个错误，把所有规范、约束、说明全塞进一个巨大的AGENTS.md文件里。这是一个很直觉的做法，就觉得”把所有东西都告诉它，它就什么都知道了”。

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

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

• 架构说明在 ARCHITECTURE.md
• 产品规格在 docs/product-specs/
• 设计文档在 docs/design-docs/
• 脚本工具在 scripts/

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

这是一种渐进式披露的设计思路，跟 UI 设计里的理念一样，不把所有信息一次性堆给用户，而是在他需要的时候自然呈现。上下文是稀缺资源，要用在刀刃上。

对应到自己的项目，实操层面就是：把指导 Agent 的文档拆分成多个文件按主题分类存放，主索引文件只写”去哪找什么”不写具体内容，踩坑点单独整理成一个文档（这是信息密度最高、最值得让 Agent 专门读的部分），然后定期维护，让文档反映当前系统的真实状态，过时的内容及时清理。

最后这一点其实很容易被忽视。文档不维护，它会腐烂，成为陷阱而不是地图。

让系统对 Agent 直接可读。

这是 Ryan 文章里我觉得最有启发的一点，也是最难做到但回报最大的一个。

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

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

具体做法是让应用本身对 Agent 可读。他们把 Chrome DevTools 协议接入了 Agent 的运行时，让 Codex 能直接打开浏览器、截图、读取 DOM、触发页面交互，自己验证 UI 是否正常。同时提供了完整的可观测性工具栈，日志、指标、追踪记录都可以通过 LogQL、PromQL 直接查询。Agent 在自己的隔离环境里跑完任务，可以查自己产生的日志，看自己触发的指标，任务完成后这个环境自动销毁，干净。

这意味着什么？

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

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

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

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

用规则代替管控，约束反而给 Agent 自由。

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

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

他在文章里说：

这种架构通常要等到你有数百名工程师时才会去做。对于编码 Agent 来说，这是一个早期的先决条件。

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

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

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

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

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

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

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

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

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

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

五、人和 AI 协同的最终状态

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

Ryan 描述了他们团队现在的工作状态。工程师不写代码，只写 Prompt；不审每一行代码，只在关键决策点介入；不手动 QA，只在 Agent 没有把握时给出判断。PR 是 Agent 开的，代码是 Agent 写的，测试是 Agent 跑的，文档是 Agent 维护的，Code Review 也是 Agent 做的。

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

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

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

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

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

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

人来搭环境，AI 来做东西。

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

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

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

人来出方向，AI 来发散。

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

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

哪条路值得走，哪个方案更符合用户真实需求，这涉及对上下文的深度理解、对商业逻辑的把握、对人性的洞察。这些不是靠处理更多数据就能解决的，它需要人在真实世界里积累的判断力。

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

人来定规则，AI 来执行。

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

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

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

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

写代码、写内容、做执行，这些会越来越不稀缺。稀缺的是能把 Harness 搭好的人，是能清楚地知道”什么是好结果”并把这个标准表达清楚的人。

能力的重心在向上移，从执行层移到系统设计层。

最后回到 Ryan 那篇文章。

他在结尾写，他们还在学习。还不知道一个完全由 Agent 生成的系统在架构连贯性上会如何随时间演变，还不知道人类的判断力在哪些地方能发挥最大作用，还不知道这一切随着模型能力增长会怎么变化。

我觉得这个坦诚很有价值。Harness Engineering 不是一个有标准答案的领域，它太新了，所有人都在边做边摸索。Ryan 他们在 OpenAI 内部的探索，是目前最前沿的实践之一，但也只是一种可能性，不是唯一答案。

但有一件事是确定的：AI 的能力在增长，但 Agent 能发挥多少，取决于它工作的环境有多好。

你搭的环境有多好，它就能干多好。

不管你是工程师、产品经理还是内容创作者，只要你在用 AI Agent 做任何需要多步骤、多判断的任务，Harness Engineering 都是值得认真对待的事。

这不是一个技术问题，是一个工作方式的问题。

参考资料

Ryan Lopopolo，《Harness Engineering: leveraging Codex in an agent-first world》，OpenAI，2026年2月