聊聊蚂蚁开源多Agent框架——muAgent

说实话，多Agent框架这两年确实火起来了，各家都在推自己的方案。蚂蚁的CodeFuse团队这次拿出的muAgent^[1]，核心思路其实很清晰——说白了就是想把Agent的SOP（标准操作程序）编排这件事，变得简单、省心。

多Agent要玩得转，关键在于Agent之间的交互链路，而这恰恰是实现SOP的命门。问题本质上就一个：上一个Agent吐出来的东西，怎么喂给下一个Agent当输入？这里面牵涉到LLM的输出控制、具体Action的执行，还有信息的解析与传递——每一个环节都是硬骨头。

架构

muAgent整合了一套相当齐全的组件：工具库、代码库、知识库，再加上沙盒环境。这意味着用户几乎能在任何领域场景下，快速搭建出复杂的多Agent交互应用。通过这个框架，处理那种多层次、多维度的复杂任务，就顺当多了。

这是它的架构图：

每个技术点拆开来看是这样的：

• Agent Base：
  提供了四种基础Agent类型——BaseAgent、ReactAgent、ExecutorAgent、SelectorAgent，基本覆盖了各种场景下的基础活动。

• Communication：
  靠Message和Parse Message来完成Agent之间的信息传递，同时还和Memory Manager配合，在Memory Pool里完成记忆管理。

• Prompt Manager：
  通过Role Handler、Doc/Tool Handler、Session Handler、Customized Handler这一套东西，自动把Agent的Prompt组装出来，而且是个性化的。

• Memory Manager：
  负责聊天历史记录的存储管理、信息压缩、记忆检索这些事儿，最后通过Memory Pool落地到数据库、本地存储或者向量数据库中。

• Component：
  用来构建Agent的各种生态组件——Retrieval、Tool、Action、Sandbox等。

• Customized Model：
  支持接入私有化的LLM和Embedding模型。

一个完整的多Agent生态需要什么能力？说到底，也就上面这几大块了。

Agent Base

在Agent层，这四种基础类型各有分工。对它们做一下Role设定，就能适配多种通用场景。所有的Action操作，都是由Agent来执行的。

• BaseAgent：
  基本功扎实，问答、工具使用、代码执行都拿得下。

• ReactAgent：
  标准的React流程——遇到问题不慌，按标准反应流程从容应对。

• ExecutorAgent：
  任务清单的顺序执行者。用户或者上一个Agent定了计划，它就排个队，挨个干。

• SelectorAgent：
  负责挑选——根据用户或上一个Agent的问题，选出最合适的Agent来响应需求。

和AutoGen横向对比一下的话，其实思路大差不差，但muAgent的粒度划分要更清晰。特别是Agent的编排，有专门的Agent来负责；而ReAct的功能也被单独抽出来作为一个独立Agent。初步来看，在ReAct的支持上，它的确比AutoGen更强一些。

Component

辅助生态组件这块做得更细致。和AutoGen不同的是，Sandbox支持隔离特性——这一点让整个辅助生态的能力更强大了。

Communication

多Agent的核心在于Agent之间的信息交互，所以Communication的实现必不可少。AutoGen是用结转逻辑来支持信息流转的，而CodeFuse则是通过独立的Communication组件来实现。从实现方式来看，CodeFuse的方案应该更强大一些——AutoGen那边主要靠一个summary_method方法就定义了。

不过重点来了：CodeFuse的Communication组件不仅仅是在做信息传递，它在整个信息流转过程中还参与了记忆管理、角色处理和Prompt组装，这实际上是把多Agent协作的关键环节都串起来了。

总结

之前对国内的Agent框架了解不多——因为本身也不多。从AutoGen入门多Agent，再回头看muAgent的实现，会发现一个有意思的点：多Agent的SOP在当前版本里更具体、更模块化了。话是这么说，底层思想还是一样的——关键的组成部件还是那几样东西。

所以归根结底，如何协调好LLM并引导它们输出预期的东西？本质就是把业务问题抽象出来，拆解成可执行的Prompt，让它们像处理业务问题一样精准执行。至于业务的编排和执行，由Agent来搞定，最后都落脚在LLM上。这条链路，才算真正打通了。