MCP 专为云设计，边缘则遵循不同规则

来源: Agentic AI Foundation (AAIF)
作者: Agentic AI Foundation
发布时间: 2026年5月19日 05:57:58
原文链接: https://aaif.io/blog/mcp-was-designed-for-the-cloud-the-edge-has-different-rules/

---

深入了解 Kierra Dotson 在 MCP Dev Summit North America 2026 上的演讲

目前 MCP（模型上下文协议）几乎所有的应用都发生在云环境中，运行在拥有充沛计算预算的大型模型上。制造车间、医疗设备、车辆、智能手机——这些是下一波 AI 部署的目标领域。

Further 公司的 AI 战略总监 Kierra Dotson，希望 MCP 社区能够理解：在设备上运行一种为稳定、高带宽基础设施设计的协议意味着什么——如果一个数据包丢失，可能导致诊断失败，或者让一个缺陷产品通过生产线。

MCP 做出的三个假设，边缘环境全都打破

MCP 当前设计在云环境中运行良好，是因为它默认了三个条件：

1. 高带宽
2. 持续连接
3. 廉价算力

在一个拥有 10 万 token 上下文窗口的大型云模型上，冗长的 JSON 负载（payload）只是个小麻烦。而在一个运行在受限设备上、上下文窗口只有 4-8K 的小型语言模型（Phi、Llama、Gemma）上，这就是一个结构性问题。一个标准的 MCP 工具模式（tool schema）可能还没等到第一个真正提示词到来，就已经消耗掉边缘模型大半的可用上下文。

Kierra 的演讲提出了三个具体建议，让 MCP 适应那些不满足上述假设的环境。每个建议针对不同的失效模式，三者共同构成了她所说的“边缘原生 MCP 栈”。

1. 二进制 MCP：压缩线路数据

第一个建议针对的是线路数据格式本身。

JSON-RPC 是人类可读的，这在开发阶段很有帮助。但一个生产线边缘设备每分钟处理上百次工具调用，它不需要人类可读的负载（payload）。它需要的是快速处理数据。

Kierra 的建议是用协议缓冲区（protocol buffers，protobuf） 替代线路上的 JSON。protobuf 是 Google 为微服务通信开发的二进制序列化格式。一个典型的 JSON 格式 MCP 工具调用占 2-5KB。同样消息编码为 protobuf 后压缩到约 200 字节，负载大小减少了 10-25 倍。二进制反序列化也比 JSON 解析快 10-50 倍，因为结构是预编译的，而不是在运行时扫描。

在工厂车间的实际好处是：更小的负载意味着更快的往返时间、更低的 CPU 负载，以及更少的无线电硬件传输耗电。在高吞吐量下，这些优势会迅速叠加。

通过连接建立阶段的能力协商步骤，保持了向后兼容性。如果服务器支持二进制 MCP，它就选择使用；否则回退到 JSON。语言模型从不会看到任何二进制处理过程。从它的视角看，它接收到的是一个结构化的工具结果，和以前一样。

关键约束：只有当主机（host）和服务器（server）位于不同物理设备上，且通过受限链路（BLE、ZigBee、拥塞的 Wi-Fi、蜂窝网络）连接时，二进制 MCP 才真正值得。如果是在同一台机器上通过 Unix 套接字通信，开销差异可以忽略不计。

2. 弹性传输与会话连续性

第二个问题是：即使消息变小了，如果网络断开，仍然会完全失败。

SSE（Server-Sent Events）需要一个持久的 HTTP 连接。一次网络抖动就会迫使客户端从零开始重新连接，完全重建会话状态。在拥有负载均衡的云部署中，这种情况很少见。但在采用激进电源管理且连接不稳定的边缘设备上，这是协议假设与部署现实之间的根本不匹配。

Kierra 的建议是用 MQTT（一种专为高延迟、不可靠网络设计的轻量级消息协议）结合本地持久化层来替代 SSE。

在她描述的工厂车间场景中，缺陷检测模型需要标记一个疑似缺陷并记录下来发送到中央质量系统。就在那一刻，设备的 Wi-Fi 断开了 500 毫秒。在当前的 MCP+SSE 方案下，工具调用失败，会话状态丢失，缺陷未被记录。

使用存储转发机制时，MCP 客户端在接触网络之前，先将工具调用写入本地存储（一个 SQLite 发件箱）。调用现在变成持久化的：

• 能够承受应用崩溃、电池耗尽和进程终止。
• 当连接恢复时，MQTT 客户端将挂起的调用发布到代理（broker），代理再传递给 MCP 服务器。
• 如果结果到达时客户端仍离线，它会在重新连接的那一刻收到结果。

无需轮询、无需重新请求、无需重复工作。

与其配套的是会话连续性。如今，MCP 会话默认是无状态的，重连的客户端需要从头开始。Kierra 提出在 MCP 消息头中添加会话 ID 和序列号，这样当客户端使用已知会话 ID 重新连接时，服务器可以重放遗漏的通知。一个正在进行多轮分析的缺陷检测模型可以休眠，20 分钟后唤醒，然后无需重启即可继续其推理链。

其代价是架构复杂性的增加。当调用不能丢失、安全标记、审计事件、诊断日志等场景出现时，这笔代价是值得的。对于本地开发或可靠的云部署，SSE 仍然是正确的选择。

3. 语义工具压缩与基于内容寻址的上下文

第三个提案实际上将两个相关问题捆绑在一起。

第一个问题是工具模式的冗余性。当模型向 MCP 服务器请求工具列表时，它会收到服务器暴露的每个工具的完整 JSON 载荷：参数、类型、描述。对于一个在车间执行单一任务的小型语言模型而言，那 50 个工具中有 42 个是不相关的。返回它们会浪费上下文，并增加工具幻觉的概率，因为模型在比所需更大的选项空间中进行推理。

Kierra 的解决方案是允许客户端在请求工具时传递会话上下文。当前正在对汽车车身执行质量检查任务的模型只请求与缺陷检测相关的工具。服务器返回 8 个工具，而不是 50 个。攻击面随之缩小：未在模式中的工具无法被调用、无法产生幻觉，也无法通过恶意提示注入。

第二个问题是冗余的传感器轮询。一个监控冷却液温度、传送带速度和机器振动的系统会循环读取这些传感器，但这些值可能在几分钟甚至几小时内保持稳定。在当前的 MCP 中，每次资源请求都会返回完整的载荷，无论是否有变化。

Kierra 提出了基于内容寻址的上下文：在发送资源载荷之前，服务器先发送一个哈希值。客户端根据本地缓存检查该哈希值。如果匹配，则完全跳过下载。如果哈希值是新的，则请求完整载荷并缓存新的哈希值。对于一批每分钟数百次轮询数十个传感器的边缘设备来说，这能大幅减少网络和 CPU 负载——原理与 HTTP ETag 相同，但作为一等特性内置于 MCP 层中。

本地优先的资源发现

最后一段简短而尖锐地针对视频等高数据量来源的问题提出了解决方案。

Kierra 描述了她观看过一个用于视频智能分析的 MCP 服务器演示：视频流被发送到云端基础设施，经过索引，然后返回结果。这种架构在需要毫秒级决策的生产线上行不通——当视频离开厂区、结果返回时，缺陷产品早已越过了剔除点。

她的方案是一种使用专用 URI（mcp-local://）的本地优先资源发现机制，并严格区分 MCP 负责什么、不负责什么。MCP 服务器是分析和决策层，它并非数据传输层。

在实践中，视觉模型直接从摄像头接收原始视频帧，没有编码，没有封装。当检测到缺陷时，它会使用结构化发现（structured finding）调用 MCP 服务器。服务器从未见过原始帧。它看到的是结果，对其评估，并通过二进制 MCP 工具调用（binary MCP tool call）触发剔除臂。剔除臂启动。单元被转移。事件被记录。原始数据流与智能层从不共享同一路径。

为什么现在重要

Kierra 以一个清晰的前瞻视角结束了讨论：边缘计算不会等待共识。已有数十亿美元涌入边缘 AI 基础设施，她预计，无论核心规范是否跟上，二进制 MCP 分支都会在未来两到三年内诞生。

她的论点并非MCP需要被取代。二进制MCP（二进制模型上下文协议）是向后兼容的。缓存层是可选加入的。本地优先的资源发现采用URI方案。现有的云部署可以照常运行。但边缘部署需要这些优化，而MCP社区完全有能力构建这些优化，而不是坐视生态系统碎片化。

Kierra Dotson是Further公司的人工智能战略总监。Agentic AI Foundation是开放代理标准和开源基础设施的所在地。要了解更多关于MCP的信息，并与思考这些问题的工程师交流，请访问aaif.io，加入AAIF Discord的讨论，或参加即将举行的AAIF活动。