多 Agent 是怎么分派任务的？

多 Agent 系统里，任务分派是主管智能体的核心动作：把拆好的子任务，发给合适的专员去执行。它相当于公司里的派活——选人、交底、跟单，一步都不能省。分派做得好，整个系统像一支配合默契的队伍；做得糙，专员再多也是一盘散沙。

分派不靠喊话，靠工单

分派的载体是一张结构化工单：任务编号、目标描述、验收标准、输入材料的位置、边界约束。喊一嗓子式的分派（一句自然语言扔过去）省事但后患多——专员理解有偏差，产出不合预期，还说不清是派的问题还是做的问题。

工单的好处是可追溯：每张单谁派的、派给谁、什么时候派、结果如何，全部留痕，出了问题能顺着单子查。

派给谁：选人看两条

第一条是能力匹配：哪个专员的提示词、模型、工具配置和这个子任务最对口。检索类给带搜索工具的，写作类给文笔调教好的，别让写代码的去整理表格。第二条是负载均衡：优先派给手上没活的专员，忙不过来的排队或分给备用角色。

两条常常冲突——最对口的专员也最忙。简单场景按能力优先，等它空；吞吐量大的场景按负载优先，接受稍弱的匹配。选择标准取决于任务更怕慢还是更怕糙。

一次派活的消息里装什么

除了工单五要素，还有两样容易被漏。一是共同背景：这个子任务在整个工程里的位置，上下游是谁，让专员知道自己这块砖砌在墙上哪个位置。二是汇报要求：结果以什么格式交、交到哪、验收标准是什么。写清这两样，专员交回的东西才能无缝衔接。

上下文不足的，分派时还要附上从记忆库里召回的相关片段，腾讯元宝的团队协作模式里就有类似设计，让专员带着历史经验上场，而不是每次都两眼一抹黑。

四样东西一起塞进派活消息，缺一样就有一处对不上。

派完之后：跟单与改派

分派不等于甩手。主管要跟单：到了约定节点没回音就催，回执里带了例外情况就处理。更关键的是改派——专员反复失败或明确表示接不了，主管要果断换人：换备用专员、拆细任务再派、或者收回来自己做。

改派同样要有记录，原专员的失败原因写进工单备注，新专员不用踩同一个坑。判断一个分派系统成熟与否，就看改派路径是否畅通：只会在第一时间派、不会中途调整的，遇到复杂任务很快露怯。

派发的节奏

子任务之间没依赖的，可以一次性批量派出去并行执行，效率最高；有依赖的，按排期逐级派，前一道工序的产出作为后一道的输入。扣子（Coze）的编排模式里，这两种节奏分别对应并行分支和串行链路。

分派四步速查

• 写工单：目标、验收、材料、边界一个不少
• 选人：能力对口优先，负载过重就换人
• 交底：附上共同背景与汇报要求
• 跟单：节点催办，失败果断改派

复盘最近一次多角色协作，四步里缺了哪步，问题八成就出在哪。

延伸阅读：派活时的历史经验从哪来，见长期记忆是怎么写入的？摘要与向量化与记忆是怎么检索的？相关片段召回；接手人怎么获得完整背景，看Agent 之间的上下文怎么交接？；两个角色抢活怎么裁，参考两个 Agent 冲突了怎么处理？。

聊聊任务分派的常见疑问

• 派得太细和太粗哪个危害大？：太粗危害更大。太细只是协调开销多些，太粗会让专员上下文爆满、一步翻车整块重来。
• 专员可以拒绝接单吗？：可以，而且应该。允许专员在材料不足、超出能力范围时明确拒绝并说明原因，比硬着头皮交差对系统健康得多。
• 主管自己该不该参与执行？：尽量少碰。主管亲手做活会顾不上跟单，只有在所有专员都搞不定的小收尾上才值得亲自下场。