新兴人工智能Agent架构全景：用于推理、规划和工具调用的综述

来看看这份关于AI Agent的综述，它系统梳理了当前Agent在推理、规划和工具调用方面的能力边界。研究的核心目标很明确：搞清楚现有Agent到底能做什么、不能做什么，分享一些在实际运行中观察到的规律，并给未来的Agent设计提供几个关键思路。方法上，这篇综述盘点了单Agent和多Agent两种主流架构，找出了不同设计中的共性模式和关键分歧，并评估了它们对最终目标的影响。可以这么说，它在选择Agent架构时涉及的几个核心问题——比如领导力怎么影响系统表现、Agent之间该如何沟通、以及规划、执行和反思这些关键阶段如何塑造一个健壮的Agent系统——都给出了很有价值的梳理。

1、问题背景

从GPT-4这样的基础模型研究开始，到AutoGPT和BabyAGI这些开源项目引爆社区，研究者们一直在尝试构建能够自主行动的Agent系统。

跟我们平时对大模型做“零次提示”不同——你在对话框里输入一句，它直接给个结果——Agent系统要复杂得多。它引入了规划、循环、反思这些控制结构，让模型能一步步推理，端到端地完成任务。再加上调用工具、插件、函数的能力，Agent就有了处理更通用任务的潜力。

社区里现在有个很有意思的争论：到底是用一个Agent单干，还是搞一群Agent群策群力？结论是，如果问题定义明确、不需要外部角色或用户反馈，单Agent架构就很高效；反之，当任务需要协作、需要并行处理多条路径时，多Agent架构的优势就体现出来了。

1.1关键术语

AI Agent是由语言模型驱动的实体，它能规划并反复执行动作直到达成目标。一个Agent架构可以由单个Agent组成，也可以由多个Agent协作。通常，每个Agent都被分配一个角色，并配有各种工具。有些Agent还有记忆组件，能存取信息。这篇综述采用了“大脑、感知和行动”的Agent定义——简单来说，就是得能理解、推理，并且能对周围环境做出反应。

角色就是Agent的“人设”，包括它的个性、行为规范，以及它能用的工具有哪些。让Agent清楚自己的角色和工具该怎么用，这一点很关键。研究发现，“人设”确实会影响大模型在具体任务中的表现，比如写社交媒体帖子；而且，用多个角色分工协作的方案，比单纯的链式思考提示效果要好得多。

工具就是模型能调用的各种函数，比如拉取外部数据、发送信息或者编辑文档。举个例子，一个“专业合同撰写人”Agent，它的角色是写合同，工具可能就是“添加文档注释”、“阅读现有文档”和“发送最终草稿的邮件”。

由单个语言模型驱动，独立完成所有推理、规划和工具调用。它有自己的系统提示和工具包，但反馈机制只能来自人类，没有其他Agent来给意见。

涉及两个或更多Agent。它们可以用同一个大模型，也可以用不同的；工具可以共享，也可以各自一套；每个Agent都有自己的角色。多Agent架构的组织形式很丰富，这篇综述把它们分成两大类别：垂直架构和水平架构。当然，这只是一个光谱上的两端，现实中的大多数架构都介于两者之间。

一个Agent当领导，其他Agent向它汇报。汇报的Agent可能只跟领导说话，也可能通过一个共享对话来互动。它的核心特征就是有明确的领导和分工。

所有Agent一律平等，大家在一个共享的讨论组里各抒己见。每个Agent都能看到所有人的消息，可以“毛遂自荐”去执行任务或调用工具，不需要领导分配。这种结构特别适合需要协作、反馈和集体讨论的任务。

1.2 开发挑战与未来趋势

• 多Agent系统开发的复杂性：
  管理多个模型和Agent不是件容易事。你得让平台既能灵活配置不同的Agent，又能支持各种流程（标准操作流程SOP或动态工作流），还得搞定一对一或广播式的通信模式。对开发者来说，最理想的就是一个既功能强大又简单易用的平台。但鱼和熊掌，想兼顾就得精心设计和权衡。

• 容错机制：
  大模型本身就有幻觉、指令理解不到位这些问题，再加个外部工具，不确定性就更大了。在多Agent系统里，一个错误很可能像病毒一样扩散。虽然大模型能帮忙识别错误，但能不能让它自行修复、并给出必要的修正信息，这还是个不小的挑战。

• 多模态数据兼容：
  支持图像、音频、视频等多模态数据需要一套从头到尾的体系化方案，从存储、展示到用户交互、消息传输。难题在于保证数据一致性、保持高性能，还不能把概念搞复杂。目前还没有一个通用的平台级编程接口来专门处理这个。

• 分布式应用的编程与系统设计：
  工业场景下，Agent可能分别由不同组织管理、运行在不同的机器上。这就要求开发者具备分布式系统编程和优化的专业知识。调试这类应用会额外费劲，因为问题会分布在各个进程或Agent里。如何高效地解决这些棘手问题，对开发人员来说是个硬骨头。

2、有效Agent的关键考虑因素

2.1 概述

Agent的使命，就是扩展语言模型的能力，去解决真实世界的难题。要做到这一点，它必须能推理、能规划，还得会调用工具来跟外部环境互动。这三大能力缺一不可。

2.2 推理和规划的重要性

推理是人类解决问题的基本能力。如果Agent要自主决策、协助人类，就必须有强大的推理能力。推理和行动是紧密咬合的——这种协同让Agent能快速学习新任务，在没见过的情况下也能做出靠谱的判断。更重要的是，Agent需要根据新的反馈来调整自己的计划。没有推理能力，Agent很可能误解指令、答非所问，或者根本想不到多步操作带来的连锁反应。

规划，正是以推理为基础的。它大致有五种方法：任务分解、多计划选择、借助外部模块、反思完善和记忆增强。这些方法让Agent能把大任务拆成小任务、从一堆方案里选一个、用现成的外部计划、根据新信息修订旧计划，或者利用外部信息来优化方案。大多数Agent模式都有专门的规划步骤，在执行动作前先启动这些技术。比如“像图表一样规划”这个方法，就是把计划画成有向图，让多个步骤同步执行。这对于那些包含很多独立子任务、适合异步执行的任务来说，能带来显著的效率提升。

2.3 有效工具调用的重要性

Agent能抽象地调用多个工具来解决问题，这正是它优于普通提示的关键。工具让Agent能跟外部数据源互动、调用API发消息、或者检索信息。通常，需要大量工具调用的问题，也正是需要复杂推理的问题。无论是单Agent还是多Agent架构，都可以通过“推理+工具调用”的组合来攻克难题。很多方法会反复推理、调用记忆、进行反思，一步步准确解决问题。典型做法就是先拆分问题，再依次用合适的工具解决每个子问题。

但单Agent模式在处理长序列任务时常常力不从心。这个时候，多Agent模式的优势就来了——它能把复杂问题先分解成几个小任务，然后每个Agent用自己独立的工具包去独立处理，既解决了并行任务，也提高了系统的稳健性。

3 单Agent架构

3.1 概述

这一节，我们来盘点几个经典的单Agent方法：ReAct、RAISE、Reflexion、AutoGPT + P和LATS。它们有的优化了推理步骤，有的加入了记忆和反思，核心都是为了让Agent在行动前能好好“琢磨”一下。

3.2 关键主题

Agent能不能成功完成任务，关键在于规划和自我纠正。如果既不会自我评估，也搞不出有效计划，单Agent很可能陷入无限循环，完不成任务，或者给一个不符合预期的结果。反过来，当任务只需要直接调用函数、不需要其他Agent给反馈时，单Agent架构就特别好使。

3.3 例子

这个模式很直接：Agent先想，再干，然后观察结果，循环直到任务完成。相比零次提示，它在多种任务上效果更好。而且整个过程都记录下来，结果更可信、也更便于人类理解。在HotpotQA数据集上，它的虚构率只有6%，而链式思考方法高达14%。不过问题也存在：它有时候会陷入重复的思路，没法跳出循环。如果中途能引入人类反馈，效果会好很多。

在ReAct基础上加了记忆机制，模仿人类的短期（临时便签）和长期（类似案例数据库）记忆。这能提升Agent在长对话里保持上下文的能力。论文还强调，即使使用小模型，微调也能带来最佳性能。RAISE在效率和输出质量上都优于ReAct。但它也有软肋：理解复杂逻辑很吃力，而且角色或知识上经常出现幻觉。比如一个销售Agent可能突然跑去写Python代码。微调能缓解这个问题，但幻觉依然是RAISE的硬伤。

这个模式用语言反馈来做自我反思。它利用成功状态、当前轨迹和持久记忆等指标，通过一个LLM评估器给Agent提供具体、相关的反馈。效果是成功率提升了，幻觉也减少了。缺点是容易陷入“非最优局部最小值”；长期记忆靠的是滑动窗口而不是数据库，容量受限于模型的token限制。虽然它超越了其他单Agent模式，但在需要大量多样性、探索和推理的任务上，还有改进空间。

专门解决用自然语言控制机器人时推理能力不足的问题。它结合了物体检测、物体可供性映射和由LLM驱动的规划系统。Agent能探索环境、寻找替代方案，或者向用户求助。它用场景图像检测物体，然后大模型从中选一个工具：规划工具、部分规划工具、建议替代工具、探索工具。这样机器人不仅能生成完整计划，还能探索、假设和创建部分计划。不过，计划不是大模型自己生成的，而是它提出目标和步骤，然后跟经典规划器（用规划领域定义语言PDDL）合作。论文坦言：“目前大模型缺乏直接把自然语言指令转成可执行计划的能力，主要是推理能力受限。”和经典规划器结合后，效果比纯大模型规划好了不少。缺点也很明显：工具选择的准确率时高时低，有时会误调或陷入循环；探索时可能做出不合逻辑的决策；人机交互也有局限，Agent无法主动请求澄清，用户也不能中途修改或终止计划。

借鉴蒙特卡洛树搜索的思路，用树来协同规划、行动和推理。状态是节点，行动是节点间的遍历。它用基于语言模型的启发式方法来搜索可能选项，然后用状态评估器选一个行动。跟其他树方法不一样，LATS加入了一个自我反思的推理步骤，性能因此大幅提升。每执行一个行动，除了环境反馈，它还从语言模型那里获得反馈，检查推理错误并提出替代方案。这种“自我反思+强大搜索”的组合让它在各种任务上表现出色。不过代价是计算资源消耗大、执行时间长。而且论文评测的基准相对简单，没在需要工具调用或复杂推理的更严苛场景里测试。

4 多Agent架构

4.1 概述

这里我们来看看几个典型的多Agent架构：团队型Agent、DyLAN、AgentVerse和MetaGPT。它们展现了Agent之间如何通过沟通和协作来共同完成目标。这不是一份完整的列表，而是为了覆盖多Agent模式的关键主题。

4.2 关键主题

多Agent架构带来了分工和反馈的巨大优势。很多架构分阶段工作，团队在每个阶段（规划、执行、评估）动态组建和重构，让专业Agent在特定任务上发挥最大作用，用完了就撤。这种“按需组队”的方式能提高准确率、缩短达成目标的时间。一个高效的多Agent系统，关键特征包括：团队里有明确的领导、能动态组队、成员之间能高效共享信息，避免关键信息在无效交流中丢失。

4.3 例子

郭等人的研究展示了领导对团队效率的影响。架构既有垂直成分（领导Agent），也有水平成分（Agent也能跟其他成员对话）。结果发现，有领导的团队完成任务速度比没领导的快了近10%。在没领导的团队里，Agent们大部分时间在互相下命令（约占50%的通信）；而有领导时，领导者60%的通信是下达指令，其他成员则更专注于交换和请求信息。最有效的领导方式，是人类担任领导者。

论文还强调了“批评-反思”步骤对生成计划、评估性能和动态重组团队的重要性。结果进一步表明，采用动态团队结构和轮换领导的方式，在完成时间和平均通信成本上是最优的。领导力和动态结构，实实在在地提升了整个团队的推理、规划和执行能力。

这个框架专注于复杂任务，比如推理和代码生成。它有一个独特的步骤：根据上一轮的工作贡献对Agent进行排名，只让顶级贡献者进入下一轮。所有Agent共享信息，没有明确领导，属于水平架构。它在多个算术和推理基准上都有改进。这再次印证了动态团队的价值——通过持续评估和排名，我们能构建出更适应任务的Agent团队。

这个架构展示了群体规划的不同阶段如何提升推理和问题解决能力。它有四个阶段：招募、协作决策、独立行动执行和评估。这四个阶段可以重复，直到达成目标。每个阶段都严格定义，帮助Agent组更高效地推理、讨论和执行。例如，招募步骤可以根据进展需要随时移除或添加Agent，确保在最合适的阶段有最合适的Agent参与进来。研究发现，水平团队通常最适合咨询等协作任务，而垂直团队则更适合需要明确分工和工具调用的任务。

不少多Agent架构允许Agent们在解决问题时自由聊天，但这容易导致闲聊，对达成目标没帮助。MetaGPT巧妙的解决方案是：要求Agent们生成结构化的输出，比如文档和图表，而不是非结构化的聊天消息。此外，它采用了“发布-订阅”机制来共享信息：所有Agent共享信息，但每个Agent只读取与自己任务相关的内容。这一下子就简化了执行流程，减少了对话噪音。在HumanEval和MBPP基准上，MetaGPT的表现明显优于单Agent架构。

5 讨论与观察

5.1 概述

综合来看，无论是单Agent还是多Agent架构，在复杂目标执行上都表现出了令人瞩目的性能。而且，有几个方法被反复验证是有效的：明确的反馈、任务分解、迭代改进和角色定义——跨架构都管用。

5.2 关键发现

从现有的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都是该轮最合适的，能带来更佳结果。

5.3 总结

在涉及推理和工具执行的复杂任务中，单Agent和多Agent模式都表现出了强大的性能。当一个Agent获得明确定义的角色、一套工具、人类反馈的机会以及迭代前进的能力时，它能做得很好。而当我们要构建一个Agent团队来合作完成复杂目标时，至少部署具备以下一个关键要素是很有帮助的：明确的领导者、明确划分的规划阶段和根据新信息完善计划的机会、智能的消息过滤，以及由拥有特定技能的Agent组成的动态团队。如果一个Agent架构采用了至少一种这些方法，它的表现大概率会比没有这些策略的Agent系统要好。

6 现有研究的局限性及未来研究的考虑

6.1 概述

尽管Agent架构在很多方面都提升了语言模型的能力，但它在评估、整体可靠性以及继承自大语言模型的问题上，依然面临重大挑战。

6.2 Agent评估的挑战

大模型有自己的标准评测基准，但Agent领域的基准却五花八门。很多研究团队在提出自己的Agent实现时，也顺手带了一套独特的基准。这导致不同Agent实现很难在同一个基准上公平对比。而且，很多Agent基准是手工制作、小规模、高度复杂的，结果也是靠人来评分。虽然这种方法能提供高质量评估，但容易因规模小、评分者开发了该方法本身而引入偏见。由于模型、环境或问题状态的变化，Agent在多次迭代中生成一致答案也可能有问题。这种随机性对小规模、复杂评估集的影响更严重。

6.3 数据污染和静态基准的影响

有些研究者用典型的LLM基准来评估自己的Agent实现。但新兴研究表明，大模型的训练数据中存在显著的数据污染——当基准问题被稍作修改，模型的表现就明显恶化。这给大模型及其Agent的基准分数真实性打了一个问号。

另外，大模型发展太快，现有数据集往往跟不上它的能力进化。为了解决这个问题，研究者开始创建对“死记硬背”有抵抗力的动态基准，也有人探索完全用合成数据生成基准的想法。但这些方法可能减少人类参与，又会引入正确性和问题解决能力的风险。

6.4 基准范围和可转移性

很多LLM基准（如MMLU、GSM8K）都是单次迭代就能解决的，不涉及工具调用。它们虽然是衡量基础模型能力的重要工具，但绝不是Agent能力的良好袋里——因为没考虑到Agent系统在多个步骤上推理或访问外部信息的能力。StrategyQA在这方面好一些，评估了模型多步推理的能力，但答案仅限于“是/否”。随着行业向Agent场景转型，我们需要更多新指标来评估Agent在工具调用任务上的性能和泛化能力。

一些Agent专属基准（如AgentBench）评估大模型在网页浏览、命令行、游戏等多种环境下的表现，这提供了一个更好的泛化能力指标。AgentBench和SmartPlay等基准引入了成功率、输出与人类响应的相似度和整体效率等客观指标。这些很重要，但也要考虑更微妙或主观的指标，比如工具使用效率、规划的可靠性和稳健性。这些指标虽然几乎和成功率一样重要，却更难衡量，往往需要人类专家评估，耗时又费钱。

6.5 现实世界的适用性

很多现有基准聚焦于逻辑谜题或视频游戏。评估这些任务能了解Agent的推理能力，但不清楚这种表现能否转化到真实世界中去。真实世界的数据往往充满噪声，覆盖的领域也更广。

一个使用真实数据的流行基准是WildBench，它源自570,000次与ChatGPT的真实对话，涵盖了海量任务和提示。虽然WildBench很广，但大多数其他真实世界基准都侧重于特定任务。例如SWE-bench，它使用GitHub上的一组Python软件工程任务。这对于评估专门写Python代码的Agent很有用，但如果要了解Agent在其他编程语言上的能力，信息量就不够了。

6.6 Agent系统中的偏见和公平性

大语言模型在评估、社交或公平性上已知存在偏见。而且，Agent“不够健壮，更容易产生更有害的行为，并且能生成比LLMs更隐蔽的内容”，这凸显了重大的安全挑战。其他研究发现，“尽管被指示从特定整治角度进行辩论，但语言模型Agent倾向于符合模型固有的社交偏见”。这种倾向会导致基于Agent的实现中间出现错误推理。随着任务复杂度和Agent参与度的增加，我们需要更多研究来识别和解决系统内的偏见。这对研究者来说是个非常大的挑战，因为可扩展且新颖的基准在创建过程中往往离不开大模型的参与，但真正稳健的偏见评估基准，必须包含人类评估。

7 结论与未来方向

这篇调研覆盖的AI Agent实现，展示了大语言模型在推理、规划和工具调用方面的快速进步。无论单Agent还是多Agent模式，都已经具备了解决复杂、多步问题的能力。核心洞察是：没有一种放之四海而皆准的最佳架构，最好的方案因用例而异。但不管选哪种架构，高性能的Agent系统往往至少会用到以下一种方法：明确定义的系统提示、清晰的领导和任务划分、专用的推理/规划-执行-评估阶段、动态的团队结构、人类或Agent的反馈，以及智能的消息过滤。采用这些技术的方法，在各种基准和问题类型上都更有效。

尽管前景令人鼓舞，但局限性和未来改进空间也很明显。短期来看，我们需要解决全面Agent基准缺失、真实世界适用性不足，以及减轻有害偏见等挑战，才能实现可靠的Agent。通过梳理从静态语言模型到动态自主Agent的发展脉络，这篇调查希望能为研究者和工程师们提供一个关于当前AI Agent格局的整体认识，也为那些正在使用或开发定制Agent架构的人，提供一些有价值的参考。