单智能体更简单、更易于维护。
最近，「多智能体系统」是人工智能领域最热门的流行词之一，也是开源框架 MetaGPT 、 Autogen 等研究的焦点。
但是，多智能体系统就一定是完美的吗
近日，来自卡内基梅隆大学的副教授 Graham Neubig 在文章《Don't Sleep on Single-agent Systems》中强调了单智能体系统也不可忽视。
Graham Neubig 从以下几个方面展开：
当代 AI 智能体发展的元素，包括大语言模型、提示以及动作空间；
多智能体系统示例；
多智能体系统存在的问题；
如何从使用多个专门的智能体过渡到一个强大的智能体，以及一些需要解决的问题。
CMU 机器学习和计算机系助理教授陈天奇对这项研究进行了转发并评论：「这是一篇关于如何让单智能体系统更强大的深刻见解，对机器学习系统也有很好的启示。提示前缀缓存将成为与其他一般推理优化技术相互作用的一项关键技术」。
基于 LLM 的智能体
大多数智能体都是基于大语言模型构建的，如 Anthropic 的 Claude 或 OpenAI 的语言模型。但语言模型不足以构建一个出色的智能体，构建一个智能体至少需要三个组件：
大语言模型 LLM；
提示：可以是用于指定模型一般行为的系统提示，或者从智能体周围环境中提取的信息类型；
动作空间：上述两项是研究者提供给 LLM 的辅助工具，以便智能体在真实世界中产生动作。
一般来说，当涉及多智能体系统时，至少要改变这三个组成部分中的其中一个。
多智能体示例
假设你正在构建一名 AI 软件开发助手，这里作者以 CodeR 为例，这是一个用于 AI 软件开发的多智能体框架。它包括多个智能体，所有智能体都使用相同的底层 LM，但提示和动作空间各不相同：
管理器（Manager）：该智能体的提示指定它应该为其他智能体编写一个规划来执行，以及输出规划的动作空间；
复现器（reproducer）：该智能体有一个提示，告诉它重现该问题，以及一个将代码写入重现错误文件 reduce.py 的动作空间；
故障定位器（Fault Localizer）：该智能体有一个提示，告诉它找到导致错误的文件，以及一个使用软件工程工具进行故障定位和列出文件以供以后使用的动作空间；
编辑器（Editor）：该智能体有一个提示，用于接收复现器和故障定位器的结果，并有一个动作空间，允许它对文件进行编辑；
验证器（Verifier）：此智能体具有提示，可接收其他智能体的结果，以及输出问题是否已解决的动作空间。
这是构建一个系统时所需要的结构，但是在构建这样的系统时存在一些困难。
多智能体系统存在的一些问题
在构建多智能体系统时，你可能会遇到许多问题，比如：
获得正确的结构：多智能体系统通过添加结构来解决问题。当智能体面临的问题与指定的结构完全匹配时，效果会很好，但问题是如果不匹配怎么办？
上下文信息的传递：多智能体系统通常在多个智能体之间传递信息，但这可能是信息丢失的原因。例如，如果故障定位器仅将其摘要信息传递给其他智能体，则通常会导致重要的上下文信息丢失，而这些信息可能对下游智能体有用。
可维护性：最后，这些智能体通常都有自己独立的代码库，或者至少有独立的提示。因此，多智能体系统可能拥有更大、更复杂的代码库。
有趣的是，很多这些挑战也适用于人类组织！我们都有过这样的经历：团队组织混乱，沟通不畅，或者当某个成员离开时，无法维持必要的技能。
如何打造出色的单智能体系统
人们为什么要打造多智能体系统？一个需要说明的重要原因是：专用于特定任务的智能体的表现通常很好，只要有合适的结构和工具，它们就能很好地完成相应的任务。
单智能体有能力竞争吗？
可能比我们预想的还更容易一些，作者表示这里已经有一个很好的原型：https://github.com/All-Hands-AI/OpenHands/tree/main/agenthub/codeact_agent
下面我们就来看看，要打造出优秀的单 LLM、单动作空间和单提示工程技术，需要些什么。
单 LLM：这是相对比较容易的部分。近段时间已经出现了一些表现出色的通用 LLM，包括 Claude 和 GPT-4o 等闭源模型以及 Llama 和 Qwen 等开源模型。虽说这些模型也不是万能的，但它们也确实能完成多种多样的任务。就算它们缺乏某个功能，也可以通过持续训练来增添，同时不会对其它功能产生太大影响。
单动作空间：这也不难。如果我们有多个使用不同工具的智能体，那么我们可以 (1) 为模型提供相对通用的工具，以帮助它们解决问题；(2) 如果不同的智能体有不同的工具组合，则可以将他们连接起来。比如，在 OpenHands 中，可以向智能体提供写代码、运行代码和执行网络浏览的工具。这样的通用方法可让模型使用为人类开发者开发的软件工具，从而增多它们的功能，做到其它多智能体能做到的事。
单提示工程技术：这是比较困难的地方！我们需要确保智能体在如何解决任务上获得正确的指示，同时从其环境中获得正确的信息。
下面给出了两个选择：
将所有提示词连接起来使用：如果我们有一个多智能体系统，要使用 10 个不同的提示词，那么为什么不将它们连接组合到一起呢？近期的长下文模型已经有能力处理多达几十万 token 了，比如 Cluade 能处理 20 万 token，而 Llama 是 12.8 万。OpenHands 也使用了此方法。但这种方法也有一些缺点。首先是成本，更长的提示词需要更多金钱和时间，不过现在有一些技术（比如 Anthropic 的提示词缓存技术）可以降低其成本。这种方法的另一个缺点是，如果提示词太多，则 LLM 可能无法关注到重点，但随着模型能力提升，LLM 在确定长上下文中的重要信息方面越来越强了。
检索增强式提示：另一种可能的选择是使用检索。如同检索增强式生成（RAG）系统一样，可以出于效率或准确度的目的对长上下文进行裁剪。在选择提供 LLM 的示例方面，这里有一些研究进展：https://arxiv.org/abs/2209.11755
总结
本文并不是说多智能体就没有用武之地了。比如在一个智能体可以访问专有信息，而另一个智能体则代表了另一个人的情况下，多智能体系统肯定大有作为！
本文的目的是批判性地思考让系统更加复杂这一趋势。有时候简单就是最好的 —— 有强大的模型、强大的工具和多种多样的提示词就足够了。
参考链接：https://www.all-hands.dev/blog/dont-sleep-on-single-agent-systems