具体现象很好描述 就是, 模型在对话的时候 会返回空的内容.
大概报错内容 在hermes中就是Empty response from model, 以及model returned empty after tool calls
这是我跟hermes app的对话分析, 请问大家遇到过这个现象吗? 怎么解决的?
1. **HermesAPP — 9:16 AM** Model returned empty after tool calls — nudging to continue
2. 对，刚才这次我自己也复现了，现象已经很明确：**不是你的 Hermes 特例，是这条会话里的模型在某些轮次会真的返回空文本**。我上一轮先做了工具调用，结果主回答阶段直接空了；你再提醒一次后，我才能继续说。这和你看到的日志是同一种故障。 现在能确认的事实有两层。 第一层是 orchestration 层已经检测到了“工具成功，但模型没吐字”。你贴的这些：
* ⚠️ Model returned empty after tool calls — nudging to continue
* ⚠️ Empty response from model — retrying (1/3)
* ⚠️ Empty response from model — retrying (2/3) 说明系统不是完全崩了，而是在 **收到空 completion 后进入补救重试**。所以报错核心不是 search_files，也不是某个 skill 文件一定坏了，而是 **模型响应体有时为空**。 第二层是这个问题在当前线程里确实发生了两次：一次是你最开始贴的 Hermes 日志，一次是我刚才那条“调用了工具但 final 为空”的实际行为。这个复现很关键，因为它把范围缩小到：
* 当前模型 / 提供商这一层
* 当前 orchestration 对空返回的处理
* 或者这两者交互时某种特定触发条件 更像根因的是这几种，按概率排： **最像的是模型提供商偶发返回空 completion。**
也就是 HTTP 成功、工具也成功，但 message.content 为空，或者只有空白字符。你日志里连续两次 retry 还是空，很像上游响应结构合法但没正文。 **第二像的是 Hermes 的“工具调用后收束回复”阶段有状态拼装 bug。**
例如工具结果被合并后，传给模型的消息体里有一段 malformed content，或者 assistant tool-call turn / follow-up turn 的组装不符合某个 provider 的要求，导致 provider 不报硬错，只回空。 **第三像的是上下文过重或某段指令冲突，让模型落入 no-op。**
这类情况通常会伴随“有时正常、有时空白”，尤其在工具调用后更明显，因为那时消息最复杂。你这条线程的系统/开发者约束很多，确实会提高触发概率，但这更像诱因，不是唯一根因。 反而**不像**的是 search_files("AGENTS.md") 本身坏了。因为从行为看，它成功返回了结果；真正坏的是“拿到结果后的下一轮自然语言生成”。 如果你要修 Hermes，我建议直接从 **空响应可观测性** 下手，不要先猜 prompt。 先做日志，把每次空响应都记录这几项：
* provider / model 名
* request id
* tool calls 数量
* 最后一轮发送给模型的 message 数与总字符数
* 返回的原始 payload，特别是 content、tool_calls、finish_reason
* 是否是首轮空、重试后空、还是重试后恢复 如果原始 payload 里 content="" 且没 error，那就是上游或适配层兼容问题；如果 payload 结构异常，基本就是 Hermes 自己的 adapter / orchestrator 组装有 bug。 然后把 fallback 改掉。现在它只是：
* nudge to continue
* retry 1/3
* retry 2/3 这不够。更稳的做法应该是：
1. **第一次空响应**：原样重试一次。
2. **第二次还空**：压缩上下文，只保留最近用户消息、必要系统提示、最近一次工具结果摘要，再重试。
3. **第三次还空**：直接输出结构化错误，不再假装继续生成，例如：
模型返回空响应；工具执行成功；最近工具：search_files("AGENTS.md")；建议检查 provider payload / adapter message assembly。 这样至少不会在 Discord 里表现成“机器人像卡住了一样连发空白”。 另一个应该马上加的是 **empty-content guard**。
3. 如果模型返回的是空字符串、纯空白、或空数组内容，不要把它当成功 assistant message 写回会话；应该直接进入 fallback 分支。否则就会出现你刚才看到的那种体验：前端像收到了一条“空回复”。 如果你要排查代码位置，最该看的模块通常是这几个：
* provider adapter：把 API 返回转成统一 assistant message 的地方
* tool-call continuation loop：工具结果回填后再次请求模型的地方
* retry middleware：判断“什么算空响应”的地方
* Discord/聊天平台输出层：是否把空字符串也当成一条可发送消息 一个很实用的判定方法是：
4.*看原始 provider 返回里有没有 token usage，但 content 为空。**
* 如果有 usage、finish_reason 正常、content 空：上游模型或 adapter 兼容问题概率大
1 个帖子 - 1 位参与者
来源: linux.do查看原文