昨天发的Hermes Agent基础安装教程文章后，有眼尖的小伙伴发现了老马截图中的模型配置，其实是unknow的，也就是未知，模型未配置成功。
一开始老马是不知道的，以为配置完成了。毕竟之前配置都是这么操作的，所以就一路猛如虎干就完了。
没想到文章发完后，回头看一下Hermes，想试试没有迁移OpenClaw配置的情况下，原来的Agent人格设定是咋样的，结果就发现翻车了。
查来查去，大概可能是Hermes在更新版本之后，不支持Coding Plan的接入了。之前老马自己主力电脑上的Hermes能够接入，当时还是老版本。
不过也不排除厂商的Coding Plan不支持某些Agent，但想想不会，主力电脑上的Hermes就正常跑着，所以估计是Hermes的问题。
加上手头上只有阿里云的Coding Plan，没有其它家的，因此也无法确认其它家的是否支持，有测过的小伙伴可以在评论区反馈一下。
通过这一次的模型配置翻车，老马又深入地学习了一下Hermes的模型配置机制，发现比OpenClaw要复杂一点，要绕一点。
虽自认为是老司机，以前也配置过OpenClaw多模型的机制，但跟Hermes还真不一样。这就有点像你又买了个新游戏，又要开始研究底层玩法，怎么去通关了。
所以有关Hermes的模型配置问题，老马觉得有必要单独用一篇文章给小伙伴介绍一下，以免在实际使用的过程中遇到了，摸不着头脑。
别笑，真的是如此。按照日志提示，老马运行hermes model去修改设置了默认模型了，结果发现还是不行，就这样来来回回不断测试。
绕了很大一圈，再去查看官方文档，加上原来主力电脑上的配置文件，丢给AI辅助分析，才算是基本搞懂了里面的机制。
Hermes模型配置的五层机制
以Windows系统为例，Hermes的配置文件路径一般位于：C:\Users\你的用户名\AppData\Local\hermes，主要是config.yaml和.env两个文件。
yaml文件是一种以数据为中心的配置文件，yaml是json的超集，这意味着json能表达的数据，yaml都能表达，而且通常更简洁。
.env文件是一个专门用于存储项目环境变量和配置信息的纯文本文件。像OpenClaw的主配置文件是OpenClaw.json，Hermes就是config.yaml。
介绍完基本的文件，下面开始正式了解Hermes模型配置的五层机制。
第一层：主模型
使用vs code、记事本等工具打开config.yaml文件后，顶部的一段配置，就是主模型的，你平时跟Hermes聊天，主要就是调这里的模型：
主模型的配置内容示例如下：
model:
default: z-ai/glm-5.1
provider: majiabin
base_url: https://api.majiabin.com/v1
api_key: 你的api key
api_mode: chat_completions
以上配置内容翻译成大白话如下：
我要用majiabin这个服务商；
模型叫z-ai/glm-5.1；
接口地址是https://api.majiabin.com/v1；
它是OpenAI兼容接口，所以api_mode用chat_completions。
这算是整个模型配置中最重要的一段，因此如果你出现模型unknow未知的情况，或者模型不可用的情况，就得来看看这里的配置有没有问题。
在Hermes的安装流程中，哪怕你的模型配置是有问题的，默认是会帮你跳过的，并不会卡在那里，这就会让你产生误判。
最终你得在安装完成之后，跟Hermes进行对话，来判断模型配置是否正确，而yaml文件的修改要比json的简单，没那么多括号和引号的格式要求。
第二层：providers模型服务商通讯录
providers位于主模型配置内容的下方，一般是为空的。这个只有在Hermes新版里面才有的，老版的老式配置文件里面没有：
如上图所示，老马在providers这里是填写了模型服务商的配置内容，并不是为空。其实无所谓，为空也是可以的。
因为providers的作用就是跟电话本、通讯录一样，它只负责登记的作用，并不会起到模型轮询的作用。模型轮询的另外一层，下面会讲到。
providers的配置内容示例如下：
providers:
majiabin:
name: MAJIABIN
api: https://api.majiabin.com/v1
transport: openai_chat
default_model: z-ai/glm-5.1
以上配置内容翻译成大白话如下：
majiabin这个名字，对应哪个API地址、用什么协议、默认模型是什么。
这里majiabin就是一个服务商的名字，对应的API地址，协议，默认模型，按以上格式进行登记，所以它可登可不登。
第三层：fallback机制
fallback机制非常好理解，就是当主模型不能用的时候，自动切换到备用模型去使用，也叫模型的轮询机制：
从上图可以看出，fallback的默认配置是为空的。假设你需要配置多个备用模型的时候，就可以删除掉括号，往下面添加其它模型的配置内容了。
比如你现在的主模型配置内容是：
model:
default: z-ai/glm-5.1
provider: majiabin
如果majiabin这个服务商的API临时挂了、限流、余额不足、接口503、网络连不上时，Hermes就可以尝试备用provider/model，而不是直接中断使用，那么配置内容示例如下：
fallback_providers:
- provider: openrouter
model: anthropic/claude-sonnet-4.5
- provider: laoma
model: moonshotai/kimi-k2.5
以上配置内容翻译成大白话如下：
主模型调用失败后，先尝试调用OpenRouter的Claude模型。如果还不行，再去尝试laoma的kimi k2.5模型。
在上述的fallback_providers中，是可以写一串多个的备用模型的。这时有小伙伴就会问了，如果fallback_providers设置了多个备用模型，那备用模型的API Base URL跟API Key要怎么填写呢？
这个问题问得好，还记得前面第二层提到的providers模型提供商通讯录么，我们的备用模型就可以在它下面补充对应的API Key：
providers:
majiabin:
name: MAJIBIN
api: https://api.majiabin.com/v1
transport: openai_chat
default_model: z-ai/glm-5.1
key_env: MAJIBIN_API_KEY
backup_openrouter:
name: OpenRouter Backup
api: https://openrouter.ai/api/v1
transport: openai_chat
default_model: anthropic/claude-sonnet-4
key_env: OPENROUTER_API_KEY
backup_other:
name: Other Backup
api: https://your-other-api.example.com/v1
transport: openai_chat
default_model: some/model-name
key_env: OTHER_API_KEY
以上配置内容翻译成大白话如下：
providers.majiabin.api写MAJIBIN的URL，providers.backup_openrouter.api写 OpenRouter 的 URL，providers.backup_other.api写另一个备用服务商的URL。每个provider自己通过key_env 去 .env里找对应API key。
后面更多的备用模型老马就不再添加了，以此类推，需要用到几个备用模型，你就根据这样的格式去添加几个。
细心的小伙伴也发现了，这里的API Key不是直接写出来的，而是要通过key_env去.env文件里面找对应的API key，这就引出了下一层机制。
第四层：.env文件
.env不是主模型配置的首选位置，它是各大模型API Key存储的地方，可以称之为钥匙柜：
比如下面的示例配置内容：
OPENROUTER_API_KEY=...
OPENAI_API_KEY=...
ANTHROPIC_API_KEY=...
翻译成大白话，这些变量的意思是：
如果Hermes要用OpenRouter的模型，这里有OpenRouter的API key。
如果Hermes要用OpenAI的模型，这里有OpenAI的API key。
如果Hermes要用Anthropic的模型，这里有Anthropic的API key。
所以在第三层的备用模型配置内容中，我们才会设置key_env去.env文件里面找对应的API key，毕竟把API Key保存在环境变量文件中，就好像把钥匙存在钥匙柜里面，比直接写在配置文件里，要安全得多。
第五层：辅助任务模型
Hermes作为一个AI Agent框架，它的作用当然不止是像Chat Bot那样只能陪你聊天，它还会偷偷做一些后台任务，比如压缩上下文、总结记忆、搜索历史会话、网页内容提取、技能搜索、危险命令审批等。
拿压缩任务举例，在config.yaml文件中，也能找到这段配置内容：
我们只看模型配置那一部分，示例配置内容如下：
compression:
summary_model: google/gemini-3-flash-preview
summary_provider: auto
summary_base_url: null
以上配置内容翻译成大白话如下：
当聊天内容太长、上下文快塞不下的时候，Hermes会找一个模型来帮你把前面的聊天记录压缩成摘要。
summary_model: google/gemini-3-flash-preview的意思是：压缩摘要时，优先用google/gemini-3-flash-preview这个模型来做总结。
summary_provider: auto的意思是：让Hermes自己判断这个模型应该走哪个提供商，不手动指定provider。
summary_base_url: null的意思是：这里不单独指定API地址，继续使用Hermes自动推断出来的默认地址。
简单说就是，这不是你的主聊天模型配置，而是聊天太长时，用哪个模型来帮忙做摘要压缩的配置。假设老马现在的主模型是z-ai/glm-5.1，但压缩摘要时可能会尝试用gemini-3-flash-preview。
还有一点是summary_provider: auto，Hermes会自己去判断，自己去猜测用哪个模型提供商。这时就会去翻.env的钥匙柜，看看有哪家提供商在这里存了API Key，有哪家的钥匙，就用哪家。
说到这里，又有聪明的小伙伴会提问了。如果compression这里本身就没有配置gemini-3-flash-preview模型，况且这只是优先的配置模型。
那Hermes就会auto自动去找，上面也说过，会去.env文件钥匙柜里面找钥匙。但是钥匙柜里面也没有钥匙的话，就会使用主模型来压缩摘要了。
你可能会觉得有点绕，但没关系，从第一层机制看到第五层，串起来理解，基本就能了解个大概了。
末了总结两句
老马翻车的时候，原因比这个还绕。一方面config.yaml文件中还残留着旧格式的模型配置内容，同时新版本又引入了新格式的模型配置内容。
话说Hermes是Nous Research这家做大模型的公司正规军开发开源的，有时候有些操作还是有点草台班子的味道，新旧格式混在一起，估计是为了做过渡迁移，但同时也造成了混乱。
另外一方面阿里云的Coding Plan接入失败后，老马又尝试了接入openrouter，结果有些免费模型不可用，索性弃用，更换另外一家模型提供商。
但这又导致openrouter的API Key残留在.env文件中。当主模型因为新旧格式不正确不可用的时候，又会去自动查.env文件，循环绕回openrouter，继续不可用。
所以说，任何一个新的开源AI Agent，都如同一个新游戏，里面的底层玩法，存在的bug，配置使用的不稳定性，都是无法预估的，这些坑只能你自己亲身去踩，才有收获。
对于Hermes Agent接下来还有哪些值得折腾的地方，敬请期待老马的更新，我们又将开启一程新的赛博养马之旅。
