Hermes Web UI Version
v0.6.12
Hermes Agent Version
v0.16.0
Bug Description
在 Hermes Web UI 中,当用户从某个自定义 OpenAI 兼容服务商的下拉框里,选了一个 图片生成模型(如 agnes-image-2.1-flash)或 视频生成模型(如 agnes-video-v2.0),Web UI 会仍然把请求发到 /v1/chat/completions,而不是服务商提供的 /v1/images/generations 或 /v1/videos/generations。远端返回 404,前端显示为 NotFoundError: OpenAIException - {"detail":"Not Found"}。
更糟的是,服务端确实有专门的图片生成端点 POST /api/hermes/media/apikey-image-generate,但这个端点内部硬编码只读 custom_providers 里名为 fun-codex 的那一项 —— 其它任何自定义服务商(包括 Agnes AI、本地图片服务、网关转发的服务商)都用不了。
实际效果:对所有非 fun-codex 服务商,Web UI 完全没有可用的图片生成路径。
环境
hermes-web-ui v0.6.12(通过 npm 全局安装)
系统:Linux x86_64
使用模型:agnes
受影响文件:dist/server/index.js(服务端请求路由部分)
Steps to Reproduce
在 ~/.hermes/config.yaml 里加一个自定义 OpenAI 兼容服务商,base URL 同时暴露 /v1/chat/completions 和 /v1/images/generations,且有一个图片模型(例:agnes-image-2.1-flash)。
打开 Hermes Web UI,顶部下拉框选该服务商和该图片模型。
发送任意应出图的 prompt。
实际现象
请求被发到 chat completions 端点。
远端返回 404 Not Found(FastAPI 风格:{"detail":"Not Found"})。
前端报错:NotFoundError: OpenAIException - {"detail":"Not Found"}。
期望行为
当用户选的是图片模型(或服务端能识别为图片模型),Web UI 应该改调服务商的 /v1/images/generations,而不是 chat completions。
Expected Behavior
证据
- chat 路径是唯一的自动路由
在 dist/server/index.js 中,chat 发送路径只走这三个分支:
Os(I.baseUrl) → /v1/chat/completions
Jo(I.baseUrl) → /v1/messages(Anthropic 风格)
ka(I.baseUrl) → /v1/responses(codex_responses)
没有任何自动分支指向 /v1/images/generations。images/generations 这个字符串只出现在 apikey-image-generate 那个 handler 内部的 e3I 函数里,而那个 handler 在 Web UI 的聊天界面里是完全不可达的。
- 专门的图片端点硬编码 fun-codex
js
复制
// dist/server/index.js
var eII = "fun-codex";
async function KkI(I) { // 从 config.yaml 解析 fun-codex 服务商
let c = (Array.isArray(l.custom_providers) ? l.custom_providers : []).find(
d => String(d?.name || "").trim() === eII
);
...
}
如果 fun-codex 缺失,handler 直接 401:
js
复制
if (!G) {
I.status = 401;
I.body = { error: Missing fun-codex provider in profile "${l}" config.yaml., code: "missing_fun_codex_provider" };
return;
}
也就是说:任何不是 fun-codex 的自定义 OpenAI 兼容图片服务商,Web UI 都用不了。
建议修复(任选其一即可)
泛化图片端点:让它从用户实际选中的模型配置(config.yaml 里的 model.provider / model.base_url / model.api_key)读取,而不是硬编码 fun-codex。
按模型名自动路由:当选的模型名包含已知图片前缀(如 image、-dall-e- 等)时,自动切到图片端点。
加 UI 入口:让 apikey-image-generate 接收任意 provider / base_url / api_key 参数,这样用户不用把自己的服务商起个别名叫 fun-codex 也能用。
Actual Behavior
对非 fun-codex 服务商该功能完全不可用,但 chat 本身不受影响。当前文档也没有提及 fun-codex 这个限制
Logs / Error Messages
Environment
Linux
Node Version
No response
Additional Context
No response
Hermes Web UI Version
v0.6.12
Hermes Agent Version
v0.16.0
Bug Description
在 Hermes Web UI 中,当用户从某个自定义 OpenAI 兼容服务商的下拉框里,选了一个 图片生成模型(如 agnes-image-2.1-flash)或 视频生成模型(如 agnes-video-v2.0),Web UI 会仍然把请求发到 /v1/chat/completions,而不是服务商提供的 /v1/images/generations 或 /v1/videos/generations。远端返回 404,前端显示为 NotFoundError: OpenAIException - {"detail":"Not Found"}。
更糟的是,服务端确实有专门的图片生成端点 POST /api/hermes/media/apikey-image-generate,但这个端点内部硬编码只读 custom_providers 里名为 fun-codex 的那一项 —— 其它任何自定义服务商(包括 Agnes AI、本地图片服务、网关转发的服务商)都用不了。
实际效果:对所有非 fun-codex 服务商,Web UI 完全没有可用的图片生成路径。
环境
hermes-web-ui v0.6.12(通过 npm 全局安装)
系统:Linux x86_64
使用模型:agnes
受影响文件:dist/server/index.js(服务端请求路由部分)
Steps to Reproduce
在 ~/.hermes/config.yaml 里加一个自定义 OpenAI 兼容服务商,base URL 同时暴露 /v1/chat/completions 和 /v1/images/generations,且有一个图片模型(例:agnes-image-2.1-flash)。
打开 Hermes Web UI,顶部下拉框选该服务商和该图片模型。
发送任意应出图的 prompt。
实际现象
请求被发到 chat completions 端点。
远端返回 404 Not Found(FastAPI 风格:{"detail":"Not Found"})。
前端报错:NotFoundError: OpenAIException - {"detail":"Not Found"}。
期望行为
当用户选的是图片模型(或服务端能识别为图片模型),Web UI 应该改调服务商的 /v1/images/generations,而不是 chat completions。
Expected Behavior
证据
在 dist/server/index.js 中,chat 发送路径只走这三个分支:
Os(I.baseUrl) → /v1/chat/completions
Jo(I.baseUrl) → /v1/messages(Anthropic 风格)
ka(I.baseUrl) → /v1/responses(codex_responses)
没有任何自动分支指向 /v1/images/generations。images/generations 这个字符串只出现在 apikey-image-generate 那个 handler 内部的 e3I 函数里,而那个 handler 在 Web UI 的聊天界面里是完全不可达的。
js
复制
// dist/server/index.js
var eII = "fun-codex";
async function KkI(I) { // 从 config.yaml 解析 fun-codex 服务商
let c = (Array.isArray(l.custom_providers) ? l.custom_providers : []).find(
d => String(d?.name || "").trim() === eII
);
...
}
如果 fun-codex 缺失,handler 直接 401:
js
复制
if (!G) {
I.status = 401;
I.body = { error:
Missing fun-codex provider in profile "${l}" config.yaml., code: "missing_fun_codex_provider" };return;
}
也就是说:任何不是 fun-codex 的自定义 OpenAI 兼容图片服务商,Web UI 都用不了。
建议修复(任选其一即可)
泛化图片端点:让它从用户实际选中的模型配置(config.yaml 里的 model.provider / model.base_url / model.api_key)读取,而不是硬编码 fun-codex。
按模型名自动路由:当选的模型名包含已知图片前缀(如 image、-dall-e- 等)时,自动切到图片端点。
加 UI 入口:让 apikey-image-generate 接收任意 provider / base_url / api_key 参数,这样用户不用把自己的服务商起个别名叫 fun-codex 也能用。
Actual Behavior
对非 fun-codex 服务商该功能完全不可用,但 chat 本身不受影响。当前文档也没有提及 fun-codex 这个限制
Logs / Error Messages
Environment
Linux
Node Version
No response
Additional Context
No response