Single-Agent 大翻身：Multi-Agent 可以退下了？

大靠山

于 2024-10-07 20:14:09 发布

阅读量966

点赞数 30

文章标签： dubbo java 人工智能前端语言模型自然语言处理

本文链接：https://blog.csdn.net/m0_59235245/article/details/142745602

版权

单体AI代理系统正在逆袭，多代理系统可能要凉凉了？

在这里插入图片描述

随着大语言模型（LLMs）的不断进步，越来越多的公司开始构建AI代理系统。

但是，到底什么是基于LLM的代理系统？

我们真的需要多代理系统吗？

前Open Devin（现Open Hands）的Graham Neubig最近发表了一篇博文，深入探讨了这个问题，并解释了如何打造优秀的单体代理系统。

来看看这场"单体VS多体"的AI代理之战！

AI代理系统的核心组成

首先，我们需要了解AI代理系统的关键组成部分：

大语言模型（LLMs）：作为系统的大脑
提示词（Prompts）：用于引导模型思考
动作空间（Action spaces）：定义代理可以执行的操作

多代理系统通常会在这些组件上进行变化，以实现不同的功能。

多代理系统：看似强大，实则复杂

多代理系统的一个典型例子是使用不同的代理来管理、复制、本地化、编辑和验证代码。这种方法看起来很强大，但实际上面临着一些严峻的挑战：

结构难以组织：多个代理之间的协调和通信变得复杂
上下文保存困难：在代理之间传递信息可能导致重要上下文的丢失
维护成本高：随着系统规模的扩大，维护和更新多个代理变得越来越困难

单体代理系统：简单而强大

相比之下，单体代理系统具有以下优势：

利用强大的通用LLMs：充分发挥大模型的全能性
整合多样化工具：在一个统一的动作空间内集成各种功能
简化提示技术：使用更直接、更有效的提示方法

单体系统的提示技巧

尽管单体系统看似简单，但在提示方面仍然需要一些技巧：

提示词拼接：将多个提示组合在一起，以覆盖更广泛的功能
检索增强提示：根据需要动态获取和使用相关信息

你认为单体AI代理系统会成为未来的主流吗？

【原文译文】

别忽视单一代理系统的潜力

作者: Graham Neubig | 2024年9月26日

最近，“多代理系统（multi-agent system）”成了人工智能领域最热门的流行词之一，不仅是 MetaGPT[1] 和 Autogen[2] 这样流行的开源框架的重点关注对象，也在各种黑客松[3]和诸多研究论文中频繁出现。然而，在这篇文章中，我想从另一个角度来看待这一趋势，并论述为何单一代理系统同样值得关注。文章将以我们构建的软件开发代理框架 OpenHands[4] 的经验为例，阐述相关观点。

本文将讨论以下几点内容：

构建现代 AI 代理的要素：大语言模型（LLM）、提示词（Prompts）和动作空间（Action Spaces）
多代理系统的示例
多代理系统的一些问题
如何从使用多个专业化代理转向使用单一强力代理，并讨论当前仍需解决的相关问题

什么是基于 LLM 的代理？

目前大多数实用的 AI 代理都是基于像 Anthropic 的 Claude[5] 或 OpenAI 语言模型[6] 这样的大型语言模型（LLM）。但仅有语言模型并不足以构建一个完整的代理系统，至少还需要以下三个组成部分：

底层大语言模型（The Underlying LLM）
提示词（Prompt）：提示词可以是指定模型行为的系统提示词，也可以是从代理的外部环境中获取的相关信息。
动作空间（Action Space）：指的是赋予代理在世界中采取行动的工具。

通常，在讨论多代理系统时，我们至少会在这三个组成部分中的某一个上进行变动。

多代理系统的一个示例

假设我们正在构建一个 AI 软件开发工具。我们可以参考 CodeR[7]——一个用于 AI 软件开发的多代理框架。CodeR 包含多个代理，这些代理使用相同的底层语言模型，但在提示词和动作空间上各不相同：

管理者（Manager）：该代理的提示词要求它编写供其他代理执行的计划，其动作空间是输出相应的计划。
再现者（Reproducer）：该代理的提示词要求它再现问题，并通过 reproduce.py 文件中的代码来复现错误。
故障定位者（Fault Localizer）：该代理的提示词要求它找出引发错误的文件，并使用软件工程工具定位故障文件供后续使用。
编辑者（Editor）：该代理的提示词要求它根据再现者和故障定位者的结果对文件进行编辑。
验证者（Verifier）：该代理的提示词要求它对其他代理的结果进行验证，并输出问题是否解决的判断结果（是/否）。

这种系统架构虽然直观，但在实际构建过程中仍然面临诸多挑战。

多代理系统面临的问题

构建多代理系统时，可能遇到以下几个难点：

架构设计的复杂性：多代理系统依赖特定架构来解决问题，这在问题与架构完全匹配时效果很好。但如果不匹配呢？例如，如果验证者想要进一步验证它的判断，需要进行文件定位，但因为这些代理是完全独立的，验证者无法直接使用相关工具完成任务。
上下文信息的维护：多代理系统通常通过多个代理之间传递信息，但这可能导致信息的丢失。例如，故障定位者将其工作内容传递给后续代理时，可能只传递摘要信息，而这些关键信息可能会对下游代理完成任务至关重要。
维护难度：每个代理通常都有独立的代码库或提示词，因此多代理系统的代码库往往更大，维护起来也更加复杂。

有趣的是，很多这些挑战与人类组织的管理问题类似！相信大家都有过这样的经历：所在团队组织混乱、沟通不畅，或者因某个成员离职导致关键技能缺失。

如何构建卓越的单一代理系统

需要明确的是，人们选择多代理系统并非没有原因——在能够为每个代理提供合适的架构和工具时，专业化代理在特定任务上表现出色。那么，单一代理系统能否与之竞争呢？我认为，这个目标比我们想象中更容易实现——我们已经在 OpenHands 中实现的 CodeActAgent[8] 中创建了一个不错的原型。以下是构建优秀的单一大语言模型（LLM）、单一动作空间和单一提示词技术所需的要素。

单一大语言模型

这是相对容易实现的部分。目前已有一些通用性很强的 LLM，包括封闭的 Claude 和 GPT-4o，以及开源的 Llama-3.1[9] 或 Qwen-2.5[10]。虽然这些模型无法涵盖所有能力，但它们的能力覆盖面非常广泛。即使它们缺少某些特定能力，也可以通过持续训练[11]来增加新能力，而不会显著影响其他能力。

单一动作空间

这也不算难。如果我们希望为多个代理提供不同的工具，可以通过以下两种方式来实现：

提供模型相对通用的工具以解决问题。
如果不同的代理有不同的工具箱，可以将它们整合在一起。例如，在 OpenHands 中，我们为代理提供了 (a) 编写代码、(b) 运行代码和 © 执行网页浏览的工具。通过这种方式，我们可以利用现有的面向人类开发者的软件工具，从而使单一代理能够胜任大多数多代理系统的功能。

单一提示词技术

这一部分相对较为复杂。我们需要确保代理能够获得解决任务的合适指示，并从其环境中获取必要的信息。以下是两种可能的实现方案：

合并所有提示词：如果一个多代理系统中有 10 个不同的提示词，为什么不将它们全部合并呢？如今，我们已经有了可以处理数十万甚至上百万个 token 的长上下文模型（如 Claude 可处理 20 万 token，Llama 可处理 12.8 万 token）。这是我们在 OpenHands 中目前采取的策略。不过这种方法也有一些缺点。首先是成本问题，较长的提示词会增加费用和处理时间，尽管 Anthropic 的提示词缓存[12]等功能使这一点比以前更加经济。其次，LLM 可能会因为被提供过多无关信息而分散注意力[13]，但随着模型能力的提升，它们在长上下文中提取重要信息的能力也在不断增强。
基于检索的提示（Retrieval-augmented Prompting）：另一种可能的选择是借助检索技术。就像基于检索的生成系统（RAG）[14]那样，可以通过检索来避免冗长上下文带来的效率或准确性问题。虽然已有一些研究工作[15]专注于在提示词中选择合适的示例，但我尚未见到有针对代理系统的相关研究。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述