MCP 上云：Agent 工程从「装插件」走向「搭基建」的四道坎

MCP（Model Context Protocol）自 2024 年底由 Anthropic 提出，一直是跑在开发者本机上的工具调用协议——Agent 要用某个工具，就在自己机器上装一个对应的 MCP server，进程内通信，即插即用。7 月底 B 站一条标题为「MCP 协议核爆级更新，AI 代理终于上云了」的视频（发布于 7 月 29 日，播放 687、收藏 16、点赞 11）把一个变化推到台前：MCP 正在从本地走向云端托管。表面看只是工具连接换个部署位置，但对动手搭过 Agent 的人，这更像基础设施层面的换轨。

MCP 本地与云端架构对比

本地和云端的差别，不在"在哪跑"而在"谁来管"

本地 MCP 的运行模型很简单：一个开发者，一台机器，工具状态全在自己进程里。鉴权用不上——你的机器上跑的东西，默认就是你自己的。多租户也不存在——只有你一个人在用。延迟可以忽略——进程内调用，微秒级。

云端 MCP 把这个模型整个打破了。工具从"装在我机器上"变成"部署在云上、多个 Agent 共享调用"。一旦进入共享，立即要回答本地阶段从未出现的问题：谁有权限调这个工具？不同用户的调用上下文怎么隔离？网络往返带来的延迟怎么扛？每次调用要不要计费、怎么计？

这不是部署位置的变化，是责任边界的变化。本地阶段开发者对自己负责就够；上云之后，工具提供方要对所有调用方负责。

上云之后要面对的四道新题

把云上 MCP 想成一层共享基建，它至少要补上四块功课。

第一道是鉴权。本地不需要鉴权，因为调用方就是工具所有者。上云后每个请求都来自不同身份，工具方必须能验明调用者是谁、有没有权限调这个工具。Token 过期、权限粒度、调用方冒充，这些在本地不存在的麻烦会一起冒出来。多数团队第一版会用 API key 兜底，但 key 泄露后的撤销和轮换往往被忽略，等出事才补。

第二道是多租户隔离。不同团队、不同 Agent 共用同一套云上工具时，各自的上下文、缓存、会话状态不能串。这听起来像传统云服务的老问题，但 MCP 场景有个特殊点：工具的"状态"往往是模型对话上下文的一部分，隔离粒度比普通 SaaS 更细，隔离失败不只是数据泄露，还可能是上下文污染——A 的 Agent 拿到 B 对工具的指令残留。

第三道是延迟。本地 MCP 是进程内调用，延迟可以忽略不计。上云后每次工具调用变成一次网络往返，从微秒级跳到毫秒甚至百毫秒级。Agent 一个任务里可能连续调十几次工具，延迟会累计放大。把"调一次工具"的延迟预算重新规划、批量请求合并、高频工具考虑本地缓存结果，这些在本地阶段根本不用想。

第四道是计费。本地工具免费——你用自己的机器。云上工具要有人付服务器钱，调用就要计量。按次、按时长、按 token，每种模型对成本曲线影响不同。对工具提供方，计费模型直接影响工具被用多还是用少；对调用方，计费透明度决定了能不能预估一次任务花多少钱。

云上 MCP 要补的四道工程题

这波转向和更广的 Agent 工程趋势是同一条线

把 MCP 上云单独看会以为是协议自己的演进，放进同期热点里看，它其实是一个更大趋势在基础设施侧的信号。同一周 B 站出现了两条关于 Agent 方法论的视频：一条讲意图识别的主流方案和选型逻辑（7 月 29 日，弹幕 89 条，讨论度异常高），另一条讲多 Agent 和单 Agent 架构什么时候怎么选（7 月 29 日）。再往前几天，用 Subagents 在工具内组队和用独立编排平台统一管理多个 Agent 的两条路径也在被对比（收藏分别 110 和 46）。

意图识别、架构选型、编排治理，这三条是方法论侧在收紧；MCP 上云是基础设施侧在收紧。两条线同时动，说明社区正从"Agent 能做什么"转向"Agent 怎么做对、怎么长期稳定地做对"。能跑 demo 和能上生产之间的工程距离，开始被认真对待。

请求链路上多出来的几个检查点

从调用方角度看，云上 MCP 让一次工具调用从"直接执行"变成"先过几道门"。请求要先验明身份，进入多租户路由，经过网络传输，到工具侧执行，执行结果再按调用方计量——每一道门都是本地阶段不存在的开销。

云上 MCP 请求链路中的检查点

理解这条链路的价值在于：延迟和成本不是均匀分布的。鉴权和路由通常是轻量操作，但网络传输是延迟大头，计费记录是异步开销。优化时抓住网络这一段收益通常最大——这也是为什么部分团队会选混合方案：高频且对延迟敏感的工具留在本地，低频或需要共享的工具才上云。

先想清楚再搬，别一窝蜂上云

对正在搭 Agent 的实践者，面对 MCP 上云这波变化，几条建议供参考。

别急着把所有 MCP server 都搬上云。先做分类：高频调用的通用工具（比如搜索、文件读写）适合共享，上云后多 Agent 复用价值高；含敏感数据的工具、低频的专有工具，留在本地往往更省心。一锅端上云只会让鉴权和隔离复杂度无谓放大。

鉴权先用最小可用方案。第一版用 API key 兜底可以，但把 key 轮换和撤销流程一起设计进去，别等泄露了才补。多租户隔离如果团队规模还小，可以先按租户 ID 做粗粒度隔离，等调用方多了再细化。

延迟先量再优化。上云初期先用日志把每次调用的端到端延迟记下来，看清分布再决定要不要做批量合并或本地缓存。凭感觉优化容易猜错瓶颈在哪。

计费模型提前和工具提供方对齐。按次还是按时长，有没有免费额度，超额怎么处理——这些直接影响你对一次任务成本的预估能力。

本地与云端 MCP 的选型决策

MCP 上云不会一夜完成，方向却已经清楚。工具层从"各自安装"走向"共享基建"，工程复杂度也会随之抬升。对实践者，提前理解鉴权、多租户、延迟、计费这四道题，比追每一个新功能更值得花时间。这周的热点信号，与其说是某个协议的更新，不如说是 Agent 工程正在补上它走向生产前必须补的那几块基础设施。