多智能体系统 vs 单一 Agent 怎么选?

这道题其实是在问，当你有多个LLM [[Agent]]一起干活的时候，跟只用一个大模型单打独斗相比，到底好在哪、难在哪。我先说基本概念。[[多智能体]]系统，说白了就是一群能自己拿主意、互相能说话聊天的智能体凑在一起干活。每个Agent独立决策，没有中央指挥官，但它们通过通信和协商分工，一起搞定一个Agent搞不定的复杂任务。

那在大模型背景下，为什么大家开始搞多个Agent协作呢？核心优势我觉得就三个。先看并行分解。单Agent处理复杂任务，要么串行一步步来，要么上下文越塞越满，容易爆。多Agent可以把大任务拆成子任务，比如一个Agent专门做规划，一个做执行，一个做验证，各干各的，效率高很多。再看深度专业化。单Agent再强也是通才，但多Agent可以给每个Agent定制角色，比如一个Agent只负责调用工具，另一个只负责记忆检索，这样每个Agent在自己那摊事上可以做到很精。还要看系统韧性。单Agent挂了就全挂了，多Agent里某个Agent出问题，任务可以动态重分配给别的Agent，系统不会完全瘫掉。

举个例子，像企业客服场景。传统做法是用一个[[RAG]]加一个LLM，用户问退款政策，模型去查知识库然后回复。但遇到复杂问题，比如订单异常同时涉及库存和价格，单Agent要么答不全要么上下文爆炸。多Agent怎么做？我见过一个架构：一个主管Agent先理解用户意图，然后派一个订单Agent查订单状态，一个库存Agent查库存，一个价格Agent查价格，最后汇总给回复Agent生成答案。每个Agent只专注自己那摊事，配合自然语言通信，整个流程清晰可控。

但落地的时候，挑战也很明显。首个坑是通信开销。Agent之间每说一句话都要调一次LLM，延迟和成本蹭蹭涨。所以实际落地得设计层级架构，比如Manager-Worker模式，主管Agent只跟几个Worker通信，Worker之间不直接对话，减少调用次数。再看一致性问题。每个Agent基于自己的上下文做决策，可能互相矛盾。比如订单Agent说已发货，库存Agent说缺货，这时候就要引入仲裁Agent或者投票机制来做冲突消解。最后是调试难。多Agent的调用链很长，出了问题不知道是规划错了还是执行错了。我上线前一定会做完整的日志追踪，把每个Agent的输入输出都记录下来，方便回溯。

还有一个容易被忽略的点，就是上下文碎片化。多个Agent对话历史加起来很容易超出上下文窗口，所以得设计摘要机制或者共享外部记忆。这个其实跟 [[GraphRAG]] 的思路有点像，通过图结构来管理多Agent的交互历史，避免信息丢失。

所以总的来说，我倾向于把多Agent看成一种架构模式，不是银弹。它特别适合任务可以自然拆解、各子任务需要不同专业能力的场景，比如客服、代码生成、游戏AI。但如果任务本身很简单，或者对延迟极度敏感，单Agent加 [[ReAct]] 反而更靠谱。我的取舍是：先看业务能不能拆，再看团队有没有能力做调试和监控，否则多Agent带来的复杂度可能比收益还大。