当时我的直觉很简单：既然 AI 经常忘事，那我就把容易忘、容易错的事情写成 Rule。
于是，像“改完必须完成编译、测试和事后验证”这一类规则就出来了。它本质上是在告诉 AI：
每次代码修改完成后必须编译 | 编译通过后必须跑测试 |
测试通过后必须跑事后验证 | 只有三步全部通过，任务才算真的完成 |
这一步非常有用。因为 AI 最爱偷懒的地方，恰恰就是那些“看起来像收尾，其实是底线”的动作。比如很多时候它会觉得：
“我改的是文档，不用编译”
“我只是小改，不用跑测试”
“这次失败看起来是历史问题，不算我引入的”
Rule 一上去，这些最粗糙的问题会立刻少很多。
但如果你真的在复杂项目里跑过一段时间，你会很快发现 Rule 的天花板。
Rule 多了以后，会出现两个非常典型的问题。
3.1 AI 会忽略 Rule
不是完全不看，而是会在复杂任务下“局部遗忘”。尤其当你的需求很长、上下文很重、同时加载了很多别的内容以后，一些 Rule 在实际执行时会被稀释掉。
3.2 AI 会绕过 Rule
这个比忽略更麻烦。因为它不是不知道规则，而是会开始给你找理由。
比如：
这次不通过不是我引入的，是之前遗留的
这个 Rule 说的是常规需求，这次是特殊情况
我已经做了等价验证，不需要完全照规则来
这其实是我做 Harness 过程中非常关键的一个认知转折：
Rule 不是没用，而是 Rule 只能做“原则约束”，不能做“流程执行”。
当我意识到这件事以后，我就开始做下一步：把固定流程从 Rule 里拆出去，做成 Skill。
如果你认真观察，你会发现工程里有一类事情非常适合做成 Skill：
执行步骤固定 | 每次都要做 |
做错一次就很恶心 | 不值得让 AI 每次重新思考 |
编译、单元测试、事后验证，就是这一类事情。
所以我们把这几个流程单独做成了 Skill，比如编译 Skill、测试 Skill、事后验证 Skill。
这样一来，Rule 里就不需要再写一堆细碎的命令和注意事项了。Rule 只要保留一句话：
“你必须做这件事。”
而 Skill 则负责把“这件事具体怎么做”写清楚。
这样做的好处特别直接：
1. Rule 变轻了
以前 Rule 既讲原则又讲流程，越写越长。现在 Rule 可以只保留真正的红线，复杂的执行步骤都交给 Skill。
2. AI 的执行稳定性变高了
以前 AI 需要临场理解“编译应该怎么编、测试应该怎么测”。现在它不是理解，而是调用一套现成的方法。
3. 维护成本更低了
比如你后来修改编译流程，只需要改编译 Skill 本身，不需要去全项目搜索每条 Rule 里是不是都写了旧命令。
这一步做完以后，我们整套系统的健壮性明显提升了一截。 但新的问题很快又出现了：
单个 Agent 在复杂需求下，还是不够稳定。
前面在规格设计文档（SPEC）、Rule、Skill 这几层补齐以后，我们已经明显感觉到系统比最早稳了很多。 至少 AI 不再是“拿到一句话就直接开写”的状态，它开始知道目标、知道约束、知道固定流程。
但当需求继续变复杂以后，一个新的问题开始越来越明显：
单个 Agent 很难在长时间、复杂链路的开发里，同时把需求理解、方案设计、风险判断、编码实现、代码自审、测试验证都做好。
这件事不是因为模型不够聪明，而是因为我们在强迫它一次性扮演太多角色。
一个 Agent 如果既负责理解需求，又负责设计方案，还负责判断可行性，再负责写代码，最后还要自己审自己、测自己，它一定会出现下面这些问题：
走到这里时，我其实面对的是一次很典型的技术选型问题。 不是“要不要上多 Agent”这么简单，而是：到底应该选哪种多 Agent 形态。
5.1 第一种做法：继续强化单 Agent
这是最容易想到的路线。 既然一个 Agent 不够稳，那就继续给它补：
更长的设计规格 | 更多的 Rule |
更细的 Skill | 更严的检查步骤 |
这条路我们其实已经走过一段，而且不能说完全没用。 SPEC、Rule、Skill 这几层，恰恰就是这样一步一步补出来的。
但问题在于，这条路越往后走，越像是在把越来越多的责任塞进一个“大而全”的角色里。 它可以让单个 Agent 变得更谨慎，却很难解决“角色冲突”本身。
说得更直接一点：
需求分析和代码审查，本来就不是同一种工作
方案设计和测试验证，本来就不是同一种思考方式
让一个 Agent 同时扮演所有角色，本质上还是在赌它一次性全都做好
这在简单任务上能凑合，在复杂工程里就会越来越吃力。
5.2 第二种做法：去中心化协作
网上很常见的另一条路，是让多个 Agent 平起平坐，通过对话和协商动态达成共识。 这类模式看起来很高级，也很像“一个 AI 团队在开会”。AutoGen 的 GroupChat 一类思路，就是这种方向的典型代表。
它的优点确实很诱人：
足够灵活
现场应变能力强
不需要一开始就把流程定义得很死
但它的缺点，在真实工程里会越来越大：
行为路径不稳定 | 每次面对同类需求，可能走出不同流程 |
谁该对哪部分结果负责，不够明确 | 一旦出问题，回退到哪一层并不清晰 |
后续换模型、换维护人时，很难保持一致 |
如果你的目标是做一个很聪明的演示，或者探索一个开放式问题，这种模式很有魅力。 但如果你的目标是长期维护一个真实项目，它就会逐渐暴露出一个致命问题：
好看，但难维护。
5.3 第三种做法：结构化调度
还有一条路，就是把多 Agent 做成一条有明确角色分工、有明确流转规则的结构化流程。
这种模式的典型特征是：
明确有一个项目经理角色 | 明确每个阶段由谁负责 |
明确每一阶段的输入和输出 | 明确什么时候能往前走，什么时候必须回退 |
它的优点也非常明确：
流程清晰 | 可控性强 |
结果可审计 | 很适合文档沉淀 |
更方便长期维护和角色替换 |
它的缺点也不是没有：
前期设计成本更高
灵活性会比自由协商差一些
产物更多，token 消耗更大
但我们最后还是坚定地选了它。 因为到了真实工程阶段，你会越来越清楚一件事：
真正贵的不是 token，真正贵的是失控。
我们需要的，不只是“AI 把代码写出来”，我们还需要：
需求文档 | 方案文档 | 开发文档 |
代码评审结论 | 测试文档 | 交付结论 |
阶段进度和回退记录 |
这些东西不是形式主义，而是为了让后续任何一个人、任何一个 AI，在几天后、几周后、几个月后，都还能看懂：
这个任务为什么这么做 | 做到哪一步了 |
哪些风险已经处理 | 哪些问题是在哪一层暴露的 |
如果现在要继续维护，应该从哪接上 |
所以从项目可维护性、流程规范性、角色可替换性来看，结构化调度几乎是我们能找到的最适合这类工程的方案。
三条路线压缩成一张表会更清楚：
5.4 结构化调度里，我们也做过一次内部 PK
即便确定了走结构化调度，这里面其实也还有两种常见做法。
做法 A：固定角色、固定流程
也就是先把有哪些 Agent、每个 Agent 干什么、什么阶段找谁，尽量定义清楚。 项目经理只负责按流程调度。
优点是：
稳定 | 容易维护 |
容易沉淀文档和规范 | 很适合固定类型的工作流 |
做法 B：只固定 PM 和开发经理，具体 Agent 动态生成
这种模式会让上层保留项目经理和开发经理，具体研发时由开发经理动态“招聘”或生成不同的 Agent 去做事。
它的好处是：
灵活性更强
面对非常多样化的问题时，理论上更容易按需适配
但问题也很明显：
角色边界更漂 | 维护成本更高 |
行为更依赖当前上下文和即时判断 | 很难做长期稳定的流程复用 |
我们最终还是选了第一种。 原因并不复杂：我们的实际开发工作流，虽然需求内容会变，但大的阶段结构其实相对固定。
比如：
一个标准需求开发，通常就是需求分析、方案设计、评估、开发、代码审查、测试、交付
一个 Bug 修复，也可以落到相对固定的裁剪版流程
既然工作流本身并不是完全开放式的，那就没必要为了“理论上的灵活性”牺牲掉稳定性和可维护性。
往前看，这几次 PK 其实都在做同一类取舍：灵活性和稳定性之间，我们最后都更偏向后者。因为对一个要长期维护的工程来说，可控、可追踪、可复用，比“理论上更灵活”重要得多。
5.5 这一章最重要的结论
所以第五章真正想讲清楚的是：
我们不是因为“多 Agent 很酷”才去做多 Agent。 我们是因为：
单 Agent 到复杂需求阶段开始失稳
自由协商式多 Agent 不适合长期维护
动态招聘式结构化多 Agent 对当前项目来说过于漂移
在一轮轮技术选型和对比之后，最后才落到了今天这条路上：
用结构化调度，把研发流程拆成一组固定角色和固定阶段，让 AI 不再是一个人在乱拳打死老师傅，而是进入一个被制度化管理的研发体系。