企业级 MCP 应用案例分析

直接 API 调用看似更便宜、更简单，但缺少大型组织所依赖的安全层。工具连接协议并未消亡，它们对于大团队的安全、治理和集中控制仍然至关重要。

Perplexity、MCP 与不断回归的辩论

距离 Perplexity CTO Denis Yarats 宣布公司放弃 Model Context Protocol（MCP）并转向直接 API、CLI（以及 Perplexity 新推出的 Agent API 产品）已经过去将近两周时间。这次采访引发了一波激烈辩论，Garry Tan 表示赞同，发推文说"MCP 真的很糟糕"，还有许多创业者和代码爱好者加入其中，而企业和安全导向的声音则提出了反驳。

说实话，这个辩论的论据与过去这 15 个月 MCP 推出以来多次出现的讨论没什么新鲜的，尽管 MCP 遭到反复质疑，但很明显 MCP 远未消亡。关于 MCP 优势的论证已经被比我聪明得多的工程师阐述过很多遍，所以我就不重复了。

这不完全是制表符 vs 空格的问题，尽管有时看起来像。这个辩论之所以反复出现，不是因为信仰问题，而是市场上存在一个巨大的鸿沟的症状。

从实践中看到的三种模式

与其对 MCP 的缺陷采取强硬立场，我不如分享我在日常工作中看到的现象。我与许多最大、最复杂的代码库背后的开发组织沟通，其中既包括拥有 50 年历史 COBOL 代码库的政府机构、银行和制造商，也包括最前沿的科技公司。今天，我看到了三个在规模化应对 MCP 时的新兴模式，以及上下文层市场中存在的缺口：

精心设计 MCP 范围和质量控制

我曾推文说 Stripe 关于他们 Minion agents 的博客文章基本上是开发工具创业者的指南，我想深入研究其中一个截图。

Stripe 在他们第二篇 Minions 博客文章中更详细地解释了他们的 Toolshed 层如何工作。

为了支持所有这些，我们构建了一个名为 Toolshed 的中央内部 MCP 服务器，使 Stripe 工程师能够轻松创建新工具，并让这些工具自动被我们的 agentic 系统发现。我们所有的 agentic 系统都能将 Toolshed 作为共享的能力层使用；将一个工具添加到 Toolshed 会立即为我们整个数百个不同 agents 的体系赋予相应的能力。

Toolshed 目前包含近 500 个 MCP 工具，用于 Stripe 使用的内部系统和 SaaS 平台。Agent 在给定一个"更小的框"（包含精心挑选的工具集）时表现最佳，所以我们为不同的 agents 配置只请求 Toolshed 工具中与其任务相关的子集。

Minions 也不例外，默认情况下获得有意精简的工具子集，虽然按用户自定义的功能允许工程师为自己的 minions 配置额外的主题分组工具集。

由于 minions 能够自主操作，完全自由地调用他们的 MCP 工具，我们还有一个内部安全控制框架，确保他们不能用工具执行破坏性操作。作为第一道防线，我们的 devbox 已经运行在 QA 环境中，因此 minions 无法访问真实用户数据、Stripe 的生产服务或任意网络出口。这不是意外：我们故意构建了隔离的 devbox，以便人类有一个可以安全实验的环境。但正如其他许多方面一样，对人类来说安全的开发环境对 minions 同样有用。

Stripe 的博客文章描述的是一个内部基础设施层，充当 MCP 的网关。每个内部 agent（他们可能有数十个甚至数百个不同用途的 minions 和其他 agents，超越了 Cursor、Amp、Claude Code 和 Codex 等"内循环"编码 agents）。

（我很想听听 Stripe 开发者的例子。在 500 多个 MCP 工具中，你们如何决定谁能用什么？访问权限是硬隔离的，还是 agents 可以搜索他们需要的工具？）

另一个我在 1 月份谈过的客户（2000+ 开发者）描述了一个官方的内部 MCP 注册表，提供给他们的开发者，加上设备级别的监控来追踪团队成员何时违反该注册表并访问外部 MCP（这是允许的，但会被追踪）。他们想让开发者探索和编写自己的 MCP！最终，围绕可靠身份认证和授权的问题是唯一阻碍他们前进的因素。

正如我上面推文中所说的：为世界上其他公司构建像 Stripe 的 Toolshed 这样的基础设施，或能根据客户风险偏好调整的 MCP 注册表，是一个巨大的机遇和需求。

通过搜索发现工具的路由模式

我最近与一家接近 1000 名开发者的公司交谈过，他们为所有开发者构建了自己的"Code Mode"式 MCP 路由器。与上面 Stripe 的方法类似，这个平台允许团队将 MCP 即时推送到每个开发者。但他们不是通过范围限制来控制上下文膨胀，而是通过他们的平台让 agents 能够在核心 agent 循环中搜索 MCP（或工具）来解决需求：

如果我们开始把一大堆工具放到 Claude Code 中，你会很快耗尽上下文窗口。

我想要的是一个单一平台作为入口，可以扇出到我们使用的所有 MCP。

我没有实现的细节，但描述画出了一个类似 Cloudflare 的 search() 和 execute() 接口的图景。思考这个模式的发展方向很有趣：agents 会运行两层搜索（或用 JavaScript 实现），首先是 MCP 服务器，然后是该 MCP 服务器提供的工具？我们确实知道工具可见性的缺乏会导致下游问题，而这个抽象可能会变得混乱。回到引发这篇文章的原始话题，使用 CLI 代替 MCP 服务器会造成可发现性缺口。一个客户告诉我：

早期我们提示 agent 使用 JIRA CLI 时效果不好。而有了 MCP 工具，由于它对能力和输入参数有描述，agent 的使用要好得多。这可能取决于具体的 CLI；GitHub CLI 被广泛使用，但其他的不是这样。

当 agents 使用 MCP"多路复用器"（没有预加载的描述和 schema）时，会付出类似的代价吗？

这个辩论仍在进行中。我对未来感到兴奋。

"让一百万个 MCP 绽放"

最后，我在 3 月初与另一家拥有 3000+ 开发者的公司交谈过，他们描述了他们的方法：

我们是一个技术优先的公司，我们正在内部构建大量 MCP。在团队构建和部署 MCP 来为某个受众提供上下文的能力方面，它完全民主化了。

我第一次听说这种方法作为一个有意的策略是在去年末（来自一个更大、更老的、不那么技术优先的公司）。这让我有点惊讶，我（天真地）把它解读为技术债。但从更多方向听到它现在让我质疑那种直觉反应，我能看到它的吸引力。

现在是一片荒蛮之地；CISOs 担心施加太多控制可能导致"黑市" MCP 在公司内部出现，这些 MCP 在安全和法律边界之外运作。或者，通过锁定太多东西，高管可能会拖累公司速度，这是当今最大的罪恶。

坦白说，我没有这家公司使用的 MCP 身份认证/授权机制的细节。也许 MCP 控制正通过认证层执行？

我真的想知道如果（当）由此产生性能或安全事件时，我们是否会看到一个转变。

客户端和基础设施跟不上时代

我的结论是没有共识，这是开发工具领域的熟悉之处。很清楚的是，在规模化运营中，需要一个结构化的格式来控制上下文层。谁将登记帮助公司管理不可预测和无限的感兴趣的服务组合？如果 agent 客户端继续忽视这一企业需求，或无法正确实现，我预计会在这个领域看到价值十亿美元的初创公司。或许这一切都会被 agent 身份认证生态消化？无论如何，我很兴奋。

在此期间，我们将继续为 agents 构建 Sourcegraph 搜索和 Deep Search 作为原生支持，无论是通过 MCP 还是 CLI。我们新的 Agent Advocate 将为 agent 赋能设立标准。

但有一个共识是明确的：我在过去 3 个月与之交谈的每一个企业（数十个）都在大量使用 MCP。不用说，X 上的 AI 独立开发者工具泡沫并不代表真实世界。

特别感谢以下个人对本博客文章的贡献：Justin Dorfman 和 Stephanie Jarmak

解锁你的组织。更快地交付。

使用 Sourcegraph，企业代码理解平台。