MCP 的采用速度极快。
开发者现在可以通过共享协议将模型连接到代码仓库、数据库、浏览器、可观测性系统、内部 API（应用程序编程接口） 以及数十种其他工具。Claude Code、Cursor、Codex、VS Code 以及越来越多的其他客户端都支持它。GitHub、Linear、Notion 等许多服务已有厂商托管的端点。Tier 1 SDK（软件开发工具包） 的月下载量正逼近五亿次。
这是一项真正的成就。多年来，每个 AI 应用都自行构建工具调用层。MCP 为生态系统提供了通用接口。一旦服务器存在，多个智能体无需定制胶水代码即可使用它。仅此一点就值得付出努力。
但在围绕 MCP 为编码智能体构建系统之后，我开始注意到另一件事。协议的标准化速度超过了其周边基础设施的发展速度。连接工具正变得容易。但要让该系统在真实用户、真实凭据和真实工作负载下可靠运行，却并非如此。
该协议解决了一个具体问题：AI 模型如何通过通用接口与工具通信？接下来的问题则不同。我们如何让成千上万次此类交互变得可靠、安全、高效、可观测且易于部署？
从演示到生产的鸿沟
理想路径看起来很简单。智能体与 MCP 客户端通信，MCP 客户端与 MCP 服务器通信，MCP 服务器调用工具，工具再与 API 或数据库通信。在演示中，这通常就是你需要的全部。
在生产环境中，情况则不同。你会有多个智能体、多个用户、多个 MCP 服务器、不能泄露的凭据、速率限制、因人或因任务而异的权限、故障、重试、日志、不断变化的工具 schema、上下文约束，以及并非完全相同的机器。心智模型变得更接近于：智能体和客户端位于身份验证、路由或网关之前，然后是若干 MCP 服务器，再然后是这些服务器所触及的实际系统。上述每一层都可能独立发生故障。
一个具体例子：一个读取文档的智能体失败一次尚可忍受。一个创建云资源、写入数据库记录或发起拉取请求的智能体中途失败，则是另一回事。部分完成的工作、不一致的状态，以及对幂等性或补偿的需求，都会成为真实要求。协议并不会凭空提供这些。
所有人都在重建同样的管道
我不断看到的一种模式是基础设施重复建设。开发者和团队反复构建身份验证、部署、连接管理、重试、日志、密钥处理、健康检查、访问控制、简单注册表、缓存和速率限制。相同的组件出现在不同的代码库中，因为协议标准化的是消息格式，而非其周边的运维关注点。
这并非 MCP 独有。早先的基础设施转型也呈现出类似形态。当物理服务器变得足够痛苦时，云抽象逐渐成熟。当每个应用都重新发明身份验证时，身份平台逐渐成熟。MCP 可能正进入一个阶段：管理数十个独立的本地服务器（每个都有自己的配置和凭据）开始让人感觉像是旧的做法。最终的抽象是存在于智能体运行时、云平台、网关还是其他地方，仍未确定。但重复建设已经显而易见。
本地 MCP 是正确的起点
基于 stdio 的本地服务器易于理解、贴近用户，并且天然与本地文件和进程相连。它们是进行实验的完美方式。本地执行还避免了许多一旦服务器迁移到网络上就会出现的问题，例如身份验证和多租户问题。
团队规模的使用暴露了局限性。每个人都需要安装和配置。版本会漂移。凭据存在于不同的机器上。一个开发者的服务器可能以与另一个开发者不同的方式出现故障。入门变得重复。可观测性变得碎片化，因为每台机器都是自己的孤岛。远程或托管服务器解决了其中一些问题，但引入了其他问题：真正跨客户端可用的身份验证、延迟、多租户、数据处理、正常运行时间、权限以及供应商依赖问题。两种模型都没有自动的优越性。它们解决不同的约束集。
2026 年 7 月的规范变更对远程场景有所帮助。移除协议级会话和初始化握手意味着远程服务器可以更像普通 HTTP 服务一样扩展。这是有用的进步。它并没有消除对身份验证、授权或运维纪律的需求。
上下文正在成为一个基础设施问题
编码智能体需要仓库上下文。天真地将整个树交给智能体会产生令牌成本、无关信息、分心、更高的延迟，有时还会导致更差的推理。更大的上下文窗口并不能消除这个问题。问题从“模型能容纳多少？”转变为“哪些上下文值得存在？”
这是我早期工作的大部分所在。Hexum.dev 的部分起点就是让仓库上下文更高效，使智能体看到相关结构而不是原始的文件转储。在使用 MBPP 和 HumanEval 的已发布 24 任务基准测试中，发送到模型的测量上下文从 220,393 个令牌降至 27,352 个（减少 87.6%），同时仍然通过所有官方测试。方法论是公开的。数字不如观察重要：一旦你开始将上下文选择视为一个深思熟虑的步骤而不是转储，其他约束就会出现。
开发者现在经常在上下文工程的旗帜下讨论这个问题。渐进式或动态工具发现是对一个相关问题的回应：在每一轮中将每个服务器的每个工具模式加载到上下文中。客户端最佳实践现在建议推迟完整定义并提供搜索式元工具。同样的指导解释了原因：渐进式发现可以大幅减少工具定义令牌，并可以通过让模型专注于更小的相关工具集来提高选择准确性。这种模式尚未普及，但压力是明显的。
工具爆炸与选择
有一个临界点，给智能体 50、100 或数百个工具会变得有害而非有益。选择准确性可能下降。上下文充满了模型可能永远不需要的模式。名称冲突和模糊描述使问题更糟。
每个工具定义是否应该始终位于活动上下文中？还是工具本身应该被动态检索？这两种方法目前都存在于实际应用中。当表面较小时，静态注册很简单。渐进式发现、对工具描述的语义搜索以及暴露更小集合的网关式路由都在被尝试。协议本身正通过渐进式发现指导和相关工作朝这个方向发展。仍然开放的问题是选择逻辑有多少存在于客户端、网关、服务器或模型自身的工具使用训练中。最小权限在这里也很重要：一个能看到所有工具的智能体是一个可以被诱骗调用它不应访问的工具的智能体。
随着智能体变得更加自主，安全性变得更加严峻
MCP 安全与普通 API 安全并不相同。智能体可以读取不可信文本，将其解释为指令，调用工具，并改变外部状态。这会产生诸如提示注入、混淆代理问题、权限过宽、恶意或被投毒的工具描述、通过参数或结果泄露机密，以及来自服务器本身的供应链风险等攻击面。
这并不意味着该协议本身不安全。它意味着，一旦自然语言可以导致软件调用真实能力，信任边界和权限模型就变得至关重要。最小权限、对破坏性操作进行显式批准、将工具结果作为不可信输入谨慎处理，以及能够贯穿从客户端到服务器再到后端系统全路径的身份验证，都比传统 API 中更为重要。一项 2026 年对 7,973 个在线远程 MCP 服务器的测量研究发现，40.55% 的工具在未认证的情况下暴露。这是部署问题，不是协议问题，但却是团队实际会遇到的问题。
当智能体开始执行真实工作时的可靠性
使用软件的人类会注意到错误并停下来。自主智能体则可能继续运行。这改变了围绕重试、幂等性、超时行为、部分失败以及工具结果验证的要求。可观测性变得更加重要，因为你可能需要重建模型当时相信了什么、它看到了哪些上下文、它知道哪些工具、它选择了哪一个、它生成了什么参数、工具返回了什么，以及它接下来做了什么。
标准化遥测正在开始出现。OpenTelemetry 的 GenAI 语义约定包括与 MCP 相关的 span 和属性。SEP-414 等工作在 _meta 中预留了空间用于 W3C 跟踪上下文，以便跟踪可以跨越 MCP 边界。官方 Python SDK 现在默认发出 OpenTelemetry span。这是否会成为团队调试智能体-工具系统的默认方式仍为时尚早，但一旦智能体走出演示阶段，需求就显而易见。
构建 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 可能也会走上类似的道路。该协议为智能体提供了一种与工具沟通的通用语言。现在我们必须构建一切必要的东西，让这种语言在大规模场景下可靠运行。
接口不再是最难的部分，围绕它的系统才是。
这些文章依据 Creative Commons Attribution-ShareAlike 4.0 International 许可证授权。
creativecommons.org/licenses/by-sa/4.0/deed.en
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文来源：Stack Overflow Blog
原文作者：Vijay Harre；如有侵权，请联系管理员删除。
