一、为什么不能凭感觉定数量？

多一个Agent多一份混乱

每个Agent都需要独立的状态管理、记忆维护和推理循环。Agent之间还需要协调通信、避免冲突。每增加一个Agent，系统整体复杂度呈指数级上升，而非线性。许多项目失败，不是因为Agent太少，而是因为Agent太多——互相干扰、资源争抢、状态不一致。

少一个Agent则无人兜底

反过来，Agent数量不足会导致某个Agent承担过多职责，推理上下文过长，状态臃肿，错误率飙升。一个既要理解用户意图、又要查询数据库、还要生成报告、最后发送邮件的Agent，大概率每项都做不好。数量不是目标，匹配才是。

二、任务依赖图：决定Agent数量的唯一地图

拆解到“原子任务”

任务依赖图的第一步，是将用户目标拆解为不可再分的原子任务。例如“撰写季度经营分析报告”可拆为：提取销售数据、提取成本数据、计算利润率、生成图表、撰写文字摘要、检查合规、发送邮件。每个原子任务都应具备清晰的输入、输出和成功标准。

标注依赖关系

原子任务之间不是孤立的。计算利润率依赖销售和成本数据都已提取；生成图表依赖计算完成；撰写摘要依赖图表生成。依赖关系决定了执行顺序，也决定了哪些任务可以并行，哪些必须串行。这张图就是Agent设计的蓝图——每一个节点或紧密相关的节点簇，都可能对应一个Agent。

三、并行与串行：Agent数量的拓扑决定论

并行节点可共享Agent

如果多个原子任务互不依赖且类型相似，比如从三个不同数据库提取数据，可以由同一个Agent通过并发调用完成。此时一个Agent对应多个并行节点，避免了重复造轮子。但前提是Agent的上下文能清晰区分不同任务的状态，不致混淆。

串行长链可拆分Agent

如果一条依赖链很长，且前后任务性质差异大，就应该拆分为多个Agent。例如，数据提取Agent只负责获取原始数据，分析Agent只负责计算，报告Agent只负责生成。每个Agent专注于自己的环节，推理上下文短而精，错误率更低，也更容易调试和优化。任务依赖图的拓扑结构，天然指明了拆分的边界。

四、依赖图的动态变化与Agent弹性伸缩

不同用户目标对应不同子图

一个客服Agent在处理“查询订单”和“投诉处理”时，任务依赖图完全不同。前者只需要订单查询+状态反馈，后者涉及工单创建、升级流程、赔偿计算等复杂依赖。固定数量的Agent无法适配动态变化的子图。正确做法是按需实例化——根据当前任务依赖图，动态决定启动哪些Agent以及各启动多少个实例。

高峰期与常态的扩容策略

当任务依赖图中某些节点成为瓶颈（比如大量并发查询请求），可以增加该节点对应Agent的实例数，而非增加Agent种类。运维体系需要支持基于依赖图的弹性伸缩，而非简单地整体扩容。这种精细化的资源调配，只有在以任务依赖图为设计原点时才能实现。

• 实战原则：从依赖图到Agent清单

三个设计检验标准

如何检验Agent数量是否合理？第一，是否每个Agent都有清晰且唯一的职责边界，对应依赖图中的一个连通子图？第二，Agent之间的通信是否可以简化为任务依赖图中已定义的输入输出关系，没有额外隐式依赖？第三，单个Agent的推理上下文长度是否可控（通常不超过对应子图的规模）？如果三个答案都是肯定的，数量就是合理的。

进化而非一次性设计

任务依赖图不是一成不变的。新场景出现时，原有图可能不再最优。建议从最简依赖图出发，先部署少量Agent，在生产环境中观察哪些节点频繁出错或超时，再逐步拆分或合并。Agent数量不是设计稿上的固定数字，而是随着任务依赖图演进持续优化的结果。记住：一张清晰的图，胜过一百次拍脑袋的决策。