<!-- title: 频道定生死：智能体通信三范式 -->

多智能体系统真正的选型战场，已经从"用几个人"挪到了"用什么频道说话"。2026 年的一个关键拐点是协议层开始收敛：Google 主导的 A2A 把 IBM 的 ACP 收编进 Linux 基金会，与 Anthropic 的 MCP 形成"智能体对智能体 / 智能体对工具"的分工；而真正撑住长链路与局部故障的，是 NATS、Kafka 这类事件总线。同步委派、工具式调用、异步事件——这三种通信范式各自的延迟、耦合度和故障隔离能力差异巨大，选错一个，上层拓扑再花哨也是脆的。本文把三范式拆开，给落地与变现的判断。

## 三范式速览：先看频道，再看人数

| 范式 | 代表协议/载体 | 调用模型 | 典型延迟 | 故障耦合 | 最适合 |
|------|--------------|---------|---------|---------|--------|
| 同步委派（Sync Delegation） | A2A（JSON-RPC/SSE/gRPC） | 一方把任务交给另一方，等结果或流式增量 | 亚秒级握手，分钟级任务 | 强耦合，调用方阻塞 | 跨厂商短链路、显式握手 |
| 工具式调用（Tool Invocation） | MCP / Function Calling | 把另一个智能体当成"工具"同步触发 | 与一次 LLM 推理同量级 | 调用方需自己容错 | 单体内嵌子能力、零新基建 |
| 异步事件（Async Event） | NATS JetStream / Kafka / Redis Streams | 发布事件，任意订阅者响应 | 毫秒级投递，解耦 | 弱耦合，可独立重试 | 长流程、多步、需扛局部宕机 |

这张表是后文所有判断的基准。一个经验法则：**链条越长、步骤越多、越要扛局部失败，就越该往表格右侧走**；越是要"一次性把另一家厂商的智能体拉进来干个活"，越该用 A2A 这种显式委派。

## 范式一：同步委派——A2A 协议深拆

A2A（Agent2Agent）是 2025 年 Google 联合 50 多家厂商推出的开放协议，2026 年并入 Linux 基金会，并把 IBM 的 ACP 吸收合并。它的核心思想是把"智能体间的一次合作"建模成一个**显式的 Task 对象**，而不是隐式的函数调用。

A2A 的三个支柱：**Agent Card（名片）** 用于能力发现，托管在 `/.well-known/agent.json`；**Task 生命周期**用 `submitted → working → input-required → completed/failed` 描述状态机；**多传输绑定**支持 JSON-RPC 2.0 over HTTP、gRPC、HTTP+JSON/REST 三种 wire 形态，长任务用 SSE 流式回推增量。

```json
// /.well-known/agent.json —— 智能体名片，A2A 的服务发现入口
{
  "name": "invoice-auditor",
  "description": "核对发票与采购单的一致性",
  "url": "https://audit.internal/a2a",
  "version": "1.2.0",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "skills": [{ "id": "audit", "name": "发票审计" }],
  "authentication": { "schemes": ["OAuth2"] }
}
```

```text
// 委派一次任务，JSON-RPC over HTTP
-> {"jsonrpc":"2.0","method":"tasks/send","id":1,
     "params":{"id":"t-901","message":{"role":"user","parts":[{"text":"核对 INV-7732"}]}}}
<- SSE 流：Task(working) -> TaskStatusUpdate(进度) -> Task(completed, 结果)
```

**优点**：能力发现与身份认证是一等公民，跨厂商互通有标准可言；Task 状态机让"等输入""进行中"这种中间态可观测。**缺点**：本质是同步阻塞语义，调用方要为长任务挂连接或轮询；Task 一旦级联三四层，任一节点失败会沿调用栈向上冒泡，形成"一崩全崩"的链路。**变现/训练营评估**：A2A 是 2026 年企业集成的"新 API 网关"叙事，适合包装成"跨厂商智能体集成实战"训练营，因为它有明确的握手、鉴权、流式回推可供拆解，门槛清晰可教学。

## 范式二：工具式调用——把另一个智能体当 Tool

最省事的范式：不引入任何新协议，把对方智能体封装成一个 function，通过 MCP 或原生 Function Calling 触发。MCP 的 2026 路线图里也明确把"agent communication"列为方向，意味着很多人会用"智能体即工具"的方式跨域协作。

```python
# 把"法务智能体"注册成一个 MCP 工具，主智能体按需调用
@tool(name="legal_review", description="合同条款法务审查，返回风险点")
def legal_review(contract_text: str) -> dict:
    resp = httpx.post("https://legal.svc/review", json={"text": contract_text},
                      timeout=60)
    return resp.json()   # 主智能体把返回值当结构化结果继续推理
```

**优点**：零新基建，复用现有工具调用栈、现有可观测、现有重试逻辑；调试与单体内嵌子能力完全一致。**缺点**：**对方没有身份**，它只是个函数，丧失了"智能体"该有的状态机与多轮交互；调用是阻塞的，超时即失败；当工具数量破百，工具定义本身吃满上下文窗口（这正是"工具定义吃上下文：体积税"已揭示的成本曲线）。**适用边界**：当你需要的是"一段确定性输出"而不是"一个会思考的协作者"，工具式调用最划算；一旦需要多轮协商、状态保持，就该升到 A2A。

**变现点**：这是企业落地最快的姿势，因为不碰组织架构、不引入外部协议治理，适合做"已有单智能体如何低成本协同"的轻量训练营，卖点是把现有 function calling 投资复用到协同场景。

## 范式三：异步事件——事件总线才是生产级骨架

凡是跑过生产的人都会承认：同步委派撑不住三五跳以上的链路。事件驱动架构（EDA）用发布订阅把协作彻底解耦，智能体之间不再"打电话问结果"，而是"往总线喊一嗓子、谁该响应谁响应"。NATS JetStream、Kafka、Redis Streams 是 2026 年多智能体后端的事实选择，配合"黑板模式（blackboard）"——所有中间产物写进一个共享事件流，任何智能体都能读、能补、能纠错。

```text
# NATS subject 设计：按职责分主题，事件即状态
research.crawled     ->  数据智能体发布原始抓取
research.summarized  ->  摘要智能体消费 crawled，发布摘要
review.flagged       ->  审稿智能体消费 summarized，发布问题
orchestrator.*       ->  编排智能体订阅以上全部做总控
```

**优点**：天然解耦，单个智能体宕掉不拖垮整链；事件可持久化重放，等于自带"做错能退"的审计与回滚材料（呼应"做错能退：自主体回滚四栈实测"的诉求）；吞吐与扇出能力远超同步 RPC。**缺点**：增加了一层基础设施与运维心智；事件 schema 演进是长期债；调试时需要全链路追踪，"长跑即迷"的漂移风险在异步链路里更隐蔽。**变现点**：这是真正能交付给企业、扛得住 SLA 的架构，适合做"多智能体上生产"的中高阶训练营，含 NATS 部署、subject 设计、死信队列、事件溯源等硬内容。

## 协议层收敛：ACP 并入 A2A，AGNTCY 接管发现层

2026 年的协议战场不是"百家争鸣"，而是"快速归并"。几个关键信号：

- **IBM ACP 并入 A2A**：IBM Research 的 Agent Communication Protocol（REST 原生、轻量）已宣布成为 A2A 的一部分，提供迁移指南。A2A 借此补齐了 REST 绑定的轻量偏好。
- **AGNTCY（Cisco 主导）做"智能体互联网"地基**：它不做语义协议，而是做**联邦注册表**——跨框架、跨协议、跨注册中心的能力发现，配 SLIM 协议做跨域传输。你可以把 AGNTCY 理解为"DNS + 网关"，A2A/MCP 是"应用层语义"。
- **MCP 固守 agent-to-tool**：MCP 的 2026 路线图把重点放在传输可扩展性、治理成熟度，继续深耕工具侧，不与 A2A 抢 agent-to-agent 的地盘。

收敛的结论很实用：**别再押注小众协议**。Agent-to-agent 押 A2A，agent-to-tool 押 MCP，跨域发现与路由交给 AGNTCY 或自建注册表，长链路后端交给 NATS/Kafka。这套"四件套"已经是 2026 年事实标准，押注它意味着选人、招人、找文档都更省力。

## 拓扑只是上层，频道才是地基

很多人先纠结"用 mesh 还是 hub-spoke 还是 hierarchy"，但这是次序问题。**通信范式决定了拓扑能长成什么样**：

- 走同步委派（A2A）的，天然适合 hub-spoke 或 hierarchical——因为有个显式调用方在做编排，层级关系就是调用栈。
- 走工具式调用的，几乎只能是 hub-spoke，且 hub 必然是那个持有上下文的主智能体。
- 走异步事件的，才能撑起真正的 mesh 与 blackboard——因为节点之间不直接互相调用，而是各自订阅主题，加入退出都不影响他人。

换句话说，"拓扑即命运"那句话只在协议选对之后成立。**协议选错，拓扑是被锁死的**：你不可能在同步 RPC 上跑出 mesh 的弹性，也不可能在事件总线上强加严格的层级时序。先定范式，再画拓扑图，是这个顺序。

## 选型决策树与变现路径

```mermaid
flowchart TD
    Q1{协作是一次性取结果<br/>还是要多轮思考?}
    Q1 -->|一次性| A[工具式调用 MCP/Function Call]
    Q1 -->|多轮| Q2{链路跳数与<br/>可用性要求?}
    Q2 -->|≤2跳, 短任务| B[同步委派 A2A]
    Q2 -->|≥3跳 或 需扛局部宕机| C[异步事件 NATS/Kafka]
    B --> Q3{跨厂商/跨域?}
    Q3 -->|是| D[加 AGNTCY 联邦发现]
    Q3 -->|否| E[内部 Agent Card 注册表]
    C --> F[叠加 blackboard 黑板模式]
    A --> G[复用现有工具调用可观测]
```

落地推荐按场景分三档：**轻量集成**（单体内嵌子能力、低预算）选工具式调用，零基建、两周上线；**企业跨部门协作**（要握手、要鉴权、要审计）选 A2A 同步委派 + 内部注册表，半年内可治理；**生产级长流程**（多跳、需 SLA、需回滚）选 NATS/Kafka 事件总线 + blackboard，这是唯一能扛住"长跑即迷"和"一崩全崩"两种顽疾的姿势，也是真正值得做付费训练营的产品化方向。

变现角度，三范式正好对应三个价位的训练营：工具式是 99 元入门体验营（最快出效果）；A2A 集成是 999 元企业实战营（有明确握手、鉴权、流式回推可拆解）；事件总线生产化是 2999 元架构师进阶营（含部署、subject 设计、死信队列、事件溯源、回滚），后者的客单价与复购率最高，因为它解决的是企业真正付费的"上线即崩"问题。

## 参考来源

1. [A2A Protocol Specification](https://a2a-protocol.org/latest/specification/) — A2A v1.0 规范，定义 JSON-RPC/gRPC/REST 三种传输绑定、SSE 流式、Task 生命周期
2. [Agent2Agent (A2A) GitHub](https://github.com/a2aproject/A2A) — 开放协议主仓，Agent Card 能力发现与 50+ 合作伙伴生态
3. [IBM Research — Agent Communication Protocol (ACP)](https://research.ibm.com/projects/agent-communication-protocol) — 官方声明 ACP 已并入 A2A 并提供迁移指南，是 2026 协议收敛的关键证据
4. [AGNTCY.org — Building the Internet of Agents](https://agntcy.org/) — Cisco 主导的联邦注册表与 SLIM 协议，跨协议智能体发现层
5. [Event-Driven Agent Architectures: NATS, Kafka, Redis Streams](https://callsphere.ai/blog/event-driven-agent-architectures-nats-kafka-redis-streams-communication) — 异步事件范式落地，含 pub/sub、死信队列、黑板模式对比
6. [AI Agent Mesh Architecture: Multi-Agent Coordination Guide (2026)](https://appscale.blog/en/blog/ai-agent-mesh-architecture-multi-agent-coordination-2026) — mesh/hub-spoke/hierarchical/blackboard 四种拓扑与协议层关系

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
