AI Agent 通信协议：多智能体协作的基础

当单个 Agent 无法独立完成复杂任务时，多个 Agent 之间的协作就变得至关重要。而协作的基础，是定义良好的通信协议。

为什么 Agent 需要通信？

单个 Agent 有天然的局限性：上下文窗口有限、工具集有限、专业能力有限。通信让 Agent 系统能够：

单 Agent 的局限：
  - 上下文窗口：一次只能处理有限的信息
  - 工具集：一个 Agent 不可能拥有所有工具
  - 专业知识：一个 Agent 难以精通所有领域
  - 并行能力：单 Agent 只能串行执行

多 Agent 协作的优势：
  - 分工协作：每个 Agent 专注擅长的领域
  - 并行处理：多个 Agent 同时处理不同子任务
  - 知识互补：不同 Agent 拥有不同的知识和工具
  - 容错能力：一个 Agent 失败不影响其他 Agent

消息格式：Agent 之间说什么？

Agent 之间的通信需要标准化的消息格式。一个典型的 Agent 消息包含以下字段：

{
  "message_id": "msg-001",
  "sender": "agent-researcher",
  "recipient": "agent-writer",
  "type": "task_result",
  "content": {
    "task_id": "task-abc",
    "status": "completed",
    "data": {
      "findings": [
        "2024年诺贝尔物理学奖授予了 Hopfield 和 Hinton",
        "表彰他们在人工神经网络和机器学习方面的基础性发现"
      ],
      "sources": ["https://nobelprize.org/..."]
    }
  },
  "metadata": {
    "timestamp": "2026-06-04T10:30:00Z",
    "confidence": 0.95,
    "tokens_used": 1200
  }
}

消息格式的设计原则：

自描述性：消息本身包含足够的上下文信息
可扩展性：新类型的消息不会破坏现有系统
类型安全：消息结构有明确的 Schema 定义
可追溯性：消息 ID 支持链路追踪

通信模式

1. 请求-响应（Request-Response）

最简单的通信模式：一个 Agent 发送请求，另一个 Agent 返回结果。

请求-响应模式：

Agent A（规划者）→ 请求 → Agent B（研究者）
Agent A ← 响应 ← Agent B

适用场景：
  - 简单的子任务分配
  - 工具调用代理
  - 信息查询

优点：简单直接，易于调试
缺点：无法并行，同步阻塞

2. 发布-订阅（Pub-Sub）

Agent 将消息发布到主题（Topic），订阅了该主题的其他 Agent 会收到消息。

发布-订阅模式：

Agent A 发布 "research_complete" 主题消息
  ├── Agent B（写作者）订阅了该主题 → 收到消息
  ├── Agent C（审稿者）订阅了该主题 → 收到消息
  └── Agent D（发布者）未订阅 → 不收到

适用场景：
  - 事件驱动架构
  - 多 Agent 同时响应同一事件
  - 松耦合的系统设计

优点：松耦合，支持并行
缺点：消息顺序不确定，调试困难

3. 黑板模式（Blackboard）

所有 Agent 共享一个"黑板"（共享状态），每个 Agent 可以读取和写入黑板。

黑板模式：

┌─────────────────────────────────────┐
│           黑板（共享状态）              │
│  task: "撰写关于 AI Agent 的文章"      │
│  research: [...]    ← 研究者写入      │
│  outline: [...]     ← 规划者写入      │
│  draft: "..."       ← 写作者写入      │
│  review: "approved" ← 审稿者写入      │
└─────────────────────────────────────┘
  ↑          ↑          ↑          ↑
Agent A    Agent B    Agent C    Agent D

适用场景：
  - 多步骤协作任务
  - 需要共享上下文的场景
  - 工作流引擎

MCP：模型上下文协议

MCP（Model Context Protocol）是 Anthropic 提出的开放标准，用于规范 LLM 应用与外部工具/数据源之间的通信。

MCP 的核心概念：

Server（服务器）：
  提供工具和数据源
  例如：文件系统、数据库、API

Client（客户端）：
  消费工具和数据
  例如：LLM 应用、Agent

通信流程：
  1. Client 发现 Server 提供的能力
  2. Client 调用 Server 的工具
  3. Server 返回执行结果
  4. Client 将结果反馈给 LLM

# MCP Server 示例
from mcp import Server, Tool

server = Server("weather-service")

@server.tool()
def get_weather(city: str) -> dict:
    """获取指定城市的天气信息"""
    # 实际调用天气 API
    return {"temperature": 25, "condition": "晴"}

@server.tool()
def get_forecast(city: str, days: int) -> list:
    """获取未来几天的天气预报"""
    # 实际调用天气 API
    return [...]  # 预报数据

# MCP Client 连接并使用
client = Client("weather-server")
tools = client.list_tools()  # 发现可用工具
result = client.call_tool("get_weather", {"city": "北京"})

A2A：Agent-to-Agent 协议

A2A（Agent-to-Agent）是 Google 提出的开放协议，专门用于不同 Agent 系统之间的通信。与 MCP 不同，A2A 关注的是 Agent 之间的对等通信，而不是 Agent 与工具之间的交互。

A2A 协议的核心组件：

Agent Card（Agent 名片）：
  - Agent 的能力描述
  - 支持的通信方式
  - 端点地址

Task（任务）：
  - Agent 之间传递的工作单元
  - 包含状态（submitted → working → completed）
  - 支持消息和 artifact（产出物）

Artifact（产出物）：
  - Agent 完成任务后的输出
  - 可以是文本、文件、结构化数据

A2A 通信流程：

Agent A（客户端）→ Agent B（服务端）
  1. 发送 Agent Card 请求，了解 B 的能力
  2. 创建 Task，描述需要完成的工作
  3. Agent B 接受任务，开始执行
  4. Agent B 更新任务状态，返回 Artifact
  5. Agent A 接收结果，任务完成

关键特性：
  - 跨平台：不同框架构建的 Agent 可以互相通信
  - 流式支持：支持 SSE 实时推送任务进度
  - 安全认证：内置身份验证和授权机制

MCP vs A2A 对比

特性	MCP	A2A
定位	Agent 与工具/数据源	Agent 与 Agent
通信方向	Client → Server	对等通信
任务管理	无内置任务状态	内置任务生命周期
适用场景	工具集成、数据访问	多 Agent 协作
发起者	Anthropic	Google

设计通信协议的最佳实践

最小化消息大小：只传输必要的信息，减少 Token 消耗
幂等性设计：相同消息重复发送不会产生副作用
超时处理：为每次通信设置合理的超时时间
错误传播：错误信息应该包含足够的调试上下文
版本兼容：新版本的协议应该向后兼容

总结

Agent 通信协议是多智能体系统的基础设施。从简单的请求-响应到复杂的发布-订阅，从 MCP 的工具集成到 A2A 的 Agent 对等通信，不同的通信模式适用于不同的场景。选择合适的通信协议，是构建高效、可靠多 Agent 系统的关键决策。