MCP单人上手容易，团队规模落地是另一回事

我已经用 MCP 一段时间了，它让我喜欢的一点是上手非常容易。找个 MCP 服务器，加到 Claude、Cursor、VS Code 或其他兼容客户端里，配置好需要的凭证，基本上就搞定了。

对在本地工作的开发者来说，这种模式非常合理。

但随着使用越来越多的 MCP 服务器，我开始思考：当超越单个开发者时，这个架构会是什么样子？

假设一个团队有 10 个开发者，有的用 Claude Code，有的用 Cursor，还有的用 VS Code。团队也有各种 MCP 服务器：GitHub、数据库、内部 API、监控，可能还有一些自己开发的工具。

简单的架构会变成这样：

从技术角度看，这没什么问题。每个开发者可以配置自己需要的 MCP 服务器，然后继续工作。

问题在于，现在配置、凭证和访问权限分散在多台机器上。到这一步，管理 MCP 开始看起来更像是管理基础设施，而不是配置开发工具。

凭证变得出奇地重要

凭证是让我首先想到这个问题的东西。

假设你有一个连接内部 API 的 MCP 服务器。当你一个人使用时，在本地保存凭证很简单。但如果 20 个开发者需要访问同一个服务，你就得决定这些凭证应该如何管理。

你可以把相同的凭证分发给所有人，但这样它们就分散在多台开发者的机器上。你也可以为每个开发者创建独立的凭证，这样隔离性更好，但会增加管理工作量。

然后常规的生命周期问题开始出现。有人离职了、API 密钥需要轮换、开发者转岗了、或者某个 MCP 服务器搬到了别的地方。

这些都不是 MCP 独有的问题。我们之前已经在数据库、内部 API、云基础设施和 CI/CD 系统上遇到过同样的问题。

有趣的是，MCP 正在一个新的地方暴露出这些相同的基础设施问题。

访问控制是另一个问题

一旦多个人使用相同的 MCP 基础设施，仅有身份验证是不够的。

你还需要决定每个人应该被允许使用什么。

例如，也许工程团队的每个人都应该能够使用搜索 GitHub 的 MCP 服务器。与此同时，你可能还有另一个连接到生产基础设施的 MCP 服务器，它应该只对一小部分人可用。

事情可以比这更细粒度。一个用户可能只允许调用只读工具，而另一个用户可以调用修改数据的工具。

使用本地 MCP 配置时，MCP 客户端通常直接连接到服务器：

这种简洁性很好，但也意味着没有一个中心位置来做这些决定。

当 AI 介入时，审计变得更有意思

另一个我最初没有太多考虑的问题是审计。

如果 AI 助手使用 MCP 服务器与 GitHub、数据库、内部 API 或其他公司系统交互，在某些时候你可能想要了解发生了什么。

在公司环境中，知道哪个用户发起了交互、使用了哪个 MCP 服务器、调用了哪个工具、以及何时发生的，这些都会很有用。

同样，这并不是什么令人兴奋的基础设施。日志和审计很少是。但这些通常正是那些无聊的问题——一旦某个东西从实验阶段进入常规使用，它们就开始变得重要了。

这开始让我想起 API 网关

我想得越多，这个问题就越让我想起 API 的演进过程。

一个简单的应用可以直接连接到一个 API：

随着系统变大，我们通常会引入另一层：

Client → API Gateway → Services

网关给了我们一个中心位置来处理身份验证、授权、路由、策略和日志记录。

这让我想知道 MCP 是否最终也需要一个类似的模式。

不是每个客户端都知道如何连接到每个 MCP 服务器，而是客户端可以通过一个公共层连接。

凭证可以集中管理。访问决策可以在一个地方进行。底层的 MCP 服务器也可以移动或更改，而不需要每个开发者都更新他们的配置。

当然，这增加了复杂性。如果你是一个开发者在笔记本上运行两个 MCP 服务器，引入网关可能会让你的设置变得更糟而不是更好。

但对于一个共享 MCP 基础设施的团队来说，我认为权衡会变得更有意思。

我决定把这个想法做出来看看会发生什么

在某个时刻，我意识到我可以一直思考架构，或者真正把它构建出来，发现它在哪里会出问题。

所以我启动了一个名为 MCPlama 的开源项目。

MCPlama 是我对网关/控制平面方法的尝试。MCP 客户端通过它连接，而平台负责处理 MCP 服务器周围的基础设施。

基本架构大致是这样的：

目标不是改变 MCP 本身。客户端和服务器仍然使用 MCP 进行通信。网关提供了一个地方来管理通信周围的那些部分：身份、凭证、策略、路由和审计。

我花了些时间考虑的一个设计决策是 MCP 服务器本身应该在哪里运行。

把一切都放在网关内部会让部署更容易，但我不太接受让任意的 MCP 服务器与控制平面共享相同的进程和环境。

相反，我开始将管理端和执行端分开。

这引入了额外的基础设施，但也创建了更清晰的边界——在管理 MCP 服务器和实际执行它们之间。

团队实际上是如何管理 MCP 的？

随着采用率的增长，我认为关于 MCP 的讨论会逐渐从「我如何连接这个服务器？」转变为「我们如何真正管理这一切？」

这意味着要弄清楚团队如何共享 MCP 服务器、凭证应该放在哪里、权限应该如何工作、私有服务器如何部署、以及组织如何跟踪他们的 AI 客户端在做什么。

我很想知道今天使用 MCP 的团队是如何处理这些问题的。开发者仍然在各自配置一切吗？你们围绕它构建了一些共享基础设施吗？或者你们在团队中使用 MCP 但根本没有遇到这些问题？

我真的想听听别人是如何解决的。