goose 如何使用 Code Mode 降低启用大量扩展时的上下文开销【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose在 goose 中启用多个扩展MCP 扩展时传统工具调用方式会把所有已启用扩展的工具定义都放进每一次 LLM 调用里每个工具都带有描述用途、参数和返回值的定义扩展一多这些定义就会持续占据上下文窗口挤压对话本身的内容。Code Mode 是 goose 提供的一种替代方式它用 3 个元工具meta-tools代替成排的工具定义让 LLM 按需发现工具、用 JavaScript 代码批量调用工具从而降低上下文开销。这篇文章基于 goose 文档给出开启 Code Mode 的完整操作路径和验证方法。前提条件goose v1.17.0 或更高版本Code Mode 在该版本引入见官方博客 Code Mode MCP in goose当前构建包含 Code Mode 扩展——它是内置平台扩展默认未启用需要手动打开使用扩展指南中将其列为 when included in the current build 的平台扩展。Code Mode 与传统工具调用的差异官方 Code Mode 文档将两种方式做了直接对比方面传统 MCP 工具调用Code Mode工具发现所有已启用扩展的工具全部暴露给 LLMdeveloper.shell、github.list_issues、slack.send_message等可能非常多只暴露 Code Mode 扩展的 3 个元工具list_functions、get_function_details、execute_typescriptLLM 用它们按需发现其他扩展的工具工具调用顺序调用每个结果都要回到 LLM 后才能进行下一次调用多个工具调用在一次执行中批量完成中间结果在本地链式传递上下文窗口每次 LLM 调用都包含所有已启用扩展的工具定义每次 LLM 调用只包含 3 个元工具定义加上本会话中已发现过的工具定义适合场景1–3 个扩展、只用 1–2 个工具的简单任务5 个以上扩展、步骤明确的多步骤工作流也就是说开启 Code Mode 后工具定义从全部常驻变成用到才加载这是它降低上下文开销的直接原因。注意两处文档表述差异上述元工具名称取自当前官方文档2026 年 2 月的博客 8 Things You Didnt Know About Code Mode 中将这三个元工具写为search_modules、read_module、execute_code应以当前文档的命名为准。启用 Code Mode 扩展方式一goose Desktop点击左上角侧边栏按钮打开侧边栏点击Extensions将Code Mode的开关打开。方式二goose CLI运行配置命令goose configure选择Toggle Extensions用空格键切换code_execution实心表示启用回车提交。官方 Code Mode 扩展文档给出的示例输出┌ goose-configure │ ◇ What would you like to configure? │ Toggle Extensions │ ◆ Enable extensions: (use space to toggle and enter to submit) │ ● code_execution └ Extension settings updated successfully上面两种方式修改的是新会话的默认扩展。如果只想在某个会话中临时启用可以在启动会话时用--with-builtin参数用法见 使用扩展指南goose session --with-builtin code_execution该扩展只对当前会话生效不会改变默认设置。验证 Code Mode 已生效Code Mode 扩展文档给出的验证方式是让 goose 执行一个需要多次工具调用的任务例如文档中的原始提示词Create a LOG.md file with the current git branch, last 3 commits, and the version from package.json判断 Code Mode 是否生效看工具调用的呈现形式未启用时会看到多次顺序的工具调用developer__shell一次执行git branch再一次执行git log……每次结果回到对话后再进行下一步启用后文档示例中 goose 只发起了Execute Code类型的工具调用代码形如import { shell, text_editor } from developer ...多个命令在同一次执行中批量完成中间结果不经过 LLM。上面 LOG.md 示例的输出属于文档示例你的环境中工具名和文件路径会随任务不同而变化判断标准是看到一次 Execute Code 调用代替了多次单独工具调用。博客中的批量示例同样说明了这一点git branch、git status、git diff、cargo test四条命令被合并进一次执行import { shell } from developer; const branch shell({ command: git branch --show-current }); const status shell({ command: git status }); const diff shell({ command: git diff }); const tests shell({ command: cargo test });上下文开销的实际收益参考博客《8 Things You Didnt Know About Code Mode》作者在同一个任务修复 goose 自身的一个 bug 并提交 PR上分别用启用/未启用 Code Mode 各跑了一次报告的结果为指标启用 Code Mode未启用Total tokens23,33933,648Input tokens23,12833,560即该次实验中启用 Code Mode 少了约 30% 的 token。这是单一作者、单一任务的一次实验数据使用 Claude Opus 4.5 模型只能作为量级参考不应视为固定预期。文档解释的开销节省来自两部分工具定义不再全部常驻上下文以及批量执行减少了往返轮次。适用边界与限制以下内容直接来自文档决定 Code Mode 是否适合你的扩展组合扩展数量与任务形态官方对比表明确传统方式适合 1–3 个扩展的简单任务Code Mode 适合 5 个以上扩展和多步骤工作流。只有 1–2 个扩展、任务是单次工具调用时博客给出的建议是直接用普通工具调用Code Mode 的发现步骤先发现模块、再读接口、再写代码、再执行反而增加开销。仅支持文本结果Code Mode 只支持工具结果中的文本内容图片、二进制数据和其他内容类型会被忽略。如果你的核心扩展依赖返回图片Code Mode 不适用。模型行为有差异Code Mode 要求模型能写出语法正确的 JavaScript、按import { shell } from developer这类模式导入工具、在写代码前先调用发现类元工具、并在执行失败后读错误重试。博客指出不同模型在这些能力上表现不一效果不佳时可换用代码生成能力更强的模型。Code Mode 没有移除 MCP它底层仍然通过 MCP 协议连接你的扩展只是把如何调用工具从逐个工具定义改为程序化接口扩展的安装、配置方式不变。下一步如果你的 goose 是通过 ACP 接入编辑器如 Neovim可以在启动参数中同样带上内置扩展博客给出的配置行是args { acp, --with-builtin, code_execution,developer }用法与goose session --with-builtin一致扩展的增删、会话中途切换等通用操作见 使用扩展指南更深入的理解可阅读 Code Mode 机制文档与 Code Mode 扩展文档。【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考