多Agent系统编排难？试试蜂群模式

做多Agent系统最累的不是写Agent，而是排编。Agent一多，调度逻辑就开始缠成一团：谁先跑、谁等谁、谁的结果作为谁的输入、失败了重跑哪个、重跑之后下游要不要跟着重算……本来只想让几个智能体协作一下，结果陷入了一套复杂度不亚于分布式系统的编排泥潭。

这篇是Harness Engineering系列第五篇，前几篇聊的都是怎么给单个Agent套缰绳——约束输出格式、控制工具权限、设计上下文骨架。这篇换个视角：当Agent从一个变成一群，缰绳该怎么分。我的核心观点先说清楚：多Agent系统的正确打开方式，不是把所有Agent编成一条流水线，而是把它们放养成一群蜂。

1. 编排式多Agent为什么会在十个Agent后崩溃

先说个反直觉的结论：**Agent越多，传统编排式架构越不可用。**这不是推理能力的问题，是沟通拓扑的复杂度问题。

1.1 协调爆发的数学直觉

假设你有N个Agent，每个Agent都需要把结果交给“下一步”的Agent。最朴素的编排方式是定义一张有向图，每个节点是一个Agent，边代表消息传递。N=3或者N=5的时候，这张图很清晰，你甚至可以在白板上画出来。但N=15的时候，边的数量开始指数膨胀——当每个Agent理论上都要知道“谁能消费我的输出”以及“我需要谁的输入”时，潜在的交互对就是N×(N-1)/2，十个Agent就是45个关系。这还只算了一对一关系，没算分支合并、循环重试。

更要命的是，这种编排图在运行时是动态的。任务输入不同，某些分支可能被跳过，某些Agent可能反复被执行。静态图变成动态图，调试难度直接翻倍。

1.2 等待链引发的“集体卡死”

编排式的另一个坑是等待链。假设有任务流A→B→C→D，A跑完B才能跑，B跑完C才能跑。看起来没问题，但实际运行中，只要中间某个Agent因为工具调用超时、模型输出格式错误、或者上下文窗口溢出而卡住，整条链就卡住了。你需要在每个环节都做超时控制、失败重试、状态恢复。

十个Agent串行，每个环节99.9%的可用性，总可用性是99%——听起来还行。但如果每个环节内部还有分支，再加上重试带来的级联效应，真实系统的成功率会肉眼可见地往下掉。

1.3 一个真实的崩溃案例：多角色模拟器

我见过一个项目，目标很朴素：搭建一个“多角色讨论系统”，让产品、设计、开发、测试四个Agent模拟开会，共同决策一个需求方案。设计文档画得很漂亮：中心有一个“主持人Agent”负责汇总各方意见，四个角色Agent轮流发言。

实际跑起来的问题在于：主持人Agent既要理解产品提的需求，又要判断设计方案的可行性，还得裁定开发和测试的冲突——它的上下文窗口很快就不够用了，一会儿忘掉前面谁说过了什么，一会儿把某个角色的观点安到另一个角色头上。而四个角色Agent呢？各自等着主持人总结、提问，才愿意继续说话。整个系统变成了一个“四个问题学生和一个记性不好的班长”的课堂，效率极低。

后来我们把它推倒重来，换成了另一种思路——**不要开会，改成分头干活，谁擅长什么直接干什么。**这就是蜂群模式的雏形。

2. 蜂群思维的工程内核：去中心化、信号素与涌现

蜂群这个词容易让人联想到科幻片里密密麻麻的飞行器，或者生物课上蜜蜂跳舞的集体智慧。但放到工程里，它对应的其实是三样特别朴素的东西：去中心化的执行单元、一个大家共享的状态空间、以及简单的竞争与协作规则。

2.1 信息素在工程世界的落地：任务黑板

蜜蜂通过释放信息素告诉同伴“这里有花源”，蚂蚁通过信息素轨迹标记“这条路径已有人走过”。工程系统不能真的放化学物质，但可以搞一块“任务黑板”——一个所有Agent都能读写、按优先级排序、带状态标记的公共任务池。

具体来说，就是一张任务表：

每个Agent在处理完自己手里的活之后，不是陷入等待，而是去黑板看有没有自己能干的活，认领下来、更新状态、执行、写回结果。整个系统没有“下一步该跑谁”的中央大脑，只有一个个主动找活干的“工蜂”。

2.2 先到先得：任务认领而不是任务分配

编排式系统像经理派活，蜂群式系统像柜台抢单。经理派活的效率瓶颈在经理本人，抢单的效率瓶颈在任务池的并发度和Agent的认领速度。

工程上实现认领机制特别简单：Agent启动后初始化一个循环，先查任务池里有没有符合自己“能力标签”且状态为“待处理”的任务，加一个“认领中”的标记（注意用原子操作或者分布式锁，避免两个Agent抢同一条），然后开始执行。执行完把结果写回任务表，把状态改成“完成”。

这个模型的优势不只是去掉了中央调度器，更重要的是并发度天然拉满——五个Agent同时开跑，不需要你操心它们之间谁先谁后。

2.3 涌现不需要“魔法”

很多人一听“涌现”就觉得玄学。其实放到工程场景，涌现就是：**每个Agent只按照局部规则行动，但整体上呈现出一种协调的、有序的处理节奏。**单个Agent不认识也不关心其他Agent，把自己手里的活干完，把结果挂回黑板，继续认领下一个任务。全局看起来，任务像水流一样从上游到下游自动推进，瓶颈环节的Agent会被同类的多个实例分担，不忙的Agent会自动跑去帮忙。

没有什么“群体意识”，这就是个消息队列加多消费者模型，只不过消费者变成了AI驱动的Agent。

3. 把Agent调教成“工蜂”：分工、微指令与收敛机制

蜂群模式落地，最难的不是架构，而是Agent本身的设计。很多人都想把Agent做得越来越聪明——长记忆、复杂推理、多步骤计划。但放到蜂群里，我反而强烈建议：Agent越笨越专一越好。

3.1 专注Agent：一个Agent只干一件事

蜂群里单只蜜蜂只做一种动作：采蜜的采蜜、筑巢的筑巢、守卫的守卫。不会出现一只蜜蜂又采蜜又请假去参加蜂王选举的情况。

Agent也是一样。与其造一个“全能项目助理”，不如拆成几个专注Agent：

• 分类Agent：负责判断输入数据的类型和路由方向；
• 抽取Agent：负责从文本中提取结构化字段；
• 检索Agent：负责向量库查询和文档召回；
• 摘要Agent：负责把长文本压成短摘要；
• 质检Agent：负责看前一个Agent的输出是不是符合规范。

每个Agent只维护很小的一套指令和工具，prompt也就几百字，模型用中等参数量的就够了。好处非常明显：每个Agent的行为边界清晰，出错概率低，替换成本低，而且可以很方便地横向扩容——队列堵了就多起两个实例。

3.2 短记忆优于长记忆

蜂群工程里，我不建议给Agent挂特别复杂的历史记忆。原因很简单：记忆一旦长了，Agent就会“自作主张”地把过去和现在揉在一起，输出变得不可控。而且记忆模块本身会成为性能瓶颈。

更好的做法是：上下文保持轻量——只把当前任务的输入、任务级的基础信息、必要的参考数据传给Agent。跨任务的交互不靠Agent记忆，靠任务黑板里的操作记录。

换句话说，记忆不是存在Agent的脑子里，而是存在任务黑板上，需要时再读。

3.3 一个可以跑的蜂群骨架

假设场景是：每天进来一大批用户工单，需要做意图分类、紧急度判断、生成回复草稿。传统编排式是：

用户工单 → 意图分类Agent → 紧急度判断Agent → 回复草稿Agent → 输出

蜂群式则变成：

用户工单 → 写入任务黑板（类型：ticket_classify） ↓ 分类Agent A/B/C 并行认领，分别产出分类结果 ↓ 结果写回黑板，生成新的任务（类型：ticket_priority） ↓ 紧急度判断Agent 认领，处理后写回 ↓ 生成回复草稿Agent 认领，完成后写回最终结果

每个环节之间没有直接调用关系，只有任务黑板上的状态流转。优点在于——如果某类Agent处理速度不够快，加实例就行；如果某类Agent改版，新版本只认领新任务，旧任务还是由旧实例处理完，平滑升级。

3.4 收敛与防震荡

蜂群模式的隐患之一就是“没人管会乱”——多个Agent为了同一件事互相覆盖写、来回处理。需要两个机制兜底：

一是幂等性。任务处理函数必须是幂等的，同样的输入重复执行N次，结果一致。这样即使两个Agent同时抢了同一任务，后写的覆盖也没问题。

二是访问控制。任务状态从“待处理”改为“处理中”时，必须是一个原子操作。我们用数据库的行级锁来实现，伪代码大致是：

UPDATE tasks SET status = 'processing', claimer = :agent_id WHERE id = :task_id AND status = 'pending'

如果更新影响的行数为0，说明已经被别人抢走了，这个Agent就放弃，继续找下一个任务。

4. 协调层不是消失了，而是变薄了

蜂群模式不是“无政府模式”，它只是把厚厚的编排逻辑压扁成了几块薄薄的协调机制。这些机制就像蜂箱里的隔板，感觉不到存在，但决定了蜂群乱不了。

4.1 调度器只做路由，不做指挥

编排式系统里的调度器是老板，告诉每个Agent做什么；蜂群模式里的调度器是路由表，只告诉“这类任务该被谁认领”，具体谁认领、怎么认领，它不管。

我习惯把调度器简化成一个匹配函数：任务类型 → 具备该技能标签的一组Agent类型。比如任务类型是“文本摘要”，只有带上summarizer标签的Agent能认领。这个匹配逻辑可以写在配置里，也可以用一个大模型来做——不过建议白天用规则，省钱又不容易出幺蛾子。

4.2 结果判优：别怕重复，怕的是没有共识

蜂群模式下，同一种任务经常被多个Agent同时处理，生成多个候选结果。这时候需要“质量仲裁”机制，常见的做法有两种：

• 投票式：N个Agent输出，取多数或中位数；
• 加权式：每个Agent自报置信度，乘以历史准确率作为加权权重，加总后取最优。

对于生成类任务（比如文案），投票不太合适，我比较喜欢用“战胜式”——让一个评审Agent对比候选结果，挑出最优的，剩下的留档。这样多花的推理成本换来的是结果稳定性，值。

4.3 可观测性：蜂群模式调试的核心

蜂群模式的排障比编排式更麻烦——你不知道任务是不是被某只“迷路的蜜蜂”带偏了。所以系统在设计之初就要埋好三点观测基础：

1. 每条黑板记录都要有完整的操作日志：谁、何时、读取了什么、写回了什么；
2. 每个Agent要有独立的运行指标：处理时长、成功率、平均尝试次数；
3. 任务要有全链路的追踪ID：从进黑板到最终输出，一条线串起来。

没有这三样，蜂群出问题的时候，你只能站在黑板前面干瞪眼。

5. 蜂群模式的适用边界

说了一大堆蜂群的好处，但我也要泼盆冷水：它不适用于所有场景。盲目蜂群化，效果可能比编排式更糟。

5.1 适合蜂群的场景

• 任务并行度高的场景：一批数据要切分成很多子任务，子任务之间互相独立。比如批量文档处理、大批量数据清洗、商品信息抽取。
• 容忍一定重复/容错性高的场景：个别任务失败，自动重试或者放弃，不影响全局。比如日志分类、工单初筛。
• 任务链路短、流程简单的场景：单任务的执行可能只有2~3步，不需要复杂的全局规划。

5.2 不要用蜂群的场景

• 强上下文依赖的长链条任务：每一步的结果都依赖上一步的完整上下文，比如生成一份包含前后呼应的长篇报告。蜂群模式下上下文太容易支离破碎，不如单Agent加流程控制。
• 强时序约束：任务必须按照严格顺序执行，比如必须先审批后付款。蜂群模式难以保证严格的先后顺序。
• 成本敏感且任务量少的场景：蜂群需要多个Agent实例并行运转，对小批量任务来说不划算，编排式更省。

5.3 演进路径：别推翻重来，先局部放养

如果你现在有一套编排式的多Agent系统在跑，我的建议是：**别急着推倒重来，先找一条最容易并行化的链路，改造成蜂群试点。**比如原来“串行执行多个独立维度的分析”，把拆分成几个独立任务丢进黑板，让几个Agent并行处理，再看收益。等好处验证清楚了，再逐步扩大范围。

6. 对方框里的个人实践体会

我自己踩过的最大坑是：一开始把蜂群模式想得太浪漫了，以为Agent会自动“涌现”出精细配合，结果上线第一天就出现系统性重复——同一个任务被三个Agent抢了，生成了三份结果，评审Agent判半天。后来加了行级锁、幂等控制、缓存去重，才稳定下来。

现在我的原则是：**蜂群架构的价值，不在于让Agent更聪明，而是让整体系统更皮实。**单个Agent跪了，其他Agent还在干活，任务从整体上还能收敛。这在KPI上是隐性收益，但在生产环境中是实实在在的救命稻草。

最后分享一个小心得：在设计蜂群的时候，试着用“丢一个Agent到迷雾里”的心态来做故障测试——拔掉任意单个Agent的连接，看看系统能不能自己把任务绕过去。如果每次都能绕过去，那你这套蜂群算是站稳了。