MCP 的采用速度远超预期。
开发者如今可以通过一个统一协议，将模型连接到代码库、数据库、浏览器、可观测性系统、内部 API 以及数十种其他工具。Claude Code、Cursor、Codex、VS Code 以及越来越多的客户端都已支持该协议。GitHub、Linear、Notion 等平台也提供了供应商托管端点。一级 SDK 的月下载量已逼近 5 亿次。
这是一个实实在在的成就。过去多年，每个 AI 应用都需要自建工具调用层。MCP 为整个生态提供了一个通用接口——一旦某个服务器实现对接，多个智能体无需编写定制胶水代码即可复用。这种基础设施的标准化，本身就值得投入。
然而，围绕 MCP 为编程智能体构建应用的过程中，另一个问题逐渐浮现：协议标准化的速度，远快于周边基础设施的成熟速度。将工具连接进来变得越来越简单，但要在真实用户、真实凭证、真实工作负载下稳定运行整套系统，仍然是另一回事。
协议解决了一个明确的问题：AI 模型如何通过通用接口与工具通信。但接下来面临的挑战完全不同：如何让数以千计的这类交互变得可靠、安全、高效、可观测，并且易于部署？
从 Demo 到生产的距离
理想路径看起来很简单：智能体与 MCP 客户端通信，客户端与 MCP 服务器通信，服务器调用工具，工具再与 API 或数据库交互。在 Demo 环境中，这通常已经足够。
但在生产环境中，局面完全不同。你面对的是多个智能体、多个用户、大量 MCP 服务器、需要严格保护的凭证、按人或按任务不同的权限控制、限速、故障重试、日志记录、不断变化的工具 schema、上下文限制，以及并非完全一致的环境配置。其 mental model 更接近于：智能体和客户端在认证层、路由/网关层、MCP 服务器集群层，以及实际后端系统层的前面。每一层都可能独立出现故障。
一个具体例子：读取文档的智能体失败一次，只是烦人；但创建云资源、写入数据库记录或打开 Pull Request 的智能体如果中途失败，问题性质就完全不同了。部分执行、状态不一致、需要幂等性或补偿机制，这些都变成了真实需求——协议本身不会凭空提供这些能力。
每个人都在重复造轮子
一个反复出现的模式是基础设施重复建设。开发者和团队不断地在各自代码库中构建认证、部署、连接管理、重试逻辑、日志、密钥处理、健康检查、访问控制、简单注册表、缓存和限速模块。这些组件在不同代码库中反复出现，因为协议只标准化了消息格式，却没有标准化围绕消息格式的运营关切。
这并非 MCP 独有的现象。此前的基础设施演进也遵循过类似的轨迹。物理服务器的痛苦达到临界点后，云抽象开始成熟；每个应用都重复造认证轮子时，身份平台开始成熟。MCP 可能正在进入这样一个阶段：管理大量各自独立配置和凭证的本地服务器，开始让人觉得像是旧时代的做法。最终的抽象层会出现在智能体运行时、云平台、网关还是其他位置，目前尚无定论——但重复建设的问题已经清晰可见。
本地 MCP 是正确的起点
通过 stdio 运行的本地服务器易于理解、贴近用户、天然连接本地文件和进程，是完美的实验起点。本地执行也天然规避了服务器一旦上网络就出现的诸多认证和多租户问题。
但团队级使用很快暴露了局限：每个人都被安装和配置所困扰，版本容易漂移，凭证分布在不同机器上，不同开发者的服务器会以不同方式出问题，新成员 onboarding 成为重复劳动，可观测性碎片化——因为每台机器都是一座孤岛。远程或托管服务器解决了部分问题，却又引入了新问题：跨客户端真正可用的认证、延迟、多租户、数据处理、可用性、权限，以及对供应商的依赖。两种模式没有自动的优劣之分，它们解决的是不同约束集。
2026 年 7 月的规范变更 对远程场景有所助益。移除协议级会话和 initialize 握手，意味着远程服务器可以更像普通 HTTP 服务那样横向扩展。这是实用的进展，但并没有消除对认证、授权和运营规范的需求。
工具太多反而有害
当一个 Agent 获得了 50 个、100 个甚至数百个工具时，问题就开始出现了——工具数量并非越多越好。选择准确率会下降，上下文中充斥着模型根本用不到的 schema，名称冲突和模糊描述会让问题进一步恶化。
核心矛盾在于：工具定义是否应该始终保留在活跃上下文中？ 还是应该支持动态检索？两种方式目前都有实践。
- 静态注册：工具数量少时简单直接
- 渐进式发现 / 语义搜索：对工具描述做向量检索，按需召回
- 网关路由：通过统一入口只暴露较小的工具子集
协议本身也在朝这个方向演进，提供了渐进式发现的指导规范。但仍有几个问题悬而未决：选择逻辑究竟该放在客户端、网关、服务器还是模型的工具调用训练层？最小权限原则在这里同样关键——一个能看到所有工具的 Agent，也更容易被诱导调用它本不该访问的工具。
安全：Agent 越自主，问题越严肃
MCP 安全与传统 API 安全有着本质区别。Agent 能读取不可信文本、将其解释为指令、调用工具并修改外部状态——这意味着攻击面涵盖了提示词注入、混乱代理问题、权限过度开放、恶意或被投毒的 Tool 描述、通过参数或返回值泄露密钥，以及服务器本身的供应链风险。
这并不意味着协议本身不安全，而是提醒我们：一旦自然语言能够驱动软件调用真实能力，信任边界和权限模型就成了核心问题。最小权限、破坏性操作的显式审批、将 Tool 返回结果视为不可信输入、覆盖从客户端到服务器再到后端全链路的身份认证——这些在传统 API 场景下要求没那么高的做法，现在都变得至关重要。
一项 2026 年对 7,973 个线上远程 MCP 服务器的测量研究 发现，40.55% 的服务器在未做认证的情况下暴露了工具。这是部署侧的问题，而非协议问题——但它恰恰是团队实际踩坑的地方。
可靠性：Agent 走上生产线之后
人类使用软件遇到错误会停下来，而自主 Agent 可能会继续执行。这就改变了重试策略、幂等性、超时行为、部分失败处理以及 Tool 返回值校验的要求。
可观测性的重要性也随之上升。一旦需要复盘 Agent 行为，可能要重建：模型相信了什么、看到了什么上下文、知道哪些工具、选择了哪个、生成了什么参数、工具返回了什么结果、以及 Agent 接下来做了什么。
标准化遥测已经开始出现。OpenTelemetry 的 GenAI 语义约定 包含了 MCP 相关 spans 和属性。SEP-414 则在 _meta 中为 W3C trace context 预留了空间，使追踪能够跨越 MCP 边界。官方 Python SDK 现已默认发送 OpenTelemetry spans。Agent 走出 demo 阶段后，这个方向的需求是显而易见的。
做 Hexum.dev 教会我的事
最初我以为主要问题是上下文效率——Hexum.dev 早期为编码 Agent 压缩代码库上下文的工作就反映了这一点。但当你优化完上下文，就会遇到工具选择问题；暴露了工具，就会遇到部署和配置问题；工具变成远程调用后，又会遇到认证和权限问题；再往后，随着 Agent 越来越自主，可靠性、安全和可观测性就排到了最前面。
核心感悟是：MCP 不只是一个协议问题，它正在成为一个基础设施类别。
现在的 Hexum.dev 是一个面向编码 Agent 的托管远程 MCP 端点。它的边界随着我们遇到的上下文处理、架构检查和 Agent 行为控制等相邻问题而扩展。Agent 仍然运行在开发者已经使用的编辑器里，Hexum.dev 只围绕特定工作流环节提供服务。这个产品并没有消除周围的那些问题——只是让它们变得更具体、更可触摸。
做 Hexum.dev 过程中有一条与协议完全无关的教训：做东西大部分时候就是在面对不确定性。事情会失败，方向会调整，你会在没人验证之前就在很多想法上花大量时间。 有愿意倾听、在需要时鼓励你、也会挑战你的朋友，比创始人通常承认的更重要。Yuchen 和 Pranav 就是这样的人——他们没有和我一起建 Hexum.dev，但听了无数次我的想法，让那些不确定的阶段变得更容易熬过去。
MCP 基础设施可能成为独立层级
一个可能未来的技术栈大致如下：最上层是模型和 Agent，下一层是 Agent 运行时和 MCP 客户端，再下面是处理路由、认证、权限、上下文管理、工具发现、缓存、可观测性、策略和可靠性的基础设施层，然后才是 MCP 服务器本身，最后是与这些服务器交互的数据库、API、代码和 SaaS 系统。
这是一个假设，不是定论。上述某些能力最终可能会落入模型提供商、Agent 运行时、云平台、网关或单个 MCP 服务器内部，边界并不固定。真正有意思的是：协议的 success 正在迫使这个问题被提出来。一旦工具互操作性被视作理所当然，剩下的工作就是让这种互操作性达到生产级别所需的一切。
协议只是开始
MCP 最大的成就也许是：开发者开始把工具互操作性当作理所当然的事。成功的标准最终都是这样的——把一个曾经困难的问题变得习以为常。 标准很少消除基础设施，只是把基础设施问题推到别的地方。HTTP 标准化了系统间的通信方式，但我们仍然围绕它构建了 CDN、负载均衡器、API 网关、可观测性平台、身份系统和云基础设施。MCP 可能也会走类似的路。协议给了 Agent 一个通用的工具语言，现在我们必须构建让这种语言在规模化下可靠运行所需的一切。
接口不再是最难的部分。周围那些系统才是。
评论