SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

模型上下文协议和 Agent 通信协议,一端连模型和工具,另一端连 Agent 和 Agent

模型上下文协议定义了一个模型如何发现、连接和使用外部工具和数据源的标准化接口——它解决的是「模型怎么接工具」。Agent 通信协议定义了多个 Agent 之间如何交换消息、协商任务和同步状态——它解决的是「Agent 之间怎么对话」。MCP 是模型面向资源的输入输出通道,Agent 通信协议是多智能体协作的交互链路,把两者混为一谈等于把电话线当成会议规则。

寓言

朝廷有两条驿道,一条送给养,一条传军令

边关前线驻着三支大军,指挥中枢设在后方五百里的元帅府。后勤系统每天需要知道三样东西:各营的粮草存量、马匹状态和箭矢储备。于是元帅府设了一条「给养驿道」——沿途每隔八十里建一个中转站,供给车到了中转站,凭令牌提物资、签收据、更新库存账目。这条驿道的核心功能是让资源需求方(各营)和资源提供方(中转站)之间有一条标准化的交互通道。

同时元帅府还有一套完全不同的通信体系:「军令鸽道」。元帅府和三位将军之间传令用的是飞鸽加密信筒,将军与将军之间的协同调动也走同样的鸽道。鸽道有自己的一套协议:传令内容按紧急度分级、接收方必须回执、一条军令可以同时抄送多路。这套体系的核心功能是让多支决策单元之间能够高效地交换信息并协同行动。

开战后第三个月,出现了组织混乱。负责给养的粮草官接到一个重要任务:调整三营的粮草优先级,把第一营的口粮先调给正在攻打隘口的第三营。粮草官把调整令写了,但不知道该走哪条渠道——粮草中转站你调整物资就行,但三个营之间的协同博弈需要在将军层面同步状态。

元帅府复盘时发现,粮草官的错误在于把一个「将领之间的协同决策」当成一个「资源通道的调整操作」。重新分配粮草这个动作只靠给养驿道完全可以执行到位,但三位将军之间关于「为什么这么分配、什么时候恢复正常分配」的信息同步必须走鸽道。一个走对了路,一个走错了路,结果第一营的将军因为信息缺失做出了错误判断。

后来元帅府在驿道管理规程里加了一条铁则:涉及多营协调的信息走鸽道,涉及单一资源和器械的交互走给养驿道,两者不得混用。同时规定粮草官不能独自发送涉及兵力协同的调整令——这类命令必须先过将军参谋署,拿到各营确认回执后才能执行。

这条铁则很快救了一次急。第三营夜里缺箭,给养驿道能立刻调出箭矢;但若要第一营让出弓手,就必须走鸽道,让两位将军同时知道风险、时间和补偿安排。前者是取物,后者是协同,路不一样。

元帅后来把两张路线图挂在大帐门口:左边是给养驿道,画的是仓、车、令牌和签收;右边是军令鸽道,画的是将军、回执、抄送和会签。粮草官再也不敢说「反正都是送信」,因为送物资和协调人心,从来不是同一件事。

模型上下文协议

定义模型与外部工具和数据源之间的标准化交互方式。客户端发现服务器端提供的工具列表,发出请求,接受响应。解决的是单个模型的能力扩展问题,本质是 client-server 架构。

Agent 通信协议

定义多个 Agent 之间交换消息、协商任务和同步状态的规则集合。解决的是多智能体协作的通信和协调问题,通常需要消息路由、会话管理和共识机制。

故事对应

  • 给养驿道:MCP——模型与工具/资源之间的标准化交互通道
  • 飞鸽加密信筒:Agent 通信协议——多决策单元的协同消息系统
  • 中转站凭令牌提物资:MCP 的 client-server 调用模式
  • 鸽道传令、分级、回执:Agent 通信中的消息路由和确认机制
  • 粮草官走错了渠道:将跨 Agent 协同需求误当成资源操作
  • 第一营将军不知情写弹劾文书:信息缺失导致错误判断——缺乏 Agent 间同步
  • 元帅府的铁则:两类渠道不可混用——区分单一资源调用和多主体协调

落到多 Agent 系统架构设计

设计一个包含多个 Agent 的系统时,先画通信拓扑图,区分两种线条。实线表示 MCP 连接——单个 Agent 到它需要的工具和数据源。虚线表示 Agent 通信协议——Agent 到 Agent、Agent 到编排器、Agent 到共享状态。如果你发现自己的架构图上只有 MCP 连接而没有 Agent 间的虚线,那么 Agent 之间的协调只能靠共享文件或全局变量——这在高并发场景下迟早崩。选型 Agent 通信协议时优先考虑消息队列系统或已有的多 Agent 框架提供的通信层,不要试图在 MCP 的请求响应模型上手动加协调逻辑。