Multi-Agent 研究一 : 概念&设计实现方向分享Multi-Agent 科普分享, 对主流的Multi-Age

Multi-Agent 研究背景

当下项目组在基于 Agent 思想在行应用层服务开发，使用 LLM 能力为用户提供上层服务，目前市面上 Agent 框架越来越多, 其中最有名的当属 langchain。

原始文章 : lilianweng.github.io/posts/2023-…

Lilian OpenAI AI Safety 负责人推出 Agent 设计分享

国内翻译 : mp.weixin.qq.com/s/Jb8HBbaKY…

论文支撑

MRKL Systems A modular, neuro-symbolic architecture that combines large language models, external knowledge sources and discrete reasoning

22-05, 核心阐述大模型如何调用工具的设计思想 - 此时还无工具调用支持

A Survey on Large Language Model based Autonomous Agents

23-08 Agent 设计的基础框架的全方位调查 - 国内第一篇 Agent 调查论文

持续性模型调查 github.com/Paitesanshi…

当我们对 Agent 使用有了一定理解和积累后, 我们发现单一 Agent 总会有一些局限性, 我们为了让某个 Agent 更专业, 会设定他们的 Prompt, 基于这样的场景, 我们无法很好的去处理一些复杂的问题.

举个例子, 我们需要实现一个可以运行的数据分析项目, 要完成质量好的话, 我们就至少需要开发&测试这两个 Agent, 单一 Agent 则无法很好的实现多角色串用.

基于这个局限性, 前沿的实验室输出了很多 Multi-Agent 的设计论文, 基于这个部分, 目前也出现了很多全新的 Multi-Agent 框架, 例如 MetaGPT, AutoGen, XAgents 等, 当然 Multi-Agent 的框架帮支持我们处理一些复杂的问题, 但也一定程度带来了更多的成本.

Multi-Agent 是什么

当要开始学习 Multi-Agent 后, 我们问了 ChatGPT, 什么是 Multi-Agent

以下是 ChatGPT 给我们的回答

"Multi Agent"（多智能体）是一个涉及到多个自主智能体（agents）的概念，这些智能体能够在某些环境中独立地或协作地工作。在计算机科学和人工智能领域，这通常指的是一群能够交互、协作、竞争或者彼此学习的智能体。这些智能体可能是软件（如虚拟机器人、算法或模型）或硬件（如机器人）。

多智能体系统（Multi-Agent Systems, MAS）具有以下特点：

自治性（Autonomy） ：每个智能体都能够自主控制其行为和状态。

本地视角（Local Views） ：每个智能体只能获得部分环境信息。

去中心化（Decentralization） ：没有一个单一的控制智能体控制整个系统。

协作与竞争（Cooperation and Competition） ：智能体可以相互合作以达成共同目标，也可以为了自己的利益与其他智能体竞争。

多智能体系统在多个领域都有应用，例如在自动化控制、社会模拟、资源管理和电子商务中。这些系统的设计和实现涉及到复杂的交互和协调机制，以及对智能体自身决策能力的研究。

目前 Multi-Agent 的目的是明确的(解决复杂问题), 但还没有出现一个行业标准的实现思想, 各家都是基于自己的论文思想设计出的 Multi-Agent 的实现

AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation Framework

Multi-Agent Systems 章节

Multi-Agent 开源实现对比

资料 zhuanlan.zhihu.com/p/660045220

作品名称(出品方)	开源地址	特点
AutoGen (微软)	github.com/microsoft/a…	支持人机交互, 多 Agent 并行协作
MetaGPT (深度赋智)	github.com/geekan/Meta…	内置(互联网公司类)Agent, 可自定制更像产品级服务, 也开始支持人机介入
AgentVerse (面壁 & 清华)	github.com/OpenBMB/Age…	自定义 Agent & 协作流程(配置), 由 AgentVerse 驱动
Agents (波形智能)	github.com/aiwaves-cn/…	和 AgentVerse 概念类似, 但支持人类参与其中
XAgent(面壁 & 清华)	github.com/OpenBMB/XAg…	内置的 Agent 协作流, 内置海量工具服务器

开源实现的思路

基础要求

Agent 的输入和输出是在彼此之间流动或者共享的.
Agent 之间的协同是需要有规则驱动的
Agent 结束是有条件的

- 最大执行轮数
- 明确定义的终止消息

实现方向

用户可以自定义参与的Agent, 人类也可以是是一个 Agent (主流)
定义好 Agent 分工, 用户直接使用.

初步结论

国内做的产品更类似为产品服务, 虽然核心概念都基本一致, 但产品使用上都有自己的定制化规则(配置解析器), 同时再适度捆绑下自己的产品"矩阵", 导致框架能力不强
AutoGen 从目前表现的极强扩展和定制能力, 有潜力成长为 Multi-Agent 的标杆性框架, 也是当下学习和实现的主要参考方向.

Multi-Agent 协作实现方向

从设计思想来说, 首先我们一定会聚合一批 Agent, 其次需要让这批 Agent 开始合理协作. 合理协作的实现方式目前有以下几种方向 : 前置 LLM , 规则 SOP, 后置汇总.

一、 SOP 驱动 Agent - 代表 MetaGPT

MetaGPT 利用几个核心概念来组成自己的协作流

Envrionment : Agent 观察&发布重要消息的公共存储空间

- add_role 的时候, role 中去关联这个 Env

Observe : Agent 从 Env 中观察到对自己重要的消息, 并开始思考和可能行动
Action : Agent 执行动作, 并发布消息到 Env 中.

docs.deepwisdom.ai/zhcn/guide/…

基于这样的基本设定, 用户可以自定义 Agent 所需要观察 Action 所产生的消息, 以及产生新的 Action 消息并发布出去, 基于此, 多个 Agent 之间就可以相互协作

二、LLM 驱动 Agent - 代表 AutoGen

AutoGen GroupChat 提供了 auto(LLM 选择), manual(手动), random(随机), round_robin(轮询) 四种协作流程, 其默认为 auto

microsoft.github.io/autogen/doc…

其 auto 的实现原理为, GroupChat 会发起 LLM 问询

其 Prompt 和 Message 设定为以下代码片段可见 : 附录 - Agent LLM 选择逻辑

可以看出 GroupChat 会将自己假装为角色扮演游戏, 并按照历史消息和当前所有的 Agent 名称, 让 LLM 判断由哪个 Agent 进行下一位执行.

三、 Agent 并行计算, LLM 汇总 - 代表 XAgents

XAgents 利用了任务 规划, 分发, 执行, 提交, 修正 的链路, 利用提交和修正 Agent 来完成后置汇总和判断下一步执行结果

www.bilibili.com/video/BV1BN…

开源实现真实场景推理

看了目前主流的实现思路, 再回过来看我们真实生活中多人团队是如何协作, 是否现在我们的实现还有优化的空间.

(一) 主流现状 (各成员能力层次不齐)

大部分人无法判断问题谁来处理, 遇到问题需要团队负责人来安排谁来处理这个问题

目前 Multi-Agent 的实现基本都是类似于此种, 外部问题由入口 Agent 来分发, 入口 Agent 能了解全局(所有 Agent) 去驱动协作

eg : MetaGPT 的 BossRequirement Message, AutoGen 的 ChatGroupManger, XAgents 的 PlanAgent.

优点 : 对团队成员综合能力要求偏低, 更加适配当下 LLM 自身能力

缺点 : 沟通成本较高, 处理的效率偏低

(二) 理想场景 (各成员能力较高)

清楚问题谁来处理, 会直接找那个人去处理.

目前没有哪家的实现是基于这个的, 这要求 Agent 身份定义是明确且彼此之间能够相互了解, 并能驱动其他Agent 去解决问题, 估计也是各家考虑到 目前的 Agent(LLM) 整体能力(角色设定, 上下文记忆, 推理反思能力)有限, 还无法形成一个全能的人去做协同

优点 : 沟通成本较低, 处理的效率偏高

缺点 : 对成员能力要求较高, 当下 LLM 能力还不足以完全达到这个能力

Multi-Agent 研究 - 结论

从协作设计实现上来说, 我更倾向选择 LLM 驱动的 Multi-Agent 设计方向, 减少工程化的侵入, 其原因如下

LLM 能力在成长, 随着时间的推移, 现在的瓶颈可能会被突破, 而 SOP 驱动是工程化的, 是无法随着时间去成长的.
LLM 驱动下的 Agent 协同是动态的, 可以按照实际的问题进行路由

扩展 - Multi-Agent 自研思考

设想一下, 如果我们需要自己实现一个 Multi-Agent 的框架, 我们可以拆解下, 我们至少需要实现哪些 Feature, 可选实现哪些 Feature.

必备要素(基础)

Agent - 单一 Agent 的能力增强
团队 - 让一群 Agent(人) 知道周边有哪些 Agent(人)
协作 - 可定制化的协作流, 可以是 LLM, 可以是 SOP
记忆 - 团队的协作数据流转需要有共享记忆存放

可选要素(完善)

提高执行效率和预期

任意单一 Agent 了解周边, 能自主驱动周边
Agent 的并发执行
人机的调整输入, 支持反复修正目标.
长期有效记忆的保留.

数据(消息和记忆)的安全性

数据严格控制, Agent 外发数据的脱敏以及可控分发

附录

AutoGen 学习资料

AutoGen 理论&介绍资料

介绍类

Talk | PSU助理教授吴清云：AutoGen-用多智能体对话开启下一代大型语言模型应用_哔哩哔哩_bilibili

AutoGen 论文作者之一

微软 AutoGen 更智能的多 AI Agents 协作框架 | 动画演示框架核心 | Code 讲解 | Demo 演示_哔哩哔哩_bilibili

理论类

AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation Framework

Multi-agent Conversation Framework

AutoGen 核心 Agent 的图谱

协作原理展示

Agent LLM 选择逻辑

# groupchat.py
	def select_speaker_msg(self, agents: List[Agent]):
        """Return the message for selecting the next speaker."""
        return f"""You are in a role play game. The following roles are available:
{self._participant_roles(agents)}.

Read the following conversation.
Then select the next role from {[agent.name for agent in agents]} to play. Only return the role."""


        # auto speaker selection
        selector.update_system_message(self.select_speaker_msg(agents))
        final, name = selector.generate_oai_reply(
            self.messages
            + [
                {
                    "role": "system",
                    "content": f"Read the above conversation. Then select the next role from {[agent.name for agent in agents]} to play. Only return the role.",
                }
            ]
        )

Demo 学习

microsoft.github.io/autogen/doc…