The Creators of Model Context Protocol
01:19:56 Share

欢迎回来。MCP、MCP、MCP。在纽约峰会之后，我们撰写了一篇广受欢迎的文章，解释了为什么我们认为Anthropic的模型上下文协议（MCP）似乎赢得了2023年至2025年的Agent开放标准之争。现在看来，每个人都加入了MCP的行列，从Cursor和Windsurf到OpenAI再到Google DeepMind。

我们的AI工程师社区渴望了解更多信息，因此我们正在做两件事来探索MCP现象。首先，今天的嘉宾Justin Spahr-Sommers和David Soria-Para是模型上下文协议的共同创建者，他们非常友好地与我们进行了他们有史以来的第一次播客，讨论了MCP的起源、挑战和未来，并欣然回答了我们来自潜在空间社区的所有问题。

其次，SWIX宣布将在2025年6月3日至5日在旧金山举行的AI工程师世界博览会上设立一个专门的MCP专场，MCP核心团队、主要贡献者和建设者将在此会面。加入我们，申请发言或赞助ai.engineer。请注意并小心。

大家好，欢迎回到潜在空间。我是Alessio，Decibel的合伙人和首席技术官，我与我的联合主持人Swix（Small AI的创始人）一起。嘿，早上好。今天我们的录制是在远程进行的，我想，与来自伦敦的Anthropic的David和Justin一起。欢迎。嘿，很高兴来到这里。欢迎。

你们因为MCP而掀起了一阵热潮，我很高兴能邀请你们来。感谢你们抽出时间。什么是MCP？让我们从一个简洁的词语开始。

从马嘴里得到的定义。然后我们将深入探讨其起源故事。但让我们从一开始就开门见山。什么是MCP？是的，当然。因此，模型上下文协议，简称MCP，基本上是我们设计用来帮助AI应用程序扩展自身或与任何生态系统或其他内容集成的东西。

插件，基本上。术语略有不同。我们使用这种客户端-服务器术语，我们可以讨论为什么是这样以及它从哪里来。但归根结底，它实际上是扩展和增强AI应用程序的功能。David，你有什么补充吗？是的，我认为这是一个很好的描述。我认为人们有很多不同的解释方式。但核心是……

我认为Justin所说的扩展AI应用程序正是它的目的。我认为这里我想强调的一个有趣之处在于，它关注的是AI应用程序，而不是模型本身。这是一个常见的误解，我们稍后可以讨论。是的。我们使用过并喜欢上的另一个版本是，MCP有点像AI应用程序的USB-C端口，它旨在成为连接整个生态系统的通用连接器。

是的，一个有趣的特性是，就像你说的那样，客户端和服务器。而且它是双向的，对吧？就像USB-C是双向的一样，这可能非常有趣。是的，让我们来谈谈它的起源故事。许多人都尝试过制定关于代理的标准。许多人都尝试过构建开源项目。我认为总的来说，我的感觉是Anthropic正在

努力争取开发者，而其他实验室却没有这样做。因此，我也很好奇是否有任何外部影响，或者只是你们两个人在一个房间里即兴创作？它实际上主要就像我们两个人在一个房间里即兴创作一样。所以这不是一个大策略的一部分。如果你稍微回溯一下时间，回到2024年7月，

我在Anthropic工作了大约三个月或两个月。我主要从事内部开发者工具的工作，这是我多年来一直在做的工作。

作为其中的一部分，我认为有一项努力是，我该如何赋能更多Anthropic的员工来使用，你知道，与我们拥有的模型进行深度集成，因为我们已经看到了这些，它有多好，它在未来会变得多么令人惊叹。当然，你知道，尽可能多地试用你自己的模型。作为其中的一部分，

从我的开发工具背景来看，我很快对这样的想法感到沮丧，即一方面，我有云桌面，这是一个带有工件的令人惊叹的工具，我真的很喜欢，但它非常局限于确切的功能集。而且无法扩展它。另一方面，我喜欢在IDE中工作。

它可以很好地作用于文件系统和其他许多东西，但它们没有工件或类似的东西。所以我一直在做的就是来回复制云桌面和IDE之间的内容。这很快让我非常沮丧。部分原因不是，我该如何解决这个问题？我们需要什么？回到我的开发人员关注点，我认真考虑过，

好吧，我知道如何构建所有这些集成，但我需要做什么才能让这些应用程序让我做到这一点？所以你很快就会看到这是一个明显的M乘N问题。就像你有多个应用程序和多个你想构建的集成一样，还有什么比使用协议更好的方法来解决这个问题呢？与此同时，我实际上正在内部从事一项与LSP相关的项目，但没有进展。但是你把

这些东西放在某人的大脑里，让他们等上几周。由此产生的想法是，让我们构建一些协议。所以回到那个小房间，那实际上就是我去找Justin，说，我认为我们应该构建这样的东西。

这是一个好主意。幸运的是，Justin对这个想法很感兴趣，并从此与我一起构建它。这就是最初的构想故事。从那时起，我们两个人就一直在构建它，在短短一个半月的时间里构建了协议，构建了第一个集成。Justin做了很多

像云桌面中的第一个集成的繁重工作。我做了很多关于这在IDE中可能是什么样子的第一个概念验证。如果你，我们可以讨论一些你可以在正式发布之前很久就能找到的小细节，如果你在正确的时间查看正确的存储库的话。但就是这样。这就是一些粗略的故事。

时间线是什么？我知道11月25日是正式发布日期。你们是什么时候开始工作的？Justin，我们是什么时候开始工作的？我认为是大约7月份。是的，一旦David提出了这个最初的想法，我就很快兴奋起来，我认为几乎在那次谈话之后我们就开始着手了。然后……

我不知道，可能是一两个月，也许是几个月在构建那些非常没有回报的部分，如果我们说实话的话，因为对于，对于建立像这样的通信协议来说，它有客户端和服务器以及各处的SDK，有很多像，

你必须做的基础工作。所以这是一个相当，那是一个相当缓慢的几个月。但之后，一旦你让一些东西通过那根线进行通信，它就会变得非常令人兴奋，你可以开始构建各种疯狂的东西。我认为这真正达到了高潮。我不记得确切的时间是什么时候，可能是

大约在发布前一个月，有一个内部黑客马拉松，一些人对MCP非常兴奋，并开始构建各种疯狂的应用程序。我认为其中最酷的一个是像一个可以控制3D打印机的MCP服务器。所以突然之间，人们感受到了这种力量，即云连接到外部世界的一种非常有形的方式。这确实给我们和发布增加了一些动力。

是的。我们将深入探讨技术细节，但我只想在这里总结一下。你提到如果你在正确的地方寻找，你可能会看到一些事情即将发生。我们总是想知道在哪里获得alpha。如何在早期找到MCP？我是一个Zed用户。我喜欢Zed编辑器。IDE上的第一个MCP实现是在Zed中。它是我编写的，在正式发布前一个月半就有了。仅仅是因为我们需要公开地去做，因为它是一个开源项目。

所以它不是，它的名字略有不同，因为我们还没有确定名称，但它在那里。我很乐意多说一点。Anthopic也对带有Zed的模型进行了一些预览，对吧？某种快速编辑模型。我承认，你知道，我是一个Cursor Windsurf用户。我没有尝试过Zed。你的，你知道，无关的或，你知道，非请求的为Zed做的两秒钟的推销是什么？这是一个好问题。我，

这真的取决于你在编辑器中看重什么。对我来说，我甚至不会说我喜欢，我比其他编辑器更喜欢Z。我认为它们在某种程度上是互补的。我喜欢使用Windsurf，我也使用Z。但我认为我对Z的主要推销是低延迟、超级流畅的体验编辑器，以及相当不错的AI集成。

我的意思是，也许，你知道，我认为这对很多人来说就是这样。我认为很多人显然非常依赖VS Code范例及其附带的扩展。好的，我想稍微回顾一下，你知道，你提到的Justin的一些事情，那就是构建MCP。在纸面上，你知道，显然我们只看到最终结果。它似乎受到了LSP的启发。我认为你们两位都承认了这一点。那么要构建多少内容呢？当你说到构建时，是指……

很多代码还是很多设计，因为我觉得它有很多设计，就像你选择JSON RPC一样，你基于LSP多少，你知道，什么是困难的部分？是的，绝对的，我的意思是，我们确实从LSP获得了很大的启发，David比我更有先前的经验，在开发工具方面，所以你知道，我主要从事产品或某种基础设施方面的工作，LSP对我来说是新的，但是作为一个

像，或者从设计原则来看，它确实非常有意义，因为它确实解决了David提到的M乘N问题，即在LSP之前的世界中，你拥有所有这些不同的IDE和编辑器，然后所有这些不同的语言都希望支持或其用户希望它们支持。然后每个人都在构建一次性集成。所以你使用Vim，你可能对像

老实说，我不知道，C语言或类似的东西有非常好的支持。然后你切换到JetBrains，你有了Java支持，但是你无法在Vim中使用优秀的JetBrains Java支持，也无法在JetBrains中使用优秀的C支持，诸如此类。因此，我认为LSP在很大程度上通过创建他们都可以使用的通用语言解决了这个问题。然后，你知道，你可以让一些人专注于真正强大的语言服务器实现，然后IDE开发人员可以真正专注于那一方面，他们都会受益

所以这是我们对MCP的关键收获，就像在AI应用程序和AI应用程序扩展的空间中具有相同的原则和相同的问题一样。但是就具体的细节而言，我的意思是，我们确实使用了JSON RPC，并且采用了这种双向性的想法，但我认为在那之后我们很快走上了不同的道路。我想还有一个来自LSP的原则，我们今天试图坚持，那就是关注功能如何体现。

而不是事物的语义，如果这是有意义的话。David称之为以演示为中心，即基本上思考和提供不同的基元，不是因为它们的语义必然非常不同，而是因为你想让它们在应用程序中以不同的方式显示出来。这是一种关于LSP是如何开发的关键见解。这也是我们试图应用于MCP的东西。但就像我说的那样，从那时起，就像，是的，我们花了很多时间，真的花了很多时间，我们可以单独讨论这一点，就像

思考我们想要在MCP中提供的每个基元以及为什么它们应该不同，例如为什么我们想要拥有所有这些不同的概念。这是一项重要的工作。正如你提到的那样，这是设计工作。但是同样

从一开始，我们就至少有三种不同的语言想要支持。那是TypeScript、Python，然后对于Z集成，它是Rust。所以在这些语言中有一些SDK构建工作，客户端和服务器的混合，以构建出我们可以开始使用的内部生态系统。然后，是的，我想只是试图让一切变得健壮，就像

我不知道，我们对本地MCP的整个概念，你启动子进程之类的东西，让它变得健壮。这也花了一些时间。是的，也许可以补充一点，我认为LSP的推论更进一步。就像我们确实仔细研究了

对LSP的批评，例如LSP没有做好的事情以及人们觉得他们希望有所不同的事情，并且真的认真对待了这一点，看看，你知道，我们希望，你知道，我们应该做得更好。我们对他们非常独特的方法进行了，你知道，像一个冗长的，例如查看JSON RPC，我可能会说，然后我们决定这不是我们所做的。所以有像

这些差异，但它显然非常非常有启发性。因为我认为当你试图构建和关注时，如果你试图构建像MCP这样的东西，你可能会选择你想在其中创新的领域，但你可能会对其他部分的模式匹配LSP感到无聊。所以这个问题允许你在许多你想感到无聊的核心部分感到无聊。像JSON RPC的选择对我们来说非常没有争议，因为它只是，它根本

无关紧要，就像你正在说的酒吧上的实际字节一样。这对我们来说没有任何区别。创新在于你选择的基元和这些类型的东西。所以我们想要做的重点更多。所以有一些先例在那里是好的，基本上。

确实如此。我想双击一下。我的意思是，有很多事情你可以深入探讨。显然我对协议设计充满热情。我想给你们看这个。我的意思是，我认为你们知道，但是，你们已经提到了M乘N问题。我可以在这里分享我的屏幕，任何从事开发工具工作的人都面临过这个问题，你基本上看到了上帝盒子。就像……是的。

所有基础设施工程的基本问题和解决方案是，你让事情走向终点，然后你放上上帝盒子，它们都会变得更好，对吧？所以这里有一个来自Uber的问题，一个来自GraphQL的问题，一个来自我以前在Temporal工作时的问题，这是来自React的问题，我只是很好奇，你知道，你是否在Facebook解决了N乘N问题，就像我一样，听起来David你以此为生，对吧？这只是N乘N的问题。是的，是的，在某种程度上，当然，我

这是一个很好的例子。但我在这类源代码控制系统和这些类型的事情上做了很多这样的工作。所以也有很多这类提示。所以你只需要把它们塞进每个人都可以读取和写入的东西中。你在某个地方构建你的上帝盒子，它就能工作。但是是的，在开发工具中，你是绝对正确的。在开发工具中，这无处不在，对吧？它无处不在。

有趣的是，我认为每个制造上帝盒子的人都面临着同样的问题，这也是你现在的可组合性问题，远程与本地，你知道，有一套非常常见的问题。所以我有点想从如何制作上帝盒子中吸取一个超然的教训。但是，你知道，我们稍后可以讨论开发方面的内容。我想双击一下，再次……

Justin提到的演示，就像功能如何体现，以及你如何说有些事情是相同的，但你只想具体化一些概念，以便它们以不同的方式显示出来。当我查看MCP文档时，我有这种感觉，我想，为什么这两件事需要在其他范例中有所不同？它们基本上是一样的。我认为

很多人认为工具调用是一切的解决方案，对吧？有时你实际上可以将不同类型的工具调用视为不同的东西。有时它们是资源。有时它们实际上是在采取行动。有时它们是其他我不知道的东西。但我只想看看像

一些你精神上归为相邻概念的东西，以及为什么对你来说强调它们很重要？是的，我可以谈谈这个。我认为从根本上说，我们思考的每一个基元，我们首先从应用程序开发人员的角度出发。如果我正在构建一个应用程序，无论是IDE还是调用桌面或某种代理界面，或者无论是什么情况，我想要从集成中接收的不同内容是什么？我认为一旦你采用这种视角，我

很明显，工具调用是必要的，但非常不够。除了将工具直接插入模型之外，你还想做很多其他事情。并且你想有一种方法来区分这些不同的事情。因此，我们开始使用MCP的核心基元，我们后来又添加了一些，但核心基元确实是工具，我们已经讨论过了。它就像直接将工具添加到模型中，或者有时称为函数调用，资源，这基本上是指你可能想要添加的数据或上下文

到上下文，到模型上下文中，这是第一个基元，就像我们决定这可以由应用程序控制一样，也许你想让模型自动搜索并找到相关的资源并将它们带入上下文，但也许你还想让它成为应用程序中的显式UI功能，用户可以在其中像

你知道，通过下拉菜单或回形针菜单或其他任何东西来选择特定内容并对其进行标记。然后这成为他们向LLM发送消息的一部分。这些都是资源的用例。然后是提示，它们故意被设计成用户启动的或用户替换的文本或消息。所以这里的类比是，如果你是一个编辑器，就像一个斜杠命令或类似的东西，或者像一个at命令。

你知道，自动完成类型的东西，就像我有一个宏，我想插入并使用。我们有

通过MCP表达了关于这些事物可能表现出的不同方式的观点。但最终，由应用程序开发人员决定，好的，你得到了以不同方式表达的不同概念。这对应用程序开发人员来说非常有用，因为他们可以为每个概念决定合适的体验。实际上，这也可以成为一个差异化点。就像我们也在考虑，你知道，从应用程序开发人员的角度来看，他们，你知道，应用程序开发人员不想

他们不希望他们的应用程序最终与其他所有AI应用程序相同。所以，他们可以做些什么独特的事情来创建最佳用户体验，即使连接到这个大型开放的集成生态系统？是的。我认为要补充一点，我想提两点。第一点是

有趣的是，虽然现在工具调用显然是95%以上的集成。我希望会有更多客户端使用工具资源，使用提示。在Z中的第一个实现实际上是一个提示实现。它不处理工具。

我们发现这实际上非常有用，因为它允许你做的是，例如，构建一个MCP服务器，它可以从Sentry或任何其他跟踪崩溃的在线平台获取回溯，并让你事先将其拉入上下文窗口。所以这样很好，因为它是一个用户驱动的交互，作为用户，你可以决定何时将其拉入，而不必等待模型来做。所以这是一个很好的方法……

以某种方式设计提示。我认为同样地，你知道，我希望，你知道，今天的更多MCP服务器会将提示作为如何使用它们同时提供的工具的示例。资源位也相当有趣。我希望我们能看到更多在那方面的使用，因为很容易想象，但还没有人真正实现它。一个系统，其中一个MCP服务器公开

你拥有的文档集、你的数据库，无论你想要什么，作为一个资源集。然后一个客户端应用程序将围绕这个构建一个完整的rack索引，对吧？这绝对是我们考虑的应用程序用例，为什么这些是以这种方式公开的，而不是模型驱动的，因为你可能想要比在上下文窗口中实际可用的更多的资源内容。所以我认为，你知道，我希望应用程序，我希望应用程序在接下来的几个月里这样做，更好地使用这些基元，因为我认为这样可以创建更丰富的体验。是的，我完全同意这一点。

我还想补充一点，我会提交我的论文。如果我有的话，我会再回到它。我认为这是一个很好的观点。每个人都只是，你知道，有一个锤子，想对所有东西都进行工具调用。我认为很多人使用工具调用来执行数据库查询。他们不为此使用资源。当涉及到确实具有API接口的东西时，例如，

像数据库一样，你可以使用执行SQL查询的工具，或者应该何时执行该操作或使用数据作为资源？所以，所以我们的，就像我们区分这些的方式是，工具总是意味着由模型启动。这有点像根据模型的判断，它会找到合适的工具并应用它。所以如果，如果那是你作为服务器开发人员想要的交互，那么它就像，好的，这个，你知道，突然之间我给了LLM运行SQL查询的能力，例如，这作为工具是有意义的。

但是资源更灵活，基本上。我认为，说实话，这里的故事今天实际上有点复杂，因为许多客户端还不支持资源。但我认为在一个理想的世界中，所有这些概念都完全实现并且有完整的生态系统支持，你会将资源用于数据库表模式等内容。

作为一种允许用户说，“好的，现在，Claude，我想和你谈谈这个数据库表。它在这里。让我们进行这次对话。”或者你正在使用的特定AI应用程序，可能是像Claude Code这样的代理应用程序，能够代理查找资源并找到你正在谈论的数据库表的正确模式。这两种交互都是可能的。但我认为任何时候你都有这种

你想列出一些实体，然后读取其中的任何一个。这可以建模为资源。资源也总是由URI唯一标识。所以你也可以将它们视为像，你知道，某种通用转换器一样。如果你想支持用户只需插入URI，然后你就能自动弄清楚如何解释它，你可以使用MCP服务器来进行这种解释。

这里一个有趣的旁注，回到Z资源的例子，它有一个提示库，你可以，人们可以与之交互。我们只是公开了一组我们希望每个人都拥有的默认提示。作为该提示库的一部分，我们有一段时间有资源，这样你启动Z，Z就会弹出

从MCP服务器填充提示库，这是一个非常酷的交互。这又是非常具体的，就像双方都需要就URI格式和底层数据格式达成一致。但这是一种很好且有点巧妙的资源应用方式。

还回到那种视角，就像作为应用程序开发人员，我想要什么？我们也把这种思维应用于像应用程序的现有功能，如果你今天采用这种方法，可以想象将其分解成MCP服务器。所以就像任何IDE，你都有一个附件菜单，我认为自然地建模为资源，它只是，你知道，

这些实现已经存在。是的，我认为直接的，就像，你知道，当你为云桌面引入它并且我在那里看到了at符号时，我想，哦，是的，这就是Cursor拥有的。但这是为其他人准备的。而且，你知道，我认为像那样，那是一个非常好的设计目标，因为它已经存在，人们可以非常整齐地映射它。我实际上正在展示Mahesh研讨会中的这张图表，你们大概

已同意。我认为这非常有用，应该放在文档首页。可能真的应该。我认为这是一个好建议。你想为此创建一个PR吗？我喜欢。是的，创建一个PR。我已经为Mahesh的研讨会创建了一个PR，因为，你知道，我知道我已经批准了。是的，谢谢。是的，我的意思是，但你知道，作为一名开发者关系人员，我总是坚持要有地图给人们。这是你必须理解的所有主要内容。

接下来两个小时我们将详细讲解这个。

因此，一张涵盖所有这些内容的图像我认为非常有帮助。我喜欢你对提示的强调。我想说的是，这很有趣，就像，我认为，在chat GPT和Claude的最早期，人们经常会想出，“你真的无法跟随我的屏幕。”在chat GPT和所有这些的早期，很多人开始，你知道，GitHub用于提示，就像我们将做prop管理器库。而且，而且，

我认为这样的东西是有帮助和重要的。我想说的是，我还看到来自human loop的提示文件，我认为这是标准化人们如何共享提示的其他方法。但是，是的，我同意应该在这里有更多的创新。我认为人们可能想要一些动态性，我认为你提供了，你允许的。我喜欢你有多步骤。这是让我觉得，“这些人真的懂了”的主要原因。

我认为你可能已经发表了一些研究，表明实际上，有时为了让模型以正确的方式工作，你必须进行多步骤提示或越狱，才能使其按照你想要的方式运行。所以我认为提示不仅仅是单一的对话。它们有时是一系列对话。是的，我不知道。

当我查看一些服务器实现时，我有一个问题。服务器构建者决定最终返回哪些数据，特别是对于工具调用。例如，谷歌地图的那个，对吧？如果你仔细查看，他们决定返回哪些属性，用户无法

覆盖它，如果缺少一个，这始终是我对SDK的抱怨，当人们构建API包装器SDK，然后他们错过一个可能新的参数，然后我无法使用它。你们怎么看待这个问题？是的，用户应该在多大程度上干预，而不是让服务器设计者完成所有工作？

我认为我们可能要对谷歌地图的那个负责，因为我认为这是我们发布的参考服务器之一。一般来说，特别是对于工具结果，我们实际上已经做出了一个深思熟虑的决定，至少到目前为止，对于工具结果来说，不是像结构化的JSON数据，不匹配模式，而是像你直接传递给LLM的消息，例如文本或图像。所以我想关联的是

你真的应该只返回一堆数据，并相信LLM能够对其进行分类和筛选，并提取它关心的信息，因为这正是它们擅长的。我们真的试图考虑如何充分利用LLM，而不是过度指定，然后最终得到一些随着LLM本身越来越好而无法扩展的东西。

所以，是的，我想在这个示例服务器中应该发生什么，我再次请求欢迎。这将是很棒的。就像如果所有这些结果类型都是从它调用的API直接传递过来的，那么LLM就可以对数据做任何它想做的事情。

是的，对我来说，这就像这个的USB-C部分，你知道，就像，“嘿，这是这个服务器上的文件”，也就是API返回的内容。然后你把它导流过去，而没有在中间做太多事情。

是的，但与此同时，就像你需要对一些部分进行一些工作，因为有时它们有奇怪的，你知道，编码或所有这些不同的东西，也许服务器应该处理。但是，是的，这是一个艰难的，这是一个艰难的设计决策，决定在哪里划清界限。我可能会在这里稍微批评一下AI，并说Claude编写了许多这些示例服务器。一点也不奇怪。但我认为

对不起，我认为这里有一个有趣的观点……

我认为目前人们仍然大多仍然只是将他们正常的软件工程API方法应用于此。我认为我们仍然需要更多地重新学习如何为LLM构建一些东西并信任它们，特别是，你知道，随着它们一年比一年好得多。对。我认为，你知道，两年前，也许这种方法会非常有效。但现在，就像，

只是将数据扔给那个非常擅长处理数据的东西，这是解决这个问题的好方法。我认为只是忘记了20、30、40年的软件工程实践，在某种程度上会有一些影响。如果我可以快速补充一点，只是为MCP提供一个框架，那就是考虑AI发展得多么快。我的意思是，这令人兴奋。这是

我们认为，对模型的下一波能力的最大瓶颈实际上可能是它们与外部世界交互的能力，例如，从外部数据源读取数据或采取有状态的操作。在Anthropic工作，我们绝对关心安全地做到这一点，并采取正确的

控制和对齐措施，以及所有这些。但随着AI变得更好，人们也会想要这样做。这将是能够有效利用AI的关键，就像能够将它们连接到所有这些东西一样。因此，MCP也是对未来以及这一切将走向何方以及这将有多么重要的押注。

是的。是的。我想说任何说格式化_的API属性都应该消失，我们应该从所有这些属性中获取原始数据，因为为什么，你知道，你为什么要为我格式化？该模型肯定足够聪明，可以格式化地址。所以我认为这应该交给最终用户。

是的。我认为Alessio即将转向服务器实现。我想，我认为我们正在谈论，我们仍在谈论MCP的设计、目标和意图。我们，我认为我们间接地确定了MCP真正试图解决的一些问题，但我希望给你一个机会，来

直接讨论MCP与OpenAPI，因为我认为这显然是一个最重要的问题。我想总结一下我们刚才谈论的所有内容，并为人们提供一个很好的小片段，人们可以说，“这是关于MCP与OpenAPI的明确答案。”是的，我认为

从根本上说，我的意思是，OpenAPI规范是一个非常好的工具。就像我在开发API和API使用者时经常使用它们一样。我认为从根本上说，或者我们认为它们对于你想要用LLM做的事情来说太细粒度了。就像它们不表达更高级别的AI特定概念，就像我们用MCP的基元谈论过的整个心理模型，并从应用程序开发人员的角度进行思考一样，你不会

在将这些信息编码到OpenAPI规范中时获得任何这些信息。因此，我们认为模型将从专门设计的工具、资源、提示和其他基元中获益更多，而不仅仅是像，“这是我们的REST API，随意使用”。我认为还有另一个方面。我认为我不是OpenAPI专家，所以所有内容可能并不完全准确。但我认为我们就像，已经存在，我们稍后可以详细讨论这一点，这是一个深思熟虑的……

设计决策，使协议具有某种状态，因为我们确实相信AI应用程序和类似AI的交互将变得固有地更具状态，而我们目前的状况是……

对无状态性的需求更多的是一个暂时的点，将在某种程度上永远存在。但我认为，随着你考虑超越纯文本的额外模式，例如与模型的交互，例如视频、音频，以及其他已经存在和存在的模式，更具状态性将变得越来越流行。

所以我认为，拥有更具状态的东西在这种交互模式中固有地是有用的。我认为OpenAPI和MCP实际上比人们想要表达的更互补。就像人们寻找这些，你知道，A与B，并且让所有这些东西的开发者进入一个房间，进行一场拳击比赛。但是

这很少发生。我认为实际上，它们非常互补，并且它们有自己非常非常强大的空间。我认为，你知道，为工作选择最佳工具。如果你想在AI应用程序之间进行丰富的交互，它可能就像，它可能是MCP。这是正确的选择。如果，如果你想要一个非常容易的API规范，并且模型可以读取和解释，这就是对你有用的东西，那么OpenAPI就是正确的选择。

这里要补充一点的是，我们已经看到人们，我的意思是，这发生得很早，社区中的人们也构建了这两个之间的桥梁。所以，如果你有一个OpenAPI规范，没有人为它构建自定义MCP服务器，那么已经有一些转换器可以将它重新公开为MCP，你也可以反过来做。太棒了。

是的。我认为MCP的另一面是人们谈论得较少，因为它没有病毒式传播，那就是构建服务器。所以我认为每个人都会发推文说，“我将Cloud Desktop连接到XMCP。太棒了。”你们会如何建议人们开始构建服务器？我认为规范就像，你可以做很多事情，这几乎就像，你如何区分作为服务器开发人员的描述性与我们之前的讨论一样，就像获取数据，然后让模型稍后操作它。你们有什么建议吗？我认为，我有一些建议。我认为关于MCP最好的事情之一，也是我们很早就做对的事情，那就是它非常非常容易构建一些可能并不惊人的东西，但它足够好，因为模型非常好，可以在大约半小时内启动它，你知道吗？所以我认为最好的部分就是像

选择你最喜欢的语言，选择它的SDK，如果它有SDK的话，然后就开始构建对你个人来说很重要的事情的工具，以及你想要看到模型与之交互的东西。构建服务器，放入工具，暂时不要太担心描述，就像在你思考时写下你的小描述，然后把它交给模型，然后

把它扔到标准IO协议中，传输到你喜欢的一个应用程序中，并看到它做事情。我认为这是魔法的一部分，或者说是开发人员获得这种能力和魔法，以便快速获得模型做一些你关心的事情。

我认为这真的让你开始并进入这种流程，就像，“好吧，我看到这个东西可以做很酷的事情。现在我可以扩展它了。现在我可以考虑我想要哪些不同的工具，我想要哪些不同的资源和提示了。

好吧，现在我有了这个，好吧，现在我的评估看起来像什么？我如何使用这样的工具来优化我的提示以进行评估？你可以做到无限的深度，但从尽可能简单的地方开始，然后用你选择的语言在半小时内构建一个服务器，以及模型如何与你关心的事情进行交互。我认为这就是乐趣所在。我认为人们，我认为MCP使之成为可能，并且

很棒的是，它为开发过程增添了很多乐趣，只是让模型快速地做事情。

我还，我又很偏向于使用AI来帮助我进行编码。我认为即使在最初的开发过程中，我们也意识到很容易基本上只是获取所有SDK代码。再次，你知道，大卫建议的那样，就像，你知道，选择你关心的语言，然后选择SDK。一旦你有了它，你就可以直接将整个SDK代码

放入LLM上下文窗口中，然后说，“好吧，既然你知道MCP了，那就为我构建一个执行此操作、此操作、此操作的服务器。”它就像，

我认为结果令人震惊。我的意思是，它可能并非在每个角落都完美无缺，你可以随着时间的推移对其进行改进。但就像，这是一种一次性获得基本上可以满足你需求的东西的好方法，然后你可以从那里进行迭代。就像大卫说的那样，从一开始就非常重视使服务器尽可能易于构建，这当然也有助于LLM也这样做。我们经常发现，就像

入门就像，你知道，用你选择的语言编写100到200行代码。这真的很容易。是的。如果你没有SDK，再次将你关心的规范子集提供给模型，就像另一个SDK一样，并让它为你构建一个SDK。它通常适用于该子集。构建完整的SDK是另一回事，但要让模型在Haskell或任何你喜欢的语言中进行工具调用，这可能非常简单。是的。对不起。

- 我想说，我在AGI house共同主持了一个关于个人代理的编程马拉松，有人构建的个人代理之一是一个MCP服务器构建器代理，它基本上会放入API规范的URL，然后为他们构建一个MCP服务器。你今天是否认为这有点像

是的，大多数服务器只是现有API之上的一个层，没有太多意见。是的，你认为这将是未来的发展方向吗？就像AI生成的，暴露给已经存在的API？或者我们将看到以前无法实现的全新MCP体验？开始吧。

我认为两者都有。我认为总会有价值，就像，“哦，我的数据在这里，我想使用一些连接器将它带到这里的应用程序中。”这种用例肯定会保留下来。我认为这有点像回到过去，我认为今天很多事情可能默认使用工具，而一些其他基元随着时间的推移可能会更合适。所以

它仍然可以是那个连接器。它仍然可以只是那种适配器层，但可以像实际将其适配到不同的基元上，这是一种增加更多价值的方法。但我也认为有很多机会可以用于用例，或者对于MCP服务器来说，它们本身会做一些有趣的事情，而不仅仅是适配器。最早的例子之一是像，你知道，内存MCP服务器，它使LLM能够记住跨对话的内容，或者像一个关系密切的同事构建的

对不起，我不应该这么说。不是关系密切的。有人构建了顺序思维MCP服务器，它使模型能够逐步思考，并提高其推理能力。这是某种情况，它实际上并没有与任何外部事物集成。它只是为模型提供了一种思考方式。

我想无论哪种方式，我认为AI创作服务器都是完全可能的。就像我曾经在提示方面取得了很多成功，就像，“嘿，我想构建一个执行此操作的MCP服务器。”即使这件事没有适应其他API，而是做了一些完全原创的事情，它通常也能弄清楚。是的，我认为，要补充一点，我认为

MCP服务器的一个重要部分将是这些像API包装器的东西。这很好，也很有效，因为它有效，而且它让你走得很远。但我认为我们只是在探索你可以做什么的早期阶段。我认为随着对某些基元的客户端支持越来越好，就像我们可以谈论采样一样，这是我最喜欢的顶级内容。

同时也是最大的挫折。我认为你可以很容易地看到它，看到像，非常非常丰富的体验。我们已经在内部构建了它们作为原型设计方面。我认为你已经在社区中看到了一些，但是有一些事情，例如，“嘿，总结一下我的，你知道，我的，我的，

我最喜欢的子reddit的早晨MCP服务器，还没有人构建，但很容易想象，协议完全可以做到这一点。这些都是稍微丰富的体验。我认为随着人们从像，“哦，我只是想，我只是在这个新世界里，我可以将我关心的事情连接到LLM”，到真正想要一个真正的流程，一个真正更丰富的体验，我真正想要向模型展示的体验，我认为然后你会看到这些东西出现

但同样，目前客户端支持与服务器作者想要做什么之间存在一点鸡和蛋的问题。是的，这是我关于可组合性的下一个问题。你们怎么看待这个问题？你们有什么计划吗？MCP的导入是什么，比如说，到另一个MCP？如果我想构建subreddit的那个，可能会有Reddit API MCP和summarization MCP。然后我如何……

我如何做一个超级MCP？是的，这是一个有趣的话题。我认为它有两个方面。我认为一个方面是，我如何构建一个需要LLM调用（以某种形式）的东西，例如用于总结，但我保持模型独立性。为此，

这就是双向性的一部分，在这种Moritza体验中，我们确实有这种机制，让服务器再次询问拥有LLM交互的客户端，对吧？就像我们谈论光标一样，谁为你运行LLM循环。

在那里，服务器作者可以向客户端请求完成，并基本上让它为服务器总结一些内容并将其返回。因此，现在哪个模型总结取决于你在光标中选择的哪个模型，而不取决于作者带来的内容。作者没有带来SDK。它没有让你拥有API密钥。它完全独立于模型，你可以构建这个。这只是一个方面。

使用MCP构建更丰富系统的第二个方面是，你可以很容易地想象一个MCP服务器为像Cursor或Windsurf或Cloud Desktop提供服务，但同时也是一个MCP客户端，并且它本身可以使用MCP服务器来创建丰富的体验。现在你有一个递归属性，我们实际上在设计原则中非常小心地试图保留它。

你到处都能看到它，以及我们在规范中训练过的授权和其他方面，就像递归模式一样。现在你可以考虑像，“好吧，我有了这个应用程序的小包，服务器和客户端，我可以将这些添加到链中，并构建基本上是MCP服务器的DAG图，它们可以彼此丰富地交互。”一个Gentic MCP服务器也可以使用可用的整个MCP服务器生态系统。我认为

这是一个非常酷的环境，你可以做的一件很酷的事情。人们已经尝试过这个。我认为你会希望看到更多这样的事情，特别是当你考虑自动选择、自动安装时。你可以做很多这样的事情，这会带来非常有趣的体验。我认为……

实际上，我们仍然需要在SDK中添加一些细节，以使其真正易于执行。就像这个既是服务器又是客户端的递归MCP服务器，或者像将多个MCP服务器的行为多路复用到一个主机中，就像我们所说的那样。这些是我们绝对想要添加的东西。我们还没有能够做到，但我认为这将有助于展示我们知道已经可能实现的事情。

还没有被充分利用。MARK MIRCHANDANI：好的，这非常令人兴奋，而且——我相信很多人会从中学到很多想法和灵感。一个既是服务器又是客户端的MCP服务器，它是一个代理吗？ FRANCESC CAMPOY：什么是代理？代理有很多定义。MARK MIRCHANDANI：因为在某些方面，你正在请求某些东西，它正在执行你并不一定知道的事情。在你和数据的最终原始来源之间存在一层干扰。你可以反驳这一点。我只是不知道你是否对代理有独到的见解。

我认为你可以那样构建一个代理。对我来说，我认为你需要定义只是代理的MCP服务器加客户端与代理之间的区别。我认为存在差异。我认为这种差异可能在于，例如，使用样本循环来创建更丰富的体验，让模型在该MCP服务器内通过这些客户端调用工具。我认为那时你才拥有一个真正的代理。是的，我认为这样构建代理非常简单。是的。

我认为这里可能有几条路径。就像，MCP和代理之间肯定存在某种关系一样。一种可能的版本是，也许MCP是一种表示代理的好方法。也许有一些像，你知道，缺少的功能或特定的事情，这将使它的可用性更好。我们应该将其作为MCP的一部分。这是一种可能性。另一种是，也许MCP作为一种基础通信层是有意义的。

让代理与其他代理或类似的东西组合。或者可能还有其他可能性。也许MCP应该专门关注AI应用程序方面，而不是代理方面。我认为这是一个非常现实的问题，我认为每个方向都有权衡。回到上帝盒子的类比，我认为我们在设计协议和某种程度上策划或引导生态系统时必须非常小心的一件事是试图做得太多。我认为这是一个非常大的——是的，你不想让一个协议试图解决阳光下的所有事情，因为那样它在所有事情上都会很糟糕。所以我认为关键问题，它仍然没有解决，就是代理在多大程度上

真正自然地融入这个现有的模型和范例？或者在多大程度上是

基本上只是正交的。它应该是什么。我认为一旦你启用双向，一旦你启用客户端服务器在将工作委托给另一个MCP服务器时相同，它肯定比不是代理更像代理。但我感谢你记住简单性，并且不试图解决阳光下的所有问题。酷。我很乐意继续讨论。我的意思是，我将双击我标记的几件事，因为它们与我们无论如何都想问你的事情相吻合。所以第一个是，它只是一个简单的

一个实现可以支持多少MCP事物？所以这是宽与深的问题。这与我们刚才讨论的MCP嵌套直接相关。在2024年4月，当Claude启动其第一个上下文时，第一个百万个令牌上下文，

示例，他们说你可以支持250个工具。而且，你知道，对我来说，这是宽泛的，因为你没有调用工具的工具。你只有模型和工具的扁平层次结构。但显然你会遇到工具混淆。当工具相邻时，就会发生这种情况，你调用了错误的工具，你将得到错误的结果，对吧？你是否建议在任何给定时间启用MCP服务器的最大数量？我认为

说实话，我认为这个问题没有一个答案，因为在某种程度上，它取决于你使用的模型，在某种程度上，它取决于工具的命名和描述对于模型来说有多好，等等，以避免混淆，我的意思是，我认为

梦想当然是像你只是向LLM提供所有这些信息，它可以理解所有内容。这有点像我们设想MCP的未来，就像所有这些信息都被带到模型中，它决定如何处理它一样。但是今天，现实或实际情况可能意味着，是的，也许在你的客户端应用程序中，像AI应用程序一样，你对工具集进行一些过滤，或者也许你运行一个更快、更小的LLM来过滤最相关的内容。

相关内容，然后只将这些工具传递给更大的模型。或者你可以使用一个MCP服务器，它是一个代理，用于其他MCP服务器，并在该级别进行一些过滤，或者类似的东西。我认为数百个，正如你提到的那样，仍然是一个相当安全的赌注，至少对于云来说是这样。我不能谈论其他模型，但是是的，我不知道。我认为随着时间的推移，我们应该期望这种情况会好转。所以我们警惕限制任何东西并阻止这种长期目标。

是的，很明显，这高度取决于描述的重叠程度，对吧？比如，如果你有非常独立的服务器来做非常独立的事情，并且工具有非常清晰的唯一名称、非常清晰、写得很好的描述，那么你的里程数可能会比同时在你的上下文中拥有 GitLab 和 GitHub 服务器时更高。然后重叠就相当显著了，因为它们看起来与模型非常相似，混淆就更容易了。

根据 AI 应用的不同，也有不同的考虑因素。如果你试图构建一些非常主动的东西，也许你试图尽量减少需要向用户提问的次数，或者尽量减少界面中的可配置性等等。但是，如果你正在构建其他应用程序，你正在构建 IDE 或聊天应用程序等等，我认为拥有允许用户说“此刻，我想要这个功能集”，或者在不同的时刻，“我想要这个不同的功能集”之类的功能是完全合理的。

还有可能不要把它当作总是开启的、完整的列表总是始终开启。是的，我认为资源和工具的概念在这里有点融合了，对吧？因为现在你是在说你想要某种程度的用户控制，对吧？或者应用程序控制。而其他时候你又想让模型来控制它，对吧？所以现在我们只是选择工具的子集。我不知道。是的，我认为这是一个公平的观点或合理的担忧。我想我思考这个问题的方式仍然是，

归根结底，这是一个 MCP 的核心设计原则，那就是最终的客户端应用程序以及扩展的用户，最终应该完全控制通过 MCP 发生的一切。当我们说工具是由模型控制时，我们的真正意思是工具只能由模型调用。不应该存在应用程序交互或用户交互，例如，“好的，作为用户，我现在想让你使用这个工具”。

我的意思是，你偶尔可能会出于提示的原因这样做，但我认为这不应该是一个 UI 功能。但我认为客户端应用程序或用户决定过滤掉 MCB 服务器提供的功能是完全合理的，甚至可以转换它们。你可以想象一个客户端应用程序，它从 MCB 服务器获取工具描述并丰富它们，使它们更好。在 MCB 范例中，我们真的希望客户端应用程序拥有完全的控制权。除此之外，我认为我思考中非常非常早期的想法是

协议中可能会有一个补充，你想让服务器作者能够将某些原语逻辑地组合在一起，这可能会提供信息，因为他们可能更了解其中一些逻辑分组，这可以同时包含提示、资源和工具。我的意思是，就我个人而言，我们可以就此进行设计讨论。就我个人而言，我的看法是这些应该是独立的 MCP 服务器，然后用户应该能够将它们组合在一起。但我们可以解决这个问题。

是否会有一个类似于 MCP 标准库的东西，比如说，“嘿，这些是规范的服务器。不要构建这个。我们会处理这些。”这些可能是人们可以组合的构建块。或者你期望人们为很多事情重新构建他们自己的 MCP 服务器？

我认为我们不会那样具有规定性。我认为本质上，你知道，有很多力量。好吧，让我改一下说法。就像我在开源方面有很长的历史，我觉得这种解决问题的奇怪方法有点用，对吧？我认为这样最好的、最有趣的选项就会胜出。我认为我们不想过于规定。我确实预见到，而且这种情况已经存在，那就是，

25 个 GitHub 服务器和 25 个，你知道的，Postgres 服务器等等。这一切都很酷，都很好。我认为它们都以自己的方式添加内容。但实际上，最终在几个月或几年后，生态系统将收敛到一组广泛使用的服务器，基本上，我不知道你是否称之为获胜，但这些将是最常用的服务器。我认为这完全没问题，因为基本上，

对这一点具有规定性。我认为这没有任何用处。我当然认为会有 MCP 服务器，你已经看到了由公司为其产品驱动的服务器。它们本质上可能就是规范的实现。例如，如果你想使用 Cloudflare worker 并为此使用 MCP 服务器，你可能想要使用 Cloudflare 开发的服务器。是的。

我认为这里可能还有一件相关的事情，只是关于我们正在考虑的一件大事，我们没有任何现成的解决方案，那就是信任或审查的问题，也许审查是一个更好的词。你怎么判断哪些 MCP 服务器是好用安全的？不管有多少个 GitHub MCP 服务器的实现，这都完全没问题，但你要确保你没有使用那些非常可疑的服务器，对吧？

因此，试图思考如何赋予声誉或，你知道的，如果假设 Anthropic 就像我们已经审查过这个，它符合我们对安全编码的标准等等。这如何在每个人都能从中受益的开放模型中体现出来？

我还真不知道答案，但这非常重要。但我认为这是 MCP 的一个很好的设计选择，它与语言无关。就像已经，据我所知，没有 Anthropic 官方的 Ruby SDK，也没有 OpenAI SDK。Alex Rudel 在构建这些方面做得很好。但是现在有了 MCP，你实际上不必将 SDK 翻译成所有这些语言。你只需要一个接口，并将该接口作为 Anthropic 来认可。所以……

是的，那很好。我对这件事有一个快速的回答。所以，很明显，已经有五到六个不同的注册中心出现了。你们宣布了你们官方的注册中心已经消失了。注册中心非常容易提供下载次数、点赞、评论和某种信任机制。我认为这有点脆弱。无论你能提供什么类型的社会证明或其他东西，下一次更新都可能损害受信任的软件包。实际上，这才是造成最大损害的软件包。

对。所以滥用信任系统就像建立信任系统一样，会造成信任系统造成的损害。所以我实际上想鼓励人们尝试 MCP Inspector，因为你只需要查看流量就可以了。我认为这适用于许多安全问题。是的，绝对的。我认为这就像一个非常经典的供应链问题，所有注册中心实际上都存在这个问题。是的。

解决这个问题的方法有很多种。你可以采用苹果的方法，审查事物，并拥有一支由自动化系统和审查团队组成的队伍来做这件事。然后你实际上就建立了一个应用商店，对吧？这是解决这类问题的一种方法。它在某些方面确实有效。但我认为它在开源生态系统中并不适用，因为你总是有某种注册中心方法，类似于 NPM 和 B2B。

软件包和 PiPi，它们都固有地存在这些，这些，这些供应链攻击问题。对。是的，完全正确。快速检查一下时间。我认为我们还要再进行 20 到 25 分钟。你们可以吗？

好的，太棒了。酷。我想双击一下，花点时间。所以我要，我们之前预览了一下未来的内容。所以我想把未来的内容留到最后，比如注册中心、无状态服务器和远程服务器，所有其他内容。但我想要更详细地介绍一下官方存储库中包含的核心服务器。其中一些是特殊的服务器，就像我们之前讨论过的那样。

所以让我先把它们调出来。例如，你提到了内存，你提到了顺序思维。我认为我真的很，真的很鼓励人们看看这些，我称之为特殊服务器的东西。它们不是通常意义上的服务器，因为它们包装了一些 API，与这些 API 交互比与 API 本身交互更容易。所以我会先重点介绍内存服务器，因为它……

有一些内存启动项目，但如果你只使用这个，实际上你就不需要它们了。它也只有 200 行代码。非常简单。显然，如果你需要将其扩展，你可能应该使用一些经过更多考验的东西。但如果你只是在介绍内存，我认为这是一个非常好的实现。我不知道你是否想重点介绍其中一些的特殊故事？我认为，不，我认为没有什么特别之处。我认为很多这些

并非所有，但很多都源于我之前提到的黑客马拉松，在那里，人们对 MCP 的想法感到兴奋。Anthropic 内部想要拥有内存或想要尝试这个想法的人现在可以使用 MCP 快速原型化一些以前不可能实现的东西。

不需要成为端到端专家的人。你不需要访问。你不需要访问这个私有的，你知道的，专有的代码库。你现在就可以用这种内存功能扩展云。这就是很多这些服务器的由来。然后还要考虑一下，你知道的，我们想要在发布时展示的功能广度？

完全正确。我认为这部分原因是你们的发布成功了，因为你们发布时提供了一组足够广泛的示例，然后人们只需复制粘贴并从中扩展即可。我还想重点介绍一下文件系统 MCP 服务器，因为它具有编辑文件的功能。基本上，我认为当我们邀请 Eric（他也在播客中构建了你们的甜蜜基准项目）时，人们对此类文件编辑功能非常兴奋。人们对这种文件编辑功能非常感兴趣。我认为有很多现有的库，还有一些其他的实现，你知道的，这对他们来说是核心 IP。现在你们只是把它发布出来了。这真的很酷。是的，我真的很，我的意思是，说实话，文件系统服务器是我最喜欢的服务器之一，因为

我认为它确实说明了我当时感受到的限制，你知道的，我当时作为一个副项目在做一个游戏，并且真的想把它连接到像 David 之前谈到的云和工件一样的东西。只是给云或突然能够给云赋予实际与我的本地机器交互的能力是巨大的。我真的很喜欢这种能力。是的。我的意思是，这是一个经典的例子，这个服务器

直接源于导致创建 MCP 和该服务器的挫败感。有一条非常清晰的直接路径，就像，这是我们目前遇到的挫败感，到 MCP 加上我们都感觉到的服务器，特别是 Justin。因此，在这方面，它与我们内心深处非常接近，就像协议本身的精神起源点一样。绝对的。

好的。然后我想重点介绍的最后一件事是顺序思维，你已经谈到了。这提供了分支，这很有趣。它提供了一种，你知道的，我需要更多空间来写作。

这非常有趣。我认为我还想澄清的一件事是，Anthropic 本周，也就是上周，发布了一篇新的工程博客，其中介绍了一个思考工具。社区对顺序思维与思考工具如何重叠有一些困惑。我只是认为这是不同的团队在世界不同地区做类似的事情。但我只想让你们澄清一下。我认为，我的意思是，肯定有，对不起，让我重新开始。

据我所知，这两者之间没有共同的血缘关系，但我认为这只是说明了一个更大的问题，那就是有很多不同的策略可以让 LLM 更周到或减少幻觉，或者无论是什么，都可以更充分或更可靠地表达这些不同的维度。

我不知道，我认为这就是 MCP 的力量，你可以构建不同的服务器来做这些不同的事情，或者在同一个服务器中拥有不同的产品或不同的工具来做这些不同的事情。并要求 LLM 应用特定的思维模型或思维模式或其他东西来获得不同的结果。所以，我不知道。我认为我想说的是，我不知道会有一个理想的规定方法，比如 LLM，这就是你应该一直思考的方式。

我认为会有针对不同目的的不同应用程序，而 MCP 允许你这样做，对吧？- 是的，我认为此外，还有一种方法，一些 MCP 服务器正在填补当时存在的差距，而模型后来自己赶上了，因为它们有

有训练时间和准备工作，进行研究以使模型本身能够做到这些事情。你可以通过像顺序思维工具这样的服务器获得很多里程碑。它并不简单，但可以在几天内完成，这绝对不是你考虑将思维添加到模型中的时间范围。

我想即兴举个例子，比如我可以想象构建，你知道的，如果我使用的是一个不太可靠的模型，或者，你知道的，也许有人认为今天的生成总体上不太可靠。比如我可以想象构建一个 MCP 服务器，它可以给我提供，

三次尝试中最好的三次，用模型回答查询三次，然后选择最好的一个等等。你可以通过 MCP 获得这种递归和可组合的 LLM 交互。- 太棒了，好的，酷。我认为，所以，对不起，感谢你们对一些服务的纵容。我只是想详细介绍一下这些。我认为我们有时间来讨论一下，

未来的路线图。人们对最近的更新从有状态服务器转向无状态服务器最兴奋。你们选择 SSE 作为你们的启动协议和传输，显然传输是可插拔的。幕后情况，比如是 Jared Palmer 的推文导致了它，还是你们已经在研究它了？

不，我们的 GitHub 讨论可以追溯到，你知道的，公开追溯到几个月前，真的，讨论了这个困境以及相关的权衡。你知道的，我们确实相信，像，AI 应用程序、生态系统和代理的未来，所有这些东西，我认为，将是有状态的，或者将更倾向于有状态。所以我们有很多……

我认为说实话，这是我们作为核心 MCP 团队讨论过的最具争议的话题之一，并且来来回回地进行了多次迭代。但最终还是回到了这个结论，那就是如果未来看起来更像是有状态的，我们不想完全远离这种范式。

现在，我们必须权衡它在操作上很复杂，或者如果需要这种长期存在的持久连接，那么部署 MCP 服务器会很困难。这是最初的 SSE 传输设计，基本上是部署 MCP 服务器，然后客户端可以连接进来。然后基本上你应该无限期地保持连接，这就像疯了。

对任何大规模运营的人来说，这都是一个艰巨的任务。这根本不是你真正想要支持的部署或操作模型。所以我们试图思考，我们如何才能在有状态的重要性与某种程度上

更简单的操作和维护等等之间取得平衡。我们提出的新的，我们称之为可流式 HTTP 传输的东西仍然包含 SSE，但它采用了一种更渐进的方法，其中服务器可以是普通的 HTTP，就像，你知道的，有一个端点你可以向其发送 HTTP post 请求，然后，你知道的，得到结果。但你可以像

逐渐增强它，比如，现在我希望结果是流式的，或者现在我希望服务器能够发出它自己的请求。只要服务器和客户端都支持像恢复会话这样的能力，比如，你知道的，断开连接并在稍后返回并从中断的地方继续，那么你就可以获得两全其美的好处，它仍然可以是这种有状态的交互和有状态的服务器，但允许你更容易地进行水平扩展，或者处理网络连接不稳定等等情况。

是的。正如你提到的，你拥有会话 ID。你如何看待未来的身份验证？对于某些 MCP，我只需要在我的命令中粘贴我的 API 密钥即可。是否有一种，是的，你认为未来的情况会怎样？是否会有类似于 .emp 的 MCP 等效项？是的。

我们在当前版本的协议的下一个版本中确实将授权作为规范。目前它主要关注使用 OAuth 2.1 或类似的现代 OAuth 子集的用户到服务器授权。我认为这有

这似乎对人们和在它之上构建的人们来说效果很好。这将解决很多这些问题，因为你真的不想让人们携带 API 密钥，尤其是在你考虑一个世界的时候，我相信这将会发生，大多数服务器将是远程服务器。所以你需要某种与该服务器的授权。对于本地情况，因为授权是在

在传输层上定义的，因此需要框架，这意味着有效地使用标头。这在标准 IO 中不起作用，但在标准 IO 中，你可以本地运行，并且无论如何你都可以做任何你想做的事情。你可能只是打开一个浏览器来处理它。然后还有一些想法，这些想法还没有完全确定，比如，你知道的，甚至在本地使用 HTTP，这将解决这个问题。

Justin 正在笑，因为他非常赞成这一点，而我非常不赞成这一点。所以我们正在就此进行一些辩论。但是像授权一样，我认为，你知道的，我们有一些东西。我认为它就像协议中的所有东西一样，可能都是最小的，试图解决一个非常实际的问题。它试图在其所做的事情上做到非常最小化。然后我们从那里开始添加。

基于人们在协议之上遇到的实际痛点，而不是从一开始就过度设计它。所以我们将看看我们当前的方面能让我们走多远，基本上。是的，我想在此基础上再补充一点，因为我认为最后一点非常重要。而且，

当你设计一个协议时，你必须非常保守，因为如果你犯了一个错误，你基本上就无法撤销这个错误，或者你破坏了向后兼容性。因此，只接受或只添加你非常确信的事情，并让人们进行临时扩展，直到可能达成更多共识，认为某些事情值得添加到核心事物中并无限期地支持，这要容易得多。

特别是对于身份验证，以及 API 密钥的这个例子，我认为这确实具有说明性，因为我们做了很多这样的头脑风暴，比如，好的，如果我有这个用例，我能否用这个版本的身份验证来实现它？我认为答案是肯定的，对于 API 密钥示例来说。比如你可以有一个 MCP 服务器，它是一个 OAuth 授权服务器。在类似于 /authorize 的网页上，它只有一个文本框供你输入 API 密钥。这将是一种完全有效的

MCP 服务器的 OAuth 流程。也许不是最符合人体工程学的设计，也不是人们理想中的设计，但因为它确实符合现有的范例并且今天是可能的，所以我们担心添加太多其他，太多其他选项，客户端和服务器都需要考虑这些选项。

是的。你们考虑过范围吗？如果像我们昨天与来自 HNAI 和 HubSpot 的 Dharmesh Shah 进行了一次访谈，他举了一个电子邮件的例子，比如他拥有所有电子邮件，你知道的，他希望对电子邮件有更细致的范围，比如，“嘿，你只能访问这些类型的电子邮件，或者发送给这个人的电子邮件”。今天，大多数范围都是 REST 驱动的，基本上是你可以访问哪些端点？你是否看到未来模型可以作为

范围层，可以说是动态地限制通过的数据？我认为可能需要范围。这可以追溯到，我们围绕这一点进行了讨论，但我们目前正在尝试做的是将其植根于非常具体的例子，并有一套很好的例子，这些是目前你无法用当前的实现解决的实际问题。这就是我们为添加到协议中设定的标准。

我认为，然后，你知道的，基于该原型，使用我们目前拥有的可扩展性，其中返回的每个结构都是可扩展的，然后在此基础上构建，并证明这将具有良好的用户体验。然后我们将其放入协议中。这在大多数情况下都是如此。对于一般的授权来说，情况并非如此。这有点自上而下，但我完全可以理解人们为什么想要它，这只是展示具体示例以及潜在解决方案的问题，这样我们不会意外地陷入这种困境，就像是的，将这些东西添加到这种方法中，它听起来大致正确，我们把它放进去，但实际上并不完全正确，现在你又回到了这种困境，添加很容易，删除很难，在协议设计中，所以我们只是有点，我们只是有点，你知道的

小心谨慎，可以说是。话虽如此，你知道的，每次我听到它，就像粗略的描述一样，它是有道理的。我很想有一个非常实际的端到端用户示例，以及它在当前实现中失败的地方，然后我们可以进行讨论。从我的角度来看，也有一些谨慎，也许不是针对范围本身。我认为这些可能很有意义，只要我们牢记用例。但我确实认为

你知道的，考虑到可组合性和事物的逻辑分组，我认为 MCP 服务器通常应该是相当小的东西。如果你想要很多功能集合，那么这些应该成为你可以作为用户或在应用程序层组合在一起的独立服务器。因此，关于身份验证的一些反对意见是，好吧，如果我需要在另一端授权 20 件不同的事情，我该如何做？就像，好吧，

也许这不是服务器应该做的事情。也许它不应该连接到 20 件不同的事情。也许这些应该是以某种方式组合在一起的独立服务器。太棒了。有很多讨论。如果人们想参与这些辩论，他们应该去哪里？只是规范存储库的讨论页面吗？这是一个好的开始。我想稍微提醒一下，在互联网上，很容易参与讨论并发表意见，而实际上并没有做任何工作。所以我认为有一些

Jensen 和我都是非常老派的开源人士，它是由功绩驱动的，也就是说，如果你做了工作，并且如果你用实际的例子和 SDK 中的工作来展示你想要做的扩展，那么你很有可能成功。如果你只是在那里发表意见，坦白地说，你很可能会被忽略，因为我们可以阅读的讨论点是有限的。

当然，我们重视讨论，我们希望进行讨论，但我们也需要管理我们的时间和参与度。我们显然会选择那些做最多工作的人。我们正在努力弄清楚，你知道的，说实话，我认为即使与我过去做的开源工作相比，MCP 相关的内容的对话和通知数量之多也是非同寻常的，一方面这很好。

但我认为我们确实需要找到更可扩展的结构来与社区互动，同时也保持对话的高信号和有效性。我想还有一点需要注意的是，与 David 的观点相关，我认为运行成功的开源项目的一个重要部分是做出一些人们会不高兴的艰难决定。你必须像，你知道的，学习像工作一样

弄清楚什么是什么，项目的实际愿景是什么，我们作为维护者或牧羊人或其他什么人认为它是什么，并坚持下去，并理解有些人不会同意这个愿景，这完全没问题，但也许也许会有其他项目更符合他们的期望等等，我认为这是一个非常有趣且相当

好的观点。它就像 MCP 这样的产品是进入一般空间中问题的解决方案空间的入口。它是在某种程度上众多入口之一。如果你不喜欢我们和那些非常接近协议开发的人选择的方向，那么总是有更多的地方。这就是开源的美妙之处，对吧？古老的分支方法。

我们总是想听到反馈，我认为我们需要使其具有可扩展性，但也只是认识到，有时我们会根据我们的直觉来做出正确的选择。关于此事的开源讨论中可能会有很多争议，但这只是这类项目有时的天性。是的，幸运的是，你们两个都不是新手。我还想说

Facebook 开源有很多历史可以借鉴，对吧？你们俩，即使没有直接参与，你们也知道，所有直接参与的人，我想都会有反应。我们最终开始是因为我显然是 React 生态系统中非常重要的一部分。我们最终开始成立工作组，它是开放的。它是在讨论中进行的，每个工作组成员都有一个代表社区重要部分的声音，但也表明他们做了工作。他们很重要。他们不是那种没有参与其中的人。我认为这对一段时间来说是有帮助的。我不确定这是否像一个积极管理的事情，因为 React 本身在多公司环境中存在问题。另一件对我来说更有趣的事情是 GraphQL。

因为 MCP 目前拥有 GraphQL 曾拥有的热度。我经历过那个。最终，Facebook 将 GraphQL 捐赠给了一个开源基金会。我认为有一个问题是，

我们是否想这样做？权衡利弊，对吧？这不是一个明确的 yes 或 no。我想说大多数人都对 Anthropic 和你们感到满意，显然，因为你们创造了它，你们是管理者。但在某个时刻，在某个规模上，你们会遇到一些瓶颈，你们会想，好吧，你知道，这是由一家公司拥有的。而且，你知道，最终人们想要，真正的开放标准是一个非营利组织。有多个利益相关者。有一个良好的治理流程，所有这些都由 Linux 基金会、Apache 等机构管理。所以我想问一下，

有什么想法吗？我个人认为现在还为时过早。你知道，你的想法是什么？是的，我认为治理通常是开源领域一个非常有趣的问题。我认为有两件事。一方面，我们真的非常希望这成为一个开放的标准、开放的协议和开放的项目，并且，你知道，参与者

来自所有想要参与的人的参与。我认为到目前为止，这工作得相当好。如果你看看拉取请求，例如，关于可流式 HTTP 的很多输入都来自 Shopify 等公司，他们已经讨论和研究过这个问题，并提出了建议。我认为这工作得很好。我们有点担心的是

任何类型的官方标准化，特别是通过实际的标准化机构或任何类型的开始将流程作为其一部分的奠基工作，以对每个人都保持某种公平，这可能会

在这个快速发展的领域（如 AI）中，流程可能会对项目产生不利影响。这就是我们担心的。我们担心会减慢我们的速度。因此，我们正在努力寻找一个很好的中间地带，例如，我们如何才能拥有我们幸运地拥有的来自每个人的参与，为每个人的目标努力，你知道。

每个人都有可能对治理模式遇到的问题，并找到正确的向前发展的道路，而不会意外地减慢项目的速度。我认为这就是我们正在努力做的。

但是，是的，我们真诚地希望这成为一个开放的项目。是的，它是由 Anthropic 发起的，我和 David 在 Anthropic 工作，但我们不希望它被视为 Anthropic 的协议。我认为对整个生态系统来说，这非常重要，任何 AI 实验室都可以参与其中、为其做出贡献或使用它。但这只是，它是在平衡这一点与

避免“委员会之死”，基本上。因此，我认为有很多成功的开源模式。我认为大多数微妙之处实际上都与公司赞助和公司发言权有关，我们将在出现时进行处理，但我们绝对希望这成为一个社区项目。

话虽如此，我想强调一下，目前，在我们说话的时候，有很多不是 Anthropic 员工的人拥有对存储库的提交访问权限和管理员访问权限。你知道，一些来自 Pydentic 的人拥有对 Python SDK 的提交访问权限，因为他们在那里做了很多非常好的工作。我们从 Block 和其他人那里得到了很多关于规范的贡献。像 Java SDK 和 C# SDK 这样的 SDK，它们完全是由不同的公司完成的，例如 C# SDK。

一个是微软做的。这是上周的一个非常新的补充，他们在那里做所有事情。他们对该项目拥有完全的管理员权限。JetBranch 做 Kotlin 项目也是如此，Spring AI 做 Java 项目也是如此。所以实际上，如果你真的仔细看看，它已经像一个多公司的大型项目，每个人都在参与。除了我们两个人之外，还有很多人拥有对项目的提交访问权限和权限。是的。

太棒了，伙计们，这太棒了。最后，你们有什么 MCP 服务器愿望清单吗？你们希望人们构建什么还没有？或者客户端。客户端或服务器。我想要更多采样客户端。这就是我想要的。我想要酷的。我希望有人构建一个采样客户端，另一个人为我构建一个服务器，它可以总结我的 Reddit 线程或总结。就像我是一个老 EVE Online 玩家一样。为我总结过去一周在 EVE Online 中发生的事情。

我希望有人能做到这一点。但为此，我需要一个采样客户端。我想要这个模型独立。不是因为我想使用除 Clot 之外的任何其他模型，因为 Clot 绝对是最好的，但我只是想要一个采样客户端，为了拥有一个采样客户端。

我将回应这一点，并广泛地说，我认为更多支持规范全部范围的客户端将是惊人的。我的意思是，我们设计事物的方式是，无论如何都可以逐步采用，但仍然如此。

如果我们投入了这些想法的所有这些原语都能以某种方式实现，那就太好了。那将是惊人的。但回到我最初参与 MCP 工作的动机和对文件系统服务器的兴奋，我喜欢将游戏作为副项目进行黑客攻击。所以我真的很想拥有一个带有 Godot 引擎的 MCP 客户端和/或 MCP 服务器，我正在使用它来构建游戏，并让它与 AI 非常轻松地集成，或者让

你知道，Claude 运行并测试我的游戏，或者类似 Claude 玩口袋妖怪的东西。谁知道呢？嘿，至少你已经构建了它们。让 Claude 从现在开始使用 Blender 构建你的 3D 模型，对吧？

但是，是的，我的意思是，即使是着色器代码之类的东西，我也只是觉得这不是我的专长。当你赋能建设者时，你能做到的事情真是太神奇了。是的，我们实际上正在与 David Hershey 合作开展 Cloud Place Pokemon 黑客马拉松。所以如果他坚持要将 MCP 引入其中，我没有计划，但如果他想，他可以。太棒了，伙计们。感谢您的时间。是的，继续努力。谢谢你们两位。这很有趣。是的，谢谢。非常感谢。干杯。干杯。