Hermes模型频繁返回空值故障分析与修复建议

背景

在基于大语言模型（LLM）构建的 AI 应用开发中，模型偶尔返回空响应（Empty Response）是一个常见但极具干扰性的故障现象。以 Hermes App 为例，开发者在调试过程中发现，模型在对话过程中会间歇性地返回空内容，导致前端显示为“机器人卡住”或连续发送空白消息。

具体的报错日志表现为 Empty response from model 以及 model returned empty after tool calls。这一现象并非单一用户的特例，而是涉及模型提供商、编排层（Orchestration）逻辑以及上下文处理等多个层面的复杂问题。当系统执行工具调用（Tool Calls）后，若主回答阶段未能生成有效文本，整个对话流便会陷入停滞或产生不可预期的行为。

核心内容

该问题本质上是模型在特定轮次返回了空文本（Empty Text），而非系统完全崩溃。日志中出现的 retrying (1/3) 和 retrying (2/3) 表明，Hermes 的编排层已经检测到“工具执行成功但模型未输出内容”的情况，并触发了补救性的重试机制。然而，现有的重试策略不足以彻底解决体验问题。

通过对故障现象的层层剖析，根因主要指向以下三个方向，按概率从高到低排列：

1. 模型提供商偶发返回空 Completion：这是最可能的原因。HTTP 请求成功，工具调用也成功，但 message.content 为空或仅包含空白字符。日志中连续两次重试仍返回空值，符合上游响应结构合法但无正文的特征。
2. Hermes 编排层的状态拼装 Bug：在工具调用后的收束回复阶段，可能存在状态拼接错误。例如，工具结果合并后，发送给模型的消息体中包含格式错误（Malformed Content），或者 assistant tool-call turn 与后续 follow-up turn 的组装方式不符合特定 Provider 的要求，导致 Provider 不报硬错，仅返回空响应。
3. 上下文过载或指令冲突：当上下文过重或存在冲突指令时，模型可能陷入“无操作”（No-op）状态。这种情况通常表现为“有时正常、有时空白”，尤其在工具调用后消息结构最复杂时更容易触发。这更多是诱因而非唯一根因。

值得注意的是，search_files("AGENTS.md") 等具体 Skill 文件本身并未损坏，因为工具已成功返回结果，故障点在于拿到结果后的下一轮自然语言生成环节。

针对此问题的解决思路，建议从空响应可观测性入手，而非盲目猜测 Prompt 问题。具体的排查与修复策略包括：

• 增强日志记录：记录每次空响应的关键指标，包括 Provider/Model 名称、Request ID、工具调用数量、最后一轮发送给模型的 Message 数量与总字符数、原始 Payload（特别是 content、tool_calls、finish_reason），以及空响应发生的阶段（首轮、重试中、还是重试后恢复）。
• 优化 Fallback 逻辑：现有的“Nudge to continue”和简单重试机制不够稳健。建议采用分级处理：
  1. 第一次空响应：原样重试一次。
  2. 第二次仍为空：压缩上下文，仅保留最近的用户消息、必要的系统提示及最近一次工具结果的摘要，再重试。
  3. 第三次仍为空：直接输出结构化错误信息（如提示检查 Provider Payload 或 Adapter 消息组装），停止假装继续生成，避免前端出现连续空白消息。
• 增加 Empty-Content Guard：在代码层面增加前置检查，如果模型返回空字符串、纯空白或空数组内容，不应将其作为成功的 Assistant Message 写回会话，而应直接进入 Fallback 分支。

排查代码时，应重点关注以下模块：Provider Adapter（API 返回转统一 Assistant Message 的地方）、Tool-call Continuation Loop（工具结果回填后再次请求模型的地方）、Retry Middleware（判断“什么算空响应”的地方）以及 Discord/聊天平台输出层。一个实用的判定技巧是检查原始 Provider 返回中是否有 token usage 但 content 为空：若有 Usage 且 finish_reason 正常但 Content 为空，则大概率是上游模型或 Adapter 的兼容性问题。

关键要点

• 故障定性：模型返回空响应是编排层检测到“工具成功但无文本输出”后的重试场景，而非系统完全崩溃。
• 根因排序：
  • 最高概率：模型提供商偶发返回空 Completion（HTTP 成功但无正文）。
  • 次高概率：Hermes 编排层在工具调用后拼接消息体时存在格式或逻辑 Bug。
  • 较低概率：上下文过载或指令冲突导致模型陷入 No-op。
• 非故障点：具体的 Skill 文件（如 search_files）通常不是问题根源，问题出在工具结果后的自然语言生成环节。
• 排查重点：
  • 记录原始 Payload，特别是 content、tool_calls 和 finish_reason。
  • 检查 Provider Adapter 和 Tool-call Continuation Loop 的代码逻辑。
  • 利用 token usage 存在但 content 为空作为判断上游兼容性问题的关键指标。
• 解决方案：
  • 实施分级 Fallback 策略：重试 -> 压缩上下文重试 -> 输出结构化错误。
  • 增加 Empty-Content Guard，拦截空字符串/空白字符，防止其作为有效消息写入会话。

意义与影响

这一案例揭示了在构建基于 LLM 的应用时，**可观测性（Observability）与容错机制（Fault Tolerance）**的重要性往往被低估。许多开发者倾向于优先优化 Prompt 工程，但当模型返回空响应时，盲目调整 Prompt 往往无效，因为问题可能出在基础设施层（Adapter、Retry 逻辑）或上游模型的不稳定性上。

通过建立完善的空响应监控和分级处理机制，开发者可以显著降低“幽灵消息”或“卡死”现象对用户体验的负面影响。此外，区分“上游模型问题”与“本地编排 Bug”的能力，是提升 AI 应用稳定性的关键技能。对于 Hermes 这类集成多种工具和复杂上下文的应用，标准化的错误处理流程和详细的日志记录是排查此类间歇性故障的唯一可靠途径。