Hermes Agent 接入 DeepAI API 中转站：Responses API 空工具名 input[n].name 400 排查

Hermes Agent 通过 custom OpenAI-compatible Provider 接入 DeepAI API 中转站 或其他 GPT-5 网关时，如果普通单轮问题能回答，但多轮跟进突然报 HTTP 400: Invalid 'input[n].name': empty string，通常不是 Key 失效，也不是简单的 Base URL 拼错。这个错误更像是 Responses API 请求历史里混入了一个不合法的工具调用 item：工具名为空、tool_call_id 为空，或者 function call output 找不到对应 call。

问题背景：多轮跟进触发 input[n].name 空字符串

在 NousResearch/hermes-agent Issue #11411 中，用户描述了一个 gateway 场景：Hermes 使用 custom OpenAI-compatible provider 和 gpt-5.4，第一条消息可能成功，但短跟进消息会触发 Responses API 400。错误里出现多个不同位置的 input[3]、input[4]、input[18]，共同点是 name 为空字符串。

Issue 中的高概率诊断是：Hermes 在构造或回放 Responses input items 时，生成了一个 malformed function_call item，或者把一个空 name / 空 tool_call_id 的 tool result 放进历史。严格校验的上游后端会拒绝这种请求，于是多轮会话被 400 打断。

典型错误：
HTTP 400: Invalid 'input[4].name': empty string.
Expected a string with minimum length 1,
but got an empty string instead.

为什么这类错误在 API 中转站场景更常见？

DeepAI API 中转站会把客户端请求统一路由到不同模型、不同协议和不同上游。对于普通 Chat Completions，请求历史通常是 messages；但 Responses API 会携带更结构化的 input item，包括 message、function_call、function_call_output、reasoning 等。字段越结构化，上游校验越严格，历史里一个空 name 都可能让整个请求失败。

这也是为什么同一个问题在单轮 prompt 里不复现，到了 gateway 多轮、Weixin/Feishu/Telegram 等消息平台里更容易出现：长会话、工具调用、上下文压缩、memory flush 和 session replay 都会增加历史污染的概率。

DeepAI API 中转站日志应该重点看什么？

排查时，先不要只看状态码。建议在 DeepAI API 中转站日志里打开请求体摘要，检查失败请求中的 Responses input item：

1. 是否有 type=function_call 但 name=""。
2. 是否有 function_call_output 的 call_id 找不到对应 function call。
3. 是否有 role=tool 且 name 或 tool_call_id 为空。
4. 失败 index 是否每次变化。如果变化，说明是历史构造或回放过程中污染，而不是固定某个用户输入。
5. 同一 prompt 用 /v1/chat/completions 是否能成功。如果能，说明 Responses item 兼容性是重点。

排查路径：先分清协议选择还是历史污染

Hermes 之前也出现过 custom GPT-5 endpoint 被强制走 codex_responses 的问题。如果你的自定义 DeepAI API 中转站或网关并没有完整实现 Responses 语义，建议优先确认 Hermes 实际走的是哪个协议。若配置明明希望走 chat_completions，但日志里只有 /v1/responses，要先解决协议选择问题。

如果确认必须使用 Responses API，那么重点就变成历史清洗：在发送前拒绝空工具名、拒绝空 tool_call_id、拒绝无匹配 call_id 的 function output，并且不要把这类失败请求继续写入 session，以免下一轮继续污染。

发送前建议校验：
- function_call.name 非空
- function_call.call_id 非空且唯一
- function_call_output.call_id 有对应 function_call
- role=tool 的 name / tool_call_id 不为空
- 失败请求不要持久化进会话历史

最小复现流程

1. 使用 Hermes custom provider，Base URL 指向 https://api.deepai.wang/v1 或你的中转站地址。
2. 选择会触发 Responses 路径的 GPT-5 类模型。
3. 先发送一个完整问题，再发送短跟进，例如“那上一点展开说说”。
4. 若出现 400，在中转站日志里查失败请求的 input[n]，定位空 name 的 item 来源。
5. 执行 /reset、重启 gateway 后再次测试；如果仍复现，说明不只是 stale session，而是 Hermes 构造路径可能持续生成 malformed item。

常见坑位

• 只看 /reset：重置会话能清掉一部分历史，但如果代码路径继续生成空工具名，问题会再次出现。
• 把所有 400 都当 Key 问题：input[n].name 是请求体 schema 错误，不是认证失败。
• Chat 和 Responses 混用：Chat Completions 能容忍的消息形状，不代表 Responses input item 合法。
• 隐藏原始上游错误：中转站如果只返回“模型请求失败”，用户就无法定位是哪个 input index 出错。
• 失败请求继续写入历史：这会造成 session growth loop，让后续请求越来越难清理。

DeepAI API 中转站的产品建议

对于 DeepAI API 中转站这类多客户端入口，建议为 Responses API 增加“结构化错误摘要”：当上游返回 input[n].name、call_id、function_call_output 这类字段错误时，在后台展示 index、item type、字段名和截断后的安全摘要。这样 Hermes、Codex、OpenClaw 这类 Agent 客户端排查起来会快很多。

从 SEO 角度，本文覆盖的真实搜索词包括：Hermes Agent Responses API 400、Invalid input name empty string、DeepAI API 中转站 GPT-5 gateway、OpenAI-compatible custom provider、function_call.name 空字符串。用户搜这些词时，往往已经有真实生产故障，文章越具体越有价值。

参考资料

• Hermes Agent Issue #11411：Responses API 400 Invalid input[n].name empty string
• Hermes Agent Issue #10473：custom GPT-5 endpoint forced to codex_responses
• Hermes Agent GitHub 仓库

总结

Hermes Agent 接入 DeepAI API 中转站后，如果多轮会话触发 Invalid input[n].name: empty string，排查重点是 Responses input history 是否混入空工具名或空 tool_call_id。先用中转站日志定位失败 item，再确认 Hermes 是否误走 Responses 路径，最后在发送前清洗 malformed tool call。把协议选择、历史回放和上游 schema 校验分开，才能稳定运行长期 Agent gateway 会话。