从 tools.ts 到真实执行Gemini CLI 工具调用链路的接入配置读完packages/core/src/tools/tools.ts之后很多人的第一反应是去翻ToolInvocation、BaseToolInvocation、DeclarativeTool.buildAndExecute这些抽象想搞清楚 Read/Edit/Execute 到底怎么被确认、怎么被执行。但真正把 Gemini CLI 跑起来时会发现工具系统本身没问题卡住的地方往往在更前面一步模型请求发不出去或者 Base URL 配错导致工具调用根本回不来。这篇不重复源码结构分析只解决一件事——让 tools.ts 里那套确认流程和模板方法真正跑在真实模型通道上。TaoToken 在这里的角色很单纯提供 Key 和 Base URL工具定义、确认逻辑、执行流程一行都不用改。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿到 Key 后把 Gemini CLI 的模型认证指向 https://taotoken.net/api 即可。一、原问题与场景工具系统写好了模型通道没接上tools.ts 定义的是工具被调用时应该长什么样ToolInvocation接口规定了shouldConfirmExecute()和execute()的生命周期BaseToolInvocation把确认流程和 MessageBus 集成做成了通用实现Kind枚举和MUTATOR_KINDS把 Edit/Delete/Move/Execute 标成需要确认的副作用操作DeclarativeTool.buildAndExecute()则是一个模板方法——先build(params)拿到 invocation再execute(signal)真正执行。这套设计是自洽的。问题出在它上游Gemini CLI 要先向模型发一次请求模型返回一个 function callCLI 才会去构造对应的ToolInvocation。如果模型请求这一步的 Base URL 或认证没配对你会看到的现象是CLI 启动了输入指令后没有任何工具被触发或者直接报认证失败、连接超时。这时候去读 tools.ts 是读不出答案的因为工具系统压根没被调用到。所以接入配置的目标很明确让 Gemini CLI 的模型请求走通使模型能正常返回工具调用意图剩下的确认和执行交给 tools.ts 里已有的逻辑。二、TaoToken 前置只需要 Key 和 Base URLTaoToken 不介入工具系统也不改 Gemini CLI 的任何源码。它提供两样东西一个 API Key用于模型请求认证一个 Base URLhttps://taotoken.net/api。注意这个地址不要加/v1也不要带任何 UTM 参数。Gemini CLI 内部会按自己的路径规则拼接请求多写一层/v1会导致 404 或路径重复。获取 Key 的入口在官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 。登录后在控制台创建 Key复制出来备用。如果你需要确认当前可用的模型 ID可以在模型对话页面试一下或者查阅接入文档里的模型列表。三、可复制配置把 Base URL 和 Key 填进 Gemini CLIGemini CLI 的模型认证配置通常通过环境变量或配置文件完成。下面给出两种常见方式按你的使用习惯选一种即可。方式一环境变量适合临时验证export GEMINI_API_KEYYOUR_API_KEY export GEMINI_API_BASE_URLhttps://taotoken.net/api如果你用的是兼容 OpenAI 风格的变量名也可以写成export OPENAI_API_KEYYOUR_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api具体变量名以你当前 Gemini CLI 版本的文档为准核心是两点Key 填YOUR_API_KEYBase URL 填https://taotoken.net/api。方式二配置文件适合长期使用在 Gemini CLI 的配置目录下找到对应的 settings 文件写入模型通道配置。不同版本路径可能不同常见的是用户目录下的.gemini或项目内的配置文件。关键字段同样是{ apiKey: YOUR_API_KEY, baseUrl: https://taotoken.net/api }如果你使用的是 Claude Code 风格的配置则对应settings.json里的ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY如果是 Codex 风格则对应config.toml。本文聚焦 Gemini CLI按它的配置项填写即可。配置完成后重新打开终端或重启 CLI让环境变量生效。四、验证请求确认工具调用能正常返回配置好之后不要一上来就测 Edit 或 Execute 这种高副作用工具。先用只读工具验证链路因为Kind.Read和Kind.Search属于低风险MUTATOR_KINDS不包含它们确认流程最简单。第一步启动 Gemini CLI输入一个会触发 Read 的指令比如让它读取当前目录下的某个文件。观察两件事模型是否正常返回了工具调用意图CLI 是否进入了shouldConfirmExecute()的判断流程。如果 Read 能正常执行说明模型通道已经通了ToolInvocation的构建和执行链路是完整的。第二步测试一个需要确认的工具比如 Edit。此时你应该能看到确认提示因为Kind.Edit在MUTATOR_KINDS里BaseToolInvocation会走确认流程。确认后工具执行成功说明从模型请求到DeclarativeTool.buildAndExecute()的整条链路都通了。第三步如果确认流程里涉及 MessageBus 决策注意getMessageBusDecision()有 30 秒超时机制超时后会默认走ASK_USER。这是 tools.ts 里的既有逻辑和模型通道无关不要误判成接入问题。成功的结果是Read 直接执行Edit/Execute 弹出确认确认后正常完成。整个过程里 tools.ts 的工具定义、Kind 分级、确认类型都没有变化变的只是背后消耗 Token 的模型通道。五、本篇常见错排查错误一Base URL 多写了/v1这是最常见的。Gemini CLI 会自己拼接路径你填https://taotoken.net/api/v1会导致请求路径变成/api/v1/...而正确的基础地址是https://taotoken.net/api。去掉/v1即可。错误二Base URL 带了 UTM 参数从某些页面复制地址时可能带上?utm_source...之类的查询串。这些参数只用于官网统计不应该出现在 API Base URL 里。填https://taotoken.net/api就够了。错误三Key 没有生效检查环境变量是否在当前终端会话中生效。如果你是在一个终端里 export然后换了另一个终端启动 CLI变量不会继承。写入配置文件或重新 source 一下。错误四模型 ID 不可用如果你在配置里指定了某个模型 ID但该模型当前不可用请求会失败。可以先用默认模型或到模型对话页面确认可用模型。错误五把工具确认超时当成接入失败前面提到getMessageBusDecision()有 30 秒超时超时后走ASK_USER。如果你看到确认框延迟出现不一定是模型通道慢可能是策略引擎在等待。区分方法是看日志里是请求阶段慢还是确认阶段慢。错误六改了 tools.ts 去适配通道完全没必要。tools.ts 是工具系统的抽象层和模型通道解耦。接入配置只动认证和 Base URL不要动工具定义、Kind 分级或确认逻辑。六、语义一致接入之后工具系统照常运转把 Base URL 填成https://taotoken.net/api、Key 填成YOUR_API_KEY之后Gemini CLI 的模型请求就走通了。tools.ts 里的ToolInvocation生命周期、BaseToolInvocation的确认流程、Kind/MUTATOR_KINDS的安全分级、DeclarativeTool.buildAndExecute()的模板方法全部保持原样。Read 该直接执行还是直接执行Edit 该确认还是确认Execute 该走MUTATOR_KINDS还是走。如果你在接入过程中遇到认证或配置问题可以到 API Keys 页面重新确认 Key或查阅接入文档核对 Base URL 写法。需要验证模型是否可用时用模型对话页面快速测一下。长期在终端里做编码和 Agent 任务的话Coding Plan 会更合适。工具系统的源码分析解决的是它怎么设计接入配置解决的是它怎么跑起来。两件事分开看tools.ts 的抽象才不会被误当成配置问题。
