MCP 已经统一了工具标准。现在，我们需要它们周边的基础设施。
MCP 的普及速度极快。
如今，开发者可以通过一套通用协议，把模型接入代码仓库、数据库、浏览器、可观测性系统、内部 API，以及几十种其他工具。Claude Code、Cursor、Codex、VS Code，还有越来越多的客户端都支持它。GitHub、Linear、Notion 等厂商也提供了托管端点。一线 SDK 的月下载量正逼近五亿次。
这是一项实打实的成就。多年来，每个 AI 应用都得自己搭建工具调用层。MCP 给整个生态带来了统一接口。只要有一个服务器（server），多个智能体（agent）就能直接使用，不用再写定制粘合代码。光凭这一点，就值得投入。
但在围绕 MCP 为编码智能体搭建系统的过程中，我注意到了另一件事：协议的标准化速度，超过了它周边基础设施的速度。接一个工具越来越简单。可要让这套系统在真实用户、真实凭证、真实工作中稳定运行，就没那么容易了。
协议解决的是一个具体问题：AI 模型如何通过统一接口跟工具对话？接下来的问题不一样了：如何让成千上万次这样的交互变得可靠、安全、高效、可观测，并且容易部署？
从演示到生产的鸿沟
理想路径看起来很简单：智能体跟 MCP 客户端对话，客户端跟 MCP 服务器对话，服务器调用工具，工具再访问 API 或数据库。做演示时，往往这就够了。
到了生产环境，情况就变了。你要面对多个智能体、多个用户、众多 MCP 服务器、绝不能泄露的凭证、速率限制、因人而异的权限和任务级权限、各种失败、重试、日志、不断变化的工具 schema、上下文限制，还有配置各不相同的机器。这时的心智模型更接近这样：智能体和客户端位于最前面，接着是认证、路由或网关，再往后是一批 MCP 服务器，最后是服务器真正接触的系统。这些层中的每一层都可能单独出问题。
举个具体的例子：一个只读文档的 agent，失败一次顶多让人心烦。但如果 agent 要创建云资源、写入数据库记录、提交 pull request，中途失败了，那就是另一回事了。部分完成的工作、不一致的状态、幂等或补偿机制的需求，都会变成实实在在的要求。协议本身并不会凭空提供这些。
大家都在重造同一套管道
我反复看到的一个现象是基础设施的重复建设。开发者和团队一次又一次地搭建认证、部署、连接管理、重试、日志、密钥处理、健康检查、访问控制、简易注册中心、缓存和限流。同一套东西在不同代码库里反复出现，原因就在于协议只标准化了消息格式，并没有管它周边的运维问题。
这不是 MCP 独有的情况。早先的基础设施演进也走过类似的路。物理服务器维护起来足够痛苦了，云抽象就成熟起来了；每个应用都在重复造认证，身份平台就成熟起来了。MCP 可能正在进入这样一个阶段：管理几十个独立的本地服务器，每个都有自己的配置和凭据——这种做法开始显得老旧。最终的抽象层会落在 agent 运行时、云平台、网关还是别的地方，目前还没有定论。但重复建设的问题已经摆在眼前。
本地 MCP 是合适的起点
基于 stdio 的本地服务器易于理解，离用户近，天然能连本地文件和进程。用它们做实验再合适不过。本地执行还避开了许多认证和多租户问题——这些问题一旦服务器上了网络就会冒出来。
团队规模的使用会暴露这些限制。每个人都需要安装和配置。版本会漂移。凭证散落在不同机器上。一位开发者的服务器出故障的方式，可能和另一位完全不同。新人上手变成重复劳动。可观测性支离破碎，因为每台机器都是一座孤岛。远程或托管服务器能解决其中一些问题，但会引入别的问题：真正跨客户端可用的认证、延迟、多租户、数据处理、正常运行时间、权限，以及供应商依赖问题。两种模式没有谁天生更优，它们解决的是不同的约束组合。
2026 年 7 月的规范变更对远程场景有利。移除协议级会话和初始化握手，意味着远程服务器可以更像普通 HTTP 服务那样扩展。这是有用的进展，但并没有消除对认证、授权和运维纪律的需求。
上下文正在成为基础设施问题
编程智能体需要代码仓库的上下文。如果直接把整棵目录树丢给智能体，会带来 token 开销、无关信息、干扰、更高延迟，有时还会让推理变差。更大的上下文窗口并不能解决这个问题。问题从“模型能装下多少”变成了“哪些上下文值得放进去”。
我早期很多工作就集中在这里。Hexum.dev 的部分起点就是让代码仓库上下文更高效，让智能体看到相关结构，而不是原始文件堆。在一个已公开的、使用 MBPP 和 HumanEval 的 24 项任务基准测试中，发送给模型的上下文从 220,393 个 token 降到 27,352 个（减少 87.6%），同时仍然通过所有官方测试。方法公开。数字本身没那么重要，重要的是这个观察：一旦你把上下文选择当成一个刻意步骤，而不是直接倾倒，其他约束就会出现。
开发者现在经常讨论这个话题，他们把它叫做上下文工程（context engineering）。渐进式或动态的工具发现，正是针对一个相关问题给出的对策：如果每一轮对话都把每个服务器上的每个工具定义都塞进上下文，负担会很重。客户端的最佳实践现在建议延迟加载完整定义，改用一个搜索式的元工具。同样的指南也解释了原因：渐进式发现能大幅减少工具定义占用的 token，同时让模型只关注少量相关工具，从而提高选择准确率。这个模式还没普及，但趋势已经很明显。
工具爆炸与工具选择
当给一个智能体配上 50 个、100 个甚至几百个工具时，事情会从帮忙变成添乱。选择准确率可能下降，上下文被模型可能永远用不到的 schema 填满，命名冲突和含糊的描述会让问题更糟。
每个工具定义都应该一直待在活跃上下文里吗？还是应该按需动态检索工具？这两种做法目前都有人用。工具数量少时，静态注册很简单。渐进式发现、对工具描述做语义搜索、以及用网关做路由只暴露一小部分工具——这些方案都有人在尝试。协议本身也在通过渐进式发现的指南和相关工作朝这个方向走。还没有定论的是：选择逻辑应该放在客户端、网关、服务器，还是模型自身的工具调用训练里。最小权限原则在这里也很重要：一个能看到所有工具的智能体，就是一个可能被诱导去调用它本不该访问的工具的智能体。
智能体越自主，安全问题越严重
MCP 的安全问题和普通 API 安全不是一回事。智能体可以读取不可信文本，把它当成指令来执行，调用工具，并改变外部状态。这就带来了新的攻击面：提示注入、混淆代理问题、权限过宽、恶意或被投毒的工具描述、通过参数或返回值泄露机密，以及服务器自身带来的供应链风险。
这并不意味着协议本身不安全。它说明的是：一旦自然语言能让软件去调用真实能力，信任边界和权限模型就成了关键。最小权限原则、对破坏性操作要求显式批准、把工具返回结果当作不可信输入来谨慎处理、以及让身份认证贯穿从客户端到服务器再到后端系统的整条链路——这些都比传统 API 场景更重要。一项针对 7,973 个在线远程 MCP 服务器的 2026 年测量研究发现，40.55% 的服务器在没有认证的情况下就暴露了工具。这是部署问题，不是协议问题，但恰恰是团队真正会踩到的坑。
智能体开始干真活之后，可靠性怎么办
人用软件，出了问题会停下来。自主智能体不会，它会接着往下跑。这就改变了重试、幂等性、超时行为、部分失败，以及工具返回结果校验等方面的要求。可观测性也变得更关键，因为你可能需要还原：模型当时以为发生了什么、它看到了哪些上下文、它知道哪些工具、它选了哪一个、生成了什么参数、工具返回了什么、然后它又做了什么。
标准化的遥测方案已经开始出现。OpenTelemetry 的 GenAI 语义约定里包含了与 MCP 相关的 span 和属性；SEP-414 这类工作则在 _meta 中预留了 W3C trace context 的位置，让链路追踪能跨越 MCP 边界。官方 Python SDK 现在默认就会发出 OpenTelemetry span。这套做法会不会成为团队调试智能体—工具系统的默认方式，现在还言之过早，但需求已经很明显了——只要智能体走出 demo 阶段就能感受到。
搭建 Hexum.dev 让我学到了什么
一开始我以为主要问题之一是上下文效率。Hexum.dev 早期为编码智能体压缩代码仓库上下文的工作，正是基于这个判断。可是把上下文优化好之后，就会撞上工具选择的问题；把工具暴露出来之后，又会撞上部署和配置的问题；工具变成远程之后，认证和权限的问题就来了；等智能体变得更自主，可靠性、安全和可观测性就全被推到最前面。我由此意识到，MCP 不只是一个协议问题，它正在变成一个基础设施品类。
Hexum.dev 目前是一个面向编程智能体的托管远程 MCP 端点。随着我们在上下文处理、架构检查和智能体行为控制等方面遇到相关问题，它的范围也不断扩大。智能体仍然运行在开发者已经使用的编辑器里，Hexum.dev 则围绕这一工作流的特定环节提供支持。开发它并没有消除周边的问题，反而让这些问题变得更加具体。
从开发 Hexum.dev 的经历中，我学到了一点，和协议本身无关。
开发过程中大部分时间都在面对不确定性。东西会出故障，方向会改变，你会在想法上投入大量时间，却不知道有没有人认可。有几个愿意倾听、鼓励你、在必要时挑战你的朋友，比创始人通常愿意承认的还要重要。Yuchen 和 Pranav 对我来说就是这样的人。他们没有和我一起做 Hexum，但他们听了无数个想法，让那些充满不确定性的阶段更容易坚持下去。
MCP 基础设施可能会成为独立的一层
一种可能的未来技术栈大致是这样的：最上面是模型和智能体，下面是智能体运行时和 MCP 客户端，再往下是一层基础设施，负责路由、认证、权限、上下文管理、工具发现、缓存、可观测性、策略和可靠性，然后是 MCP 服务器本身，最底层是这些服务器所访问的数据库、API、代码和 SaaS 系统。
这是一个假设，不是确定的事实。其中一些能力最终可能落在模型提供商内部、智能体运行时内部、云平台内部、网关内部，或者各个 MCP 服务器内部。边界并不固定。有意思的地方在于，协议的成功正在迫使我们面对这个问题。一旦工具互操作性被视为理所当然，剩下的工作就是让这种互操作性达到生产级所需的一切。
协议只是起点
MCP 最大的成就，或许是开发者开始把工具互操作性视为理所当然。成功的标准最终都会做到这一点——让曾经困难的问题变得稀松平常。
标准很少能消灭基础设施，它只是把基础设施的问题挪到了别处。HTTP 统一了系统之间的通信方式，但我们还是围绕它建起了 CDN、负载均衡、API 网关、可观测性平台、身份系统和云基础设施。MCP 可能也会走同样的路。这个协议为智能体（agent）提供了一套调用工具的共同语言。接下来，我们得把让这套语言在大规模场景下稳定运行所需的一切都建起来。
接口不再是难点，围绕接口的系统才是。
本文采用知识共享署名-相同方式共享 4.0 国际许可协议授权。