1. 设计与拆解先搞清楚四种范式各自解决什么问题1.1 为什么单个大模型不够用非得上多智能体做AI应用做了三年多我越来越确定一件事单个大模型本质上是个手巧但只有一双手的老师傅。你让他同时干三件事他能把三件事都干成六十分但你要是把三件事分给三个角色各干各的再有人统一下节奏出来的东西往往能到八十五分往上。这也是为什么这两年多智能体Multi-Agent系统突然从学术论文卷到了工程落地——大家发现与其逼着单个模型变大变全不如让几个模型围绕一个目标分工协作各司其职。但协作绝对不是一句你帮我、我帮你就完事的漂亮话。我见过太多团队一上来就奔着超级Agent军团去结果Agent之间互相踢皮球上下文传到一半就乱套或者API账单高得吓人。问题几乎都出在同一个地方没想清楚这些Agent之间到底该按什么范式协作。1.2 从机械到群智四种范式是一条演进链我把目前主流的Multi-Agent协作方式归纳成四种范式。它们不是并列的四种选项更像是一条从机械到智能、从集权到自治的演进链流水线Pipeline任务被切成固定工序前一个Agent干完后一个才能动手。这是最朴素的分工。办公楼Orchestrator / Hub-and-Spoke一个主管Agent居中调度底下若干专职Agent各管一摊。这是最常见的组织结构。评审团Debate / Critic Loop多个Agent扮演不同立场互相评审、挑刺、迭代修正。这是冲质量去的。小蚂蚁Swarm没有中心协调者大量对等Agent按局部规则自主协作像蚁群一样靠简单个体的加和涌现出全局结果。最初设计的系统只用了流水线后面慢慢发现有的任务需要动态路由——于是加了办公楼范式再后来内容质量一直不稳——评审团范式进来了直到有一次做开放域信息聚合才发现前三种范式全都不好使最终被逼着做了一版小蚂蚁。整个过程不是哪个高级选哪个而是每一种任务场景都有它不可替代的位置。1.3 范式选型背后的两个核心变量选择范式时我通常只看两个变量任务的确定性和耦合度。确定性指的是任务步骤是不是事先能完全写清楚。如果能流水线就是最优解如果不能就需要办公楼里那个主管现场做判断。耦合度指的是各个子任务之间是顺序衔接还是互相影响。顺序衔接用流水线互相影响就得考虑评审团或小蚂蚁那样的闭环机制。后面在每个范式里我都会先讲清楚它的核心机制、适用场景再给出一段能直接改来用的实现草图最后附上我在实际项目中踩过的坑和参数调法。排版上我会用机制 → 场景 → 代码 → 避坑的顺序展开方便你边看边对照自己的业务。2. 流水线范式最朴素的协作但是99%系统的起点2.1 机制本质把大任务拆成单向链条流水线范式说白了就是顺序执行。任务被拆解成几个阶段每个阶段由一个Agent负责前一个Agent的输出直接作为后一个Agent的输入中间不做回环。你可以把它想象成工厂里的装配线拧螺丝的只拧螺丝装轮胎的只装轮胎东西从传送带一头进另一头就出来一台整车。在AI应用里这条传送带上流动的不是轮胎和螺丝而是数据对象——一段文本、一份JSON、一组合格的结果。每个Agent只负责对这份数据进行一次变换然后传给下一个。2.2 典型场景内容生产流水线我做得最多的一个流水线是文章自动生产系统。以前是一个人从头写到底后来拆成了五个Agent协作选题Agent根据关键词库和热点数据产出选题方向和核心观点。大纲Agent把选题拆解成章节结构每章写明论点。初稿Agent按大纲逐章展开写出完整初稿。润色Agent优化语言表达调整段落节奏补充比喻案例。校对Agent检查错别字、标点、事实性错误输出最终版本。这个链路看起来平平无奇但它是理解Multi-Agent的绝佳起点因为它强迫你做一件至关重要的事定义接口。每个Agent的输入输出必须用统一的数据结构固定下来。我常用的是一个简单的包from dataclasses import dataclass, field from typing import Any dataclass class StageMessage: stage_name: str # 当前流水线阶段名 payload: dict # 核心数据负载 meta: dict field(default_factorydict) # 元信息如模型参数、耗时等每个Agent只处理payload并原样传递meta。这样下游Agent永远只跟StageMessage这一个结构打交道换人换模型都不影响链路。2.3 流水线的实现框架与命令示例用代码实现流水线可以不用任何重型框架。我早期的版本甚至就是一段循环pipeline [ outline_agent, draft_agent, polish_agent, proofread_agent, ] current_message StageMessage(stage_nameinput, payloadsource_material) for stage_processor in pipeline: current_message stage_processor(current_message) print(f完成阶段: {stage_processor.__name__}, 输出长度: {len(str(current_message.payload))}) final_result current_message.payload这段代码有两个关键点一是管道里的Agent统一接口只要是一个输入StageMessage、输出StageMessage的可调用对象塞进列表就行二是每个Agent内部只依赖上一个阶段的输出不关心上游是怎么生产的这样就解耦了。当然真做产品级系统时我不会用裸循环而是用任务队列比如Redis Stream或简单的SQLite队列表来跑异步流水线。这样每个Agent可以独立扩缩容某个阶段慢了也不阻塞上游。异步化之后还要在meta里加一个trace_id跟踪全链路日志否则线上出了问题根本没法排。2.4 流水线的优缺点与避坑指南流水线优势非常明显简单、可控、每一个环节都可以单独测试出了问题定位也直观——数据卡在哪个Agent就是那个Agent的问题。但它有两个硬伤。第一是总耗时累加整条链路完成时间等于所有Agent执行时间的和如果中间某个Agent调用了一个响应很慢的模型会把整个链路全拖住。第二是不可回环前一个Agent输出错了后一个Agent只能将错就错没法回头修正。避坑经验生产环境里一定要给每个Agent设置独立的超时和重试机制。我遇到过初稿Agent偶尔返回空列表的诡异情况后来发现是模型偶尔不按提示词要求的JSON格式输出。解法是加一个兜底解析器解析失败就重发一次重发还失败就返回一个带error标记的结构让下游Agent明确跳过该阶段。另一个坑是提示词里的交接说明写得太长太啰嗦导致每个Agent都花大量上下文去理解协议真正干活的空间被压缩了。我现在的做法是把交接协议固化在代码层即下文说的StageMessage提示词里只写你收到的数据是上一阶段的产出请完成你的工序不夹带任何格式说明。适用判断标准如果任务能清晰划分成三个阶段以上、阶段之间没有复杂的依赖且允许线性时延那别犹豫直接用流水线。3. 办公楼范式主管居中调度让Agent各司其职3.1 机制本质把决策和执行分开流水线覆盖不了的一类任务是任务步骤没法事先确定。比如用户说帮我分析一下这个报表具体要分析哪些维度、要不要做对比、要不要给出建议全靠临时判断。这个时候就需要一个主管Agent来拆解意图、分派任务、汇总结果下属Agent只专注执行。这就是办公楼范式也叫中心调度范式Orchestrator Pattern。核心结构是两类Agent主管Orchestrator负责理解任务、拆解子任务、决定路由、汇总与后处理。专员Worker只负责执行分派下来的子任务把结果交回给主管。类比一下一栋办公楼里主管不亲自写代码、不亲自画图但他知道什么时候该找程序员、什么时候该找设计师。下属不需要知道客户需求全貌只需要把手里的活干漂亮。3.2 典型场景智能客服工单系统我做的一个智能客服产品就是典型的办公楼范式。用户进来说一句话前台主管Agent先做意图识别和槽位抽取然后决定走哪条路如果用户要退货就转给售后专员Agent如果是技术问题就转给技术支持Agent如果用户情绪激烈先转给安抚专员Agent。这个路由决策在实现上不一定非要单独调一次模型。我常用的做法是让主管Agent输出一个结构化的路由指令{ intent: after_sale_return, confidence: 0.92, params: { order_id: SO-2025-001234, product_sku: MK-88 }, route_to: after_sale_agent, fallback: human_service_queue }主管Agent只负责输出这个JSON实际的路由动作由代码执行——比如查一个route_table字典找到对应的处理函数。这样主管Agent的上下文窗口不会被业务细节占满路由决策做起来又快又准。3.3 办公楼范式的实现要点一个容易被忽略的细节是主管Agent不要做重复劳动。不少团队让主管Agent把所有下属Agent输出复制一遍再拼装结果是主管的上下文越变越长、成本越来越高。正确的做法是主管只维护一个任务状态清单和结果索引下属Agent的完整结果存到外部存储数据库、内存缓存、文件需要拼接时再按引用取。我用过一个简单的任务状态结构dataclass class TaskStatus: task_id: str intent: str status: str # pending / running / completed / failed assigned_agent: str result_ref: str error_msg: str 主管每次只更新这个清单最后的汇总环节再根据result_ref把完整结果取回来拼装。这样主管的输入输出永远是小体量的不会爆上下文窗口。办公楼范式的另一个要点是错误处理与降级策略。下属Agent出错了不能直接失败返回要设一个降级路由比如技术Agent三次失败后主管自动把工单转给人工程序。我用一个简单的重试计数器超过阈值就改路由到人工队列避免用户无限等待。3.4 办公楼范式的优劣势与经验总结办公楼范式最大的优势是动态性和可扩展性强可以很自然地接入几十个不同方向的Agent每个Agent只需要对主管负责不需要知道其他Agent的存在。新增一个方向的Agent只需要在主管的路由规则里加一条。但它有两个典型的坑。第一个坑是主管Agent容易被心智过载。当子任务类型超过七八种、路由规则比较复杂时主管模型可能需要很强的推理能力。我用实测数据说话普通的中小模型当主管路由准确率只有七成换成一个更强的模型能到九成以上。所以办公楼范式里主管Agent值得你多花成本、用更强更稳的模型下属Agent反而可以用小模型来省钱。第二个坑是嵌套过深。有些场景下主管下面还有一级小主管这就形成了多层办公楼。我实际测下来两层的嵌套还能接受三层以上链路时延明显变大且跨层的上下文丢失概率显著上升。如果真有这种需求优先考虑引入消息总线或队列解耦而不是继续往下堆管理层级。经验之谈办公楼范式解决的是任务动态路由不是多步骤顺序执行。如果你发现路由规则是固定的、每个单子都要按相同流程跑那流水线加一个前置判断节点就够用了不必上办公楼。4. 评审团范式让Agent互相挑刺迭代出高质量结果4.1 机制本质协作的目的是对冲幻觉前三类范式里Agent之间多少还是你好我好的协作关系。但有一类任务单个Agent吭哧吭哧写完质量就是上不去——不是能力不够是缺少从外部视角看自己的能力。这个场景下评审团范式就派上了用场。评审团范式的核心机制是生成与评审的对抗迭代。至少一方Agent负责产生产出另一方Agent负责从反面挑问题、给修改意见然后循环修改 → 评审 → 再修改 → 再评审直到满意或达到迭代上限。你可以理解为写文章的人容易写嗨需要一个挑剔的编辑在耳边说这段逻辑不通、那个结论没依据。**让模型A给模型B挑刺本质上是用另一套上下文和偏好去对冲单个模型可能有的系统性幻觉。**同一个模型既当作者又当评审员效果远不如两个不同角色、甚至不同参数的模型互相评审。4.2 典型场景技术方案评审我做得最多的是方案评审场景。某团队拿出一个技术方案初稿让我用AI帮忙做架构评审。我没有让单个Agent直接帮我看一下方案而是组建了一个评审团架构师Agent关注扩展性、耦合度、单点风险。运维Agent关注部署成本、可观测性、故障恢复。安全Agent关注数据安全、鉴权、注入风险。财务Agent是的我没开玩笑关注资源成本和长期维护成本。每个评审Agent独立阅读方案给出结构化意见。然后我再用一个仲裁Agent汇总各方意见输出一个优先级排序的修改清单返回给方案作者。这里核心在于评审与作者分离。方案作者Agent先按修改清单迭代一版然后评审团再审。第二次评审往往能发现上一轮没覆盖到的深层次问题尤其安全Agent和运维Agent的意见经常互相打架仲裁Agent就得拍板。4.3 让评审不流于形式的关键参数评审团范式的问题是不只是搭了结构就完事迭代机制必须设计得当否则很容易变成互相无脑同意或者无限抬杠。有四个关键设计点我心里的优先级是这样排的设计维度推荐做法不做会怎样角色数量3-5个足够太多则吵评审团过大观点重叠度高反而浪费token迭代次数设上限如2-3轮无限迭代导致成本失控且收益边际递减仲裁机制必须有专门的仲裁Agent没有仲裁各方意见冲突时无法收敛输出格式强制结构化JSON自由文本意见无法自动汇总和排序温度参数的设置在这里也很值得讲。评审Agent为了能挑出问题我会把temperature调得偏高一点比如0.4到0.6让它的思维多一点发散而仲裁Agent则需要更收敛、更确定我把temperature调到0.1左右。生成内容的Agent如果是在创作场景下我给0.6-0.8如果是改代码、改严谨的方案我就用0.2-0.3。实操心得token的成本大头往往不在生成Agent而在多轮评审累积的上下文。我的做法是每一轮迭代只把上一轮的修改说明评审意见传给生成Agent不把之前的所有老版本都一股脑塞进去。这样每轮上下文长度可控成本也随之稳定下来。4.4 评审团范式的适用边界评审团范式最适用的场景是质量敏感型任务内容生成、代码审查、方案设计、翻译润色。只要单次生成的结果不够好且修改空间大它就越大放异彩。但它也有明显的边界。第一如果任务是事实型问答比如某市面积是多少你让几个Agent互相评审大概率是几个人一起编。这种场景需要的是外接知识库检索不是评审团。第二如果实时性要求很高多轮迭代会拖慢响应。我实测过一次单轮生成的P95响应在2秒左右跑两轮评审直接涨到6秒以上没法做在线实时交互。关于如何终止迭代我的经验是把满意的定义显式交给评审Agent而不是生成Agent。也就是评审Agent最后输出一个approve: true/false字段和一个score评分。当approve为真或者评分连续两轮没有提高就停。不能指望生成Agent自己判断我可以停了——它永远认为自己的产出是好的。5. 小蚂蚁范式去中心化自组织让群体涌现智慧5.1 机制本质没有中心舞台只有自组织涌现前三类范式都有一个共同前提存在一个看得清的全局结构——流水线是静态链路办公楼有主管评审团有仲裁。但有一类任务任务的探索空间大到根本没法预先规划结构。比如帮我排查这个几十万行的系统里可能存在的性能瓶颈你没法提前把步骤列成流水线也没法让一个主管想清楚所有分支任务。这时候就得祭出小蚂蚁范式也就是去中心化的Swarm模式。核心思想是不设主管、不画链路让一批对等的Agent根据规则自主行动并通过共享的消息环境来协作最终结果靠群体行为涌现。类比蚂蚁找食蚁群没有队长每只蚂蚁只是顺着信息素浓度往前走。单个蚂蚁的行为极其简单但成千上万只蚂蚁加在一起就能找出从蚁窝到食物的最优路径。AI场景里信息素就是各Agent在共享消息区比如消息队列、任务黑板里留下的结果和反馈。5.2 典型场景开放域信息聚合我被逼着做小蚂蚁范式的项目是一个开放域调研系统。需求是针对某个主题自动扫描不同维度的信息并汇聚成报告。一开始用办公楼范式主管拆任务拆到一半就崩溃了——因为很多可探索的方向主管根本不知道它们存在。于是我把架构改成了小蚂蚁风格初始化一个探索Agent群体每个Agent领到一个差异化的探索方向比如关注技术趋势方向关注市场动态方向关注风险合规方向它们的初始方向由一个简单的种子列表产生。每个探索Agent独立工作把自己的发现写回共享消息区。额外的聚合Agent不断监视消息区发现某一主题下的发现越来越多就新开一个子专题Agent去深入挖掘。最后的主编Agent负责读取消息区里所有沉淀内容过滤重复、合成最终报告。整个系统里没有一个Agent掌握全局但最后却产出了一份覆盖不同视角的报告。最有意思的是某次它竟然挖出了一个初始种子列表里完全没有提及的长尾风险点——那种再挖深一点的链路就是群体协作涌现出来的行为。5.3 小蚂蚁范式的工程化要点小蚂蚁范式听起来浪漫工程化却最折腾。纯靠Agent之间的自然语言互相喊话成本不可控、效果不可控。我做成型的方案是在中间加了三件配套基础设施第一任务黑板Task Blackboard。所有Agent不直接对话而是往黑板上写结构化消息。消息格式类似dataclass class AntMessage: agent_id: str topic: str content_type: str # exploration / finding / duplication / request content: str session_id: str timestamp: float黑板帮我实现了解耦和历史回溯出问题时我可以像看蚂蚁留下的轨迹一样按agent_id回放每个Agent的行为。第二去重与收敛机制。没有中心主管最常见的问题就是50个Agent全部扑到同一个热点上产出大量重复内容。我加了一个向量检索相似度去重器Agent写完以后先过一遍黑板如果和已有内容相似度超过阈值就直接丢弃或让Agent换个方向再产出。第三成本护栏。开放域探索最怕成本跑飞。我的做法是给每个Agent设置一个预算每个Agent最多能发多少条消息、跑多少轮探索额度用完就自动休眠。整体再由一个监督循环监控所有Agent的总消耗一旦超过会话预算就动态冻结部分Agent。分布式去中心化的实现上如果要支持多个Agent并行跑不建议自己写消息队列直接用成熟的Redis Stream或NATS至少能省一半坑。Agent实例的动态扩缩容我用的是一个简单的调度循环检测黑板里待探索方向队列的长度超过阈值就启动新的Agent实例空了就回收。5.4 小蚂蚁范式的两面性小蚂蚁范式最大的优点是发现能力和适应性强。它能覆盖到那些你事前完全想象不到的方向而且天然支持大规模并行弹性也好。缺点是结果质量不稳定要知道Agent群体涌现出来的不一定全是智慧也可能是信息垃圾场。我实测下来同样的任务跑三次三次结果的结构和质量有明显波动这在笔记本范式里是很少见的。另外有一个比较隐秘的坑没有中心调度想要按特定口径审计一个决定是怎么做出的基本无能为力。黑板上虽然记录了消息但为什么某Agent决定往这个方向探索往往隐含在它的提示词和上下文里光看它的行为轨迹看不出来。如果要落地到强审计需求的行业我建议还是用办公楼范式打底把探索类任务放到下层去用小蚂蚁跑。6. 多范式实战一个系统里如何混搭与选型6.1 什么时候该用哪种范式我在前五章分别讲了四种范式各自的机制与适用场景但真实项目中很少只用一个范式。选型时我会用一个三问判断法来快速决策第一问任务步骤是否能在运行前完全确定能确定 → 流水线范式不能确定 → 进入第二问第二问任务是否需要多个不同专业方向的知识需要 → 办公楼范式不需要但需要防止生成质量问题 → 评审团范式第三问任务的探索空间是否巨大且不可预知是 → 小蚂蚁范式否 → 回到前两个最保险的范式这套判断法不能涵盖所有边界情况但能覆盖八成以上的工程现实。剩下两成就靠经验微调了。6.2 一个典型案例跨平台内容中台系统我在某公司负责过一个内容中台系统核心功能是从源素材自动生成多平台投放文案。这个系统的架构就是多范式混搭的典型。整体链路是一套流水线选题Agent → 素材清洗Agent → 素材分析Agent → 多平台文案生成Agent。但在素材分析这一步内部嵌了一个办公楼范式主管Agent根据素材类型图文/视频/纯数据动态路由到对应的分析专员Agent。到了文案生成这一步每个平台方向的生成Agent写完初稿都会交给一个评审Agent打分低于阈值就按修改意见返工一轮这就是嵌套的评审团范式。只有当运营人员发起自由探索新选题任务时我才会额外启动一个小蚂蚁范式的工作池让几十个探索Agent去全网抓线索产出候选选题清单喂回流水线的源头。这个系统的经验告诉我四种范式不是单选题而是可以在一个系统内分模块混搭的。关键是每个模块的边界都要清清楚楚流水线负责粗粒度编排办公楼负责模块内部的动态路由评审团负责质量关卡小蚂蚁负责开放探索。每层范式管好自己的范围不要越界。6.3 参数选择、成本控制与上下文管理无论用哪种范式有四个工程参数是通用的我每次上线前都会盯着调模型强度分配让决策型Agent主管、仲裁、评审用更强的模型让执行型Agent写稿、向量化、提取用更小更快的模型。这能省三到四成的token成本。温度参数梯度创作类Agent调高一点0.5-0.7评审类/仲裁类调低0.1-0.3避免输出过于发散导致格式不稳定。上下文截断策略每个Agent只接收它完成任务必需的信息不盲目把全链路数据都传下去。我在流水线里靠StageMessage.payload做白名单筛选在办公楼里靠result_ref按需取数。超时与重试每个外部调用的Agent都套一层超时重试降级的壳。降级不是只报错给用户而是路由到下一个可处理的Agent或人工队列。加了这些参数规矩之后线上系统的稳定性上了一个大台阶。以前动不动就某个Agent莫名输出了乱码现在绝大多数情况都能被兜底逻辑处理掉。7. 常见问题与排查技巧实录本章整理了我在四种范式实战里遇到频率最高的五类问题按症状→原因→解法整理成一张速查表方便你直接对照。症状最常见原因排查方法与解决对策Agent之间来回踢皮球任务不收敛缺少明确的终止条件和最终仲裁者检查是否设了迭代上限引入专门的仲裁/主管Agent做最终决策评审团里给approve字段设硬性终止条件上下文越传越长token成本飙升没有做数据白名单筛选全量信息往下传改用结构化消息传递下游只接收需要的字段用外部存储存储详细结果只传递引用某Agent总是输出格式不对提示词里格式说明太复杂或模型温度太高把格式说明浓缩为一条JSON示例固化在代码层解析器里降低该Agent的temperature办公楼范式中主管路由经常出错主管Agent模型能力不足或路由规则超过其认知负荷换用更强模型把路由规则从自然语言改成结构化枚举代码路由给每个路由配置显式样本few-shot小蚂蚁范式产出大量重复内容缺少去重机制多个Agent挤在同一个方向引入向量检索相似度去重器给每个Agent的初始方向差异化和冲突检测限制单个方向最多并发Agent数量这里我再单独展开两个最容易被忽视的实战细节。第一个是日志和可观测性。多Agent系统出了错最痛苦的往往不是跑错而是不知道自己哪一环跑错了。我给每个Agent的输入输出都加了一个trace_id和stage_name全部打到结构化日志里线上排障时按trace_id检索几秒钟就能把整条协作链路拉出来。如果系统简单没有引入日志平台那也至少要在代码里加一个logger.info记录每个Agent的入参出参摘要否则排查问题全靠瞎猜。第二个是评估与回归。所有多Agent系统改一个Agent的提示词都可能影响全链路质量。所以我维护了一个金标测试集里面大概有四五十条覆盖常见任务场景的测试用例每次改完提示词或模型参数后就跑一遍回归测试看输出质量的关键指标评分、合规率、耗时不超标比例是否回退。没有这套评估多Agent系统会越改越乱上了线都不知道效果是变好还是变坏。8. 结尾个人经验与两个实用建议做了这么多年AI应用最终的体会是多Agent系统不是越复杂越好。一个能做10分任务的流水线抵制住诱惑不用小蚂蚁是成熟的表现一个明确需要动态路由的客服系统硬套流水线做成一锅粥则是另一种不成熟。根据我的真实经验再补两个实用建议第一上线前第一件事是定义好每个Agent的输入输出协议和错误处理降级路径然后再去调参协议没定清楚时调参是浪费时间的第二每个Agent的提示词尽量只描述角色、目标和边界不描述协作流程协作流程的编排尽量放在代码层。提示词里一旦开始描述当你收到A的消息后你应该先做B再做C那这个系统基本就没有可维护性可言了因为改一次编排逻辑就要改无数个Agent的提示词。四种范式本身没有高下之分关键是拿捏住任务的确定性、耦合度和质量要求在对的位置用对的结构。剩下的事就是一遍遍跑测试、修边界、看日志——多智能体系统的工程难点不在让Agent干活而在让Agent们稳定、安全、可控地一起干活。把这些难点啃透了你手里这群小蚂蚁就能真正帮你扛起大规模的生产任务了。