LLM 智能体的通信协议

高效的多智能体系统不仅需要单个智能体的能力。它们能否良好运作，取决于智能体如何交流。智能体间非结构化的自然语言交流可能导致模糊不清、效率低下以及协调失败。因此，设定清晰的通信协议是设计实用多智能体LLM系统的一项基本工作。协议确立了管理消息交换的约定规则，确保智能体能准确理解彼此的意图和信息。

智能体通信协议的核心组成部分

设计协议需要明确几个重要方面：

1. **消息结构：**智能体之间交换的每条消息都应遵循预设的格式。这种结构通常包含必要的元数据以及实际内容。常见字段包括：

   • sender_id：发送消息的智能体的唯一标识符。
   • recipient_id：预期接收者的标识符。可以是特定智能体ID、群组ID或广播地址。
   • message_id：消息本身的唯一标识符，用于追踪、关联（例如，将响应与请求关联）和去重。
   • timestamp：消息生成或发送的时间，对于排序和调试很重要。
   • protocol_version：允许通信标准随时间演变。
   • message_type 或 intent：一个指示消息的交流行为或目的的字段（例如，QUERY_DATA、TASK_ANNOUNCEMENT、REPORT_STATUS、PROPOSE_PLAN）。这使得智能体能够迅速将消息转发给合适的内部处理程序。
   • content 或 payload：实际传达的信息。其格式需要仔细考虑。

2. 内容序列化：content 字段需要一个所有参与智能体都能解析和生成的统一格式。常见选项包括：

   • **JSON (JavaScript 对象表示法)：**可读性好，支持广泛，LLM易于处理和生成，尤其是在有函数调用或结构化输出功能的情况下。常是LLM智能体系统的默认选择。
   • **YAML (YAML 不是标记 (token)语言)：**同样可读性好，对于复杂的嵌套结构可能比JSON更简洁。解析可能稍重。
   • **Protocol Buffers (Protobuf)：**由Google开发的二进制序列化格式。在大小和速度方面效率高，强制执行严格的模式。可读性较差，需要模式编译步骤，但非常适合性能要求高的应用或进程间通信。 选择取决于可读性、LLM易用性、性能和模式严格性之间的权衡。对于许多LLM多智能体系统应用，JSON提供了良好的平衡。

3. **消息类型（执行语/意图）：**为 message_type 定义受控词汇可使消息的解释标准化。受言语行为理论和FIPA ACL等智能体通信语言（ACL）的启发，这些类型定义了消息的语用功能。例如：

   • REQUEST：请求另一个智能体执行一个动作。
   • INFORM：提供信息或陈述一种观点。
   • QUERY_IF：提出一个是/否问题。
   • QUERY_REF：请求某个引用的值。
   • PROPOSE：提议一个行动或计划以供接受/拒绝。
   • ACCEPT_PROPOSAL：同意先前提出的提议。
   • REJECT_PROPOSAL：不同意先前提出的提议。
   • SUBSCRIBE：请求关于特定事件或主题的通知。 使用标准化类型简化了智能体逻辑，因为智能体可以根据声明的意图改变行为，而无需复杂的NLP从内容负载中的非结构化文本中推断意图。

4. **寻址与路由：**协议必须明确消息如何送达其预期接收者。

   • **直接寻址：**向特定 agent_id 发送消息。
   • **广播：**向系统中的所有智能体发送消息（由于可能产生开销，请谨慎使用）。
   • **多播/群组寻址：**向预定义的一组智能体发送消息（例如，所有具有“规划者”角色的智能体）。
   • **基于角色的寻址：**向当前承担特定角色的智能体发送消息，而无需知道其具体ID。 底层基础设施（例如，中央消息代理，如RabbitMQ/Kafka，或直接点对点连接）影响这些寻址方案的实现方式。

常见互动模式

协议有助于智能体之间形成特定的互动模式：

• **请求-响应：**最简单的模式。智能体A发送 REQUEST 消息，智能体B处理并回复 INFORM（结果）或 FAILURE 消息。

基本请求-响应互动流程。

• **发布-订阅（Pub/Sub）：**将信息生产者（发布者）与消费者（订阅者）分离。智能体订阅特定主题（例如，系统警报、市场数据更新）。当智能体向主题发布消息时，消息代理将其分发给所有当前订阅者。这对于传播状态变化或事件非常有效，且无需直接耦合。

• **契约网协议（CNP）：**一种更复杂的分布式任务分配模式，常用于能力分散在智能体之间的情况。

  1. **任务公布（征求提案）：**一个管理者智能体广播任务描述。
  2. **投标（提案）：**有能力的智能体（承包者）评估任务并提交投标（提案），可能包含成本或预估时间。
  3. **授予（接受/拒绝提案）：**管理者评估投标并将任务授予一个或多个承包者，通知获胜者（接受提案）和落选者（拒绝提案）。
  4. **执行与报告（告知/失败）：**选定的承包者执行任务并报告结果（告知）或失败（失败）。

简化版契约网协议互动流程。

为LLM智能体设计协议

在专门为基于LLM的智能体设计协议时，请考虑以下因素：

• **LLM可解析性：**所选的消息结构和序列化格式（通常是JSON）必须易于被智能体的LLM核心解析并生成。在此使用LLM的函数调用或结构化输出功能非常有效。模式应明确定义，并可能在提示或系统指令中提供给LLM。
• **清晰度与灵活性：**虽然结构化类型（如 告知、请求）是有益的，但 content 负载仍可能包含自然语言元素。协议设计需要在可靠处理所需的结构与复杂通信所需的灵活性之间取得平衡。例如，一个 请求 消息可能包含结构化参数 (parameter)，但也包含用于具体指令的自然语言字段。
• **错误处理：**定义协议层面的错误处理。如果消息格式错误、接收者不存在或请求超时，会发生什么？包含特定的错误消息类型（例如，消息格式错误、智能体不可用），如果需要，可使用确认机制（ACK）来保证传递。智能体必须被设计成能够妥善处理这些错误情况。
• **上下文 (context)管理：**需要多少对话历史？在每条消息中包含完整的历史记录效率低下。协议应利用 消息ID 和 关联ID 字段来关联相关消息。智能体可能需要访问共享内存或日志，根据这些ID检索相关上下文。
• **安全性：**在智能体可能不完全受信任的系统中，协议可能需要包含用于身份验证（验证发送者身份）、授权（检查发送者是否被允许发送此消息类型或请求此操作）和消息完整性（确保消息未被篡改）的机制。

选择或设计合适的通信协议对多智能体LLM系统能否成功有很大影响。它决定了智能体如何协调、分享信息，并最终实现共同目标。协议应具备足够的表达力以满足必要的互动，同时结构化程度也要足以保证可靠性，并使LLM能够有效参与。要构建可扩展的系统，需认真考量消息结构、序列化、消息类型、互动模式以及LLM集成。