曾在国内率先予以过MCP管理的支持, 且始终都在留意MCP的发展情况。就像MCP于2024年11月开源之后, 我们便预感到这是较其他而言更易于被广泛运用的Agent接入外部系统的协议, 其能够加速模型的货币化进程。在 MCP 爆火之后, 它遭遇了一系列的挑战, 特别是当主流 Agent 客户端把 CLI 当作连接外部系统的技术方案之际, 关于 MCP 被沦为弃子的这种说法到处都是。社区针对 MCP 的吐槽主要集中在上下文拥挤以及费钱这两方面。身处AI时代, 制作软件相对简单, 然而, 一旦面临规模化进行落地情况时, 架构的设计以及工程的质量便成为了稀缺的资源, 而这恰恰是AI很难直接予以替代的。这次升级解决了什么问题最新版的核心之处有改动, 此改动是将 MCP 进行改变, MCP 原本是一种有状态且依赖长连接的协议, 现在被改回了无状态的请求/响应模型。这还是文章标题里所讲的“重回 HTTP 范式”的缘由所在, HTTP 协议具备无状态的特性, 而这种无状态在 Web 架构当中属于最基础同时也是最成熟的做法。先来看, 过去呢有个情况是, MCP 依赖着什么, 依赖握手以及 Mcp--Id 会话标识去维持上下文, 这是一种情况。还有就是, 这意味着什么, 意味着同一会话的多次请求, 必须得落到同一个服务端实例上才行, 不然的话, 上下文就要丢失了就是这样。拿高德地图的MCP来说, 用户询问“从公司到最近的充电桩该如何走”, 这时Agent在一次会话当中常常需要接连调用所暴露的多个tool。首先运用地理编码工具将地址转变为坐标, 接着使用POI搜索工具去找附近的充电桩, 最后凭借路径规划工具计算出路线。地理编码、POI搜索、路径规划这三个tool共享同一个会话上下文, 在有状态模式下就必定需要由同一个实例来承担。可当出现调用量上涨的情况, 并且后端部署了多个实例之时, 负载均衡就不能够简单地去将请求进行打散, 而是要维持同一会话始终回到最初始的那个实例, 这也就是所谓的会话亲和性。要去维持这种亲和性, 要么是让负载均衡记住会话与实例之间的绑定关系, 要么是在实例之间实现会话状态的共享, 而这些均属于横向扩容时额外产生的架构成本。新版本将先前的那套握手以及会话标识予以退役处理了具体指的是SEP - 2575、SEP - 2567, 转而变更为每个请求都进行自我描述, 协议版本、客户端身份还有能力都随着请求一同携带, 也就是说任何一个请求都能够落到普通轮询负载均衡后面的随便哪一个实例上, 不再需要共享存储了。原先存在的, 那些需要服务端主动去发起的, 并且依赖长连接的交互, 被替换成了多轮请求MRTR, 其中服务端返回, 客户端带上答案重试。HTTP请求也开始强制携带Mcp-和Mcp-Name两个, 网关、限流器可以直接按路由和计量, 无需解析请求体。社区并非一面倒的支持新版本是否解决了最痛的槽点需解决部署及扩展问题的是无状态化, 能降低运维复杂度的也是无状态化, 然而社区针对MCP最为集中的抱怨, 是上下文存在拥挤状况、花费钱财, 此乃开发者体验方面的问题, 并且新版本几乎未曾对这些问题给予正面回应。上下文拥挤的源头, 是工具定义为前置加载, Agent 在开展工作以前, 得先将所有可用工具的阐释读入上下文, 工具数量一旦增多, 仅这些定义便会占据相当一部分窗口, 真正留给任务自身的空间遭压缩。新版本当中, 与这个问题最为相近的改动在于tools/list、/list、/list的返回情况开始带有ttlMs以及SE-2549, 客户端能够实现对于工具目录的缓存, 在重新连接之后维持上游缓存的稳定状态。除此之外, 还额外增添了一个可供选择的/, 从而使得能力发现能够更加靠前。但此时需要明确区分的是, 缓存所优化的是避免反复重新拉取工具清单, 它并未使得单轮对话里工具定义所占用的token有所降低。该占用的上下文依旧会占用, 只是重复获取的次数变少了。所以, 就上下文拥挤这个关键槽点而言, 缓存乃是与之相关的外围进一步提升措施, 并非从根本上解决问题的办法。带来上下文拥挤这一状况的直接后果是什么, 是费钱。token占用的情况并未出现下降, 如此一来调用成本自然而然也就没办法降得下来。新版本里面没有任何一条改动是朝着优化压缩工具这个方向去的。开发者们内心真正所期望的究竟是什么, 那便是: 工具能够依据需求来进行加载, 只有在需要的时候才把相关工具的定义输送到上下文当中。新版本自身带来了一笔新成本, 此成本即为迁移, 无状态化属于一次破坏性变更, 对于那些依赖会话标识的实现而言, 需对代码加以改造, 配套的弃用清单同样不短: 某些被正式弃用, 转而投向 CIMDRoots 以及一些相关的被弃用HTTP SSE 传输步入退场倒计时。扎实的架构设计和丰富的工程实践才是稀缺资源望向后方, 此次升级未曾去引入什么具备新颖特质的机制, 无状态, 请求自身具备描述性按照路由, 皆是在Web架构当中被运用了许多年的陈旧办法。MCP之所以要经历一番环绕之后再回归至这些做法之上, 是由于在爆火以后真正的考验并非是“是否定义了Agent连接外部系统的全新标准”倒是“能不能在规模化的流量情形之下保障调用方以及维护方的体验”。能靠一个主意解决的是前者, 需对可扩展性、部署形态以及治理成本进行全盘考虑的是后者。对此, 扎实的架构设计以及丰富的工程实践是必要的。这正好是 AI 时代最容易被低估且最属稀罕之物的对象正在开发对 MCP 最新版的支持将于本周发布 MCP 重回 HTTP 范式，再次证明架构设计和工程实践才是稀缺资源
曾在国内率先予以过MCP管理的支持, 且始终都在留意MCP的发展情况。就像MCP于2024年11月开源之后, 我们便预感到这是较其他而言更易于被广泛运用的Agent接入外部系统的协议, 其能够加速模型的货币化进程。在 MCP 爆火之后, 它遭遇了一系列的挑战, 特别是当主流 Agent 客户端把 CLI 当作连接外部系统的技术方案之际, 关于 MCP 被沦为弃子的这种说法到处都是。社区针对 MCP 的吐槽主要集中在上下文拥挤以及费钱这两方面。身处AI时代, 制作软件相对简单, 然而, 一旦面临规模化进行落地情况时, 架构的设计以及工程的质量便成为了稀缺的资源, 而这恰恰是AI很难直接予以替代的。这次升级解决了什么问题最新版的核心之处有改动, 此改动是将 MCP 进行改变, MCP 原本是一种有状态且依赖长连接的协议, 现在被改回了无状态的请求/响应模型。这还是文章标题里所讲的“重回 HTTP 范式”的缘由所在, HTTP 协议具备无状态的特性, 而这种无状态在 Web 架构当中属于最基础同时也是最成熟的做法。先来看, 过去呢有个情况是, MCP 依赖着什么, 依赖握手以及 Mcp--Id 会话标识去维持上下文, 这是一种情况。还有就是, 这意味着什么, 意味着同一会话的多次请求, 必须得落到同一个服务端实例上才行, 不然的话, 上下文就要丢失了就是这样。拿高德地图的MCP来说, 用户询问“从公司到最近的充电桩该如何走”, 这时Agent在一次会话当中常常需要接连调用所暴露的多个tool。首先运用地理编码工具将地址转变为坐标, 接着使用POI搜索工具去找附近的充电桩, 最后凭借路径规划工具计算出路线。地理编码、POI搜索、路径规划这三个tool共享同一个会话上下文, 在有状态模式下就必定需要由同一个实例来承担。可当出现调用量上涨的情况, 并且后端部署了多个实例之时, 负载均衡就不能够简单地去将请求进行打散, 而是要维持同一会话始终回到最初始的那个实例, 这也就是所谓的会话亲和性。要去维持这种亲和性, 要么是让负载均衡记住会话与实例之间的绑定关系, 要么是在实例之间实现会话状态的共享, 而这些均属于横向扩容时额外产生的架构成本。新版本将先前的那套握手以及会话标识予以退役处理了具体指的是SEP - 2575、SEP - 2567, 转而变更为每个请求都进行自我描述, 协议版本、客户端身份还有能力都随着请求一同携带, 也就是说任何一个请求都能够落到普通轮询负载均衡后面的随便哪一个实例上, 不再需要共享存储了。原先存在的, 那些需要服务端主动去发起的, 并且依赖长连接的交互, 被替换成了多轮请求MRTR, 其中服务端返回, 客户端带上答案重试。HTTP请求也开始强制携带Mcp-和Mcp-Name两个, 网关、限流器可以直接按路由和计量, 无需解析请求体。社区并非一面倒的支持新版本是否解决了最痛的槽点需解决部署及扩展问题的是无状态化, 能降低运维复杂度的也是无状态化, 然而社区针对MCP最为集中的抱怨, 是上下文存在拥挤状况、花费钱财, 此乃开发者体验方面的问题, 并且新版本几乎未曾对这些问题给予正面回应。上下文拥挤的源头, 是工具定义为前置加载, Agent 在开展工作以前, 得先将所有可用工具的阐释读入上下文, 工具数量一旦增多, 仅这些定义便会占据相当一部分窗口, 真正留给任务自身的空间遭压缩。新版本当中, 与这个问题最为相近的改动在于tools/list、/list、/list的返回情况开始带有ttlMs以及SE-2549, 客户端能够实现对于工具目录的缓存, 在重新连接之后维持上游缓存的稳定状态。除此之外, 还额外增添了一个可供选择的/, 从而使得能力发现能够更加靠前。但此时需要明确区分的是, 缓存所优化的是避免反复重新拉取工具清单, 它并未使得单轮对话里工具定义所占用的token有所降低。该占用的上下文依旧会占用, 只是重复获取的次数变少了。所以, 就上下文拥挤这个关键槽点而言, 缓存乃是与之相关的外围进一步提升措施, 并非从根本上解决问题的办法。带来上下文拥挤这一状况的直接后果是什么, 是费钱。token占用的情况并未出现下降, 如此一来调用成本自然而然也就没办法降得下来。新版本里面没有任何一条改动是朝着优化压缩工具这个方向去的。开发者们内心真正所期望的究竟是什么, 那便是: 工具能够依据需求来进行加载, 只有在需要的时候才把相关工具的定义输送到上下文当中。新版本自身带来了一笔新成本, 此成本即为迁移, 无状态化属于一次破坏性变更, 对于那些依赖会话标识的实现而言, 需对代码加以改造, 配套的弃用清单同样不短: 某些被正式弃用, 转而投向 CIMDRoots 以及一些相关的被弃用HTTP SSE 传输步入退场倒计时。扎实的架构设计和丰富的工程实践才是稀缺资源望向后方, 此次升级未曾去引入什么具备新颖特质的机制, 无状态, 请求自身具备描述性按照路由, 皆是在Web架构当中被运用了许多年的陈旧办法。MCP之所以要经历一番环绕之后再回归至这些做法之上, 是由于在爆火以后真正的考验并非是“是否定义了Agent连接外部系统的全新标准”倒是“能不能在规模化的流量情形之下保障调用方以及维护方的体验”。能靠一个主意解决的是前者, 需对可扩展性、部署形态以及治理成本进行全盘考虑的是后者。对此, 扎实的架构设计以及丰富的工程实践是必要的。这正好是 AI 时代最容易被低估且最属稀罕之物的对象正在开发对 MCP 最新版的支持将于本周发布