当 LLM Agent 从原型走向生产环境时，最危险的故障往往不是答错题，而是凌晨两点的宕机——一次 429 限流、一段超长的日志、一个过期的 API Key。大多数框架把这一切甩给开发者的 try/except 去兜底，而 Hermes Agent 把恢复能力直接内建在运行时里。

这篇文章将拆解 Hermes Agent 的六层韧性栈：错误分类、自适应重试、Provider 降级、上下文压缩、检查点回滚与会话恢复。你会看到 Hermes 在出错时是如何自己站起来的。

1. 先分类，再决策：错误分类器

Hermes 将所有 API 错误统一交给 agent/error_classifier.py 中的 classify_api_error() 处理。它不会把所有异常都当成普通网络问题，而是把每一次失败映射为具体的 FailoverReason：rate_limit（限流）、overloaded（过载）、context_overflow（上下文溢出）、payload_too_large（负载过大）、long_context_tier（长上下文档位）、auth（认证）、billing（计费）、content_policy_blocked（内容策略拦截）、ssl_cert_verification（SSL 证书校验）、timeout（超时）、stream_drop（流中断）、thinking_signature、model_incompatible（模型不兼容）、invalid_request（非法请求）。

每种原因都携带三个标志位：retryable（可重试）、should_fallback（应降级）、should_compress（应压缩）。恢复循环只依据这些标志位行动，而不是盯着原始错误文本。这让恢复策略可预测、可测试、可扩展。

2. 自适应重试：读取 Retry-After，而不是盲目 sleep

Hermes 在 agent/retry_utils.py 中实现了 adaptive_rate_limit_backoff()。它不是朴素的指数退避，而是：

• 读取 HTTP Retry-After 响应头。
• 把等待时间上限设为 600 秒，防止某个 Provider 无限期卡住会话。
• 针对 Z.AI 编码过载场景使用专门的长/短退避策略。
• 加入抖动（jitter），避免多个 Hermes 实例在同一瞬间扎堆重试。

在重试循环中，Hermes 会打印一个紧凑的状态块：错误类型、Provider、模型、已耗时、上下文大小和倒计时。对于 7×24 小时网关或 cron 任务的调试来说，这种透明度至关重要。

3. Provider 降级：从本地重试到跨 Provider 逃生

Hermes 不会死盯一个 Provider，而是根据错误类型选择路径：

• 透明的本地重试：遇到连接断开、5xx、408 时，在同一 Provider 上重试若干次。
• 认证刷新与凭据池：遇到 auth 错误时，刷新凭据、续期 Nous Portal 运行时，如果配置了凭据池还会轮换 Key。
• 计费与限流：将当前 Provider 标记为 unhealthy，激活降级链：先是自定义的 fallback_chain，然后是全局 fallback_providers，最后是内置的自动发现链。
• 内容策略拦截：遇到 content_policy_blocked 不再重试，而是明确告诉用户下一步该怎么做。

针对 Nous Portal 的 429，Hermes 会写入一条跨会话的 rate_limit 记录，让所有 worker 都避开同一个已耗尽的配额桶，从而保护高并发、长时运行的生产部署。

4. 上下文压缩：把“上下文爆炸”变成常规操作

长对话中最常见的故障是超出上下文窗口。Hermes 处理这个问题时异常精确：

• 输出上限错误：当 max_tokens 超过 Provider 的模型上限时，直接提示用户调低 model.max_tokens，而不是浪费重试次数。
• 输入过大：Hermes 从错误信息中提取真实上限，更新压缩器的 context_length，然后压缩消息。
• Minimax 特例：当 Provider 只报告“超出 X tokens”时，保留原始窗口并执行压缩。

压缩不是一锤子买卖：先把消息总结，再从工具消息中剥离图片负载，最后才提示用户 /new 或 /compress。对于 Anthropic 长上下文档位错误，窗口会临时从 1M 降到 200K 并执行压缩，而不会持久化这次降级。

5. 检查点与回滚：文件与状态的双保险

Hermes 在 tools/checkpoint_manager.py 中内置了文件系统检查点管理器。任何时候都可以用 /rollback 列出可用检查点并恢复。对于重构、配置变更或批量文件操作来说，这是一个轻量的撤销层。

快照功能更进一步：

/snapshot create before-major-refactor
/snapshot restore 20260717_142030
/snapshot prune 10

/snapshot 保存的是 Hermes 配置与运行时状态，而 /rollback 备份的是工作目录下的文件。两者合起来，状态和文件都有了保障。

6. 会话恢复：CLI 与 Telegram 之间的无缝切换

Hermes 把每一次对话都持久化到 ~/.hermes/state.db 这个 SQLite 数据库中，包括完整消息历史、工具调用、token 计数、系统提示词快照、时间戳和父会话 ID。这意味着：

• hermes --continue 或 hermes -r <session_id> 可以恢复上一次 CLI 会话。
• /new payments-refactor 可以命名一个会话，之后用 /resume payments-refactor 找回。
• 会话可以跨平台切换：在 CLI 里开始，在 Telegram 上继续，再到桌面端用 /resume 接着聊。

恢复时，Hermes 会展示一段紧凑的摘要，你不需要重读整条线程。长会话也可以用 /compress 保持在可控范围内。

7. 应急命令速查表

命令	功能
/retry	重新发送上一条消息。
/resume [name]	恢复之前的会话。
/new [name] / /reset	开始新会话，可命名。
/compress [here [N] | focus topic]	手动压缩上下文。
/undo	撤销最近一次用户/助手对话。
/rollback [number]	列出或恢复文件系统检查点。
/snapshot create/restore/prune	保存、恢复或清理快照。
/stop	停止所有后台进程。
hermes --continue	恢复最后一次 CLI 会话。
hermes -r <id>	按 ID 恢复会话。
hermes -c "name"	按名称恢复会话。

8. 与常见框架对比

能力	Hermes Agent	OpenAI Agents	AutoGen/AG2	CrewAI	LangGraph
错误分类	内置 FailoverReason	SDK 基础错误	简单	工具级	自己设计
自动 Provider 降级	内置降级链	手动实现	部分支持	不支持	手动实现
上下文压缩	内置多阶段	不支持	不支持	不支持	不支持
会话持久化/恢复	SQLite + /resume	自己保存	自己保存	不支持	状态机检查点
文件系统检查点	/rollback	不支持	不支持	不支持	不支持
跨平台切换	内置	不支持	不支持	不支持	不支持

Hermes 与它们的区别在于：错误处理不是可选插件，而是 Agent 运行时的一部分。你不需要手写 try/except、维护 Provider 列表、手动裁剪上下文——这些都是默认行为。

9. 给工程团队的实用建议

1. 配置降级 Provider。 生产环境至少准备一个备用 Provider，这样 429 和 402 错误就不会变成半夜的告警。
2. 给重要会话命名。 用 /new <task-name> 命名，之后就能用 /resume 跨平台切换。
3. 大改动之前先建快照。 /snapshot create <label> 让你随时快速回滚。
4. 周期性任务用 cron no_agent。 对重复的关键任务，no_agent: true 的 cron 脚本直接输出 stdout，避免 LLM 推理带来的不确定性。
5. 备份 ~/.hermes/state.db。 你全部的对话历史都存在这里。

结论

Hermes Agent 的错误处理体系远不止“重试几次然后放弃”。它从分类、重试、降级、压缩、检查点、会话恢复六个方向，系统地攻击 LLM 运维中最常见的故障模式。对于想把 Agent 跑进生产环境的团队来说，这种自愈能力和模型本身的推理能力一样重要。

如果你还在为 Provider 宕机、上下文膨胀、模型切换手写各种临时脚本，不如把这些脏活交给 Hermes。配置好降级链，敲下 /resume，继续干活。