GLM-5.1 全面支持与 Gemini CLI 集成：HagiCode 的多模型进化之路

本文介绍了 HagiCode 平台近期的重要更新，智谱 AI GLM - 5.1 模型得到了全面支持，Gemini CLI 成功地作为第十个 Agent CLI 被集成，这是 GLM - 5.1 全面支持并与 Gemini CLI 集成的情况，两项更新进一步强化了平台的多模型能力和多 CLI 生态，这里说的是此文中讲述这样场景当时的背景陈述。

时间流逝极为迅速，大语言模型的进展恰似春天里的竹子那般，飞速地向上猛长。往昔我们还在为“一个能够编写代码的AI”而满心欢喜，如今已然是多个模型协同合作、多种工具相互融合的时段了。这具备趣味性吗？大概是这样吧，毕竟开发者所需求的向来都不单单是工具自身，而是一种能够适配各种各样场景、灵活自如进行切换的从容自在。

HagiCode，身为一个 AI 辅助编码平台，于近期，算是迎来了两件重要之事，其一呢，是智谱 AI 的 GLM - 5.1 模型实现了全面接入，其二呢，是 Gemini CLI 正式成为了被支持的第十个 Agent CLI。这两件事情，要说大，好像也没那么大，要说小，其实也不算小，只是就平台的完善来讲，终究算是一件挺好的事情。

智谱AI的最新旗舰模型是GLM - 5.1，相较于GLM - 5.0，其推理能力变得更强，对代码的理解更为深入，工具调用也愈发顺滑。更为关键的是，它身为首个支持图片输入的GLM模型，这意味着什么呢？意味着用户能够直接截图让AI查看问题，无需再费尽周折地进行描述了。这种便利性，使用过后便会明白。

在此同一时间，HagiCode借助HagiCode.Libs.Providers架构，将Gemini CLI成功予以集成。这属于第十个Agent CLI，老实讲，能够来到这般地步，也仅仅多少有那么一点儿成就感而已。

须得提及的是，HagiCode具备的图片上传功能，使得用户能够直接做出截图，进而与AI展开交流。即便运行的是GLM 4.7版本，该平台依旧能够实现良好运行 ，而且已然助力项目完成了诸多关键的构建工作。至于GLM - 5.1？那必然会朝着更优方向发展。

关于 HagiCode

分享于这里的方案源自我们于HagiCode项目里的实践经历，HagiCode是个开源的AI辅助编码平台，其目的在于借由多模型、多CLI的架构设计，给开发者予以灵活、强大的AI编程助手，项目地址是github.com/HagiCode-org/site。

多 CLI 架构设计

作为 HagiCode 的核心优势当中的一个，借助统一的抽象层去支持多种不同的 AI 编程 CLI 工具。这种设计具备的好处，说白了也就是如此这般：新的事物能够进入进来，旧有的事物能够留存下来，并且代码不会出现混乱的情况。毕竟，哪个人不期望生活可以呈现出这样的状态呢？

AIProviderType 枚举

支持的 CLI 提供商类型，是由平台借助 AIProviderType 枚举开展定义的。

public enum AIProviderType
{
    ClaudeCodeCli = 0,    // Claude Code CLI
    CodexCli = 1,          // GitHub Copilot Codex
    GitHubCopilot = 2,     // GitHub Copilot
    CodebuddyCli = 3,     // Codebuddy CLI
    OpenCodeCli = 4,      // OpenCode CLI
    IFlowCli = 5,         // IFlow CLI
    HermesCli = 6,        // Hermes CLI
    QoderCli = 7,         // Qoder CLI
    KiroCli = 8,          // Kiro CLI
    KimiCli = 9,          // Kimi CLI
    GeminiCli = 10,       // Gemini CLI (新增)
}

能够瞧见，Gemini CLI 身为第十个成员迈入了这个大家庭，每一个 CLI 均具备独特的特性以及适用的场景，用户能够依据自身的需求灵活地去选择，毕竟，条条大路通罗马，只是有的路走起来比较顺畅一些，有的路略微曲折一些而已。

Provider 架构

由 HagiCode.Libs.Providers 所提供的是统一的 Provider 接口，这使得每个 CLI 的集成变得规范且简洁，就以 Gemini CLI 作为例子来说：

public class GeminiProvider : ICliProvider
{
    private static readonly string[] DefaultExecutableCandidates = ["gemini", "gemini-cli"];
    private const string ManagedBootstrapArgument = "--acp";
    public string Name => "gemini";
    public bool IsAvailable => _executableResolver.ResolveFirstAvailablePath(DefaultExecutableCandidates) is not null;
}

这种设计的好处是：

说白了，这般设计实际上就是将繁杂之事予以简化，从而令生活略微轻松一些而已。

Provider Registry

供应商注册处，自动开展别名映射工作，同时进行注册操作：

if (provider is GeminiProvider)
{
    registry.Register(provider.Name, provider, ["gemini-cli"]);
    continue;
}

这表明，用户能够运用gemini或者gemini-cli上述这两种途径，去调用Gemini CLI，而系统会自行进行识别。这恰似你朋友众多，有的被称作大名，有的被唤做小名，不管怎样讲的都是他，无论怎样称呼均可。

GLM-5.1 模型支持

智谱AI的最新旗舰模型是GLM - 5.1，HagiCode针对它完成了全面的支持。

Secondary Professions Catalog

HagiCode借助Secondary Professions Catalog对所有支持的模型予以管理。以下所呈现的是GLM系列的配置：

关于模型的标识，名称，所支持的图像，以及与之兼容的命令行界面家族型号。

glm-4.7

GLM 4.7

glm-5

GLM 5

claude, codebuddy, hermes, qoder, kiro

glm-5-turbo

GLM 5 Turbo

claude, codebuddy, hermes, qoder, kiro

glm-5.0

GLM 5.0 (Legacy)

claude, codebuddy, hermes, qoder, kiro

glm-5.1

GLM 5.1

true

claude, codebuddy, hermes, qoder, kiro

GLM-5.1 的关键特性可以总结为：

GLM-5.1 vs GLM-5.0

依据代码的层面予以观察，GLM - 5.1 和 GLM - 5.0 的关键差异之处在于。

// GLM-5.0 (Legacy) - 有特殊保留逻辑
private const string Glm50CodebuddySecondaryProfessionId = "secondary-glm-5-codebuddy";
private const string Glm50CodebuddyModelValue = "glm-5.0";
// GLM-5.1 - 独立的新模型标识
private const string Glm51SecondaryProfessionId = "secondary-glm-5-1";
private const string Glm51ModelValue = "glm-5.1";

带有“A legacy”标记的GLM - 5.0是为做能够有向后兼容性状况而被保存下来的旧版本标识，相反GLM - 5.1在于那是全新独立版本不存在任何历史包袱，比如有些人老是会处在往昔之中，然而另外有些人则是能够轻装上阵从而行进得更快而已。

配置 GLM-5.1

在 HagiCode 中使用 GLM-5.1 的配置示例：

{
  "primaryProfessionId": "profession-claude-code",
  "secondaryProfessionId": "secondary-glm-5-1",
  "model": "glm-5.1",
  "reasoning": "high"
}

图片上传功能

HagiCode，其具有的支持图片展示的这一情况，是借助SecondaryProfession来达成的，会通过该SecondaryProfession所拥有的SupportsImage属性来予以实现的：

public class HeroSecondaryProfessionSettingDto
{
    public bool SupportsImage { get; set; }
}

于Secondary Professions Catalog里，GLM - 5.1的配置情况是这样的：

{
  "id": "secondary-glm-5-1",
  "supportsImage": true
}

这意味着用户可以直接上传截图让 AI 分析，比如：

不再需要手动去描述问题啦，直接进行截图就可以了——这个功能所具备的便利性，用过之后便会知晓。毕竟呀，存在一些事情，讲述再多都比不上看那么一眼。

Gemini CLI 集成

Gemini CLI，是第十个 Agent CLI，借助标准的 Provider 架构，被集成到 HagiCode 里面。

配置选项

Gemini CLI 支持丰富的配置选项：

public class GeminiOptions
{
    public string? ExecutablePath { get; set; }
    public string? WorkingDirectory { get; set; }
    public string? SessionId { get; set; }
    public string? Model { get; set; }
    public string? AuthenticationMethod { get; set; }
    public string? AuthenticationToken { get; set; }
    public Dictionary AuthenticationInfo { get; set; }
    public Dictionary EnvironmentVariables { get; set; }
    public string[] ExtraArguments { get; set; }
    public TimeSpan? StartupTimeout { get; set; }
    public CliPoolSettings? PoolSettings { get; set; }
}

从包含基本方面的各类选项，到体现高级特性的种种设定，这些选项全面覆盖了各个领域，用户能够按照自身需求做出灵活的配置选择。毕竟，每个人的需求都并非相同，具备更为灵活一点的性质总是比较好的。

ACP 通信协议

Gemini CLI 对 ACP（Agent Communication Protocol）通信协议予以支持，此乃 HagiCode 所统一的 CLI 通信标准，借由 ACP，各异的 CLI 能够以一致的方式同平台展开交互，极大地简化了集成工作，说白了，便是将复杂之事予以统一化，使得众人都能够轻松些许而已。

环境配置

使用智谱 AI 的模型，需要配置相应的环境变量。

智谱 AI ZAI 平台

export ANTHROPIC_AUTH_TOKEN="your-zai-api-key"
export ANTHROPIC_BASE_URL="https://open.bigmodel.cn/api/anthropic"

阿里云 DashScope

export ANTHROPIC_AUTH_TOKEN="your-aliyun-api-key"
export ANTHROPIC_BASE_URL="https://coding.dashscope.aliyuncs.com/apps/anthropic"

当完成配置然后，HagiCode便能够正常去调用GLM - 5.1模型了。这件事情讲难其实并非难矣，讲简单其实亦非简单呀，总之依照着去做便是了。

HagiCode 自身构建实践

提及实践，具备最佳示例性质的便是 HagiCode 平台自身所拥有的构建流程，HagiCode 的开发流程对 AI 能力进行了充分运用：

使用 GLM 4.7 即可良好运行

HagiCode平台在设计方面有着相当不错的优化成果，哪怕是运用GLM 4.7，同样能够收获良好的开发体验感受，而且该平台已然协助完成了多个重要的构建项目，其中涵盖了：

这实际上也还算不错，毕竟压根不是所有的人都非得要用最新的事物。契合自身的，才是最为出色的。

GLM-5.1 事半功倍

升级到 GLM-5.1 后，这些能力将得到进一步增强：

将其类比，就如同从骑行的自行车转而乘坐汽车，二者所能抵达的地点是相同的，两者之间仅仅是速度存在差异以及舒适度有所不同而已。

多 CLI 集成最佳实践

HagiCode.Libs.Providers给出了统一的登记以及运用机制：

services.AddHagiCodeLibs();
var gemini = serviceProvider.GetRequiredService>();
var codebuddy = serviceProvider.GetRequiredService>();
var hermes = serviceProvider.GetRequiredService>();

呈现出的这种依赖注入的设计，于各个 CLI 的运用层面而言，致使其变得极为简洁，并且还便于去开展单元测试以及进行模拟，毕竟这一点，代码编写能够保持干净程度稍高一点，实际上对于自身来讲也是算作一种负责的表现，这是毋庸置疑的。

注意事项

在实际使用中，有几个地方需要注意：

API Key配置得确保正确设置ANTHROPIC_AUTH_TOKEN，不然就没办法调用模型，模型可用性方面GLM - 5.1得在对应的模型提供商那儿开通权限，图片功能是只有支持supportsImage: true的模型才能够使用图片上传功能，CLI安装是在使用Gemini CLI之前，要确保gemini或者gemini cli在系统PATH中。

这些均为小事，然而，若小事处理得不妥当，那么，也是会有可能转变为大事的。故而，仍旧是需要留意一下的。

总结

凭借GLM - 5.1的全方位支持，以及Gemini CLI的成功整合，HagiCode进一步巩固了自身作为具备多模型、多CLI特性的AI编程平台的能力，这些更新不但给予用户更多的挑选余地，还彰显了HagiCode在架构设计方面的前瞻性与可扩展性。

GLM - 5.1具备的图片支持能力，与HagiCode的截图上传功能相结合，使得“看图说话”得以实现。这大大降低了问题描述所需的成本。并且，十个CLI得到支持，这意味着用户能够依据自身的偏好以及场景，灵活地挑选最为合适的AI编程助手。毕竟，选择增多总归是件好事。

最关键的是，HagiCode平台本身的搭建实践证实，就算运用GLM 4.7，平台仍旧能够顺畅运行并达成繁杂任务，然而升级至GLM - 5.1之后，开发效率会获得更进一步的提高。这仿佛如同人生那般，并非一定得去追寻最优，契合自身的便好。当然，要是能够在契合自身的基础之上变得更佳，那无疑更为美妙。

倘若你对具备多模型以及多 CLI 的 AI 编程平台怀有兴趣，这般情况下不妨尝试一下 HagiCode，它是开源的，是免费的，并且处于持续进化之中。总之尝试一下并不会耗费资金，要是果真契合你呢？

参考资料

如果本文对你有帮助：

相关标签： # GLM-5.1 # HagiCode # 多模型 # GeminiCLI # AI编程助手