00:00:00人工智能领域最重要的技术之一就是MCP协议，但六个月后，它却成了我们的一大难题。
00:00:06最初，人们本地只运行两到三个MCP服务器，但MCP已经发展得远不止如此。
00:00:13现在，人们同时运行着数百个MCP服务器，拥有数千种工具，这已经成了一个巨大的问题。
00:00:20众所周知，Cloudflare首先注意到了这一点，随后Claude也发布了一篇关于这个问题的研究论文。
00:00:26但Docker实际上为此提出了一个解决方案，通过一种全新的使用方式，解决了MCP最关键的问题之一。
00:00:34这种动态模式可以节省大量token，加速你的代理，并实现我个人非常期待的全新自动化类型。
00:00:43因此，Docker发布了一篇文章，其中他们基本上敦促我们停止对代理环境进行硬编码。
00:00:50那么，他们这是什么意思呢？
00:00:51首先，我们到底信任哪些MCP服务器？
00:00:54第二，我们如何避免用可能根本用不到的工具定义来填充我们的上下文？
00:01:00举个例子，如果你有一千个工具，可能在一次聊天中只会用到两三个。
00:01:05第三，代理如何高效、自主地发现、配置和使用这些工具？
00:01:12但我希望你关注第二个问题：我们如何避免用可能根本用不到的工具定义来填充我们的上下文？
00:01:19举个例子，如果你有一千个工具，可能在一次聊天中只会用到两三个。
00:01:23Anthropic也发布了一篇关于此的帖子，我们曾在之前的视频中介绍过，并收到了许多希望实现此功能的人的积极反馈。
00:01:32而Docker也确实着手实现了它。
00:01:34在我们深入之前，你需要知道Docker早在这个问题出现之前，就已经为此搭建了整个基础设施。
00:01:41为此，你需要了解他们的MCP目录，其中列出了你可以真正信任的经过验证的MCP服务器。
00:01:48连接起来非常简单，你只需在Docker中连接它们即可。
00:01:52例如，我在这里连接了Notion，你可以看到我现在有两个服务器，而我的MCP客户端（大多数时候是Claude代码）只连接到Docker，然后Docker基本上管理着我所有的MCP服务器。
00:02:04所以这完全解决了我们到底信任哪些MCP服务器的第一个问题。
00:02:09现在，为了让我们的代理能够动态使用这些MCP，他们实现了一个MCP网关，该网关已经内置了工具，可以自主使用目录中的MCP服务器。
00:02:22所以本质上，你只需要连接一个MCP，而这个MCP就拥有它在目录中连接的所有工具的上下文信息。
00:02:31我已经连接了两个，它知道要将哪些工具定义实际带入上下文窗口。这样你的上下文窗口就不会变得臃肿。
00:02:39为了实现这一点，他们添加了一些新工具，包括MCP查找、
00:02:43添加和删除，这些工具基本上可以通过名称或描述在目录中查找MCP服务器。
00:02:48我会向你展示并指导你如何正确添加它们。
00:02:51举个例子，我正在使用我的GitHub MCP，我告诉它我想搜索一些有趣的仓库。
00:02:57在指定了仓库类型后，它实际上并没有直接调用工具本身，而是使用了Docker MCP服务器，该服务器再用正确的信息调用工具，并显然返回所有结果。现在，我希望你注意一件事，LLM返回了关于仓库的所有信息。它返回了链接、
00:03:17星标、
00:03:18描述，甚至知道这些仓库的发布日期。
00:03:21我希望你记住这一点，因为它在未来会很重要。
00:03:25现在，我们来看看动态工具选择。这是文章最重要的部分，也是我提到使用MCP服务器新方式时所指的内容。
00:03:35再次引用Claude的文章，他们讨论了Claude或任何AI代理如何使用更多token。一是上下文窗口中的工具定义，二是中间工具结果。这里我们谈论的是MCP工具调用实际返回的原始结果。因此，我们使用GitHub工具搜索到的所有这些细节都被返回到上下文窗口中。这就是为什么Claude知道关于仓库的每一个小细节，而我只想要仓库的描述和链接。这样一来，只需几次工具调用，比如在我的例子中，可能需要20次工具调用，整个上下文窗口就会被填满。这是他们在MCP网关项目中改进的一点，他们只提供真正有用的工具。例如，在我的例子中，一种可以节省上下文的方法是只给我搜索仓库工具，而不是GitHub MCP中包含的其他40个工具。因为在这个会话中，我只想使用搜索仓库工具。但同样，一旦你开始以这种方式选择工具，它也会开启一系列新的可能性。这就引出了代码模式。Cloudflare基本上概述了我们一直以来使用MCP的方式是错误的，这不是正确的方法。而Docker实际上是第一个实现这个新解决方案的公司。我对此进行了大量尝试。我必须说，我对执行结果感到非常惊讶。所以他们说，通过让代理能够直接使用MCP工具进行编码，这意味着他们获取工具并在代码中实现它们，他们可以为代理提供这些代码模式工具，以全新的方式使用工具。那么代码模式是做什么的呢？它创建一个支持JavaScript的工具，可以调用其他MCP工具。这可能看起来很简单，但我将向你展示的例子希望能澄清这一点。现在，在我们深入实现之前，还有其他一些需要考虑的事情。首先，由于这是代理编写的代码，显然它未经测试且不安全。因此，Docker计划让它在一个沙盒中运行。由于他们已经提供了Docker容器，这对他们来说几乎是显而易见的。这种方法最终提供了三个主要好处。首先，它完全安全，因为这是沙盒的主要好处。它不会对你的系统造成任何实际损害。然后是我们一直在讨论的所有token和工具效率，它使用的工具不必在每次请求时都发送给模型，模型只需要知道一个新的代码模式工具。因此，如果没有代码模式，如果你只使用，比如说这三个工具，并且它反复运行这些工具，那么那47个其他工具的上下文也会随着我们实际使用的三个工具一起发送。但是有了代码模式，代理会使用我们实际需要使用的工具编写自定义的“分析我的仓库”工具。每次它只引用那一个代码模式工具。通过这种方式，它通过不发送我们实际不需要使用的工具来节省所有其他上下文。然后我们还有状态持久性，其中卷管理数据在这些工具调用之间如何保存。它们实际上不会发送给模型。一个非常简单的例子是数据处理管道。所以我们假设我们想要下载一个数据集，数据集被下载并返回，但它实际上被保存到卷中，模型只知道它成功下载了。模型不会被五千兆字节的数据淹没。然后，如果我们想处理前10,
00:06:51000行，模型可以从存储数据的卷中读取并返回实际的摘要。通过这种方式，只有应该发送给模型的数据，例如最终结果、
00:07:01摘要、
00:07:01任何错误消息或问题的答案，才会传输给模型，并且上下文窗口保持干净。
00:07:07我之所以搜索这些GitHub仓库，是为了发现新的开源工具，以便在我的视频中使用。我通常的做法是使用“查找GitHub仓库”工具进行多次调用。我只是输入不同的关键词来搜索工具。所以我把这个需求告诉了Claude代码，它将所有这些不同的工具调用组合成一个单一的工具，可以根据我提供的任何关键词搜索仓库。你可以看到，即使在这里没有代码模式，Docker实际上也运行了多个查询。而这正是我想要解决的问题。它创建的工具叫做“多重搜索仓库”。
00:07:37创建工具后，它使用MCP exec工具实际运行了它。它通过六个不同的关键词搜索，基本上给我找到了29个独特的仓库，但结果直接在响应和终端中返回，这意味着所有结果都被返回到上下文窗口中。为了解决这个问题，我告诉它应该将所有内容写入文件，模型只需要获取仓库的描述即可。不需要提供任何星标或其他任何信息。它修改了工具，并将所有这些结果写入了我仓库中的一个文本文件，这样如果我想查找某个特定仓库的详细信息，我可以通过引用该文本文件来完成。现在，我希望看到一个能够保存和重用这个工具的方法。目前唯一的选择是手动将其保存为文件。之后，我让它搜索Notion MCP。连接后，我问它是否可以创建一个工具，将GitHub搜索结果直接输出到Notion，而不是使用文本文件。同样，使用代码模式，它确实创建了“GitHub到Notion”工具，允许我将结果粘贴到Notion中。
00:08:40运行之后，基本上有一些小问题我需要修复。但本质上，我现在在Notion中有了这个数据库。它基本上是硬编码的。所以无论我提供什么查询，它都会根据不同的字段将结果输入到这个数据库中。
00:08:55它甚至会包含日期，这样我就可以轻松筛选，只搜索我真正想要的结果。模型一次只能知道GitHub仓库的名称和描述。它不会得到其他任何信息，但其余信息都保存在这里。老实说，如果你浏览一下这个目录，你至少会有一个关于如何将MCPs串联起来创建这些出色工作流的想法。同时，你还在节省token并保持你自己的AI代理的性能。开始使用它们真的非常容易。你需要更新你的Docker版本。但如果你还没有，它们可能在测试版功能中被禁用。所以请确保这个Docker MCP工具包已启用。
00:09:34除此之外，你将拥有你的目录，并且这些新功能默认是启用的。所以你所要做的就是连接你的客户端，然后你就可以开始使用了。我们的视频到此结束。如果你想支持本频道并帮助我们继续制作此类视频，你可以使用下面的“超级感谢”按钮。一如既往，感谢你的观看，我们下期再见。