做到这里，七个 Agent 的骨架其实已经搭起来了。 而且老实说，跑起来以后效果确实和我们预期差不多。
复杂需求终于不再是一个 Agent 一路硬闯，而是开始形成一条标准的文档链。 像我们后来一些比较完整的需求，已经能够沉淀出标准的阶段文档，整条链也更清晰了。
但这并不意味着系统就成熟了。 恰恰相反，真正把这套东西跑起来以后，新的问题才开始一轮一轮冒出来。
这一章我想讲的，就是这些真实的曲折过程。 因为 Harness Engineering 从来不是“一次设计到位”，而是跑一段、撞墙、补洞、再跑一段、再升级。
7.1 第一轮问题：下游开始自己修改上游文档
多个 Agent 真正协作起来以后，第一个很快暴露出来的问题是：
下游觉得上游做得不够好，就顺手自己改了。
最典型的，就是方案设计看完需求分析写的文档以后，觉得某些地方不严谨，于是没有选择打回，而是自己按照理解把需求补掉了。
这件事听起来很“聪明”，甚至一开始你会觉得它像是在帮你提高效率。 但跑久了你会发现，这是非常危险的：
需求到底是谁负责，开始变得模糊
方案到底是基于原需求，还是基于方案设计私自修过的需求，也开始模糊
真出了问题以后，你根本不知道该追责给哪一层
所以我们后来明确加了一条非常重的规则：
下游不能直接改上游文档。 当下游认为上游产出不合格时，只能提出阻塞项，由 PM 把流程正式打回给上游。
这一条一落地，整个系统第一次真正有了“谁负责哪份产物”的边界感。
7.2 第二轮问题：PM 太容易越界
流程继续往下跑以后，很快又冒出第二个问题：
PM 很容易从流程管理者，滑成一个到处给意见的人。
这其实很好理解。 PM 站在流程中心，天然知道所有阶段发生了什么。一旦需求不清、方案有争议、开发遇到卡点，它就特别容易顺手说：
“这个需求我觉得可以这么补”
“这个方案不如改成那样”
“这个问题别退了，开发顺手修一下就行”
但我们后来越跑越清楚地认识到： PM 给出的这类意见，往往并不专业，甚至特别容易把整个流程带偏。
所以我们后来对 PM 的职责做了严格收缩：
PM 只负责流程管理 | PM 不负责专业判断 |
PM 不负责给需求、方案、开发、测试提建议 | 其他 Agent 拿不准时，PM 只能去拉真正能解决问题的专业 Agent |
实在无法明确的，流程必须暂停，由人来做最终决策 |
这一轮调整以后，PM 的定位才真正清晰下来：
它不是流程中央的“总专家”，而是流程中央的“总路由器”。
7.3 第三轮问题：各个 Agent 的专业性都还不够，这里以代码审查和测试这两个 Agent 举例
接着我们又踩到了第三个坑。
跑了一段时间以后我们逐渐发现，问题并不只是某一个 Agent 做得不够好，而是整套多 Agent 在早期都还存在专业性不够深的问题。
需求分析会有需求边界挖得不够透的时候，方案设计会有方案覆盖不够全的时候，闸门总控也会有风险识别不够狠的时候。 这里我选择以代码审查和测试这两个 Agent 来举例，是因为它们在整条链里处在非常典型的收口位置，更容易把前面累积的问题看得更清楚。
因为前面角色如果专业性稍微差一点，问题不一定立刻炸；但一旦到了收口阶段，很多前面遗漏的问题会一下子集中暴露。
所以这里我还是拿代码审查和测试举例，不是因为只有它们不专业，而是因为它们最能代表“整套系统的专业性不足，最后会在哪里爆出来”。
虽然前面几层已经拆开了，但到了下游，我们一开始的代码审查和测试，确实也都还比较“常规”。
最初的代码审查，更像是普通的代码审查：
看有没有明显逻辑 bug
看有没有违反 Rule
看实现有没有一些基础问题
最初的测试，也更像常规验证：
看功能大面上能不能跑
看是否有明显异常
这些当然有用，但远远不够。 因为到了这个阶段，代码审查和测试实际上已经不是一般角色，而是整条链的最终收口。
它们如果只看“本层有没有问题”，就会漏掉很多真正重要的东西：
需求有没有被完整实现 | 方案有没有被正确落地 |
验收标准有没有被覆盖 | 在功能正确之外，稳定性和基础性能有没有达到要求 |
所以后来我们专门加强了这两个角色的专业性要求。
代码审查不再只是给代码意见，而是必须对照需求和方案，确认“做的是不是对的、是不是完整的”。 测试也不再只是走一遍流程，而是要站在真正收口的位置，去看功能、边界、回归、稳定性和基础性能诉求。
我展示一下我现在的需求分析agent，大家也可以作为参考：
这一步很重要。 因为从这里开始，多 Agent 才不只是“流程拆得很细”，而是真的开始具备质量闭环能力。
7.4 第四轮问题：Rule 约束开始不够用了
流程问题补得差不多以后，我们一度以为系统已经比较稳了。 但很快又发现一个新的老毛病：
很多已经写进 Rule 的基础约束，Agent 还是会时不时不遵守。
比如它会说：
“这个不通过不是我引入的，是之前遗留的问题”
“这条 Rule 这次场景特殊，可以先不管”
“我已经做了主要工作，这一步可以先跳过”
走到这里我才真正意识到一件事：
Rule 再多，本质上还是自然语言约束。
自然语言约束可以管住很多基础行为，但当需求越来越复杂时，它一定会被忽略、被绕过，或者被“解释性执行”。
所以我们后来又往前走了一步： 把很多能判定的约束，尽量落地成脚本。
也就是：
编译要过，不是口头说“应该没问题”
测试要过，不是口头说“理论上没影响”
规则扫描要过，不是口头说“这次特殊”
只有脚本通过，才算真正开发完成。
这也是为什么后来总验证脚本变得越来越重要。 因为它不是又多了一份工具，而是把“是否完成”这件事，从 Agent 的主观汇报，变成了一个可检查的客观结果。这个话题将在第八章展开细聊。
7.5 第五轮问题：Agent 会偷懒，于是又补了基线对比
脚本上来以后，本来以为事情就结束了。 但 AI 很快又展示了新的“聪明”。
它会告诉你：
“这次不通过不是我造成的”
“这个错误本来就存在”
“这个 Warning 是历史遗留”
这时候如果你没有额外机制，真的很容易被它糊过去。 于是我们又顺手补了一层：
开发前先跑一次，开发后再跑一次，做基线对比。
做法上一般是：改代码前先跑一遍总验证（或同一套测试与静态检查），把输出或报告留作基线；改完再跑一遍，对两次结果做对比（看新增失败、告警或违规项）。
如果开发后新增了错误、失败、Warning 增量，就必须修。 这样一来，“是不是你这次引入的”就不再靠嘴解释，而是靠前后报告对比。
这一点很像给 AI 又加了一层紧箍咒。 但它也恰恰说明了一件事：
Harness 不是只靠相信 AI，而是靠不断补机制，让它没有太多偷懒空间。
7.6 第六轮问题：流程本身也开始难维护了
当需求一轮一轮跑下来，系统越来越成熟时，我们又遇到了一个更后期的问题：
流程本身开始越来越难维护。
最开始，很多流程规则都写在 PM 的长文里。 一开始这样是够用的，但到后面，阶段多了、回退边多了、角色边界多了，你会越来越痛苦：
规则都在长文里，能看，但不好校验 | 改一处很容易漏另一处 |
阶段和回退关系越来越复杂，维护久了很容易双写不一致 | 换维护人、换模型以后，角色边界容易漂 |
这时候我才意识到，前面那几轮补洞主要都在解决“让流程能跑起来”，而这一轮要解决的，是让流程本身也变成可维护资产。
所以我们后来又做了一次专门的升级，这次升级不是再多加几个 Agent，也不是再补几条 Rule，而是把原来散落在长文和默契里的流程要素，正式抽出来。
我们大概补了三层东西。
第一层：把流程结构单独抽成流程定义文件
以前流程主要写在 PM 的长篇说明里。 这种写法的好处是人读起来顺，但坏处也很明显：当阶段、迁移边、回退边越来越多时，流程结构就会被埋在大段描述里。
于是我们后来把下面这些东西单独抽出来：
有哪些阶段 | 每个阶段默认由哪个 Agent 负责 |
正常应该怎么往前走 | 出问题时允许退回到哪 |
某些特殊回退要满足什么条件 |
这样一来，如果以后再回答“这条流程到底怎么走”，就不需要先去翻一大篇散文，而是先看这份流程定义文件。
它的价值在于，流程结构第一次从“写在说明里的知识”，变成了“可以单独维护、单独校验的资产”。
第二层：把每个 Agent 的输入输出抽成角色契约
光有流程定义文件还不够。 因为就算你知道现在该轮到哪个 Agent，如果没有进一步说清楚“它到底该读什么、写什么、什么情况下算阻塞”，角色边界还是会慢慢漂。
所以我们后来又给每个 Agent 都补了一份角色契约。 它其实就是每个角色的接口说明。
里面重点固定几件事：
这个角色必须读哪些上游产物 | 这个角色必须写出哪些文档结果 |
什么情况下它有权提出阻塞 | 什么情况下它必须把问题交回 PM 路由 |
这样做以后，Agent 就不再只是“一篇很长的人设提示词”，而更像一个有输入输出边界的稳定模块。
这对长期维护特别重要。 因为后面即使你换模型、换提示词，甚至换维护人，只要契约还在，角色边界就不至于轻易漂掉。
第三层：再补一个流程校验脚本
流程定义文件和角色契约都抽出来以后，还差最后一步：
怎么保证这些流程资产本身是齐的、是一致的。
于是我们后来又补了一个流程校验脚本，专门去检查最基础的几类问题，比如：
流程定义文件是不是存在 每个 Agent 对应的契约文件是不是齐全 流程里提到的角色，能不能在契约里找到
它现在还不是一个特别复杂的“流程编译器”，但已经足够把很多最容易出现的低级问题拦在前面。
比如以前很容易出现这样的情况：
PM 文档里写了一套流程 | 角色文档里又是另一套说法 |
某个契约文件忘了补 | 某个阶段加了，另一个地方却没同步 |
这些问题单看都不大，但一旦累积起来，整个多 Agent 流程就会越来越难维护。
所以这一轮升级的本质，其实非常明确：
不是让流程更复杂，而是让流程本身也从“靠人记住”升级成“可以被拆分、被维护、被校验”的工程资产。
7.7 回头看，这一整段曲折过程说明了什么
第五章到第七章连起来看，其实是在回答同一件事：
第五章在解决“为什么选这条路线” 第六章在解决“这条路线上的角色怎么拆” 第七章在解决“拆完以后，系统怎么继续补稳”
也就是说，Harness Engineering 在真实项目里的成长路径，根本不是：
✕ 不是这样 先设计一套完美体系，再照着执行。 | ✓ 而更像这样 先用最小可用形态跑起来，然后在真实问题里不断补结构、补边界、补门禁、补反馈闭环。 |
这也是我特别想让读者看到的一点。 如果你要在自己的项目里搭 Harness，不要以为第一天就得把最终形态全画出来。 更现实、更正确的做法，往往是：
先看你当前最大的痛点在哪里 | 先补最关键的一层 |
让系统先跑起来 | 然后在真实问题里继续把它补强 |
这才是它真正落地的样子。
7.8 如果你想在自己的项目里从 0 开始，我建议按这个最小顺序搭
前面讲的是完整演化过程，这里把它收成一个最小起步路径。
如果你今天手上也有一个项目，想把 AI 慢慢带进工程里，我建议不要一上来就把所有东西一次搭齐，而是按下面这个顺序来：
1 先磨出一份能指导开发的设计规格文档 先别急着写 Rule、拆 Agent。先把目标、边界、验收标准、兼容要求这些最基本的问题和 AI 反复聊透。没有这一步，后面所有约束都会飘。 | 2 先补最关键的 Rule，不要贪多 一开始只盯那些最容易反复出错、最容易偷懒的底线，比如“改完必须编译、测试、做验证”。不要第一天就写几十条 Rule，把自己也压垮。 |
3 把高频固定动作下沉成 Skill 当你发现某些动作每次都要做、而且每次都不希望 AI 临场发挥时，就把它们做成 Skill。编译、测试、事后验证，往往是最适合最早下沉的一批。 | 4 当单 Agent 开始失稳时，再拆多 Agent 如果任务还短、链路还浅，一个 Agent 先跑也没问题。只有当你明显感到它开始混淆需求、方案、实现和自我评估时，再拆需求分析、方案设计、开发、评审、测试这些角色。 |
5 当多 Agent 开始变复杂时，再补流程定义文件和角色契约 一开始流程短的时候，长文说明也许够用；但当阶段多了、回退多了、维护人也多了，就要尽快把流程结构和角色边界单独抽出来。 | 6 当项目进入持续迭代时，再补 dev-map 和任务看板 这一步解决的是“AI 怎么快速理解整个项目，而不是只理解当前任务”。项目越大、历史越长，这一层就越重要。 |
7 当你想把闭环继续往外推时，再考虑 MCP 先把开发闭环跑通，再去接构建、签名、发布、制品这些外部工程系统。不要一开始就把整个世界都接进来。 |
先让 AI 知道该做什么，再让它知道必须怎么做，再让它在复杂任务里学会分工，最后再让整套流程本身变成可维护的工程资产。
实际跑起来时的界面
上一节收的是「从零开始按什么顺序搭」。这里贴一张 Cursor 长截屏：同一条线拿去解一个具体需求时，PM Agent（Orchestrator，总调度） 按 workflow 依次调用各子 Agent，从分析、方案、开发、审查一直到测试和收尾。左侧是这一路的时间线——谁被点到、何时跑完、审查打回再跑也留在上面；右侧是同一段里我跟 PM 的对话，和左边各步大体对得上。
