Hermes Agent 这类长期运行的代码 Agent，经常需要自动压缩上下文：当对话太长时，把中间历史总结成语义摘要，再继续保留最近消息。接入 DeepAI API 中转站、GitHub Copilot、OpenAI-compatible 网关或多模型路由时，一个很隐蔽的问题是：主模型能正常工作，但辅助压缩模型因为参数不兼容返回 400。
max_completion_tokens，如果辅助压缩任务仍发送 max_tokens，会导致 400 和上下文摘要失败。GitHub Issue 背景：上下文压缩请求被 max_tokens 拒绝
Hermes Agent 的 GitHub 仓库中有一个已关闭且标记为 completed 的 Issue：用户使用 GitHub Copilot Provider 和 GPT-5 系列模型做 auxiliary.compression。当自动上下文压缩触发时，Hermes 发送了 max_tokens，但上游 OpenAI-compatible endpoint 返回 400，提示该模型不支持 max_tokens，应使用 max_completion_tokens。
错误后果不是简单的“压缩失败重试”。Hermes 会插入一个 fallback context marker，并移除中间对话窗口，却没有生成真正的语义摘要。这会让 Agent 丢失之前的文件路径、命令输出、决策过程和已经解决的问题。
为什么 max_tokens 会变成兼容性问题
不同模型家族和 API 版本对“生成长度限制”的参数命名不完全一致。旧式 Chat Completions 里常见 max_tokens，而一些新模型或新版 OpenAI-compatible endpoint 会要求 max_completion_tokens。如果中转站、客户端或辅助任务路径没有跟着模型类型切换参数，就会出现 400。
错误示例：
{
"max_tokens": 1024
}
新模型可能要求：
{
"max_completion_tokens": 1024
}
DeepAI API 中转站用户应该关注哪一层
如果你通过 DeepAI API 中转站统一接入多种模型，建议把请求链路拆开看：
- Hermes 主模型路径：普通聊天、代码执行和工具调用是否正常。
- 辅助压缩路径：
auxiliary.compression是否使用同一个 Provider、同一个参数转换逻辑。 - 中转站路由层：是否知道目标模型需要
max_completion_tokens。 - 上游模型层：400 错误的具体 message 是参数不支持、模型不存在，还是认证失败。
不要只验证主聊天，因为上下文压缩、标题生成、记忆写入、审批等辅助任务可能走另一套代码路径。
Hermes 配置排查思路
Issue 中的示例配置大致是主模型和辅助压缩都使用新模型：
model:
default: gpt-5.5
provider: github-copilot
api_mode: chat_completions
auxiliary:
compression:
provider: copilot
model: gpt-5.4
如果换成 DeepAI API 中转站或自定义 Provider，建议同时确认：
- 主模型和辅助压缩模型是否都支持当前 API 模式。
- 辅助任务是否继承了正确的 base_url 和 api_key。
- 目标模型需要
max_tokens还是max_completion_tokens。 - 是否有模型别名导致路由到不同上游。
看到 fallback context marker 要警惕
上下文压缩失败后，系统可能为了继续运行而插入 fallback marker。短期看任务没有崩溃，但长期看会丢失语义摘要。对代码 Agent 来说，这会让后续回答忘记之前改过哪些文件、为什么做某个选择、哪些命令已经运行过。
- 如果看到 compression summary failed，先查错误码和参数。
- 如果看到 fallback marker，说明中间历史可能没有被真正总结。
- 如果 Agent 后续答非所问，检查是否发生过压缩失败。
- 不要只看当前尾部消息是否保留，重点看中间窗口是否有语义摘要。
DeepAI 后台日志怎么辅助定位
通过 DeepAI API 中转站接入时，可以用后台日志快速判断问题在哪：
- 请求是否到达：没有日志，说明 Hermes 可能没有走中转站。
- 请求模型：确认压缩任务使用的是否是你预期的模型 ID。
- 错误码：400 通常看参数，401 看 Key，404 看模型和路径，429 看额度与频率。
- 请求体摘要：确认是否包含
max_tokens或max_completion_tokens。 - 任务类型：尽量区分主聊天、压缩、标题生成和记忆写入。
生产建议：把参数兼容做成路由策略
多模型中转站最好不要把所有模型都当成同一种 OpenAI-compatible。建议按模型家族或 endpoint 维护参数策略：哪些模型使用 max_tokens，哪些使用 max_completion_tokens，哪些不支持 temperature，哪些不支持 stream usage。这样 Hermes、Claude Code、Dify、n8n 等客户端就不用各自踩一遍坑。
如果你在 DeepAI API 中转站里为 Hermes 单独创建 Key，也可以按 Key 或模型别名做日志过滤，快速定位辅助任务的异常消耗和 400 错误。
参考资料
- Hermes Agent GitHub 仓库
- Hermes Agent Issue #34530：auxiliary context compression sends max_tokens
- Hermes Agent custom Provider 辅助任务走错端点排查
- DeepAI API 中转站教程导航
总结
Hermes Agent 接入 DeepAI API 中转站时，主模型可用不代表辅助压缩任务一定可用。遇到上下文压缩 400、fallback marker 或中间历史丢失时，要重点检查目标模型的长度参数：该用 max_tokens 还是 max_completion_tokens。把主任务和辅助任务的参数兼容逻辑统一起来，才能让长期 Agent 会话真正稳定。