一、介绍
正如计算机发展的历史，从单机走向网络到现在已经相对成熟的分布式系统。AI的发展也在经历类似的过程，一个Agent即使再强大，仍然无法解决日渐复杂的系统问题。那么多个Agent出现并协作工作来解决实际问题就成为了一种可能。这和前面提到的，计算机的硬件在向深度发展遇到瓶颈后开始横向发展是一个道理。
但分布式也有不同的道路，早期的计算机网络都是直接使用物理机，而现在基本上云厂商都直接面向虚拟机了。在Agent的发展目前也有两个方向，一个是Claude Code的Agent Teams，它通过提供多个Agent在一个项目中并行工作来实现更强大的功能进而提高工作效率；另外一个是Kimi的多Agent Swarm方案，在大模型训练时提供了多个Agent并行工作。
其实大家只要简单思考一下，这个并不是多么新奇的功能，俗话说得好："一个好汉三个帮，一个篱笆三个桩"，"多生孩子好打架"，话粗理不粗。
二、Agent Teams
在实际的AI应用中，大量的Agent和SubAgent的交互，会导致过长的上下文，长也就罢了，但过多的Token意味着过多的Money，这就不友好了。而且传统的SubAgent间无法直接交流，导致这种Agent间的处理只是简单的独立任务的处理，无法进行正常的并行交互。
Agent Teams则引入了共享任务清单，通过一个主Agent管理多个子Agent，子Agent间可互相交互通信，但是它没有进行上下文的压缩，在将相关结果返回主Agent后，仍然存在着上下文过长的情况，而且Teams缺乏弹性扩容（看看和网络发展多么相似），其并行度仍然显得僵硬和没有弹性。
它类似于传统的现实世界中的初级管理，通过一个主Leader来管理多个成员，而成员间可以互相通信进行分工协作。它已经向着分布式的应用迈出了坚实的一大步。
三、Agent Swarm
Agent Swarm的蜂群模式，其实它可以分为理论上的完全分布式模式和实际的Kimi中的Swarm。怎么理解这个问题呢。如果从P2P中的节点发现可以更好理解，最初的P2P节点发现比如流言或洪泛算法可以说是完全分布式的。但后来发现它也有它的缺点，真正的实践应用中更广泛的使用的是类似Kademlia算法+超级节点这种以中心化为辅助的分布式结构（比如常见的迅雷、原来的电骡和现在的区块链网络技术等）。
但实际上Kimi中的Swarm的Leader（主Agent）功能更强大，它能动态进行并行任务的拆解和分配，多个并行任务可以进行协作交互，并将任务结果返回到主Agent。但反过，其离分布式AI也更远。
四、二者的区别和联系
Agent Teams只是类似于分布式网络中初级的多机协作系统，并行度也是固定的，无法进行动态的任务分解和管理。 而Agent Swarm则升级了一步，动态增强了SubAgent间的协作。它动态生成的多个SubAgent返回阶段性结果到主Agent，提高了并行速度和减少了Token应用。同时它还引入了动态并行技术（如Kimi中的PARL），可以实时的根据具体任务情况进行动态的并行任务处理扩展。
另外，Agent Teams需要用户进行各种复杂的安装和学习使用，成本较高，更适合专业开发人员，集成度相对较低。而Agent Swarm则自带虚拟机（类似进入了Docker容器阶段），直接就可以部署使用，集成度很高。这就可以比作最初的程序员使用文本编辑器写代码，再用各种编译、调试等工具进行处理。而后来的程序则可以直接使用IDE，一次全搞定。
Swarm和Teams都是对AI并行发展的一种有益的实践，就像分布式计算机技术发展一样，不到最后谁也不知道哪种是一种更优秀的结果。
五、应用场景
Agent Teams更适合于任务结构清晰、步骤明确，质量要求较高但是规模较小的情况。就可以通过任务列表的方式来进行任务的协作交流。它看上去更专业化。
而Agent Swarm更适合于较大规模的复杂任务，需要进行动态并行管理、持续跟进且并行调度的情况。可以说面对的任务问题越是开放性，则其越具有优势。
Agent Teams更像是一个现在已经可以被看清楚的实践，而Agent Swarm则更像是探索的实践。AI应用发展到现阶段，其实仍然场景还是很小。所以Agent Teams的应用可能会更合适一些，但随着应用场景越来越复杂，Agent Swarm会越来越有优势。
六、总结
AI在应用上走入并行或者说分布式开发，是一个必然的结果。不过，随着分布式的AI出现极有可能又会衍生出一系列的技术领域。这对开发者来说，很可能是件大好事。
对于每个开发者来说，所做的只有一件事，敞开胸怀，拥抱变化，接受新知识，迎接新挑战！