代码模式并不取代MCP（它实际的功能）

Source: Dev.to

“拨号时代”的代理工作流

有一天我们会告诉我们的孩子们，过去必须等代理响应，但他们不会了解那个时代，因为他们那一代的代理会快得多。我和 Nick Cooper（OpenAI 的 MCP 指导委员会成员）以及 Bradley Axen（goose 的创作者）开玩笑地聊起这件事。他们都笑了，因为他们明白我们当前这套“拨号时代”的代理工作流有多么笨拙和实验性。

模型上下文协议 (MCP)

MCP 通过引入一个新常规——将代理连接到日常应用的能力——推动了进步。不过体验并不完美——我们仍在探索如何在这些工具的强大功能与模型本身的技术限制之间取得平衡。

快速提示： 在 goose 中我们把 MCP 服务器称为 extensions。从现在起我会使用 extensions 这个词。

为什么人们写下 MCP

许多用户会遇到卡顿或不稳定的情况，往往在不自觉中陷入了 “工具臃肿” 的陷阱。为帮助你获得良好的使用体验，有大量的 “不要这样做” 建议。例如，goose 团队和高级用户遵循的最佳实践是：

不要一次打开太多扩展。
否则，会话会更快退化，幻觉增多，任务执行变慢。

“扩展太多”问题

首次使用的用户常常因为兴奋而一次性打开一堆扩展：

“这太酷了。我需要它来访问 GitHub、Vercel、Slack、我的数据库……”

实际上，代理的上下文窗口会被 数百个令牌的工具定义 塞满。每一次工具调用都会迫使模型将所有这些定义保留在其 “活动记忆” 中，导致：

• 明显的性能下降
• 幻觉增加
• 错误让用户觉得平台还未准备好进入正式使用阶段

动态扩展 – 首次尝试缓解

goose 团队最初通过添加 动态扩展 来应对这一问题，这些扩展会让大多数工具保持休眠状态，直到代理明确需要它们。虽然这是朝着效率迈出的巨大一步，但它仍然是一个相对隐藏的功能，许多普通用户很少发现。

我花了很多时间观察人们在使用大量活跃扩展时的操作，看到他们在浪费代币去调用根本没有使用的工具，我不禁皱眉。

Source: …

代码模式 – 解决扩展臃肿

代码模式 将限制工具的想法更进一步。我最初是在 Cloudflare 的一篇博客文章中了解到它的，文章提出代理应该 编写 JavaScript/TypeScript 来决定调用哪些工具，然后在一次执行中运行这些逻辑，而不是一次一步地调用工具。

工作原理

1. 仅提供三个基础工具：

   • search_modules
   • read_module
   • execute_code

2. 代理在运行时 发现 所需内容，并编写自定义脚本，将这些操作链式组合在一次执行中。

当代码模式的概念在社交媒体上流传时，很多人声称它是 MCP 的替代品。事实并非如此。 代码模式仍然在底层使用 MCP——它发现并执行的工具仍然是 MCP 工具。

类比：

• HTTP 是使通信成为可能的底层协议。
• REST 是建立在 HTTP 之上的架构模式。

同理，MCP 是标准化代理如何连接工具的协议，而 代码模式 是代理更高效地与这些工具交互的模式。在 goose 生态系统中，代码模式被视为一个 MCP 服务器（扩展）。

代码模式作为扩展

goose 将代码模式本身做成了一个名为 代码执行扩展 的扩展。启用后，它：

• 包装你的其他扩展
• 将它们暴露为 JavaScript 模块
• 让 LLM 只看到三个工具，而不是数十个

示例脚本

import { shell, text_editor } from "developer";

const branch = shell({ command: "git branch --show-current" });
const commits = shell({ command: "git log -3 --oneline" });
const packageJson = text_editor({ path: "package.json", command: "view" });
const version = JSON.parse(packageJson).version;

text_editor({
  path: "LOG.md",
  command: "write",
  file_text: `# Log

Branch: ${branch}

Commits:
${commits}

Version: ${version}`
});

Source: …

实验：代码模式 vs. 非代码模式

为了真正了解代码模式是如何工作的，我进行了一个比较 有 与 无 代码模式的实验。

• 模型： Claude Opus 4.5

• 已启用扩展： 8 个不同的扩展

• 提示：

  “创建一个 LOG.md 文件，包含当前 git 分支、最近 3 次提交以及 package.json 中的版本”

无代码模式

• 代理执行了 五次独立的工具调用 来收集数据并写入文件。
• 由于所有八个扩展的完整定义都已加载，任务消耗了 总上下文窗口的 16 %。
• 这说明了标准工作流的可扩展性问题：加载的工具越多，系统越不稳定，越容易出现故障。

有代码模式

• 代理使用其发现工具找到所需模块，并编写了一个 单一、统一的 JavaScript 脚本 来处理整个工作流。
• 只使用了 上下文窗口的 3 %。

结果： 使用代码模式后，我可以在模型性能下降或出现幻觉之前进行更长时间的会话，因为不必承载过多工具的负担。

要点

• Code Mode 并不一定让任务执行得更快；它的主要好处是 上下文窗口效率。
• 通过减少模型必须在活动内存中保持的工具定义数量，Code Mode 延迟性能下降 并 降低幻觉。
• 它是 基于 MCP 的模式，而不是替代品。

随意在你自己的 goose 会话中尝试 Code Mode，看看你能在单个上下文窗口中容纳多少内容！

代码模式概览

“代码模式帮助我们在构建能够扩展以处理所有工具而不崩溃的代理方面迈出一步。” – MCP 团队

为什么代码模式可能感觉沉重

• 额外的往返 – 大语言模型必须发现合适的工具，生成 JavaScript，然后执行它。
• 开销 vs. 直接调用 – 对于只需要一两个工具的任务，编写和运行代码可能比直接调用工具更费事。

代码模式发挥优势的情形

• 启用了众多扩展 – 它可以协调庞大的工具箱。
• 多步骤编排 – 需要多个顺序操作的复杂工作流。
• 长时间会话 – 随时间保持连贯性。

不适合使用的情形

• 你仅有 1‑2 个扩展。
• 任务是 单步。
• 速度更重要，而非上下文的持久性。

最近的改进（Goose v1.17.0 – 2025年12月）

展望未来

团队正在持续改进代码模式，使其更加用户友好且功能强大。随着平台的发展，代理将变得越来越无限制，摆脱对简单任务“配额化”工具的需求。

入门指南

1. 在 Goose v1.17.0 或更高版本中 启用 “代码执行” 扩展。
2. 加入 我们的 Discord，分享你的使用体验并向社区学习。

准备好尝试代码模式了吗？动手体验一下，看看它如何改变你的工作流！