MCP standardized tools. Now we need the infrastructure around them.

MCP 标准化工具。现在我们需要围绕它们的基础设施。 - Stack Overflow

2026年10月15日

MCP 标准化工具。现在我们需要围绕它们的基础设施。

[

MCP 的采用速度非常快。

现在，开发者可以通过共享协议将模型连接到仓库、数据库、浏览器、可观测性系统、内部 API 以及数十种其他工具。Claude Code、Cursor、Codex、VS Code 以及越来越多的其他客户端都支持该协议。GitHub、Linear、Notion 等平台已存在由供应商托管的端点。Tier 1 SDK 的月下载量已接近 5 亿次。

这是一项真正的成就。多年来，每个 AI 应用都必须自行构建工具调用层。MCP 为生态系统提供了通用接口。一旦存在服务器，多个代理无需定制适配器即可使用它。仅凭这一点就值得付出努力。

但在围绕 MCP 构建代码代理的过程中，我开始注意到另一个问题。协议的标准化速度超过了基础设施的建设速度。连接工具变得容易了，但要在真实用户、真实凭证和真实工作负载下可靠地运行整个系统却变得困难。

该协议解决了一个具体问题：如何通过通用接口让 AI 模型与工具通信？下一组问题则截然不同。我们如何让成千上万次交互变得可靠、安全、高效、可观测，并且易于部署？

从演示到生产环境的鸿沟

理想路径看似简单。代理与 MCP 客户端通信，客户端与 MCP 服务器通信，服务器调用工具并与 API 或数据库交互。在演示中，这通常就足够了。

但在生产环境中，情况发生了变化。你将面对多个代理、多个用户、多个 MCP 服务器、必须防止泄露的凭证、速率限制、因人而异或因任务而异的权限、失败、重试、日志、不断变化的工具模式、上下文约束以及非同构的机器。此时的思维模型更接近于：代理和客户端首先经过认证、路由或网关，然后是一组 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年对7973个实时远程MCP服务器的测量研究表明，40.55%的服务器在没有认证的情况下暴露了工具。这是部署问题而非协议问题，但正是团队实际遇到的问题。

当代理开始执行实际工作时的可靠性

人类使用软件时遇到错误会停止。自主代理可能继续执行。这改变了重试、幂等性、超时行为、部分失败和工具结果验证的要求。可观测性变得更加重要，因为可能需要重建模型的信念、看到的上下文、知道的工具、选择的工具、生成的参数、工具返回的内容以及后续操作。

标准化的遥测技术开始出现。OpenTelemetry的GenAI语义约定包含与MCP相关的跨度和属性。SEP-414等工作的_meta字段保留了W3C跟踪上下文的空间，使跟踪能够跨越MCP边界。官方Python SDK现在默认发出OpenTelemetry跨度。尽管团队调试代理-工具系统是否默认采用这种方式仍处于早期阶段，但一旦代理超越演示阶段，这一需求就显而易见。

构建Hexum.dev教会我的事

MCP 不仅仅是一个协议问题，它正在演变为一个基础设施类别。我们意识到，MCP 的挑战远不止于协议层面，而是涉及整个基础设施体系的构建。

Hexum.dev 今天作为一个托管的远程 MCP 端点，为代码代理提供服务。随着我们在上下文处理、架构检查和代理行为控制方面遇到更多相关问题，其功能范围也在不断扩大。代理仍然运行在开发者已有的编辑器中；Hexum.dev 则专注于该工作流中的特定环节。构建 Hexum.dev 并没有消除周边问题，而是将这些抽象问题具象化为可解决的工程挑战。

构建 Hexum.dev 的过程中有一个重要启示与协议无关： 构建过程本质上充满不确定性。很多想法在验证前就会失败，方向不断调整，大量时间都花在未被验证的探索上。在需要时能倾听、鼓励并挑战你的朋友，其价值往往被创始人低估。Yuchen 和 Pranav 就是这样的人。他们虽然没有直接参与 Hexum 的构建，但一直倾听我的想法，让那些不确定的探索变得更容易坚持下去。

MCP 基础设施可能成为独立的层级

一个可能的未来技术栈架构如下：最顶层是模型和代理，其下是代理运行时和 MCP 客户端，再下层是基础设施层，负责路由、认证、权限、上下文管理、工具发现、缓存、可观测性、策略和可靠性，然后是 MCP 服务器本身，最后是数据库、API、代码和 SaaS 系统。

这是一个假设性框架，而非确定结论。部分能力可能最终会集成到模型提供商、代理运行时、云平台、网关或单个 MCP 服务器中。边界并非固定不变。有趣的是，协议的成功正在推动这一问题的出现。当工具互操作性成为默认能力后，剩下的工作就是构建使其达到生产级可靠性的所有基础设施。

协议只是起点

MCP 最大的成就可能是让开发者开始将工具互操作性视为理所当然。这正是成功标准的最终状态——让原本困难的问题变得普通。

标准很少能消除基础设施需求，而是将基础设施问题转移到其他层面。HTTP 标准化了系统通信方式，但我们仍然围绕它构建了 CDN、负载均衡器、API 网关、可观测性平台、身份系统和云基础设施。MCP 可能会遵循类似路径。协议为代理提供了通用的工具语言，现在我们需要构建使这种语言在大规模场景下可靠运行的所有基础设施。

接口本身已不再是最大的挑战，围绕它的系统才是真正的难点。

这些文章采用知识共享 署名-相同方式共享 4.0 国际许可协议进行授权。

creativecommons.org/licenses/by-sa/4.0/deed.en