一文搞懂 Multi-Agent：AI 是如何分工、协作与决策的？

单个 agent 只需要处理一条时间线感知、推理、行动、循环。一旦变成多个 agent问题的维度立刻从一维变成了多维——谁该做哪一部分谁需要知道谁发现了什么谁的动作要等谁先完成两个 agent 的判断打架了听谁的系统怎么知道所有人都干完了难的从来不是让每个 agent 变聪明而是 让它们别互相拖后腿“—— 多智能体系统的协调原理单个 agent 只需要处理一条时间线感知、推理、行动、循环。一旦变成多个 agent问题的维度立刻从一维变成了多维——谁该做哪一部分谁需要知道谁发现了什么谁的动作要等谁先完成两个 agent 的判断打架了听谁的系统怎么知道所有人都干完了这五个问题不管用的是哪个框架、哪个大模型、哪种业务场景只要是多个自治单元一起工作就必须回答。这篇文章不打算讲某一家公司命名好的架构模式而是想把这五个问题拆开讲清楚“协调”这件事本身有哪些通用的解法——原理是什么、代价是什么、具体怎么用代码实现出来。01、协调问题的五个基本维度在设计任何一个多智能体系统之前先把这五个维度想清楚比直接选一个架构模板更重要1.任务分配——整体目标怎么拆成可独立执行的子任务落到具体哪个 agent 头上。2.信息流动——一个 agent 的发现、结论、中间状态怎么传递给需要它的其他 agent。3.执行时序——多个 agent 是严格排队还是可以同时铺开同时铺开时何时该停下对齐。4.冲突消解——两个 agent 产出互相矛盾、或同时想改同一份资源时听谁的、怎么合并。5.终止判定——系统怎么知道“这件事已经做完了”而不是无限空转或草率收场。 接下来分别展开这五个维度各自有哪些通用机制。02、任务分配——谁来做什么层级式分配一个大脑说了算最直接的分配方式是设一个“大脑”agent由它分析整体目标、拆解子任务、指派给合适的执行者执行者做完后交回大脑整合。这种方式很像公司里的项目经理制——任务拆解和分配的决策权高度集中好处是全局一致性有保障代价是这个“大脑”会变成整个系统的瓶颈它的判断力上限决定了拆解质量上限一旦它本身出故障整个系统就会停摆。市场式分配谁能干、谁来抢另一种思路借鉴市场机制把子任务发布出去让具备相应能力的 agent 自主“竞标”或按能力匹配去认领不需要中心节点决定“该给谁”。原理是用局部的分布式决策替代中心化决策好处是没有单点瓶颈、扩展性强代价是全局最优不再有保障可能出现多个 agent 争抢同一个高价值任务、某些任务却无人问津的情况。自组织分配从共享队列里领活介于两者之间的是设一个共享任务队列agent 谁有空谁去领做完标记完成再领下一个——更接近生产线的“拉动式”调度。它兼顾去中心化和简单性实现成本比市场机制低得多局限是只解决了“谁来做”没解决任务之间是否存在依赖关系——依赖条件还没满足时agent 可能就把任务抢走了。03、信息流动——谁需要知道谁的发现直接寻址点对点传递一个 agent 直接把消息发给另一个指定 agent类似打电话。信息路径最短不容易被中间环节压缩污染但要求发送方在发送时就明确知道该发给谁agent 数量和交互关系一旦频繁变化硬编码的点对点连接会迅速变得难以维护。集中转发一切经过中枢所有信息先汇总到一个中枢节点再由它决定转发给谁。好处是中枢天然拥有全局视角能识别跨 agent 的关联性局限是中枢容易变成瓶颈且信息每经过一次转发和总结都有被压缩、丢失细节的风险层层转手之后最初的关键信息很可能面目全非。共享内存把信息放进公共空间不经过中转所有 agent 直接读写一个共享存储——有发现就写进去需要信息就去查。这个思路来自更早的分布式人工智能研究中的“黑板系统”blackboard system多个专家把推理结果写上共享黑板其他专家看到新信息就被触发做进一步推理协作行为是“涌现”出来的。好处是没有中转损耗、没有单点故障局限是行为难以预测容易出现重复劳动也容易出现自我强化但不收敛的循环。发布-订阅按主题广播agent 不把消息发给具体对象而是发布到一个“主题”上订阅者提前订阅好由路由层负责投递。原理是把“谁该收到”的判断从发送方转移到了显式的订阅关系上扩展性很强代价是路由层本身可能出错——消息被误分类或路由丢失时系统会安安静静地什么都不做这种“沉默失效”比直接崩溃更难排查。04、执行时序——谁先谁后顺序执行接力棒模式agent 排队工作前一个做完把结果交给后一个。好处是任何时刻只有一个 agent 在动不存在并发冲突逻辑最容易推理和调试代价是总耗时是所有 agent 耗时的简单相加完全没利用任务本可以互不干扰、同时进行这个特性。并行执行 屏障同步分头行动定点汇合子任务彼此独立时可以让所有 agent 同时开始等全部完成后在一个“屏障”节点统一汇总再进入下一阶段——原理和分布式计算里的 map-reduce 一致。它能把总耗时从“相加”压缩到“取最长的那一个”代价是整体进度取决于最慢的那个 agent其余早完工的只能干等直到超时或被强制跳过。事件驱动异步谁触发谁响应不设固定阶段划分agent 监听特定事件事件发生就响应处理完可能产生新事件触发下一个 agent整条链路由事件流自然驱动。优势是灵活不需要提前把所有分支设计进固定流程代价是执行路径难以追溯——一个事件触发的连锁反应可能经过五六个 agent必须依赖完善的日志和链路追踪否则调试难度会显著上升。05、冲突消解——听谁的集中仲裁一个人拍板把最终裁决权交给某一个特定 agent不同来源的意见汇总上来由它综合判断。原理上和层级式任务分配是同一思路——牺牲一部分去中心化的灵活性换取判断的一致性。生成者-验证者分权而非集权把“产出结果”和“评判结果是否可信”显式拆成两个不同的 agent而不是同一个 agent 既当运动员又当裁判。这个机制的原理来自一个反复验证过的现象让 agent 自己判断自己做得好不好几乎必然会倾向于认可自己的结果自我评估天然带有偏向性。这个机制真正生效的前提是评判标准必须写得足够具体——一句笼统的“检查一下好不好”起不到任何把关作用。投票与共识多数人说了算没有天然可信的裁决者时让多个 agent 各自独立判断再通过投票或共识机制决定最终结果。好处是能过滤掉单个 agent 的偶然性错误代价是成本更高且如果多个 agent 共享同一种系统性偏差比如都基于同一个基座模型投票机制无法纠正这种共同的盲点。锁与版本控制技术层面的并发冲突当冲突不是“意见不一致”而是“两个 agent 同时想改同一份资源”解法通常借用分布式系统里现成的机制加锁、乐观并发控制、版本控制。这类机制解决的是“谁先动手”的工程问题而不是“谁的判断更对”的认知问题两者不能用同一套机制笼统应付。06、终止判定——什么时候算完成固定预算跑满就停设一个硬性上限——最大轮次数、最长运行时间、最高花费到了就停。实现最简单能兜住无限循环这种最坏情况但它不关心任务是否真的完成可能在还差一点点时强行掐断也可能早该结束却继续空转到上限。收敛阈值没有新发现就停观察系统的“新增产出速率”连续若干轮没有产生有价值的新信息就认为已经收敛。尤其适合共享状态、事件驱动这类没有中心节点掌控全局进度的架构因为没有人能直接说“任务完成了”只能靠观察系统整体活跃度间接判断。独立评估终止由裁判说了算最可靠但成本也最高设一个专门的评估角色用明确、可核验的标准检查产出是否满足要求通过才真正终止。这和“生成者-验证者”冲突消解机制在原理上是同一件事——评判权必须独立于执行权否则“是否完成”这个判断会被执行者自己的乐观偏差污染。07、把五个维度组合起来理论讲完了下面用一段简化的 TypeScript 伪代码展示怎么把上面五个维度组装成一个可运行的协调层不绑定任何具体厂商的 SDK核心是把“分配、通信、时序、冲突消解、终止”这五件事显式拆成五个可替换的组件。typescriptinterface Allocator { // 任务分配 assign(tasks, agents): Map; } interface Channel { // 信息流动 publish(from, payload): void; read(agentId): any[]; } interface Scheduler { // 执行时序 run(assignments): PromiseResult[]; } interface Resolver { // 冲突消解 resolve(results): any; } interface TerminationPolicy { // 终止判定 shouldStop(history, budget): boolean; }typescriptasync function coordinate(...) { while (true) { const assign allocator.assign(tasks, agents); const results await scheduler.run(assign); results.forEach(r channel.publish(r.id, r)); history.push(results); if (termination.shouldStop(history, budget)) break; tasks deriveNext(resolver.resolve(results)); } return resolver.resolve(history.flat()); }「任何一个具体的多智能体架构本质上都是在给这五个接口分别选一个实现」选层级式分配器 集中转发通道 并行调度器 集中仲裁 固定预算终止得到的就是最常见的“一个大脑指挥多个执行者”的架构换成队列式分配器 共享内存通道 事件驱动调度器 投票消解 收敛阈值终止得到的就是完全去中心化的协作架构。中间还有大量排列组合具体选哪一种取决于任务本身的依赖结构、对一致性的要求以及愿意为并行和去中心化付出多少额外的工程复杂度。08、代价是共同的不管选择哪种组合多智能体协调都要为以下几件事付出代价这是通用的、和具体选哪种机制无关信息保真度下降信息每多经过一层转发、一次总结就有一次被压缩、被简化、被误读的风险层级越深、中转越多风险积累越明显。并行的速度收益要用同步开销换完全不并行最容易保证一致性但慢完全并行最快但需要更复杂的机制处理冲突和保证收敛没有免费午餐。去中心化程度越高行为越难预测高度去中心化的系统里行为是多个自治单元互动“涌现”出来的出问题时排查成本显著更高。终止条件最容易被忽视很多团队认真设计任务怎么分、信息怎么传却把“什么时候算完”留到最后或者交给一个固定轮次上限草草了事。写在最后多智能体协作说到底不是“用了几个 agent”的问题而是“任务分配、信息流动、执行时序、冲突消解、终止判定”这五件事分别怎么解决的问题。具体某个厂商命名的某种架构模式不过是在这五个维度上分别选定了一组实现方式的组合。理解了这五个维度的通用原理就不再需要记住某个模式的名字才能设计系统而是可以直接从任务本身的结构出发为这五个问题分别挑选最合适的解法再把它们组装起来。