Agora：一种适用于大型语言模型的可扩展多Agent协议

简介

本研究介绍了 Agora，一个为大型语言模型（LLM）网络设计的元通信协议。Agora 旨在解决代理之间通信时的效率、可扩展性和灵活性之间的三难困境，通过混合使用自然语言和结构化协议，实现高效、可扩展且灵活的通信。

原文：https://arxiv.org/abs/2410.11905

观点

1. 代理通信三难困境：LLM 驱动的代理网络在通信时面临效率、可扩展性和灵活性之间的权衡。
2. Agora 的设计理念：Agora 通过结合不同的通信方法，解决了通信效率、可扩展性和灵活性之间的权衡。
3. 协议文档（PD）的作用：PD 是一个纯文本描述的文档，是 Agora 实现自动化协议协商和实施的核心。
4. 自组织协议的涌现：在大型网络中，Agora 能够促进 LLM 代理之间的自动协商，形成自组织的协议。
5. 成本效益的提升：通过实施 Agora，可以显著降低通信成本，提高网络的成本效益。

核心实现步骤

1. 定义协议文档（PD）：创建 PD 来描述通信协议，使 LLM 能够理解和遵循协议。
2. 实现多层次通信策略：根据通信频率和任务复杂度，选择自然语言、LLM 编写的例程或人工编写的例程进行通信。
3. 自动协商与实现协议：代理之间通过自然语言或 PD 中定义的例程自动协商和实现通信协议。
4. 协议的涌现与共享：鼓励代理生成和共享 PD，以促进自组织协议的涌现和网络的自我优化。
5. 成本效益分析：评估 Agora 协议相对于纯自然语言通信的成本效益。

案例

1. 两个代理的天气预报示例：展示了如何通过自然语言交流到协议协商，再到例程实现，以及如何通过 Agora 降低通信成本。
2. 100个代理的大型网络示例：在一个包含 100 个 LLM 代理的网络中，验证了 Agora 的可扩展性和在复杂任务中的应用效果。

在这个案例中，研究人员通过一个简单的场景演示了 Agora 协议如何在两个 LLM 代理之间实现高效的通信。这两个代理分别是：

• 代理A（Alice）：一个旅游服务代理，需要查询特定日期和地点的天气预报，以便向用户提供服务。
• 代理B（Bob）：一个天气服务代理，能够提供天气预报数据。

通信过程

初始自然语言交流

1. 代理A 的查询：代理A 使用自然语言向代理B 发送查询请求，询问特定日期和地点的天气情况。
2. 代理B 的响应：代理B 接收到查询后，使用自然语言回复天气预报的详细信息。

协议协商与实现

1. 协议讨论：在多次自然语言交流后，代理A 和代理B 开始讨论建立一个标准化的协议来优化通信过程。
2. 协议文档（PD）的创建：双方协商出一个 JSON 格式的协议，其中包含了请求和响应的结构化数据格式。
   • 请求格式：{"date": "YYYY-MM-DD", "location": "string"}
   • 响应格式：{"temperature": number, "precipitation": number, "weatherCondition": "string"}
3. 协议实施：一旦协议得以确立，代理A 和代理B 就分别实现了相应的例程来处理请求和响应。代理A 在发送请求时附带协议的哈希值，代理B 根据哈希值识别并使用相应的处理例程。

成本分析

1. 协议协商成本：协商和实现协议的成本为 0.043 美元。
2. 单次自然语言交流成本：每次自然语言交流的成本为 0.020 美元。
3. 成本效益：当查询次数超过两次时，使用 Agora 协议的成本效益开始超过纯自然语言交流的成本。随着交流次数的增加，Agora 协议的成本效益逐渐显著。

案例结论

通过这个天气预报的案例，研究人员证明了 Agora 协议能够有效地降低通信成本，并提高了通信的效率。代理之间通过自然语言交流开始，随着交流的频繁，逐步过渡到使用标准化的协议进行通信，这不仅减少了对 LLM 的依赖，而且降低了整体的通信成本。此外，该案例还展示了 Agora 协议如何促进代理之间的自主协商和协议实施，为多智能体系统中的通信提供了一个可行的框架。

两个代理之间的协商过程示例

我们报告了 Alice 和 Bob 为传输天气预报协议进行协商的过程。请注意，虽然大语言模型（LLM）使用了 Markdown 风格的格式，但为了便于阅读，我们将 Markdown 语法替换为相应的排版样式。

Alice

你好。我来协商一个用于查询天气预报服务的协议。该服务应接受日期和地点作为输入，并返回当天的预报天气情况、温度和降水量。
在开始之前，我想明确我们这次协商的规则。我们应该专注于设计一个简单且明确的协议，来规定发送和接收消息的具体格式。我们不必担心消息如何传递，并假设实现时将接收一个字符串并返回一个字符串。
首先，我建议使用基于 JSON 的协议。输入消息可以是一个包含两个属性的 JSON 对象：「date」和「location」。输出消息可以是一个包含三个属性的 JSON 对象：「temperature」、「precipitation」和「weatherCondition」。
你对这个提议有什么看法？

Bob

你的提议很好，符合保持协议简单和明确的目标。使用基于 JSON 的协议来处理输入和输出消息是一个不错的选择。以下是协议的更详细规范：
输入消息 输入消息是一个具有以下结构的 JSON 对象：
{
"date": "YYYY-MM-DD",
"location": "string"
}
• date: 一个字符串，表示请求天气预报的日期，格式为 YYYY-MM-DD。
• location: 一个字符串，表示请求天气预报的地点。
输出消息 输出消息是一个具有以下结构的 JSON 对象：
{
"temperature": number,
"precipitation": number,
"weatherCondition": "string"
}
• temperature: 一个数字，表示当天的预测温度，单位为摄氏度（°C）。
• precipitation: 一个数字，表示当天的预测降水量，单位为毫米（mm）。
• weatherCondition: 一个字符串，表示当天的预测天气情况。可能的值为「sunny」（晴天）、「cloudy」（多云）、「rainy」（雨天）、「snowy」（雪天）。
示例
输入：
{
"date": "2023-10-01",
"location": "New York"
}
输出：
{
"temperature": 22.5,
"precipitation": 5.0,
"weatherCondition": "cloudy"
}
如果你同意这个结构，我们可以最终确定协议。

Alice

LLM 回复：我同意提出的协议结构。它与需求高度一致，且简单明了。

Finalised Protocol(最终协议）

名称：天气预报查询协议
描述：用于查询给定日期和地点的天气预报的协议。
输入消息：输入消息将是一个具有以下结构的 JSON 对象：
{
"date": "YYYY-MM-DD",
"location": "string"
}
• date：一个字符串，表示请求天气预报的日期，格式为 YYYY-MM-DD。
• location：一个字符串，表示请求天气预报的地点。
输出消息：输出消息将是一个具有以下结构的 JSON 对象：
{
"temperature": number,
"precipitation": number,
"weatherCondition": "string"
}
• temperature：一个数字，表示该日的预期温度，单位为 °C。
• precipitation：一个数字，表示该日的预期降水量，单位为毫米（mm）。
• weatherCondition：一个字符串，表示该日的预期天气状况。可能的值为 "sunny"（晴天）、"cloudy"（多云）、"rainy"（下雨）、"snowy"（下雪）。
示例
输入：
{
"date": "2023-10-01",
"location": "New York"
}
输出：
{
"temperature": 22.5,
"precipitation": 5.0,
"weatherCondition": "cloudy"
}

总结

Agora 通过引入协议文档（PD）和多层次通信策略，有效地解决了大型语言模型网络中的代理通信三难困境。通过两个案例研究，Agora 展现了其在降低通信成本、提高通信效率和促进复杂任务自动化方面的潜力。这一研究为未来多智能体系统中的通信协议设计提供了重要的理论和实践基础。

普通人的AI入门指南

帮助你以低成本、零基础学会如何利用AI工具。AI就像办公软件一样，是每个人的必备技能。 掌握AI会让你在求职中占据优势，在未来的工作和学习中事半功倍。

查看详情>