推荐语
AI正在从聊天工具进化为"动手做事"的智能体，MCP协议正是这一变革的关键推手。
核心内容：
1. MCP协议如何成为连接AI与真实世界的"USB-C"接口
2. MCP Server如何通过三大原语改变人机交互方式
3. 协议设计中的Sequential Thinking等创新机制解析
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
从「模型只能聊天」到「模型开始写代码、查数据、连设备」——
你是不是也感受到，AI 正在“亲自上手做事”了？
这背后，离不开一个关键角色：MCP（Model Context Protocol，模型上下文协议）。
🎧 在本期《Latent Space》播客中，MCP 联合创建者 Justin 和 David带来一场硬核但易懂的技术漫谈，全面解析：
🧩 MCP 到底是什么？为什么它被称为 AI 的 USB-C？
🛠️ MCP Server 如何连接模型与工具，构建真实世界能力？
🧰 Sequential Thinking、Memory、File System 等代表性 Server 背后有什么设计巧思？
📚 Prompt、Resource、Tool 三大原语如何改变交互方式？
🌍 MCP 如何一步步成为“AI 应用的统一接口层”？
📁 本文为超 2 万字逐字翻译稿，结构清晰、信息密度极高，
建议【收藏 + 分段阅读吸收】。
🧑💻 如果你正在构建 AI 产品，或希望深入理解
下一代智能体的工作方式与设计原理，这篇文章值得你反复研读。
《Latent Space》播客：Model Context Protocol（MCP）特别篇👥 嘉宾：Justin Spa Summers & David Sauria Para（MCP 协议联合创建者）🎙️ 主持人：Swyx（Small AI 创始人）& Alessio（Decibel 合伙人兼 CTO）
大家好，欢迎回到《Latent Space》播客节目！我是 Alessio，Decibel 的合伙人兼 CTO，今天和我一起主持的是 Swyx，Small AI 的创始人。👋 早上好！我们今天远程连线了两位来自 Anthropic 的嘉宾——David 和 Justin，他们此刻正在伦敦。欢迎你们！你们因为 MCP 可谓在圈里掀起了一阵旋风，所以我们特别高兴能把你们请来，也感谢你们愿意抽出时间接受这次访谈！那我们就直接切入正题——到底什么是 MCP？我们想先听听你们最“官方原汁原味”的定义，之后再谈它的起源。MCP，全称是 Model Context Protocol（模型上下文协议），它的本质是一种我们设计出来的机制，目的是为了让 AI 应用变得更强大、更具可扩展性，能无缝地集成到一个插件生态中。我们用了“客户端-服务器”这种术语来描述它——虽然说法有点不同寻常，但这其实很好地反映了它的运作方式。说到底，MCP 就是为了扩展和增强 AI 应用的功能。对，我觉得 Justin 的说法非常准确！关于 MCP 的解释有很多种方式，但核心目标其实就是让 AI 应用本身更强大，而不是让模型本身发生变化。这一点特别关键——很多人误以为 MCP 是关于“模型”本身的，其实不然，MCP 专注的是“应用层”。我们后来很喜欢的一种比喻是——MCP 就像是 AI 应用的 USB-C 接口。什么意思呢？它是一种通用的连接器，可以连接一个完整的生态系统，允许各种工具、资源、功能无缝对接。对，而且它的一个有趣特性是：它是双向的（two-way）。就像 USB-C 那样，既可以传输数据，也可以接收信号，MCP 也是一种双向通信协议，这让 AI 应用可以和外部世界实时对话、协作。其实一直以来很多人都试图制定“代理标准”、建立开源规范。但我感觉 Anthropic 在开发者方向上 的推进力度是其它实验室都不具备的。所以我特别想知道，MCP 的诞生背后，有没有什么外部影响？还是你们俩真的就是在某个房间里即兴碰撞出来的？说实话，这真的是我们两个人在一个小房间里开始讨论出来的。这背后完全没有什么宏大战略，也不是公司什么高层的决策。如果你把时间拨回到 2024 年 7 月，那时我刚加入 Anthropic 两三个月。我的主要任务是开发内部使用的开发者工具。我之前的职业生涯基本也都在做类似的事情。而在这个过程中，我一直在思考：我们该如何让更多 Anthropic 的员工能够深入地和模型集成、交互？在做内部工具的过程中，我越来越意识到一个痛点：我们虽然拥有非常强大的模型，但很多工具之间完全无法联通或扩展，体验极其局限。- 一个是 Anthropic 内部的 Cloud Desktop，它有很棒的 artifacts 管理功能；
- 另一个是我自己熟悉的 本地 IDE，可以操作文件系统、写代码，但没有 Cloud Desktop 那种集成体验。
结果就是我经常需要手动把文件从一个工具复制到另一个工具，来回折腾，非常低效，久而久之让我越来越沮丧。作为一个长期在做开发工具的人，我很快意识到，这其实是一个典型的 M×N 问题 ——有很多不同的应用（M），又有很多你希望它们连接的能力或资源（N），所以与其一个个写死连接，我们是不是应该干脆定义一个“协议”？“我觉得我们应该把这个东西做出来，这主意挺不错的。”幸运的是，Justin 当时也很感兴趣，我们就一拍即合，一起着手动工。这就是 MCP 的真正起点：我们两个人从那一刻开始，花了大约一个半月时间，一起构建了这个协议。主要是负责将 MCP 的第一版协议集成到 Cloud Desktop 中。我这边则主要在 IDE 端实现了一些早期原型，用来展示 MCP 的基本工作方式和潜力。其实如果你当时在 GitHub 上“盯着正确的 repo”，就有可能在官方发布之前，提前发现一些关于 MCP 的蛛丝马迹。
你们是什么时候开始真正开发 MCP 的？我记得是 11 月 25 日正式官宣对吧？那最早是从什么时候动工的？我记得大概是 7 月左右。David 一跟我讲这个想法，我立刻就被吸引了，然后我们几乎是在那次谈话之后就开始动手了。但说实话，接下来的几个月我们都在做一些“没啥成就感”的基础工作，因为作为一个通信协议，MCP 需要涵盖客户端、服务器、各种 SDK……在真正跑起来之前，得先打好一大堆底层地基。之后的几个月，我们确实在默默干一些“看不到成果”的活儿，全在铺设 MCP 的基础设施和通信通路。但一旦你看到：“诶，协议跑通了！”那瞬间真的非常令人兴奋——你就能开始搭建各种疯狂的应用场景！我记得是在正式发布前的一个月左右，公司内部搞了一次 Hackathon，好几位同事因为 MCP 激动得不得了，疯狂搞各种实验。我印象最深的是：有人真的用 MCP 做了一个服务器，能远程控制 3D 打印机！那一刻大家意识到：“我们真的在让 AI 和现实世界产生连接。” 这也极大地推动了后续的发布节奏和信心。你们刚刚提到：如果有人当时看对地方，其实就能提前发现 MCP 的迹象。我们一直都想知道：“哪里才能抢先获得行业内幕？”我是一个资深 Zed 编辑器用户，我很喜欢这个工具。而事实上，第一版 MCP 在 IDE 上的实现，就是我在 Zed 上写的。它上线时间比正式发布早了大约一个半月。我们之所以这样做，是因为 Zed 是个开源项目，我们需要把开发过程放在公开环境中进行。那时候我们还没确定 MCP 这个名字，代码里叫法略有不同，但那时的雏形已经在那里了。话说回来，我还记得 Anthropic 之前也发布过一个模型预览，你们是不是也有一个和编辑器结合的快速编辑模型？我自己平常是 Cursor 和 Windsurf 用户，还没试过 Zed。你们能不能简单说说 ——Zed 有什么特别之处？其实这还要看你对编辑器最看重什么功能。我自己也用 Windsurf，也用 Zed。我觉得 Zed 最大的优势是：延迟极低，编辑体验超级流畅，而且 AI 集成也做得“还不错”。当然，很多人深度绑定 VS Code 的生态，插件多，迁移成本高，但 Zed 的表现确实很亮眼。MCP 的设计看起来明显是受了 LSP（语言服务器协议）的启发。当你们说“花了几个月在构建 MCP”时，究竟是在构建什么？是大量的编码？还是协议的设计？确实，我们从 LSP 得到了很多启发。David 对这块经验更丰富，我更多是做产品和底层架构的。LSP 的最大贡献之一是解决了 M×N 的对接问题：不同编辑器和语言之间的适配都统一了。这正是我们设计 MCP 想借鉴的理念——把 AI 应用和其扩展能力之间的对接，标准化为“共同语言”。我们采用了 JSON-RPC、双向通信，同时也保留了 LSP 的“以呈现为导向”理念（presentation-focused），即不同语义应有不同界面呈现方式。我们从一开始就决定支持三种语言 SDK：TypeScript、Python、Rust（Zed 用）。所以我们确实也写了很多代码，搭建客户端与服务器的交互机制。我们还设计了一个叫 Local MCP 的机制，能在本地以子进程方式处理请求。为保证系统稳定，我们花了不少时间在底层打磨。我们还特别研究了很多 LSP 的批评意见，比如 JSON-RPC 的特殊用法，我们没有照搬，而是设计了不同的实现方式。通信协议我们用 JSON-RPC，不搞新花样。我们真正聚焦的是 MCP 中的原语设计：我们的目标从一开始就清晰：MCP 的价值不在于“用什么协议”，而在于“它提供了哪些能力”。06🔍 Resource原语 & Prompt 的现实用法与潜力你们提到“功能在应用中的呈现方式”很关键。为什么要把语义接近的功能分成多个原语？- Tools（工具）：模型主动调用功能（类似 function calling）
- Resources（资源）
- Prompts（提示语）
这些原语不是为了限制开发者，而是提供更多表现方式和自由度。大多数集成仍停留在 tool calling，但其实 Prompt 和 Resource 原语很有潜力。- MCP Server 可从 Sentry 提取错误堆栈，以 prompt 形式加入上下文
- Resource 可暴露数据库文档等，由客户端构建 RAG 检索系统
这些机制能让应用更主动控制上下文信息，提升交互效率。很多时候你只是想让模型参考一个数据库 schema，完全没必要非用 Tool Call 包一层。客户端可以自动智能搜索，也可让用户手动选择资源，大大提升了交互灵活性与上下文清晰度。07🎯 Resource 与 Prompt如何区分？在 Zed 编辑器里，我们通过 Resource 加载一组默认提示语（Prompt Library），模型就能主动展示它们供用户选择。这种“已有界面行为 → 协议原语”的转换，是 MCP 可扩展性的核心关键。没错。我们不是凭空发明，而是把已有应用行为标准化为协议原语，从而实现通用和复用。你们刚才提到工具（Tool）和资源（Resource）的区别，我觉得这正好是大家经常搞混的地方。比如说，现在有些人会写一个工具，让模型来执行 SQL 查询，但有时候这个“查询动作”看起来其实也可以被当作一个 Resource。那你们怎么看？到底什么时候该用 Tool，什么时候该用 Resource？有没有什么明确的标准或者建议？- Tool 更像是 模型主动调用的能力，也就是说，模型自己判断需要的时候，就会去执行某个 Tool。
- 而 Resource 更偏向于 “提供信息”或“上下文补充”，它可能是用户选出来的，也可能是应用加载进来的，但模型本身不会去“调用”它，它是被动放进来的背景信息。
不过我得坦白讲，现实中这个区分有点模糊，因为很多客户端现在还不完全支持 Resource 这个原语，所以开发者只能退而求其次，把一些逻辑塞进 Tool 里。- Tool：模型主动使用，如“查询天气”、“执行 SQL”；
- Resource
而且 Resource 都有 唯一的 URI 标识符，你可以把它们看作是 MCP 世界里的“网址”或“引用”。比如你扔进一个 URI，模型就知道“哦，你是在说这张表”，然后 MCP Server 就可以根据 URI 返回对应的数据，这就构建起了一个非常通用的上下文引用机制。其实还有一个特别实用的用法是：你可以设计 MCP Server 来处理这些资源 URI，自动完成解析、抽取和上下文填充的工作。举个例子，Zed 的 Prompt Library 就是这么做的。我们用 MCP Server 暴露了一组默认提示语，作为 Resource 形式提供，Zed 启动时就自动加载这些 prompt，放进 UI 里供用户选择。整个流程既简单又优雅，Server 处理资源的 URI 和内容，客户端直接渲染和使用这些“动态提示语”。从应用开发者的角度，我们在设计 MCP 的时候，也有个很重要的思考方向：“如果把应用里已有的功能，拆分成 MCP Server，会长成什么样？”举个例子，现在很多 IDE 都有附件菜单（attachment menu），你点开能看到项目文件、日志、配置等资源。这些东西，其实就可以被自然地建模成 Resource 原语。对，我当初看到你们在 Cloud Desktop 引入 MCP 的时候，第一反应就是：“诶，这不就是 Cursor 里那个 @ 功能吗？”你们现在把它做成标准协议，对整个生态真的是个重大进展。这意味着 不只是 Cursor，而是每个 IDE 都可以拥有类似能力。我最近还在看 Mahesh 的 MCP 工作坊，他的总览图我非常喜欢，几乎把 MCP 的全部概念都梳理清楚了。哈哈，其实这是个不错的建议。你要不要直接给我们提个 PR？（笑）哈哈我很愿意啊，我之前还给 Mahesh 的工作坊提过 PR，因为我真的觉得——“如果你想教大家理解 MCP，第一步就要给他们一张完整的地图。”这样大家在脑子里就有一个总纲，后面讲解的所有内容，都能对上号。其实你们提到的 prompts（提示语）这一块我特别感兴趣。从 ChatGPT 和 Claude 刚发布时，大家就搞“Prompt Library”、“Prompt Manager”，还冒出很多“Prompt GitHub for AI”的项目，但后来都没火。我觉得 MCP 的 prompt 可能是这个空白领域的答案。像 Humanloop 做的 PromptFile 项目也在尝试标准化提示语，但我觉得 MCP 的设计更进一步：- 甚至支持多步嵌套（multi-step prompting）。
因为我们都知道，有时要让模型输出一个合格结果，是需要引导、反思、甚至 jailbreak 的，不是一句 prompt 就能搞定的。不过我注意到：像 Google Maps 的 MCP Server 示例，返回字段是作者定义的，用户不能覆盖字段，只能接受预设内容。这让我想起很多 API SDK 的问题——接口更新了，SDK 没跟上，参数就不能用。你们怎么看这个问题？Server 开发者和终端用户之间，边界应该怎么划？我猜你说的是我们发布的 Google Maps Server（笑）。我们在 Tool 的设计上，其实是刻意不做结构化 schema 限制的。返回结果不是固定格式 JSON，而是直接输出文本、图片或模型能理解的自然语言内容。“把尽可能多的信息原样返回给模型，让它自己判断、提取、整合。”这就是大模型的强项啊！你不用管字段名，直接整包数据给它，它会自己处理。我们不想因为过度设计结构，限制模型本该具备的泛化能力。那种 "formatted_address" 字段其实很多余，模型不需要我们格式化地址，它可以自己理解。 预处理太多只会降低灵活性、增加耦合度。“既然你用了大模型，就要相信它，别用传统方式限制它。”太多开发者还用传统 API 思维写 MCP Server，比如提前结构化转换——这其实不适合模型交互。很多人习惯了几十年的软件工程思维，让他们放弃精细控制不容易。但模型越来越强，我们必须改变思维方式，更多依赖模型的推理能力，而不是替它做一切。我还想补一句：MCP 不只是为了解决现在的问题，更是对未来的下注。现在每次模型升级都带来飞跃，但下一步突破可能不在模型本身，而是模型和外部世界的连接能力。MCP 就是我们押注的方向，它让模型自然地与现实世界交互，也保留了安全性、权限控制等机制。我还有一个观点，像 "formatted_*" 这样的字段，其实都该淘汰。模型现在真的够聪明，能自己处理各种格式，我们只需要给它真实内容。未来每个 MCP Server 就像一个 USB-C 插口，模型自己识别、适配。他们依然用传统 API 思维做 MCP Server——定义字段、限制参数、处理格式……这不是 LLM 的哲学。两年前模型可能还处理不了这些结构问题，但现在它们完全能胜任，甚至比我们做得还好。所以我们要学会“放手”：别再被几十年工程洁癖束缚，这是全新的智能体，要重新书写规则。12🔗 MCP vs OpenAPI，有什么不同？很多人会把 MCP 和 OpenAPI 混为一谈，你们能不能清楚地讲讲区别？好问题！我们不否定 OpenAPI，它确实是好工具，但它太细粒度了，只能描述字段、参数，不能表达 AI 应用里的“高层语义结构”，比如工具、资源、提示词等。MCP 关注的是“应用层”的抽象问题，也就是“AI 应用要如何定义、暴露、组合功能”。还有个大区别：MCP 是有状态（stateful）协议。我们相信未来 AI 应用一定越来越有状态，现在还可以勉强无状态，但等到视频、音频、多轮推理等加入，保持上下文状态将非常关键。所以 MCP 从一开始就设计了状态管理能力，既支持简单用法，也能应对复杂交互。我们不认为 MCP 和 OpenAPI 是对立的，更像是互补工具：- MCP：适合描述 AI 如何工作、如何调用外部能力、如何组织上下文
其实已经有人做了 OpenAPI 与 MCP 的桥接工具：- 有工具可将 OpenAPI 转为 MCP Server；
- 也可将 MCP Server 转为 OpenAPI 接口供系统调用。
它们不是非此即彼，很多场景下可以互为补充、互相适配。
13🧑💻 如何从零构建一个 MCP Server？其实 MCP 真正厉害的地方，不是连接 Cloud Desktop 的那些炫技演示，而是你们发布的那些参考 Server 实现，真的让人能马上动手上手做。如果我是开发者，想要从零开始构建一个 MCP Server，应该怎么起步？我这边有几个建议。首先最重要的是：先别想太复杂，直接从一个简单的场景开始。MCP 的美妙之处在于——你可以用非常少的代码就跑起来一个最小可用的 Server，模型本身会帮你补很多细节。你只需要选一个你最熟悉的编程语言和对应的 SDK，写一个 MCP 工具（Tool），让模型能调用你最在意的那个功能，哪怕只是调用天气 API 或读取本地文本，都可以直接感受到 MCP 的魔力。而且你甚至不需要把 Server 做得完美，你只要写一个描述，大概告诉模型这个工具是干什么的，模型就能理解并用好它。一旦你把 MCP Server 接上 Cursor、Claude 等客户端，就能看到模型开始用你写的工具做事，那种感觉真的非常魔幻、非常有成就感。“我还可以加点啥？”“我能不能接一个我自己的数据库当 Resource？”当你有了第一个 MCP Server 原型之后，自然就会想往下拓展：你可以从 10 行代码开始，构建一个拥有完整交互能力的 AI 应用。我特别喜欢的方式是——让 AI 帮我写 MCP Server。我们测试过很多次，只要把 SDK 的代码复制给模型，并对它说：“现在你知道 MCP 是怎么工作的了，帮我写一个 Server，比如能抓天气，或者读本地 CSV。”大多数时候模型能写出能直接运行的代码。你可能要调试一下，但基本结构都通了，效率非常高。我们的目标是：几十行代码就能跑起来，不论是 Python、JavaScript、Rust，甚至其他语言。“把 MCP SDK 丢给模型，它就能帮你写工具。”哪怕你换语言、换场景，它也能理解协议结构，写出可用代码。就算某种语言没有现成的 MCP SDK，你也可以让模型即兴写一个 MVP 出来。只需把协议结构和现有 SDK 示例给模型，它就能在你想用的语言（比如 Haskell）写出一个可运行版本。模型写 SDK 对于快速原型和实验来说完全可行。14⚡ MCP Server Builder Agent 的出现我们最近在 AGI House 办了一场以“个人智能体”为主题的 Hackathon。其中有个项目特别酷：开发者做了一个 MCP Server Builder Agent，可以粘贴一个 API 地址，自动为你生成对应的 MCP Server！这几乎是“AI 帮你写 MCP Server 的 Agent”，把原本复杂的开发流程变成了一键部署的体验。你们觉得，未来 MCP Server 会不会大多数只是 API 包装器？还是说你们希望看到更多原生为 MCP 打造的新体验？一方面，很多人会把 MCP Server 当作“连接器”，接已有的数据或 API，让模型能用就好。这种方式高效、实用。另一方面，也越来越多有想象力的 Server 出现，它们不是包装已有服务，而是自己就是“能力提供者”。- 一个 “记忆” MCP Server，让模型能跨对话记住内容；
- 一个 “顺序思维（Sequential Thinking）” Server，帮助模型逐步拆解问题、进行有序推理。
这些 Server 不依赖 API 或数据库，而是改变模型思考方式本身。这让我们意识到：MCP 不只是接世界的工具，它也可以成为提升模型智能的载体。所以 MCP Server 不一定要“接东西”，它也可以什么都不接，只要能提供“结构化思维流程”或“策略提示”，就能创造价值。即便你想做“完全原创逻辑”的 Server，也可以让大模型帮你写。只要你表达清楚自己的想法，模型就能写出代码骨架、设计接口逻辑，甚至想出交互方式。比如我想做一个 MCP Server，每天早上总结我关注的 Subreddit 内容。模型可以帮我写采集器，抓内容后总结，再通过 MCP 接口暴露出来。整个流程不依赖任何外部平台，但能构建出一个真实可用的 AI 工具。MCP 不再只是“插件整合器”，它将变成构建真正 AI 工作流的核心平台。生态尚未成熟，客户端与服务端都在等对方“先走一步”。开发者说：“我想做高级 Server，但客户端还不支持。”客户端说：“我们没看到 Server 用到这些能力。”
MCP 的“组合性”到底意味着什么？Server 能不能互相组合，甚至组成一个“超级 MCP 应用”？比如我做一个汇总 Reddit 的 Server，它可能依赖一个“爬 Reddit”的 Server，加上一个“总结内容”的 Server……这是个非常棒的问题，我们在设计之初就考虑到了这个场景。- 另一种是 既是 Server 又是 Client，它自己也会调用别的 Server。
这样你就可以让一个 Server 编排其他 Server 的功能，它就像个“超级 Agent”，能拼接多个模块完成复杂任务。一旦你有了“Server 也是 Client”的结构，你就能构建出一个 MCP Server 网络，就像链条一样串起来。你甚至可以构建一个 DAG（有向无环图）结构，每个节点代表一个能力，系统协同执行任务。是的，我们在 MCP 规范中特意保留了递归调用的能力。我们都允许 Server 嵌套调用其它 Server。这样就能构建由多个子能力组成的“复合应用”，每个部分有清晰边界，却又能协同工作。更进一步，你甚至可以让 Server 在运行时“感知当前有哪些 MCP Server 可用”，并动态选择、连接、适配——整个系统就像一个智能体网络，高度灵活、模块化运行。当然，目前 SDK 层面还没有全部补齐这类组合调用的便利性支持。我们计划在后续更新中提供相关工具，让大家更方便构建“双身份 MCP Server”（即既是服务提供方又是调用方）。听起来 MCP Server 既能服务、又能调用，还能决策……- 一种方向：MCP 拓展特性，成为 Agent 的理想表示；
我们也在思考协议的边界：哪些功能该 MCP 管，哪些交给上层 Agent Runtime？你们的态度让我想到“Guard Box（守护盒子）”——我还是觉得 MCP 天然就是 Agent 的底层协议。它支持双向通信、Server 也是 Client、支持嵌套调用……宁可先保守一点，确保连接层做得好， 再决定是否扩展能力边界。一个 MCP 实现能支持多少 Server？Claude 在发布百万上下文时说支持 250 个工具，没有唯一答案，取决于模型种类、工具命名、描述清晰度等。很多系统会用小模型筛选最相关工具子集，再交给主模型。甚至可以通过 MCP Proxy Server 实现动态过滤与调用编排。目前 Claude 在支持几百个工具时表现仍然稳定。比如 GitHub 和 GitLab 的 MCP Server 提供类似功能，就很容易混淆。就算工具是模型触发的，你也能前置筛选、限制权限、改变表现形式。19🌀 Tool工具 vs Resource资源的再辨析有时候工具（Tool）和资源（Resource）界限模糊。资源还有个关键点是：每个 resource 都有 URI。它变成一种“知识的超链接”，模型看到 URI 就能通过 MCP Server 获取内容。在 Zed 编辑器中，我们实现了一个 Prompt Library，这些 prompt 来自 MCP Server 提供的资源。很多现有功能其实可以外部化为 MCP Server：以前在 IDE 里点击“附件”，是写死的资源列表；现在可以动态通过 MCP Server 提供，不改逻辑也能扩展。20✨ Cursor 的“@”功能是 MCP Resource 的范例这让我想到 Cursor 的 “@” 功能！输入框打个 @，就能弹出工具或上下文——这和你们的 MCP Resource 模型一模一样！你们把这种功能抽象成协议，现在不止 Cursor，谁都能用！你们在 Mahesh 的 Workshop 展示了一张图，非常清晰地梳理了 MCP 各元素的关系。我建议你们把它放官网首页！它能让人一眼理解 MCP 的组成。我一贯坚持 DevRel 写文档要开头就画“全局地图”。过去很多人尝试做 “Prompt GitHub” 或 “Prompt 管理平台”，但发展都不理想。我们希望 MCP 提供一种更实用的方式：Prompt 可共享、模块化、动态调用。最近看到 Humanloop 推出 PromptFile 格式，尝试标准化 prompt 分享。但我更看重 MCP 提供的“动态性”，尤其是多步提示（multi-step prompting）能力。Prompt 不是单轮输入，而是动态、有逻辑递进、结构化的引导。比如 Google Maps MCP Server，字段写死了，我不能指定返回内容，这真的很烦！我们在设计 MCP 时，故意不强制使用结构化 schema。让返回内容可以直接进入 LLM 上下文，由模型自己理解处理。就像 USB-C，把“文件”插进去，操作系统自己处理。比如 API 返回的数据很乱，那些“脏活累活”还是由 MCP Server 来做。其实我们自己写的参考 Server，很多是 Claude 写的！这说明我们写 MCP Server 时，思维还是传统 API 模式。23💡 MCP 的服务端实现（Server Implementation）那我们现在可以进入下一个话题，来聊聊 MCP 的服务端实现（server implementatio）。我们可以先从一些你们在开源仓库里发布的“特殊 server”讲起，比如：- Sequential Thinking（顺序思维）
我觉得这些都很有意思，它们不是传统那种“包装 API 的 server”，而是直接赋予模型新能力的模块。这些 server 的设计理念，我认为对社区开发者特别有启发意义！其实这些 server，大部分都诞生于我们公司一次内部 Hackathon。当时 MCP 刚刚搭建起来，很多同事看到之后都非常兴奋，开始用它去实现自己早就想做、但没法做的功能。过去大家想让 Claude “记住某些事”，总得等我们内建支持。但有了 MCP，任何人都能写一个记忆模块，插上就用！但它能立刻赋予模型“跨会话记忆”的能力，实用性非常强。开发者可以用 MCP 快速打造模型的新技能，几乎零门槛。我还特别喜欢你们的另一个 server——File System（文件系统）服务。它给 Claude 增加了一个超强能力：直接编辑本地文件。这个 server 就是朝那个方向迈出的非常实用的一步。这个 File System server，其实是我个人非常喜欢的一个项目。当时我在做一个小游戏的 side project，特别希望 Claude 能帮我调试、修改本地代码。那时候我们已经有 artifacts（模型输出产物）了，但模型却没法直接操作我的本地文件系统，这让我很困扰。于是我就用 MCP 做了这个 server，效果立竿见影！对我来说，这个 server 完全体现了 MCP 的精神：还有一个我很喜欢的 server 是 Sequential Thinking（顺序思维）。它能让模型像人一样，一步一步地展开复杂的推理过程，相当于在模型“脑子里”装了个流程图引擎。是的，Sequential Thinking server 的一个功能就是：当模型需要“更多空间”去思考和书写，它就能帮助模型展开结构化的推理流程。对了，我注意到你们最近在工程博客里发布了一个叫 Think Tool 的新功能。社区里有些人好奇：这个和 Sequential Thinking server 有什么关系吗？据我所知，Sequential Thinking 和 Think Tool 是两个完全独立的项目，没有直接的团队重合。这说明大家都在探索如何让模型“更像在思考”而不是“单轮反应”。你可以用不同的 Server，赋予模型不同的“思维风格”。开发者可以按需组合，打造最适合自己应用的“思维引擎”。我认为我们不会出现一种“统一标准”的模型思维方式，“让模型的思考方式因场景而异，根据具体应用需求灵活调整。”随着模型越来越强大，MCP 能帮我们更好地引导它们的能力，也让开发者能根据自己的目标，搭建出真正有意义的交互方式。我认为，随着时间推移、社区发展，MCP 的价值只会越来越大。能真正帮助模型实现与外部世界的连接，成为 AI 应用生态的基础设施。它将走进真实的生产环境，成为 AI 实际部署的重要基石。我们会看到很多真正落地的产品，通过 MCP 与模型对接，这种开放协作的模式，正是推动整个 AI 生态繁荣的核心力量。
帮助我们在可管理的范围内，放心地把 AI 引入实际场景中。你可以决定模型可以接触哪些资源、调用哪些工具、访问哪些数据，是的，这是我们在设计 MCP 时非常核心的一个原则：但我们在协议设计上，其实做了很多工作，来确保它也足够安全、结构清晰。我们希望它既能支持各种灵活玩法，又不会在实际部署中失控或变得混乱。然后才去设计协议的各个部分，而不是反过来从理论出发。所以 MCP 的各个组件和原语，都跟最终用户体验息息相关。TypeScript、Python，还有为了 Zed 的集成使用了 Rust。确实，除了设计协议本身，我们还花了大量时间在 SDK 上，包括客户端、服务器端的实现，都是为了确保它们能可靠通信、真正跑通。还有一点就是，我们还专门开发了一个叫 Local MCP 的东西，它允许你通过本地子进程的方式启动 MCP Server。我们在设计 MCP 的过程中，其实也借鉴了 LSP（语言服务器协议）的一些经验，我们认真分析了 LSP 的设计取舍，并思考哪些地方我们可以做得更灵活、更好用。比如说，LSP 在某些地方采用了比较独特的 JSON-RPC 实现方式，我们研究过，也决定在 MCP 中不完全照搬，而是重新设计。在哪些地方真正存在痛点？在哪些方面我们可以做出创新？全新的“原语”设计，这些原语背后，是对 AI 应用交互模式的全新理解。我们不只是思考它们“语义”上的不同，更重要的是——它们如何在应用中呈现出来（manifest）？所以在 MCP 里，我们一开始就定义了三种核心原语：- 🛠️ Tools（工具）
- 📚 Resources（资源）
- ⚡ Prompts（提示词）
之后我们又新增了一些类型，但这三种是我们最早设定、最基础的组成部分。也就是“function calling”，作用是让模型主动调用外部功能或 API。这是目前最主流的用法。你可以把它理解为一种“宏”，快速插入结构化提示内容。其实现在 MCP 的使用中，绝大多数人还是主要在用 Tool（工具）这一种原语，但我真的希望大家能多多使用 Prompts 和 Resources。做一个 MCP Server，从 Sentry 抓取崩溃信息，这样用户在对话前就能主动交出调试上下文，非常直观好用。你可以暴露文档、数据库内容，让 MCP 客户端索引，就是刻意让它不依赖模型自动调用，而是由应用层控制的。因为现实中你提供给模型的内容往往远超上下文窗口的承载能力，每一个 Resource 在 MCP 中都带有唯一 URI 标识符，不仅可以用作上下文输入，还能作为通用 Transformer 输入源。用户只需粘贴一个 URI，客户端即可识别、解析、注入上下文。Zed 编辑器内置的 prompt 库，就是用 MCP Resource 实现的。Zed 启动时通过 MCP Server 拉取默认 Prompts，以资源形式填充进用户的 prompt 库，非常方便。你可以把已有应用里的功能模块“协议化”，变成独立的 MCP Server，比如许多 IDE 中的“附件菜单”或“片段插入”，它们都可以被建模成 Resource，成为标准化能力对外开放。
我第一次看到你们在 Cloud Desktop 里用 MCP 加了个 “@” 符号，我立刻反应过来 —— 这不就是 Cursor 编辑器里的同一个交互方式嘛！你们做的事情，其实就是把这些现有的 UI 组件和交互，我们甚至还画过一张图，专门总结 MCP 里的各个原语之间的关系。我们也觉得那张图应该直接放到官方文档首页上，真的非常直观清晰！对我来说，作为一个开发者关系从业者，我特别看重这种“概念地图”。我希望在介绍 MCP 的时候，能有一张总览图告诉大家：“这是你必须理解的几个核心概念，接下来我们就来一一拆解。”我记得在 ChatGPT 和 Claude 刚出现的早期，大家特别热衷搞“Prompt 管理器”或“Prompt GitHub 库”。现在有了 MCP，我觉得你们的设计真的打开了新的可能性，尤其是你们支持动态化、多步提示、交互式提示这些能力。我注意到你们还支持多步提示（multi-step prompting），当时我就想：“哇，这群人真的懂模型是怎么工作的！”通过多轮引导甚至“越狱”技巧，可以显著提高模型表现，我在看一些 MCP Server 的实现时注意到：很多时候是由服务器开发者来决定工具调用最终返回哪些数据。比如 Google Maps 的例子，Server 会决定返回哪些字段，而用户是没办法自定义这些内容的，这让我联想到传统 SDK 的一个痛点。在 MCP 中，用户应该有多大权限介入工具调用的返回数据？这个问题我们其实思考过，而且在 MCP 中我们做了一个刻意的设计选择：目前为止，MCP 的 Tool Result（工具调用结果）并不是结构化的 JSON 数据，也没有绑定特定的 Schema。相反，我们让它返回的是纯文本、图像或其他“可直接喂给模型的内容”，与其试图对输出做过度加工，不如直接把原始数据交给 LLM。而且随着模型能力提升，这种方式的扩展性也会更强，不会被格式限制死。所以以 Google Maps 为例，理想的工具调用结果应该是：Server 直接把原始 API 返回的内容原样传给模型，这样一来，模型可以自主选择使用哪些字段，我们也能少踩些坑。我觉得你刚刚说的这点，完全呼应了你们把 MCP 比作“AI 的 USB-C 接口”这个比喻。就像 USB-C 不去改变文件内容，只是作为传输通道，MCP 也只是把数据“搬”给模型，不去干涉它怎么理解。有些 API 返回的数据可能会有奇怪的编码格式，或者格式非常混乱，这时候 MCP Server 还是需要做一些基础清洗，你要怎么决定：哪些地方该清洗、哪些地方应该交给模型处理？只处理那些严重影响理解或兼容性的问题，其余的尽量保留原始数据。
28🤖 MCP 示例 Server 是 Claude 写的？顺便一提，有些 MCP 示例 Server……呃，我得实话实说——可能是因为它是由一位“AI 开发者”生成的，哈哈。现在很多人构建 MCP Server 的方式，仍然是延续传统的软件工程习惯。给大语言模型（LLM）构建系统，其实需要“重新学习”设计方式。信任模型的能力，把工具变成它的“帮手”，而不是“命令它做什么”的指令集。可能不再是模型本身的能力，而是它能否高效连接外部世界。比如能不能读取外部数据库、调用真实 API、执行状态更新，当模型越来越强，大家自然希望它能真正动起来，连通世界。让模型具备“读取数据”和“执行动作”的能力，且过程安全、受控、可组合。
29🔍 MCP vs. OpenAPI：谁更懂模型？我一直觉得，很多 API 的字段像 "formatted_address" 这种就没必要存在。模型本身就有足够能力把原始地址解析成你想要的格式啊！我知道接下来 Alessio 可能要聊“Server 端实现”那块，系统性地总结一下 MCP 和 OpenAPI 的差异。这也是大家最关心的问题之一，我们今天聊了很多相关细节，我希望你们能给出一个“权威的、可引用的”比较视角。但我们认为它对于大语言模型（LLM）来说还是太细颗粒度了。它没办法表达一些更高层次的、面向 AI 应用的抽象概念。我们更倾向于认为，LLM 与 OpenAPI 的契合度不高，“这是一个 REST API 的说明书，照着调用就行。”而 MCP 想做的是提供面向 AI 应用的抽象原语，比如工具（Tools）、资源（Resources）、提示（Prompts）等等，还有一个关键区别是：MCP 被有意设计成是“有状态的（stateful）”。我们相信，AI 应用和 AI 交互未来一定会变得越来越有状态，而 OpenAPI 那种“无状态”的接口设计，只是当下的一个过渡阶段。尤其当我们进入多模态时代，比如模型要处理音频、视频、图片等，就刻意保留了状态性的表达能力，因为这会成为未来交互的核心。随着模型越来越强，大家自然会希望它能维持上下文、管理会话历史、跟踪长期目标，其实我们并不觉得 MCP 和 OpenAPI 是对立的，它们是可以互补的。可以把 OpenAPI 规范转换成 MCP Server，这样原有资源也能接入新生态。也完全可以把 MCP Server 映射为 OpenAPI 接口，反过来也行。30⚙️ 构建自己的 MCP Server，其实没你想的难 但很少人真的深入去看：如何构建一个 MCP Server。首先，MCP 非常容易上手，你可以从一个非常简单的 Server 开始，我们已经有多种 SDK 支持，只需半小时就能跑通一个 Demo！构建一个 MCP 工具，让模型来调用你关心的东西。你只需要把它接到标准输出（stdout），传输协议就是这样启动的。让开发者能迅速体验到模型控制真实世界的那种兴奋感。“哦，我可以继续加更多工具，我可以引入 Resources，我可以加 Prompts。”“我该怎么做评估（eval）？我的提示词还能怎么优化？”我自己其实也很喜欢用大模型来帮我写 MCP Server。在开发早期阶段，我们就发现你只要把 SDK 的代码扔进上下文窗口，然后告诉模型：“我想做一个能干 XX 的 Server”，它往往能一把写出来！所以你只需要写个 一两百行代码，用你喜欢的语言，基本就能跑起来！你也可以把协议的那一部分规范交给模型，再配上一个已有 SDK 的示例，它也能帮你生成一个简单的 SDK 子集，足够让你跑通 MCP 的核心功能。但想跑通 Tool Call、哪怕是用 Haskell 都不难。
我们之前在 AGI House 联合举办了一场 Hackathon，主题是“个人代理”。他做了一个 MCP Server 构建器 Agent，你只需要把一个 API 规范（API spec）的 URL 贴进去，它就会自动帮你生成一个对应的 MCP Server！你们觉得现在的大多数 MCP Server 是不是其实只是对已有 API 的简单包装？未来我们会不会看到一些完全全新构想、MCP 原生的体验？有些人就是想把已有的数据或服务，通过 MCP 接到自己常用的 AI 应用里，这种适配器式”的 MCP Server 绝对有市场。但我们也能预见，未来会有越来越多原生的 MCP Server出现，它们将提供一些你之前根本没法实现的、非常独特的新能力。Memory（记忆）Server、Sequential Thinking（顺序思考）Server， 它们并没有连接任何外部 API—— 它们本身就是在增强模型的推理能力或交互方式， 更像是一种“能力插件”，真正赋予模型新的技能。你可以理解这些 MCP Server 是在教模型“怎么思考”，而不是“去哪里找数据”。它们也一样是非常有价值的 Server，因为它们扩展了模型的思维方式。你完全可以构建一个 MCP Server，让模型回答三次，再自动挑选最好的结果。你就能打造出一种更可靠、更有层次的交互结构，而这正是 MCP 能帮你实现的。32💾 文件系统 Server：模型也能“动手操作”那我们接下来想更深入聊聊你们在 MCP 发布时内置的一些核心 Server，比如记忆模块（Memory）、顺序思考（Sequential Thinking）这些特别的 Server 设计思路。比如说你们内置的 文件系统 MCP Server，我就觉得特别有意思。它能让模型直接访问本地文件，甚至实现 编辑文件内容！因为以前要实现类似功能门槛很高，而你们直接把它开源了！我在用 Cloud Desktop 搞副业游戏项目的时候，一旦 Claude 能“动手”处理你电脑上的代码或文件，对我来说，这个文件系统 Server非常具有象征意义，我们当初开始做 MCP，就是因为像我和 Justin 这样的人
是你们那个叫Sequential Thinking（顺序思考）的 MCP Server。它可以让模型有一种“分步写作”或“推理空间扩展”的感觉，前段时间，Anthropic 工程团队不是刚发了一个叫Think Tool的工具嘛，不过我猜，这两个工具可能是不同团队各自独立开发的。嗯，就我所知，这两个工具之间没有直接的渊源或继承关系。而且这些都可以作为独立的 MCP Server 插件来使用。你甚至可以在一个应用中，根据需要组合不同的思维方式。我们其实并不认为未来会出现那种“唯一最完美的思维方式”——也就是说，不存在一个通用 prompt 能解决所有问题。让不同的应用可以选择最适合自己上下文和用户的思维路径。我还想补充一点——其实有很多 MCP Server，尤其是早期的那些，它们的意义在于：当模型还不具备某些能力时，先用 MCP 填补空白。比如我们通过 Server 引入某种思考方式、流程、结构，在未来模型进化之后，这些能力可能会变成“原生”的，你可以用 MCP Server 让它 尝试回答三次，然后自动选择表现最好的那一个。哪怕模型本身还不具备“自我反思”能力，也能先模拟出来。让它能通过 MCP 实现某种形式的自我审视与多轮尝试。它不只是简单地调用一次模型，而是让整个思考过程变得更有深度，
这些想法真的特别鼓舞人心，感觉能开启一整类全新的 AI 应用方式。是关于文件系统 Server 或 Sequential Thinking Server 的幕后开发过程？其实这些 Server 没有那么多“宏大的历史”，很多都是在我们公司内部的一次Hackathon（黑客马拉松）里萌芽的。于是就动手做了一些实验性的 Server，像是Memory、Sequential Thinking，根本不需要接触 Anthropic 内部的私有代码库。也推动了 MCP Server 生态的多样化发展。也有刻意挑选一些功能跨度比较大的 Server来展示。目的就是让大家看到：MCP 不是只适用于某一种类型的扩展，它可以覆盖从代码编辑、文件操作，到推理流程和记忆管理等等多种场景。很多开发者看到之后就直接开始复制、魔改、拓展，快速进入实战。比如你们发布的那个 File System Server，“哇，现在我用 Claude 就能直接编辑本地文件了？”我注意到已经有人把这个 Server 当成核心组件，它就是围绕文件系统和编辑功能构建起来的，很多人都对它特别感兴趣。其实这个 File System Server 对我来说很有个人情感。当时我在做一个独立游戏的 side project，然后我特别希望 Claude 能够参与开发流程、帮我调试文件内容。“如果 Claude 能访问我的本地文件，那该多酷啊！”File System Server 的想法就是这么来的。有了这个 Server，Claude 就能真正看见我的项目结构、代码文件、目录层级，因为以前模型总是“瞎猜”，现在它终于能“看见并理解”了。它真的变成了我开发过程中的一部分伙伴，而不只是个聊天工具。其实这个 File System Server，某种意义上也算是MCP 的“精神起点”。我们有各种强大的工具，但它们彼此之间完全无法连接。36🔁 Sequential Thinking 与模块化思维方式那我们再聊聊另一个我特别喜欢的 Server —— Sequential Thinking（顺序思考）Server。但你们竟然只用一个 prompt 就搭建出这种“分步骤思考”的效果，实在太厉害了。而且最近你们 Anthropic 又发布了一个新功能，叫 Think Tool（思考工具），“诶，那这个和 Sequential Thinking Server 有啥不同？”乍一看，它们好像都是为了让模型“更认真思考”嘛，对吧？我们内部也没有说什么“Think Tool 就是对 Sequential Thinking 的延续”这种说法。它允许你通过不同的 Server，赋予模型不同的“思维方式”。不管你是想要一步步推理、快速回答、查找信息还是模仿风格，你都可以为模型加载一个合适的 MCP Server，不仅仅是“调用某个 API”，而是把不同能力模块化、组合化地接入模型。你可以像拼乐高一样，用不同的 MCP Server 搭出属于你自己的 AI 能力体系。现在我们用 MCP Server 来补足模型的不足，比如说，你可以用 MCP Server 搭建一个“三选一策略”：
37❓一个 MCP Server 作为客户端调用其他 Server，算 agent 吗？如果一个 MCP Server 自己也作为 MCP 客户端，去调用别的 Server，这个界限该怎么划分？你们觉得这样算 agent 吗？如果只是一个 MCP Server 顺带调用其他 Server，但如果它内部有自己的计划逻辑、推理机制和多轮控制流，其实从更宏观的角度看，MCP 和 agent 之间确实有很强的关联。你可以把 MCP 当作是构建 agent 的一种方式，或者是 agent 之间彼此组合与通信的基础协议。MCP 要不要朝 agent 的方向进一步发展？还是说我们应该保持它的“AI 应用通信协议”定位，不去承担太多 agent 层职责？现在 MCP 已经具备了很多 “类 agent” 的能力——比如双向通信、Server 也可以是 Client、嵌套组合调用等。但我们还是很小心，不想把 MCP 变成一个“万事通协议”，38🔌 一个客户端能连接多少个 MCP Server？一个 MCP 客户端最多可以同时连接多少个 Server？这是不是也会影响模型的调用效果？比如工具冲突、混淆等问题？比如，如果你提供了几十个工具，但它们名字和描述都差不多，确实，有些场景特别容易出错，比如你同时加载了 GitHub 和 GitLab 的 Server，它们提供的工具非常相似，模型可能会搞不清楚到底该用哪个。如果是那种需要用户高度自主操作的 IDE 或聊天应用，听起来这和你们刚才讲的“资源”和“工具”的使用逻辑挺像的，有些时候是模型自己去调用——这个机制本身就很灵活。客户端（也就是应用）始终拥有完全的控制权，必要时可以对 MCP 提供的内容进行筛选、重写或干预。有时候，MCP Server 的开发者自己也会希望对工具或资源进行逻辑分组，这样一来，客户端在使用时也可以更好地组织和展示这些功能。这种分组应该在客户端层面实现，也就是说，每个功能拆成独立的 MCP Server，然后由客户端来组合使用。这样更灵活，也更符合 MCP 的“组合式”设计理念。那你们有没有想过搞一个“标准库”级别的 MCP Server 集合？比如像 Python 的标准库一样，有一套大家都默认会用的官方组件。我们其实不太想做那种“由上而下”规定大家用什么的事，我们更倾向于让生态自然生长，让大家自由构建自己喜欢的 Server。采用一种“市集”式的方式，然后让最实用、最受欢迎的 Server 自然被大家采纳。现在有很多 MCP Server 是由不同公司、不同社区开发的。- Microsoft 和 JetBrains 也都在构建自己的实现
你会发现其实已经有很多不是 Anthropic 员工的人拥有提交权限了。- Pydantic 社区成员维护 Python SDK
- Microsoft 也加入了 .NET 的部分
41🎯 MCP 的愿望清单：你会是下一个构建者吗？听起来 MCP 已经是一个真正意义上的多方共建的大项目了，有没有什么你们特别想让别人去做的 MCP Server？我以前是个 EVE Online 的老玩家，我特别想要一个 MCP Server，每天早上可以自动总结我最喜欢的 subreddit 或游戏社区的最新动态。其实这类 Server 并不难做，真正的难点是现在但我真的非常希望有人能先把 sampling 客户端做出来，包括 sampling、资源组合、链式调用……都在设想之中。所以我真的很希望未来有一天 Claude 能通过 MCP，42🕹️ Claude 玩宝可梦？MCP 的下一个奇迹！哈哈，那你至少已经能让 Claude 帮你写 3D Shader 了吧？我觉得你这个“AI 玩游戏”的愿景，听起来现在已经不再遥不可及了。我们请到了 David Hershey 一起参与，非常感谢你们邀请我们来做客，这次访谈真的很有意思。
粤ICP备17114055号