Model Context Protocol Deep Dive
42:23 Share

在本期节目中，Daniel 和 Chris 深入探讨了模型上下文协议 (MCP)，这是一个新兴标准，用于支持自主式 AI 与外部系统、API 和数据源进行交互。他们探讨了 MCP 如何支持互操作性、社区贡献和快速发展的 AI 集成生态系统。对话还重点介绍了一些现实世界的工具，例如 FastAPI-MCP。 参与者： Chris Benson – 网站、GitHub、LinkedIn、X Daniel Whitenack – 网站、GitHub、X 链接： 协议网站 Anthropic 博客文章 博客文章 - 模型上下文协议 (MCP) 概述 FastAPI-MCP 如何使用 FastAPI MCP 服务器：完整指南 Candle（Rust 框架）</context> <raw_text>0 欢迎收听 Practical AI，这是一档让所有人都能轻松、高效地使用人工智能的播客。如果您喜欢这个节目，您一定会喜欢 The Change Log。它在周一发布新闻，周三进行深入的技术访谈，周五则是一档精彩的周末谈话节目。您可以在收听播客的任何地方搜索 The Change Log 找到我们。

感谢我们 Fly.io 的合作伙伴。在五分钟或更短的时间内启动您的 AI 应用程序。请访问 Fly.io 了解详情。欢迎收听 Practical AI 播客的完全互联剧集。

在只有我和 Chris 没有客人的剧集中，我们会努力让您了解 AI 行业中发生的许多不同的事情，并可能分享一些技巧或资源，帮助您提升机器学习和 AI 技能。

我是 Daniel Whitenack。我是 PredictionGuard 的首席执行官，一如既往地与我的联合主持人 Chris Benson 合作，他是洛克希德·马丁公司的一名首席 AI 研究工程师。Chris，你好吗？我今天过得很好，Daniel。我们有一些有趣的事情要谈论。是的，是的。你知道，一如既往，这是一个有趣的季节，新的事件。

新的模型发布、新的工具、新的框架。当然，2025 年似乎注定是自主式 AI 之年。这是许多人都在谈论的事情。的确。而且，你知道，当然，它不断地出现在我们面前。自主式 AI 是否以任何方式影响着你的世界？

方式、形状或形式？在不透露我不允许谈论的任何内容的情况下。是的，是的。绝对的。好的。好的。所以是的，我想说的是，在很多方面，我看到我们的客户正在形成一种模式，有点像他们已经做了粗略的事情。所以就像一个知识库聊天机器人，

他们可能做过结构化数据交互，比如文本到 SQL 之类的东西。也许他们创建了一个自动化程序，比如，“我将把这个文件放在这里，然后会发生几件事，其中一些是由 LLM 驱动的，然后一些东西会从另一端弹出，或者我会给这个人发电子邮件。”所以他们开始开发这些独立的助手，然后

然后我看到他们开始有点顿悟，在这些独立的助手或工具之上添加一层，我认为我们通常可以称之为自主层，它现在说，好吧，我可以与非结构化数据交互。我可以与结构化数据交互。我可以与这些自动化程序交互。也许我可以通过 API 与其他系统交互。我该如何开始将这些东西联系起来，以便

有趣的流程和各种方式。这就是我所看到的。我不知道。我不知道，如果你也看到了这种模式。我有。我只是想指出，我和你已经谈论过这些事情很久了。我们在 COVID 之前没有。

在自主式出现之前，我们并没有说它是，我们没有使用这个术语，因为这是最终采用的术语，但我们经历了很多生成式的东西，我们当时说，好吧，下一步是许多这些代理。

不同的架构要回溯。我们现在肯定看到了这一点。它有一个名字。是的，它有一个名字。实际上，它还有一个协议。它有一个协议。很好的过渡。或者无论如何，它正在开发一个协议，这绝对是我认为我们今天想要深入探讨的事情，现在我们可以

我们没有客人。我们可以退后一步，稍微深入研究一下模型上下文协议。那么，Chris，你第一次在哪里看到这个协议出现的？是的。

好吧，当 Anthropic 发布博客文章时，你知道，你开始看到它到处都是。所以博客文章发布后仅仅几个小时，我相信你也是一样。然后所有后续的帖子和文章都出来了，等等。但是，是的，它引起了轰动。是的，所以技术上来说这是上周的事。

如果我查看公告日期，对，这是 2024 年 11 月 25 日。Anthropic 发布了一则公告，介绍了模型上下文协议，

当然，他们还写了一篇博客文章来介绍它。它来自 Anthropic，但也链接到一个开放项目，模型上下文协议，它只是 GitHub 上的模型上下文协议。有一个网站 modelcontextprotocol.io，它介绍了规范等等。所以它起源于 Anthropic，但是……

但是我认为从一开始，Anthropic 就希望这将成为一个更广泛采用的协议。也许我们应该先谈谈对这种需求。

我们之前在节目中谈到过工具调用，Chris。我不知道你是否记得一些讨论，但是经常会有这种情况，我认为我们甚至谈到了人们谈论 AI 模型的尴尬时刻，你知道，租一辆车或类似的事情，并与 kayak.com 交互。

好吧，AI 模型不会这样做，对吧？引擎盖下会发生其他事情，我认为这在一段时间内可能被称为工具调用或函数调用，其步骤本质上是 LLM。你会给 LLM 提供上下文，可能是 kayak.com API 的模式，对吧？

然后你会提出一个查询，并让 LM 生成适当的 JSON 主体来调用 kayak.com API。然后你将使用普通的旧式代码，你知道，Python 请求或其他什么来实际执行对外部工具的 API 调用。

并获得响应。这个流程大致是这样吗？你知道，我有没有说错什么？没有，没有，这就是我的理解。人们会在其中放入相当多的自定义代码来将这些不同的方面粘合在一起。并且在不同的组织之间差异很大。是的，是的。所以这就是，我想，出现的压力点或需求是，

每个人都看到，好吧，也许最好将 AI 模型插入到外部工具中，而不是让 AI 模型做所有事情，对吧？所以有些事情是 AI 模型做得不太好的。当我提到 AI 模型时，我默认指的是 Gen AI 模型。让我们只关注大型语言模型。它们不会成为你在以下方面最好的朋友

例如，进行时间序列预测，也许使用大量数据，但是有一些工具可以做到这一点。那么，如果我只是通过 API 利用这些工具，我可以要求我的“代理”给我一个 x 的时间序列预测。然后

并且有一个工具在引擎盖下与数据库交互，提取数据。然后有一个工具进行时间序列预测，然后就完成了。你将这两者结合起来，看起来你的 AI 系统正在进行预测，但实际上你是在引擎盖下调用这些外部工具。问题是，

每个人都有不同的工具。每个人都有不同的数据库。每个人都有不同的 API。每个产品都有不同的 API。每个人都有不同的函数代码。因此，类似于在互联网早期，每个人都在发布内容并在网上创建自己的内容目录，自己的格式等等。

没有一个协议是每个人在使用互联网或网络时都遵循的。但是后来开发了协议，对吧？比如 HTTP。

现在这是一种常见的做法。就像我有一个网络浏览器，对吧？我可以访问任何网站，并且我希望从提供网站的 Web 服务器向我返回某些内容。这些内容应该采用我的浏览器可以解释的特定格式，以便我获得信息。因此，每个 Web 服务器都有一个协议或标准。所以当我访问一个，

Netflix 或其他什么，它会向我发送回类似的，比如说，结构化或格式化或配置的数据，就像我去 Amazon.com 搜索产品一样。直到最近，这些工具调用才不是这种情况。因此，对于 AI 模型，每个人都独自将工具集成到他们的 AI 模型中，并

使用任何自定义代码、任何自定义提示、任何自定义内容，这意味着，Chris，如果你创建了一个工具调用代理，而我现在想使用你开发的一些工具，而我也有我自己的工具调用代理，我可能必须修改我的代理才能使用你的工具，或者你可能必须修改你的工具才能与我的

自主框架兼容。这种情况已经持续了一段时间了，我想这相当痛苦。是的。我们已经在许多剧集中多次谈到过这个总体想法。在我看来，它最终回到了 AI 领域随着时间的推移而成熟的概念。

我们已经多次谈到过 AI 不是一个独立的事物。它在一个由各种功能组成的软件生态系统中，其中许多功能都已标准化。我认为这是我们所处的这个领域又一个步骤，它正在快速发展，以其需要的方式自然成熟。现在我们有一个协议作为标准化的粘合剂，

可以被采用，每个人都知道可以期待什么。正如你指出的那样，与 HTTP 的类比很好，因为它，你知道，你有一个标准格式、标准序列化，你可以直接插入它。所以是的，从我的角度来看，这是一个好消息。是的，我认为我对这个问题有很多疑问，因为它直接影响到我工作的领域。的确。它引发了各种问题。所以

诸如，好吧，你如何构建 MCP 服务器？谁在创建 MCP 服务器？什么类型的模型可以与 MCP 服务器交互？来回传递什么有效负载？因此，可能值得深入研究其中的一些内容。首先，可能最好深入研究一下 MCP 系统是如何运行的，以及

然后这可能是有意义的。我们谈论的一些其他内容，例如可以与 MCP 服务器交互的模型。有一系列很棒的文章，我们将在节目说明中链接。我鼓励你们所有人查看这些文章。我们当然会发布

Anthropic 的主要博客文章，以及协议网站，还有一些博客文章。所以我发现我非常喜欢的一篇来自 Phil Schmidt，模型上下文协议概述。这篇非常有用。我认为它很有用，因为它可以帮助你形成一个心智模型

对于各个组件以及它们在一个使用 MCP 的系统中如何交互。所以，你知道，你可能在车里听着这个。我会谈谈这些主要组件，因为你可能没有看这篇文章。但是在使用 MCP 的系统中，有主机、客户端和服务器。

因此，主机将是一个应用程序，例如最终用户应用程序。假设这是我的代码编辑器，我的代码编辑器在引擎盖下以某种方式将使用 MCP 内容。我将进行编码。我将进行氛围编码。对。而且，你知道，询问各种事情，它将在

以某种方式并导致事情发生。这就是主机，即最终用户应用程序。有一个客户端位于主机应用程序内，它是一个 MCP 客户端，这意味着这个客户端可能是一个库，例如，它知道如何执行 MCP 操作。一个类比是

在 Python 中，我可以导入请求包，它知道如何向 Web 服务器来回执行 HTTP 调用。将客户端（可能是 MCP 客户端）想象成类似的东西，它存在于您的应用程序中，并且知道如何与 MCP 服务器（而不是 Web 服务器）来回执行此操作。是的。

然后服务器是您从客户端访问的外部程序、工具或资源。它们公开，就像我说的那样，通过这种标准化平台公开工具、资源、提示。

所以这是，你知道，这是一个客户端服务器架构。客户端位于主机内，主机是最终用户应用程序。然后是服务器，你可以，你知道，再次将其视为这个 MCP 服务器。现在我们可以，我们应该谈谈 MCP 服务器的作用，但是你可以将客户端视为调用工具，你知道，

你知道，发出资源请求，发出提示或提示格式或模板的请求。MCP 服务器正在公开这些工具、资源和提示。这说得通吗，Chris？是的。我的意思是，从某种意义上说，它本质上是一种新型的中间件，你知道，对于那些，我意识到这个术语可能不会引起所有听众的共鸣，但这是一种经典的术语。

连接服务和系统的不同方面的概念，以试图简化和标准化。所以，你知道，这是一种不同的说法。但是是的。是的，是的。我认为这是一个很好的方法。甚至 Phil 在他的博客文章中也有这种……

MCP 在中间作为调解员。所以我认为这是一个很好的类比。我们提到了工具、资源和提示。因此，在协议规范中，MCP 服务器可以公开工具、资源或提示。因此，工具可能是我们之前已经讨论过的 Kayak API 或调用数据库之类的东西。它们是

它是可以执行某些操作的函数，例如调用天气 API 来获取当前天气，或者像我提到的那样预订汽车，或者有一些 MCP 服务器可以帮助你在代码库上执行 GitHub 操作。这些是公开的工具或函数。这是 MCP 服务器可以公开的第一件事。第二件事是资源，你可以将其视为……

LLM 可以访问的数据集或数据源。所以，你知道，你想公开为配置上下文或数据集到应用程序的内容。然后是第三个提示。这些将是代理可以用来以最佳方式运行的预定义模板。假设你是

假设你的 MCP 服务器中的工具与问答和知识发现有关。你可能有一些预先配置的问答提示，LLM 可以使用这些提示，你知道这些提示对于某个工作范围或其他内容是优化的。你可以这样考虑。所以这些是在这里公开的工具、资源和提示。

在 MCP 服务器中。这说得通吗？是的。我知道你在那篇文章中特别指出的一件事，帮助我立即理解了这一点，那就是工具由模型控制，资源由应用程序控制，提示由用户控制。这对我来说很容易理解。所以是的，这是你对这个问题的很好的解释。是的，是的，绝对的。

然后在模型客户端或 MCP 客户端和 MCP 服务器之间的交互中，还有一些可能的事情。其中一件事是

应用程序需要了解如何连接和初始化与 MCP 服务器的连接，并打开该连接。这可以通过标准输入输出发生，这意味着你的服务器可能在本地运行，或者，你知道，作为应用程序的一部分，或者

或者它可能在远程运行，你可以通过服务器发送的事件来回与服务器交互。但是你还需要执行一种发现过程。我回想起旧的微服务时代，Chris，你可能还记得。

你知道，怀念或不怀念？两者都有，这取决于我当时在做什么。这让我想到微服务的发现之类的东西，就像，

嘿，在我的大型微服务环境中有哪些服务，我如何发现它们在哪里以及我在哪个域上连接到它们等等？它们是什么？所以这是一个完整的主题。我想它现在可能仍然是一个完整的主题。但是有一种发现机制，你可以……

在 MCP 服务器和 MCP 客户端之间实际公开工具列表或提示列表或资源列表。这些对于 AI 应用程序来说是可以发现的。所以它知道，嗯，

它能做什么。我可以预订汽车吗？不，我不能，因为这没有作为 MCP 服务的一部分公开，但是也许我可以做与 GitHub 相关的事情，或者也许我可以做数据库相关的事情，或者任何其他事情。好的，Chris。所以我们已经谈到了一些关于 MCP 客户端和 MCP 服务器的内容。当然还有更多内容可以在协议部分进行讨论和深入研究。

而且，你知道，我们在这里只是触及了表面。我们不会在播客上讲解整个协议。也许这对我们的听众来说是一种解脱。但是那里有一个完整的协议。我认为最好谈谈两件额外的事情，当我看到 Anthropic 发布 MCP 并谈论它时，我的脑海中立即出现了这两件事……

第一，我如何创建一个 MCP 服务器，或者我在哪里可以访问 MCP 服务器以连接到我自己的 AI 系统？然后第二，如果我不使用 Anthropic 模型，我可以使用 MCP 吗？这些是我的两个直接问题。我不知道，Chris，你是否看到，你知道，有各种各样的 GitHub 问题

GitHub 存储库正在出现，以及各种 MCP 服务器的示例。你有没有看到任何对你来说有趣的东西？对我来说最有趣的是，当我专注于 Python 的 AI 时，我非常专注于 Rust 的边缘。并且有一个模型上下文协议的官方 Rust SDK。所以这是

这自然是我所倾向的。是的，是的。所以有，并且有 Python 实现。我认为有很多编程语言实现。还有一些预先构建的示例服务器。我已经看到各种 Python 服务器了。

Blender，这是一种 3D 建模动画类型的东西。它是开源的。是的，完全正确。然后是 Ableton Live，这是一个平台，就像一个音乐制作平台。

有一些是针对 GitHub 的。我已经提到了这一点。Unity，游戏开发引擎。有一些可以控制你的浏览器，与 Zapier 集成，各种各样的东西。所以人们已经创建了许多这样的 MCP 服务器。同样，当你创建这个 MCP 服务器时，基本上你只需要创建……

本质上，你可以将其视为一个 Web 服务器，在其上具有各种路由，但这些是公开特定路由的特定路由……

通过特定协议公开特定类型的内容，这些工具、资源和提示。例如，通过服务器和事件来回进行 JSON 通信。但是，你知道，仍然遵循特定的协议。现在，如果你想创建一个模型上下文协议，你可以查看协议的所有具体细节。

协议服务器用于你的工具。我实际上想这样做。我们有一个内部工具用于执行文本到 SQL。这非常频繁。我经常称之为“仪表板杀手”应用程序。就像，你知道，每个人都创建了大量没有人使用的仪表板。而且，你知道，如果你可以只

连接到你的数据库并提出自然语言问题，那不是更好吗？所以我们围绕这个有一个完整的 API，你知道，你可以添加你的数据库模式信息和各种有趣的东西，并进行自然语言查询。所以就像，我不知道，在这个简单的 API 中有六七个不同的端点，它执行结构化数据交互。所以我想，好吧，酷。我们用 fast API 编写了它，这太棒了。所以它是一个 Web 服务器，并且，

它有一些端点，对吧，允许你进行 SQL 生成，或者允许你修改数据库信息，或者允许你执行此操作的各种元素。我们通过工具调用将其用作内部工具。所以我想，好吧，将它转换为我可以插入代理的 MCP 服务器需要什么？好吧，

你可以或多或少地从头开始这样做，只需遵循协议即可。但是人们已经开始提出一些非常好的工具。所以有一个叫做 FastAPI MCP 的东西。所以如果你搜索一下，这是一个 Python 框架，它基本上与 FastAPI 一起工作，并将你的 FastAPI Web 服务器转换为 MPC 服务器或 MCP 服务器。

而且它有效。所以，你知道，根据我的经验，我只是在我的 fast API 端点添加了几行代码，将我的 fast API 应用程序包装在这个框架中，然后……

运行应用程序，这同样是这个 fast API 应用程序。这立即可以作为 MCP 服务器被发现，这意味着如果我有一个 AI 系统，我们稍后会谈到这一点，如果我有一个可以与 MCP 服务器交互的 AI 系统，我的服务，即我们使用的文本到 SQL 系统，将可供该代理使用，并且

作为插入的潜在工具，你知道，我们将连接到的数据库。这说得通吗？是的。这是一个很好的解释。是的。所以，我确定，我的意思是，你提到了你谈到的这个 rust 客户端。我想类似的事情在很多便利函数中也是可能的，等等。我不太了解 rust，但我认为情况就是这样。

是的。而且它也是其中之一，我喜欢 MCP 从一开始就迅速获得如此多的语言支持的事实。我想你听我说过这个。我的一个不满是

至少从那里开始，很多 AI 的 Python 特性。我认为我在之前的剧集中说过，当你能够支持许多不同的方法来适应现实生活往往会带给我们的多样性时，这是一个成熟的问题。

很好。我喜欢 MCP 非常非常快地实现了这一点。所以是的，在我所处的世界中，你知道，将 MCP 作为一种协议，在边缘和数据中心都能工作，对我来说是一件大事。

是的，它实际上也适用于单节点。我的意思是，我们谈到了客户端服务器，对吧？但是你可以以这种嵌入式方式运行 MCP“服务器”，这种方式可以在桌面应用程序或单节点应用程序中被发现。所以当然没有。所以我想我的意思是，如果你正在使用 MCP，这是安全和身份验证相关的。是的。

这并不意味着你需要通过公共互联网连接到 MCP 服务器。这并不意味着所有这些都是未经身份验证的，或者你不能应用任何类型的安全措施。它的确意味着，例如，在我的例子中，

所以我现在已经将我们的文本到 SQL 引擎转换为 MCP 服务器。我可以将数据库连接插入到其中，连接到数据库，然后

但是根据我设置与数据库的连接方式，那里可能存在潜在的漏洞。如果我的 MCP 服务器没有任何身份验证，你知道，我把它放在公共互联网上，任何人都可以使用它。所以这里有两个级别的安全或身份验证或威胁防护相关。一个是安全。

实际连接级别的 MCP 服务器身份验证。另一个是，好吧，我仍然可以创建一个有漏洞的工具，对吧？或者拥有比它应该更多的代理。是的。我认为你提出的其中一件事我很喜欢的是，你知道，你可以在一台物理设备上运行，对吧？

并将各种系统联系在一起。就像如果你把它带到 AI 世界之外，并谈论我们常用的协议，你之前提到了 HTTP，你知道，protobufs 非常常见，等等，你知道，你，你可以，你可能正在使用所有这些我们多年来一直在使用的东西在一台设备上。这并不意味着它们是根据定义在许多不同的远程位置上的许多服务。它都可以收集在那里。呃，

并且它仍然具有价值，因为你仍然拥有这种标准化，并且各种供应商，无论是商业的还是开源的，都可以提供对此的接口，以使其更容易。因此，它变得更加可插入，但并没有紧密集成，这是一件好事，呃，架构。我认为 MCP 现在在这个领域真正给了我们这种能力。所以就像我说的那样，它，它，

它确实将成熟度提升到了更高的水平，你知道，你知道，从我们都在编写自定义粘合代码到现在的水平，嘿，我将标准化为 MCP，然后我们就开始了。是的。我认为类似地，人们可以将他们从使用方面的直觉转移过来，

Web 服务器进入这个世界。就像你不会仅仅下载 GitHub 上的一些代码，并期望在你本地运行该服务器时其中没有漏洞一样，你知道，MCP 也是如此，对吧？你肯定想知道你在运行什么，你知道，包含什么，你在哪里运行它，身份验证是如何设置的，等等，等等。同样，如果你要连接到其他人的 MCP 服务器，

就像，Chris，你正在运行一个，我想连接到它。

取决于我的用例，我可能非常想知道你的 MCP 服务器可以访问哪些数据？你是如何记录、缓存、存储信息的等等？它是多租户的还是单租户的等等？所以你可以运用你在我们所有人都在工作的环境中积累的一些直觉，这个环境涉及很多客户端-服务器交互，并将这些直觉带入这个领域。

好的，Chris，我们已经讨论了 MCP 的一般情况。我们已经讨论了

创建 MCP 服务器或其开发。这里有一件很明显的事情，那就是 Anthropic 发布或宣布了这个模型上下文协议，当然其他人也注意到了它。你看到 OpenAI 现在也支持 MCP，而之前他们有他们自己的 API 工具调用版本。

所以这里有一个更普遍的问题，那就是，我正在使用 LAMA 3.1 或 DeepSeek。我可以使用模型上下文协议吗？更一般地说，随着模型的激增，它们确实如此，人们真正考虑的是模型无关性，这意味着他们正在构建这样的系统，他们希望在其中切换模型，

我是否必须使用 Anthropic 或现在的 OpenAI 来使用 MCP？至少根据我们自己工作中发现的情况，这个问题的答案是，目前，有点是和不是。但将来，肯定会有很多灵活性。我的意思是，

Anthropic 在某种意义上领先一步，就像 OpenAI 发布某些东西一样，例如各种代理协议或工具调用之类的东西。他们有，你知道，这是他们发布的东西，对吧？一些他们一直在努力实现的东西，他们可能最初具有一定的优势。所以 Anthropic 显然一直在努力实现这一点。他们的模型、他们的桌面应用程序等等都很好地支持它。

其他人正在努力追赶，这其中包括开放模型。所以如果你考虑像 Lama 3.1 或 Quinn 2.5 或你正在使用的任何模型这样的东西，这些开放模型，没有什么可以阻止它们生成模型上下文协议错误。

同意。

协议交互，但你可能需要用许多模型上下文协议的例子和相关信息来加载该开放模型的提示，以便它能够生成该协议，这完全没问题。你可以这样做，并且

我们在内部做过，我也和做过的人谈过，也有一些博客文章等等。所以在这个意义上没有什么。这就是为什么我说“是”和“不是”。没有什么可以阻止你现在使用开放模型或 Anthropic 以外的模型来做到这一点。

你可能只需要用许多与 MCP 相关的、一致的例子来加载上下文窗口，才能为 MCP 服务器生成一致的输出。但将会发生的事情，类似于工具调用发生的事情。所以如果你记得，工具调用被发布了。每个人，进展，我这样看待它。就像，

人们发现有很多这样的例子。人们发现

模型通常可以遵循指令。所以在某个时候，人们开发了像 Alpaca、ChatML 等等这样的提示格式，这些格式具有通用的指令遵循形式。这些通常变得更加标准化。现在所有的训练集，好吧，不是所有的训练集，但许多像 Lama 和其他主要模型系列的训练集都包括训练

指令遵循示例。然后人们开始进行工具调用。然后人们开始开发工具调用特定的示例，将其包含在他们用于模型的数据集中，包括像 Hermes 和其他数据集中的工具调用格式。所以现在许多模型的训练数据集中确实包含工具调用示例。

现在我们将对 MCP 进行完全相同的进展。如果人们以某种方式执行，他们现在就可以使用开放模型进行 MCP。然而，随着 MCP 示例被包含在开放模型和其他封闭模型的训练数据集中，它将变得更高效。所以现在是和还不是。

是的，我同意。我的意思是，最终，会有不同的组织采取两种方式。有些只是说，让我们直接采用 MCP。其他的，比如像 OpenAI 这样的提供商，他们中的一些人会开源他们自己的方法来尝试竞争。

市场将会，你知道，人们会尝试一下。基于，你知道，提供易于使用的示例，将会有一定程度的竞争，并且可能会有某种东西比其他的更受欢迎，因为这就是我们在软件中反复看到的。还会有一个点，任何真正的竞争者，你都会有支持 MCP 和所有顶级竞争者的服务器，并提供每个竞争者的示例。

直到明确世界将要做什么。所以我想，是的，我认为 Anthropic 做得很聪明，他们领先一步，他们一开始就发布了一个高质量的视频

协议，有很多很好的例子和 SDK。这是一个非常聪明的举动，试图在游戏早期赢得市场。所以看看这个会很有趣，但我认为我试图说明的关键点，也是你明确说明的点是，世界已经以这种方式改变了，在某种程度上，就每个人现在都必须提升到拥有这种特定于 AI 的

中间件，它将模型与所有资源、资源和工具以及它需要的提示联系起来。所以我非常高兴看到它到位，我们将在接下来的几个月里看到一些变化。

是的，是的。好吧，我确实很想知道事情会如何发展。肯定有很多各种各样的工具包正在开发中，也许我可以分享其中几个。Chris，你可以分享 Rust 的那个，我想你还有另一个你想分享的 Rust 资源。但是我从 Python 世界中使用的那些，如果人们想探索这些，并且

更深入地了解一下。如果你是一个 FastAPI 用户，那么我绝对建议你看看 FastAPI-MCP。这就是我使用的框架。我在我的 FastAPI 应用程序中导入或插入了三行代码，并且

现在你最终可能想修改比这多一些的东西，但这将让你开始运行。对我来说有帮助的另一件事是实际上有一个 MCP 检查器应用程序。例如，在 FastAPI 中我喜欢的一件事是，你可以启动你的应用程序，你立即就会有 Swagger 格式的 API 文档。你可以去看看。

好吧，MCP 检查器可以帮助你检查你是否连接到你的 MCP 服务器，验证列出的工具，执行示例交互，查看哪些是成功的，查看从 MCP 服务器返回的内容，所有这些事情。所以这是一个非常有用的工具，它实际上也链接在 fast api-MCP 文档中，并且，

Chris，你提到了一个 Rust 客户端。我相信还有很多其他的。我很好奇，一般来说，你一直在探索这个 Rust 世界很多。我很想听到你一直在探索的任何资源，人们可能会感兴趣。

是的，我会提到一个。它与 MTV 分开，但我认为它对于边缘推理尤其有趣。它托管在 Hugging Face 上。它被称为 Candle，我认为就像烛台一样。

你可以找到它，它自称是 Rust 的最小 ML 框架。但这确实引起了我的注意，因为我经常倡导边缘上下文和边缘用例，

我们严格地将 AI 从数据中心中取出，并在世界各地做一些有趣的事情，这些事情可能是代理的，可能是物理的。随着我们的前进，Candle 是一件有趣的事情。如果我们幸运的话，我们将来可能会有一集，我们可以详细探讨一下。但是如果边缘和高性能的极简主义事物在这个上下文中让你感兴趣，

去 Hugging Face 查看 Candle。是的，是的。鼓励人们这样做。那里所有的甲壳类动物，不是吗……Rustaceans。Rustaceans。没错。是的，完全正确。不过它确实有甲壳类动物的主题，你说得对。是的，是的。好的，酷。我们一定会检查一下。正如我提到的，我们将在我们的……

在我们的节目笔记中分享一些链接到我们一直在讨论的博客文章、MCP 协议、Python 和 Rust 工具的链接。所以请查看一下，尝试一下，开始创建你自己的 MCP 服务器，并在 LinkedIn 或 X 或任何地方让我们知道你开始构建的酷炫 MCP 内容。我们下次再见。很高兴和你聊天，Chris。很高兴和你聊天，Daniel。

好了，这就是我们本周的节目。如果你还没有查看我们的 ChangeLog 时事通讯，请访问 changelog.com/news。在那里你会找到 29 个理由，是的，29 个理由说明你应该订阅。

我会告诉你第 17 个理由，你实际上可能会开始期待星期一。听起来好像有人得了星期一的病。changelog.com/news 还有 28 个理由在等着你。再次感谢我们 Fly.io 的合作伙伴、Breakmaster Cylinder 的节拍以及你们的收听。现在就到这里，但我们下次再聊。