先讲个真实经历。某项目组内部要做一份行业竞品分析我当时图省事直接扔了五个大模型智能体进去告诉他们你们每个人负责竞品的一个维度最后汇总给我。结果五份结论里有两份在核心数据上完全打架三份的行文风格各唱各调最离谱的是没有一个智能体愿意对未知信息做标注全都用一本正经的口吻编完了。最后我花了半天时间手工缝合才意识到一个一直被我忽略的问题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_formatjson ) 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_formatjson ) 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_formatjson ) 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(), keylambda 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 走到最后拼的不是单个模型的智商而是这套协作秩序设计得好不好。