结构化调度确定下来以后，下一个问题就是： 到底要拆成几个 Agent，怎么拆。
这一步如果做得不好，多 Agent 不会让系统更稳，只会让系统更乱。 所以我们当时并不是一上来就拍板“就七个”。相反，我们是随着问题暴露，一层一层把角色拆出来的。
6.1 第一步，先拆需求分析、方案设计、开发实现
最早我们碰到的核心问题，是“模糊需求直接流进代码”。 用户说一句想法，AI 很快就能写出点东西，看起来很有执行力，但往往会有三个问题：
需求边界不清
技术方案是边做边想的
做完以后很难说清这是按什么思路做的
所以最先拆出来的，其实是三层最基础的角色：
需求分析 负责把模糊想法变成结构化需求。
方案设计 负责把需求翻译成真正能落地的技术方案。
开发实现 负责按照前面的约束去写代码，而不是边写边定义需求。
为什么这三层必须先拆？
因为如果这三层不拆开，后面所有事情都会混成一团。 需求和方案混在一起，方案和实现混在一起，最后出了问题你根本不知道该补哪一层。
所以可以说，需求分析、方案设计、开发实现 是整套多 Agent 体系最早的骨架。
6.2 第二步，再补上闸门总控
但只拆这三层，很快又不够用了。
原因是： 需求写出来了，方案也写出来了，并不代表它真的已经具备进入开发的条件。
我们在实际跑的时候，很快就遇到很多这种情况：
需求写了功能，但没写清验收标准 | 方案看起来完整，实际漏了关键边界 |
某个改法理论上能做，但放到当前工程里风险很高 | 开发真开工以后，才发现前面很多问题没人提前拦住 |
这时候我就意识到，流程里必须有一个专门的角色，站在“开发之前的最后一道门”上。 于是我们补出了第四个关键角色：
闸门总控（可行性分析）
它的必要性就在于，它不负责重新写需求，也不负责重新写方案，而是专门判断：
这份需求够不够清楚 | 这份方案有没有明显漏项 |
这件事在现有工程里是不是能安全落地 | 现在进开发，会不会把风险直接带进编码阶段 |
如果没有闸门，很多问题都会在开发阶段才爆炸。 而开发阶段是最贵的阶段之一，因为这时候已经开始写代码了，返工成本会迅速变大。
所以闸门总控本质上是在帮我们做一件事： 把很多本该更早暴露的问题，提前暴露。
需求分析、方案设计以及闸门总控实际上是我将之前反复和AI讨论需求文档中，必经的步骤都提炼出来，让AI形成固定工作流。
6.3 第三步，再把代码审查和测试独立成最后收口
接着我们又碰到一个特别现实的问题：
开发说自己做完了，不等于真的做对了。
如果只有需求、方案、闸门、开发这几层，流程还是缺最后的收口。 因为“实现完成”这个动作，本身不能证明：
需求有没有被完整实现 | 方案有没有被正确落地 |
边界条件有没有处理 | 是否引入新的风险 |
于是我们又把下游收口拆成了两层：
代码审查
测试验证
这两个角色为什么不能合在一起？
因为它们解决的根本不是同一个问题。
代码审查的必要性
代码审查不是看格式好不好看这么简单。 它负责的是从实现层回头看：
有没有偏离需求 | 有没有偏离方案 |
代码结构是否合理 | 有无明显遗漏和潜在问题 |
它更像是“技术落地质量”的最后一道收口。
测试验证的必要性
测试验证则是从行为层再看一遍：
功能跑起来是不是对的 | 用户路径能不能真正走通 |
边界和回归有没有炸 | 正确性之外，稳定性和基础性能是不是能接受 |
它更像是“实际结果质量”的最后一道收口。
如果没有代码审查，开发很容易“代码能跑就算完成”。 如果没有测试验证，系统又很容易停留在“看起来写对了”。
所以代码审查和测试，必须是两道独立的关。 这也是为什么我们后来越来越觉得：下游角色不是附属品，而是整套流程的真正收口。
6.4 第四步，再补一个只做路由的 PM
到这里，角色已经不少了。 新的问题又来了：
谁来决定现在该找谁？
如果让每个 Agent 自己判断下一个该找谁，那流程很快又会滑回自由协商。 于是我们最后把项目经理这个角色放到了中央。
但这里有一个特别重要的点：
我们需要的不是一个“最懂研发的 PM”，而是一个“最守流程边界的 PM”。
它的职责只有这些：
读取当前阶段的文档结论 | 决定流程前进还是回退 |
指定下一阶段由哪个 Agent 接手 | 维护交接、迭代、交付记录 |
它不负责：
写需求 | 定方案 |
直接改代码 | 替其他 Agent 给专业结论 |
这一点非常关键。 因为 PM 一旦越界，就会把整个多 Agent 系统重新拉回到“一个中央大脑说了算”的旧路上去。
6.5 为什么最后会稳定成这七个 Agent
所以最后，这套系统自然收敛成了我们现在的七个 Agent：
1 项目经理（PM） 负责路由、交接、回退和进度管理。 | 2 需求分析 负责把模糊诉求变成清晰需求。 |
3 方案设计 负责把需求变成技术方案。 | 4 闸门总控（可行性分析） 负责在开发前做最后的可行性和风险把关。 |
5 开发实现 负责真正落地代码和实现细节。 | 6 代码审查 负责从实现质量、需求一致性、方案一致性上做技术收口。 |
7 测试验证 负责从功能正确性、稳定性、边界和回归风险上做结果收口。 |
这里最重要的不是“正好七个”，而是这七个角色各自解决了一个前一个角色解决不了的问题。
需求分析解决“想做什么” | 方案设计解决“打算怎么做” | 闸门总控解决“现在能不能做” |
开发实现解决“真正把它做出来” | 代码审查解决“是不是按要求做出来” | 测试验证解决“做出来的东西到底能不能用” |
PM 解决“整条链怎么有序地串起来” |
这就是它们各自的必要性。 不是为了把流程搞复杂，而是为了把一个原本混在一起的大任务，拆回到可以被管理、被交接、被替换、被回退的几个模块。
6.6 角色拆完以后，我们还做了一件很实际的事：给不同 Agent 配不同档位的模型
这一点其实很工程化。
很多人一提多 Agent，会下意识觉得既然都拆角色了，那是不是所有 Agent 都应该上同样强的模型。 但我们实际跑下来发现，这样做既没必要，也很浪费。
原因很简单：不同 Agent 的工作性质，决定了它们对模型能力的要求并不一样。
比如 PM 这个角色，本质上只负责流程流转、阶段判断、交接记录和任务推进。 它最重要的是守流程、读文档、做路由，而不是输出特别复杂的专业结论。 所以对 PM 来说，用一个相对简单、但更节约 Token、性价比更高的模型，往往就已经足够了。
而像需求分析、方案设计、代码审查、测试这类角色，承担的专业判断明显更重，对理解能力、推理深度、细节覆盖度的要求也会更高。 这时候就更适合给它们配更强一点的模型，把算力花在真正需要的地方。
这件事带来的好处非常现实：
不是所有环节都在用最贵的方式跑 | 整体成本更可控 |
真正高价值的专业环节反而能拿到更合适的能力 | 整套流程更容易长期稳定地跑下去 |
不是每个岗位都配同一把最贵的锤子，而是让不同岗位用最合适、最有性价比的工具。
多 Agent 真正落地以后，很多设计都不再只是“AI 玩法”，而会越来越像真实团队的资源配置问题。
顺便提一句，这套“给不同 Agent 分配不同模型”的实践，我目前主要是在 Cursor 上完成的。 在我上个月体验 CodeBuddy 时，它还不支持为各 Sub Agent 自定义所用模型；但很快 CodeBuddy 就补上了这一能力——在这里要为 CodeBuddy 的迭代速度点个赞。 这类能力一旦具备，多 Agent 会从“能跑”进一步走向“跑得更合理、更省成本”。
当你真的进入多角色、多阶段、长期迭代的工程开发以后，模型分层配置本身就会变成 Harness Engineering 里非常重要的一部分。