多 Agent 协作模式（三）：分工、隔离与验证
前两篇讲了如何用 AI 对话（第一篇）和如何用 AI 做开发（第二篇）。这一篇解决一个更大的问题：当一个项目复杂到单个 AI 处理不过来时，怎么办？
答案是多 Agent 协作——让多个 AI 同时干活，每个 AI 负责不同的部分。但多 Agent 协作不是简单的"人多力量大"，搞不好会比单个 AI 更糟。本文将深入拆解多 Agent 协作的核心原则、常见误区和实战技巧，帮助你真正驾驭多 AI 并行工作的力量。
一个 AI 干一个活
多 Agent 协作的第一原则是：每个 AI 只负责一个明确的模块或任务。
不要给一个 AI 同时安排"写前端"和"写后端"。不要给一个 AI 同时做"写代码"和"写测试"。每个 AI 的职责边界必须清晰。
为什么？因为 AI 的上下文窗口是有限的。一个 AI 同时处理太多任务，它会在不同任务之间搞混——前端的变量名用到后端的函数里，测试用例的逻辑混进业务代码里。
正确的做法是：你有三个模块要做，就开三个 AI 对话。对话 A 只做登录模块，对话 B 只做文章模块，对话 C 只做评论模块。互不干扰。
你作为项目经理，负责把这三个模块的接口定义好、数据格式规定好。每个 AI 按照你定的标准独立开发。
实战技巧：如何定义"一个明确的模块"
"一个模块"并不是越小越好，也不是越大越好。好的模块定义应该满足三个条件：
第一，输入输出清晰。 你能用一两句话说清楚这个模块"接收什么数据、返回什么结果"。比如"接收用户名和密码，返回 JWT Token 和用户信息"——这就是一个清晰边界。
第二，依赖关系最少。 模块 A 需要调用模块 B 的功能？没关系，但只要你不让一个 AI 同时做 A 和 B，它们之间的依赖就是可控的。关键是不让单个 AI 承担两个有交叉依赖的模块。
第三，可在一个上下文窗口内完成。 这是最实际的限制。如果你发现一个模块的描述超过 500 字，或者需要参考的文档超过 3 篇，那这个模块可能还是太大了，应该继续拆分。
验证必须独立
这是多 Agent 协作中最容易被忽视、也最重要的一点。
绝对不能让 AI 自己验证自己写的代码。
一个 AI 写了登录模块，它说"我测试过了，没问题"。你信吗？不应该信。因为它自己写的代码，自己测的时候会自动忽略那些"显然不会出问题"的边界情况。
验证必须由另一个 AI 来做。
具体做法：对话 A 写完了登录模块，你把代码和需求文档发给对话 B，让对话 B 根据需求文档写测试用例并执行。对话 B 不知道对话 A 的实现细节，它只根据需求来判断"这个功能对不对"。
这就像工厂里的质检员——生产的人不能兼质检。
验证的三种层次
在实际操作中，验证可以分为三个层次，从简单到复杂：
第一层：功能验证。 这是最基本的。验证 AI 只需要确认"功能是否跑通"。比如登录模块：输入正确的用户名密码能登录，输入错误密码返回错误提示。这一步大部分 AI 都能胜任，但远远不够。
第二层：边界测试。 这是大多数人会忽略、但最能暴露问题的。验证 AI 需要测试各种极端情况：用户名包含特殊字符怎么办？密码为空怎么办？网络请求超时怎么办？数据库里没有这个用户怎么办？并发 100 个登录请求会怎样？好的验证 AI 会系统性地列举所有边界场景，而不是只测 happy path。
第三层：安全审计。 对于涉及用户数据的模块尤为重要。验证 AI 需要主动寻找安全漏洞：有没有 SQL 注入风险？敏感信息有没有加密？有没有越权访问的可能？会话管理是否安全？这一层往往需要你在 prompt 里明确引导，否则 AI 不会主动想到这些。
环境也要注意隔离
更进一步，验证环境也要隔离。不要让验证 AI 和开发 AI 共享同一个上下文。验证 AI 应该只看到：需求文档、接口定义、代码。它不应该看到开发 AI 的思考过程、调试记录、中间产物。
隔离的好处是：验证 AI 不会"被带偏"。它看到的是最终结果，而不是开发过程中的各种假设和妥协。
具体实现建议：每个对话结束后，把最终版代码复制到一个新文档里，只保留代码和接口说明，去掉所有中间讨论痕迹。把这个干净版本发给验证 AI。
常见问题：什么时候不需要多 Agent？
在热情拥抱多 Agent 协作之前，有必要冷静思考：什么时候不需要多 Agent？
小项目不需要。 一个静态个人博客、一个简单的计算器脚本、一个只需 50 行代码的自动化脚本——这些交给单个 AI 就够了。多 Agent 的协调成本（你的管理时间）可能比开发成本还高。
探索性研究不需要。 你还不确定技术方案、还在比较多条路径的时候，用单个 AI 反复对话试探更高效。等方向明确了，再拆分给多 Agent 并行执行。
强耦合系统要谨慎。 如果两个模块之间的接口频繁变化、有大量共享数据结构，让它们独立开发可能反而增加沟通成本。这时候让一个 AI 统一处理这两个模块，可能比分开更高效。
经验法则：如果你需要超过 3 个 AI 对话才能完成一个任务，那说明这个任务值得用多 Agent 模式；否则，单个 AI 可能更快。
大问题拆小问题
多 Agent 协作能成立，有一个前提条件：你能把大问题拆成小问题。
如果你跟 AI 说"帮我做一个完整的电商网站"，没有任何一个 AI 能做好。因为这个任务太大了，上下文太多，AI 一定会顾此失彼。
但如果你拆成：
- 用户系统（注册、登录、个人资料）
- 商品系统（列表、详情、搜索）
- 订单系统（下单、支付、退款）
- 后台管理（商品管理、订单管理、用户管理）
每个系统再拆成更小的模块。每个模块足够小，单个 AI 能在一个对话里处理完。
拆分的能力，是你作为架构师最核心的能力。 AI 能帮你执行，但拆分的判断必须你来做。因为只有你自己知道哪些模块之间耦合度高、哪些可以完全独立、哪些需要优先完成。
拆分的实用方法论
怎么判断拆分得好不好？一个简单的标准：每个模块能不能用一段话（200 字以内）说清楚它的输入、输出和核心逻辑？ 如果说不清楚，说明这个模块还需要继续拆。
另外，拆分时有两个实用的思考框架：
框架一：按数据流拆分。 想想你的应用中数据的流向。用户输入→验证→存储→查询→展示。每个环节可以是一个模块。好处是接口天然清晰——上一个环节的输出就是下一个环节的输入。
框架二：按用户角色拆分。 想你的用户有几类？普通用户做什么？管理员做什么？每类角色的操作可以独立开发，公共部分抽成共享模块。好处是每类角色的需求相对内聚，不容易互相干扰。
无论用哪种框架，拆分后建议写一个简短的"模块说明书"——每个模块 3-5 句话说明：做什么、不做什么、和谁有依赖。这个文档就是你给 AI 的"项目 Briefing"。
你的角色：项目经理
多 Agent 协作模式下，你的角色从"程序员"变成了"项目经理"。
你不再亲手写每一行代码（AI 写），不再亲自测试每一个功能（另一个 AI 测）。你的工作是：
拆任务。 把大项目拆成小模块，每个模块有明确的输入输出。
定标准。 每个模块的接口格式、数据规范、验收标准。
做协调。 模块 A 和模块 B 之间有依赖？你来定调用顺序。模块 C 的接口变了？你来通知所有相关 AI。
最后验收。 所有模块都做完了，你来组装、集成、做整体测试。
这个工作 AI 替代不了你。因为你需要对整个项目有全局视角，而每个 AI 只看到自己那一小块。
项目经理的时间分配建议
在实际操作中，建议这样分配你的时间：
- 30% 时间用于拆分和规划——这一步做得越好，后面的返工越少。花 1 小时认真拆分，可能避免 10 小时的返工。
- 20% 时间用于写 Prompt——给每个 AI 的指令要足够清晰、足够具体。模糊的 prompt 会导致 AI 反复确认，浪费大量时间。
- 30% 时间用于验收和协调——等项目跑起来后，大部分时间是检查各模块的输出质量、处理模块间的衔接问题。
- 20% 时间用于集成和优化——模块各自工作正常，但合在一起可能出问题。集成测试和性能优化也需要你的关注。
项目管理中的常见陷阱
多 Agent 协作虽然强大，但有几个容易踩的坑：
陷阱一：过度拆分。 把一个简单功能拆成 5 个小模块，每个模块只有 20 行代码。结果是协调成本远超开发成本。记住拆分的原则：每个模块要足够值得独立的 AI 对话来处理（至少数百行代码、有明确的独立功能）。
陷阱二：接口定义不清。 你让 AI A 写用户模块，AI B 写订单模块，但你没有明确定义它们之间怎么通信。最后两套代码完全无法对接。务必在拆分阶段就把接口文档写好——数据格式、字段名称、错误码定义，越具体越好。
陷阱三：忽视集成测试。 每个模块单独测试都通过了，你很高兴。但组装在一起就崩溃了。这在多 Agent 开发中非常常见，因为每个 AI 只保证自己的部分是对的，没有人考虑过整体。集成测试必须由你或一个专门的集成 AI 来做。
陷阱四：上下文漂移。 你用同一个长对话窗口让 AI 做多个相关模块。一开始还行，但对话越长，AI 对最初的需求记忆越模糊，开始出现"自相矛盾"的代码。解决方案：每个模块一句话新建对话，用文档记录接口定义和需求摘要。
实战案例：一个内容管理系统的多 Agent 开发
为具体说明，假设你要开发一个内容管理系统（CMS），我们来走一遍多 Agent 协作的流程。
第一步：拆分。 你分析需求后，拆出 5 个模块：用户认证、文章管理、分类系统、评论系统、后台统计。
第二步：定标准。 你写了简要的接口文档。比如文章管理系统需要提供：创建文章（POST /api/articles）、获取文章列表（GET /api/articles?page=1&limit=10）、获取文章详情（GET /api/articles/:id）、更新文章、删除文章。所有接口统一返回 JSON 格式，包含 code、message、data 三个字段。
第三步：并行开发。 你开 5 个 AI 对话，分别对应 5 个模块。每个对话里你只给该模块的需求和接口文档，不给其他模块的信息。
第四步：并行验证。 5 个 AI 都写完了代码。你又开 5 个对话（或者用同一个对话分 5 次交互），分别验证每个模块的功能和边界情况。
第五步：集成。 你验证各模块无问题后，开一个专门的"集成 AI"对话，给它所有模块的代码和接口文档，让它组装成一个完整系统，并测试模块间的协作。
第六步：部署。 集成测试通过后，你部署上线，观察运行日志，处理遗留问题。
整个流程中，你只做了拆分、定标、验收和集成。所有代码和测试都由 AI 完成。这就是多 Agent 协作的力量。
小结
多 Agent 协作的关键：
- 一个 AI 干一个活——职责清晰，互不干扰
- 验证必须独立——不能自己审自己
- 环境要隔离——验证 AI 不看开发过程
- 大问题拆小问题——拆分能力是核心
- 你当项目经理——拆任务、定标准、做协调、做验收
多 Agent 协作不是银弹。对于小项目，单个 AI 就够了。但当项目复杂度超过单个 AI 的处理能力时，这套模式能让你在不失控的前提下，成倍提升开发效率。
下一篇是这个系列的最后一篇：如何让 AI 在每次项目中自我进化——把经验变成 Skill，让 AI 越用越好用。