超级飞侠Fly1. 为什么把GLM放进Gemini CLI：这次集成解决的三个痛点
上个月我把HagiCode升级到多模型架构的时候，第一个想通的点就是：CLI工具不应该绑定单一模型供应商。Gemini CLI这个名字很容易让人误以为它只能连Gemini，但实际上它的接口设计从一开始就是按多模型代理来做的，只是官方默认配置指向了Gemini的服务端点。这次HagiCode做的GLM全面支持，本质上是把这个代理层打通，让同一套命令行工作流可以自由切换到GLM系列模型上。
先说清楚几个让我决定做这次集成的实际痛点。第一，Gemini CLI在长上下文代码理解上很强，尤其是处理大型仓库的跨文件检索时，它的上下文窗口优势很明显，但在中文注释项目的理解上偶尔会出现偏差，而GLM系列模型对中文代码注释、中文技术文档、中文issue语义的把握明显更自然。第二，团队成员里有人用的是Codex工作流，有人用Continue插件，还有人直接在终端里跑CLI，如果HagiCode只能对接某一种模型，那大家就得各自维护一套配置，这在实际协作中非常割裂。第三，也是最现实的一点——GLM coding plan的7天体验卡性价比很高，在快速原型阶段用它跑批量代码生成任务，比按token计费的国际模型省钱太多，而且国内访问延迟低，体验很稳定。
所以我把这次升级的目标定得很明确：HagiCode作为统一的CLI入口，保留Gemini CLI原生的命令语法和交互体验，同时把GLM-4系列（包含Flash版本）作为一等公民接入，用户通过一条配置命令就能切换后端模型。这个思路推进下来，整个改动量比预想的小很多，因为Gemini CLI本身已经把协议适配层做得比较干净了。
提示：如果你还不熟悉Gemini CLI，可以把它理解成终端里的AI编程助手——你在项目目录里执行
gemini命令，它就能读取项目代码、回答关于代码库的问题、帮你生成代码或者执行代码修改。HagiCode做的多模型支持，相当于给这个助手换上了不同的“大脑”来驱动。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 多模型架构的选型思路：为什么HagiCode选择“兼容层”而不是“重写”
2.1 先看清楚Gemini CLI的能力边界
在动手之前，我把Gemini CLI的能力边界仔细摸了一遍。它的核心机制分三层：命令行交互层负责用户输入和工具调用展示，Agent执行层负责规划任务、调用工具、读写文件，模型适配层负责把请求发给具体的模型服务并解析返回。前两层跟具体模型没什么耦合，真正的关键是第三层——模型适配层决定了你能接哪些模型。
Gemini CLI的模型适配层默认走的是Google GenAI SDK的协议格式，包括generateContent接口、streamGenerateContent流式接口、以及工具调用的functionCall响应格式。这意味着如果要接入GLM，我需要做的不是重新实现一套Agent逻辑，而是写一个协议转换器：把HagiCode内部统一的模型调用请求转换成GLM API的格式，再把GLM返回的流式响应转换回HagiCode期望的格式。
这个决策的好处非常明显。Agent层里已经沉淀了大量实用功能——上下文压缩、文件检索、多轮对话管理、代码diff应用——这些功能如果重写一遍，至少要几周的工期，而且很容易踩坑。采用兼容层方案，我只需要专注在协议转换和模型能力对齐上，两天内就能跑通端到端的流程。
2.2 协议转换中最绕不开的三个字段
在具体实现协议转换时，有三个字段的处理是决定成败的细节。第一个是系统提示词的结构。Gemini API把系统提示词放在system_instruction字段里，而GLM API（兼容OpenAI格式）把它放在messages数组里且role标记为system。看似只是格式迁移，但如果原有提示词里包含工具定义文档，GLM对工具描述的长度和格式就有自己的解析限制，需要做一次截断或重排。
第二个是工具调用的表示方式。Gemini的functionCall返回的是结构化JSON，包含name和args，而GLM的tool_calls也采用了类似的OpenAI风格结构，但有一个关键差异：Gemin