本文首发自个人博客对话 MCP 团队：MCP 的起源、技术细节与设计思路、与 Agent 的关系及未来迭代方向
上一篇文章《MCP 的应用场景，其实是一个巨大的赚钱机会》 发出后，后台接到很多读者留言，询问能否写一篇文章再详细介绍下 MCP 设计细节，本来想动笔，不过凑巧的是，搜索过程中发现 AI Engineer 频道刚好在上周五（4 月 4 日，新鲜热乎的 🤙）采访了MCP 团队的两位发起工程师 ，基本涉及到了 MCP 的方方面面。本篇内容是访谈的脱水版文字稿，移除了和 MCP 无关的话题和口头表达时的语癖，基本能够解答大家对 MCP 的起源、技术细节与设计思路、与 Agent 的关系及未来迭代方向的疑问，也比大多数能读到的二手内容权威多了。
人物介绍
- 主持人 Alessio (A) ，Decibel 合伙人兼 CTO
- 主持人 swyx (S) ，Small AI 创始人
- 嘉宾 David (D) ，Anthropic 工程师
- 嘉宾 Justin (J) ，Anthropic 工程师
00:37 什么是 MCP？
S：能否先给大家一个简明的定义？MCP 是做什么的？
J：好的。MCP 全称是 Model Context Protocol，我们想解决的是"如何让 AI 应用快速而灵活地扩展功能"。具体而言，MCP 提供了一套通信协议，让 AI 应用（我们叫"客户端"）和各种外部扩展（我们叫"MCP 服务器"）能彼此协作。这里的"扩展"可以是插件、工具或者其它资源。MCP 的目的就在于让大家在构建 AI 应用时，能够轻松引入外部服务、功能，或者调取更多数据，让应用拥有更丰富的能力。我们的命名中有"client-server"的概念，主要是为了强调交互模式，但本质就是在做一个"让 AI 应用更易扩展"的通用接口。
D：简单说，MCP 对应的场景就是：当我们在用一个 AI 应用时，常常想让它接入更多外部工具、数据或特性。但如果每次都要单独做对接，就会很繁琐。MCP 类似于"USB-C 接口"，它以统一的方式让不同 AI 应用对接到各种工具和资源。而且，它面向的是 AI 应用，不是直接去修改底层模型。
02:00 MCP 的起源
D ：我在加入 Anthropic 之前，一直在做开发者工具，特别关注如何让开发者提升效率。加入后，我在内部使用 Claude Desktop，发现在某些场景下，我需要在 IDE 与 Claude Desktop 之间反复地复制粘贴，才能够获得我想要的上下文或工具访问权限，这样的体验让人感觉很割裂。于是我开始思考：能不能做一个类似 LSP（Language Server Protocol）的东西？把这种"AI 应用与扩展之间的通信"标准化。 当时我还在看如何把 LSP 部分思想应用在内部工作，就跟 Justin 在一个小会议室聊了这个想法，他也很感兴趣。我们快速迭代，做出了 MCP 的雏形，先写了个简单协议和测试版 SDK。期间还做了对 Claude Desktop 和 IDE 的初步集成。后来我们内部办了一场黑客松，一些同事用 MCP 编了可以控制 3D 打印机的服务器，还有实现"记忆功能"之类的扩展。这些原型大受欢迎，让我们相信这个想法能带来很大潜力。
J：对，我接到 David 的想法后，也觉得特别有价值。前期开发基础设施很枯燥，比如要定义协议、实现 SDK、多语言互通等。但当我们终于把最初版本跑起来时，就能在很短时间内编写新工具、让它们跟 Claude 或其它 AI 应用对接。内部黑客松的那些有趣项目，让我们看到 MCP 的可塑性和落地价值。
05:18 开发挑战与解决方案
S：提到 LSP，你们的 MCP 看上去也采用了 JSON-RPC、双向通信等模式。为什么还要花很多精力设计呢？能否具体谈谈开发时遇到的挑战？
J ：LSP 解决的核心是编辑器与编程语言的"M×N"难题：不同编辑器都要适配各种语言，很容易重复造轮子。LSP 就统一了协议，让"编辑器-语言"各自只需要实现一次。而我们的目标类似，只不过场景换成了"AI 应用-扩展"之间的对接。 然而，LSP 本身只解决了开发者工具中的一种形态。我们需要在 MCP 中加入更多"AI 场景"所需的原语，比如工具（Tool）、资源（Resource）、可插入的提示（Prompt）等。每一个概念代表不同的交互方式，工具让模型主动调用函数，资源可以让用户或模型在聊天时插入额外数据，提示则更像可插入的文本模板。要把这些都抽象好，并保证可扩展性和易用性，需要大量设计和取舍。
D ： 我们参考了针对 LSP 的诸多批评意见，尽量在 MCP 中改进。例如 LSP 在 JSON-RPC 上的某些做法太复杂，我们就做了一些更直接的实现方式。但真正花时间的是如何确定 MCP 应该提供哪些功能原语、如何让它们在应用层表现得简单并且强大。最初几个月，我们主要都在讨论和打磨这部分，像"工具调用如何体现给用户？资源应该怎样标识和加载？提示能否支持多步文本？"等等，保证了现在 MCP 虽然结构不大，却能表达丰富的 AI 交互模式。
08:06 技术细节与设计思路
S：你们反复提到"工具""资源"和"提示"三个核心原语，能不能详细说说你们为什么要这样区分？
J：好的。
- Tool：让模型自行决定什么时候调用。对应用开发者而言，这类似"函数调用"，只是由模型发起的。如果一个 MCP 服务器提供 "获取天气" 这种功能，模型在推理时如果觉得需要天气信息，就会直接调用这个工具。
- Resource：相当于可以给模型或用户引用的外部数据。可以是文本、文件，也可以是数据库记录。它有唯一 URI 标识，应用可以在交互过程中让模型选择要不要用这些数据，也可以让用户从"资源列表"里手动挑选注入对话。
- Prompt ：这是人为触发的提示文本，相当于"提示片段库"。在编辑器里，可能以
/ 命令或模板形式出现。当用户想使用这个提示时，可以直接注入给模型。
D ：我们发现很多人对"函数调用"非常关注，但其实在实际场景中，有很多是用户或应用希望主动插入的上下文------这并不一定让模型自己调用。所以 Resource 和 Prompt 就变得非常必要。Prompt 还能支持多步链式的文本，这样我们可以预先设计复杂提示场景，避免每次都手动复制黏贴大段文本。这些都让 MCP 能表达更丰富的体验。
29:45 MCP 与 OpenAPI
S：很多人会问，MCP 和 OpenAPI 对比如何？或者说它们会不会冲突？
J：OpenAPI 在传统 RESTful 领域很成熟，但如果你想针对 AI 场景，构建那种可多轮调用、可调取不同数据上下文的扩展，OpenAPI 可能太细粒度了。它并没有"提示""资源""工具"的高级抽象。我们更希望为 AI 应用提供专门的协议能力。 当然，OpenAPI 还是很有用，很多人已经实现了从 OpenAPI 自动转成 MCP 服务器的适配器。如果你只需要一次性的函数调用，OpenAPI 很好。但是如果你需要让模型在上下文中混合使用外部数据、多步推理、用户插入提示等场景，就会发现 MCP 更加自然。
D：两者其实是互补而不是对立。MCP 允许工具端更灵活地表达自己可提供的功能和数据，也支持模型和用户在多轮对话中随时获取或调用。OpenAPI 仍能保留自己在描述 API 方面的优势，只是对于 AI 应用场景，有时 MCP 更贴近需求。
32:48 如何构建 MCP 服务器
A：你们有许多示例服务器，比如"文件系统服务器""记忆服务器"之类。对想要自己做 MCP 服务器的开发者，你们有什么建议？
D：最好的办法就是直接动手写一个最小可用版。你可以挑选任意语言，看看是否已有对应的 MCP SDK，然后实现一个简单的"工具"即可。比如你想给模型一个"把某些表格数据返回并总结"的接口，你只需创建一个 MCP 服务器，提供一个返回数据的函数描述，用几行代码就能跑通。后续再慢慢完善，比如增加更多资源、提示、或更灵活的工具描述。
J ：对，而且你还可以把 MCP 的相关文档和 SDK 代码复制进一个 AI 模型，比如 Claude 里，告诉它"帮我写个 MCP 服务器，支持某个功能"，它一般会给出一个可行的初始版本。然后你再手动做一些修改就行。 MCP 一开始就故意做得很简洁，让开发者能快速上手。
40:39 MCP 与 Agent 的关系
S：说到可嵌套的客户端与服务器，如果一个 MCP 服务器本身也能调用别的 MCP 服务器，这会不会像"Agent"？
D ：可以这么理解，但也要看你怎么定义"Agent"。MCP 自身只是一种通信协议，让"上下文管理"和"调用逻辑"能灵活组合。如果你在服务器里加一套多步推理或递归调用逻辑，就可以做出一个"Agentic"的 MCP 服务器，比如对接数据库时多次查表、总结，然后再把结果返回给客户端。但 MCP 本身并不会强制你一定要这样做。
J ：我们希望先把协议打磨好，用来连接 AI 应用和外部扩展。Agent 常常包含更多策略或推理机制。MCP 只是提供一个底层"双向通信"的能力，让你能在需要的时候实现 Agent 化的功能，但并不把所有 Agent 逻辑都装进协议中。
43:13 MCP 中的"工具"与"提示"
D ：很多人觉得"工具调用"是最直接的方式，但其实"资源（resource）"和"提示（prompt）"也很重要。例如，如果你要让用户自行决定何时引入某份文件或信息，用 Resource 会更自然，让用户选完后注入给模型。 提示（Prompt）则更像编辑器里 / 命令 或"模板插入"的概念，可以是一段固定文本，也可以是多步或带变量的提示，这样用户一键就能把复杂提示加入对话。
J：这些原语背后都有各自适用场景。工具是"模型自己想用时随时可调"，资源更像"额外可选上下文"，提示则是"用户显式想插入的预设文本"。我们希望把这些都抽象出来，给应用开发者提供更多可控的用户体验，而不是所有事情都丢给模型自由调用。
45:45 MCP 中的嵌套调用与工具混淆
S ：如果我在同一个上下文里挂载了很多 MCP 服务器，里面可能有几十个工具，模型可能会混淆，该怎么解决？
J ：在现阶段，可能需要应用侧做些辅助，比如只在恰当时机暴露特定工具，或者对工具说明做严格区分，或者用个轻量模型先判断该用哪个工具，再把结果交给大模型。 毕竟，如果全都一次性扔给模型，难免出现混淆。而且实际可用多少工具，也取决于模型的上下文能力和对描述的理解程度。
D ：如果两个工具功能或描述太相近，就很容易让模型搞错。随着模型变得更强大，这个问题可能会逐渐缓解。但目前看来，让客户端对工具做些筛选或优化描述是一种不错的做法。也有开发者尝试做" Agentic 服务器"，帮你在众多工具里选择，再调用真正的功能。
49:11 客户端如何控制工具调用
J ：我们非常强调一件事：虽然 MCP 里"工具"是由模型发起调用，但应用和用户拥有最终控制权。客户端完全可以决定哪些工具暴露给模型，也可以决定如何描述这些工具。如果用户不想让模型访问某些工具，或者想对工具做额外安全检查，应用端可以直接过滤或修改工具信息。
D ：对，MCP 设计中保留了应用端最大化的自主性。我们不希望模型直接"越权操作"，也不希望开发者在做安全或隐私控制时束手束脚。协议只是把"双向沟通"的通路打通，但何时允许、如何允许，都可以在客户端层面管理。
52:08 MCP 服务器的授权与信任问题
A ：那在授权和安全上，你们怎么处理？比如我要用一个第三方 MCP 服务器，该怎么确保它是可信的？
D ：我们在下一版协议里加入了对 OAuth 2.1 的最简支持，让用户在浏览器里完成授权流程就行。这样服务器就能有一把令牌来确认访问权限。当然，若在本地场景，也可以通过本地通信来处理。更复杂的需求，像细粒度授权、访问范围等，可能还需要做扩展。我们想先解决最普遍的场景，看社区是否有针对特定需求的方案，然后再考虑要不要写进协议。
J：确实，任何软件供应链都有可能被攻击或滥用。我们或许需要一些"信誉"或"签名认证"，让大家知道某个 MCP 服务器是不是官方或社区认可的安全实现。但这又牵涉到"谁来背书""谁来维护"等问题。我们倾向先让协议保持灵活，等社区积累足够经验后，再考虑更完善的治理或认证机制。
01:01:34 无状态服务器与未来发展
S：你们最近更新了"无状态"或"可断开重连"的传输方式，以前用 SSE 做长连接有没有问题？
J ：最初我们用 SSE（Server-Sent Events）做长连接，让客户端和服务器保持持续的会话，这样服务器可以随时推送。但对大规模分布式部署可能不太友好。 社区反馈也提出希望有无状态 HTTP，这样部署会更灵活。因此我们和社区讨论后提出一种可流式 HTTP 传输，让服务器和客户端可以在需要时重连并恢复会话，既能做到状态追踪，也更便于横向扩容或处理断线情况。
D ：对，我们相信 AI 应用未来一定需要相当程度的"有状态"支持，尤其当涉及多模态或更复杂的任务。但我们也理解很多人想用传统无状态 HTTP 部署模型服务。所以现在我们就折衷出一套"可流式+可断线重连"的方案，保留了两边的优点。
01:10:07 开源治理与社区参与
A：MCP 开源后，你们怎么看待多方共建、标准化组织等话题？有可能像 GraphQL 那样进入基金会吗？
D：我们非常希望 MCP 成为真正的开放标准项目，而不仅是 Anthropic 的"私有协议"。现阶段，我们先把代码放在一个公共仓库里，不少公司都在贡献，比如 Microsoft 做了 C# SDK，JetBrains 做了 Kotlin 版本，Block、Shopify 等都对协议提出过改进意见。我们也给很多核心贡献者直接的提交权限。 真正要把它放进某个正式的标准化组织时，就会涉及很多流程------这可能减缓创新速度。我们当下更想用更灵活的开源社区模式，快速试错迭代。
J：对，而且治理也是一个渐进过程。当前重点是维持社区活力和高速迭代。我们并不排斥未来成立专门基金会，也不排斥和更多企业一起共建。但我们要让协议在真正需求的驱动下演进，而不是陷入"委员会式开发"的泥潭。
01:18:12 "理想"的 MCP 实现或项目
A：你们还有哪些希望社区做的 MCP 实现或项目？
D：我个人一直想要更多关于"采样推理"（sampling loop）的客户端，也希望有人写一些能自动汇总 Reddit 或游戏动态的 MCP 服务器，让模型读外部信息再做总结。另外，我也希望看到更多人用资源、提示等原语，做出真正"上下文丰富"的体验。别只停留在工具调用。
J：我做游戏开发爱好者项目时，特别想要一个对接 Godot 引擎或 Unity 的 MCP 插件，能让模型对游戏环境进行自动测试、调试甚至写关卡脚本。对于我来说，这才是把 AI 应用的能力最大化的场景。当然还希望有更多客户端能完整支持 MCP 的所有原语，让社区建起多种不同类型的应用。
A：非常感谢你们两位详细分享，让我们对 MCP 的设计初衷、发展方向和潜力都有了更多了解。祝你们未来一切顺利，也期待 MCP 生态越做越大！