作为一个长期折腾各种自动化方案的人，我对"造一个能自己干活的系统"这件事有天然的执念。但早期试过不少单体的 Agent 框架，总被同一个问题卡住：单个模型实例一旦任务复杂，就开始忘事、跑偏，上下文一长连自己最初的目标都丢了。后来接触到一个叫agency-agents的项目思路——它核心不是再做一个更强的单体 Agent，而是参考现实公司的分工逻辑，把任务拆给一组各司其职的 Agent 协作完成。这个方向一下子戳中了我的需求，我基于它搭了一套自己的协作系统，跑了几个月，把过程中踩过的坑和最终沉淀下来的设计一起整理出来。如果你也在纠结多 Agent 系统怎么编排角色、怎么通信、怎么避免 Agent 之间互相污染上下文，这篇文章应该能帮你省不少试错时间。
我默认读这篇文章的你，已经具备一定的项目实操经验，至少自己调过一两个 ChatBot API，知道 temperature、token、system prompt 是什么概念。如果纯小白，也能看懂，但动手实操时建议先跑通一个最小 Demo 再回来对照架构细节，否则信息量会有点大。
1. 为什么最后选了"模拟公司分工"这条路
先聊清楚一个问题：单体 Agent 到底哪里不够用，才催生了多 Agent 协作这套思路。
我最早做自动化写作和代码生成时，最崩溃的场景是"长任务发散"。让一个 Agent 写一篇产品分析长文，开头 2000 字还正常，写到 4000 字就开始重复前面的观点，甚至自相矛盾。后来我把任务拆成"大纲—初稿—分章节—整合"这么几个阶段，每一阶段单独调一次 API，效果好了不少。这其实就是朴素的流水线思想：将大任务拆成小任务，每个子任务控制在一个较小的上下文窗口内，模型就不容易因为长上下文而崩溃。
但分阶段调用有一个致命缺点——阶段之间没有反馈回路。我在第二阶段写完初稿，第三阶段发现数据引用错了，第二阶段的模型根本不会知道，也不会自动修正。于是问题从"一个模型做全部事情"变成了"多个模型各做各的，但没有人对整体结果负责"。
让我下定决心走 agency-agents 这条路的，是看到它把"监工"这个角色也做成了 Agent。流程不再是单向流水线，而是形成闭环：规划 Agent 负责拆任务，执行 Agent 负责干活，审查 Agent 负责找毛病，修正 Agent 负责返工，规划 Agent 最后验收。这本质上就是把一个公司的人力结构压缩进了一套自动化系统里。
用这种方法还有两个不容易察觉的好处。第一，每个 Agent 的系统提示词可以极垂直——审查模型的 prompt 里不用写任何业务知识，只需要写"挑错标准"，这比一个全才模型的 prompt 简单得多，也稳定得多。第二，出错时可以精准定位责任节点，而不是对着几千行日志猜"到底是哪一句话让模型疯了"。
我在项目里把这个系统命名为agency-sim，但图省事还是会直接在代码仓库里叫它 agency-agents，因为核心目录结构就是按不同角色分的 agents 包。
提示：不要一上来就搞 10 个 Agent。我试过头重脚轻的角色编排，结果系统的排查难度爆炸式上升。最合适的起步规模是 4-5 个 Agent，每个职责边界清晰，等跑稳了再慢慢加角色。
2. 项目骨架与角色分工设计
2.1 五个角色的职责边界与提示词思路
我现在的稳定版本一共 5 个 Agent，分别对应公司在一次任务中会出现的角色。这个数量不是拍脑袋定的，而是反复删减后保留下来的最小可用集合。
| 角色 | 对应公司岗位 | 核心职责 | 输入内容 | 输出内容 |
|---|---|---|---|---|
| Planner | 项目经理 | 拆解用户需求，制定任务清单和验收标准 | 用户原始需求 | 结构化的任务列表 |
| Researcher | 研究员 | 负责收集结构化资料，整理事实与数据 | 任务清单中的调研项 | 参考资料包，标注来源与置信度 |
| Writer | 内容生产者 | 根据资料包撰写正文内容 | 规划任务 + 资料包 | 按模板产出的初稿 |
| Reviewer | 质检员 | 对照验收标准逐条审查，发现缺陷 | 初稿 + 任务验收标准 | 缺陷列表，每条含严重等级 |
| Reviser | 返工执行者 | 根据缺陷列表对稿子做局部修改，不改动无关部分 | 初稿 + 缺陷列表 | 修改后的终稿 |
每个角色背后其实都是同一个大模型 API，区别在于三样东西：系统提示词、暴露给它的工具集、输出格式约束。
拿 Reviewer 举例子，它的系统提示词和我写代码时的 code review 自查清单几乎一一对应，包括：事实是否和资料包一致、数据引用是否能在参考资料里找到出处、文章结构是否衔接生硬、结尾是否立得住。这个 Agent 不允许调用任何外部工具，只能读内容，所以在实现上它不需要任何 API key 之外的额外配置，只是不允许配工具。
Writer 则相反，它的特权很大——可以调用资料包、结构化数据文件、模板库，但绝对不直接接触原始用户需求。为什么要做这个隔离？因为我在早期版本里发现，如果 Writer 同时能看到用户需求原文和资料包，它会把两者混在一起，写出"我知道用户想要什么"这种自以为是的话，而且引用数据时喜欢夹带私货。隔离了需求原文之后，Writer 只能基于资料包做二次创作，素材边界就锁住了。
2.2 编排层的实现逻辑
这套角色系统需要一个编排层把 5 个 Agent 串起来。我用的是一种叫"状态机加任务队列"的简化方案，没有上太重的框架。
核心数据结构是一个任务状态机，每个任务有这些状态：pending（等待调度）、in_progress（执行中）、reviewing（审查中）、rejected（需要返工）、completed（完成）。
任务状态流转: pending -> in_progress -> reviewing -> completed | | v v rejected <- 缺陷太多需要返工Rejected 出来的任务不会直接回到 Writer，而是带着 Reviewer 的缺陷列表回到 Planner。Planner 的任务是判断这缺陷是内容问题、资料问题、还是需求理解偏差，然后决定是给 Reviser 局部返工、让 Researcher 补充资料、还是直接打回需求理解阶段重新立项。
这个设计的精妙之处在于决策权不分散。每个 Agent 都只能发现自己职责范围内的问题，但要不要返工、谁来返工、返工到什么程度，永远由 Planner 一个 Agent 拍板。这避免了现实中多部门互相踢皮球的现象出现在系统里。
2.3 不是所有任务都需要走全流程
刚开始我很死板，什么任务都让 5 个 Agent 全跑一遍。后来发现有些小事根本不需要研究这个环节，有些活不需要审查。我加了一个角色——Router（路由器），它不是独立 Agent，而是一组规则。
路由规则示例: 如果任务类型 = "简单文案改写" 且 字数 < 300: 跳过 Researcher 和 Reviewer 如果任务类型 = "数据分析报告" 且 有数据文件: 强制走 Researcher + Reviewer 如果任务类型 = "代码重构": 增加一个 Tester 角色（在 Reviewer 之后执行）这个 Router 规则让我系统整体效率提升了 30%，因为小型任务不再被重型审查流程拖累。它也很好地体现了 agency-agents 的核心理念——角色和能力分离，任务的需求决定哪个角色登场。
3. Agent 之间的通信协议与上下文隔离
3.1 消息结构的设计
多 Agent 系统最容易翻车的点不在单个 Agent 的推理能力，而在它们之间的对话协议。如果两个 Agent 对同一术语的理解不一致，或者消息里缺少必要的信息字段，下游 Agent 就会在错误的上下文里继续工作，产生错上加错的结果。
我在设计通信协议时参考了消息队列的思路，每条任务消息包含五个固定字段：
{ "message_id": "msg_8f3k2d9f", "task_id": "task_1001", "from_agent": "planner", "to_agent": "researcher", "payload": { "instruction": "查找2024年市场规模数据", "context_refs": ["requirement#3"], "constraints": { "deadline": "2024-12-01", "source_priority": ["官方统计", "行业白皮书"] } }, "metadata": { "depth": 0, "parent_task_id": "task_1000" } }这个结构的核心思路是：payload 只放对执行有用的信息，context_refs 引用的是项目里的共享上下文文件，而不是把大段原文复制粘贴到消息里。这样做的直接好处是省 token，间接好处是避免上下文污染。
3.2 共享上下文文件作为"白板"
一开始我的 Agent 之间直接传完整文本，结果系统跑不到 10 轮，消息里堆了几万 token 的历史记录，每个 Agent 都被无效上下文带偏。后来我引入了"共享白板"机制——项目目录下维护一个 context 文件夹，每个任务有自己的上下文文件，Agent 只通过 context_refs 按需读取。
这个白板机制的灵感来自我在团队协作时的体验：会议室里的白板写满了当前讨论的核心信息，每个人进来只需要扫一眼关键部分就能跟上思路，而不是从头到尾听完所有人的发言。对 Agent 也是同理，给它的上下文只需要包含与当前手头任务直接相关的材料，它就能表现得像个专注的专家，而不是一个充满精神污染的万事通。
共享上下文文件里我会维护一个"事实清单"。"事实清单"是系统中所有经过 Reviewer 验证过的数据结论的集合，后续 Agent 引用数据时，必须先查事实清单，查不到才去找来源取新数据。这相当于建立了一套系统内部的"记忆锚点"，防止不同 Agent 各说各话。
3.3 防止 Agent 陷入"鸡同鸭讲"
还有一种常见的通信混乱是术语歧义。比如 Planner 说"做市场分析"，Researcher 理解成"查市场规模"，Writer 理解成"做竞品对比"，结果交付内容完全跑偏。
我的解决方案是在消息中强制附加一个"交付物定义段"。每个任务消息的 payload 里必须有 deliverable（交付物）字段，明确说明这个任务完成后应该产出什么格式的文件、包含哪些模块。Planner 每次派单时都会把 deliverable 写死，下游 Agent 只能在这个范围内发挥。这个字段在早期版本里是选填的，后来我发现只要有 Agent 偷懒不填，整个流程就会出现不可预知的变形，于是直接改成必填并用代码校验。
注意：Agent 通信协议越严格，单个 Agent 的发挥空间就越小。但别慌，实际效果告诉我，一个严格执行协议但创新能力有限的 Agent，比一个自由发挥但经常跑偏的 Agent 有价值得多。多 Agent 系统的核心竞争力不是单个 Agent 的智商，而是流程的可控性。
4. 任务路由与依赖调度：多 Agent 协作的核心难点
4.1 任务的依赖关系与 DAG 建模
当你有了多个 Agent 之后，最头疼的问题就变成了：这些 Agent 什么时候该干活、谁先干、谁后干、哪些能干、哪些必须等别人干完。
举一个实际场景：用户要求系统产出一份"2024年某行业市场分析报告"。这个需求会被 Planner 拆成 7 个子任务：
- 定义报告框架和章节结构（Planner 直接完成）
- 调研行业市场规模与增长率（Researcher）
- 调研主要玩家与竞争格局（Researcher）
- 调研用户痛点与需求趋势（Researcher）
- 基于调研结果撰写市场概述章节（Writer，依赖任务 2、3、4）
- 撰写竞争分析章节（Writer，依赖任务 3）
- 全文整合与一致性校验（Writer，依赖任务 5、6）
这 7 个子任务的依赖关系本质上是一个有向无环图，叫 DAG。我为什么说本质上？因为我实现时没有真的引入图数据库或者专门的 DAG 库，而是用一个简单的依赖计数表。
每个任务有两个关键字段：dependencies（它依赖哪些任务的 ID）和 dependents（哪些任务依赖它的完成）。调度器每次循环都扫描所有 pending 状态的任务，如果某个任务的 dependencies 全部处于 completed 状态，就把它送入就绪队列，交给对应的 Agent 执行。
代码片段（简化）： def get_ready_tasks(tasks): ready = [] for task in tasks: if task.status == 'pending': deps = task.dependencies if all(tasks[dep].status == 'completed' for dep in deps): ready.append(task) return ready当 Researcher 完成了任务 2 的调查，依赖任务 2 的 Writer 任务 5 就会被自动激活。如果任务 3 还没完成，任务 5 就只能继续等。这个机制保证了系统永远不会在材料不齐的情况下开始撰写，从源头规避了"编造数据"的温床。
4.2 路由失败的兜底策略
任务调度不可能永远一帆风顺，Agent 终究不是人，它们偶尔会给出无法解析的输出。我在项目里给每个 Agent 的响应做了一个"协议校验层"，检查它返回的内容是否符合约定的 JSON 结构。如果连续 3 次校验失败，就把这个任务标记为 failed，并触发一个兜底路由路径。
兜底路径是我踩了不少坑之后摸索出来的方案，核心原则是：不让失败的 Agent 无限重试，而是让它的上游重新派发任务。
比如 Writer 连续 3 次产出的报告都不符合交付物定义段的要求，Planner 不会把任务原样丢给 Writer 重做，而是先判断问题根源：是 Researcher 提供的资料包太混乱？是 Writer 的系统提示词描述不清楚？还是任务本身的交付物定义段写得有歧义？Planner 会把任务拆成"重新整理资料包"和"修正系统提示词"两个子任务，分别发给对应的目标 Agent。
4.3 模型输出接力的陷阱
任务调度中还有一个隐蔽的坑：Agent 之间传递输出时，源 Agent 的思考痕迹和目标 Agent 的正式输出混在一起。
这主要还是因为现在的模型在输出时，常常会把推理过程和分析内容放在正式结论前面。如果我直接把源 Agent 的整个响应文本传给下游 Agent，下游 Agent 会误把源 Agent 的"内心 OS"当成事实依据，从而做出错误决策。
我处理这个问题的办法很野蛮：在传输层做一次输出清洗。每个 Agent 的响应在写入共享消息队列前，只保留我定义在交付物模板里的正式内容字段，其余推理痕迹全部剥掉。下游 Agent 永远只能看到干净的交付物，不会看到源 Agent 的推理草稿。
这也被我在系统设计文档里称为"输出合同机制"——每个 Agent 都遵循"输出即合同"的原则，所有不该外传的信息全部留在自己的私有输出空间里，只有合同规定的字段才能进入协作通道。
5. 踩过的坑与完整排查链路
5.1 坑一：Agent "套娃"导致的上下文污染
第一次完整跑通这套系统后，我兴奋了不到半天，就发现一个可怕的规律：前几个任务输出质量还行，到第 10 个任务之后，Agent 的产出就开始变得啰嗦、跑题，甚至开始引用根本不存在的资料。
我当时的直觉反应是"模型上下文被打满了"。但打开系统日志一看，困惑了——每个 Agent 在调度器那里的上下文都只是干净的任务消息，并没有累积历史。
真正的问题出在任务消息本身的内容上。我对比了第 2 个任务和第 9 个任务的原始输入，发现第 9 个任务里，Planner 给 Researcher 的 instruction 里包含了前 8 个任务的全部摘要信息，因为我在设计 prompt 时让 Planner 把"项目全局信息"写进了每条派单消息。于是每个新任务实际上都背着整个项目的历史包袱，Agent 面对一个越来越长的 prompt，自然被历史信息干扰。
排查过程可以总结成三个步骤：
- 日志检查：先看消息队列里每个任务 payload 的实际大小，发现长度异常膨胀。
- 字段比对：将 instruction 字段和标准模板对比，发现多了"项目历史摘要"。
- 根因定位：检查 Planner 的系统提示词，发现里面写死了"每次派单时必须附带项目全量背景资料"，这是一个错误的设计。
修复方案是：把"项目历史摘要"从 Planner 的 instruction 字段里移除，改为通过 context_refs 引用共享白板文件。下游 Agent 不再被塞入与当前任务无关的历史信息，而是按需读取背景资料。
5.2 坑二：上游输出幻觉成了下游的"事实"
第一个坑修完之后，系统跑起来顺畅了一段时间，但很快我发现了一个更隐蔽的问题：Researcher Agent 在整理资料包时，偶尔会生成一些看起来有模有样、实际上完全不存在的调研数据。Writer 拿到这份资料包后如获至宝，直接引用，Reviewer 检查时又因为不知道这些数据是假的，检查不出来，于是假数据在系统里畅通无阻。
这个问题的根源不在单个 Agent 的幻觉概率，而在协作系统的信息验证机制缺失。Reviewer 的审查清单里本来有"数据是否和资料包一致"这一条，但它默认资料包是可信的，所以只会检查 Writer 有没有忠于资料包，而不会检查资料包本身的事实准确性。
排查链路：
- 随机抽查系统产出的 10 份报告，标注所有可疑数据。
- 对每条可疑数据回溯其来源消息，发现全部来自 Researcher 的交付资料包。
- 检查 Reviewer 的审查逻辑，发现它只看"Writer 是否忠于资料包"，不验证资料包本身。
- 在 Reviewer 的审查模板中添加"数据完整性校验"步骤：要求 Reviewer 对每条关键数据独立查找可验证来源。如果查不到来源，直接标记为"待核实"。
这一步修正之后，系统产出的事实错误率下降了很多。但代价也很明显，Reviewer 的 API 调用次数增加了，整体成本上升。后来我用了一个折中办法：Reviewer 只对"高风险数据字段"做来源校验，低风险描述性内容不做二次验证。数据风险等级由 Planner 在生成任务清单时标注。
5.3 坑三：并发写同一份共享文件导致状态错乱
我的系统支持并行执行多个独立子任务，比如 Researcher 同时调研市场规模和竞争格局时，两个并发 Agent 都会往项目的 context 目录里写入调研结果文件。结果发现，有时一个 Agent 写文件时把另一个 Agent 刚刚写入的内容覆盖了，导致任务 B 的文件丢失或混入任务 A 的数据。
最初我以为是文件读写代码写错了，后来排查发现是文件锁机制的缺失。
排查链路：
- 观察现象：偶尔出现"任务 B 的交付物里混入了任务 A 的内容"。
- 翻看调度日志：确认两个任务确实在同一时间窗口内执行。
- 检查共享白板写入逻辑：发现代码只用了简单的 open('file', 'w')，没有对同一文件的并发写做互斥保护。
- 根因结论：两个并发 Agent 同时写同一路径，后写者的内容直接覆盖先写者的内容。
修复方案是给每个任务的输出文件加上互斥锁，并用带任务 ID 的独立文件名隔离不同任务的输出。只在所有任务完成后的"整合阶段"，才由专职 Agent 合并所有文件。从那以后，状态错乱问题再也没出现过。
提示：多 Agent 系统的调试难度是传统单体系统的几倍，因为问题不总是发生在出问题的那个 Agent 上，而可能出在某个 Agent 提供的数据或上下文里。排查时务必先看消息内容，再看代码，最后才怀疑模型。
5.4 坑四：Reviewer 一次次把同一个缺陷打回，系统陷入无限循环
有一次系统进入了死循环：Planner 让 Writer 写一篇产品介绍，Writer 写完，Reviewer 打回，说"缺乏用户角度内容"，Writer 修改后，Reviewer 又打回，说"用户角度内容过于主观"，如此循环了几十轮，token 哗啦啦地流出去，产出的却是一份被改得面目全非的文档。
这次我没有先改代码，而是先从系统设计的层面反思。Reviewer 的审查标准在我这个系统里是硬编码的吗？不是，审查标准其实也是模型给出的自由文本。两个 Agent 一个是生成方、一个是审查方，如果审查标准本身模糊，双方就是鸡同鸭讲，永远不可能达成一致。
解决方案是在 Planner 派单时增加"验收标准明确化"环节。Planner 在派写作任务前，自己先把"验收标准"细化成可检查的规则列表。Reviewer 只按明确定义的规则逐条检查，不再自由发挥。如果 Reviewer 认为有一条规则写得不清楚，它只能把"标准不明"标记为缺陷，交给 Planner 去细化规则，而不能直接打回让 Writer 猜测。
这个改动让系统的返工率从 40% 左右降到了 15% 左右，效果非常显著。
6. 实测效果与调优记录
6.1 单 Agent vs 多 Agent 的对比实验
我把自己这套系统和一个"把所有任务交给单个 Agent 完成"的对照组做了对比实验，一共 20 个不同类型的任务，包括长文写作、数据分析、方案策划、代码重构。
对比维度和结果如下：
| 对比维度 | 单 Agent 方案 | agency-agents 方案 |
|---|---|---|
| 任务完成率 | 65% | 92% |
| 事实性错误率 | 22% | 7% |
| 平均字数控制偏差 | ±18% | ±5% |
| 任务平均耗时（分钟） | 3.2 | 6.8 |
| 平均 token 消耗 | 1x | 1.8x |
| 可调试性 | 差，出错难定位 | 好，能精确定位到角色和环节 |
从纯效率指标看，单 Agent 更快，token 更省，但完成率和质量明显落后。更关键的是可调试性：单 Agent 出错，你只能靠猜；多 Agent 出错，你可以直接定位到是 Researcher 数据不准，还是 Reviewer 标准模糊，还是 Writer 执行有偏差，排查效率高了一个量级。
对于我这种需要长期维护、不断完善的人来说，多 Agent 系统带来的可维护性优势远比那点速度和 token 成本重要。
6.2 调参经验：温度、token 上限、重试机制
系统跑稳之后，我开始对各个 Agent 做参数细调。这个环节很看经验，我分享一下我的参数思路，仅供参考。
- Planner（规划 Agent）：temperature 设为 0.2。它需要稳定、可靠地拆解任务，不需要天马行空的创意。temperature 高了会导致拆分计划不稳定，子任务一次一个样。
- Researcher（调研 Agent）：temperature 设为 0.3。它需要基于事实归纳，不需要编造，但对来源策略可以有一点自主性。
- Writer（写作 Agent）：temperature 设为 0.7。这是唯一一个需要一定创造力的角色，温度太低写出来的东西干巴巴。但也不能高于 0.8，否则会出现华丽但失控的表达。
- Reviewer（审查 Agent）：temperature 设为 0。它只做规则判断，完全不需要随机性。我把它的重试次数设为最大，因为审查稳定性是质量底线。
- Reviser（返工 Agent）：temperature 设为 0.4。它在修改时要保持原文风格，不能把整篇都推翻，需要平衡忠实与改进。
token 上限方面，我按任务长度动态设置，但核心原则是：执行型 Agent 的 max_tokens 设置得比输出模板最大长度略大一点，够用就好。审查型 Agent 的 max_tokens 反而要放宽，因为它的输出虽然短，但在内部推理阶段可能消耗较多 token 来逐条核对规则。
6.3 成本优化：有没有必要让每个 Agent 都调用一次 API
刚开始 5 个 Agent 全流程跑，一个中等报告大概要消耗 6-8 万 token，成本确实让人肉疼。后来我做了三件降本的事。
第一，Router 规则直接跳过不必要的环节。简单改写任务不吃 Researcher 和 Reviewer，直接 Writer 完成，成本变成原来的 20%。
第二，给 Reader 和 Reviewer 增加"批量处理"模式。如果有多个同类任务，以一个更大的 batch 形式让 Agent 一次处理多个子任务，减少模型调用次数。这个模式要求先做一次任务聚类，聚类的依据是任务类型和交付物模板是否相同。
第三，引入了"缓存命中"策略。Researcher 在开始新任务前，先检索共享事实清单，如果清单里已经有足够用的数据，就直接引用，不再额外调用模型查资料。
我做了一个简单的成本统计，优化后的全流程成本降到最初的 55%，但质量几乎没有下降。
7. 这套架构能做什么、不能做什么
写到这里，我希望你能对 agency-agents 这类系统有比较清醒的认知。它确实强大，但不是银弹。
它擅长的场景：
- 长文、长报告的自动化生产，需要多章节、多角度、多层次加工
- 需要引用事实和数据支撑的任务，通过 Researcher 和 Reviewer 的双重把关降低幻觉
- 流程性强、有明确交付物规范的任务，比如周报生成、竞品分析、方案初稿
它不擅长的场景：
- 极短、极简单的任务，走多 Agent 流程完全是杀鸡用牛刀
- 需要连续实时交互的对话系统，用户问一句，Agent 回一句，不应该组织 5 个角色轮番上阵
- 创造性极高但没有明确规范的任务，多 Agent 的严格交付物定义反而会限制发挥空间
我在项目文档里反复强调的一句话是：多 Agent 系统的价值不在于"数量多"，而在于"分工明确"和"流程可回溯"。如果你用 5 个 Agent 只是为了做 1 个 Agent 能做的事，那你只会得到 5 倍的延迟、5 倍的成本、5 倍的故障率。
我在另一个场景中尝试过把这套架构改造成一个代码审查系统，只是把 Writer 换成写代码的 Agent，Reviewer 换成专抓 bug 的 Agent。效果同样不错，主要原因是分工逻辑是一脉相承的——一个人不可能既是高效的写码者、又是冷眼的审查者，模型也一样。
8. 最后的建议：如果你想从零开始，先做减法
如果你看完文章有点心动，想自己搭一套类似的系统，我的建议是从最小闭环开始，不要一上来就追求全角色矩阵。
第一步，只做两个 Agent：执行者和审查者。任意一个任务，执行者先干，审查者挑错，发现缺陷就返工。这一步能让你快速感受到多 Agent 系统和单 Agent 的核心差异在哪。
第二步，加一个 Planner。让规划 Agent 负责拆解任务和定验收标准，你就开始体会到"任务可以被追踪，错误可以被归因"的好处了。
第三步，需要事实类任务时再加 Researcher。在这之前不要加，否则你只是多了个花 token 的角色。
我在自己的项目里就是在第一步和第二步之间反复横跳了很久，最终才确定 5 个角色的方案。一开始想塞 8 个角色，砍掉 3 个之后系统反而更稳了。做减法这件事，在人工智能系统的设计里，往往比做加法更考验功力。
