先讲个真实经历。某项目组内部要做一份行业竞品分析，我当时图省事，直接扔了五个大模型智能体进去，告诉他们"你们每个人负责竞品的一个维度，最后汇总给我"。结果五份结论里有两份在核心数据上完全打架，三份的行文风格各唱各调，最离谱的是没有一个智能体愿意对"未知信息"做标注，全都用一本正经的口吻编完了。最后我花了半天时间手工缝合，才意识到一个一直被我忽略的问题：Multi-Agent 系统的效果上限，从来不是单个模型的能力，而是协作范式。
这些年我陆续做过内容生成流水线、任务拆解平台、质量审校系统，慢慢把 Multi-Agent 的协作模式摸出了门道。市面上讨论 Agent 的帖子很多，但多数都在讲单个 Agent 怎么调 prompt、怎么接工具，真正讲清楚"多个智能体之间该以什么关系协作"的内容其实不多。这篇文章想把这个问题讲透，核心是一条演进线：从流水线到办公楼，再到对等协商，最后变成一群小蚂蚁。四种范式没有绝对优劣，只看你的任务长什么样。
1. 先厘清概念：协作范式到底管的是哪几件事
1.1 单 Agent 的天花板在哪里
很多人觉得 Multi-Agent 是噱头，理由是"大模型已经够强了，为什么还要拆成好几个互相通信"。这个说法有道理，但不全对。一个模型再强，它在单次运行里能消化的上下文是有限的，能扮演的角色也是单一的。让同一个模型既当分析师又当批判者再当总结者，它很容易在长对话里失去最初的定位，最后产出的东西既不像分析，也不像批判。
另一个问题是系统性偏见。单个智能体的判断链路里，如果第一步出现了理解偏差，后面所有步骤都会继承这个偏差，而且会被一步步放大。就像一个人做校对，他可能刚好在某几个知识点上有盲区，那么漏掉的错误就会一路畅通。
多智能体的价值，就是引入不同的上下文窗口、不同的角色偏置和反馈回路，让"偏见"有机会被另一方纠正。但这里有个前提——多个智能体不是简单地堆数量，而是要有明确的协作关系。否则就会像我开头那次经历一样，五个智能体各说各话，协调成本比收益还高。
1.2 协作范式的三个核心维度
我习惯用三个维度来判断一套 Multi-Agent 系统到底采用了什么范式：
- 信息流向：数据是直线传递，还是树形汇聚，还是网状广播，还是局部邻居间低频交换？
- 决策权分布：有一个中心节点做最终裁决，还是所有节点地位平等，靠规则收敛？
- 容错策略：单个节点出错后，系统是直接中断，还是靠其他节点补位，还是整体结果依然可用？
这三个维度一变，系统的行为特性就完全不同。比如同样是处理文本任务，A 方案是 Agent1 写初稿、Agent2 审校、Agent3 终审，B 方案是五个 Agent 同时写稿再投票选优，两者在成本、延迟、质量稳定性上的表现会差出数量级。
1.3 四种范式的全景图
我把 Multi-Agent 协作分成四种范式，正好对应标题里的几个意象：
| 范式 | 核心意象 | 信息流向 | 决策权 | 容错方式 |
|---|---|---|---|---|
| 流水线范式 | 手工工坊的组装线 | 直线顺序传递 | 上游决定下游 | 单点中断，整体停摆 |
| 办公楼范式 | 层级组织架构 | 树形拆解与汇总 | 中心节点裁决 | 主管兜底纠错 |
| 广场范式 | 公开讨论与市场竞价 | 网状广播与回传 | 协商、投票、竞价 | 多数意见抵消单点偏差 |
| 蚁群范式 | 蚂蚁群体的觅食行为 | 局部邻居间交换信号 | 无中心，靠涌现 | 单点失效几乎无感 |
从流水线到蚁群，本质上是一条"刚性逐渐减弱、柔性逐渐增强"的演进线。流水线确定性最高，蚁群鲁棒性最强，办公楼和广场居中。下面我按这个顺序，分别展开讲清楚适用场景、实现骨架和踩坑点。
2. 流水线范式：工序固定的手工作坊，稳定但脆弱
2.1 流水线的结构与适用场景
流水线范式是最好理解的：任务被拆成若干个固定环节，Agent A 的输出直接作为 Agent B 的输入，像工厂组装线一样一站接一站。这种模式最适合流程稳定、环节边界清晰、串联顺序基本不变的场景。典型例子是内容生产：选题规划 → 资料检索 → 初稿撰写 → 合规审查 → 润色排版，每个环节职责单一，几乎不需要回环。
我最早做多智能体内容系统时用的就是这条路线。它最大的直观优势是可观测性极强——任务走到哪一步、卡在哪个环节，日志一翻就知道。你甚至可以给每个环节单独做质量评估，哪一站的输出不满意就单独优化哪个 Agent 的 prompt，不需要动整个系统。
2.2 一个内容生产流水线的实现骨架
用伪代码表示大概是这样：
# 流水线范式：内容生产链，每个环节是独立 Agent def content_pipeline(topic: str) -> str: # 环节1：选题分析 outline = planner_agent.run( f"为文章《{topic}》生成详细大纲，包含目标读者和核心论点" ) # 环节2：资料检索与草稿 draft = writer_agent.run( f"基于大纲写作初稿，要求论证充分、案例具体。\n大纲：{outline}" ) # 环节3：事实与合规校验 review = critic_agent.run( f"检查以下文章的事实性错误和合规风险，逐条列出问题。\n文章：{draft}" ) # 环节4：终稿修订 final = polisher_agent.run( f"根据审查意见修订文章，保留优点，修正问题。\n问题：{review}\n原文：{draft}" ) return final这个骨架看起来简单，但有几个细节值得注意。第一，每个环节的输入要自带上下文摘要，不能只传上一环节的原始输出，否则 Agent 容易迷失在长文本里。第二，审计意见（review）和原文（draft）要分开传，让改稿 Agent 清楚区分"事实依据"和"修改建议"。第三，如果某个环节的输出格式不稳定，最好在 prompt 里强制要求 JSON 结构，并在中间加一层校验逻辑。
2.3 流水线的三个隐藏成本
流水线范式看着省心，实际用起来有三个坑：
- 单点故障是硬伤。任何一个环节输出异常（比如某次模型抽风产出空内容），后续所有环节都会跟着崩。我后来在环节之间加了一层"空值检测和重试机制"，才把故障率压下来。
- 整体延迟等于各环节延迟之和。五级流水线每级平均三秒，整体就是十五秒以上，用户等待体验很糟糕。改进思路是让早期环节用更小更快的模型，只把复杂判断留给大模型。
- 上游错误会被无脑放大。流水线做了一个假设：每个环节的输出都是可信的。一旦大纲这一环就跑偏了，后面的初稿、审查、润色全都在一个错误地基上继续盖楼，而且盖得越用心，错得越离谱。
所以流水线适合的，一定是"环节执行本身不太容易出大错"的任务。如果你发现某个上游环节经常需要下游返工，说明这里不适合严格线性，应该考虑加回环或者换范式。
3. 办公楼范式：分级拆解与审核汇报的树形架构
3.1 办公楼范式的工作方式
当任务复杂度上升，单条流水线就无法承载了。一个中型任务可能需要同时做市场调研、技术评估、成本测算、竞品对比，如果把它们硬串进一条流水线，不仅链路过长，而且很多环节之间其实是并行关系，不存在天然的前后依赖。
这时候就需要"办公楼"这种层级架构：一个主管智能体负责理解总目标、拆解子任务、分派给不同的部门智能体，部门执行完再把结果汇总回来，主管统一审查合并。它和组织架构很像——老板不亲自写代码，但他决定谁写前端、谁写后端，最后负责合代码和把关质量。
这种范式在 Multi-Agent 里通常叫 Planner-Executor 架构，也是目前商业化产品里用得最多的一种。核心价值在于把复杂问题拆成可并行执行的小块，充分利用并行计算缩短整体耗时。
3.2 从一份技术方案的拆解看层级协作实现
拿"生成一份技术方案文档"举例，办公楼范式的骨架是：
# 办公楼范式：主管拆解 + 部门执行 + 主管审核 def hierarchy_plan(mission: str) -> str: # 阶段1：主管拆解 plan = manager_agent.run( f"将任务拆解为不超过4个可并行的子任务，\ 每个子任务给出负责人分工和验收标准。任务：{mission}", response_format="json" ) subtasks = plan["subtasks"] # 阶段2：部门并行执行 results = {} for task in subtasks: worker = get_worker(task["role"]) results[task["id"]] = worker.run(task["description"]) # 阶段3：主管汇总审核 merged = manager_agent.run( f"将各子任务结果汇总为统一文档，\ 消除矛盾，补充总论。各子任务结果：{results}" ) # 阶段4：主管自查，不达标则局部返工 verdict = manager_agent.judge(merged) if verdict["score"] < QUALITY_THRESHOLD: return hierarchy_plan(mission + "，重点改进：" + verdict["issues"]) return merged这里的关键是任务拆解后要附带验收标准。如果你让主管只输出子任务描述，不做验收定义，部门 Agent 就会各自发挥，最后汇总时你得到一份内部风格混乱、观点冲突的文档。加了验收标准后，部门 Agent 至少知道自己要在什么方向上用力。
3.3 办公楼范式的核心瓶颈
办公楼范式最大的问题，是主管智能体容易成为决策瓶颈。它承担了拆解、汇总、审核、返工决策四个职责，相当于所有信息都要经过它。子任务越多，主管理解上下文的压力就越大，它越容易在汇总阶段丢三落四。
我做某次跨部门协作系统时，主管 Agent 在汇总阶段经常漏掉子任务里的关键细节。后来想了三个办法：一是让每个部门 Agent 返回结构化内容（固定字段+摘要），而不是自由发挥的长文；二是汇总前先让主管列出"预期包含的要素清单"，再逐个对照；三是给主管配一个"袖珍审查助手"，专门负责核对清单覆盖度。效果提升很明显。
办公楼的另一个隐患是层级过深。有的团队喜欢建三级以上结构：总主管 → 部门主管 → 执行 Agent。层级一多，每层都会损失一部分上下文信息，传递到最终输出时，最底层的细节基本丢光了。我通常建议不超过两层，如果任务实在复杂，优先把任务横向拆分而不是纵向加层。
4. 广场范式：对等协商、投票与市场博弈
4.1 为什么需要"去权威化"的协作
流水线和办公楼有一个隐含假设——中心节点足够聪明。主管 Agent 看走眼，全盘皆输。可现实是大模型的判断本身就有概率性，同一个问题让同一个模型跑十次都可能给出不同结论。当任务对准确性要求很高时，把决策权集中在单一中心节点上，风险是很大的。
于是我逐渐开始引入第三种范式：广场范式。它是办公室之外的另一类社会形态——没有固定上级，多个智能体在平等的地位上，通过对话、投票、评审或竞价来达成共识。你可以在一个内容系统里让一个 Agent 写方案、另外两个 Agent 分别扮演"合规官"和"用户代表"去挑刺，再由评审组投票决定是否通过。这种方法天然具备对抗性，可以有效抵消单点偏差。
4.2 评审团模式与市场拍卖模式的取舍
广场范式里有两种常见子模式：
评审团模式：多个智能体从不同角色视角审查同一份结果，给出评分与意见，最后按规则收敛（投票、平均分、或指定仲裁者）。它适合质量审校、答案评审、决策支持这类"结果需要可信背书"的场景。
市场拍卖模式：一个任务发布方列出需求和预算，多个执行者智能体出价竞标，任务发布方按价格、能力信息综合选择中标者，执行完成后由第三方验收。它适合任务分派、资源调度这类"需要动态匹配供需"的场景。
两种子模式的选择标准很简单：如果你关心的是"这份东西到底行不行"，用评审团；如果你关心的是"这个任务该交给谁"，用市场拍卖。两者也可以结合——先由评审团定标准，再让市场按标准竞标。
4.3 投票与协商机制的简易实现
给一个最小化的投票评审实现：
# 广场范式：多角色评审团投票 def committee_review(answer: str, agents: list[Agent], threshold: float = 0.8) -> str: reviews = [] for reviewer in agents: score, reason = reviewer.run( f"请从你的专业视角评审以下答案，输出0-1分并说明理由。\n答案：{answer}", response_format="json" ) reviews.append((score, reason)) avg_score = sum(s for s, _ in reviews) / len(reviews) if avg_score >= threshold: return answer # 评审通过，结束 # 未通过：汇总意见，让撰写者修改后重新评审 feedback = "\n".join(f"- {r}" for _, r in reviews) revised = writer_agent.run( f"根据评审意见修改原答案，保留合理内容。\n意见：{feedback}\n原答案：{answer}" ) return committee_review(revised, agents, threshold)注意，这里我把递归深度控制得很死。实际工程里要限制评审轮数，否则很容易陷入"无限互怼"的死循环——A 说改，B 说不能改，C 说折中，最后来回踢皮球。我一般设置最大三轮，三轮没达成共识就直接由预先指定的仲裁 Agent 拍板。
广场范式也有成本问题：一次评审要调用三五个智能体，token 消耗是单 Agent 的好几倍。所以它只适合对质量要求高、且误差代价大的环节，不适合做全链路无脑套用。我见过有人把广场范式套在每一个小工具调用上，结果一个简单任务烧掉了十几次模型调用，效果还不比流水线好，属于典型过度设计。
5. 蚁群范式：没有控制塔，用局部规则涌现全局智能
5.1 蚁群的本质：个体极简，集体复杂
如果说办公楼和广场都还保留了"人"的组织影子，那么蚁群范式就完全是另一套逻辑了。它借鉴自真实蚁群：单只蚂蚁的智力很低，只会跟着信息素浓度走，但它和几万只同类通过局部互动，却能涌现出找最短路径、搬运大型食物等群体智能。
落到 Multi-Agent 上，蚁群范式的核心特征是：没有中心控制、没有全局视角、每个 Agent 只看得到局部信息，通过简单的局部规则和反馈信号反复迭代，最终让全局呈现有意义的模式。单个 Agent 甚至可以设计得非常简单，能力弱一点没关系，关键是量大、便宜、抗造。
我在做信息汇聚类任务时用过这种思路。比如从一万条用户反馈中提取高频问题，传统做法是写一个巨型 Agent 去阅读全部数据，但上下文窗口根本装不下。蚁群解法是派一堆小型 Agent，每个只随机看一小部分数据，各自输出局部发现，然后这些发现作为"信息素"喂给下一轮 Agent，让它们知道哪些方向值得深挖，几轮迭代后，高频主题自然浮现。
5.2 蚁群式汇聚任务的简化实现
下面是一个简化版的蚁群式多轮信息汇聚：
# 蚁群范式：局部感知 + 信息素式反馈迭代 def swarm_extract(all_texts: list[str], scout_agent: Agent, rounds: int = 4) -> dict: pheromone = {} # 候选主题 -> 累计置信度 batch_size = 50 for r in range(rounds): # 每轮随机抽取一批文本片段 batch = random.sample(all_texts, batch_size) for chunk in batch: # 侦察兵只基于局部文本 + 上一轮的信息素做判断 local_result = scout_agent.run( f"当前文本片段中值得关注的候选主题是什么？ \ 已有的候选热度参考：{pheromone}。文本：{chunk}", response_format="json" ) for topic, score in local_result["topics"]: # 局部规则：热度越高越强化，越低越衰减 pheromone[topic] = pheromone.get(topic, 0.0) * 0.5 + score # 只保留超过阈值的主题，按置信度排序 final_topics = { t: s for t, s in sorted(pheromone.items(), key=lambda x: -x[1]) if s > STIGMERGY_THRESHOLD } return final_topics这套实现里最有意思的是pheromone字典——它充当了信息素矩阵，但它不是存储在某一个中心节点上的记忆，而是通过每一轮不同侦察兵 Agent 的"局部感知+共享状态"逐渐积累起来的。每个 Agent 不需要知道全局数据长什么样，只需要看到"上一轮大家觉得哪些话题热"。于是个体保持极简，全局却具备记忆。
另外要注意，蚁群范式里 Agent 本身可以非常轻量。我有一次用了一个故意限缩 prompt 的模型，让它只做"从文本里挑出候选话题并给一个 0-1 分"这一件事，效果反而比让它同时做分析、归类、总结要好。因为它任务边界极窄，不容易发散。
5.3 蚁群范式的代价：不确定性与质量漂移
蚁群范式听上去很酷，但它的代价同样明显。
- 结果不可解释：没有任何一个 Agent 知道最终结论为什么是这个样子。出了问题，你只能倒查信息素积累路径，难度比查流水线日志高得多。
- 质量漂移：前几轮还有效的局部规则，换了数据分布后可能就失效了，而且因为没有中心监督，你很难及时发现。
- 随机性强：同一批数据跑两次，因为随机抽样选择不同，结果可能不一样。对一致性有要求的业务场景要慎重。
所以蚁群范式不适合精确型任务，比如"生成一个符合要求的产品文案"这种对措辞有强约束的场景，它天然适合的是：海量数据粗筛、热点发现、众包标注、资源调度、路径规划这类"要广度不要精度"的任务。你在生产中不要孤注一掷，可以把蚁群作为预筛环节，筛出候选后交给流水线或办公楼范式做精细处理，这样两者优势能互补。
6. 选型决策：从任务特征出发，而不是从范式热度出发
6.1 一张表搞定范式选型
聊完四种范式，最终要落到实践。我做选型时先看四个维度：任务流程的确定性、质量要求的严格度、任务规模、容错成本。整理成表如下：
| 任务特征 | 推荐范式 | 核心理由 |
|---|---|---|
| 环节固定、顺序明确、单点产出重要 | 流水线 | 可控性强，容易定位和优化 |
| 目标复杂、需要并行拆解、有质量兜底需求 | 办公楼 | 中心化拆解+并行执行，工程上最成熟 |
| 结果争议大、需要多视角校验、对抗性任务 | 广场 | 多角色对抗能降低系统性偏差 |
| 海量数据、动态环境、需要高容错 | 蚁群 | 无单点瓶颈，天然分布，按规模横向扩 |
| 数据海量+最终结论需要精修 | 蚁群预筛 + 后续精修 | 各取所长，控制成本 |
这张表只是起点。真实任务往往需要组合使用，我下面讲一下最实用的两个混合套路。
6.2 混合范式：工业界的真实解法
现在多数落地的 Multi-Agent 系统都是混合范式。我做得最多的是这个组合：办公楼管拆解、流水线管执行、广场管质量兜底。
具体到系统里就是：主管 Agent 把任务拆成子任务后，子任务内部如果是固定步骤，就用流水线片段执行；产出结果后不直接交付，而是扔给一个三到五个角色的评审团做终审，不达标就打回修订。这样一个系统既有了办公楼的复杂任务覆盖能力，又有了流水线的确定性，还在最关键的质量出口上避免了单一决策者拍板的风险。
另一个我常用的小组合是蚁群预筛 + 办公楼精排。在知识库问答场景里，无法把所有候选文档都塞给大模型，我就用一批轻量 Agent 快速打分过滤，把十万条候选缩到几十条，再交给主管 Agent 和精读 Agent 做深度判断。蚁群在这里不是产出最终结论，而是当一个"低成本粗筛网"。
6.3 成本与延迟的工程考量
范式选型直接决定账单数字。我粗略列一个相对成本对比（基于一次典型中等任务）：
| 范式 | 相对 Token 消耗 | 单次任务延迟 | 故障影响面 |
|---|---|---|---|
| 流水线 | 1 倍基线 | 累加延迟，较长 | 单点中断即失败 |
| 办公楼 | 1.2~1.5 倍 | 并行后可能更低 | 主管失误影响全局 |
| 广场 | 2~4 倍 | 多轮往返，最长 | 多数人可兜底，但要防死循环 |
| 蚁群 | 视轮次和个体数而定 | 单轮低，总轮次高 | 单点失效几乎无感 |
这里面最容易踩的坑是"为了并行而并行"。办公楼范式里，并行子任务节约了时间，但每个子任务需要把上下文复制一份，token 消耗其实是升高的。如果子任务之间强依赖上游结果，硬并行反而会导致主管频繁返工，费用和时间双高。我做这类系统时，一定会先画出依赖图，只有真正互不依赖的节点才并行。
7. 实践总结：我一直保留的几个习惯
系统做多了，有些经验远超书本，写在这里算是一个阶段性的个人备忘。
第一，永远从最简单范式起步。我见过太多团队一上来就搞五层办公楼嵌套广场评审，结果第一个 Demo 就卡在链路调试上。我的习惯是先用一条最短流水线跑通端到端，让它产生结果，再根据结果缺口决定加哪一层——质量不够就加评审团，任务太复杂就加主管拆解，数据太多才考虑蚁群式预筛。范式是给问题配的，不是给简历镀金的。
第二，范式切换不是改 prompt，是重新设计。同样一组 Agent，从流水线换成广场，意味着上下文的组织方式、输出约束、错误处理逻辑全都变了。有一次我把流水线末端直接加了个评审 Agent，以为只是多一步调用，结果评审 Agent 拿到终稿后总是想重写，反而把好稿改坏了。后来才意识到，广场范式里的评审 Agent 需要被明确告知"你只能给意见，不能直接改稿"，而且要给它的意见设置统一的结构格式。范式没变对，Agent 能力再好也白搭。
第三，不确定性要用观测性来换。蚁群和广场方案都比较"活"，系统内部很多过程是不可预见的。这种情况下我会给每条 Agent 消息加链路追踪 ID，把每轮的摘要、评分、修改原因都落日志。不是为了审计别人，而是出了问题你能倒排查到是哪一轮哪条反馈带偏了方向，这不难，但很多人不做，于是出了问题只能整锅端掉重来。
最后再补一句很实在的：别让单个 Agent 承担它不适合的协作位置。流水线里的润色 Agent 再聪明，也不该让它瓜分审校 Agent 的职责；办公楼里的部门 Agent 再全能，也没必要替代主管做全局决策。让每个智能体在范式里只做好一类事，系统整体反而更稳。这和带团队很像——不是每个人都有决策权，关键是每个人都知道自己在什么位置、该怎么和邻居打交道。Multi-Agent 走到最后，拼的不是单个模型的智商，而是这套"协作秩序"设计得好不好。
