DeepAI Paper Hermes Agent 教程 Discord /btw 带图却像没看见:Hermes background agent 为什么拿不到图片附件

Discord /btw 带图却像没看见:Hermes background agent 为什么拿不到图片附件

在 Discord 里用 Agent 时,很多人会自然地把“文字 + 图片”一起发给机器人:

/btw Which one should I buy?

然后附上两张商品图。

理论上,后台 Agent 应该能看到图片,比较外观、参数、场景,再给出建议。

但 NousResearch/hermes-agent issue #25614 记录了一个很典型的 Gateway 数据链路 bug:图片确实被 Discord adapter 缓存到了本地,但 /btw / /background 这条后台任务路径只把文字 prompt 传给了后台 Agent,附件没有继续传下去。

结果就是:

用户发了图,日志里也看到图片被缓存,后台 Agent 却像完全没看见图片。

这类问题很容易被误判成“模型不支持视觉”“API 不稳定”或“图片太大没识别”,但根因其实在 Hermes Gateway 的命令分发路径。


现象:普通消息能识图,/btw 后台任务看不到图

issue 里的复现很直接:

1. 在 Discord 发送:

   /btw Which one should I buy?

2. 同时附上 1-2 张图片。 3. Discord adapter 日志显示图片已经被缓存。 4. 后台 Agent 回复时完全没有图片上下文。

更关键的是:

普通的 text + image 消息可以正常处理图片。

只有 /btw/background 出问题。

这说明问题不在 Discord 下载附件,也不在视觉模型本身,而在“命令路径”和“普通消息路径”之间的数据传递差异。


/btw 和 /background 是什么关系?

issue 里明确提到:

/btw is an alias for /background

也就是说,下面两种写法走的是同一类后台任务逻辑:

/btw Which one should I buy?
/background Which one should I buy?

它们的目标不是在当前对话里同步回复,而是启动一个 background agent task,让 Agent 在后台处理。

问题也正出在这里:后台任务的入口只拿到了命令参数里的文字,没有把原始事件里的图片字段带过去。


根因:_handle_background_command 只取了文字,没有转发 media_urls

issue 给出的根因非常清楚。

gateway/run.py 里,_handle_background_command 大致只做了这件事:

prompt = event.get_command_args().strip()

然后把这个 prompt 传给:

_run_background_task(...)

后续 _run_background_task 调用:

agent.run_conversation(user_message=prompt)

于是后台 Agent 收到的只有:

Which one should I buy?

没有:

event.media_urls
event.media_types

这就是为什么 adapter 明明缓存了图片,Agent 仍然看不到。

图片停在 Gateway event 上,没有进入 background task。


为什么普通消息没问题?

普通消息路径使用的是另一套处理逻辑。

issue 提到,regular message 的 handle_message 路径会处理图片,约在 gateway/run.py line ~6731 附近。

普通消息会走类似:

Discord attachment
→ adapter 缓存图片
→ event.media_urls / media_types
→ handle_message
→ 视觉增强 / 图片描述
→ agent.run_conversation

/btw / /background 旧路径变成了:

Discord attachment
→ adapter 缓存图片
→ event.media_urls / media_types
→ _handle_background_command 只取 command args
→ _run_background_task 只拿 prompt
→ agent.run_conversation(user_message=prompt)

中间少了一步:

把 media_urls / media_types 传给 background task,并复用视觉增强逻辑。

影响范围:不只是 Discord,所有 background 命令都要警惕

issue 标的是 Discord,因为复现发生在 Discord。

但报告里也写了:

and likely other platforms

原因很简单:如果多平台 Gateway 最终都进入同一个 _handle_background_command,那么只要该函数丢弃 event.media_urls / event.media_types,问题就不只属于 Discord adapter。

Discord 只是最容易复现:

  • 用户常把图片直接拖进频道;
  • /btw 很适合问“买哪个”“这张图是什么”“帮我比较”;
  • 后台 Agent 的回答如果没有图片上下文,会显得特别离谱。

修复方向:让 background task 复用普通消息的 vision pipeline

issue 给出的修复建议是两步:

1. 从 _handle_background_commandevent.media_urlsevent.media_types 传给 _run_background_task; 2. 在 _run_background_task 调用 agent.run_conversation() 之前,使用已有的 _enrich_message_with_vision() 给 prompt 加上图片描述。

也就是说,不要为后台任务重写一套视觉处理,而是复用普通消息已经验证过的路径:

media_urls / media_types
→ _enrich_message_with_vision()
→ enriched prompt
→ agent.run_conversation()

这样有两个好处:

  • 普通消息和后台任务的图片理解行为一致;
  • 不会影响不带图片的 background task,向后兼容。

issue 评论也提到,该问题是 #24252 的 duplicate,并且 PR #25603 已经有开放修复:把 media_urls / media_types 从 event 转发给 background agent task。


排查时怎么判断是 Gateway 丢附件,而不是模型不会看图?

遇到 /btw 带图没效果,可以按这个顺序排查。

1. 普通消息 + 图片是否正常?

先不要用 /btw,直接发:

这张图里有什么?

并附上同一张图片。

如果普通消息能识图,说明:

  • Discord attachment 下载正常;
  • adapter 缓存正常;
  • 视觉模型或 vision enrichment 基本正常。

那问题更可能在 /background 命令路径。

2. 日志里是否显示图片被缓存?

如果 gateway 日志里能看到图片缓存路径或 media URL,但后台 Agent 回复仍然完全没有图片信息,说明图片卡在 event 层,没有进入后台 Agent。

3. 后台 Agent 的 prompt 是否只有文字?

如果能打开 debug 日志,重点看 background task 最终传给 agent 的 user_message 是否只剩命令参数文字。

典型错误就是:

Which one should I buy?

而不是包含图片描述或附件上下文的 enriched prompt。


对用户的临时规避方案

在修复版本发布前,可以用这些办法绕过:

方案一:不要用 /btw,直接发普通图文消息

如果你需要 Agent 立即看图,先走普通消息路径:

帮我比较这两张图,哪个更适合购买?

附图发送,不要加 /btw

方案二:先让 Agent 总结图片,再把总结交给后台任务

例如先问:

请描述这两张图的关键信息。

拿到图片描述后,再用 /btw 处理更长任务。

方案三:升级到包含 PR #25603 修复的版本

如果你的 Hermes 版本已经包含相关修复,/btw / /background 应该能把图片上下文传给后台 Agent。


DeepAI API 中转站相关边界

如果你的 Hermes 使用 DeepAI API 中转站,链路通常是:

Discord → Hermes Gateway → background agent → DeepAI / OpenAI-compatible API

#25614 的问题发生在:

Hermes Gateway → background agent

也就是请求到达模型 API 之前。

所以如果 /btw 带图没效果,不能第一时间怪 DeepAI 或模型:

  • adapter 已经缓存图片;
  • 但 background task 没收到 media_urls / media_types
  • API 端自然也收不到图片上下文。

DeepAI API 中转站可以作为稳定的 OpenAI-compatible 后端,例如:

https://api.deepai.wang/v1

但前提是 Hermes Gateway 先把图像上下文正确传给 Agent,再由 Agent 组织请求。


FAQ

为什么普通图文消息能看图,/btw 不行?

因为普通消息路径会处理 event.media_urls / event.media_types,而旧的 /btw / /background 路径只提取了命令文字参数,没有把图片字段传给后台任务。

图片是不是没有从 Discord 下载下来?

不一定。这个 issue 的关键是图片已经被 adapter 缓存,但没有继续转发给 background agent。

/btw/background 都受影响吗?

是的。issue 明确说明 /btw/background 的 alias,两者同属后台任务命令路径。

这个问题只影响 Discord 吗?

复现平台是 Discord,但如果其他平台也复用同一个 background command 处理逻辑,也可能出现类似附件丢失。

修复思路是什么?

event.media_urlsevent.media_types 传给 _run_background_task,并在后台任务里复用 _enrich_message_with_vision()

DeepAI 能解决这个问题吗?

不能直接解决。这是 Hermes Gateway 内部附件传递问题,不是模型 API 问题。只有当图片上下文传到 Agent 后,DeepAI/OpenAI-compatible 后端才有机会处理视觉内容。


总结

#25614 的核心不是“Discord 图片没上传成功”,也不是“视觉模型看不懂”。

真正的问题是:

/background 命令路径只传文字 prompt,丢掉了 event.media_urls / event.media_types。

所以后台 Agent 收到的不是“文字 + 图片”,而只有一行文字。

对 Gateway 类型项目来说,这个问题很有代表性:

同一个用户消息,在普通路径能正常处理,不代表命令路径也保留了完整上下文。

附件、图片、语音、引用、thread metadata,都要在每条分发路径里显式传递,否则就会出现“前端收到了,Agent 没看到”的断链问题。

Related Post

飞书审批按钮报 200340?Hermes Agent 远程执行卡片回调的配置排查指南飞书审批按钮报 200340?Hermes Agent 远程执行卡片回调的配置排查指南

Hermes Agent 接入飞书 / Lark 后,危险命令审批卡片点击 Allow Once、Session、Always、Deny 报 200340?这通常不是模型 API 问题,而是 Feishu card.action.trigger、Interactive Card 与 Card Request URL 没配置完整。本文给出远程审批回调链路排查清单。

Hermes agent deepai gpt5 custom endpoint api mode codex responses.png

Hermes Agent 接入 DeepAI API 中转站:gpt-5 自定义端点被强制走 codex_responses 怎么排查Hermes Agent 接入 DeepAI API 中转站:gpt-5 自定义端点被强制走 codex_responses 怎么排查

Hermes Agent 使用自定义 OpenAI-compatible 端点接入 API 中转站时,如果模型名以 gpt-5 开头,即使显式设置 api_mode=chat_completions,也可能被运行时强制切到 codex_responses,导致响应变慢或卡住。本文结合 Hermes Agent Issue #10473,整理 DeepAI API 中转站场景下的协议选择、模型命名和排查方法。

少了一个 api_mode,模型目录就串台:Hermes 自定义 Provider 为什么把 Anthropic 当 OpenAI 校验少了一个 api_mode,模型目录就串台:Hermes 自定义 Provider 为什么把 Anthropic 当 OpenAI 校验

Hermes 自定义 provider 明明配置了 api_mode: anthropic_messages,/model 校验却丢掉 api_mode,导致按 OpenAI catalog 探测并提示 gpt-5-pro 等相似模型。本文复盘 #9146:为什么协议模式必须贯穿 validate_requested_model、probe_api_models 与 fetch_api_models。