北京
上周二，我注意到Ollama Cloud Pro的配额消耗速度异常快，比平时快得多。七天内烧掉了6.03亿个token，而我甚至不知道它们去了哪里。
我打开Hermes Agent的日志，发现了一个此前完全不知情的存在：一个名为auxiliary的配置块，里面静静躺着十二个后台任务。压缩、网页提取、视觉识别、会话搜索、技能匹配——每当我键入一条消息，它们全都在后台安静地执行。每个任务的提供者都设为自动模式。由于我没有配置备用链路的API密钥，每一项都静默回落到了我的主力模型kimi-k2.6，一个万亿参数模型。
我对这一切毫无察觉。Agent正在向我在聊天中活跃使用的同一个模型发送十一条后台提示，通过同一配额，而且不向我展示这些提示。仅压缩操作在长会话中就会触发10到20次，每次都发送完整的对话历史。
发现问题后我立刻做了修复。我修改了~/.hermes/config.yaml里auxiliary块的配置。更新后的完整YAML见文末。只需要输入/reset或者重启Hermes，配置变更会在新会话中生效。
此前十二个任务全部挤在一个万亿参数模型上，现在它们被分配到六个不同模型上，规模从80亿参数到1万亿参数不等。我在网上搜索了几十个关于Hermes的指南，没有一个提到auxiliary块。官方文档描述了YAML结构，但没有警告说自动提供者模式会静默回落到主力模型。我只找到AI Garage制作的一个视频讨论了这个问题——除此之外什么也没有，没有博客文章，没有Discord讨论串，没有Reddit讨论。
自动回落的链路是：openrouter → new portal → codex → gemini flash。如果这些后端都没有配置API密钥，它就会回落到你的主力聊天模型。所以当我在给k2.6键入一条消息时，Agent正通过同一配额向同一模型发送另外十一条，而且不让我看到提示。我当时订阅了Ollama Cloud Pro，我目录里可用于路由的模型包括多个不同规格。我把它们全部拉取下来，针对这十二个辅助任务做了测试，最终形成了现在的路由分配。
我的Hermes版本有十二个辅助任务。我按实际消耗成本给它们排个序：更早的Hermes版本（比如AI Garage视频里展示的）只有八个任务，而我的版本有十二个——最近更新中添加了四个。配置逻辑简单直接：给每个任务分配不影响正常使用的最轻量模型，而把k2.6留给实际对话。
在确定云端路由方案之前，我曾经尝试在本地运行这些辅助任务。我通过Ollama在机器上拉取了gemma4:e2b，我的显卡是RTX 5070 Ti，8 GB显存，一个60亿参数模型还能装下，两个就已经捉襟见肘。每当Hermes切换任务时，显存就摇摇欲坠。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
