干货 | IBM：系统性整理Agent架构、框架

发布时间：2024 年 04 月 17 日

Agent 人工智能 自动化系统

本篇综述性文章深入探讨了人工智能代理实现的近期进展，特别关注这些代理在实现复杂目标时所需的高级推理、规划和工具执行能力。文章旨在 a) 阐述当前人工智能代理实现的能力与局限，b) 分享我们在观察这些系统运作过程中获得的洞见，c) 对未来人工智能代理设计的发展提出建议。通过概述单代理和多代理架构，识别设计选择中的关键模式和差异，并评估这些设计对达成既定目标的整体影响，我们达成了这些目标。文章还概述了在选择代理架构时应考虑的关键要素，领导力对代理系统的影响，代理间的沟通方式，以及规划、执行和反思的关键阶段，这些都是构建强大人工智能代理系统的关键因素。

Agent的前世今生

自前年ChatGPT爆火以后，很多生成式AI应用都采用了检索增强生成（RAG）技术来生成对话。尽管RAG不断地在进步和优化，但是越来越多的团队都在积极探索下一代AI应用的新形态，聚焦于新的应用新星：Agent（智能代理）。

Agent应用起步于GPT4，通过AutoGPT、BabyAGI等开源项目不断发展。Agent应用依靠更加复杂的交互、协调、规划、循环、反思，充分利用了模型的内在推理能力，实现任务的全程自动化。再加上工具、插件、函数调用等能力，Agent可以适应更加广泛的工作和场景。

而Agent也从最开始的单一Agent，不断发展为多Agent的形式。单一Agent架构在问题边界清晰、且无需其他代理角色或用户反馈时表现优异。但是多Agent架构则在需要协作和多条独立执行路径时更具有优势。

可以参考历史文章：

Agent四大范式 | CRITIC：吴恩达力推Agent设计范式

Agent四大范式 | 综述：全面理解Agent工作原理

划重点 | 吴恩达：Agent模式将在不久的将来超过下一代模型

什么是Agent？

AI Agent是一种由大语言模型驱动的实体，能够规划并执行多轮行动以达成既定的任务目标。AI Agent的架构可以是单一Agent独立运作，或是多个代理协同合作解决问题。每个Agent通常会被赋予一个角色，并配备多种工具，以帮助它们独立或团队协作完成任务。部分代理还具备记忆功能，能够存储和检索信息，超越了它们接收的消息和提示。在这篇文章里，作者使用了“大脑、感知和行动”三个要素来定义Agent，这些要素是Agent理解环境、进行推理和采取行动的基本要求。

Agent角色（Agent Persona）是否有效？

Agent角色定义了Agent应扮演的角色或个性，以及任何特定于该Agent的指令。角色描述还包括了Agent可以利用的工具。这些描述让Agent明白自己的职责、工具的用途以及如何高效地使用这些工具。

有研究表明，塑造的个性可以显著影响大型语言模型（LLM）在常见下游任务中的行为，例如撰写社交媒体帖子。采用多个代理角色解决问题的方法，相较于要求模型逐步展示其计划的链式思维（CoT）提示，也显示出了显著的进步。

什么是Agent的工具？

在AI Agent的语境中，工具指的是模型可以调用的任何功能，允许Agent与外部数据源交互，通过提取或推送信息。以专业合同撰写者为例，该Agent被赋予了明确其角色和任务类型的人物设定，并配备了添加文档注释、阅读现有文档或发送最终草稿电子邮件等相关工具。

单一Agent架构

单一Agent架构由单一语言模型驱动，独立完成所有推理、规划和工具执行。Agent接收系统提示和完成任务所需的工具。在这种模式下，没有其他Agent的反馈机制，但可能有人提供反馈以指导Agent。

多Agent架构

多Agent架构则涉及两个或更多Agent，它们可以使用相同的语言模型或不同的语言模型。每个代理可以访问相同或不同的工具，并拥有自己的角色。多代理架构在复杂性上可以有多种组织形式，本文将其分为两大类：垂直架构和水平水平。这种划分方式实际上是理想情况下的两种极端，大多数多Agent架构实际上是出于这两者之间。

垂直多Agent架构

在垂直架构中，一个Agent作为领导者，其他Agent直接向其汇报。根据架构的设计，汇报的Agent可能只与领导Agent通信，或者所有Agent之间可以共享对话。垂直架构的显著特征是有一个领导代理和明确的劳动分工。

水平多Agent架构

而在水平架构中，所有Agent平等参与，共同讨论任务。Agent间的通信在一个共享的讨论线索中进行，每个Agent都能看到其他Agent的所有消息。Agent也可以自愿承担特定任务或调用工具，无需领导代理的指派。水平架构通常适用于需要协作、反馈和团队讨论的任务。

打造高效Agent应用的关键因素

设计Agent的目的是用来扩展大语言模型的功能，来处理真实世界的一系列复杂问题。首先模型要有强大的问题解决能力，要处理问题，还需要具备强大的推理和规划能力，以及与外部环境互动的工具调用功能。

为什么推理和规划能力很重要

推理是认知的基石，是使人能够做出决策、解决问题并理解周围的世界的关键能力。Agent如果想要在复杂环境中有效互动、自主决策，并在各种任务中协助人类，就必须具备强大的推理能力。“行动”与“推理”之间的紧密协作，使得Agent能够快速学习新任务，并在未知情境或信息不确定的情况下，进行稳健的决策或推理。此外，代理还需要推理能力来根据新的反馈或学到的信息调整其计划。如果Agent缺乏推理能力，可能会在执行简单任务时误解查询、基于字面理解生成响应，或未能考虑到多步骤的影响。

规划 是需要强大的推理能力，通常包括五种主要方法：任务分解、多计划选择、外部模块辅助规划、反思与改进以及记忆增强规划。这些方法使得模型可以分解任务为子任务、从多个生成的选项中选择一个计划、利用现有的外部计划、根据新信息修订先前计划，或利用外部信息来改进计划。大多数Agent模式都有一个专门的规划步骤，在执行任何动作之前，会调用这些技术中的一种或多种来制定计划。例如，“像图一样规划”（Plan Like a Graph, PLaG）是一种将计划表示为有向图的方法，允许多个步骤并行执行，这在处理包含许多独立子任务的任务时，可以显著提高性能，特别是那些从异步执行中获益的任务。

为什么工具调用能力很关键

与直接使用大语言模型相比，Agent的主要优势在于Agent能够通过调用多种工具来解决复杂问题。这些工具使得代理能够与外部数据源进行交互，通过api或者其他方式收集信息。无论是单Agent模式还是多Agent架构，都可以通过运用推理和工具调用来解决现实世界的复杂问题。很多方法通过多次迭代推理、记忆、反思来解决这些问题。一般会把一个大问题拆解为若干个子问题，然后依次使用合适的工具来解决这些子问题。

单Agent架构

这里，作者主要介绍了几种单Agent方法：ReAct、RAISE、Reflexion、AutoGPT + P和LATS。这些方法在采取行动前，都会有一个专门的阶段来对问题进行推理和规划。而之所以选择这些方法来介绍，也是因为这些方法对于提升Agent的推理能力、工具调用能力都有不错的表现。

Agent成功的关键

Agent成功的关键在于恰当的规划和自我纠错能力。如果缺乏自我评估和制定有效计划的能力，单Agent可能会陷入无尽的执行循环，无法完成特定任务，或者无法给出满足用户期望的结果。并且，当任务直接执行功能调用，并且不需要其他Agent反馈时，使用单Agent架构时合理有效的。

ReAct方法

在ReAct（Reasoning + Action）策略中，Agent首先对指定任务构思一个想法，随后基于这个想法采取行动，并观察结果。这个过程可以不断循环，直至任务完成。ReAct在多样化的语言和决策任务上相较于传统的Zero Shot提示方法，展现出了更高的效率，并且由于模型的思维过程被完整记录，它还提升了与人类的互操作性和信任度。在HotpotQA数据集的测试中，ReAct的幻觉发生频率仅为6%，远低于思维链（CoT）方法的14%。然而，ReAct策略也有其局限性。模型在提高信任度的同时，可能会陷入重复生成相同想法和行动的循环中，难以产生新想法来完成任务，跳出ReAct循环。在任务执行过程中引入人为反馈，可能会显著提升其在现实世界情境中的效能和应用范围。

RAISE方法

RAISE（Reasoning and Acting through Scratchpad and Examples）方法是ReAct的增强版，增加了模仿人类短期和长期记忆的记忆机制，通过使用草稿本来实现短期记忆，以及一个类似先前例子的数据集来实现长期记忆。

这些新增组件显著提升了代理在长对话中维持上下文的能力。对模型进行微调可以实现最佳性能，即便使用的是较小的模型。RAISE在效率和输出质量上均超越了ReAct。

尽管RAISE在某些方面显著优于现有方法，但也存在一些问题：

• • 首先，RAISE在理解复杂逻辑方面存在挑战，这限制了其在多种场景下的应用。

• • 此外，RAISE代理可能会围绕其角色或知识产生幻觉。例如，一个角色不明确的销售代理可能会保留编码Python的能力，导致他们开始编写Python代码，而非专注于销售任务。这些代理有时还会向用户提供误导性或错误的信息。尽管通过微调模型可以解决这一问题，但幻觉问题仍然无法很好的解决。

Reflexion方法

Reflexion方法是指通过语言反馈实现自我反思。通过利用成功状态、当前路径和持久记忆等评价指标，利用大语言模型的评估器为Agent提供针对性反馈。这种方法不仅提升了任务的成功率，而且相较于思维链（Chain-of-Thought）和ReAct方法，减少了幻觉现象。尽管如此，Reflexion模式的作者也指出了其存在的一些限制：

• • Reflexion容易陷入“非最优局部最小值”的解决方案。

• • 它依赖滑动窗口机制来处理长期记忆，而非数据库，这限制了长期记忆的容量，因为它受到语言模型的令牌数量限制。

• • 尽管Reflexion在单Agent模式中表现突出，但在处理需要大量多样性、探索和推理的任务时，仍有提升性能的空间。

AutoGPT + P（Planning）

AutoGPT + P也是一种解决大语言模型在Agent应用推理限制的方法。这种方法使得Agent能够寻找环境中缺失的物品，提出替代方案，或向用户寻求帮助以达成目标。AutoGPT+P的操作始于利用场景图像来识别物体。随后，语言模型依据这些信息从四种工具中选择其一：计划工具、部分计划工具、候选计划工具和探索工具。这些工具使机器人不仅能生成完成目标的完整计划，还能探索环境、做出假设并制定部分计划。然而，语言模型并非完全独立生成计划。它负责生成目标和步骤，与一个执行计划的经典规划器协同，该规划器使用规划领域定义语言（PDDL）。AutoGPT + P通过将大语言模型Agent应用的规划能力与传统规划器相结合，在机器人规划上显著优于其他纯粹基于语言模型的方法。尽管AutoGPT+P是首创，但它也有不足之处：

• • 工具选择的准确性参差不齐，有时会错误调用工具或陷入循环

• • 在需要探索的场景中，工具选择有时会做出不合逻辑的决策，如在错误地点寻找物品。

• • 框架在人机互动方面存在局限，代理无法请求澄清，用户也无法在执行过程中修改或终止计划。

多Agent框架

多agent框架里，作者推荐DyLAN、AgentVerse和MetaGPT。介绍了如何实现代理间交流、协同执行计划来实现任务目标。

多Agent框架大多数采用分阶段工作的方式：规划、执行、评估等。通过将代理的角色和技能与当前任务精准匹配，团队能够以更高的准确度达成目标，并缩短达成目标的时间。有效的多代理架构的显著特点包括：团队中有明确的领导力，团队构建的动态性，以及团队成员间有效的信息共享，确保关键信息不会在无关对话中丢失。

Embodied LLM Agents Learn to Cooperate in Organized Teams

Emmm..... 这个框架就叫这个名字 Embodied LLM Agents Learn to Cooperate in Organized Teams。这个框架是突出了领队Agent对整个Agent团队效能提升的作用，不仅通过领队形成了垂直的指挥链，还允许代理之间进行水平间交流。

有明确领导的团队比无领导的团队完成任务的速度提高了将近10%。

在没有明确领导的团队中，代理大部分时间都在相互下达指令（约占沟通的50%），其余时间则用于信息共享或寻求指导。而在有明确领导的团队中，领导的沟通有60%是在提供方向，这促使其他成员更专注于信息交流和请求。

这个框架的作者发现：当领队是人类时，团队的效能最佳。文章还强调了在计划生成、表现评估、反馈提供和团队重组中采用“批评-反思”步骤的重要性。研究结果表明，具有动态轮换领导结构的团队在任务完成时间和平均沟通成本上都取得了最佳表现。总而言之，领导力和动态团队结构显著提升了团队在推理、规划和任务执行上的整体能力。

DyLAN框架

DyLAN（The Dynamic LLM-Agent Network）框架构建能够处理复杂任务如推理和代码生成的动态代理结构。DyLAN通过评估每位Agent在最近一轮工作中的贡献度，并仅将贡献突出的Agent送入下一轮执行，展现了其水平结构的特点，即代理间可以自由交换信息，且团队无固定领导者。DyLAN在多项衡量算术和推理能力的基准测试中表现更佳，这突显了动态团队的重要性，并说明通过不断评估和排序代理的贡献，能够组建出更适合完成特定任务的代理团队。

AgentVerse框架

多Agent架构AgentVerse 通过明确的团队规划阶段来增强AI Agent的推理和问题解决能力。AgentVerse将任务执行过程分为四个主要阶段：招募、协作决策、独立行动执行和评估，直至达到最终目标。通过为每个阶段设定清晰的框架，AgentVerse引导代理团队更高效地进行逻辑推理、讨论和行动。

以招募阶段为例，它允许根据目标进展情况增减Agent，确保在问题解决的每个阶段都有恰当的Agent参与。研究者发现，在需要协作的任务中，如咨询工作，水平团队通常更为合适；而在需要明确分工以调用工具的任务中，垂直团队则更为适宜。

MetaGPT框架

多Agent架构允许Agent间进行信息交流和共享。然而，这种对话机制有时会导致Agent间的冗余交流，不利于推动团队目标的实现。MetaGPT通过引导Agent产出结构化的结果——如文档和图表——而非无序的聊天信息。此外，MetaGPT引入了“发布-订阅”的信息共享机制，使得所有代理都能在统一平台上发布信息，同时仅订阅与其个人目标和任务相关的信息。这种方式不仅优化了整体目标的执行流程，也减少了代理间的无效沟通。在HumanEval和MBPP等基准测试中，与单代理架构相比，MetaGPT的多代理架构显著展现出了更佳的性能表现。

一些建设性意见

采用单Agent还是多Agent架构？

综合以上各种Agent框架，作者认为单Agent模式更适用于工具列表有限且流程明确定义的任务。

单Agent架构的实现相对简单，因为只需定义一个Agent及其工具集。此外，单Agent架构不受其他Agent不良反馈或团队成员无关对话的干扰。但若其推理和完善功能不够完善，可能会陷入执行循环，难以向目标迈进。

多Agent架构则适合于那些能从多个角色反馈中获益的任务，如文档生成，其中一个Agent可以对另一个Agent编写的文档部分提供明确反馈。当需要在不同任务或工作流程间进行并行处理时，多Agent系统同样适用。在没有提供示例的情况下，多代理模式比单代理表现更佳。多代理系统天生更为复杂，通常需要有效的对话管理和明确的领导指导。

尽管单Agent和多Agent模式在能力范围上有所差异，但研究也发现，“当Agent得到的提示足够有力时，多Agent讨论并不一定能提升推理能力”。这暗示了在决定是采用单Agent还是多Agent时，应基于用例所处的环境，而非仅仅基于所需的推理能力。

Agent是否能够异步处理

单个Agent能够同时启动多个异步调用，但其工作模式并不内在地支持跨不同执行线程的责任分配。换言之，尽管任务以异步方式处理，它们并不构成真正意义上的并行处理，因为这些任务并非由独立的决策主体来独立管理。相对地，单个Agent必须依次规划和执行任务，需等待一组异步操作结束后，才能进行评估并转向下一步骤。而在多Agent架构中，每位Agent都能独立运作，从而允许更为动态的职责分配。这种架构不仅促进了跨不同领域或目标的任务同步执行，还使得各个Agent能够不受其他代理所处理任务状态的制约，自主决定下一步行动，展现了一种更为灵活和并行的任务管理方式。

反馈与人类监管对代理系统的作用

人类在解决复杂问题的时候，极少的能一次性提出正确且稳定的解决方案。一般来说，会先提出一个可能的解决方案，然后对其进行批判和优化，或向他人咨询，以获得不同视角的反馈。而这种反复的反馈和改进过程对于协助Agent解决复杂问题也极为关键。

这在一定程度上是因为语言模型往往在回答初期便急于给出答案，这可能导致解决方案与目标状态越来越偏离，形成所谓的“雪球效应”。引入反馈机制后，代理更有可能及时纠正方向，准确达成目标。

此外，纳入人类的监管可以提升代理的即时响应质量，使其更符合人类的预期，避免代理走上低效或错误的解决路径。目前，代理体系中融入人工验证和反馈，能够带来更可靠和值得信赖的结果。

语言模型还可能表现出迎合用户立场的倾向，即便这意味着无法提供一个中立或平衡的观点。特别是AgentVerse论文中提到，Agent容易受到其他Agent反馈的影响，哪怕这些反馈本身并不合理。这可能导致Agent团队制定出偏离目标的错误计划。通过强化提示可以缓解这一问题，但开发Agent应用的开发者在设计用户或代理反馈系统时，应充分意识到其中的风险。

多Agent架构的挑战：Agent间的信息共享

单Agent模式由于无需管理团队动态，更能够集中精力于手头任务。多Agent系统中的非必要对话可能会影响Agent的有效推理和工具使用，从而降低团队的整体效率。这种情况在水平架构中尤为明显，因为代理们通常使用共享群组聊天，能够看到对话中的每条消息。通过消息订阅或过滤机制，可以确保代理只接收与其任务相关的信息，从而提高性能。在垂直架构中，任务根据代理的能力被清晰分配，有助于减少团队分心。但如果领导Agent未能及时向支持代理传达关键信息，可能会导致团队混乱或结果失真。为解决这一问题，可以在系统提示中明确包含访问权限信息，以确保代理间的交互适宜于上下文环境。

角色定义和动态团队的重要性

在单Agent架构中，明确的角色定义保障代理集中精力完成既定任务，正确使用工具，并减少对不必要功能的幻想。在多Agent架构中，角色界定同样确保每位Agent都清楚自己的职责所在，不会承担超出自身能力范围或任务描述之外的工作。此外，确立一个明确的团队领导，能够通过简化任务指派过程，提升多代理团队的整体表现。同时，为每个Agent设定清晰的系统提示，可以避免Agent间进行无意义的交流，从而减少冗余对话。动态团队策略，即根据实际需要将Agent添加到系统中或从系统中移除，也被证实能够提升效率。这确保了参与规划或执行任务的所有Agent都适合当前工作的需求。

阶段性总结

无论是单Agent还是多Agent模式，在需要推理和工具应用的复杂任务上都展现了强大的性能。

当Agent被赋予明确的角色定位、工具集、接受人工反馈以及能够逐步迭代以达成目标的能力时，单Agent模式能够发挥出色的效果。

在构建需要协同合作以实现复杂目标的Agent团队时，配备以下关键要素之一的Agent将大有益：具备清晰领导力、明确的规划阶段以及在新信息学习后能够对计划进行完善的机会、智能的消息筛选机制，以及能够根据当前子任务需求配备特定技能的动态团队。如果Agent架构至少采用了这些方法中的一种，其性能很可能超越单一代理架构或缺乏这些策略的多Agent架构。

当前进展的局限性

Agent效果评估

大型语言模型（LLM）通常通过一系列标准化基准测试来衡量其综合理解和推理能力，然而，评估Agent应用的基准测试却千差万别。

许多研究小组在推出自己的代理应用实现时，也会同时引入他们独有的Agent基准测试，这使得在统一的基准上比较不同代理实现的效果变得困难。此外，许多新制定的、特定于代理的基准测试包含了手工打造的、极为复杂的评估集，这些评估集的结果需要人工进行评分。这种做法虽然能够提供对方法效能的高质量评估，但相比大规模数据集，其鲁棒性不足，并且由于开发方法的研究者同时负责编写和评分，因此评估过程可能引入偏见。此外，由于模型、环境或问题状态的多样性，代理在连续迭代中生成一致答案也面临挑战。这种额外的随机性对于规模较小、结构复杂的评估集来说，尤其成为一个更加突出的问题。

数据污染与静态基准的挑战

部分研究者采用标准的大语言模型（LLM）基准测试来评估他们的代理应用实现。但最新研究表明，模型训练所用数据存在显著污染，这一点从基准问题一经修改，模型表现便急剧下降的观察中得到了证实，让人对语言模型及其驱动的代理应用的基准分数的真实性产生疑问。进一步地，研究者们发现，随着大型语言模型（LLM）能力的快速进步，现有数据集往往无法跟上模型日新月异的能力，因为现有基准测试的难度水平通常是静态且固定的。为应对这一挑战，已有研究致力于开发能够抵御简单记忆的动态基准测试。此外，研究者们也在探索根据用户特定环境或应用场景生成完全合成的基准测试。尽管这些方法有助于减少数据污染，但减少人为干预的程度也可能带来准确性和问题解决能力的额外风险。

基准测试的范畴与Agent能力的迁移性

目前，众多语言模型基准测试旨在单轮迭代中求解，且不涉及工具调用，如MMLU或GSM8K等。这类测试对于评估基础语言模型的性能至关重要，但它们并不足以全面代表代理应用的能力，因为它们未能考量Agent系统进行多步推理或获取外部信息的能力。StrategyQA通过多步推理测试模型，改进了这一点，但其答案仅限于是或否。随着行业不断向Agent驱动的用例转型，未来将需要更多元的评价标准，以更准确地衡量Agent在处理超越其训练数据范围任务时的表现和泛化能力。特定于Agent的基准测试，例如AgentBench，通过在多样的环境如网页浏览、命令行界面和视频游戏中评估基于语言模型的Agent，提供了更为全面的代理性能评估。这有助于更好地判断Agent通过推理、规划和工具调用来适应新环境的能力。AgentBench和SmartPlay等基准测试引入了客观的评估指标，用以衡量实现的成功率、输出与人类响应的相似度及整体效率。尽管这些客观指标对于把握实现的可靠性和准确性至关重要，但同样不可忽视更为细致或主观的性能评价标准。工具使用效率、规划的可靠性和鲁棒性等指标的重要性不亚于成功率，但它们的衡量却更为困难。许多这类指标需要人类专家进行评估，与使用大型语言模型作为评判的评估相比，这种方法的成本更高，也更耗时。

真实场景的应用情况

当前的多数基准测试集中考察代理系统在逻辑谜题或视频游戏上的推理能力。这些任务的表现虽有助于评估代理系统的逻辑推理能力，但它们在现实世界中的表现如何，目前尚无定论。特别是，现实世界的数据往往更为复杂多变，覆盖的领域也远超过一般基准测试所涉及的范围。

Agent系统中的偏见与公平性

语言模型在评估过程中以及社会或公平性方面存在偏见已为人所熟知。更具体地，代理系统被特别指出“较不稳健，更容易表现出有害行为，并且相比大型语言模型（LLM），能够生成更加隐蔽的内容，这突显了显著的安全挑战”。还有研究发现，“尽管被引导从特定的政治视角进行辩论，LLM代理仍然倾向于遵循模型内部的社会偏见”[24]，这种倾向可能导致基于代理的系统中出现错误的推理。

Arxiv

通往 AGI 的神秘代码

if like_this_article():
    do_action('点赞')
    do_action('再看')
    add_wx_friend('iamxxn886')

if like_all_arxiv_articles():
    go_to_link('https://github.com/HuggingAGI/HuggingArxiv')    star_github_repo(''https://github.com/HuggingAGI/HuggingArxiv')