Hermes Auxiliary 任务排错：主聊天正常，为什么标题生成、压缩和后台 review 会失败？

Hermes Agent 有一个很容易被忽略的事实：主聊天能正常回复，不代表所有后台任务都正常。

很多用户接入 DeepAI 或其他 OpenAI-compatible API 后，只测试一句：

hello

能回答，就以为 Hermes 全链路没问题。

但 Hermes 不只是主聊天。它还有一堆 auxiliary / background 路径：

title generation；
context compression；
session search；
background review；
memory provider teardown；
auxiliary provider routing；
compression model feasibility check。

这些路径可能使用不同客户端、不同 provider 解析逻辑、不同 base_url 处理、不同 stdout/stderr 管理。于是就会出现一种很迷惑的情况：

主对话正常，但标题生成 502；
主模型正常，但压缩判断错；
主 provider 正常，但 auxiliary provider 404/403；
后台 review 不该说话，却把 teardown 日志漏到父终端。

这篇继续基于 Hermes GitHub Issues / PR，专门讲 auxiliary 任务排错。

先分清：main agent 和 auxiliary client 不是一条路

Hermes 里的 main agent 负责和用户对话、调用工具、维护任务状态。

Auxiliary client 则常用于“辅助但重要”的小任务，例如：

给会话生成标题
压缩上下文
生成摘要
搜索 session
做 background review
检查 compression model 是否可用

它们都可能调用 LLM，但调用路径不一定和主对话完全一样。

所以一个很关键的判断是：

如果主对话正常，但辅助任务失败，不要马上改 DeepAI Key 或 Base URL。

先问：失败的是 main path，还是 auxiliary path？

Issue 1：Windows 系统代理让 auxiliary client 的 localhost 请求变成 502

判断是不是这个问题

如果你看到：

WARNING agent.title_generator: Title generation failed: Error code: 502

并且满足这些条件：

Windows；
开了系统代理；
auxiliary provider 指向 localhost / 127.0.0.1；
主聊天正常；
curl localhost endpoint 正常；

那就高度怀疑 trust_env=True 代理劫持。

处理建议

可以按优先级尝试：

1. 设置 NO_PROXY=localhost,127.0.0.1
2. 关闭 Windows 系统代理再测
3. 避免 auxiliary endpoint 指向 localhost
4. 升级到修复 auxiliary client trust_env 行为的 Hermes 版本
5. 如果自己维护代码，对 localhost base_url 使用 httpx.Client(trust_env=False)

如果你用的是 DeepAI 公网地址：

https://api.deepai.wang/v1

这个问题不一定直接命中。但如果你的结构是：

Hermes auxiliary → 本地代理 / 本地转发 → DeepAI

那仍然可能中招。

Issue 2：Azure Foundry auxiliary provider 没走 anthropic_messages 路径

这个 PR 的启发

Auxiliary provider routing 很容易和 main runtime 不一致。

主模型正常，不代表辅助模型也走了同样的协议。

如果你遇到：

主聊天正常
但标题生成 / 压缩 / background task 报 404 或 403

要查 auxiliary path 是否正确读取了：

provider；
api_mode；
base_url；
per-task override；
OpenAI-wire vs Anthropic-wire。

虽然这个 PR 针对 Azure Foundry，但它对所有复杂 provider 都有参考意义。

对 DeepAI 用户怎么理解

DeepAI 的常规 OpenAI-compatible 路径一般是：

https://api.deepai.wang/v1
chat_completions 风格

配置简单很多。

但如果你在 Hermes 里给不同 auxiliary task 指定了不同 provider，或者通过本地代理/网关中转 DeepAI，就要确认 auxiliary task 没有走错 base_url 或 api_mode。

Issue 3：compression model context length 判断没拿到 custom_providers

对 DeepAI 长上下文模型用户的意义

如果你用 DeepAI 接入长上下文模型，不要只看主对话能不能处理长文本。

还要观察：

Hermes 是否触发 context compression；
compression 模型是否是 auto；
auto 是否复用了 main provider / base_url；
custom provider 里的 context_length 是否被 auxiliary path 正确读取；
压缩前后的日志是否正常。

如果长上下文任务表现不稳定，不一定是 DeepAI 模型不行，也可能是 Hermes compression feasibility 判断错。

Issue 4：background review 的 memory provider teardown 输出泄漏

为什么这也算 auxiliary 排错

因为它说明：background task 的问题不一定是“回答错”，也不一定是“模型错误”。

它可能是：

stdout/stderr 重定向范围不对；
memory provider shutdown 时机不对；
后台 fork 输出泄漏；
父终端被后台任务日志污染。

如果你在 Hermes 主终端里看到莫名其妙的后台 review、memory sync、provider teardown 输出，不一定是 agent 主动说话，也不一定是 DeepAI 输出。

它可能只是 background review 的 cleanup log 泄漏。

Auxiliary 问题速查表

现象	更可能原因	优先检查
主聊天正常，title generation 502	Windows proxy 劫持 localhost	NO_PROXY、trust_env、aux base_url
主模型正常，auxiliary provider 404/403	aux path 没按 api_mode 路由	provider、api_mode、base_url、per-task override
长上下文压缩异常	compression context length 检测错	custom_providers、context_length、compression logs
后台 review 输出污染终端	stdout/stderr redirect 范围问题	background review、memory provider teardown
curl 正常但 auxiliary 失败	curl 与 SDK/aux client 行为不同	SDK client、proxy、headers、base_url rewrite

DeepAI 接 Hermes 时，别只测主对话

如果你把 DeepAI API 中转站接进 Hermes，基础测试当然要做：

curl https://api.deepai.wang/v1/chat/completions \
  -H "Authorization: Bearer YOUR_DEEPAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_MODEL_ID",
    "messages": [{"role": "user", "content": "reply ok"}]
  }'

但这只证明 DeepAI endpoint 可用。

Hermes 里至少还应该测：

1. Title generation

开一个新会话，看标题是否正常生成，日志里有没有：

title_generator failed
502
403
404

2. Context compression

给一个较长任务，观察是否触发压缩，以及压缩后是否继续稳定。

3. Session search / summary

如果 Hermes 使用 session search 或 memory summary，确认辅助请求没有走错 provider。

4. Background review

如果启用后台 review，看父终端是否出现不该出现的 review 输出或 teardown 日志。

5. 不同 provider 的 auxiliary override

如果 main model 用 DeepAI，但 auxiliary 指向另一个 provider，或者反过来，一定要确认 base_url、api_mode、key、headers 都是按任务生效的。

一个更稳的 DeepAI + Hermes 配置思路

为了减少 auxiliary 路径踩坑，可以先保持简单：

主模型：DeepAI Custom Endpoint
辅助模型：先跟随主模型 / auto
Base URL：https://api.deepai.wang/v1
API Key：DeepAI API Key
模型：DeepAI 控制台真实模型 ID

先不要一上来就给 title、compression、review 分别指定不同 provider。

等主对话、工具调用、压缩、标题生成都稳定后，再逐步拆分 auxiliary provider。

每拆一次，都测一遍：

main chat
title generation
compression
background task
delegate/subagent

这样出问题时才知道是哪次修改引入的。

总结

Hermes 里的 auxiliary task 是很多问题的隐藏来源。

主聊天正常，不代表 title generation、context compression、session search、background review 都正常。

Windows proxy 可能只影响 auxiliary localhost 请求。

Azure Foundry 这类复杂 provider 可能在 main runtime 正常，但 auxiliary path 没按正确 api_mode 路由。

Custom provider 的 context_length 可能在主模型里正确，在 compression feasibility 里丢失。

Background review 的 cleanup 输出也可能污染父终端。

所以用 DeepAI 接 Hermes 时，不要只测一句 hello。至少要测主对话、标题生成、压缩、后台任务和 delegate。这样才能确认 DeepAI 不是只在主聊天里可用，而是在 Hermes 的 Agent 全链路里稳定可用。