一、先说结论：这三件事决定 Hermes 能不能长期稳定跑
很多人理解 Agent 时，容易把注意力全部放在大模型上：模型够不够强？推理够不够聪明？工具调用准不准？但真正上线以后，决定系统稳定性的，往往不是模型参数，而是模型外面的运行控制。
Hermes Agent 里的压缩、Fallback 和预算控制，本质就是给 Agent Loop 加上三道工程保险丝：上下文太长，要会压缩；模型不可用，要会换路；任务跑太久，要会刹车。
可以把 Hermes Agent 想象成一个持续工作的技术助理：它可能一天到晚在云服务器上接收来自 CLI、Telegram、Discord、Slack 或定时任务的请求。只要它持续工作，就会遇到三个问题：聊天记录越堆越长、外部模型服务偶尔不可用、复杂任务可能一直循环。
所以，压缩不是为了省几个 token，Fallback 不是为了炫技多接几个模型，预算控制也不是为了限制能力。它们共同解决的是：让 Agent 在真实世界里可持续、可恢复、可解释。
二、压缩：解决“上下文装不下”的问题
2.1 上下文为什么会爆？
Agent 和普通聊天机器人最大的不同，是它不只是说话，还会读文件、调用终端、搜索网页、访问工具、执行子任务。这些工具结果都会被放回上下文，让模型知道刚刚发生了什么。
这就带来一个现实问题：一开始上下文很清爽，跑着跑着就会堆满终端日志、文件内容、搜索结果、错误栈、历史决策。模型窗口再大，也不可能无限装。Hermes 的解法不是等到彻底爆掉再报错，而是在达到一定比例时提前压缩。
官方文档把 Hermes 的压缩分成两层：第一层是 Gateway Session Hygiene，大约在上下文达到 85% 时触发，属于消息进入 Agent 前的安全网；第二层是 Agent ContextCompressor，默认大约在 50% 时触发，运行在 Agent Loop 内部，能拿到更准确的 token 使用量。
2.2 Gateway 85%：入口层的安全网
Gateway 层面对的是跨平台消息入口。比如一个 Telegram 对话放了一晚上，用户第二天继续发消息，这时会话历史可能已经很大。Gateway 的安全检查会在消息真正进入 Agent 前做一次粗略判断，避免一上来就把模型 API 打爆。
这个安全网的阈值更高，约 85%。原因很简单：它不应该过早压缩，否则长会话每一轮都可能被压缩，反而影响体验。它的定位不是日常压缩主力，而是“兜底”。
2.3 Agent 50%：真正的主力压缩器
Agent 内部的 ContextCompressor 才是日常压缩主力。它在模型调用前检查上下文使用情况，如果超过配置阈值，就会进入压缩流程。默认阈值约 50%，也就是在还有空间时提前整理，而不是等到马上崩溃。
2.4 压缩不是粗暴删除，而是结构化“记重点”
Hermes 的压缩流程可以用一句话概括：开头保留、尾部保留、中间摘要、工具调用成对保护。
开头为什么要保留？因为系统提示、第一轮任务目标、基础规则可能非常重要。尾部为什么要保留？因为最近几轮往往是当前正在处理的问题，如果被压成摘要，模型很容易丢失细节。中间为什么可以摘要？因为很多旧日志、旧搜索结果、旧尝试已经不需要逐字保留，只需要保留目标、约束、进展、关键文件、关键错误和下一步。
2.5 压缩摘要里应该保留什么？
Hermes 官方文档中的摘要模板不是简单写一句“前面聊了很多”，而是结构化记录：用户目标、约束和偏好、已完成工作、正在进行的工作、阻塞点、关键决策、相关文件、下一步、关键上下文。
摘要字段 | 作用 |
Goal | 用户到底想完成什么，而不是只记聊天表面内容 |
Constraints & Preferences | 用户偏好、代码风格、技术约束、业务限制 |
Progress | 已完成、进行中、卡住的事情 |
Key Decisions | 重要技术决策以及原因 |
Relevant Files | 读过、改过、创建过的文件 |
Next Steps | 下一轮应该继续做什么 |
Critical Context | 错误信息、配置值、关键路径等不能丢的细节 |
这就是 Hermes 压缩机制最值得学习的地方：它不是“把历史变短”，而是“把历史变成下一轮能继续工作的任务状态”。
三、Fallback：解决“模型服务不可用”的问题
3.1 为什么 Agent 必须有 Fallback？
在真实环境里，模型服务不可能永远稳定。可能遇到 429 限流，可能遇到 500/502/503 服务异常，可能遇到 401/403 授权问题，也可能是网络临时断开。如果 Agent 每次遇到这种问题都直接失败，用户体验会非常脆弱。
Hermes 的 Fallback 机制，就是让主模型出问题时，系统可以在同一个会话中切换到备用 provider:model，继续处理当前任务。
3.2 第一层：Credential Pools，同一个 provider 内换钥匙
如果你对接的是同一个模型服务，可能会配置多个 API Key。某一个 key 被限流，不代表整个 provider 都不可用。Credential Pools 的作用就是先在同 provider 内部做 key 轮换。
这类恢复成本最低，因为模型、协议、返回格式都不变，只是换了认证凭据。对于生产系统来说，这是一种非常实用的限流缓冲。
3.3 第二层：Primary Model Fallback，跨 provider 换模型
如果同 provider 内部也不行，就要切换备用模型。Hermes 推荐使用 top-level 的 fallback_providers 列表进行配置。它会按顺序尝试多个 provider:model。旧版本的 fallback_model 单模型配置仍然兼容，但新配置应该优先使用 fallback_providers。
Fallback 激活后，Hermes 不是重新开一个空会话，而是在当前会话里替换运行时组件：模型名、provider、base_url、api_mode、client 等会被更新，然后重置重试计数继续跑。这一点很关键，因为用户的上下文和任务进度不能丢。
官方 Provider Runtime 文档也提到，Fallback 的触发点包括：无效 API 响应重试到上限、401/403/404 等非重试型客户端错误、429/500/502/503 等临时错误重试到上限。
3.4 第三层：Auxiliary Fallback，辅助任务单独恢复
Hermes 里并不是只有“主对话模型”会调用 LLM。压缩摘要、视觉理解、网页抽取、技能中心操作、MCP 辅助操作、记忆刷新等，也可能调用辅助模型。
这就要求辅助任务有自己的路由策略。比如主模型很贵、很强，但压缩摘要可以用便宜快速的模型；又或者主模型不可用，但压缩任务不应该直接拖垮整个 Agent。因此 Hermes 的 auxiliary.* 配置可以为不同辅助任务设置 provider、model、base_url 等。
3.5 Fallback 的注意点：不是所有地方都完全一样
Hermes 的 Fallback 不是魔法，需要知道边界。官方 Provider Runtime 文档提到，子 Agent 委派会继承父 Agent 的 provider，但不一定继承 fallback 配置；辅助任务也有自己独立的 provider 自动检测链。
所以在生产配置里，不能只看“主 Agent 能 fallback”，还要检查压缩、视觉、网页抽取、定时任务这些旁路是否配置合理。否则主对话模型恢复了，辅助压缩却失败，长会话质量仍然会下降。
四、预算控制：解决“Agent 停不下来”的问题
4.1 为什么需要预算？
Agent Loop 的特点是循环：模型思考、调用工具、拿到结果、继续思考、再调用工具。如果没有上限，遇到复杂任务、错误路径或工具返回不稳定时，Agent 可能一直尝试。
这不仅浪费成本，还会造成用户不可控：你不知道它什么时候结束，不知道它已经做了多少，也不知道失败在哪里。预算控制的作用，就是给 Agent 一个明确的停止条件。
4.2 默认预算：主 Agent 约 90 次迭代
官方 Agent Loop 文档提到，Hermes 使用 IterationBudget 跟踪迭代次数。默认最大迭代约 90 次，可以通过 agent.max_turns 配置；环境变量 HERMES_MAX_ITERATIONS 也用于控制每个对话的最大工具调用迭代次数。
当预算达到 100% 时，Agent 不应该继续无限运行，而是停止并返回已经完成工作的摘要。这是非常符合工程系统思维的：失败也要可解释，不能悄悄消耗资源。
4.3 子 Agent 预算：委派任务也要有限制
Hermes 支持子 Agent，也就是主 Agent 可以把复杂任务委派出去。子 Agent 的预算和父 Agent 是独立的，官方文档提到子 Agent 默认受 delegation.max_iterations 控制。
这意味着父子预算不是简单共享。总迭代次数可能超过父 Agent 的 cap，因为每个子 Agent 有自己的工作空间和预算。这种设计给复杂任务留了弹性，但也要求开发者配置 delegation.max_iterations 和最大并发数，避免并行子任务放大成本。
五、三者如何一起工作？
5.1 一次长任务中的协同过程
假设用户让 Hermes 帮忙修复一个复杂项目：它先读项目规则、跑测试、定位文件、调用终端、改代码、再跑测试。过程中会产生大量上下文，也可能遇到模型限流，还可能因为测试失败反复尝试。
这时三道保险丝会同时发挥作用：上下文接近阈值时压缩；主模型报错时 fallback；循环次数过多时预算收口。
5.2 三者分别控制不同风险
机制 | 主要风险 | 解决方式 |
Compression | 上下文过长、工具输出过大、会话无法继续装入模型窗口 | 把中间过程压成结构化摘要，保留开头和尾部 |
Fallback | 模型限流、服务异常、认证异常、连接失败 | 同 provider 换 key 或跨 provider 切备用模型 |
Budget | 工具循环、子任务失控、成本和时间不可控 | 限制主 Agent 和子 Agent 的迭代次数，到上限后总结 |
这三者不是互相替代，而是互相补位。压缩让任务能继续“记住重点”；Fallback 让任务在模型不稳定时“换路继续”；预算让任务在无法继续推进时“停下来交代清楚”。
六、压缩与持久化：为什么压缩不会让任务彻底断片
很多人一听“压缩”，第一反应是担心丢信息。这个担心是合理的。Hermes 的压缩确实是有损摘要，不是逐字保留。但它通过几件事降低风险：Memory 先落盘、最近消息原样保留、工具调用结果成对保护、摘要结构化、压缩后形成新的 session lineage。
官方 Agent Loop 文档提到，每轮结束后消息会保存到 session store，Memory 变更会写入 MEMORY.md / USER.md，会话可以通过 /resume 或 hermes chat --resume 恢复。这意味着压缩主要影响“当前模型上下文”，不等于所有历史完全消失。
不过也要诚实地说：有损压缩一定存在质量风险。如果摘要模型窗口不足、摘要失败、或者中间过程包含大量关键细节，压缩质量就会影响后续任务。因此生产配置里，压缩模型不能随便选太弱、太小窗口的模型。
七、故障处理矩阵：看到报错时应该想到哪道保险丝
这个矩阵非常适合排查问题。比如上下文相关报错，不要马上换模型，先看 compression.threshold、summary model、context length；如果是 429，先看 credential pool 和 fallback_providers；如果是一直调用工具不结束，先看 agent.max_turns、delegation.max_iterations 和工具返回质量。
八、源码阅读路线：想吃透这块应该看哪些文件
如果你想深入源码，不建议从整个仓库开始乱翻。先看 run_agent.py，因为它是 AIAgent 主循环，负责模型调用、工具执行、重试、fallback、预算、压缩触发。然后看 agent/context_engine.py 和 agent/context_compressor.py，理解可插拔上下文引擎和默认压缩器。
再继续看 agent/auxiliary_client.py，它关系到压缩摘要、视觉、网页抽取等辅助 LLM 调用。最后看 hermes_cli/runtime_provider.py 和 gateway/run.py，前者解释 provider/client/api_mode 如何解析，后者解释跨平台消息入口和 gateway 级会话卫生。
九、给开发者的落地建议
9.1 压缩配置建议
第一，不要轻易关闭压缩。长任务和跨平台会话一定会膨胀，关闭压缩等于把风险推迟到 API 报错那一刻。第二，压缩摘要模型要有足够上下文窗口，不能只图便宜。第三，protect_last_n 不要设太低，否则当前正在处理的问题容易被摘要化。
9.2 Fallback 配置建议
建议使用 fallback_providers 列表，而不是只用旧的 fallback_model。备用模型的选择要考虑协议兼容、上下文窗口、工具调用能力和成本。对于关键业务，最好同时配置 credential pool 和 cross-provider fallback。
9.3 预算配置建议
预算不要无限放大。主 Agent 的 agent.max_turns 要能覆盖常见任务，但不能大到失控。子 Agent 的 delegation.max_iterations 和并发数要结合成本评估。如果工具质量不稳定，应该优化工具返回和任务拆解，而不是单纯提高预算。
9.4 观测建议
生产系统里最好记录四类信息：压缩触发次数、fallback 激活次数、预算用尽次数、辅助任务失败次数。只要这四类指标持续上升，就说明系统不是“偶发问题”，而是架构或配置需要调整。
十、总结：长期运行 Agent 的核心不是“更聪明”，而是“更抗打”
Hermes Agent 的压缩、Fallback 和预算控制，体现的是 Agent 工程化的成熟方向：模型只是大脑，真正让它长期稳定工作的，是上下文治理、运行时恢复和执行边界。
压缩让 Agent 不会因为历史太长而失忆或崩溃；Fallback 让 Agent 不会因为某个模型服务异常就全盘失败；预算控制让 Agent 不会无限循环、无限消耗。
如果把 Agent 当成一个真实生产系统，这三件事就是它的基础设施：压缩负责“记得住”，Fallback 负责“接得上”，预算负责“停得下”。理解这三点，比单纯记住某个框架 API 更重要。
