我对 MCP 的认知错了

MCP 服务器通常专注于集成单个服务，为代理提供新的工具和/或上下文。但如果我们换个视角，打破一些熟悉的模式，把 MCP 变成代理可以按需使用的一组新能力呢？

需要明确的是——围绕单个服务构建的 MCP 和 CLI 在许多用例中运行良好。接下来要讲的是另一种方法，其范围远不止于直接集成。无论你觉得它是否有用，它都可能改变你对程序员在 AI 时代角色的看法。

模型上下文协议背后的概念

如果你还没接触过：模型上下文协议（Model Context Protocol，MCP）标准化了 AI 代理（如 ChatGPT、Claude、OpenCode 或 Amp）连接到外部系统的方式。该协议的功能不止于此，但其核心用例很简单：传递 JSON Schema，描述代理可以选择哪些工具，以及用什么参数调用它们。

在实践中，一个现有的 API（比如 Resend 的 API）可以被转换成一套针对 AI 代理优化的工具，让它们能够发送邮件、管理联系人、发起营销活动等。

与原始 API 相比，MCP 工具提供了 LLM 默认缺乏的上下文：描述和提示，增加了操作成功的概率，或者在操作失败时帮助代理恢复。下面是一个场景，代理使用原始 API 发送邮件时因缺少属性而卡住。而在 MCP 场景中，它会得到关于如何从错误中恢复的清晰提示。

当代理使用像 GitHub 这样的知名服务时，它已经知道接口了。在这种情况下，额外的上下文价值不大。但对于不那么流行的服务，代理要么失败并从错误中学习，要么必须先找到最新的文档来学习如何使用。

对于编码代理来说，CLI 工具通常比 MCP 更方便：它们原生访问 bash，并通过 bash 访问它们控制的整个设备。这对于单个用户和简单集成来说效果很好，但一旦你超出单用户环境或转移到远程，这种优势就会消失。所以整个“MCP vs CLI“的争论其实没有意义，我们谈论的是不同的用例。

了解这些之后，让我们拓宽视野，思考超越集成之外的 MCP。

超越服务集成

为了探索 MCP 的真正能力，我们来看看 Kody——一个由 Kent C. Dodds（及贡献者）构建的个人助手，专注于通用能力而非直接集成。

Kody 运行在 Cloudflare 上，可以远程连接到任何支持 MCP 的代理框架，也可以在后台按计划或响应事件工作。实际上，这个助手在用户所在的地方都可用：OpenAI Codex、Anthropic Claude Code，或任何自定义 UI。

其核心只有两个工具：

• search：查找并/或加载 Kody 的能力
• execute：在 Kody 的运行时内运行 TypeScript 代码，直接访问其所有功能。

它们共同让代理能够探索可用的能力，包括在之前交互中创建的能力，并在脚本中使用它们。听起来很强大。但为什么呢？

嗯，让一个典型的代理“准备一份每周邮件报告“，它需要执行一系列操作才能完成。而由于 LLM 是非确定性的，每一步都可能增加出错的风险！

Kody 选择了不同的路径。它编写并测试一个脚本，一次性获取所有消息，然后将其保存为一个包。 此后，它只需重复使用这个包。由于代码基本上是确定性的，结果保持一致，除非脚本调用了 LLM（例如，来总结消息），或者包含其他引入随机性或产生不可预测结果的逻辑。

无论如何，这种方法要可靠高效得多。

代码执行只是冰山一角。让这个 MCP 与众不同的是它的原生组件，而且这些组件的通用化程度远超典型的集成。

注意：下面的内容不仅对 MCP 重要，对于一般性地与 AI 代理协作也很重要。

因此，与其用每个具体功能来思考，我们应该提升思维层次，转向系统设计和产品工程。这将我们的注意力从 AI 已经轻松处理的细节上移开，转向塑造代理运行环境的高层概念。当然，这不会凭空而来：它需要对用户上下文和可能用例的深刻理解，远远超出描述某个特定功能的简单需求文档。

让我们通过更仔细地审视 Kody 的架构，来考虑几个例子。

#1 包

如前所述，助手可以每次逐步执行每个操作，也可以编写脚本保存以便以后重用。

在下面的例子中，用户请求代理提供一个播客，突出最重要的新闻。其逻辑随后被设计、测试并存储。甚至可以与他人共享！从此以后，每当用户请求播客时，代理只需选择正确的包并执行它。

从技术角度看：

• D1 数据库跟踪包及其详细信息。
• Cloudflare Artifacts 保存原始的、版本化的源代码。
• Cloudflare KV 存储包的即用型捆绑包。
• Cloudflare Workers 提供代码运行的隔离环境。
• Cloudflare Durable Objects 在需要时保存数据并支持实时会话或长时间运行的服务。

包是利用 AI 在编程方面日益强大的能力的一种巧妙方式，让代理聪明地工作，而不是费力地工作。我无需提这节省了大量令牌，也就是你的钱。

#2 集成

将代理与外部应用和服务连接的方式是 Kody 的另一个组件，也是我们如何转变编程思维的一个例子。Kody 没有构建与通讯工具、邮件、日历、问题跟踪器、地图或各种设备的专用集成，而是提供了 OAuth、API 凭证、OpenAPI 规范、外部 MCP 服务器和私有网络连接器的通用原语。然后它将它们的功能暴露给“execute“工具的运行时。

这使得代理足够独立：当它面临需要它没有的集成的任务时，它只需创建一个，要求用户登录或安全地提供 API 密钥。

下面的例子展示了两种场景：

• 一种场景中，缺少集成让代理完全停滞。
• 另一种场景中，代理配置了一个连接并围绕它构建了可重用的行为，只需请求用户帮助完成授权。

从技术角度看，Kody 拥有可重用的认证机制，因此代理不必每次从头重建一切。相反，它专注于提供特定于提供商的配置，并决定如何处理由此产生的连接。下面的图表展示了这一点。

这就是我们生活的现实。我们很多人还记得构建 OAuth 集成需要几个小时。现在代理可以即时生成它们，只需要一点引导。意识到这一点，让 Kent 的助手从一个需要手动构建集成的助手，变成了一个自己构建集成的助手！

这里还有一个额外的好处：助手通常会随着它运行所依赖的 LLM 的每一次升级而自动改进。 而且“加速正在加速“，你可能已经注意到了。

#3 任务和工作流

纯粹反应式的代理——只在被提示时才行动的代理——仍然有其用途，但它们开始显得过时了。如今，代理不仅应该回应我们说的话，还应该在我们不在的时候行动。

有了 Kody 可以构建的包，后台任务自然就浮现在脑海中。毕竟，一旦代码被编写出来，它就可以自动运行，完全不需要 LLM 参与。而且由于任务和工作流是 Kody 的原生能力，它可以自己管理它们。

从技术角度看：

• D1 跟踪任务计划、工作流状态和执行情况。
• Cloudflare Artifacts 保存任务和包的源代码。
• JobManager Durable Objects 在计划任务时唤醒 Kody。
• Workflows 管理持久化运行，包括等待和重试。
• Workers 执行任务包和内联工作流代码。
• StorageRunner Durable Objects 在运行之间保存任务数据。
• 执行后，D1 记录结果，对于重复任务，记录下一次运行时间。

下面是任务和工作流的区别：

简而言之，任务将一个一次性或重复性计划与要执行的代码配对，代码可以是独立的片段，也可以是包拥有的任务入口。它们非常适合像发送后续邮件或生成报告这样的自动化。

而工作流则依赖 Cloudflare Workflows 来管理单个持久化执行。当工作需要在等待、超出原始请求继续、避免重复运行或在失败后重试时，它们就派上了用场，因此它们很自然地适合多步骤任务。

#4 记忆

代理需要记忆，这样它们才能在不每次都被告知所有细节的情况下行动。虽然代理记忆仍然是一个开放问题，但一些有前途的策略已经存在，比如 Quarq Agent 和 Observational Memory，它们可以结合并取得令人印象深刻的结果。

Kody 保持更简单：一个搜索工具，底层使用混合搜索，结合了词汇匹配和向量搜索，再加上一些过滤和重排序。

在实践中，你可以要求代理记住某事，它会准备一个新的记忆条目候选，并与现有记录进行比较。基于此，代理决定是存储新记忆还是更新现有记忆。

由于记忆只是另一种能力，它可以很容易地与其他操作结合，包括通过包执行的操作。比如，我们告诉助手我们最喜欢的地方，稍后，我们可以直接要求去上次喜欢的那家餐厅的方向。

值得注意的是，“代理记忆“不一定像人类记忆那样工作。根据实现方式的不同，代理可能意识不到自己知道某事，即使直接询问，也可能无法检索到相关记忆。这可能导致虚构或性能下降。

#5 值

某些代码片段、包应用、任务或工作流需要稳定的配置，可以在以后再次读取。Kody 提供了值（Values）能力，用于在会话、应用或用户的上下文中存储小型的、可读的设置。

与记忆不同，值是按名称确定性检索的，而不是根据含义或模式匹配按上下文检索。它们主要用于非敏感配置，例如时区、选中的工作空间、报告格式或默认项目。

例如，如果一个包包含 UI，一个应用作用域的值可以在会话之间保存用户的设置。

这个简单的原语可以支持许多有用的场景。例如，一个后台任务可以定期更新一个用户作用域的 currentCity 值。然后，一个包或代理可以在回答诸如“附近哪里有好吃的？“这样的问题时显式地检索它。

值最适合保存小的最新配置值。位置历史或更大的记录集合则属于存储的范畴。

#6 存储

一个包、任务、服务、应用或执行可能需要自己的私有数据库来保存运行时状态和累积的记录。

Kody 不是将这些信息表示为 Kody 中央 D1 数据库中的单个值，而是为运行时分配一个 StorageRunner Durable Object。

从技术上讲，Kody Storage 是一个绑定到单个运行时身份的私有、持久化数据库。执行代码的 Worker 是临时的；它写入的数据会持久化。

#7 远程连接器和外部 MCP 服务器

如前所述，Kody 是一个 MCP 服务器，暴露了两个工具，search 和 execute，以及一组能力。充当 MCP 客户端的代理可以连接到 Kody 并与这些工具交互。但 Kody 也可以将其能力注册表扩展到包含外部系统提供的工具。

它支持两种连接模型：

• Kody 可以自己充当 MCP 客户端，并通过 kody.mcp 接口访问外部 MCP 服务器的工具。
• 本地进程可以连接到 Kody，并通过 kody.remote 接口暴露它们的工具。

在这两种情况下，额外的工具都成为用户隔离的 Kody 环境的一部分。代理可以通过 search 发现它们，并从 execute 中调用它们，就像 Kody 的内置能力一样。

要点

将视角从一个连接器转变为一个能力层，使得 MCP 服务器的概念更加灵活，并且在很多方面真正地适应 AI 原生。Kent 没有通过旧的编程习惯（一切都需要手工构建）的视角来看待代理的能力，而是几乎利用了 AI 今天能做的所有事情，创建了一个克服了典型代理面临的许多限制的助手。最重要的是，他的助手会随着底层模型的改进而改进——这在我们设计 AI 系统时值得牢记。

以下是几个值得带走的要点：

• 代码模式： 推理模型可以生成有用的代码。不要强迫每个任务都通过预定义工具完成，而是在适当的时候给代理一个沙盒运行时。当需要稳定的接口、权限和可审计性时，专用工具仍然很重要。
• 确定性： LLM 行为可能会变化，尤其是在使用采样时。不要试图完全消除这种可变性，而是在生成和评估时利用它。代理可以生成一个实现，测试它，然后修改它。一旦验证通过，运行该实现通常比每次重复完整的推理过程更快、更便宜、更可靠。
• 泛化： 与其自己实现每个操作，我们可以塑造环境，让代理创建并执行特定于任务的操作，同时代码强制执行约束并确定性地验证结果。
• 原语： 围绕一个狭窄用例设计的组件会限制代理。偏好那些具有清晰契约的小型能力，能够支持多个用例，同时不会变得模糊或不安全。
• 组合： 当代理的接口、权限和故障模式明确时，它们可以组合原语。我们不需要自己构建每个工作流，而是需要给代理提供可重用的组件，让它们能够安全地组装成新的工作流。
• 控制： 代理自行生成能力会带来合理的工程风险。答案不是忽视它们或停止探索，而是通过沙盒化、最小权限、验证、可观测性、批准关卡和回滚来约束执行。
• 验证： 确定性执行并不能保证正确的结果。验证必须测试显式的不变量、权限和预期效果。如果成功无法形式化，则使用评估、人工审查或有限的不确定性。

就是这样。我对 MCP 的认知错了。我曾经认为它们只是连接器，带有一丝协议本身的额外功能，并假设整个能力层必须直接绑定到主系统。

我很好奇你对这一切的看法，所以欢迎留言，如果你觉得有用，也可以转发。