Hermes Agent 的 Context Length 为什么老出错？从 64K 门槛、Ollama 误报到 custom provider 手动修正的完整排查

Hermes Agent 这类工具最容易把人逼疯的一种错误，不是装不上，也不是网关起不来，而是那种特别拧巴的状态：能聊两句，能跑点简单命令，一到长任务、多步工具调用、复杂上下文，就突然开始报 Context length exceeded，或者虽然不报错，但明显像失忆一样前言不搭后语。Hermes 官方 FAQ 对这个问题的定义非常直接，原因通常就两类：要么是会话真的已经长到超过模型窗口了，要么是 Hermes 检测错了你的模型上下文长度。这句话看着简单，实际上已经把大多数坑都点出来了。

很多人对"上下文超限"的理解还停留在聊天机器人阶段，觉得不过就是聊太久了。可 Hermes 不是普通聊天器，它要跑多步工具调用、记忆压缩、子代理、终端输出、文件读写、MCP 之类整套工作流。上下文窗口对它来说，不是"聊得开心一点"的附加项，而是 工作记忆的底座。Hermes 官方 Quickstart 明确要求，模型上下文窗口至少要 64K tokens，否则无法支撑多步工具调用所需的工作记忆；低于这个门槛的模型，Hermes 甚至会在启动时直接拒绝。也就是说，很多"Agent 怎么这么笨"的根子，其实根本不在 Agent，而在你给它配的脑容量从一开始就不够。

一、第一件事先想明白：Hermes 的 64K 不是建议，是硬门槛

Hermes 这条线和一般聊天工具最本质的不同，就是它不是只靠几轮对话撑起来的。它要在上下文里同时装下系统提示、工具定义、工具输出、用户任务、执行历史、压缩摘要，有时还要装 Delegation 和 MCP 相关信息。正因为这样，官方才在 Quickstart 里把 64K context window 写成最低要求，并且明确说这是"支持多步工具调用工作流所需工作记忆"的底线。这个表述其实已经很客气了，翻译成人话就是：你要是拿太小的模型来跑 Hermes，它不是表现差一点，而是根本不适合干这活。

所以第一种最常见的误判，就是用户把"模型能出字"误当成"模型适合跑 Hermes"。这两者根本不是一回事。一个 8K、16K 甚至 32K 的模型，可能在普通聊天里还能凑合，但一旦进到 Hermes 的工具链，就会很快暴露出工作记忆不足的问题。你会看到的表面症状可能是：任务开始时还像模像样，做着做着突然忘记前文；或者一调用几个工具后就开始超限；又或者根本在启动时就被拒绝。这些都不是玄学，都是窗口预算不够的直观后果。

二、Context length exceeded 不一定说明你聊太久了，也可能是 Hermes 从一开始就认错了模型

Hermes 官方 FAQ 专门点出了一个很关键的现实：如果在第一段长对话里就出现 Context length exceeded，那很可能不是会话太长，而是 Hermes 把模型的上下文长度识别错了。 官方给出的检查方法也非常直接。第一，看 CLI 启动时那一行，它会显示检测到的 context limit，比如 Context limit: 128000 tokens。第二，在会话里用 /usage 看当前 token 使用情况和剩余空间。也就是说，Hermes 不是完全黑盒，它其实已经把"它以为你模型有多大脑子"这件事告诉你了。问题是，大多数人根本没看。

这类错识别最烦的地方在于，它看起来特别像"模型明明号称大窗口，怎么一用就废"。其实模型可能没撒谎，撒谎的是中间环节的检测。Hermes 文档明确给了修法：如果自动检测有误，就在 ~/.hermes/config.yaml 里显式设置 context_length。如果是 custom provider，还可以按具体模型逐个设置。也就是说，当自动识别不可信时，官方并没有让你继续撞墙，而是明确允许你直接手工告诉 Hermes：别猜了，这个模型的真实窗口就是这么大。

最常见的显式修法长这样：

model:
 default: your-model-name
 context_length: 131072

如果你是自定义端点，按模型单独写：

custom_providers:
 - name: "My Server"
 base_url: "http://localhost:11434/v1"
 models:
 qwen3.5:27b:
 context_length: 32768

这个配置不是锦上添花，而是在自动检测失灵时的直接止血方案。

三、Ollama 用户最容易中招，因为它"报告的窗口"和"你实际跑的窗口"可能不是一回事

Hermes 官方 FAQ 里有一个非常实用、但很多人会漏掉的提醒：Ollama 的 /api/show 可能报告的是模型最大上下文，而不是你实际配置生效的 num_ctx。 这句话的杀伤力很大，因为它直接解释了为什么很多本地用户会遇到这种情况：模型名看着很大，文档说也支持长上下文，结果 Hermes 还是一跑就超。问题不一定是 Hermes 瞎了，也不一定是模型骗人，而是 Ollama 报给 Hermes 的信息和你真实运行时分配的上下文预算可能压根不是一回事。

这时候最危险的做法，就是盲信自动检测。你看见 CLI 写了个很大的 context limit，以为万事大吉，实际一到长任务就崩；或者相反，CLI 识别偏小，明明模型能跑更大窗口，Hermes 却保守得要命。这两种情况最后都该回到同一个解决办法：手工写 context_length，不要再赌自动识别会不会突然良心发现。 对本地模型来说，稳定往往比自动优雅更重要。你真想省时间，就别让工具彼此猜来猜去。

四、真正的排障第一步，不是重启，而是先看 /usage

Hermes 官方对 Context 问题给的第一手动作很明确：除了看启动时的 Context limit，还可以在会话里用 /usage。这个命令的重要性，经常被严重低估。因为它不是单纯告诉你"用了多少 token"，而是帮助你判断：到底是会话真的长到快炸了，还是一开始识别的上限就不对。前者应该用 /compress 或开新会话解决，后者应该改配置，不然你压缩十次也只是拿错药治错病。

所以一个最实用的判断逻辑是这样的。 如果 /usage 显示你已经逼近当前上下文上限，那先别怀疑检测错了，先用 /compress。 如果 /usage 看着并没那么夸张，但 Hermes 却在第一段稍长会话里就超限，那就优先怀疑 context detection。 如果是本地或 custom provider，更要优先看 config.yaml 里有没有明确写 context_length。 这种顺序，比上来就换模型、删会话、重装 Agent 有用得多。

五、/compress 不是摆设，它就是官方给你的正规减压阀

Hermes 官方 FAQ 对这件事没有一点含糊。遇到上下文太长，官方第一个建议就是：

/compress

然后才是开一个新会话 hermes chat，或者换一个更大窗口的模型。文档还专门在性能问题部分提醒，长对话、冗长系统提示、频繁工具调用会持续累积上下文，应该定期用 /compress 降低 token 占用，同时尽量保留关键上下文。 这意味着 /compress 不是一个聊胜于无的小功能，而是 Hermes 用来维持长工作流可持续性的核心机制之一。

很多人最常犯的错，是把 /compress 理解成"万不得已再用"。其实如果你是重度任务用户，应该把它当成正常维护动作。就像跑日志、清缓存、轮转数据库一样，长会话的上下文也需要整理。你要是一直堆，从不压，最后不是模型不行，是你自己把工作台堆成了垃圾山。机器再能忍，也不是来替你做数字囤积癖托底的。

六、开新会话不丢人，很多时候它比死撑更专业

Hermes 官方在 FAQ 和性能问题说明里都提到，当会话太长时，除了 /compress，还可以直接开一个新会话 hermes chat，必要时以后再 --continue 恢复特定会话。这件事特别值得强调，因为很多用户对"开新会话"有一种奇怪的羞耻感，好像一旦重开，就说明 Agent 设计失败。其实不是。对长任务系统来说，切分工作、压缩历史、按阶段续跑，本来就是专业操作，不是妥协。

尤其是在 Context 检测已经确认没问题的前提下，如果你还坚持把所有东西都塞进一个会话里，那就不是工具的问题，而是你在用"永不归档"的方式挑战物理上限。再强的模型也不是无限容器，何况 Hermes 还要把工具输出、系统提示和执行轨迹一起带着跑。适时开新会话，很多时候比继续硬聊要稳得多。

七、custom provider 最该做的，不是祈祷兼容，而是把窗口写死

Hermes 的一个大优点是 provider 很自由，但自由的另一面就是检测结果更不稳定。官方 FAQ 已经给了 custom provider 的例子，允许你在 custom_providers 下面为每个模型单独设置 context_length。这个设计其实非常聪明，因为 Hermes 已经默认承认了一件事：不同自定义端点的能力声明、OpenAI-compatible 程度、上下文报告方式都可能不一致。与其让它自动猜，不如让你明确指定。

这对接入 GLM、Qwen、本地 vLLM、llama.cpp、SGLang 或其他兼容端点的人尤其重要。你只要走 custom 路线，就不该把上下文长度当成"它自己应该知道"的东西。最稳的办法就是把 base_url、模型名、context_length 一起写明。这样做虽然少了点自动魔法的美感，但换来的是可预测。对真正跑长任务的人来说，可预测比优雅重要得多。毕竟生产事故从来不会因为你配置写得简洁就给你打折。

八、如果是第一段长对话就爆，不要优先怪模型，先怪配置

这一点值得单独拉出来，因为它真的太常见了。Hermes 官方原话已经把判断标准说出来了：如果在第一段长对话里就出事，很可能是上下文检测错了。 这个提示的价值在于，它帮你把"模型太弱"和"配置不对"这两种完全不同的根因区分开。前者要换模型，后者要改配置。你要是一上来就换模型，等于把配置错当成了采购问题，浪费时间还容易把判断搞乱。

更实际一点说，很多大窗口模型本身没问题，问题出在中间层。可能是 provider 接口没把真实窗口传出来，可能是 Ollama 报了最大值不是当前值，可能是 custom endpoint 兼容但不完整，也可能是你自己本地参数设了 num_ctx 却没写进 Hermes 配置。这个时候，最靠谱的动作永远不是"再试一次看运气"，而是回到 Context limit、/usage 和 config.yaml 三件事上。排障最怕靠运气，运气这东西对报错从来不讲道理。

九、最省时间的排查顺序，照着走就行

如果你现在正被 Hermes 的 Context 问题折磨，最实用的顺序我建议就这一套。

先看启动时 CLI 打印的 Context limit。 这一步是判断自动检测有没有明显离谱的第一证据。

再进会话里跑 /usage。 看是会话真长了，还是明明没多少内容却快到顶。

如果会话真的长了，先 /compress。 必要时直接开新会话，不要死撑。

如果第一段长任务就出错，优先怀疑检测错了。 去 ~/.hermes/config.yaml 里手工写 context_length。custom provider 逐模型单独写。

如果你用的是 Ollama 或本地兼容端点，不要盲信自动报告值。 官方已经提醒过，Ollama 可能报告最大窗口而不是实际 num_ctx。

如果模型本身低于 64K，就别再和现实较劲了。 这类模型从设计上就不适合 Hermes 的多步工具链。

结语

Hermes 的 Context Length 问题，表面上看像一个报错，实质上暴露的是三层现实。第一，Hermes 不是轻量聊天工具，它天生需要更大的工作记忆。第二，自动检测不是永远靠谱，特别是在本地模型、Ollama 和 custom provider 场景里。第三，长任务系统不是靠硬撑维持的，而是靠 /usage、/compress、新会话和手工修正配置一起维持的。

说到底，Context length exceeded 真正烦人的地方，不是它报错，而是它很容易让人误以为"Agent 不行"。其实多数时候，不是 Agent 不行，是你给它配的脑子、你告诉它的脑容量，或者你维护会话的方式，本来就不对。工具没那么冤，错配才是罪魁祸首。

如果 Hermes 连基础会话都还没稳定跑通，而不是单纯的长任务超限，建议先回到 Hermes 装好了却不工作怎么办，先把 Provider 和基础链路排干净。

有些任务失败并不完全是上下文窗口不够，也可能是执行阶段被安全审批拦住了，对这类情况可以继续看 Hermes 危险命令为什么总被拦。