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 等）如何处理你的请求。

💡 通俗讲：你买了一张 OpenRouter 的车票，Provider Routing 决定这张车票走哪条线路——走最便宜的、走最快的、还是走延迟最低的。

这和 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 三个过滤器，组合出六种常见策略：

实战配置示例

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

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.only
providers_ignored  ← provider_routing.ignore
providers_order    ← provider_routing.order
provider_sort      ← provider_routing.sort
provider_require_parameters ← provider_routing.require_parameters
provider_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: openrouter
    model: anthropic/claude-sonnet-4

触发降级的条件：

关键设计：按轮次（Per-Turn）降级，不是按会话（Per-Session）

每次用户发送新消息，Hermes 都从主模型开始尝试。如果主模型在当前轮次中失败，降级只对本轮生效。下一轮重新尝试主模型。

💡 通俗讲：主模型像你的首选餐厅。今天满座了，你去隔壁吃一顿。明天不会因为今天满座就默认去隔壁——你还是先去首选餐厅看看。

单轮内最多降级一次。如果降级也失败，走正常错误处理流程。这个设计防止了级联降级循环，同时每轮都给主模型一个恢复的机会。

辅助任务降级

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

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.<task>.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 → 刷新失败 → 轮换
  → 成功 → 正常继续

四种轮换策略

配置方式：

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

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

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

错误恢复机制

快速上手

# 添加第二个 OpenRouter Key
hermes auth add openrouter --api-key sk-or-v1-your-second-key

# 添加第二个 Anthropic Key
hermes auth add anthropic --type api-key --api-key sk-ant-api03-your-second-key

# 添加 DeepSeek Key
hermes auth add deepseek --type api-key --api-key sk-ds-your-key

# 查看凭据池状态
hermes auth list

# 交互式凭据管理
hermes auth

自动发现

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

这意味着如果你的机器上同时装了 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、自定义端点等）时成本报告会断裂。

外部追踪工具选型

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

关键陷阱：跨提供商 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: true
  threshold: 0.50      # 上下文窗口占用超过 50% 时触发
  target_ratio: 0.20   # 压缩后目标占用 20%
  protect_last_n: 20   # 保护最近 20 条消息不被压缩

反抖动保护

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

💡 通俗讲：一次压缩省了 8% 但花了 2,000 Token 生成摘要，净收益是负的。Hermes 能识别这种情况并自动刹车。

冻结记忆快照的成本意义

Hermes 在会话启动时冻结记忆快照。会话中途的写入更新磁盘文件，但不改变系统提示词。这不是设计疏忽，而是提示词缓存效率的关键：

• 系统提示词在整个会话期间保持不变
• 每轮 API 调用都能命中提示词缓存
• 多轮对话中输入 Token 成本降低约 75%

辅助压缩模型的选择

这是社区踩坑最多的地方：辅助压缩任务默认跟主模型走。

用 Claude Opus 做上下文压缩是极度浪费的。压缩任务的本质是「总结文本」，Flash 级别的模型完全能胜任。Reddit 社区的实测数据显示，把 auxiliary.compression 换成 Flash 级模型后，Token 花费直降 85%+。

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

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)            — 加载一个工具的完整 Schema
tool_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 的成本对比

使用场景

• 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}")
    # 本地处理，不消耗 Token
    if "TODO" in content:
        results.append(f"{f}: {content.count('TODO')} TODOs")

print("\n".join(results))  # 只有这行返回给 Agent

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

资源限制

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

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 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 Key
echo '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/bash
set -euo pipefail

# 查看当前凭据池
hermes auth list

# 添加备用 Key
hermes auth add openrouter --api-key sk-or-v1-backup-key-here
hermes 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 任务系统和子代理成本管理

下一步

• AI 编程实操课：Claude Code + Codex + Agent 工作流，覆盖一人公司、自媒体自动化、AI 副业全场景。237 篇实战教程 + 最佳实践 + 源码包，跟着做就出成果。国内版-FlowUS | 国际版-BMC
• YouTube 频道：翔宇工作流
• 微信公众号：搜索「翔宇工作流」