MCP：给 AI Agent 一个标准化的工具插座
Anthropic 今天发布了 Model Context Protocol（MCP）。
消息不算意外。任何在生产环境跑过 AI Agent 的人都会遇到同一堵墙：模型能推理，但它摸不到数据。每接一个数据源，就要写一套胶水代码。这件事不优雅，也不可持续。
MCP 试图解决的，就是这个问题。
问题本质：上下文孤岛
能力和上下文是两件事。
过去两年，业界花了大量资源在模型能力上——推理、长文本、多模态。这些投入是值得的，进展也有目共睹。但部署 Agent 的团队很快发现，模型够聪明没用，它看不到正确的信息。
根本原因是架构性的：数据住在系统里，模型住在 API 后面。两者之间的每一次连接都是手工活——自定义 retrieval、定制化的 function calling schema、一次性的 API wrapper。规模一上来，这套做法的维护成本会压死任何工程团队。
行业里已经有不少尝试：RAG pipeline、各种 tool use 框架、LangChain 类的抽象层。它们能用，但都是在应用层解决协议层的问题。治标不治本。
MCP 的设计选择
MCP 的架构简洁：MCP Server 暴露数据和能力，MCP Client（AI 应用）连接到 Server。协议层负责标准化两者之间的通信。
几个值得关注的设计决策：
传输层选 JSON-RPC。 这是务实的选择。JSON-RPC 足够简单、可调试、工具链成熟。没有为了炫技去搞自定义二进制协议。
本地优先，远程次之。 首发的 Claude Desktop MCP 支持是本地 Server。这降低了开发者的入门门槛——不需要部署基础设施，就能验证 idea。远程 MCP Server 的工具包”即将推出”，说明他们清楚这条路要走，只是没到时候。
双向连接。 “secure bidirectional connections” 不是随便说的。单向数据拉取不够用——Agent 需要读，也需要写，还需要订阅变化。MCP 的设计留了这个空间。
开源优先。 协议规范、SDK、预构建 Server 全部开源。这是正确的路径。一个只服务于 Claude 的私有协议不叫标准，叫壁垒。
类比：LSP 给了我们什么启示
理解 MCP 最好的参照是 Language Server Protocol（LSP）。
LSP 之前，每个编辑器要支持一门语言，就得自己实现补全、跳转、诊断。M 个编辑器 × N 门语言 = M×N 的集成工作量。LSP 出现后，变成了 M+N。语言提供一个 Server，编辑器实现一个 Client，两者通过协议对话。
MCP 试图做同样的事：M 个 AI 应用 × N 个数据源，变成 M+N。数据系统提供 MCP Server，AI 应用实现 MCP Client，通过协议连接。
类比的上限在于执行。LSP 成功的核心原因之一是微软同时控制了 VS Code（顶级 Client）和大量的语言 Server 实现，提供了足够强的参考。MCP 目前的参考 Client 只有 Claude Desktop，这是短板。
从 Agent Infra 视角看 MCP
构建 Agent 系统的团队应该关注几件事：
协议的价值在生态，不在协议本身。 MCP 规范今天就能读完，有用的是配套的 Server 生态。Anthropic 首批开源了 Google Drive、Slack、GitHub、Git、Postgres、Puppeteer 的 Server 实现，这是一个合理的起点。但真正的价值要等社区补完更多长尾 connector。
内部数据系统是真正的战场。 公开系统的 MCP Server 很快会有人写。企业内部系统——私有数据库、内部工具、遗留系统——才是大多数 Agent 实际需要的上下文来源，也是最难集成的部分。
多模型支持是关键变量。 如果 MCP 只有 Claude 实现，它是 Anthropic 的私有生态。如果 OpenAI、Google 的应用也支持，它才是基础设施。目前这个问题悬而未决。值得关注 Zed、Replit 这类工具的后续动向——他们既用 Claude，也在接入其他模型，他们的选择会说明问题。
对 Agentic Memory 的影响。 长期来看，MCP 和 Agent memory 系统之间存在关联。如果外部数据源可以通过标准协议接入，memory 层的设计就可以更干净地分离”短期上下文”和”持久化知识库”。这个方向目前还没有成熟的模式，但 MCP 的出现让它的解法空间变宽了。
现在该做什么
对于正在生产环境跑 Claude 的团队：现在可以用 Claude Desktop 测试本地 MCP Server，验证你最重要的内部数据源是否可以接入。成本低，反馈快。
对于在观望的团队：协议规范值得读一遍，理解它的模型。但大规模押注可以等等，等多模型支持的格局清晰之后再做决策。
对于想参与开源贡献的开发者：现在是好时机。MCP Server 的实现门槛不高，但生态缺口很大。写一个你日常用的工具的 MCP Server，是快速积累社区声望的方式。
MCP 是一次正确方向上的尝试。协议设计克制、开源路径清晰、起步生态有诚意。
但协议的命运不由设计决定，由采用决定。接下来一年，值得持续跟踪。