超越单兵作战：多智能体 Multi-Agent System (MAS)

汀、人工智能

于 2024-07-10 10:33:55 发布

阅读量84

点赞数 6

分类专栏： AI Agent 文章标签：人工智能 Agent 多智能体智能体 XAgents MetaGPT LangGraph

涉及博主原创类文章，未经博主许可不允许转载

本文链接：https://blog.csdn.net/sinat_39620217/article/details/140316883

版权

AI Agent 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

#AI是在帮助开发者还是取代他们？#

超越单兵作战：多智能体 Multi-Agent System (MAS)

Multi-Agent System 是指一个系统中有多个智能体同时工作的情况。在这样的系统中，每个智能体都具有一定程度的自主性，可以独立执行任务、做决定，并且能够与其他智能体进行交互，协作完成更复杂的任务或达成共同的目标。

多智能体系统是一种分布式人工智能（DAI）的重要分支，它将一个大而复杂的系统分解为多个小的、相互服务的系统单元（即智能体）。这些智能体通过相互通信、共享信息和资源，以及协作和竞争来共同实现系统的整体目标。

关键特性
- 自主性：智能体拥有控制自己行动和内部状态的能力，不必受到外部控制的强制。
- 局部视角：每个智能体只能获得有限的、局部的信息，而不是系统的全局信息。
- 分散性：控制和数据通常是分布在各个智能体中，而不是集中处理。协作：智能体可以相互协作，通过组合各自的能力和信息来解决问题。
- 互动交流：智能体之间可以通过某种形式的通信机制来共享信息、协调行动等。
协作模式
- 合作（Cooperation）在合作模式中，智能体相互协作，共同努力实现一个共同的目标或优化某项共享资源的利用。合作模式强调的是团队之间的协同工作和资源分享。
- 竞争（Competition）在竞争模式中，智能体之间相互竞争资源或优势地位，每个智能体的目标是通过优于其他智能体来实现自己的利益最大化。
- 混合模式（Coopetition）混合模式是合作与竞争的结合，这种模式下的智能体在某些情况下可能需要合作，而在其他情况下则表现出竞争的特征。这种模式非常适合复杂的环境和任务，智能体需要灵活选择合作或竞争以适应不断变化的环境和目标。比如：智能仓储系统的运输机器人，它们需要通过合作来避免碰撞、规划最佳路线，但在完成任务的优先次序上可能表现出竞争，尤其是在高需求时段处理紧急订单时
- 利己模式（Self-Interest）在利己模式中，智能体的设计和行为都是为了优先考虑并实现自己的利益或目标。这种模式下的智能体可能会与其他智能体进行交互，但这些交互主要是基于评估这些交互如何帮助它们达到自己的目标。比如：无人驾驶，只关心自己如何达到目的地，虽然客观上可能和其他车辆产生竞争行为（比如超车），但不产生竞争关系
应用领域

多智能体系统广泛应用于各种领域，如自动化控制系统、机器人、智慧交通、经济模型分析、社会动力学研究、网络游戏、分布式计算等。在这些系统中，智能体可以是物理存在的，比如机器人、无人机，也可以是虚拟的，比如软件代理/王者荣耀「绝悟」AI

更多比赛可参考：https://aiarena.tencent.com/

Honor of Kings AI Open Environment of Tencent(腾讯王者荣耀AI开放环境) :https://github.com/tencent-ailab/hok_env
基于pytorch框架用resnet101加GPT搭建AI玩王者荣耀 https://github.com/FengQuanLi/ResnetGPT

1.LLM 时代的 MAS

随着 LLM 的兴起，研究者们逐渐认识到 LLM 的优势及其局限性，那么综合多个不同功能的 LLM 的优点，共同实现一个目标的 Multi-Agent 系统便应运而生。这种协作式的 Multi-Agent 系统也是当前的主流方向。注意：下文提到的 Multi-Agent，也特指 LLM Based Multi-Agent

当前大部分的 Multi-Agent 框架的设计初衷都是希望通过多个 agent 的配合来解决更复杂的问题。那 Single-Agent 没办法处理复杂问题吗？什么样的问题需要 Multi-Agent 的架构来处理呢？

1.1 Single-Agent 如何处理复杂任务

在面对一个复杂的任务时，人类会将这个任务拆解为一个个的小任务，并将这些任务做一定的规划，来最终完成。Agent 也是同样的思路，不过在这个大方向上，也出现了很多不同的策略：

Chain of Thoughts (COT)
Chain of Thoughts
Self Consistency (COT-SC)
Tree of Thoughts (TOT)
Graph of Thoughts (GOT)
ReAct
Plan-and-execute

ReAct（Reason+Act）

https://arxiv.org/abs/2210.03629

https://www.promptingguide.ai/zh/techniques/react

eACT机制的核心在于将推理和行动紧密结合，使语言模型能够交替地产生推理路径（Thought）和文本动作（Action），以解决不同的语言推理和决策任务。具体来说，ReACT通过以下几个步骤实现这一目标：

推理路径生成：模型首先基于当前的环境或上下文生成推理路径（Thought），这些推理路径包含了对问题或任务的逐步分析和理解。
文本动作生成：在推理路径的指导下，模型生成文本动作（Action），这些动作可以是查询外部数据源、执行特定操作或生成最终答案等。
环境交互与反馈：文本动作被发送到外部环境或数据源，以获取新的观测值（Observation）。这些观测值用于更新模型的内部状态，并作为后续推理和行动的基础。
循环迭代：上述过程不断循环迭代，直到达到任务目标或满足某个终止条件

Plan-and-execute

https://arxiv.org/abs/2305.04091

大型语言模型（LLMs）在多种NLP任务中表现优异。为处理多步骤推理任务，零样本思维链（Zero-shot-CoT）通过添加“让我们一步一步思考”的提示来减少人工干预。但存在计算错误、遗漏步骤和语义误解等问题。“规划求解（PS）”提示策略，先规划任务为子任务，再逐步解决。为减少计算错误并提升推理步骤质量，进一步提出PS+提示，加入更详细指令。在GPT-3上的实验表明，该零样本提示策略在所有数据集上均大幅优于Zero-shot-CoT，与零样本思维编程（Zero-shot-Program-of-Thought）相当或更优，且在数学推理问题上接近8样本思维链提示的性能。

其他更多策略细节介绍参考：AI Agent技术的最新进展与改变世界的典型项目巡礼章节1.2.3 step-by-step

1.2 Single-Agent 的局限性

通过以上方式确实可以提升复杂任务的执行效果，但当复杂度继续升高时，仍然存在以下局限性：

单视角的缺陷从人类的认知科学已经知道，单个人的视角是有缺陷的，即使他是一个很理性的人并尝试以很理性的方式独立思考，就结果来说这个思考过程的结果仍然是不太靠谱的。人类是以群体的方式进化的，只有在群体讨论、相互检查、相互批判、一起理性推理才能够以一个比较好的准确率得到正确的推理结果。

那么 LLM 有单视角缺陷的问题吗？也是有的。虽然 LLM 可以扮演很多视角，但会随着 system prompt 或者前几轮的对话快速坍缩到某个具体的视角上，按照这个视角进行对答。进入到单视角之后，LLM 也一样有着单视角问题，即使像是 AutoGPT 要求进行自我批判之后，仍然也距离多视角辩论有差距。而 Multi-Agent 可以跳出这个限制，更加灵活的调用 LLM 已经学习到的其他视角来进行自我修正和推理。

效率低下当复杂度持续提升时，子任务的数量大幅增加，MAS 可以通过任务的拆解和分发，由不同的 Agent 来并行的执行子任务，效率可以显著提升。
对 Long Context Window 要求比较高当前大部分的 Single-Agent 框架（比如 AutoGPT），需要记住所有的历史信息，意味着在面临长历史的复杂任务时，对 Context Window 要求比较高。而在 MAS 中，每个 Agent 只需要关注与自己相关的信息即可，可以很大程度上降低对于记忆容量的要求。

1.3 MAS 的优势

鲁棒性和容错性由于多智能体系统的分布式特性，即使部分智能体发生故障或失效，系统其他部分仍然可以继续工作。这种冗余设计增加了系统的鲁棒性和容错能力。
灵活性和可扩展性智能体可以动态加入或离开系统，使得多智能体系统可以根据需要轻松地扩展或缩减。这种灵活性使系统能够适应不同规模的任务和环境变化。
更好的效果、更低的成本对工具 / 职责进行分组可以取得更好的效果。与需要从几十种工具中进行选择相比，从更少的工具集中选取的成功率更高。同时将职责拆分后，每个代理甚至可以使用单独的微调 LLM（比如注重逻辑推理的 Agent 使用 GPT4，用于写作的 Agent 使用开源免费模型），从而达到更好的效果和更低的成本。

相关论文：《ChatEval: Towards Better LLM-based Evaluators through Multi-Agent Debate》

文本评估历来面临重大挑战，经常需要大量的人力和时间成本。随着大型语言模型（LLMs）的出现，研究人员已探索将LLMs作为人类评估的替代品的可能性。虽然这些基于单一代理的方法显示出潜力，但实验结果表明，需要进一步的发展才能缩小它们当前的有效性与人类评估质量之间的差距。认识到人类评估过程的最佳实践通常涉及多个评估人员协作进行评估，我们采用了一种多代理辩论框架，超越了单一的代理提示策略。基于多代理的方法使得一组LLMs能够与其智能对等体协同工作，利用其不同的能力和专业知识来提高处理复杂任务的效率和有效性。在本文中，我们构建了一个名为ChatEval的多代理裁判团队，该团队能够自主讨论和评估不同模型在开放式问题和传统自然语言生成（NLG）任务中生成响应的质量。我们的分析表明，ChatEval超越了简单的文本评分，提供了一种模仿人类的评估过程，以实现可靠的评估。

2. Multi-Agent 框架

2.1AutoGen

代码仓库：https://github.com/microsoft/autogen
相关论文：https://arxiv.org/abs/2308.08155
AutoGen 简介

AutoGen 是微软开发的一个对话式 multi-agent 框架，通过通用的多智能体对话框架支持下一代 LLM 应用程序。它提供可定制和可对话的代理，这些代理集成 LLM、Tools、Human。通过在多个有能力的代理之间自动聊天，可以很容易地让他们自主或在人工反馈下集体执行任务，包括需要通过代码使用工具的任务。

下图显示了 AutoGen 中的内置代理：

AssistantAgent：默认使用 LLM、不需要人工输入、不能执行代码。它可以编写 Python 代码供 UserProxyAgent 在收到消息（通常是需要解决的任务的描述）时执行。它还可以接收执行结果并提出更正或错误修复建议。可以通过传递新的系统消息来更改其行为。
UserProxyAgent：人类的代理，默认情况下，在每个交互回合中征求人类输入作为代理的回复，并且还具有执行代码和调用函数或工具的能力。当它检测到接收到的消息中的可执行代码块并且未提供人工用户输入时，它会自动触发代码执行。

代码示例：


import os

from autogen import AssistantAgent, UserProxyAgent

from autogen.coding import DockerCommandLineCodeExecutor



config_list = [{"model": "gpt-4", "api_key": os.environ["OPENAI_API_KEY"]}]



#create an AssistantAgent instance named "assistant" with the LLM configuration.

assistant = AssistantAgent(name="assistant", llm_config={"config_list": config_list})



#create a UserProxyAgent instance named "user_proxy" with code execution on docker.

code_executor = DockerCommandLineCodeExecutor()

user_proxy = UserProxyAgent(name="user_proxy", code_execution_config={"executor": code_executor})



#the assistant receives a message from the user, which contains the task description

user_proxy.initiate_chat(

    assistant,

    message="""What date is today? Which big tech stock has the largest year-to-date gain this year? How much is the gain?""",

)

执行逻辑

对话模式

https://microsoft.github.io/autogen/docs/tutorial/conversation-patterns

Teachable Agents - 可「学习」的 Agent

https://microsoft.github.io/autogen/blog/2023/10/26/TeachableAgent/

EcoAssistant - 更准确、更经济地使用 Agent

https://microsoft.github.io/autogen/blog/2023/11/09/EcoAssistant

AutoBuild

根据问题动态生成一个 Multi-Agent Group

https://microsoft.github.io/autogen/blog/2023/11/26/Agent-AutoBuild

2.2 LangGraph

代码仓库：https://github.com/langchain-ai/langgraphjs

LangGraph 是一套在 LangChain 框架之上的一套开发组件，可以使用 LCEL（LangChain Expression Language）轻松的开发带有状态的，可控循环流程的 LLM 应用，例如 Multi-Agent 应用。在这之前，我们先简单的了解下 LangChain

LangChain
https://python.langchain.com/v0.2/docs/introduction/

LangChain 是一个框架，用于开发由大型语言模型提供支持的应用程序，它简化应用程序生命周期的每个阶段：开发：使用 LangChain 的开源构建块和组件构建应用程序。使用第三方集成和模板开始运行生产化：使用 LangSmith 检查、监控和评估您的链条，以便您可以自信地持续优化和部署部署：使用 LangServe 将任何 Chain 换为 API

一个最简单的 Agent


from langchain_core.tools import tool

from langchain import hub

from langchain.agents import AgentExecutor, create_tool_calling_agent

from langchain_openai import ChatOpenAI



@tool

def multiply(first_int: int, second_int: int) -> int:

    """Multiply two integers together."""

    return first_int * second_int





@tool

def add(first_int: int, second_int: int) -> int:

    "Add two integers."

    return first_int + second_int





@tool

def exponentiate(base: int, exponent: int) -> int:

    "Exponentiate the base to the exponent power."

    return base**exponent





tools = [multiply, add, exponentiate]

prompt = hub.pull("hwchase17/openai-tools-agent")

llm = ChatOpenAI(model="gpt-3.5-turbo-0125")



agent = create_tool_calling_agent(llm, tools, prompt)

agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

agent_executor.invoke(

    {

        "input": "Take 3 to the fifth power and multiply that by the sum of twelve and three, then square the whole result"

    }

)

2.2.1 LangGraph 产生原因

https://blog.langchain.dev/langgraph/

LangChain 的一大优势是可以轻松创建自定义链。不过，到目前为止，我们还缺少一种方法，可以轻松地将循环引入这些链中。实际上，这些链是有向无环图（DAG），大多数数据协调框架也是如此。当人们创建更复杂的 LLM 应用程序时（比如 Agent），我们经常看到的一种模式是在运行时引入循环，比如在循环中推理下一步、执行下一步，直到达到目标。在 LangChain 中，这种循环是通过 AgentExecutor 来完成的，但 AgentExecutor 太简单、无法做更多定制，这也是 LangGraph 产生的原因。

2.2.2 LangGraph 核心概念

LangGraph 的核心是将代理工作流建模为状态机。可以使用三个关键组件定义代理的行为：State、Node、Edge。整个流程简单概括就是：Node 完成工作并更新 State，Edge 来决定下一步该做什么。State表示应用程序当前快照的共享数据结构。它可以是任何数据类型，但通常是一个 Dic/Map


from typing import TypedDict, Annotated



def add_messages(left: list, right: list):

    """Add-don't-overwrite."""

    return left + right



class AgentState(TypedDict):

    #The `add_messages` function within the annotation defines

    #*how* updates should be merged into the state.

    messages: Annotated[list, add_messages]

NodeNode

NodeNode 可以是一个函数或者 LCEL runnable，该函数 / LCEL 接受 State 作为输入，并输出一个更新的 State。你可以通过以下方式添加一个节点：


from langgraph.graph import StateGraph, END



def call_model(state: AgentState):

    messages = state['messages']

    response = model.invoke(messages)

    #We return a list, because this will get added to the existing list

    return {"messages": [response]}

  

#Define a new graph

workflow = StateGraph(AgentState)



#Define the two nodes we will cycle between

workflow.add_node("agent", call_model)

workflow.add_node("tools", tool_node)



#This means that this node is the first one called

workflow.set_entry_point("agent")

EdgeEdge 定义逻辑的路由方式以及停止的方式


def should_continue(state: AgentState) -> Literal["tools", "__end__"]:

    messages = state['messages']

    last_message = messages[-1]

    #If the LLM makes a tool call, then we route to the "tools" node

    if last_message.tool_calls:

        return "tools"

    #Otherwise, we stop (reply to the user)

    return "__end__"

  

workflow.add_conditional_edges(

    "agent",

    should_continue,

)

workflow.add_edge('tool', 'agent')



app = workflow.compile()

使用 LangGraph 构建一个 MAS

https://langchain-ai.github.io/langgraph/tutorials/multi_agent/multi-agent-collaboration/

2.3 LangSmith

LangSmith 是一个用于构建生产级 LLM 应用程序的平台。它允许您调试、测试、评估和监控基于任何 LLM 框架构建的链和智能代理，并无缝集成 LangChain。以下是它的几个核心能力：

调试：

测评：

监控：

https://www.youtube.com/watch?v=jx7xuHlfsEQ&list=PLfaIDFEXuae2CjNiTeqXG5r8n9rld9qQu&index=2&ab_channel=LangChain

2.4 MetaGPT

代码仓库：https://github.com/geekan/MetaGPT
相关论文：https://arxiv.org/abs/2308.00352

特点：SOP（Standard Operating Procedure）驱动，SOP 理念贯穿整个框架

通过广泛的协作实践，人类在各个领域制定了被广泛接受的 SOP。这些 SOP 在支持任务分解和有效协调方面发挥着至关重要的作用。SOP 概述了每个团队成员的责任，并建立了中间产出的标准。MetaGPT 将人类社会中的 SOP 理念运用到框架中，为不同的代理分配不同的角色，有效地将复杂任务分解为涉及多个代理协同工作的子任务。并且要求代理生成结构化输出，如高质量的需求文档、设计工件、流程图和接口规范。中间结构化输出的使用大大提高了目标代码生成的成功率。

MetaGPT 使用 Shared Message Pool（共享信息池）来完成通信。每个 Agent 不仅可以在池中发布自己的结构化信息，还可以透明地访问来自其他 Agent 的信息。为了避免信息超载及无关信息而分心，MetaGPT 使用消息发布 - 订阅机制来获取 Agent 感兴趣的消息。

为了提升代码的可执行性，MetaGPT 引入了一种可执行的反馈机制，对代码进行迭代改进。工程师能利用自身的历史执行和调试内存，不断改进代码。这种迭代测试过程一直持续到测试通过或达到最多 3 次重试为止。

代码示意

定义 Action


class SimpleWriteCode(Action):



    PROMPT_TEMPLATE = 

    Write a python function that can {instruction} and provide two runnnable test cases.

    Return python your_code_here `with NO other texts,

    your code:

    



    def __init__(self, name="SimpleWriteCode", context=None, llm=None):

        super().__init__(name, context, llm)



    async def run(self, instruction: str):



        prompt = self.PROMPT_TEMPLATE.format(instruction=instruction)



        rsp = await self._aask(prompt)



        code_text = parse_code(rsp)



        return code_text

定义 Role

a.绑定 Action
b.watch 其他输入（来自用户 or 其他 agent）


from metagpt.roles import Role



class SimpleCoder(Role):

    def __init__(

        self,

        name: str = "Alice",

        profile: str = "SimpleCoder",

        **kwargs,

    ):

        super().__init__(name, profile, **kwargs)

        self._watch([UserRequirement])

        self._init_actions([SimpleWriteCode])



    async def _act(self) -> Message:

        logger.info(f"{self._setting}: 准备 {self._rc.todo}")

        todo = self._rc.todo



        msg = self.get_memories(k=1)[0]  #找到最相似的 k 条消息



        code_text = await SimpleWriteCode().run(msg.content)

        msg = Message(content=code_text, role=self.profile, cause_by=todo)



        return msg

3.创建团队、雇佣角色并执行任务


import asyncio

import typer

from metagpt.logs import logger

from metagpt.team import Team

app = typer.Typer()



@app.command()

def main(

    idea: str = typer.Argument(..., help="write a function that calculates the product of a list"),

    investment: float = typer.Option(default=3.0, help="Dollar amount to invest in the AI company."),

    n_round: int = typer.Option(default=5, help="Number of rounds for the simulation."),

):

    logger.info(idea)



    team = Team()

    team.hire(

        [

            SimpleCoder(),

            SimpleTester(),

            SimpleReviewer(),

        ]

    )



    team.invest(investment=investment)

    team.run_project(idea)

    await team.run(n_round=n_round)



if __name__ == '__main__':

    app()

支持人类介入


team.hire(

    [

        SimpleCoder(),

        SimpleTester(),

        # SimpleReviewer(), # 原始行

        SimpleReviewer(is_human=True), # 更改为这一行

    ]

)

2.5 XAgents

XAgents 是一种新的 Multi-Agent 框架, 由清华大学和面壁智能联合提出。它旨在提供一种更可控、更具扩展性的 Multi-Agent 系统, 相比于其他框架如 AutoGPT 和 MetaGPT 有更好的性能。XAgents 采用了外循环规划任务、内循环执行 subtask 的新机制, 实现了自主和可控的平衡。

核心设计理念：

双循环机制
- 外循环用于高层任务管理，内循环用于低层任务执行。外环流程使代理能够识别总体任务并将其分割为更小、更可操作的组件。这种层次划分反映了人类在应对复杂挑战时所采用的自然认知过程。
ToolServer：：工具执行 Dockera.
- 与传统系统不同，XAgent 使用 ToolServer 作为执行引擎来支持这些属性。它在 Docker 环境中运行，为工具执行提供隔离且安全的空间。这种隔离确保该工具执行的操作不会危及主系统的稳定性或安全性。
- 这种设计带来了很多好处：（1）安全性：在 Docker 容器内运行工具可以保护主系统免受潜在危害； (2) 模块化：将代理规划和工具执行的角色分开，可以使代码更易于管理，更容易调试，并且具有可扩展性； (3) 效率：系统可以根据需求和使用模式启动、停止和重新启动节点，从而实现资源的最佳利用。借助 ToolServer，XAgent 将 LLM 决策过程的复杂性与工具执行分离开来。
函数调用：XAgent 的通用语言
- 结构化的通信模式对于代理系统的稳健性至关重要。因此，我们采用 OpenAI 的函数调用作为 XAgent 的通用语言。这带来了几个关键属性： (1) 结构化通信：函数调用本质上以明确说明所需和期望的方式进行格式化。这种结构可以最大限度地减少误解和潜在错误； (2) 统一框架：不同的任务，无论是总结、规划还是 API 调用，在传统人工智能系统中可能需要不同的方法。通过将所有任务转换为特定的函数调用，我们确保以一致的方式处理每个任务。这种统一简化了系统设计； (3) 与外部工具无缝集成：代理经常需要与外部系统、数据库或工具进行通信。函数调用允许这种通信标准化，提供代理和外部工具都可以理解的通用语言。
协同人机协作
- XAgent 允许用户主动干预和指导其决策过程。首先，它提供了一个直观的界面，用户可以覆盖或修改 XAgent 提出的操作，从而将机器效率与人类直觉和专业知识结合起来。其次，当 XAgent 遇到不熟悉的挑战时，它配备了 “AskHumanforHelp” 工具。该工具向用户征求实时反馈、建议或指导，确保代理即使在不确定的地形中也能发挥最佳功能。这种交互式范例将机器自主性与人类智慧相结合，促进了人类与 XAgent 之间的共生关系。

2.6 斯坦福小镇

代码仓库：https://github.com/joonspk-research/generative_agents
相关论文：https://arxiv.org/abs/2304.03442

虚拟小镇作为早期的 multi-agent 项目，很多设计也影响到了其他 multi-agent 框架，里面的反思和记忆检索 feature 比较有意思，模拟人类的思考方式。

代理（Agents）感知他们的环境，当前代理所有的感知（完整的经历记录）都被保存在一个名为 “记忆流”（memory stream）中。基于代理的感知，系统检索相关的记忆，然后使用这些检索到的行为来决定下一个行为。这些检索到的记忆也被用来形成长期计划，并创造出更高级的反思，这些都被输入到记忆流中以供未来使用。