单体AI代理系统正在逆袭，多代理系统可能要凉凉了？
随着大语言模型（LLMs）的不断进步，越来越多的公司开始构建AI代理系统。
但是，到底什么是基于LLM的代理系统？
我们真的需要多代理系统吗？
前Open Devin（现Open Hands）的Graham Neubig最近发表了一篇博文，深入探讨了这个问题，并解释了如何打造优秀的单体代理系统。
来看看这场"单体VS多体"的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) 运行代码和 (c) 执行网页浏览的工具。通过这种方式，我们可以利用现有的面向人类开发者的软件工具，从而使单一代理能够胜任大多数多代理系统的功能。
单一提示词技术
这一部分相对较为复杂。我们需要确保代理能够获得解决任务的合适指示，并从其环境中获取必要的信息。以下是两种可能的实现方案：
合并所有提示词：如果一个多代理系统中有 10 个不同的提示词，为什么不将它们全部合并呢？如今，我们已经有了可以处理数十万甚至上百万个 token 的长上下文模型（如 Claude 可处理 20 万 token，Llama 可处理 12.8 万 token）。这是我们在 OpenHands 中目前采取的策略。不过这种方法也有一些缺点。首先是成本问题，较长的提示词会增加费用和处理时间，尽管 Anthropic 的提示词缓存[12]等功能使这一点比以前更加经济。其次，LLM 可能会因为被提供过多无关信息而分散注意力[13]，但随着模型能力的提升，它们在长上下文中提取重要信息的能力也在不断增强。 基于检索的提示（Retrieval-augmented Prompting）：另一种可能的选择是借助检索技术。就像基于检索的生成系统（RAG）[14]那样，可以通过检索来避免冗长上下文带来的效率或准确性问题。虽然已有一些研究工作[15]专注于在提示词中选择合适的示例，但我尚未见到有针对代理系统的相关研究。
找到最佳解决方案仍然是一个活跃的研究课题，但我相信这是可以克服的挑战。如果你对此感兴趣，欢迎加入 OpenHands 的 Slack 社区[16]与我们一起探讨更多内容！
结论
以上讨论并非否定多代理系统的价值。例如，当某个代理拥有特权信息，或在多个代理分别代表不同用户执行任务的情况下，多代理系统无疑是最优选择！
本文的目的只是希望大家能够对增加系统复杂性的趋势保持批判性思考。有时简单才是最优解。凭借强大的模型、先进的工具和多样的提示词，我们已经朝着这一方向迈出了坚实的一步。
如果你对上述内容感兴趣，可以通过我们的开源项目[17]或在线版本[18]尝试基于单一通用 AI 代理构建的强大开源软件开发工具，或者加入我们的社区[19]并做出贡献[20]！
参考资料
MetaGPT: https://github.com/geekan/MetaGPT
[2]Autogen: https://microsoft.github.io/autogen/
[3]黑客松: https://medium.com/@kyeg/announcing-the-sthe-first-multi-agent-hackathon-ever-b5e76f534b0d
[4]OpenHands: https://github.com/All-Hands-AI/OpenHands
[5]Anthropic 的 Claude: https://www.anthropic.com/claude
[6]OpenAI 语言模型: https://platform.openai.com/docs/models
[7]CodeR: https://arxiv.org/abs/2406.01304
[8]OpenHands 中实现的 CodeActAgent: https://github.com/All-Hands-AI/OpenHands/tree/main/agenthub/codeact_agent
[9]Llama-3.1: https://ai.meta.com/blog/meta-llama-3-1/
[10]Qwen-2.5: https://qwenlm.github.io/blog/qwen2.5/
[11]持续训练: https://arxiv.org/abs/2402.01364
[12]Anthropic 的提示词缓存: https://www.anthropic.com/news/prompt-caching
[13]分散注意力: https://arxiv.org/abs/2307.03172
[14]基于检索的生成系统（RAG）: https://learnbybuilding.ai/tutorials/rag-from-scratch
[15]研究工作: https://arxiv.org/abs/2209.11755
[16]加入 OpenHands 的 Slack 社区: https://join.slack.com/t/opendevin/shared_invite/zt-2oikve2hu-UDxHeo8nsE69y6T7yFX_BA
[17]开源项目: https://github.com/All-Hands-AI/OpenHands
[18]在线版本: https://www.all-hands.dev/join-waitlist
[19]加入我们的社区: https://github.com/All-Hands-AI/OpenHands?tab=readme-ov-file#-join-our-community
[20]做出贡献: http://nds-ai/OpenHands/blob/main/CONTRIBUTING.md
?
?
?
?
本文同步自于知识星球《AGI Hunt》
星球实时采集和监控推特、油管、discord、电报等平台的热点AI 内容，并基于数个资讯处理的 AI agent 挑选、审核、翻译、总结到星球中。
每天约监控6000 条消息，可节省约800+ 小时的阅读成本；
每天挖掘出10+ 热门的/新的 github 开源 AI 项目；
每天转译、点评 10+ 热门 arxiv AI 前沿论文。
星球非免费。定价99元/年，0.27元/天。(每+100人，+20元。元老福利~）
一是运行有成本，我希望它能自我闭环，这样才能长期稳定运转；
二是对人的挑选，鱼龙混杂不是我想要的，希望找到关注和热爱 AI 的人。
欢迎你的加入！
