第 12 章 · Agent 分布式通信

核心观点 + 逻辑框架（运行篇 · 通信语义与选型）

原书章节 ↗

▍速览

一句话版（开场，约 20 秒）

分布式通信要回答的不是该用哪个中间件，而是通信语义的选择及其后果：把业务标识、必要状态和结果获取从连接与执行实例中剥离出来，让人机、能力、协作、内构四个通信面在请求—响应、流式、任务句柄、持久通道四档语义里各取所需。

一段话版（完整表达，约 90 秒）

Agent 从单进程走向分布式后，通信本身成为需要设计的对象。判断依据是两个坐标：按通信双方身份划分的四个通信面，与按时间、空间耦合度划分的四档交互语义——人机面要增量可见与随时打断，能力面要包容毫秒级查询与分钟级任务，协作面要承载长任务交接，内构面要扛住海量会话通道的元数据成本。选型的起点是为每个通信面选择成本与风险可接受的最低充分语义，而不是统一采用最高档位。无论落在哪一档，每段通信都要回答六个问题：标识、顺序、投递与去重、续传点、生命周期、背压。协议层在持续分化：MCP 走向无状态核心、把状态责任上推应用层显式任务句柄，A2A 强化完整任务生命周期——协议无状态不等于业务无状态，流式输出也不直接决定任务能否离线运行。最终让任务状态、检查点、消息日志与消费位置各有归属，业务标识独立于连接存在。

• 命题 让必要状态独立于连接存在：任务状态/检查点/消息日志可关联、不可替代
• 坐标 四通信面 × 四档交互语义交叉成选型地图
• 边界 同步的四项优势与三项判据；异步三形态与代价清单
• 收敛 MCP 无状态核心与 A2A 任务生命周期反向演进，由通信形态决定
• 落点 通道键决定治理粒度；每通信面从最低充分语义起步

收尾

任务不属于某台机器，机器只负责当前这一棒——通信设计让业务标识、必要状态与结果获取独立于连接与实例存在。

▍逻辑框架（记忆卡片）

① 命题：四个假设重检与一条主线

• 调用耗时是否有界：包含探索、外部处理和审批的任务可能持续很久，长任务不能只靠延长同一个 HTTP 请求承载
• 会话是否依赖当前连接：会话可跨多次连接存在，连接只是当前的数据传输路径；节点更替后需重新定位任务与订阅位置
• 等待期间占用哪些资源：模型调用与人工介入增加等待，异步 I/O 减少线程占用、持久化等待可进一步释放执行资源
• 通信端点是否会变化：扩缩容、故障接管与沙箱重建会改变物理地址，契约需把业务标识与物理端点分开

主线：让必要状态独立于连接存在。三类内容——业务任务状态、执行检查点、消息日志与消费位置——可关联、可同基础设施承载，但不能互相替代；消息重播不自动恢复进程，也不自动撤销或去重外部操作。

② 参考模型：四个通信面

• 人机面（AG-UI）：用户/前端 ↔ Agent；增量 token 流、前端流式、待办收件箱、人在回路审批；核心矛盾：要增量可见与随时打断，而前端连接最不可靠
• 能力面（MCP）：Agent ↔ 工具/数据；垂直方向工具调用；核心矛盾：工具耗时分化极大，毫秒级查询与分钟级任务共用一套协议
• 协作面（A2A）：Agent ↔ Agent；水平方向任务委派；核心矛盾：任务天然长跑，点对点拓扑下两两集成与信任随数量组合增长
• 内构面（无标准协议）：服务端组件之间；消息队列/事件流/内部 RPC；核心矛盾：海量会话通道的元数据成本与多租户隔离

通信面决定契约由谁定义与标准化程度；协议只提供其中部分契约，持久化、路由、授权与恢复仍需实现补齐。

协议层：AG-UI / MCP / A2A · 内构面为分析而设，非行业标准分层

③ 参考模型：四档交互语义

• S1 请求—响应：一次请求取得结果；响应期内耦合、依赖可达端点；解决短调用与直接反馈，不自带长任务查询与事件续传
• S2 请求域流式：一次请求中逐步返回事件；当前流依赖连接；解决增量可见与进度反馈，单凭流不能保证断连后补齐
• S3 任务句柄：提交后凭标识查询或订阅；执行与首次请求解耦；解决长任务查询、离线取回结果，不自动保证事件重播或业务恢复
• S4 持久通道：按通道订阅、确认和补读；生产与消费解耦；解决推送、削峰、重播与通道治理，仍需应用状态、幂等与运维机制

两轴常见组合（表 12-4）：

• 人机面：S1 表单式问答｜S2 token 流、前端流式协议｜S3 收件箱与任务列表｜S4 多端接入同一会话
• 能力面：S1 工具调用｜S2 秒级任务的请求内流式升级｜S3 MCP Tasks 扩展｜S4 需要额外的持久通道契约
• 协作面：S1 简单交互的同步返回｜S2 A2A 流式消息｜S3 A2A 任务加状态查询与推送通知｜S4 消息中间件承载的 Agent 网格
• 内构面：S1 组件间内部 RPC｜S2 服务端组件间流式转发｜S3 任务表加认领机制｜S4 会话级通道、事件流

档位是谱系，不是成熟度等级；一个系统可同时使用多档语义。

流式结束 ≠ 任务结束 · 流只说明结果如何到达，不说明任务是否独立于连接

④ 通信契约六要素

• 标识：会话、任务、轮次、消息各自的标识与从属关系；任务标识直接绑定消息线程标识会限制后台执行与跨渠道续接
• 顺序：保序范围通常可限制在任务或会话内（请求侧以会话标识为分区键），不承诺跨会话全局顺序
• 投递保证：至少一次/至多一次/恰好一次的选择 + 配套去重键；同一系统不同通道可取不同强度
• 续传点：断连或换节点后从何处继续，与任务查询能力分开声明
• 生命周期：通道与任务的创建、过期与销毁规则；回收前核对活跃任务、未确认消息与必要恢复窗口
• 背压：过载时减速而不是崩溃；协议错误与限流信号、客户端重试、网关准入、消息队列共同参与

⑤ 同步通信及其边界

四项难以替代的工程优势：

• 控制路径直接：输入、返回值与错误关联在一次调用中；跨进程仍可能超时或结果未知，不能省略幂等与追踪
• 进程内调用栈连续：单机进程内同步调用栈即是最完整的失败上下文；跨进程同步同样有分布式追踪问题
• 运维复杂度低：不引入队列、事件流或任务表，就没有保留策略、消费组、DLQ、重投风暴等新失效模式
• 成本结构简单：短调用免消息驻留、保留与消费管理开销

三项选择依据：能否在约定时限内完成（协调连接/空闲/总截止时间；不可预测长等待需独立任务查询与恢复路径）｜链路是否需要独立伸缩与削峰（消息或任务队列分离生产与消费速率）｜失败结果是否可确认（同步也可用幂等键与状态查询；异步化不消除外部副作用的确认责任）。只在实际需要的链路增加机制。

⑥ 异步通信的三种形态与代价

• 任务句柄：凭稳定标识稍后查询任务状态与结果；结果的持久性、查询保留期与故障恢复能力由服务端分别承诺，不能仅凭返回 Task ID 推导
• 事件驱动：围绕已发生的状态变化触发后续处理；引入消息中间件不自动得到可重放审计或业务状态恢复；以事件重建业务状态须记录完整状态变化、版本与外部结果
• 持久通道：四条最小语义——命名通道 / 续传点（通道,序号）/ 结果保留 / 未确认重投（消费者仍需幂等）

代价清单：每跳延迟（传输/持久化/排队，与端到端时延目标一起测量）｜幂等要求（定义幂等键、恢复前核对外部系统状态）｜保留策略（按容灾回溯与审计需求设定）｜故障传播（无超时编排边放大失败）｜可观测缺口（调用栈不再连续，全链路追踪加统一关联）。

⑦ 能力面：MCP 传输四代演进

• 2024-11-05：JSON-RPC 2.0，stdio 与 HTTP 加事件流双端点；状态=会话级常驻推送通道；代价=需管理服务端推送连接
• 2025-03-26：Streamable HTTP 单端点；状态=会话标识头 + 可选事件重放标识；代价=负载均衡后需粘性会话或共享会话存储
• 2025-11-25：保留会话与握手；首次引入实验性任务机制
• 2026-07-28：无状态核心；状态=每请求元数据 + 应用层显式任务句柄；重放责任下沉应用层；变更通知经 subscriptions/listen 按类型订阅

协议无状态 ≠ 应用无状态：协议放弃承担状态，状态责任转移到应用层显式句柄并由应用选择持久化后端；传输续传与应用恢复是两层责任——核心传输不提供 SSE 重播，重新提交调用需处理幂等与未知结果。

⑧ 协作面：A2A 任务生命周期与两协议反向

• 设计取向：为可能长时间运行的任务与人在回路交互而设计；核心工作单元不是一次性函数调用，而是有状态、可长跑的任务

• 任务模型：已提交/执行中/需要输入/需要授权/完成/失败/取消/拒绝；产物经 Artifact 关联；保留由服务端契约约束

• 两种机制分工：流式消息=S2（作用域限单次请求、流完即断，适合进度可见）；推送通知=S3 通知增强——是"去拉取"的触发器，结果可寻址性仍由任务查询保证

• 左：MCP：垂直、工具调用、无状态核心、状态上推应用层、削弱会话状态

• 右：A2A：水平、任务交接、完整生命周期状态机、强化任务

两协议走向相反方向由通信形态本身决定：一次能力调用 vs 持续任务交接，不是路线优劣；编排 Agent 经 A2A 委派、专业 Agent 经 MCP 调工具，可组合使用。

人 人机面：12.8 落地要点（观察视图 · 远程控制 · 持久收件箱）

• 任务在服务端独立存在，前端连接只是当前观察视图；断连只影响可见性、不影响任务推进；重连经续传点（状态快照 + 增量事件）补齐遗漏事件，前端副本不是任务权威状态
• Claude Code Remote Control：多客户端接入同一会话视图，断开只关闭观察窗口、会话继续；定位是 "a client for Claude Code sessions rather than a place where code runs"；依赖 Anthropic 自有前端协议，并非 AG-UI 语义
• 执行期引导可走请求域流式（仅在会话活跃时有意义）；阻塞式审批必须走持久化机制——等待人工响应时间不可预测；待办收件箱按"需要输入 / 错误 / 已完成"三类组织
• AG-UI 事件模型与扩展仍在演进：采用时固定规范及 SDK 版本，区分已实现能力与草案；事件格式、运行中断与消息续传是不同能力
• 精确补读需另约定事件标识、保留窗口与重复处理；只需恢复当前视图时可重新获取状态与消息快照；是否持久化、如何鉴权、输入到达后如何继续由服务端实现

人机面默认 S2；存在阻塞式人工审批，或需要跨设备、跨会话续看进度时升至 S3 或 S4。

⑨ 内构面：通道键决定治理粒度 + 手脑分离

• 三个案例通道键：会话标识（智能语音：请求保序+响应隔离）｜用户×模型 / 用户（网关限流/资产中心：按用户治理、单用户挂起不牵连他人）｜会话+环境（Qoder：控制面与执行面异步交接）
• 手脑分离四层（Qoder Cloud Agent）：脑—Agent Runtime（决策与推进）｜路—MQ（保序投递、承担等待与背压）｜手—Sandbox Worker（按需计算、完成即释放）｜底—Session State（持久化事实、支撑挂起恢复与重放）
• 规模化代价：每会话一个标准主题→元数据先于业务压垮控制面；反模式=会话与常驻工作进程绑死（"宠物"：有名字、有状态、不能替换）
• 轻量通道（LiteTopic）：按业务标识声明并挂载到少量父主题，服务端仅存字符串键 + 轻量索引；首次发送自动创建、双向索引精准投递、空闲存活自动回收、单通道挂起释放线程；就绪集合由写入 / 确认 / 解锁事件填充，公平排空防止饥饿；消费分通配符订阅（批量接入父主题）与显式订阅（按单通道订阅）两种模式

选型决策：每通信面取最低充分语义起步——人机面默认 S2、能力面默认 S1、协作面持续交接 S3、内构面按职责 S1/S3；升级由具体触发条件驱动，不统一上最高档位。

会话常驻、计算流动、状态可续 · 协议无状态 ≠ 业务无状态

▍逻辑全景图（四通信面 × 四档语义 → 契约要素 → 选型决策）

两轴交叉构成选型地图：按通信双方身份分四个通信面，按时间与空间耦合度分四档交互语义；每段通信用六要素检查，选型从最低充分语义起步

• 人机面 AG-UI
• 能力面 MCP
• 协作面 A2A
• 内构面 无标准协议

示意 · 按第 12 章正文重构：两轴坐标 + 契约六要素 + 协议演进与内构面落点

▍书中关键图（SVG 重绘版·示意）① 四档交互语义谱系

档位	交互形态	时间耦合	空间耦合	状态	解决的问题
S1 请求—响应	一次请求取得结果	响应期内耦合	依赖可达端点	临时调用状态	短调用与直接反馈
S2 请求域流式	逐步返回事件	当前流依赖连接	依赖可达端点	当前流	增量可见与进度反馈
S3 任务句柄	凭标识查询 / 订阅	执行与请求解耦	依赖可查询入口	持久任务与结果引用	长任务查询与离线取回
S4 持久通道	订阅、确认与补读	生产与消费解耦	逻辑通道关联	消息日志与消费位置	推送、削峰、重播与治理

流式输出不直接说明任务是否独立于连接存在；需分别检查：是否有独立于连接的任务句柄、是否有事件续传位置。

示意 · 按原书表 12-3 四档交互语义谱系重绘

▍书中关键图（SVG 重绘版·示意）② 智能语音交互：会话通道承载请求保序与响应隔离

示意 · 按原书 12.7.1 智能语音交互案例重绘（Request 分区顺序 Topic + Response LiteTopic）

▍书中关键图（SVG 重绘版·示意）③ 手脑分离：决策与执行拆到不同进程

示意 · 按原书 12.7.2 手脑分离案例（Qoder 四层 + Anthropic 三抽象）重绘