多 Agent 任务分配，从人工分工到算法分工
三个 Agent 干五个子任务，谁来分。大部分项目的做法是写死，A 查数据，B 写报告，C 做校验，简单直接。任务一多、能力一重叠，写死的分工就开始别扭，有的 Agent 排队，有的闲着，还有的接了自己根本做不好的活。
先分清两种情况
一种是能力不重叠，各管一段，那写死最省心，出问题也好定位。另一种是任务数量变动，Agent 能力有交叉，人工分工的规则会越写越长，最后变成一坨 if-else。这时候才值得上算法分配。
判断标准很简单，分工规则能不能用三句话说清。说不清就该算。
贪心的坑
最直觉的做法是轮询或者按空闲度分配，谁闲给谁。问题在于它不看能力匹配，一个擅长写代码的 Agent 被派去做数据核对，产出质量差，还得返工。轮询适合同质 worker，Agent 恰恰是异质的。
好一点的做法是给每个 Agent 和每个子任务打上能力标签，算匹配分，取最高。这就是二分图匹配的思路，任务数和 Agent 数都不大时，匈牙利算法能给出全局最优解，代价是复杂度上来了，几十个任务还行，上千个就得换启发式。
让模型提议，让代码裁决
另一种实用路线是让模型做分配，毕竟它读得懂任务描述和 Agent 说明。风险也在这里，模型可能把任务派给不存在的 Agent，或者忽略硬约束，比如某个 Agent 没有某系统的权限。
做法和参数校验那篇一个路子。模型输出分配方案，代码校验三件事，Agent 是否真实存在，能力标签是否满足任务要求，依赖顺序是否合理。校验不过就把错误回给模型重来，超过次数就退回默认规则。模型的提议能覆盖大部分情况，代码的裁决兜住剩下那一小部分。
依赖顺序比分配更难
分配解决谁做，依赖解决什么时候做。三个子任务里有两个能并行，第三个要等前两个的结果，这就是个 DAG。拓扑排序决定执行顺序，同层并行，跨层串行。写死顺序的团队经常在这里翻车，前两步明明可以并行，硬是排队跑，总耗时翻倍。
并行还有个隐性成本，并发的 Agent 都在烧 token，都在调工具，瞬时成本和限流风险都上来了。并行度要设上限，不是越并行越好。
分配失败怎么办
必然有分不出去的任务，没有 Agent 具备相应能力。三种处理，降级给最接近的 Agent 并标注风险，转人工，或者直接告诉用户这个需求做不了。最差的做法是硬派给谁，然后让它在工具调用里反复失败，用户等着看一堆报错。
能力不足时明确说出来，这和会话隔离篇里拿不到身份就返回需要补充身份是同一种交互设计，给个明确回应，别假装能干。
结合系列
多 Agent 协作篇讲的是职责怎么切，这篇补上任务怎么派。黑板模式是另一种解法，不预先分配，让模块自己判断能不能推进，适合任务边界模糊的场景。参数校验篇的提议与裁决模式在这里复用一次，模型负责生成方案，代码负责守门。
