多智能体编排：监督者、黑板、投票、辩论、流水线和蜂群协作
摘要
本文把多智能体编排视为任务分工、状态传递、证据合并和冲突处理的工程问题，而不是角色扮演。监督者、黑板、投票、辩论、流水线和蜂群协作分别适合不同任务结构：有的强调协调，有的强调共享工件，有的强调候选比较，有的强调批判性审查，有的强调稳定工序，有的强调大规模探索。文章的核心观点是，多智能体只有在责任边界、工具权限、中间工件和停止条件清楚时才可能提高质量；否则它只会增加成本、延迟和错误传播路径。
关键词
多智能体；监督者模式；黑板模式；投票；辩论；流水线；蜂群协作；Agent 编排
研究问题与方法
本文研究的问题是：何时需要多个智能体，以及怎样选择编排模式。方法上，文章先定义多智能体共同底座，包括状态、工具治理、消息协议、评测和预算，再分别分析六种模式的适用条件、收益来源和失败模式。比较标准不是角色名称是否丰富，而是任务完成率是否提升、风险是否下降、中间产物是否更可验收。
下面的图给出模式选择的决策路径。它强调先判断任务结构，再选择协作形态，而不是从“想用多智能体”倒推需求。
多智能体收益可以用一个简单的不等式约束：
只有质量提升和风险下降超过协调成本，多智能体才有工程意义。否则，单智能体加工具和评测通常更稳。
多智能体编排不是给几个大模型分配漂亮头衔，也不是让一组角色在聊天室里轮流发言。它讨论的是一个更具体的问题：当一个任务需要多个具备推理、工具、记忆、权限和判断能力的工作单元协作时，系统应该怎样分配责任、传递状态、合并证据、处理冲突、控制成本，并判断什么时候可以停止。监督者、黑板、投票、辩论、流水线和蜂群协作，是六类最常见也最容易被误用的编排模式。
理解这些模式，有两个前提。第一，多智能体不等于更聪明。多个模型重复阅读同一段上下文、反复生成相似意见，只会增加延迟、成本和错误表面积。第二，编排不等于把控制权全部交给模型。生产级系统应该把可确定的流程交给代码、状态机和权限系统，把非确定的理解、判断、生成、取舍交给模型。真正可用的多智能体系统，通常是确定性控制和模型推理的组合。
这篇教程按工程视角拆解六种编排方式。每种模式都会讲适用场景、系统结构、优点、风险和落地方法。读完之后，你应该能够回答三个问题：一个任务是否真的需要多智能体；应该选择监督者、黑板、投票、辩论、流水线还是蜂群；怎样让协作结果可验证、可追踪、可交付。
引言：先把“多智能体”从角色扮演里拿出来
多智能体系统的基本单位不是“人设”，而是“带责任边界的执行单元”。一个合格的智能体至少应该具备五类信息：目标、输入、可用工具、输出契约和停止条件。目标说明它为什么存在；输入说明它能看见什么；工具说明它能做什么；输出契约说明它必须交付什么结构；停止条件说明它何时结束工作。
如果一个所谓的智能体只有一句系统提示，例如“你是资深架构师，请给出建议”，但没有工具、没有状态、没有输出契约、没有验收标准，它更接近一个提示词角色，不是工程意义上的智能体。多智能体编排也不是把这种角色复制三份。真正的编排要解决的是工作流问题：谁先做，谁后做，谁能并行，谁能否决，谁能改文件，谁只能读资料，谁负责最终汇总。
OpenAI Agents SDK、Google Agent Development Kit、Microsoft AutoGen、LangGraph、CrewAI 等框架在具体接口上不同，但它们都在围绕相似问题提供构件：智能体定义、工具调用、任务交接、状态管理、追踪、评测、人类确认和多智能体关系。框架名称会变化，底层问题不会变。只要系统里存在多个会使用模型和工具的工作单元，就必须面对编排。
一个最小多智能体任务可以这样描述：
用户目标：写一份可发布的技术选型报告。
研究智能体：检索官方文档、论文、项目资料，输出来源卡片。
分析智能体：比较方案，输出优劣和适用边界。
写作智能体：根据来源和分析生成正文。
评审智能体：检查事实、结构、重复和遗漏。
协调器：决定每一步是否通过、返工或交付。
这个例子里，关键不是有四个名字，而是每个工作单元的责任不同、输入不同、输出不同、权限不同。研究智能体不直接写最终稿，写作智能体不能虚构资料，评审智能体不能只说“看起来不错”，协调器不能无限让大家继续优化。边界清楚，多智能体才可能提高质量；边界模糊，多智能体会把错误扩散到更多回合。
什么时候不该用多智能体
学习多智能体之前，要先学会不用。很多任务用单智能体加工具就足够，比如查询数据库、总结一份短文档、根据固定模板生成邮件、把一个 JSON 转成表格、解释一段代码。此时拆成多个智能体，只会增加上下文同步和结果合并的负担。
不该用多智能体的第一种情况，是任务目标单一且验收明确。比如“把这段英文翻译成中文”“把这份会议记录整理成十条待办”“检查 Markdown 链接是否可达”。这些任务的难点不在多视角思考，而在稳定执行。单智能体外加程序校验更高效。
第二种情况，是没有清晰中间工件。多智能体协作必须围绕工件，而不是围绕闲聊。研究卡片、测试报告、候选答案、风险清单、代码补丁、事实核查表，都属于工件。如果系统只能保存长对话，不能保存结构化中间成果，后续智能体看到的就是噪声。
第三种情况，是成本和延迟不允许。一个监督者调用三个专家，再调用一个评审，再返工一次，很容易把一次请求变成十几次模型调用。对于用户期望秒级响应的场景，除非任务价值足够高，否则多智能体会破坏体验。
第四种情况，是权限边界还没设计好。让多个智能体共享同一组高危工具，比让一个智能体犯错更危险。一个研究智能体误判资料，可能只是生成错误结论；一个执行智能体误调用删除接口，可能直接造成数据损失。没有权限分层，不要急着扩展智能体数量。
判断是否需要多智能体，可以用四个问题：
任务是否需要明显不同的专业视角。
任务是否需要生成者和检查者分离。
任务是否能拆出可独立验收的中间工件。
多智能体增加的成本是否能换来更高完成率或更低风险。
四个问题中至少满足两个，再考虑编排模式。否则优先优化单智能体的工具、上下文和评测。
多智能体编排的共同底座
不管选择哪种模式，生产级多智能体系统都需要几个共同底座。
第一是任务状态。状态不等于聊天历史。状态应该包含目标、约束、已完成步骤、未解决问题、工具结果、工件地址、风险标记、预算消耗和当前决策。LangGraph 强调用状态图和持久化检查点管理多步骤执行，Google ADK 也把会话、记忆、工件和事件视为智能体运行的重要组成部分。原因很简单：没有状态，就无法恢复、追踪和评测。
第二是工具治理。工具要有名称、参数模式、返回结构、错误类型、权限范围和审计记录。工具描述应该面向模型理解，但不能泄露内部实现细节。高风险工具要有人类确认或策略控制。只读工具、写入工具、发布工具、支付工具、删除工具不能混在一个无差别列表里。
第三是消息协议。智能体之间不能只传自然语言感想。每次交接至少应该说明：输入是什么，结论是什么，证据是什么，置信度如何，哪些问题未解决，下一方应该做什么。OpenAI Agents SDK 中的 handoff、AutoGen 的多智能体会话、A2A 协议对任务和消息的抽象，都体现了同一个方向：让智能体之间的交互可以被系统理解，而不是只有人类勉强读懂。
第四是评测和追踪。多智能体系统的失败常发生在中间过程：研究阶段用了过时来源，分析阶段忽略约束，合并阶段丢失少数意见，评审阶段没有真正检查。只看最终答案，很难知道哪里坏了。生产系统需要记录每个智能体的输入、输出、工具调用、耗时、失败、返工和最终影响。
第五是预算。预算包括 token、时间、工具调用次数、并发数量、人工确认次数和风险额度。多智能体编排没有预算，就会自然膨胀。每个模式都应该写明最大轮数、最大候选数、最大重试次数和降级策略。
可以把这些底座想成一个通用运行框架：
任务入口
-> 建立任务状态和预算
-> 选择编排模式
-> 分配智能体和工具权限
-> 执行、交接、合并、校验
-> 写入轨迹和工件
-> 按验收标准交付或返工
如果底座缺失，六种编排模式都会退化成“多轮提示词聊天”。
监督者模式：一个协调者管理多个专家
监督者模式是最直观的多智能体编排。系统中有一个监督者智能体或确定性协调器，负责理解任务、选择下一位工作者、传递必要上下文、检查结果、决定是否继续。工作者智能体负责特定职责，例如检索、写作、编码、测试、安全审查、数据分析。
监督者模式适合任务目标较清楚，但路径需要动态选择的场景。比如用户说“帮我调研并写一份本地大模型部署方案”，监督者可以先派研究者检索资料，再派工程分析者比较 Ollama、vLLM、llama.cpp，再派写作者生成正文，再派评审者检查引用和逻辑。如果研究阶段发现用户硬件限制很强，监督者可以改变路线，把重点从高吞吐服务转向桌面级部署。
这种模式的核心价值，是把全局控制和局部执行分开。监督者看目标和状态，工作者看局部任务和工具。LangChain 的多智能体文档把“工具调用式”架构描述为一个中心化智能体把子智能体当工具调用，适合集中路由和流程控制；OpenAI Agents SDK 的 handoff 则支持把控制权从一个智能体转移给另一个更合适的智能体。这两种实现细节不同，但都围绕一个问题：谁决定下一步由谁做。
监督者模式有三个常见结构。
第一种是确定性监督者。协调逻辑由代码或图工作流控制，模型只在节点里做语义判断。比如固定流程为“研究、提纲、正文、审核、发布”，每一步是否通过由结构化评分决定。这种方式稳定，适合业务流程明确的场景。
第二种是模型监督者。监督者本身是一个大模型智能体，根据任务状态选择下一个智能体。这种方式灵活，适合开放任务。风险是监督者可能反复路由、遗漏关键步骤或被局部输出带偏。
第三种是混合监督者。流程骨架由代码控制，分支选择由模型辅助。例如系统规定必须经过事实核查和最终验收，但允许模型决定是否需要额外检索、是否需要安全评审、是否需要用户确认。这通常是生产系统更实用的选择。
设计监督者时，最重要的是输出契约。监督者每次决策不应该只输出“让研究员继续”，而应该输出结构化内容：
下一角色：researcher
任务输入：需要补充哪些资料
可用工具：web_search, docs_reader
预期输出：来源卡片，包含标题、链接、日期、关键结论
停止条件：至少八个高可信来源，覆盖官方文档、论文和项目文档
预算：最多两轮检索
这样工作者知道要交付什么，系统也能检查是否合格。
监督者模式的主要风险是单点瓶颈。监督者如果判断错误，整个团队会朝错误方向前进。监督者如果上下文过长，会逐渐丢失重要约束。监督者如果过度谨慎，会让任务不断返工。缓解方法包括：把用户硬约束固定在任务状态里；让监督者只读取摘要和关键工件，不读取所有长文本；为返工设置上限；让最终评审独立检查监督者是否遗漏目标。
另一个风险是专家智能体变成摆设。很多系统里，所谓研究者、写作者、评审者看到的是同一份上下文、使用同一个模型、执行同一种提示，只是名字不同。这样的分工没有意义。有效分工应该至少在工具、视角、输入或验收标准上有所不同。
黑板模式：共享工作区驱动协作
黑板模式来自早期人工智能系统和分布式问题求解研究。它的基本思想是：多个知识源或工作单元不直接互相指挥，而是围绕一个共享黑板读写中间状态。黑板上保存问题、部分解、证据、假设、冲突、优先级和完成状态。控制器观察黑板变化，决定下一步激活哪个知识源。
在大模型应用里，黑板可以是数据库、任务对象、文档目录、向量库、事件流、工件仓库或状态图。智能体不是在一个群聊里说话，而是向黑板提交结构化工件。例如，研究智能体写入来源卡片，分析智能体读取来源卡片并写入对比矩阵，风险智能体读取对比矩阵并写入风险清单，写作智能体读取所有已批准工件生成正文。
黑板模式特别适合信息逐步积累、问题结构复杂、多个角色可以异步工作的任务。比如做代码迁移时，扫描智能体发现依赖，测试智能体发现失败用例，修复智能体提交补丁，文档智能体更新说明，协调器根据黑板上的失败状态决定下一步。再比如做长文研究时，资料、反例、术语定义、案例和参考链接可以持续沉淀在黑板中，不需要每个智能体重新检索。
黑板模式的优势在于可追踪和可恢复。每个工件都有作者、时间、来源和状态；任务中断后可以从黑板继续；评审者能看到某个结论来自哪些证据。相比共享聊天记录，黑板更适合作为生产系统的协作记忆。
设计黑板时，不要把它做成一个巨大的自由文本字段。推荐把黑板拆成几类对象：
任务目标：用户需求、硬约束、验收标准。
证据卡片：来源、链接、日期、摘要、适用范围、可信度。
假设列表：尚未验证但影响决策的前提。
工件列表：提纲、代码补丁、报告、截图、测试结果。
问题队列：待解决问题、负责人、优先级、截止条件。
冲突记录：互相矛盾的结论和裁决结果。
预算状态：剩余轮数、剩余 token、剩余工具调用次数。
黑板模式的关键是写入规则。每个智能体写入黑板时，必须说明对象类型、来源、状态和可用性。比如“已验证来源”“待核查说法”“失败测试”“候选方案”“最终采用方案”应该是不同状态。没有状态标记，后续智能体会把草稿当事实，把假设当结论。
黑板模式也要控制并发。多个智能体同时写入可能产生冲突，例如两个修复智能体修改同一文件，两个研究智能体给出相反结论。解决方式可以是乐观锁、版本号、工件审批、冲突队列或监督者裁决。黑板不是无序留言板，而是带规则的协作工作区。
黑板模式的最大风险是信息污染。黑板越大，噪声越多；旧结论如果没有过期机制，会影响新任务；低可信来源如果和高可信来源混在一起，会误导写作和决策。因此需要定期压缩、归档、去重和标注可信度。长期知识可以进入记忆库，当前任务黑板应该保持聚焦。
投票模式：用多候选降低单次偶然性
投票模式的基本做法，是让多个智能体或同一模型的多次采样独立生成候选答案，再通过投票、评分、聚合或仲裁选择结果。它常用于推理题、分类判断、代码生成、事实核查、方案比较和安全审查。
投票背后的直觉是：单次模型输出具有随机性和路径依赖，多次独立尝试可能覆盖不同思路。Self-Consistency 论文证明，在链式思维推理中，采样多条推理路径并选择最一致答案，可以显著提升多类推理任务表现。Tree of Thoughts 进一步把思考过程组织成可搜索的树，允许模型生成、评估和选择中间想法，而不是一次性走到底。Mixture-of-Agents 则展示了多个大模型输出经分层聚合后可能提升生成质量。
工程上，投票模式有几种实现。
第一种是答案多数投票。多个候选直接给出答案，系统选择出现最多的结果。它适合选择题、分类、简单判断。缺点是多数不等于正确，尤其当所有候选共享同一偏见时。
第二种是理由加答案投票。候选不仅给答案，还给证据或推理摘要。仲裁者读取理由后选择。它适合复杂判断，但要防止仲裁者被看似流畅的错误理由说服。
第三种是评分投票。每个候选按准确性、完整性、风险、成本、可执行性等维度评分，再按加权结果选择。它适合方案比较和生成任务。
第四种是独立评审投票。多个评审智能体检查同一个输出，每个评审只看特定维度，例如事实、格式、安全、用户体验。最终由监督者合并问题清单。这比让多个评审泛泛评价更有效。
投票模式最重要的原则是独立性。如果所有候选共享同一上下文污染、同一错误资料、同一提示诱导，投票只会放大错误。为了提高独立性，可以使用不同模型、不同提示角度、不同检索结果、不同工具路径或不同随机种子。对于事实性任务，还可以让候选先独立列来源，再由仲裁者只依据可验证证据判断。
投票模式还需要定义合并方式。不是所有问题都适合简单多数。比如三个候选里，两个给出模糊答案，一个给出有来源的反例，此时少数意见可能更重要。安全审查更不能多数通过就放行，只要任何一个高可信评审发现严重风险，就应该进入人工确认或返工。
一个实用投票流程如下：
生成阶段：三个候选独立完成任务，不互相可见。
标准化阶段：每个候选输出答案、证据、假设、风险。
评分阶段：评审器按同一 rubric 打分。
仲裁阶段：选择最高分、合并优势、保留异议。
验证阶段：对最终答案做事实或测试校验。
投票模式的主要成本是调用次数。不要为了每个小任务都启用三路投票。更合理的策略是按风险触发：高价值决策、不可逆操作、长文事实、复杂推理、法律财务医疗等高风险内容才启用投票；普通低风险任务使用单智能体加校验。
辩论模式：让反方主动寻找盲点
辩论模式让多个智能体围绕同一问题提出观点、质疑对方、修正结论，最后由裁判或用户选择结果。和投票相比，辩论强调交互式对抗；和普通讨论相比，辩论必须有证据、规则和裁决标准。
多智能体辩论相关研究显示，多个语言模型通过交换论点和批评，有机会改善推理和事实性表现。辩论的价值不在于让模型模拟人类争吵，而在于主动暴露盲点。一个模型生成方案时，往往会自然维护自己的思路；另一个被指定为反方的智能体，会更积极地寻找条件缺失、证据不足、边界不清和风险未覆盖。
辩论模式适合开放决策和高风险方案，例如是否采用某个架构、是否把数据交给云 API、是否上线某个自动化能力、某份分析报告是否过度乐观。它不适合简单事实查询。让两个智能体辩论“vLLM 是否支持 OpenAI 兼容接口”，不如直接查官方文档。
一个好的辩论流程通常包含四步：
立论：正方给出方案、理由和证据。
反驳：反方指出假设、风险、缺口和反例。
修正：正方基于反驳更新方案或承认限制。
裁决：裁判按标准选择结论、保留风险、给出下一步。
辩论要避免三个问题。
第一个问题是无限回合。模型很容易为了继续而继续，把同一观点换词重复。辩论必须设置回合数，常见是两轮立论加一轮裁决。超过回合数仍有重大分歧，就应该转为检索证据或人工决策。
第二个问题是没有证据。辩论不是观点游戏。每个关键主张应该引用来源、测试结果或明确假设。不能验证的主张要标记为判断，而不是伪装成事实。
第三个问题是裁判偏见。裁判如果看到过多修辞，可能选择表达更强势的一方。缓解方法是让裁判按 rubric 评分，例如“事实支持、约束覆盖、风险处理、可执行性、成本、用户价值”，而不是按整体印象判断。
辩论模式在工程系统里常常和监督者模式结合。监督者提出任务，正方和反方分别处理，裁判生成决策。也可以和黑板模式结合，把每轮论点写入黑板，避免结论丢失。对于高风险任务，还可以要求反方只输出“不可接受风险”，不参与方案优化，以免角色混淆。
辩论的产出不应该是长篇聊天记录，而应该是决策摘要：
推荐方案：采用混合架构。
支持理由：隐私数据留本地，复杂推理交给云端高能力模型。
主要反对意见：本地模型运维成本、云端合规边界、路由复杂度。
已处理风险：增加数据分级、脱敏、审计和降级策略。
未解决问题：具体云供应商数据政策需要按合同确认。
下一步：用三类真实任务做 PoC 评测。
这样用户得到的是可执行决策，而不是模型吵架现场。
流水线模式：把复杂任务拆成稳定工序
流水线模式把任务拆成一系列有序步骤，每个步骤由专门智能体或工具完成，输出成为下一步输入。它和监督者模式的区别在于，流水线流程更固定，动态路由更少。它适合结构稳定、可重复执行、每一步有明确验收的任务。
典型例子是内容生产流水线：选题、资料检索、提纲、正文、事实核查、编辑、排版、发布检查。也可以是代码修改流水线：需求解析、代码检索、变更计划、补丁、测试、代码审查、说明。还可以是数据分析流水线：数据读取、清洗、探索、建模、可视化、解释、报告。
流水线的价值是降低复杂度。每个智能体只处理一个阶段，不需要理解全部问题。系统可以在阶段边界做校验和缓存。某一步失败时，可以只返工该步骤，而不是让整个任务重来。CrewAI 的 sequential process、Google ADK 的工作流智能体、LangGraph 的图式执行都可以支持这种模式。
设计流水线时，要先定义每一步的输入输出，而不是先写提示词。例如写长文流水线可以这样设计：
资料检索输入：标题、读者、来源要求。
资料检索输出：来源卡片列表。
提纲输入：标题、读者、来源卡片。
提纲输出：章节列表、每章问题、关键来源映射。
正文输入：提纲、来源卡片、字数要求。
正文输出：完整 Markdown 草稿。
事实核查输入：草稿、来源卡片。
事实核查输出：问题清单、缺源句子、修改建议。
编辑输入：草稿、问题清单。
编辑输出：发布稿、参考资料、检查结果。
每一步都应该能单独测试。资料检索是否满足来源数量；提纲是否覆盖标题承诺；正文是否引用已有资料；事实核查是否能发现无来源断言；编辑是否去重并面向最终读者。流水线不是把长任务切碎，而是把每段工序变成可验收单元。
流水线模式最容易出现的问题是误差传递。早期步骤如果错了，后续步骤会在错误基础上继续加工。例如资料检索用了过时文档，正文写得再好也不可靠。因此关键阶段需要闸门。资料不足不能进入写作；测试失败不能进入发布；风险未处理不能进入自动执行。
另一个问题是过度僵化。固定流水线适合稳定任务，但开放任务可能需要回跳。例如写作阶段发现资料不够，就必须回到检索；测试阶段发现需求理解错了，就要回到计划；用户新增约束时，可能要重新评估整个流程。好的流水线应该允许有限回跳，而不是只能直线前进。
流水线模式和人类团队的工作方式接近，因此非常适合产品化。用户不需要看到内部每个模型的全部输出，但可以看到清晰进度：正在检索资料、正在生成提纲、正在核查事实、正在整理发布稿。这里的界面文案必须面向最终用户，不要暴露“节点 ID”“内部 prompt”“tool_call 参数”等实现细节。
蜂群协作：大量轻量个体的分布式探索
蜂群协作常被误解为“越多 agent 越强”。更准确地说，蜂群模式适合大量相对轻量、可并行、可局部失败的探索任务。每个智能体执行一个小任务，系统通过聚合、竞争、选择或环境反馈逐步逼近目标。
在软件工程中，蜂群可以用于并行查找 bug 原因、并行探索不同修复方案、并行生成测试用例、并行搜索资料、并行评估多个设计草案。在内容任务中，蜂群可以让多个研究单元分别覆盖论文、官方文档、项目文档、案例、反例，再汇总成知识图谱。在数据任务中，多个分析单元可以从不同特征、不同模型、不同异常路径探索数据。
OpenAI Swarm 曾以教育框架形式展示 routines 和 handoffs 的轻量多智能体思路，后来的 Agents SDK 提供了更正式的构件。这里的“swarm”并不意味着系统失去控制，而是强调多个工作单元可以快速产生候选，并通过交接或聚合形成结果。
蜂群模式的优势是覆盖面。一个智能体按一条思路搜索，容易错过其他方向；多个轻量智能体可以并行探索不同区域。它也适合不确定性高的问题，因为系统不需要提前知道哪条路径正确，可以用低成本探索换取更好的候选集。
蜂群模式必须有聚合器。没有聚合器，蜂群只是大量碎片输出。聚合器要负责去重、排序、验证、合并和裁决。例如十个研究智能体各自提交资料卡片，聚合器要删除重复来源，保留官方和高可信资料，标记冲突观点，形成最终来源包。十个修复智能体各自提出补丁，聚合器要运行测试、比较改动范围、选择最小可行方案。
蜂群模式还必须有资源限制。并行数量、每个个体的最大工具调用、总预算、失败阈值、候选保留数量都要明确。否则蜂群会迅速变成烧钱机器。对大多数产品来说，蜂群不应该作为默认响应路径，而应该用于高价值、高不确定、高并行收益的任务。
蜂群协作和投票的区别在于，投票通常让多个候选解决同一个问题，然后选答案；蜂群更强调探索空间划分，不同个体可能处理不同子区域。蜂群和黑板的关系也很紧密：蜂群个体可以把发现写入黑板，聚合器从黑板读取并整理。
一个实用蜂群流程如下：
任务分区：按来源类型、文件区域、方案方向或风险类别拆分。
并行探索：每个智能体只处理一个分区，输出结构化发现。
聚合去重：合并相同发现，删除低价值重复。
冲突验证：对矛盾结论启动额外检索、测试或评审。
候选选择：保留少量高质量方案进入下一阶段。
最终交付：由写作、执行或决策智能体生成统一结果。
蜂群模式的典型失败，是每个个体都输出“不错的建议”，但没人负责把建议变成结果。避免这种失败，要把聚合和交付设计成一等公民。
六种模式怎样选择
选择编排模式，可以从任务结构出发，而不是从框架功能出发。
如果任务需要动态分配给不同专家，选择监督者模式。比如“看一下这个项目为什么启动失败，并修好”。监督者可以根据错误决定是派依赖分析、配置检查、代码修复还是测试执行。
如果任务需要长期共享状态、异步积累证据、多人读写工件，选择黑板模式。比如“维护一个持续更新的竞品情报库”“跟踪一个大型迁移任务”“让多个智能体共同维护知识库”。
如果任务需要降低单次随机性，选择投票模式。比如“判断这段合同是否有风险”“在多个候选摘要里选最准确的一个”“让三种推理路径解同一道复杂题”。
如果任务需要主动发现盲点和反例，选择辩论模式。比如“是否应该把敏感数据交给云模型”“这个架构方案的最大风险是什么”“这份报告是否过度乐观”。
如果任务流程稳定且可阶段验收，选择流水线模式。比如“生产一篇长文”“完成一次代码变更”“生成一份数据分析报告”。
如果任务空间大、可以并行探索，选择蜂群模式。比如“从一个大型代码库里找潜在性能瓶颈”“并行收集某技术生态资料”“生成并筛选五十个测试用例”。
现实系统经常组合使用这些模式。一个长文写作系统可能用流水线作为主流程，用蜂群并行检索资料，用投票选择标题，用辩论检查争议结论，用黑板保存工件，用监督者控制返工。组合没有问题，但组合必须有主结构。没有主结构，系统会变成多个模式互相打架。
模式组合示例：写一份生产级技术白皮书
假设任务是写一份关于“企业如何落地本地模型和云模型混合架构”的技术白皮书。这个任务信息量大、来源要求高、需要方案判断，也需要最终可读文本。可以这样组合：
主流程：流水线。
资料阶段：蜂群按官方文档、论文、项目文档、云厂商政策、开源部署框架分区检索。
资料存储：黑板保存来源卡片、争议点、术语定义和案例。
方案阶段：监督者派架构智能体、成本智能体、安全智能体分别分析。
争议阶段：辩论“哪些数据可以上云，哪些必须留本地”。
标题和摘要阶段：投票生成多个候选并评分。
审核阶段：事实核查智能体和最终编辑智能体独立检查。
这个设计听起来复杂，但每个模式都有清楚位置。流水线提供主节奏，蜂群负责覆盖资料，黑板负责状态，监督者负责分配，辩论负责风险，投票负责候选选择。系统不是为了展示多智能体，而是为了满足白皮书的质量要求。
如果任务缩小为“写一篇一千字博客”，就不需要这么复杂。也许单智能体加一次事实核查就够了。多智能体设计要随任务价值和风险伸缩。
模式组合示例：代码修复和回归验证
再看一个工程任务：用户报告本地 Web 应用在 iPad 宽度下布局错乱，希望修复并验证。这个任务适合监督者加流水线。
监督者先读取需求，派侦察智能体检查相关页面、CSS 和组件。侦察智能体只读文件和截图，不改代码。然后监督者派执行智能体修改样式，执行智能体只能写指定文件。接着测试智能体运行构建、打开浏览器、在桌面和 iPad 视口截图验证。最后评审智能体检查是否引入重复信息、内部文案或元素重叠。
如果问题原因不明确，可以加入蜂群：两个侦察智能体分别从 CSS 断点和组件结构查找原因。若修复方案有争议，可以让一个智能体主张“局部样式修复”，另一个主张“组件布局重构”，再由裁判按改动范围、风险和验证结果选择。
这里的关键是权限。侦察者不能写文件，执行者不能发布，测试者不能修改业务逻辑，发布动作需要用户确认。多智能体带来的安全性，不是因为模型更谨慎，而是因为系统把权限拆开了。
消息和工件：不要让协作只剩聊天记录
多智能体系统最常见的工程失败，是把所有协作都塞进自然语言消息。自然语言适合表达复杂判断，但不适合作为唯一状态载体。系统需要结构化工件。
一个研究工件可以包含：
source_title
source_url
source_type
publish_or_update_date
claim
evidence_summary
confidence
limitations
used_by_sections
一个代码修改工件可以包含：
files_changed
intent
diff_summary
tests_run
test_result
known_risks
rollback_note
一个评审工件可以包含：
severity
location
problem
evidence
recommended_fix
blocking
这些字段不一定要暴露给最终用户，但必须存在于系统内部。最终用户看到的是清晰结果：参考资料、文件路径、测试结果、剩余风险。内部结构让系统可控，外部呈现要保持简洁。
工件还要有版本。写作草稿、评审问题、修订稿、发布稿不能混在一起。黑板或状态库应能回答：当前采用哪个版本，哪个版本被废弃，废弃原因是什么，最终结论引用了哪些来源。
记忆：多智能体共享什么，不共享什么
多智能体系统需要记忆，但共享记忆要谨慎。全部共享会导致污染，完全隔离会导致重复劳动。更合理的是分层。
任务内短期记忆应该共享，例如用户目标、硬约束、已完成步骤、关键工具结果、最终采用工件。这些信息决定当前任务能否完成。
角色私有工作记忆可以部分隔离。例如反方智能体可以保存自己的风险列表，避免过早被正方观点影响；多个投票候选在生成阶段不应互相可见，保证独立性。
长期项目记忆应该按相关性检索，而不是默认注入。比如某项目的编码规范、用户偏好、历史失败案例可以在代码任务中读取；但不相关项目的旧经验不应进入上下文。
共享记忆还要带来源和时间。没有时间戳的记忆很危险，尤其是模型版本、API 政策、价格、框架接口等会变化的信息。读取长期记忆时，系统应该标记“可能需要重新验证”的内容。对于当前事实，仍要优先查官方文档。
冲突处理：多智能体一定会意见不一致
多智能体系统不是为了消除冲突，而是为了让冲突可见、可裁决。冲突主要有四类。
第一是事实冲突。一个来源说某框架支持某功能，另一个来源没有提到或说不支持。处理方式是查官方文档、版本说明和实际运行，而不是让模型凭语气判断。
第二是目标冲突。一个智能体追求质量，另一个追求速度；一个追求安全，另一个追求便利。处理方式是回到用户目标和优先级。如果用户没有给优先级，系统要提出选择，而不是暗自决定。
第三是方案冲突。不同智能体提出不同实现路径。处理方式是按成本、风险、可验证性、可维护性和用户价值评分，并保留未采用方案的理由。
第四是权限冲突。某个智能体建议执行超出权限的动作。处理方式不是让它继续解释，而是触发确认、降级或停止。
冲突记录应写入黑板或任务状态。最终交付时，不需要展示所有争论细节，但应该说明关键取舍。例如“采用本地向量检索加云端推理，因为敏感原文不出本地，云端只接收脱敏摘要；未采用全云方案，原因是数据分级和合规要求不满足”。
评测：不要只评最终答案
多智能体评测要覆盖结果和过程。结果评测回答“最终交付物是否正确”，过程评测回答“系统是否以可接受方式得到它”。
结果指标包括任务完成率、事实准确性、引用质量、测试通过率、用户可用性、格式合规、是否满足硬约束。过程指标包括工具调用是否必要、权限是否越界、返工次数、冲突是否处理、预算是否超限、是否保留证据。
AgentBench、GAIA、τ-bench 等评测工作都强调真实任务、工具使用、多步交互和环境反馈的重要性。对于多智能体系统，还要额外评估协作质量：角色分工是否有效，中间工件是否可用，监督者是否正确路由，评审是否发现真实问题，聚合是否丢失关键少数意见。
一个实用评测集可以这样组织：
样例输入：用户任务和约束。
环境准备：文件、网页、数据库、工具状态。
预期工件：必须生成哪些中间结果。
禁止行为：不能改哪些文件，不能调用哪些工具。
通过条件：最终输出和过程轨迹必须满足什么。
评分规则：事实、完成度、风险、成本、体验。
评测时，不要让模型自评替代客观检查。字符数、链接数量、文件修改范围、测试退出码、截图尺寸、JSON schema 都应该用程序检查。模型评审适合语义质量、逻辑一致性和用户体验，但它也需要证据。
安全和权限：智能体越多，越要收紧边界
多智能体系统扩大了攻击面。一个智能体可能被外部网页提示注入影响，另一个智能体可能把恶意内容当成指令，第三个智能体可能拥有写入权限。OWASP LLM Top 10 把提示注入、敏感信息泄露、供应链、过度代理等列为重要风险。多智能体系统必须把这些风险当成架构问题，而不是上线后补丁。
基本原则是最小权限。研究智能体只需要读网页和写来源卡片，不需要删除文件。评审智能体只需要读工件和写问题清单，不需要调用发布接口。执行智能体可以改工作区，但不能绕过测试直接发布。发布智能体必须经过确认。
第二个原则是指令分层。来自用户、系统、工具返回、网页、文档、其他智能体的内容，可信度不同。网页里的“忽略之前指令”不应成为系统指令。工具返回的数据应该被当作数据，而不是自动当成命令。
第三个原则是敏感数据最小化。多智能体协作时，不要把全部用户数据广播给所有角色。研究者可能不需要看到客户身份，写作者可能不需要看到原始日志，云端模型可能只需要脱敏摘要。数据流向应该和角色责任匹配。
第四个原则是可审计。高风险工具调用要记录发起者、原因、参数、结果和审批状态。发生问题时，团队必须能还原是哪一步导致的，而不是只看到最终答案。
落地路径：从单智能体走向多智能体
建议按四个阶段落地，而不是一开始就做复杂平台。
第一阶段，做好单智能体闭环。让一个智能体能理解任务、调用工具、保存状态、输出可验证结果。没有单智能体质量，多智能体只会放大混乱。
第二阶段，加入独立评审。先把生成者和评审者分开。例如写作后由事实核查智能体检查，代码修改后由测试智能体验证。这个阶段通常投入不大，却能明显提高质量。
第三阶段，引入监督者或流水线。对于重复任务，用流水线固定工序；对于开放任务，用监督者动态分配。此时要建立工件和状态库，不要再依赖长聊天记录。
第四阶段，按需加入黑板、投票、辩论和蜂群。只有当任务确实需要共享工作区、多候选、对抗检查或并行探索时，再引入这些模式。每引入一种模式，都要增加相应评测，证明它带来收益。
落地过程中，最重要的不是框架迁移，而是接口契约。无论用哪个框架，都要写清楚智能体职责、工具权限、输入输出、预算、错误处理和验收标准。框架可以替换，契约应该稳定。
常见误区
误区一：智能体越多越好。实际情况是，智能体数量越多，协调成本越高。只有当分工减少混乱、提高覆盖、降低风险时，数量才有意义。
误区二：让所有智能体共享完整上下文。完整上下文会增加成本，也会破坏候选独立性。应该按角色提供最小必要信息。
误区三：把评审智能体写成礼貌评论员。评审必须有硬标准、问题等级和阻塞条件。只会说“整体不错”的评审没有价值。
误区四：用辩论替代检索。事实问题优先查资料、跑测试、看文档。辩论适合价值判断和风险暴露，不适合确认 API 是否存在。
误区五：把黑板做成长文本垃圾桶。黑板应该保存结构化工件和状态，不是无限追加聊天记录。
误区六：忽略最终交付。多智能体输出很多中间内容不等于完成任务。用户需要可用文件、可运行代码、可读报告、明确结论和剩余风险。
误区七：把框架能力当产品能力。支持 handoff、tool call、workflow 只是基础。真正决定产品质量的是任务设计、工具质量、权限治理、评测集和真实用户路径。
检查清单
设计多智能体编排前，可以用这份清单自查：
目标是否清楚：最终交付物和验收标准是否明确。
模式是否必要：为什么单智能体不够。
角色是否有差异：工具、输入、视角或权限是否不同。
工件是否结构化：中间结果能否被系统检查和复用。
状态是否可恢复：中断后能否从任务状态继续。
路由是否可解释：为什么派某个智能体执行下一步。
冲突是否可裁决：意见不一致时按什么标准处理。
预算是否有限制：最大轮数、最大并行、最大重试是否明确。
权限是否最小化：每个角色是否只拿必要工具。
评测是否覆盖过程：是否检查工具、轨迹、工件和最终结果。
用户输出是否干净：是否去掉内部字段、调试术语和实现细节。
这份清单比选择框架更重要。框架能帮你实现编排，但不能替你判断编排是否合理。
结语：先设计责任，再设计角色
多智能体编排的核心不是“我有几个 agent”，而是“这个任务需要哪些责任”。监督者负责路由和全局状态，黑板负责共享工件和证据，投票负责降低单次偶然性，辩论负责暴露盲点，流水线负责稳定工序，蜂群负责并行探索。六种模式没有绝对高低，只有适用边界。
生产级系统应该从任务完成标准出发。先定义最终交付，再定义中间工件；先定义权限和验收，再定义智能体名称；先证明多智能体提高质量，再把它放进默认流程。这样设计出来的系统，才不是角色扮演式的假智能，而是能在真实任务中分工、校验和交付的协作架构。
参考资料
- OpenAI Agents SDK 文档：Multi-agent：介绍通过 handoffs 和 agents-as-tools 设计多智能体工作流，用于监督者和交接模式。
- OpenAI Agents SDK 文档：Agents：说明 Agent、instructions、tools、handoffs、guardrails 等基础构件，用于智能体定义。
- OpenAI Swarm GitHub README：展示轻量 routines 和 handoffs 教育框架，用于蜂群协作历史背景。
- Google Agent Development Kit：Multi-agent systems：说明多智能体组合、层级、顺序和并行协作，用于模式分类。
- Google Agent Development Kit：Workflow agents：说明 Sequential、Parallel、Loop 等工作流智能体，用于流水线和并行执行。
- LangChain 文档：Multi-agent：说明 tool calling 和 handoffs 两类多智能体架构，用于监督者模式。
- LangGraph 文档：Multi-agent systems：说明网络、监督者、层级、工具调用和自定义多智能体架构，用于模式比较。
- LangGraph 文档：Supervisor：展示监督者路由多个专家智能体的图式实现，用于监督者模式。
- LangGraph 文档：Swarm：展示多智能体 handoff 和 swarm 风格协作，用于蜂群模式。
- Microsoft AutoGen 文档：Multi-agent Conversation Framework：说明多智能体会话、工具、人类反馈和自动化协作，用于协作协议设计。
- CrewAI 文档：Introduction：说明 Crews、Flows、角色、工具和流程，用于工程化多智能体团队。
- CrewAI 文档：Processes：说明 sequential、hierarchical 等执行过程，用于流水线和层级监督者。
- A Blackboard Architecture for Control：经典黑板架构资料，用于解释共享工作区和知识源协作。
- Blackboard Systems：介绍黑板系统概念、知识源和控制结构，用于黑板模式说明。
- Self-Consistency Improves Chain of Thought Reasoning in Language Models：提出多推理路径采样和答案一致性选择，用于投票模式。
- Tree of Thoughts: Deliberate Problem Solving with Large Language Models：提出思考树搜索、生成和评估中间想法，用于候选探索和选择。
- Improving Factuality and Reasoning in Language Models through Multiagent Debate：讨论多智能体辩论对事实性和推理的改善，用于辩论模式。
- Mixture-of-Agents Enhances Large Language Model Capabilities：讨论多个模型输出聚合提升能力，用于投票和聚合模式。
- AgentBench: Evaluating LLMs as Agents：提供多环境智能体评测思路，用于评测设计。
- GAIA: a benchmark for General AI Assistants：强调真实任务、工具使用和多步推理，用于智能体评测。
- τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains：评测工具智能体在真实领域规则和多轮交互中的可靠性，用于过程评测。
- OWASP Top 10 for LLM Applications 2025：列出提示注入、敏感信息泄露和过度代理等风险，用于安全边界设计。