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，满载时切 Googlerequire_parameters设为 true，确保只路由到支持所有请求参数的提供商
先走 Anthropic，满载时切 Google。开启 require_parameters 后，可以避免因为某个子提供商不支持 temperature 或 top_p 而返回错误。
隐私保护型：
提示词：生成隐私保护型 Provider Routing 配置
请帮我生成 provider_routing 配置。要求：
ignore拉黑不信任的提供商：Together、Leptondata_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 的韧性体系由三层防线组成：
- 凭据池（Credential Pools）：同一提供商内多 API Key 轮换——这是第一层防线
- 主模型降级（Primary Model Fallback）：主模型失败后自动切换到不同提供商/模型
- 辅助任务降级（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 日配额耗尽、连接失败）时，会触发四层降级链：
- 主辅助提供商（你配置的那个）
auxiliary.（可选的自定义链）.fallback_chain - 主 Agent 的提供商 + 模型（兜底）
- 警告 + 重新抛出
这里有一个关键区分点：短暂的 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：
- 去重：对工具结果做 MD5 哈希，>200 字符的重复内容替换为
"[Duplicate tool output]" - 摘要化：20+ 个工具专用处理器。
npm test的 47 行输出变成"[terminal] ran npm test → exit 0, 47 lines"；1,200 字符的文件读取变成"[read_file] read config.py (1,200 chars)" - 参数截断：>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、skillsevict_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 | 图片理解，独立配置不受主模型限流影响 | |
| 压缩 | 跟主模型 | 跟主模型 | 显式配置，防压缩风暴 |
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 任务系统和子袋里成本管理
