Hermes Agent 报错 "Response Remained Truncated After 3/4 Continuation Attempts" 修复

当 Hermes Agent 在回合结束时提示 Response remained truncated after 3 continuation attempts 或 Response remained truncated after 4 continuation attempts，说明当前回合因达到单轮输出上限（finish_reason='length'）或遇到流式连接中断（st.is_stub）进入了自动续写恢复循环（_continue_text），但在用尽重试次数后仍未能拿到完整结束符。

现在就能做的 3 步解法

1. 看报错前一行的告警信号： 检查重试计数（1/3 或 1/4）正上方的那一行提示（或运行 hermes logs errors -n 100），判断本次是单轮输出达到上限（finish_reason='length'）、流式传输中途断开（Stream interrupted — requesting continuation），还是未产出可见文本（no visible text was produced）。
2. 不要原样重发，先保住已有输出： 先把报错上方已拼接出的半截回复复制保存；如果当前回合涉及改文件或跑命令，先执行只读命令 /diff、/status 与 /context 确认工作区状态，避免盲目重发覆盖磁盘改动或翻倍消耗 Token。
3. 让模型只续写剩余部分，或缩小单轮输出、换输出上限更大的模型： 明确要求模型“只从最后完成的小节继续往下写”，或把大体积文件修改拆成多次小补丁；若受制于当前模型的单轮输出上限，可改用输出上限更大的模型。使用一个 UniRoute API Key（见 Hermes CLI 接入文档）即可在 Hermes 内切换 Claude、GPT、DeepSeek 等模型——例如 DeepSeek 官方价格页标明 deepseek-flash 与 deepseek-v4-pro 的最大输出长度为 384K（截至 2026-10-27，实时费率见 UniRoute 定价页；注意 UniRoute 目录里各模型的输出上限可能不同，请以 /zh/models 为准）。

本文覆盖的报错原文变体（核对自 NousResearch/hermes-agent 固定提交 b0427271e33c8b239985d3d66bd9d4f10f87e25b 源码及官方 Issue #628、#9372、#46833、#58423）：

• Response remained truncated after 3 continuation attempts（2026 年中期之前的发布版，如 v0.9.0–v0.16.0）
• Response remained truncated after 4 continuation attempts（当前 main 分支 agent/turn_truncation.py）
• ⚠️ Response still truncated after N continuation attempts — no visible text was produced.
• Codex response remained incomplete after 3 continuation attempts（codex_responses 协议路径）

注：用户也会搜索类似 "response still truncated after two output token limit continuations" 的写法——该表述并非 b0427271 源码中的字面原文，但指向同一类输出续写耗尽故障。

核查范围说明（2026-10-20）：本文基于 NousResearch/hermes-agent 官方 Issue 及固定提交源码（b0427271e33c8b239985d3d66bd9d4f10f87e25b）核查整理。我们未在 UniRoute 环境复现该故障，文中步骤旨在帮助开发者快速定位原因并保全既有进度，不作“单一配置即可包治所有上游截断”的承诺。

---

1. 快速分流：先看报错前一行的告警信号

最终的 Response remained truncated... 仅代表“续写恢复未能在上限内完成”。在重发指令前，请先核对重试计数（1/3 或 1/4）正上方紧邻的告警提示或 hermes logs 日志，区分具体触发路径：

---

2. 停止条件与计费边界（切勿盲目连点重试）

遇到续写失败时，请勿直接连按重试。由于自动续写会向上游发送携带历史上下文的后续请求，盲目重跑同一条大 Prompt 往往会白白增加 Token 消耗。

1. 不要仅凭报错数字硬推实际请求数或是否有正文：在 agent/turn_truncation.py（第 305–370 行）中，_continue_text 会先将计数器加一（n += 1），仅在满足 n < 4 and filled is None 时才真正发出下一次续写请求；若检测到上下文窗口已满也会提前终止。同时，若上游或中断存根未产生可见文本（例如空存根或思考阶段耗尽预算，见第 316–320、356–360 行），屏幕上会提示 no visible text was produced。因此，不能用固定公式从报错文案反推是否有可见正文、实际发出了几次成功请求，或是否产生费用（是否收费及具体金额取决于所连服务商、本地免费部署或云端部署方式、实际 usage 记录与账单结算）。
2. 以真实调用记录与账单为准：请先在会话中运行 /usage 和 /status，并查看 hermes logs（agent.log）或上游服务商日志中的实际 api_calls 与 Token 统计。如果你通过 UniRoute 接入 Hermes，可前往 UniRoute 控制台核对每笔请求的实际记录（注：控制台可见的调用日志与钱包余额结算属于不同记录环节）。
3. 先保全工作区与会话现场：
   • 如果报错上方已经打印出拼接后的部分回复（partial_response），先把可用内容复制或保存下来，避免从零重算。
   • 如果该回合包含文件读写或命令执行，先运行只读的 /diff（或在终端执行 git status / git diff）以及 /agents，确认前序步骤是否已经修改了磁盘文件。
   • 停止条件：如果缩小范围提示后连续 2 次依然触发截断，请立即停止重试，先执行第 4 节的只读诊断。

---

3. 为什么有的报“3 次”、有的报“4 次”？为什么旧帖的 max_tokens 已失效？

在检索 GitHub Issue 时，你常会看到不同帖子里给出的报错次数和配置建议互相矛盾，这源于 2026 年间 Hermes 的版本演进。

1. 历史版本（3 次）与当前 main 分支（4 次）

• 历史版本显示 3 continuation attempts：2026 年 3 月至 7 月的多条官方 Issue——包括 #628（2026 年 3 月）、#9372（v0.9.0，2026 年 4 月）、#46833（v0.16.0，2026 年 6 月）和 #58423（2026 年 7 月）——均报出 Response remained truncated after 3 continuation attempts。
• 当前 main 分支显示 4 continuation attempts：在当前 agent/turn_truncation.py（第 305–370 行）中，_continue_text 最终返回 Response remained truncated after 4 continuation attempts（而 codex_responses 的未完成处理分支仍保留 3 次的文案）。
• _continue_text 同时承接 length 与流中断存根（st.is_stub）：如 agent/turn_truncation.py（第 328–337 行）所示，_continue_text 既处理 finish_reason == "length"，也处理流式响应中途断开留下的 st.is_stub 路径。因此，不能绝对地将该报错归结为“只因输出 Token 上限引起、绝不涉及流中断”。

2. 版本敏感配置与官方 Issue 状态核对表

---

4. 只读诊断命令清单（不改状态、不耗费额外 Token）

在修改配置或压缩会话前，先使用官方 CLI 命令参考文档 与 斜杠命令参考文档 中的只读命令确认现状：

会话内只读斜杠命令（零 LLM 调用，不影响 Prompt Cache）

• /status：显示当前模型、Provider、Session ID、累计 Token 以及本地会话摘要。由内存直接计算，零 LLM 调用，不会重置 Prompt Cache（见 slash-commands.md 第 65 行）。
• /context（简写 /ctx）：展示上下文窗口占用比例、距自动压缩阈值的余量及各规则文件 Token 估算。同样为纯本地只读，零 LLM 调用，不影响缓存（见 slash-commands.md 第 66 行）。
• /usage 与 /config：只读查看当前会话用量与生效配置。
• /diff 与 /agents：只读查看工作区未提交的 Git 改动，以及当前会话是否有正在运行的后台子任务。

终端只读排查命令

# 1. 查看本机安装的 Hermes 版本与 Commit
hermes --version

# 2. 查看运行状态
hermes status

# 3. 执行只读健康检查（首次排查切勿加 --fix）
hermes doctor

# 4. 查看 ~/.hermes/logs/ 中的错误与告警日志
hermes logs errors -n 100
hermes logs --level WARNING --since 1h

• hermes doctor 的能力边界：通过 hermes doctor 仅说明本地配置文件语法和基础网络连通正常，不能证明实际长输出不会撞上服务端限制。
• hermes dump 隐私保护：如需运行 hermes dump 导出环境摘要，切勿添加 --show-keys，并在发帖前手动删去私有文件路径、内网域名和账号标识。默认不要运行 hermes debug share（除非显式加 --local），否则日志会被上传到公共粘贴服务。

---

5. 先保全、再恢复的操作步骤（含明确的有损与请求/费用边界）

由于上下文压缩（/compress）属于有损摘要，而新建/重置会话（/new、/reset）会丢弃当前活动上下文，任何恢复操作都无法承诺绝对“无损”。请按从轻到重的顺序操作，并先保全已有成果：

配置文件修改与后台任务注意事项

• 编辑 ~/.hermes/config.yaml 前先关闭客户端：正在运行的 Hermes 会话可能会把内存中的状态回写到 config.yaml，覆盖你的手工修改。若需配置自动上下文压缩（注：当前官方 configuration.md 第 997–1015 行 使用 compression: 配置块，而非早期 #628 评论里讨论的 session_hygiene:），请先退出 CLI 或停止网关。
• 切勿把 /stop 当成常规清理步骤：根据官方 slash-commands.md（第 51 行），/stop 会终止所有正在运行的后台进程（Kill all running background processes）。除非你已通过只读命令 /agents 确认存在卡死的后台任务、核实了它已产生的文件副作用且确认可以强行终止，否则不要随意执行 /stop。
• 严禁删除 ~/.hermes 或 ~/.hermes/state.db：删除该目录会直接破坏本地历史会话数据库、Cron 任务及所有持久化状态。

---

6. 关联上游错误排查指南

若你在 hermes logs errors 中同时看到上游返回 HTTP 500、529 Overloaded 或流空闲断开，可分别参考 Claude Code API Error 500 排障指南、Claude API 529 Overloaded 错误修复方案 与 Claude Stream Idle Timeout 流空闲超时排查指南。