1. 项目全貌HagiCode 为什么要做多模型集成先说说背景。我一直在维护一个叫 HagiCode 的个人开发工具项目定位很简单一个跑在终端里的 AI 编程工作台把代码补全、仓库级理解、自动化测试生成、提交信息润色这些琐碎但高频的活儿统一收口到命令行里。早期版本只接了一家模型供应商用起来倒也顺手但随着项目越做越深入问题开始变得扎眼——单一模型的瓶颈太明显了代码生成质量、上下文窗口长度、响应速度、成本控制全都被一家绑死。最难受的是不同模型在不同任务上各有所长有的擅长长仓库的全局理解有的在单文件重构上又快又准有的在测试用例生成上非常稳。把它们全塞进一个工具里让用户按场景自由切换这才是 HagiCode 该有的形态。所以这个版本的核心工作就是两件事第一把 GLM 系列模型完整接入 HagiCode 的模型层第二让 HagiCode 能够以 Gemini CLI 作为前端交互入口跑通一套“多后端模型 标准 CLI 工具”的完整链路。也就是说你可以用 Gemini CLI 的交互体验背后实际调用的是 GLM 的模型能力也可以在同一个工作流里随时切换到 Gemini 官方模型HagiCode 负责路由、适配和调度。这听起来不算复杂但真正落地的时候牵涉到的东西不少API 协议差异、工具调用格式转换、上下文窗口语义对齐、流式输出的兼容处理、鉴权体系对接、模型能力映射……每一个环节都可能踩坑。这篇文章把整个集成过程的思路和实现细节梳理一遍给同样在做多模型工具集成的朋友一个可参考的路径。2. 技术选型为什么偏偏是 GLM 和 Gemini CLI2.1 GLM 系列模型的定位与优势在确定接入 GLM 之前我对比过市面上主流的开源和商用模型。选择 GLM 有几个很现实的原因。首先是它对开发者友好。GLM 的 API 形态走的是 OpenAI 兼容协议base_url 指向智谱开放平台的 v4 端点请求结构和字段命名与业界主流保持一致。这意味着在代码层面做模型适配时不需要额外写一套协议转换层绝大多数 HTTP 客户端和 SDK 可以直接复用。对于 HagiCode 这种需要同时维护多套模型的工具来说协议兼容度直接决定了接入成本。其次是 GLM 在代码类任务上的能力已经够用。以 GLM-4.5 系列为例长文本理解能力在同级别模型里属于第一梯队128K 的上下文窗口对于中等规模代码仓库的全局分析、跨文件重构来说完全够用。它的工具调用function calling机制也比较成熟支持并行调用多个工具这在自动化代码修改场景里非常关键——比如同时读取多个文件、对比不同实现版本、批量执行静态检查这些操作如果能并行发出效率提升是很明显的。还有一个容易被忽视的点GLM 的定价策略对工具类产品很友好。HagiCode 的使用场景是高频小请求单次调用消耗的 token 不算多但如果一天跑几十次甚至上百次自动化任务成本就会拉开差距。GLM 的输入输出价格相比同规格的国外模型有显著优势而且平台经常有面向开发者的体验活动新用户会送 token 额度实际跑下来成本压力小很多。2.2 Gemini CLI 的开放生态与工程优势Gemini CLI 是 Google 开源的一款终端 AI 编程工具基于 TypeScript 编写采用 Apache 2.0 协议。它最大的特点不是“又一个 AI 编程助手”而是它的协议设计思路和对外开放程度。Gemini CLI 的架构核心是模型无关的。它内部定义了一套标准化的工具调用规范和上下文管理机制对外则通过环境变量来指定模型端点。默认情况下它连接 Gemini API但你完全可以通过配置环境变量的方式把请求转发到任何兼容端点。这种“预设一个默认目标但保留完全自定义能力”的设计给了我很大的发挥空间。另外Gemini CLI 的交互设计也值得借鉴。它支持多模态输入粘贴截图让它看 UI 问题或者把设计稿直接丢进对话里这对前端开发场景非常有用。同时它的文件编辑能力做得很细支持逐块 patch 的精准修改模式在代码审查场景下能显著减少误修改。更重要的是Gemini CLI 的原生模型 Gemini 3 在复杂编程任务上表现确实强尤其是算法实现、架构设计、调试推理这类高难度场景。把 GLM 和 Gemini 放在同一个工具里用户可以在日常简单任务上走 GLM 节省成本碰到硬骨头切到 Gemini 冲能力这是最理想的搭配。2.3 多模型架构的整体设计思路整个集成架构分三层。最底层是模型接入层封装各家 API 的统一客户端GLM 走 OpenAI 兼容协议Gemini 走原生 SDK各自独立实现互不干扰。中间是适配层把不同模型的响应格式标准化成统一结构包括文本内容、工具调用、token 消耗统计、结束原因等。最上层是交互层也就是 Gemini CLI 这个前端它通过环境变量和配置文件决定实际请求走哪个模型端点。这种分层设计的好处是明显的。接入新模型时只需要在模型层新增一个实现类适配层和交互层完全不用动反过来如果以后想换一个更趁手的 CLI 前端只要它支持类似的环境变量配置方式模型层和适配层的代码可以直接复用。我在设计 HagiCode 的多模型支持时一直遵循“高内聚低耦合”的原则各个模块之间只通过标准接口通信避免硬编码。3. 集成实现从协议适配到指令级调优3.1 环境变量与端点配置Gemini CLI 支持通过环境变量配置自定义模型端点这是整个集成的地基。核心配置项有两个GEMINI_API_KEY用于指定鉴权凭证GEMINI_BASE_URL用于指定 API 端点地址。接入 GLM 时环境变量可以这样配置export GEMINI_API_KEY你的智谱API Key export GEMINI_BASE_URLhttps://open.bigmodel.cn/api/paas/v4这里有一个值得注意的细节智谱开放平台的 v4 端点本身就是 OpenAI 兼容格式而 Gemini CLI 在自定义端点模式下也以 OpenAI 兼容协议发起请求两者在协议层面天然对齐。这意味着不需要在中间架设额外的转换代理直接把 Gemini CLI 的请求转发给智谱端点就能让 Gemini CLI 使用 GLM 的模型能力。更具体地Gemini CLI 的原生端点格式对路径拼接有要求。实际上除了GEMINI_BASE_URL之外还可以利用GEMINI_MODEL环境变量直接指定要使用的模型名称。在 HagiCode 的配置模板里我给用户准备了这样一组开箱即用的配置export GEMINI_API_KEY你的智谱API Key export GEMINI_BASE_URLhttps://open.bigmodel.cn/api/paas/v4 export GEMINI_MODELglm-4.5设置完之后在终端里输入gemini进入交互模式本质上是 Gemini CLI 的对话界面但底层实际调用的已经是 GLM 的推理接口。我用一个简单的 JavaScript 函数测试过链路连通性模型的反应速度和流式输出的稳定性都符合预期。3.2 鉴权机制与安全处理鉴权这块需要单独说。智谱 API 的鉴权方式走 Bearer Token也就是在请求头里带上Authorization: Bearer API_KEYGemini CLI 在自定义模式下的鉴权逻辑正好兼容这一套。所以理论上直接透传GEMINI_API_KEY就能完成身份验证。但有一个工程上的坑智谱平台的标准鉴权其实是通过Authorization: Bearer API_KEY的 HTTP Header 完成的在某些 SDK 或工具链中还需要额外生成带时间戳的鉴权串。Gemini CLI 自带的鉴权流程可能不会为你完成智谱特有的签名逻辑。如果你的请求遇到 401 鉴权失败排查方向应该是确认请求头是否正确携带了 API Key以及是否存在 token 过期或签名过期的问题。在 HagiCode 的实现里我加了一层密钥管理机制。API Key 统一存放在用户目录下的配置文件中权限设为 600仅当前用户可读写默认不打印到日志也不写入 shell 历史。每次请求前从配置读取密钥用完即失效从源头避免密钥泄露风险。3.3 工具调用与输出格式的映射处理GLM 和 Gemini 在工具调用的 JSON 格式上存在差异这是集成过程中最需要小心处理的环节。Gemini CLI 在交互过程中会频繁发起工具调用比如读取文件、执行命令、编辑代码块。这些工具调用通过函数声明function declaration的方式传给模型模型在回复中返回结构化的 tool call 对象。Gemini 原生模型对工具调用的表述方式和 GLM 有所不同直接透传会导致部分工具调用无法被正确解析。为了处理这个问题我在 HagiCode 的适配层写了一个转换模块。它做的事情是把 Gemini CLI 发出的工具调用请求重新封装成 GLM 能识别的格式再把 GLM 返回的工具调用结果翻译回 Gemini CLI 期望的结构。核心逻辑是维护一张函数名和参数的语义映射表确保同一操作在不同模型之间的表达差异被抹平。实际测试中发现GLM 对工具调用中嵌套 JSON 对象的处理能力很强即使参数层级较深也能准确解析。这对 HagiCode 这种需要频繁读写文件、执行命令的工具来说是一个加分项。相比之下一些轻量级模型在深层嵌套参数上经常出现截断或丢字段的问题GLM 在这方面目前没有遇到过类似情况。3.4 上下文窗口语义对齐与流式输出兼容GLM 和 Gemini 在上下文窗口语义上存在差异具体体现在“token 计算口径”上。Gemini 官方模型使用自己的 tokenizerGLM 也有自己的 tokenizer两边对同一段代码的 token 统计结果并不一样。这意味着你无法精确地用 GLM 的 token 数去估算 Gemini 的 token 数。在 HagiCode 里我走出了一条务实的路子不对 token 做刻意的换算而是以字符数为主要计量单位token 数仅供参考。这样既避免了换算误差也简化了模型的选型逻辑。无论是 GLM 还是 Gemini只要字符数在上下文窗口的安全范围内就默认可以正常处理。流式输出方面GLM 遵循 OpenAI 标准的流式格式即 SSEServer-Sent Events每个事件包含一个choices[0].delta结构文本内容逐段推送。Gemini CLI 原生支持 SSE 流式解析因此在流式链路上同样是天然兼容。实际测试中GLM 的流式响应稳定首次响应令牌大约在 0.5 至 1.5 秒之间对于交互式编程场景是可以接受的连续对话中的平均 token 吞吐量完全能满足日常使用需求。4. 多模型路由HagiCode 如何聪明地分配任务4.1 模型路由规则设计支持 GLM 和 Gemini 只是第一步真正让 HagiCode 好用的是它内部的模型路由机制。如果一个工具只支持多模型但不能自动分配任务用户还得手动切换那和多装两套工具没有本质区别。HagiCode 的模型路由按任务类型进行分流。大致规则是这样的任务类型推荐模型理由简单代码生成、补全GLM-4.5响应快、成本低单文件重构GLM-4.5指令理解能力好编辑准确跨文件全局修改Gemini 3长上下文能力强推理稳定测试用例生成GLM-4.5输出规范格式稳定复杂调试、算法实现Gemini 3推理深度好复杂问题处理能力强代码审查Gemini 3能拿到更大的上下文整体判断更准提交信息生成GLM-4.5轻量任务GLM 足够且更经济这个路由规则不是拍脑袋定的而是基于我自己长时间使用两个模型的实测经验。简单任务是高频动作走 GLM 能大幅降低运行成本复杂任务虽然频次低但对正确率要求高交给 Gemini 更稳妥。4.2 成本与性能的平衡策略多模型集成的另一个关键是成本控制。HagiCode 的默认配置里成本优化优先于性能。但这不意味着牺牲体验而是通过合理的任务分配来平衡。我用一个实际场景来说明。假设你正在写一个新功能模块需要先让 AI 理解项目结构再生成一段核心逻辑代码最后写几个测试用例。整个过程如果全部走 Gemini成本会比较高如果全部走 GLM部分理解型任务的准确率又不够。HagiCode 的做法是结构理解的任务涉及多文件关联分析分配给 Gemini单文件代码生成和测试编写分配给 GLM。这样既保证了关键环节的质量又把整体成本控制在合理范围内。实测数据显示同样的三次任务全走 Gemini 的成本约为 0.5 元全走 GLM 约为 0.2 元而 HagiCode 混合路由约为 0.3 元同时任务完成质量与全 Gemini 方案基本持平。对于每天频繁使用 AI 编程助手的开发者来说这个差距会被放大长期下来是不少钱。4.3 默认模型与手动切换的交互细节HagiCode 保留了手动切换模型的能力。在任意对话中你可以输入/model glm-4.5或/model gemini-3来切换当前会话使用的模型也可以输入/models查看所有可用模型列表。默认模型的优先级逻辑是会话级设置优先于全局设置全局设置优先于配置文件默认值。这样的设计对频繁切换模型的人很友好。比如你在处理一个跨模块功能大部分时间用 Gemini但写单元测试的时候临时切到 GLM等切回其他任务时再切回来。这个操作在 HagiCode 里只需要两步不需要退出重进也不会丢失当前会话的上下文。4.4 自动失败切换与降级机制多模型系统最怕的是某个模型服务不可用整个工作流就卡死了。HagiCode 内置了自动失败切换机制当默认模型请求连续失败超过阈值或响应延迟超过设定时间系统会自动把任务转发到备用模型。整个切换过程对用户无感只会附加一条提示说明当前使用的模型。这个机制在 GLM 服务偶尔负载较高时很有用。有几次我在高峰期使用智谱端点的响应时间明显变长HagiCode 自动切到 Gemini 完成了任务用户几乎无感知。同时降级机制还会记录失败原因和次数供后续优化参考。这个后手准备让整个系统的可靠性提升了一个量级。我实际使用中遇到过一个活生生的例子。某次持续集成流水线跑半夜定时任务期间智谱的接口出现短暂不稳定连续三次请求超时。如果没有自动切换机制整条流水线就会卡在那里等人工介入但 HagiCode 自动把任务转给了 Gemini第二天早上我查看日志才发现夜间发生过一次降级且任务已完成。5. 实操过程从零开始接入 GLM 到 Gemini CLI5.1 前置准备账号、密钥与工具链开始之前需要准备三样东西智谱开放平台的账号用于获取 GLM API Key、安装了 Node.js 18 以上版本的环境Gemini CLI 运行依赖以及 Gemini CLI 本身。智谱开放平台的注册和密钥申请流程很直接登录后在控制台的 API Key 页面生成一个密钥即可。需要注意密钥只会在创建时完整显示一次务必第一时间保存到本地。如果泄露了或搞丢了只能删除重建。Gemini CLI 的安装方式取决于你的包管理器。我用 npm 安装npm install -g google/gemini-cli安装完成后先验证基础可用性不配置任何自定义端点确认gemini命令能正常进入交互界面。这是一个重要的前置验证可以排除掉“工具本身没装好”的干扰因素为后续配置自定义端点建立干净的基线。5.2 配置约束IDE 之外的终端工作流Gemini CLI 本身是一个终端交互工具这决定了它的使用场景主要面向命令行工作流。它和 Cursor、IDEA 这类 IDE 插件是互补的关系而不是替代关系。在 HagiCode 的使用场景里Gemini CLI 主要承担两类工作一是在不打开 IDE 的情况下快速完成小规模代码修改比如修一个 bug、改一个配置二是作为自动化流水线的执行引擎在 CI 环境下直接跑 AI 驱动的代码检查或测试生成。这种设计也带来了一个优势模型切换对工作流无侵入。无论你用的 IDE 是 VS Code、IDEA 还是 Neovim只要终端环境一致Gemini CLI 和 HagiCode 的配置就完全复用。我在实际使用中就是终端跑 Gemini CLI编辑器用 VS Code两者通过文件系统共享上下文。需要提醒的是如果你期望的是“在 IDE 的聊天面板里直接切换 GLM”那 Gemini CLI 不是最合适的选择你可能需要看 IDE 插件层面的模型配置能力比如 Cursor 里的自定义模型接入或者 IDEA 的 AI 插件配置。HagiCode 的定位是控制台工作流它更擅长批处理、流水线和远程开发场景。5.3 端到端联通验证完成环境变量配置后做一次完整的联通验证很关键。我先准备了一个简单的测试项目里面包含一个主函数和一个未完成的测试文件。第一步启动 Gemini CLI确认它能正确加载 GLM 端点gemini进入交互界面后输入一个简单的指令“读取当前目录下的 main.js找出其中的函数并说明各自的作用。”如果配置正确Gemini CLI 会调用 GLM 的接口并返回准确的函数说明。第二步测试工具调用链路。我让模型“将 main.js 中的add函数改名为sum”。这个指令要求模型先读取文件内容再调用编辑工具修改代码最后返回修改结果。整个过程如果 GLM 的工具调用适配正确应该能一气呵成完成。第三步验证流式输出的体验。随意输入一段要求生成代码的指令观察响应是否以流式方式逐字输出有没有卡顿、中断或者重复输出的问题。实测下来 GLM 的流式表现很稳定没有出现输出中断的情况。5.4 配置持久化与团队共享环境变量写在 shell profile 里对个人使用是够了。但 HagiCode 考虑到团队协作的场景提供了一套配置文件方案。在项目根目录放一个.hagicode.json里面统一管理模型端点、API Key 引用位置注意不是明文密钥、默认路由规则等。团队共享配置的时候有一个安全实践必须遵守配置文件里不存真实密钥只存环境变量占位符比如${ZHIPU_API_KEY}。每个开发者在自己机器上设置真实的环境变量从源头避免密钥随代码仓库流转。加上.gitignore里排除包含密钥的文件团队协作的安全性就稳妥了。6. 踩坑实录多模型集成中的典型问题6.1 GLM 与 Gemini 的协议差异问题前面提到 GLM 和 Gemini CLI 在协议上天然对齐但这是宏观层面的判断。实际集成过程中还是有不少细微差异需要处理。比如请求体中tools字段的格式。Gemini 官方模型对工具的描述使用functionDeclarationsGemini API 的原生格式而在 OpenAI 兼容端点里工具描述用的是functionsOpenAI 格式。Gemini CLI 在面向 Gemini API 时按前者组装请求在面向自定义端点时需要转换为后者。如果你在对接其他模型时发现工具调用一直失败先查一下是不是这里出了问题。再比如stop参数的处理。Gemini 允许通过stopSequences指定停止序列而 OpenAI 兼容协议里对应的是stop字段且只接受字符串或字符串数组。如果配置的位置不对或格式不符模型可能会多输出一大段内容。这些细节问题在联调阶段会集中爆发我的建议是准备一套完整的请求抓包工具链逐步对比每次请求的实际报文快速定位差异点。6.2 上下文窗口计数不一致的问题GLM 和 Gemini 对上下文窗口的计数方式不同直接拼接会导致“我以为没超、其实超了”的问题。Gemini 的 tokenizer 编码效率和 GLM 的 tokenizer 编码效率在不同语言上是不同的。对中文来说Gemini 的 tokenizer 往往更密集对代码来说GLM 的 tokenizer 则更贴近常见的 OpenAI 系编码。HagiCode 的应对方式是“双轨统计”。上下文占用量以字符数为硬指标token 数为软指标。在需要严格控制的场景比如长文件写入、大规模重构下以字符数超过阈值作为触发截断或分片的信号。这样虽然放弃了 token 级的精确控制但换来了简洁的工程实现和可预测的行为。6.3 工具调用解析失败的排查思路工具调用的解析出错是多模型集成里最常见的故障。症状通常是模型返回了一段包含工具调用意图的文本但解析器没有把它识别成结构化的 tool call导致后续动作无法执行。排查思路按三步走。第一步确认请求中是否正确发送了工具定义缺了工具定义模型不会知道它可以调用工具第二步检查返回结果中的tool_calls字段是否存在如果存在但不是数组形式可能是目标模型在该轮选择了直接回答而非调用工具此时需要调整提示词或温度参数第三步检查参数内容是否为合法的 JSON如果模型返回的工具调用参数含有多余字符比如尾部逗号、注释需要做清洗再解析。我在 HagiCode 里写了一个兜底的容错解析器专门处理这类“脏数据”。它先用 JSON.parse 尝试解析失败后用正则提取关键字段再进行二次校验。实测下来这个方法能把工具调用的解析成功率从 92% 提升到 99% 以上。6.4 为什么 token 消耗突然增多了接多模型之后很多用户会遇到一个现象同样一轮对话token 消耗比之前明显增多。这个问题的成因往往是多方面的。一个主要原因是上下文累积。当你从一个模型切到另一个模型时之前的对话历史会被完整保留并发送给新模型而这个历史是用旧模型的 tokenizer 计算的在新模型的 tokenizer 下可能膨胀了。我实测过GLM 和 Gemini 对同一段代码的 token 统计可以差到 15% 到 30%。另一个原因是系统提示词的长度差异。Gemini CLI 自带的系统提示词在适配自定义端点时可能会额外注入一些格式说明这些说明会占用上下文空间导致每次请求的 token 数增加。还有一个容易被忽略的点工具调用循环中的中间结果也会占用 token。当模型连续调用多次工具来完成一个任务时每次工具调用产生的输入输出都会累积到上下文中。如果工具返回了大量冗余信息比如目录树、编译日志token 消耗会呈线性甚至超线性增长。建议的做法是在自动化任务中定期清理上下文保留关键里程碑信息丢弃中间过程噪音。HagiCode 里提供了一条/compact指令触发上下文压缩只保留最近几轮对话的摘要和关键事实。7. 性能优化与稳定性保障7.1 模型 AK 轮换与请求限流多模型接入后最容易翻车的地方是请求频率控制。GLM 和 Gemini 的 API 都设置了不同等级的速率限制超出会被拒绝或降级。HagiCode 内置了简单的请求限流器默认按模型分别设置每秒请求数上限超过后自动排队。同时API Key 的轮换机制也值得提一下。如果你在 CI 环境里跑大规模自动化任务单个 API Key 很容易触达速率上限HagiCode 支持配置多个 Key 实现轮换每次请求自动选择下一个可用 Key。这个机制同样适用于本地多人协作的场景。7.2 超时与重试策略模型服务的不可用是常态而不是异常。HagiCode 的请求处理管线里针对不同类型的失败设置了不同的重试策略限流429 状态码等待后重试最多 3 次等待时间按指数退避递增服务不可用5xx 状态码立即重试一次如果持续失败则触发模型切换网络超时重试一次如果还是超时则切换模型或终止任务这个策略在多次实测中表现不错。尤其是配合自动模型切换机制后服务整体的可用性从 98% 提升到了 99.5% 以上用户体验的提升非常明显。7.3 本地缓存与增量上下文为了减少 token 消耗和请求延迟HagiCode 引入了本地缓存机制。对常见的文件读取结果比如项目配置文件、依赖声明文件、常用代码片段在文件内容未发生变化时直接返回缓存结果不重复请求模型。增量上下文是另一个优化点。在连续对话中如果模型需要读取一个大文件比如几千行的模块文件全量塞进上下文会非常浪费 token。HagiCode 会按需截取文件的相关片段比如只发送函数签名和注释而不是完整文件内容。只有当模型明确要求查看完整源码时才发送全量内容。这个机制实测能把长文件相关任务的平均 token 消耗降低约 40%而任务完成质量几乎不受影响因为大部分情况下模型真正需要的只是接口定义和关键实现细节。8. 架构扩展HagiCode 的插件化模型接入设计8.1 模型提供者的抽象接口HagiCode 的多模型支持之所以能持续演进核心在于模型接入层的抽象设计。所有模型提供者都实现同一个接口包含chat()、streamChat()、listModels()、countTokens()四个核心方法。GLM 和 Gemini 各自有一个独立的实现类互不依赖。新增一个模型支持时只需要新建一个实现类注册到模型注册表中然后在路由配置里加上对应的模型名称和适用任务类型就完成了整个接入流程。不需要改动交互层、适配层或任务调度层的任何代码。这种插件化的设计大大降低了支持新模型的边际成本。我在接入 GLM 时从开始动手到跑通全部测试只花了不到半天时间后续如果要接入其他兼容 OpenAI 协议的模型理论上速度会更快。8.2 自定义工具的注册机制除了模型层面的抽象HagiCode 还支持自定义工具的注册。你可以给模型添加一个“搜索本地文档”“查询数据库表结构”之类的工具然后在 Prompt 系统词里描述它的功能模型就会在合适的时机调用它。自定义工具的注册格式遵循 JSON Schema 规范工具名、描述、参数结构都按标准定义。GLM 对这些 Schema 的解析能力不错即便是包含嵌套 object 的复杂工具定义也能正确理解和调用。8.3 后续模型接入的演进方向下一阶段 HagiCode 计划支持更多的模型供应商和更丰富的路由策略。方向包括基于历史成功率的路由哪个模型在这个任务类型上表现最好就优先将这类任务分配给它、基于用户反馈的路由用户对某个结果点了赞或踩会被记录下来影响后续分配、以及面向特定领域的微调模型接入。理想的状态是用户只告诉 HagiCode“帮我完成这个需求”而不需要关心底层用的是哪个模型。模型选择、参数调优、上下文管理、成本控制这些细节全部由系统自动完成。GLM 和 Gemini 的接入是这个长期目标的第一步。9. 写在最后多模型不是叠加而是编排折腾这一圈下来我个人最大的体会是多模型集成真正的难点不是“能连接多少个模型”而是“怎么让不同模型在正确的场景发挥正确的价值”。GLM 和 Gemini 各有不可替代的长处单纯地拼凑多个 API 接口除了多了一个切换按钮没有实际意义。HagiCode 这轮做的“GLM 全面支持 Gemini CLI 集成”实质上是在搭建一套模型编排框架让接入的每个模型都能被分配到最合适的任务上。如果你也想做类似的事情我的建议是先进去动手不用等所有设计都想清楚。环境变量配好跑通一条最简单的链路再逐步叠加路由、切换、容错这些能力。踩坑的时候别慌把请求报文打出来看绝大多数问题都能在三步内定位到。这套思路不仅适用于 GLM 和 Gemini CLI未来任何新模型出现你都能以同样的方式快速把它纳入你的工作流。
1. 项目全貌HagiCode 为什么要做多模型集成先说说背景。我一直在维护一个叫 HagiCode 的个人开发工具项目定位很简单一个跑在终端里的 AI 编程工作台把代码补全、仓库级理解、自动化测试生成、提交信息润色这些琐碎但高频的活儿统一收口到命令行里。早期版本只接了一家模型供应商用起来倒也顺手但随着项目越做越深入问题开始变得扎眼——单一模型的瓶颈太明显了代码生成质量、上下文窗口长度、响应速度、成本控制全都被一家绑死。最难受的是不同模型在不同任务上各有所长有的擅长长仓库的全局理解有的在单文件重构上又快又准有的在测试用例生成上非常稳。把它们全塞进一个工具里让用户按场景自由切换这才是 HagiCode 该有的形态。所以这个版本的核心工作就是两件事第一把 GLM 系列模型完整接入 HagiCode 的模型层第二让 HagiCode 能够以 Gemini CLI 作为前端交互入口跑通一套“多后端模型 标准 CLI 工具”的完整链路。也就是说你可以用 Gemini CLI 的交互体验背后实际调用的是 GLM 的模型能力也可以在同一个工作流里随时切换到 Gemini 官方模型HagiCode 负责路由、适配和调度。这听起来不算复杂但真正落地的时候牵涉到的东西不少API 协议差异、工具调用格式转换、上下文窗口语义对齐、流式输出的兼容处理、鉴权体系对接、模型能力映射……每一个环节都可能踩坑。这篇文章把整个集成过程的思路和实现细节梳理一遍给同样在做多模型工具集成的朋友一个可参考的路径。2. 技术选型为什么偏偏是 GLM 和 Gemini CLI2.1 GLM 系列模型的定位与优势在确定接入 GLM 之前我对比过市面上主流的开源和商用模型。选择 GLM 有几个很现实的原因。首先是它对开发者友好。GLM 的 API 形态走的是 OpenAI 兼容协议base_url 指向智谱开放平台的 v4 端点请求结构和字段命名与业界主流保持一致。这意味着在代码层面做模型适配时不需要额外写一套协议转换层绝大多数 HTTP 客户端和 SDK 可以直接复用。对于 HagiCode 这种需要同时维护多套模型的工具来说协议兼容度直接决定了接入成本。其次是 GLM 在代码类任务上的能力已经够用。以 GLM-4.5 系列为例长文本理解能力在同级别模型里属于第一梯队128K 的上下文窗口对于中等规模代码仓库的全局分析、跨文件重构来说完全够用。它的工具调用function calling机制也比较成熟支持并行调用多个工具这在自动化代码修改场景里非常关键——比如同时读取多个文件、对比不同实现版本、批量执行静态检查这些操作如果能并行发出效率提升是很明显的。还有一个容易被忽视的点GLM 的定价策略对工具类产品很友好。HagiCode 的使用场景是高频小请求单次调用消耗的 token 不算多但如果一天跑几十次甚至上百次自动化任务成本就会拉开差距。GLM 的输入输出价格相比同规格的国外模型有显著优势而且平台经常有面向开发者的体验活动新用户会送 token 额度实际跑下来成本压力小很多。2.2 Gemini CLI 的开放生态与工程优势Gemini CLI 是 Google 开源的一款终端 AI 编程工具基于 TypeScript 编写采用 Apache 2.0 协议。它最大的特点不是“又一个 AI 编程助手”而是它的协议设计思路和对外开放程度。Gemini CLI 的架构核心是模型无关的。它内部定义了一套标准化的工具调用规范和上下文管理机制对外则通过环境变量来指定模型端点。默认情况下它连接 Gemini API但你完全可以通过配置环境变量的方式把请求转发到任何兼容端点。这种“预设一个默认目标但保留完全自定义能力”的设计给了我很大的发挥空间。另外Gemini CLI 的交互设计也值得借鉴。它支持多模态输入粘贴截图让它看 UI 问题或者把设计稿直接丢进对话里这对前端开发场景非常有用。同时它的文件编辑能力做得很细支持逐块 patch 的精准修改模式在代码审查场景下能显著减少误修改。更重要的是Gemini CLI 的原生模型 Gemini 3 在复杂编程任务上表现确实强尤其是算法实现、架构设计、调试推理这类高难度场景。把 GLM 和 Gemini 放在同一个工具里用户可以在日常简单任务上走 GLM 节省成本碰到硬骨头切到 Gemini 冲能力这是最理想的搭配。2.3 多模型架构的整体设计思路整个集成架构分三层。最底层是模型接入层封装各家 API 的统一客户端GLM 走 OpenAI 兼容协议Gemini 走原生 SDK各自独立实现互不干扰。中间是适配层把不同模型的响应格式标准化成统一结构包括文本内容、工具调用、token 消耗统计、结束原因等。最上层是交互层也就是 Gemini CLI 这个前端它通过环境变量和配置文件决定实际请求走哪个模型端点。这种分层设计的好处是明显的。接入新模型时只需要在模型层新增一个实现类适配层和交互层完全不用动反过来如果以后想换一个更趁手的 CLI 前端只要它支持类似的环境变量配置方式模型层和适配层的代码可以直接复用。我在设计 HagiCode 的多模型支持时一直遵循“高内聚低耦合”的原则各个模块之间只通过标准接口通信避免硬编码。3. 集成实现从协议适配到指令级调优3.1 环境变量与端点配置Gemini CLI 支持通过环境变量配置自定义模型端点这是整个集成的地基。核心配置项有两个GEMINI_API_KEY用于指定鉴权凭证GEMINI_BASE_URL用于指定 API 端点地址。接入 GLM 时环境变量可以这样配置export GEMINI_API_KEY你的智谱API Key export GEMINI_BASE_URLhttps://open.bigmodel.cn/api/paas/v4这里有一个值得注意的细节智谱开放平台的 v4 端点本身就是 OpenAI 兼容格式而 Gemini CLI 在自定义端点模式下也以 OpenAI 兼容协议发起请求两者在协议层面天然对齐。这意味着不需要在中间架设额外的转换代理直接把 Gemini CLI 的请求转发给智谱端点就能让 Gemini CLI 使用 GLM 的模型能力。更具体地Gemini CLI 的原生端点格式对路径拼接有要求。实际上除了GEMINI_BASE_URL之外还可以利用GEMINI_MODEL环境变量直接指定要使用的模型名称。在 HagiCode 的配置模板里我给用户准备了这样一组开箱即用的配置export GEMINI_API_KEY你的智谱API Key export GEMINI_BASE_URLhttps://open.bigmodel.cn/api/paas/v4 export GEMINI_MODELglm-4.5设置完之后在终端里输入gemini进入交互模式本质上是 Gemini CLI 的对话界面但底层实际调用的已经是 GLM 的推理接口。我用一个简单的 JavaScript 函数测试过链路连通性模型的反应速度和流式输出的稳定性都符合预期。3.2 鉴权机制与安全处理鉴权这块需要单独说。智谱 API 的鉴权方式走 Bearer Token也就是在请求头里带上Authorization: Bearer API_KEYGemini CLI 在自定义模式下的鉴权逻辑正好兼容这一套。所以理论上直接透传GEMINI_API_KEY就能完成身份验证。但有一个工程上的坑智谱平台的标准鉴权其实是通过Authorization: Bearer API_KEY的 HTTP Header 完成的在某些 SDK 或工具链中还需要额外生成带时间戳的鉴权串。Gemini CLI 自带的鉴权流程可能不会为你完成智谱特有的签名逻辑。如果你的请求遇到 401 鉴权失败排查方向应该是确认请求头是否正确携带了 API Key以及是否存在 token 过期或签名过期的问题。在 HagiCode 的实现里我加了一层密钥管理机制。API Key 统一存放在用户目录下的配置文件中权限设为 600仅当前用户可读写默认不打印到日志也不写入 shell 历史。每次请求前从配置读取密钥用完即失效从源头避免密钥泄露风险。3.3 工具调用与输出格式的映射处理GLM 和 Gemini 在工具调用的 JSON 格式上存在差异这是集成过程中最需要小心处理的环节。Gemini CLI 在交互过程中会频繁发起工具调用比如读取文件、执行命令、编辑代码块。这些工具调用通过函数声明function declaration的方式传给模型模型在回复中返回结构化的 tool call 对象。Gemini 原生模型对工具调用的表述方式和 GLM 有所不同直接透传会导致部分工具调用无法被正确解析。为了处理这个问题我在 HagiCode 的适配层写了一个转换模块。它做的事情是把 Gemini CLI 发出的工具调用请求重新封装成 GLM 能识别的格式再把 GLM 返回的工具调用结果翻译回 Gemini CLI 期望的结构。核心逻辑是维护一张函数名和参数的语义映射表确保同一操作在不同模型之间的表达差异被抹平。实际测试中发现GLM 对工具调用中嵌套 JSON 对象的处理能力很强即使参数层级较深也能准确解析。这对 HagiCode 这种需要频繁读写文件、执行命令的工具来说是一个加分项。相比之下一些轻量级模型在深层嵌套参数上经常出现截断或丢字段的问题GLM 在这方面目前没有遇到过类似情况。3.4 上下文窗口语义对齐与流式输出兼容GLM 和 Gemini 在上下文窗口语义上存在差异具体体现在“token 计算口径”上。Gemini 官方模型使用自己的 tokenizerGLM 也有自己的 tokenizer两边对同一段代码的 token 统计结果并不一样。这意味着你无法精确地用 GLM 的 token 数去估算 Gemini 的 token 数。在 HagiCode 里我走出了一条务实的路子不对 token 做刻意的换算而是以字符数为主要计量单位token 数仅供参考。这样既避免了换算误差也简化了模型的选型逻辑。无论是 GLM 还是 Gemini只要字符数在上下文窗口的安全范围内就默认可以正常处理。流式输出方面GLM 遵循 OpenAI 标准的流式格式即 SSEServer-Sent Events每个事件包含一个choices[0].delta结构文本内容逐段推送。Gemini CLI 原生支持 SSE 流式解析因此在流式链路上同样是天然兼容。实际测试中GLM 的流式响应稳定首次响应令牌大约在 0.5 至 1.5 秒之间对于交互式编程场景是可以接受的连续对话中的平均 token 吞吐量完全能满足日常使用需求。4. 多模型路由HagiCode 如何聪明地分配任务4.1 模型路由规则设计支持 GLM 和 Gemini 只是第一步真正让 HagiCode 好用的是它内部的模型路由机制。如果一个工具只支持多模型但不能自动分配任务用户还得手动切换那和多装两套工具没有本质区别。HagiCode 的模型路由按任务类型进行分流。大致规则是这样的任务类型推荐模型理由简单代码生成、补全GLM-4.5响应快、成本低单文件重构GLM-4.5指令理解能力好编辑准确跨文件全局修改Gemini 3长上下文能力强推理稳定测试用例生成GLM-4.5输出规范格式稳定复杂调试、算法实现Gemini 3推理深度好复杂问题处理能力强代码审查Gemini 3能拿到更大的上下文整体判断更准提交信息生成GLM-4.5轻量任务GLM 足够且更经济这个路由规则不是拍脑袋定的而是基于我自己长时间使用两个模型的实测经验。简单任务是高频动作走 GLM 能大幅降低运行成本复杂任务虽然频次低但对正确率要求高交给 Gemini 更稳妥。4.2 成本与性能的平衡策略多模型集成的另一个关键是成本控制。HagiCode 的默认配置里成本优化优先于性能。但这不意味着牺牲体验而是通过合理的任务分配来平衡。我用一个实际场景来说明。假设你正在写一个新功能模块需要先让 AI 理解项目结构再生成一段核心逻辑代码最后写几个测试用例。整个过程如果全部走 Gemini成本会比较高如果全部走 GLM部分理解型任务的准确率又不够。HagiCode 的做法是结构理解的任务涉及多文件关联分析分配给 Gemini单文件代码生成和测试编写分配给 GLM。这样既保证了关键环节的质量又把整体成本控制在合理范围内。实测数据显示同样的三次任务全走 Gemini 的成本约为 0.5 元全走 GLM 约为 0.2 元而 HagiCode 混合路由约为 0.3 元同时任务完成质量与全 Gemini 方案基本持平。对于每天频繁使用 AI 编程助手的开发者来说这个差距会被放大长期下来是不少钱。4.3 默认模型与手动切换的交互细节HagiCode 保留了手动切换模型的能力。在任意对话中你可以输入/model glm-4.5或/model gemini-3来切换当前会话使用的模型也可以输入/models查看所有可用模型列表。默认模型的优先级逻辑是会话级设置优先于全局设置全局设置优先于配置文件默认值。这样的设计对频繁切换模型的人很友好。比如你在处理一个跨模块功能大部分时间用 Gemini但写单元测试的时候临时切到 GLM等切回其他任务时再切回来。这个操作在 HagiCode 里只需要两步不需要退出重进也不会丢失当前会话的上下文。4.4 自动失败切换与降级机制多模型系统最怕的是某个模型服务不可用整个工作流就卡死了。HagiCode 内置了自动失败切换机制当默认模型请求连续失败超过阈值或响应延迟超过设定时间系统会自动把任务转发到备用模型。整个切换过程对用户无感只会附加一条提示说明当前使用的模型。这个机制在 GLM 服务偶尔负载较高时很有用。有几次我在高峰期使用智谱端点的响应时间明显变长HagiCode 自动切到 Gemini 完成了任务用户几乎无感知。同时降级机制还会记录失败原因和次数供后续优化参考。这个后手准备让整个系统的可靠性提升了一个量级。我实际使用中遇到过一个活生生的例子。某次持续集成流水线跑半夜定时任务期间智谱的接口出现短暂不稳定连续三次请求超时。如果没有自动切换机制整条流水线就会卡在那里等人工介入但 HagiCode 自动把任务转给了 Gemini第二天早上我查看日志才发现夜间发生过一次降级且任务已完成。5. 实操过程从零开始接入 GLM 到 Gemini CLI5.1 前置准备账号、密钥与工具链开始之前需要准备三样东西智谱开放平台的账号用于获取 GLM API Key、安装了 Node.js 18 以上版本的环境Gemini CLI 运行依赖以及 Gemini CLI 本身。智谱开放平台的注册和密钥申请流程很直接登录后在控制台的 API Key 页面生成一个密钥即可。需要注意密钥只会在创建时完整显示一次务必第一时间保存到本地。如果泄露了或搞丢了只能删除重建。Gemini CLI 的安装方式取决于你的包管理器。我用 npm 安装npm install -g google/gemini-cli安装完成后先验证基础可用性不配置任何自定义端点确认gemini命令能正常进入交互界面。这是一个重要的前置验证可以排除掉“工具本身没装好”的干扰因素为后续配置自定义端点建立干净的基线。5.2 配置约束IDE 之外的终端工作流Gemini CLI 本身是一个终端交互工具这决定了它的使用场景主要面向命令行工作流。它和 Cursor、IDEA 这类 IDE 插件是互补的关系而不是替代关系。在 HagiCode 的使用场景里Gemini CLI 主要承担两类工作一是在不打开 IDE 的情况下快速完成小规模代码修改比如修一个 bug、改一个配置二是作为自动化流水线的执行引擎在 CI 环境下直接跑 AI 驱动的代码检查或测试生成。这种设计也带来了一个优势模型切换对工作流无侵入。无论你用的 IDE 是 VS Code、IDEA 还是 Neovim只要终端环境一致Gemini CLI 和 HagiCode 的配置就完全复用。我在实际使用中就是终端跑 Gemini CLI编辑器用 VS Code两者通过文件系统共享上下文。需要提醒的是如果你期望的是“在 IDE 的聊天面板里直接切换 GLM”那 Gemini CLI 不是最合适的选择你可能需要看 IDE 插件层面的模型配置能力比如 Cursor 里的自定义模型接入或者 IDEA 的 AI 插件配置。HagiCode 的定位是控制台工作流它更擅长批处理、流水线和远程开发场景。5.3 端到端联通验证完成环境变量配置后做一次完整的联通验证很关键。我先准备了一个简单的测试项目里面包含一个主函数和一个未完成的测试文件。第一步启动 Gemini CLI确认它能正确加载 GLM 端点gemini进入交互界面后输入一个简单的指令“读取当前目录下的 main.js找出其中的函数并说明各自的作用。”如果配置正确Gemini CLI 会调用 GLM 的接口并返回准确的函数说明。第二步测试工具调用链路。我让模型“将 main.js 中的add函数改名为sum”。这个指令要求模型先读取文件内容再调用编辑工具修改代码最后返回修改结果。整个过程如果 GLM 的工具调用适配正确应该能一气呵成完成。第三步验证流式输出的体验。随意输入一段要求生成代码的指令观察响应是否以流式方式逐字输出有没有卡顿、中断或者重复输出的问题。实测下来 GLM 的流式表现很稳定没有出现输出中断的情况。5.4 配置持久化与团队共享环境变量写在 shell profile 里对个人使用是够了。但 HagiCode 考虑到团队协作的场景提供了一套配置文件方案。在项目根目录放一个.hagicode.json里面统一管理模型端点、API Key 引用位置注意不是明文密钥、默认路由规则等。团队共享配置的时候有一个安全实践必须遵守配置文件里不存真实密钥只存环境变量占位符比如${ZHIPU_API_KEY}。每个开发者在自己机器上设置真实的环境变量从源头避免密钥随代码仓库流转。加上.gitignore里排除包含密钥的文件团队协作的安全性就稳妥了。6. 踩坑实录多模型集成中的典型问题6.1 GLM 与 Gemini 的协议差异问题前面提到 GLM 和 Gemini CLI 在协议上天然对齐但这是宏观层面的判断。实际集成过程中还是有不少细微差异需要处理。比如请求体中tools字段的格式。Gemini 官方模型对工具的描述使用functionDeclarationsGemini API 的原生格式而在 OpenAI 兼容端点里工具描述用的是functionsOpenAI 格式。Gemini CLI 在面向 Gemini API 时按前者组装请求在面向自定义端点时需要转换为后者。如果你在对接其他模型时发现工具调用一直失败先查一下是不是这里出了问题。再比如stop参数的处理。Gemini 允许通过stopSequences指定停止序列而 OpenAI 兼容协议里对应的是stop字段且只接受字符串或字符串数组。如果配置的位置不对或格式不符模型可能会多输出一大段内容。这些细节问题在联调阶段会集中爆发我的建议是准备一套完整的请求抓包工具链逐步对比每次请求的实际报文快速定位差异点。6.2 上下文窗口计数不一致的问题GLM 和 Gemini 对上下文窗口的计数方式不同直接拼接会导致“我以为没超、其实超了”的问题。Gemini 的 tokenizer 编码效率和 GLM 的 tokenizer 编码效率在不同语言上是不同的。对中文来说Gemini 的 tokenizer 往往更密集对代码来说GLM 的 tokenizer 则更贴近常见的 OpenAI 系编码。HagiCode 的应对方式是“双轨统计”。上下文占用量以字符数为硬指标token 数为软指标。在需要严格控制的场景比如长文件写入、大规模重构下以字符数超过阈值作为触发截断或分片的信号。这样虽然放弃了 token 级的精确控制但换来了简洁的工程实现和可预测的行为。6.3 工具调用解析失败的排查思路工具调用的解析出错是多模型集成里最常见的故障。症状通常是模型返回了一段包含工具调用意图的文本但解析器没有把它识别成结构化的 tool call导致后续动作无法执行。排查思路按三步走。第一步确认请求中是否正确发送了工具定义缺了工具定义模型不会知道它可以调用工具第二步检查返回结果中的tool_calls字段是否存在如果存在但不是数组形式可能是目标模型在该轮选择了直接回答而非调用工具此时需要调整提示词或温度参数第三步检查参数内容是否为合法的 JSON如果模型返回的工具调用参数含有多余字符比如尾部逗号、注释需要做清洗再解析。我在 HagiCode 里写了一个兜底的容错解析器专门处理这类“脏数据”。它先用 JSON.parse 尝试解析失败后用正则提取关键字段再进行二次校验。实测下来这个方法能把工具调用的解析成功率从 92% 提升到 99% 以上。6.4 为什么 token 消耗突然增多了接多模型之后很多用户会遇到一个现象同样一轮对话token 消耗比之前明显增多。这个问题的成因往往是多方面的。一个主要原因是上下文累积。当你从一个模型切到另一个模型时之前的对话历史会被完整保留并发送给新模型而这个历史是用旧模型的 tokenizer 计算的在新模型的 tokenizer 下可能膨胀了。我实测过GLM 和 Gemini 对同一段代码的 token 统计可以差到 15% 到 30%。另一个原因是系统提示词的长度差异。Gemini CLI 自带的系统提示词在适配自定义端点时可能会额外注入一些格式说明这些说明会占用上下文空间导致每次请求的 token 数增加。还有一个容易被忽略的点工具调用循环中的中间结果也会占用 token。当模型连续调用多次工具来完成一个任务时每次工具调用产生的输入输出都会累积到上下文中。如果工具返回了大量冗余信息比如目录树、编译日志token 消耗会呈线性甚至超线性增长。建议的做法是在自动化任务中定期清理上下文保留关键里程碑信息丢弃中间过程噪音。HagiCode 里提供了一条/compact指令触发上下文压缩只保留最近几轮对话的摘要和关键事实。7. 性能优化与稳定性保障7.1 模型 AK 轮换与请求限流多模型接入后最容易翻车的地方是请求频率控制。GLM 和 Gemini 的 API 都设置了不同等级的速率限制超出会被拒绝或降级。HagiCode 内置了简单的请求限流器默认按模型分别设置每秒请求数上限超过后自动排队。同时API Key 的轮换机制也值得提一下。如果你在 CI 环境里跑大规模自动化任务单个 API Key 很容易触达速率上限HagiCode 支持配置多个 Key 实现轮换每次请求自动选择下一个可用 Key。这个机制同样适用于本地多人协作的场景。7.2 超时与重试策略模型服务的不可用是常态而不是异常。HagiCode 的请求处理管线里针对不同类型的失败设置了不同的重试策略限流429 状态码等待后重试最多 3 次等待时间按指数退避递增服务不可用5xx 状态码立即重试一次如果持续失败则触发模型切换网络超时重试一次如果还是超时则切换模型或终止任务这个策略在多次实测中表现不错。尤其是配合自动模型切换机制后服务整体的可用性从 98% 提升到了 99.5% 以上用户体验的提升非常明显。7.3 本地缓存与增量上下文为了减少 token 消耗和请求延迟HagiCode 引入了本地缓存机制。对常见的文件读取结果比如项目配置文件、依赖声明文件、常用代码片段在文件内容未发生变化时直接返回缓存结果不重复请求模型。增量上下文是另一个优化点。在连续对话中如果模型需要读取一个大文件比如几千行的模块文件全量塞进上下文会非常浪费 token。HagiCode 会按需截取文件的相关片段比如只发送函数签名和注释而不是完整文件内容。只有当模型明确要求查看完整源码时才发送全量内容。这个机制实测能把长文件相关任务的平均 token 消耗降低约 40%而任务完成质量几乎不受影响因为大部分情况下模型真正需要的只是接口定义和关键实现细节。8. 架构扩展HagiCode 的插件化模型接入设计8.1 模型提供者的抽象接口HagiCode 的多模型支持之所以能持续演进核心在于模型接入层的抽象设计。所有模型提供者都实现同一个接口包含chat()、streamChat()、listModels()、countTokens()四个核心方法。GLM 和 Gemini 各自有一个独立的实现类互不依赖。新增一个模型支持时只需要新建一个实现类注册到模型注册表中然后在路由配置里加上对应的模型名称和适用任务类型就完成了整个接入流程。不需要改动交互层、适配层或任务调度层的任何代码。这种插件化的设计大大降低了支持新模型的边际成本。我在接入 GLM 时从开始动手到跑通全部测试只花了不到半天时间后续如果要接入其他兼容 OpenAI 协议的模型理论上速度会更快。8.2 自定义工具的注册机制除了模型层面的抽象HagiCode 还支持自定义工具的注册。你可以给模型添加一个“搜索本地文档”“查询数据库表结构”之类的工具然后在 Prompt 系统词里描述它的功能模型就会在合适的时机调用它。自定义工具的注册格式遵循 JSON Schema 规范工具名、描述、参数结构都按标准定义。GLM 对这些 Schema 的解析能力不错即便是包含嵌套 object 的复杂工具定义也能正确理解和调用。8.3 后续模型接入的演进方向下一阶段 HagiCode 计划支持更多的模型供应商和更丰富的路由策略。方向包括基于历史成功率的路由哪个模型在这个任务类型上表现最好就优先将这类任务分配给它、基于用户反馈的路由用户对某个结果点了赞或踩会被记录下来影响后续分配、以及面向特定领域的微调模型接入。理想的状态是用户只告诉 HagiCode“帮我完成这个需求”而不需要关心底层用的是哪个模型。模型选择、参数调优、上下文管理、成本控制这些细节全部由系统自动完成。GLM 和 Gemini 的接入是这个长期目标的第一步。9. 写在最后多模型不是叠加而是编排折腾这一圈下来我个人最大的体会是多模型集成真正的难点不是“能连接多少个模型”而是“怎么让不同模型在正确的场景发挥正确的价值”。GLM 和 Gemini 各有不可替代的长处单纯地拼凑多个 API 接口除了多了一个切换按钮没有实际意义。HagiCode 这轮做的“GLM 全面支持 Gemini CLI 集成”实质上是在搭建一套模型编排框架让接入的每个模型都能被分配到最合适的任务上。如果你也想做类似的事情我的建议是先进去动手不用等所有设计都想清楚。环境变量配好跑通一条最简单的链路再逐步叠加路由、切换、容错这些能力。踩坑的时候别慌把请求报文打出来看绝大多数问题都能在三步内定位到。这套思路不仅适用于 GLM 和 Gemini CLI未来任何新模型出现你都能以同样的方式快速把它纳入你的工作流。
