Hermes Agent成本控制实战：模型路由与凭据轮换及Token追踪

Hermes Agent 能跑起来并不让人意外，真正让人意外的，是跑了一个月之后看到账单时还能保持淡定。

社区里流传最广的故事通常是这样的：装好了 Hermes，对接上 Anthropic API，勤奋地跑了一周，一看账单——$137 没了。问题并不出在 Hermes 本身，它是开源免费的，用的是 MIT 许可证。真正的症结在于没有做成本工程。一个未经优化的 Hermes 实例，光是 72 个工具的 Schema，每轮对话就要吃掉 19,210 个 Token；而辅助压缩任务默认跟主模型走同一条线路，一旦主模型被限流，压缩也跟着崩溃，整个对话上下文瞬间丢失。

这篇文章不谈省钱的「心态」，只给可落地的配置。一套系统化的方案，能把月费从 $200 压到 $5 以下。核心的技术手段包括：Provider Routing 用六种排序策略挑选最便宜的子提供商、Credential Pools 用四种轮换策略确保限流不会中断会话、辅助模型独立配置来防止压缩风暴、Tool Search 延迟加载砍掉 89% 的固定 Token 开销，以及 execute_code 让中间结果不再进入上下文窗口。

如果你还没装 Hermes，建议先看 Hermes Agent 完全指南把基础架构搞清楚，再回来做成本优化。

Provider Routing：OpenRouter 内部的子提供商路由

Provider Routing 控制的是 OpenRouter 内部子提供商（比如 Anthropic、Google、AWS Bedrock、Together AI 等）如何处理你的请求。它和 Fallback Providers——也就是跨提供商的故障转移——是两个完全独立的维度。简单理解，Provider Routing 是同一个平台内部的路由优化，而 Fallback Providers 是主模型整体失败时切换到完全不同的提供商。

配置结构

provider_routing 控制六个维度：排序策略、提供商白名单、黑名单、显式优先级、参数兼容性过滤和数据收集权限。

提示词：生成 Provider Routing 配置

请帮我生成 Hermes 的 provider_routing 配置块。要求包含以下六个字段：

• sort：排序策略，可选值 price（按价格）、throughput（按吞吐量）、latency（按延迟）
• only：白名单数组，只使用列表中的提供商，留空表示不限制
• ignore：黑名单数组，永不使用列表中的提供商
• order：显式优先级顺序数组，按顺序依次尝试
• require_parameters：布尔值，设为 true 时仅路由到支持请求中所有参数的提供商
• data_collection：控制数据收集，可选值 allow 或 deny，留空表示使用提供商默认行为

六种排序策略的选择逻辑

sort 字段有三个值，再搭配 only、ignore、order 三个过滤器，可以组合出六种常见策略：

策略组合	配置	适用场景
纯价格优先	sort: "price"	高流量开发、成本敏感
纯吞吐量优先	sort: "throughput"	长文本生成、批量任务
纯低延迟优先	sort: "latency"	交互式对话、终端实时使用
价格优先 + 白名单	sort: "price" + only: [...]	只在信任的提供商中选最便宜的
显式排序 + 兜底	order: ["Anthropic", "Google"]	优先 Anthropic，满载时切 Google
隐私保护型	ignore: ["Together", "Lepton"] + data_collection: "deny"	不想数据流向某些提供商

实战配置示例

成本优化（日常编码推荐）：

provider_routing:sort: "price"

一行配置，让 OpenRouter 自动选择当前最便宜的子提供商。适合写代码、跑任务这类对延迟不敏感的场景。

速度优化（交互对话推荐）：

provider_routing:sort: "latency"

当你在终端里和 Hermes 对话时，首 Token 延迟直接影响体验。latency 模式会优先选择响应最快的子提供商。

指定优先顺序 + 参数完整性保障：

提示词：生成指定优先顺序的 Provider Routing 配置

请帮我生成 provider_routing 配置。要求：

• order 指定优先顺序：先走 Anthropic，满载时切 Google
• require_parameters 设为 true，确保只路由到支持所有请求参数的提供商

先走 Anthropic，满载时切 Google。开启 require_parameters 后，可以避免因为某个子提供商不支持 temperature 或 top_p 而返回错误。

隐私保护型：

提示词：生成隐私保护型 Provider Routing 配置

请帮我生成 provider_routing 配置。要求：

• ignore 拉黑不信任的提供商：Together、Lepton
• data_collection 设为 deny，关闭数据收集

如果你对数据流向有要求，用 ignore 把不信任的提供商拉黑，再用 data_collection: "deny" 从全局层面关闭数据收集。

生效范围

需要特别说明的是，Provider Routing 仅在使用 OpenRouter 时生效。直连 Anthropic API 或 DeepSeek API 时，这套配置无效——因为你已经确定了提供商，不存在「路由」的问题。通过 Nous Portal 路由的流量同样会尊重 routing 配置，而且 Portal 订阅者还能额外享受 10% 的 Token 折扣。

技术实现

路由配置在创建 AIAgent 时作为参数传入：

providers_allowed← provider_routing.onlyproviders_ignored← provider_routing.ignoreproviders_order← provider_routing.orderprovider_sort← provider_routing.sortprovider_require_parameters ← provider_routing.require_parametersprovider_data_collection← provider_routing.data_collection

这些参数最终会附加到发往 OpenRouter 的 HTTP 请求头中，由 OpenRouter 的路由层来执行实际的选择。

Fallback Providers：三层韧性架构

一个提供商不够用，三层才够稳。Hermes 的韧性体系由三层防线组成：

1. 凭据池（Credential Pools）：同一提供商内多 API Key 轮换——这是第一层防线
2. 主模型降级（Primary Model Fallback）：主模型失败后自动切换到不同提供商/模型
3. 辅助任务降级（Auxiliary Task Fallback）：视觉、压缩、网页提取等辅助任务各自拥有独立的提供商解析链

主模型降级配置

fallback_providers:- provider: openroutermodel: anthropic/claude-sonnet-4

触发降级的条件如下：

HTTP 状态码	行为
429 限流	重试后触发
500/502/503 服务端错误	重试后触发
401/403 认证失败	立即触发
404 模型未找到	立即触发
无效响应	多次后触发

这里有一个关键设计需要注意：降级是按「轮次」进行的，而不是按「会话」。每次用户发送新消息，Hermes 都会从主模型开始尝试。如果主模型在当前轮次中失败，降级只对本轮生效，下一轮会重新尝试主模型。而且单轮内最多只降级一次——如果降级也失败，就走正常错误处理流程。这个设计有效防止了级联降级循环，同时每轮都给主模型一个恢复的机会。

辅助任务降级

每个辅助任务都有独立的提供商解析链，这是成本控制的核心战场：

任务	功能	配置键
Vision	图片分析	auxiliary.vision
Web Extract	网页摘要	auxiliary.web_extract
Compression	上下文压缩	auxiliary.compression
Skills Hub	技能搜索	auxiliary.skills_hub
MCP	MCP 辅助操作	auxiliary.mcp
Approval	命令审批分类	auxiliary.approval
Title Generation	会话标题	auxiliary.title_generation
Triage Specifier	Kanban 任务细化	auxiliary.triage_specifier

auto 模式探测链（文本任务）：

OpenRouter → Nous Portal → Custom endpoint → Codex OAuth →API-key providers (z.ai, Kimi, MiniMax, 小米, Hugging Face, Anthropic) → give up

auto 模式探测链（视觉任务）：

Main provider (if vision-capable) → OpenRouter → Nous Portal →Codex OAuth → Anthropic → Custom endpoint → give up

容量错误降级

当显式设置的辅助提供商遇到容量级别的错误（比如 402 余额不足、429 日配额耗尽、连接失败）时，会触发四层降级链：

1. 主辅助提供商（你配置的那个）
2. auxiliary..fallback_chain（可选的自定义链）
3. 主 Agent 的提供商 + 模型（兜底）
4. 警告 + 重新抛出

这里有一个关键区分点：短暂的 HTTP 429 限流（带 Retry-After 头）不会触发降级——Hermes 会尊重你的显式选择，等待重试。只有日/月配额耗尽、支付错误和连接失败才会绕过显式提供商。

委派提供商覆盖

子袋里（通过 delegate_task 创建的）会继承父袋里的降级链，但可以用更便宜的模型：

delegation:provider: "openrouter"model: "google/gemini-3-flash-preview"

这是一个很容易被忽略的降本点：子袋里的任务通常比主任务简单，完全没必要用同等昂贵的模型。

Hermes 支持的提供商

截至撰稿时，Hermes 支持 30+ 个提供商：OpenRouter、Nous Portal、OpenAI Codex、GitHub Copilot、Anthropic、z.ai（GLM）、Kimi/Moonshot、MiniMax、DeepSeek、NVIDIA NIM、Google Gemini（OAuth 和 API Studio 两种）、xAI/Grok、AWS Bedrock、Qwen Portal、Alibaba/DashScope、腾讯 TokenHub、Microsoft Foundry、LM Studio（本地模型）、Hugging Face、Custom endpoint 等。完整列表见 Hermes 完全指南 和 本地模型集成。

Credential Pools：同提供商多 Key 轮换

凭据池是三层韧性架构的第一层防线。它允许为同一提供商注册多个 API Key 或 OAuth Token。当一个 Key 触发限流或计费配额时，Hermes 会自动轮换到下一个健康的 Key——保持会话不中断，同时也不切换提供商。

请求流程

请求进入→ 从凭据池选择 Key（round_robin / least_used / fill_first / random）→ 发送到提供商→ 429 限流？→ 计划/用量限制？ → 立即轮换到下一个 Key→ 通用/瞬时 429？ → 同一 Key 重试一次 → 第二次 429 → 轮换→ 全部 Key 耗尽 → 触发 fallback_model（不同提供商）→ 402 计费错误？ → 立即轮换（24 小时冷却）→ 401 认证过期？ → 先尝试刷新 Token → 刷新失败 → 轮换→ 成功 → 正常继续

四种轮换策略

策略	行为	适用场景	配置值
fill_first（默认）	用第一个健康 Key 直到耗尽，再用下一个	单主力多备份	fill_first
round_robin	均匀轮换，每次选择后轮转	多 Key 均匀分摊	round_robin
least_used	总是选请求计数最低的 Key	长期均衡	least_used
random	在健康 Key 中随机选择	简单场景	random

配置方式：

提示词：生成凭据池轮换策略配置

请帮我生成 credential_pool_strategies 配置块。要求按提供商分配轮换策略：

• openrouter：round_robin（多 Key 均匀分摊负载，OpenRouter 通常有多个计费 Key）
• anthropic：least_used（长期均衡使用，保持各 Key 用量一致）
• deepseek：fill_first（单主力多备份，用完一个再换下一个，方便追踪单 Key 用量）

错误恢复机制

错误类型	Hermes 行为	冷却时间
429 限流（瞬时）	同一 Key 重试一次，第二次连续 429 轮换	1 小时
429 限流（配额）	立即轮换	1 小时
402 计费/配额耗尽	立即轮换	24 小时
401 认证过期	先尝试刷新 OAuth Token，刷新失败才轮换	无
全部 Key 耗尽	降级到 fallback_model（跨提供商）	无

快速上手

# 添加第二个 OpenRouter Keyhermes auth add openrouter --api-key sk-or-v1-your-second-key# 添加第二个 Anthropic Keyhermes auth add anthropic --type api-key --api-key sk-ant-api03-your-second-key# 添加 DeepSeek Keyhermes auth add deepseek --type api-key --api-key sk-ds-your-key# 查看凭据池状态hermes auth list# 交互式凭据管理hermes auth

自动发现

Hermes 启动时还会从多个来源自动发现凭据：

来源	示例	自动发现
环境变量	OPENROUTER_API_KEY	是
OAuth Token（auth.json）	Codex device code	是
Claude Code 凭据	~/.claude/.credentials.json	是（Anthropic）
手动添加	hermes auth add	持久化到 auth.json

这意味着如果你的机器上同时装了 Claude Code 和 Hermes，Hermes 会自动发现 Claude Code 的 Anthropic 凭据——不需要手动复制 Key。

委派和子袋里共享

• 同一提供商：子袋里会获得父袋里的完整凭据池，可在限流时轮换 Key
• 不同提供商：子袋里加载该提供商自身的凭据池
• 每任务凭据租赁确保子袋里并发轮换时不冲突

已知问题：Fallback 共享凭据池

GitHub Issue #33088 指出一个需要注意的问题：当 fallback 提供商和主提供商使用同一个平台时（比如都走 OpenRouter），fallback 的 429 错误会消耗主池中的 Key。目前的修复方向是：池在 fallback 共享同提供商时保留（多 Key 轮换是设计意图），在切到不同提供商时清除。所以使用时建议尽量把 fallback 配成不同平台的提供商。

Token 追踪：三层可见性

钱花在哪里了？这个问题需要从三个层面来回答。

微观层：每次调用

• 每次 LLM 调用的 prompt token 和 completion token
• 使用的模型标识
• 按当前模型单价换算的美元成本

中观层：每次对话

• 端到端交互的总 token 数和总成本
• 上下文窗口利用率（已用 / 总容量）

宏观层：每个步骤

• Agent 循环中每个 span 的 token 计数
• 排序 trace 找到最贵的步骤
• 子袋里 span 汇总其子 span 的 token 使用

Hermes 内置追踪

Hermes TUI 的 /agents 叠加层提供了相当实用的功能：

• 运行中和已完成子袋里的实时树状视图
• 每分支的成本、token 和文件变更汇总
• 终止和暂停控制——可以中途取消正在烧钱的子袋里
• 事后审查：逐轮浏览每个子袋里的工具调用历史

对日常使用来说，这个内置功能已经够用了。但它有一个明显的硬伤：跟 OpenRouter 的定价层耦合在一起。GitHub Issue #19469 指出，使用直连提供商（Anthropic、Bedrock、自定义端点等）时，成本报告会出现断裂。

外部追踪工具选型

如果需要更精细的成本归因，可以搭配外部工具：

工具	类型	核心能力	适合场景
Langfuse	开源	Observation 级 Token + 成本追踪，Prompt 管理	最成熟的开源选择，适合自托管
Opik（Comet）	开源	Span 级追踪，自动成本计算，内置提供商价格表	开源替代方案
LiteLLM	开源	100+ 提供商统一袋里，虚拟 Key 预算管理	作为 Hermes 前置成本控制网关
Braintrust	商业	三层可见性，Agent trace 每步归因	Agent 循环中精确的 Token 归因
Bifrost（Maxim AI）	商业	层级虚拟 Key，语义缓存，自动限额	替代 LiteLLM 的 Hermes 前置网关

关键陷阱：跨提供商 Tokenizer 不一致

这里有一个很容易踩的坑：不同提供商使用的是不同的分词器（Tokenizer）。本地 token 估算可以用于规划，但生产报告必须依赖提供商响应中返回的 usage 字段。跨提供商的估算误差足以扭曲成本比较、路由决策和上下文窗口告警。

上下文压缩与缓存：每轮省 75%

Hermes 的压缩系统是一条五阶段流水线，设计目标是在保留关键信息的前提下，最大限度减少上下文窗口的占用。

五阶段压缩流水线

阶段一：工具结果剪枝（无 LLM 调用）

三个子步骤，全部基于规则，不消耗 Token：

1. 去重：对工具结果做 MD5 哈希，>200 字符的重复内容替换为 "[Duplicate tool output]"
2. 摘要化：20+ 个工具专用处理器。npm test 的 47 行输出变成 "[terminal] ran npm test → exit 0, 47 lines"；1,200 字符的文件读取变成 "[read_file] read config.py (1,200 chars)"
3. 参数截断：>500 字符的工具调用参数按 JSON 感知方式截断，防止 JSON 断裂导致无限重试循环

阶段二：边界确定

保护头部（前 3 条消息）和尾部（约 20K Token 预算），中间区域进入压缩。

阶段三：LLM 摘要

使用结构化 12 节模板生成摘要。模板被明确框定为「给另一个助手的简报」——这个措辞很关键，它能防止摘要器试图去回答对话中的问题，而不是单纯地总结它们。

阶段四：消息组装

[头部] + [摘要] + [尾部] 拼接成新的上下文。

阶段五：完整性修复

修复被压缩破坏的 tool_call/result 配对。为被删除结果的调用添加占位符结果，避免模型因为看到调用但看不到结果而产生困惑。

压缩配置

compression:enabled: truethreshold: 0.50# 上下文窗口占用超过 50% 时触发target_ratio: 0.20 # 压缩后目标占用 20%protect_last_n: 20 # 保护最近 20 条消息不被压缩

反抖动保护

如果连续两次压缩各自节省不到 10% 的 Token，Hermes 会自动停止压缩。

冻结记忆快照的成本意义

Hermes 在会话启动时冻结记忆快照。会话中途的写入会更新磁盘文件，但不会改变系统提示词。这不是设计疏忽，而是提示词缓存效率的关键：系统提示词在整个会话期间保持不变，每轮 API 调用都能命中提示词缓存。在多轮对话中，输入 Token 成本可以降低约 75%。

辅助压缩模型的选择

这是社区里踩坑最多的地方：辅助压缩任务默认是跟主模型走的。用 Claude Opus 来做上下文压缩，说句不客气的话，是极大的浪费。压缩任务的本质就是「总结文本」，Flash 级别的模型完全能胜任。Reddit 社区的实测数据显示，把 auxiliary.compression 换成 Flash 级模型后，Token 花费直降 85% 以上。

auxiliary:compression:provider: deepseekmodel: deepseek-v4-flash# 用 Flash 做压缩，不用 Pro

Tool Search：延迟加载省 89% Token

Hermes 默认安装有 72 个工具，每个工具的 Schema 定义都要写进每轮 API 调用的请求体。72 个工具，大约就是 19,210 Token 的固定开销——而且还是每一轮。GitHub Issue #4379 的实测数据更惊人：默认安装的 Hermes，每次 API 调用中大约有 73% 是固定开销（约 13,900 Token），其中工具 Schema 占了绝对大头。

Tool Search（v0.16.0+，截至 2026 年 6 月的最新版本）用三个桥接工具替代了完整的工具数组：

tool_search(query, limit?) — 搜索延迟加载的工具目录tool_describe(name)— 加载一个工具的完整 Schematool_call(name, arguments) — 调用一个延迟加载的工具

实际交互流程

Model: tool_search("create a github issue")→ { matches: [{ name: "mcp_github_create_issue", ... }, ...] }Model: tool_describe("mcp_github_create_issue")→ { parameters: { type: "object", properties: { ... } } }Model: tool_call("mcp_github_create_issue", { title: "...", body: "..." })→ { ok: true, issue_number: 42 }

从 19,210 Token 降到约 2,200 Token，减少了 89%。

完整配置

提示词：生成 Tool Search 延迟加载配置

请帮我生成 tool_search 配置块。要求：

• mode：auto（自动判断是否启用延迟加载，可选值 auto / always / off）
• threshold：0.1（工具 Token 占上下文窗口比例阈值，超过 10% 时 auto 模式启用延迟加载）
• pinned_tools：始终完整加载、不延迟的 7 个核心工具——terminal、read_file、write_file、list_directory、send_message、memory、skills
• evict_after_turns：3（工具调用后 3 轮未再使用则从活跃列表卸载）

关键设计决策

• 核心工具永不延迟：terminal、read_file、write_file、patch、search_files、todo、memory、browser_*、web_search、web_extract、clarify、execute_code、delegate_task、session_search、send_message 等始终直接加载
• 仅 MCP 和非核心插件工具做延迟加载
• pinned_tools 白名单：可以指定额外始终加载的工具
• evict_after_turns：工具调用后 N 轮未再使用则从活跃列表卸载

代价

官方文档明确指出：静态侧的 Token 节省是真实的，但部分节省会被搜索/描述/调用的额外轮次「还回去」。对于只有少量 MCP 工具的配置，Tool Search 可能反而会增加总 Token 消耗。判断标准很简单：如果你的工具目录 Token 占上下文窗口的比例不到 10%，那就关掉 Tool Search；超过 10%，再打开。threshold: 0.1 就是这个意思——auto 模式会自动帮你做这个判断。

互补方案：Tool Slimmer

社区项目 Hermes Tool Slimmer 从另一个角度解决了同样的问题：在配置时做预筛选，只注册当前任务相关的工具子集。Tool Search 是运行时延迟加载，Tool Slimmer 是配置时预筛选——两者可以叠加使用。

execute_code：中间结果不入上下文

execute_code 是 Hermes 里最容易被低估的降本工具。它的核心优势在于：中间工具结果永远不进入上下文窗口——只有最终的 print() 输出才会返回给 Agent。

和 delegate_task 的成本对比

维度	delegate_task	execute_code
推理	完整 LLM 推理循环	仅 Python 代码执行
上下文	全新隔离对话	无对话，只有脚本
工具访问	所有非阻止工具 + 推理	7 个工具通过 RPC，无推理
并行性	默认 3 个并发子袋里	单脚本（内部可多线程）
Token 成本	较高（完整 LLM 循环）	较低（只返回 stdout）

使用场景

• 3 个以上连续工具调用且调用间有处理逻辑
• 批量数据过滤或条件分支
• 循环处理结果集

实战示例：批量文件检查

# execute_code 内部调用 Hermes 工具from hermes_tools import terminal, read_file, write_file# 批量读取 + 处理，中间结果不进上下文results = []for f in ["api.py", "models.py", "routes.py"]:content = read_file(f"src/{f}")# 本地处理，不消耗 Tokenif "TODO" in content:results.append(f"{f}: {content.count('TODO')} TODOs")print("n".join(results))# 只有这行返回给 Agent

如果用常规方式，Agent 需要三次 read_file 调用，每次的完整文件内容都会进入上下文窗口。但用了 execute_code，三个文件的完整内容只在 Python 沙箱内处理，Agent 只看到最终的统计结果。

资源限制

限制项	默认值	超限行为
超时	300 秒	SIGTERM 杀死，5 秒宽限后 SIGKILL
Stdout	50 KB	输出截断
Stderr	10 KB	保留末尾用于调试
工具调用数	50 次	返回错误

批处理模式：跨提示词并行降本

Hermes 的批处理模式支持跨数百或数千个提示词的并行运行。虽然它主要用于训练数据生成，但其成本控制设计同样值得借鉴：

• Nous Portal 订阅：将模型访问 + 网页搜索 + 图像生成 + TTS + 云浏览器打包为一账单，避免跨五个供应商管理限额
• Provider Routing 参数：--providers_allowed、--providers_ignored、--provider_sort 在批处理层面直接控制成本
• 推理控制：--reasoning_effort（none/minimal/low/medium/high/xhigh）和 --reasoning_disabled 可完全禁用推理 Token
• 检查点恢复：失败任务不重复执行，按内容匹配恢复

推理控制参数在交互模式下也可以使用——如果你的任务不需要深度推理（比如简单的格式转换），设置 reasoning_effort: minimal 可以大幅减少 completion token。

翔宇实战：五台机器共享 + 防压缩风暴

以上都是文档和社区方案。下面是一组真实环境的实测配置——在五台 Mac（4 台 Mac mini + 1 台 MacBook）上跑 Hermes 的成本控制经验。

模型策略：免费优先，按量兜底

场景	模型	提供商	说明
主力（常态）	GLM-5.1	z.ai	Coding Plan Max，五台机器共享一个 Token
主力（额度耗尽）	DeepSeek V4 Pro	deepseek	按量计费无上限，$1.74/M 输入 $3.48/M 输出
视觉辅助	Gemini 2.5 Flash	google	图片理解，独立配置不受主模型限流影响
压缩	跟主模型	跟主模型	显式配置，防压缩风暴

GLM Coding Plan Max 是按月免费额度制。五台机器加上 Hermes 共享同一个 Token，重度使用会触碰到月度上限。额度耗尽时的表现是 HTTP 429。

防压缩风暴：独家踩坑经验

压缩风暴（Compression Storm）是一个在实际使用中发现并命名的问题。它的症状是：辅助压缩任务默认跟随主模型。主模型一旦被限流（GLM 返回 429），压缩也跟着挂掉。Agent 于是丢失了整个对话上下文——不是丢一条消息，是全部丢失。

原因在于 auxiliary.compression 默认走 auto 模式，而 auto 模式的探测链第一站就是主模型的提供商。主模型限流时，压缩请求走同一个提供商，自然同样被限流。

解法也很直接：把 auxiliary.vision 和 auxiliary.compression 显式配置成独立的提供商，不走 auto 模式。视觉用 Gemini Flash（免费额度大），压缩跟主模型但独立配置——这样切模型时只需要改一处。

完整 config.yaml

提示词：生成 Hermes 五台机器实战 config.yaml

请帮我生成 ~/.hermes/config.yaml 完整配置。要求包含以下所有模块：

主模型：

• model.default = glm-5.1，provider = zai（GLM Coding Plan Max 免费额度）
• 额度耗尽时切换：model.default 改为 deepseek-v4-pro，provider 改为 deepseek

Provider Routing（仅 OpenRouter 生效）：

• sort = price（按价格排序子提供商）

凭据池策略：

• openrouter = round_robin（多 Key 均匀分摊）
• deepseek = fill_first（单主力多备份）

降级链：

• fallback_providers 配一项：provider = deepseek，model = deepseek-v4-flash

辅助任务独立配置（防压缩风暴，不走 auto 模式）：

• vision：provider = google，model = gemini-2.5-flash（图片理解，免费额度大）
• compression：provider = zai，model = glm-5.1（跟主模型但显式配置，切模型时只改这里）
• skills_hub：provider = deepseek，model = deepseek-v4-flash
• mcp：provider = deepseek，model = deepseek-v4-flash

委派子袋里：

• provider = deepseek，model = deepseek-v4-flash（子袋里任务简单，用便宜模型）

Tool Search 延迟加载：

• mode = auto，threshold = 0.1
• pinned_tools 7 个：terminal、read_file、write_file、list_directory、send_message、memory、skills
• evict_after_turns = 3

上下文压缩：

• enabled = true，threshold = 0.50（占用超 50% 触发），target_ratio = 0.20（压缩到 20%），protect_last_n = 20

Code Execution：

• mode = project，timeout = 300，max_tool_calls = 50

通用版本：去掉 GLM 相关配置，主模型改为 deepseek-v4-flash（provider = deepseek），compression 的 provider 也改为 deepseek、model 改为 deepseek-v4-flash，其余不变。

GLM 额度耗尽时的切换流程

# .env 加 DeepSeek Keyecho 'DEEPSEEK_API_KEY=sk-ds-your-key-here' >> ~/.hermes/.env# config.yaml 改两行# model.default: deepseek-v4-pro（或 deepseek-v4-flash 更省）# model.provider: deepseek# GLM 额度恢复后切回# model.default: glm-5.1# model.provider: zai

端点配置优化

# 国内直连 GLM（推荐），跳过 3 秒自动探测GLM_BASE_URL=https://open.bigmodel.cn/api/coding/paas/v4

不设 GLM_BASE_URL 时，首条消息会慢约 20 秒（3 次 HTTPS 探测 + 推理延迟）。直接指定端点后，首消息响应时间会降到正常水平。

成本实绩

在免费优先 + 按量兜底的策略下，五台机器的月均 API 支出大约在 $3-5 之间。大部分时间吃 GLM 免费额度，只有月末额度紧张时才切到 DeepSeek 按量计费。

行业背景：模型路由降本的学术和产业验证

这套「不要一个提供商走到黑」的思路并不是 Hermes 独创，有大量的学术和产业数据支撑：

• CASTER 论文（ACM Web Conference 2026）：轻量级路由器可降低推理成本达 72.4%
• Route-To-Reason 框架：同时选择模型和推理策略，Token 用量和 API 成本降低达 60%
• Budget-Aware Agentic Routing 论文（arXiv 2602.21227）：在严格预算约束下智能分配贵/便宜模型
• FinOps for LLMs 2026 报告：企业第一年 FinOps 工作平均降 30-60% LLM 成本
• Zylos Research 2026-04 报告：系统化路由可降低 30-70% 成本

有一个数据特别值得记住：天盘博客《AI Agent 代币经济学》指出，未优化与优化后的部署成本，差距可以达到 200 倍。Hermes 的设计——Provider Routing + Credential Pools + Fallback Providers 三层架构——本质上就是把学术研究中的这些路由策略，工程化地落地到了一个开源 Agent 框架里。

成本监控脚本

配置完成后，日常运行还需要监控。

查看凭据池状态

#!/bin/bashset -euo pipefail# 查看当前凭据池hermes auth list# 添加备用 Keyhermes auth add openrouter --api-key sk-or-v1-backup-key-herehermes auth add deepseek --type api-key --api-key sk-ds-backup-key

成本警报脚本（配合 execute_code 使用）

这个脚本在 Hermes 会话中通过 execute_code 运行，用于检查过去一小时的 API 花费是否超出预算。

提示词：生成 Hermes 成本告警脚本

请帮我写一个 Python 脚本，在 Hermes 会话中通过 execute_code 运行。要求：

• 通过 hermes_tools.terminal 调用 hermes stats --last-hour --json，获取最近一小时的 Token 使用统计
• 命令加 2>/dev/null || echo '{}' 兜底，防止命令不可用时报错
• 解析 JSON 响应，提取 total_tokens 和 total_cost_usd 两个字段
• 设定小时预算阈值 HOURLY_BUDGET = $0.50
• 超出预算时打印告警（含实际花费、预算值、Token 总量）
• 未超出时打印正常状态（含花费和预算对比）
• 用 try/except 捕获 JSON 解析失败，输出"统计数据不可用"

社区可视化方案：Hermes Dashboard

hermes-dashboard 是社区开发的成本监控仪表盘，提供：按模型和提供商的成本分解视图、实时 Token 消耗追踪、以及按会话和时间段的用量统计。

hermes dashboard --port 9119 &

常见问题

Hermes Agent 一个月大概花多少钱？

未优化的 Hermes 每月 API 费用通常在 $50-200 之间。通过本文介绍的系统化成本控制方案（模型路由 + 凭据池轮换 + 辅助模型分离 + Tool Search），可以压到 $5-8/月。如果主力模型用免费额度（比如 GLM Coding Plan），日常使用几乎可以做到零成本。

Provider Routing 和 Fallback Providers 有什么区别？

Provider Routing 控制的是 OpenRouter 内部子提供商的选择策略（按价格、速度、延迟排序），属于同一平台内的路由优化。Fallback Providers 是跨提供商的故障转移——当主模型整体失败时切换到完全不同的提供商和模型。两者是独立的两个维度，可以同时配置。

凭据池的四种轮换策略怎么选？

fill_first（默认）适合单主力多备份场景；round_robin 适合多 Key 均匀分摊负载；least_used 适合长期均衡使用；random 适合简单场景。建议 OpenRouter 用 round_robin 均匀分摊，Anthropic 或 DeepSeek 用 fill_first 保持单 Key 追踪。

什么是压缩风暴？怎么防？

压缩风暴是指辅助压缩任务默认跟主模型走，主模型一旦限流（429），压缩也连带崩溃，Agent 丢失整个对话上下文。防护方案：把 auxiliary.compression 显式配置成独立的提供商和模型，不走 auto 模式。

Tool Search 延迟加载有什么代价？

静态侧的 Token 节省是真实的（从 19,210 降到约 2,200），但部分节省会被搜索/描述/调用的额外轮次还回去。如果只有少量 MCP 工具，Tool Search 可能反而会增加总 Token 消耗。只有工具目录足够大时（超过上下文窗口的 10%），收益才显著。

execute_code 和 delegate_task 哪个更省 Token？

execute_code 更省。delegate_task 会启动完整的 LLM 推理循环，Token 成本较高。execute_code 只执行 Python 代码，中间工具结果不进入上下文窗口，只有最终 print() 输出返回给 Agent。适合 3 个以上连续工具调用且调用间有处理逻辑的场景。

能不能完全免费运行 Hermes？

理论上可以。方案是主力模型用 GLM Coding Plan 或 Gemini Flash 免费档，辅助任务用 Gemini Flash，降级链挂上本地模型（LM Studio）作为最终兜底。但完全免费意味着会频繁碰到限流，不适合生产环境。建议至少保留一个按量计费的提供商（如 DeepSeek）作为兜底。

Hermes 内置的成本追踪功能够用吗？

日常使用够用。Hermes TUI 的 /agents 叠加层提供会话级别的成本、Token 和文件变更汇总。但如果需要跨系统的全流程追踪、精确的成本归因和预算告警，建议搭配 Langfuse（开源）或 LiteLLM（统一袋里层）作为前置网关。

延伸阅读

• Hermes Agent 完全指南：架构原理和 14 篇子教程导航
• Hermes Agent 本地模型集成：LM Studio / Ollama 本地推理
• Hermes Agent Docker 部署：生产环境容器化
• Hermes Agent 评测：和同类产品的全面对比
• Hermes Agent Kanban 多 Agent 编排：Kanban 任务系统和子袋里成本管理