维护者确认：PR #3368 Chat Completions 桥接默认开启 image_url

[MagicLizi]

PR #3368 把 Chat Completions 桥接层默认 capabilities 改为 fail-open 的 image_url，使所有不在硬编码白名单里的自定义供应商都会走图片格式转换。

这不是局部缺陷修复：默认能力面扩大后，不支持视觉的供应商也可能先收到图片再被拒绝。需要维护者确认：

• fail-open 是否是可接受的默认策略
• 能力拒绝 vs 内容无效的错误分类是否够严
• 是否应改为按供应商声明能力，而不是全局默认开启

确认方式：直接在 PR 上 Approve；需要修改请 Request Changes，作者改完后再 Approve 即放行。

---

关联 PR:#3368(作者 @Battleplus);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的技术架构调整,维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断

自定义 openai-chat 视觉模型需要一条可配置的图片能力通路，但不建议把 imageInput: 'image_url' 加入 Chat bridge 的全局默认能力；建议对 #3368 Request Changes。

Chat Completions 协议能够表达 image_url，并不等于每个兼容端点或该端点下的每个模型都支持视觉。当前仓库已经具备格式转换能力，也已有按模型显式声明能力的实现方向。真正缺少的是自定义 Codex 路由的能力接线，而不是让所有未知端点先接收图片、再依赖上游 4xx 和错误文案推断能力。

行动

1. 保留未知路由默认 fail-closed：不要修改 CHAT_BRIDGE_DEFAULT_CAPABILITIES 为全局 imageInput: 'image_url'。
2. 优先复用 fix(desktop): allow opted-in Chat bridge images #2698 的方向：仅当当前用户供应商、当前 Codex openai-chat 模型明确声明 supportsImageInput: true 时，合并 imageInput: 'image_url'；现有官方验证路由继续自动开启。
3. fix(codex-proxy): enable image_url by default in Chat Completions bridge #3368 对错误分类的改进可以保留，但建议拆成独立、聚焦的修复：严格区分模型能力拒绝与图片尺寸、格式、URL 等内容错误，并覆盖结构化错误、handler 包装及纯文本响应。
4. 合并能力方案前至少完成一个真实第三方视觉端点和一个纯文本端点的 smoke test；当前自动化测试证明了转换和分类代码路径，尚未证明真实上游行为。
5. 若维护者仍希望采用全局 fail-open，则必须先解决“上游确认拒绝后，历史回放仍重复发送图片”的恢复问题，并补充不会循环重试或持续阻塞会话的端到端验证；不应把它留作合并后的 follow-up。

代码依据

当前 main@25220b456fab17eac5acb6804405f6acd28712fb 中：

• packages/responses-chat-bridge/src/translate-request.ts

  • imagePart() 已把 Responses input_image 转换为 Chat Completions { type: 'image_url', image_url: { url, detail? } }；URL、data URL 与 detail 均有现成路径。
  • messageContent() 仅在 capabilities.imageInput === 'image_url' 时转换图片。
  • 对不具备该能力的路由，最新用户图片保持 fail-closed；历史回放中的不兼容图片则会被裁剪，以免持续阻塞后续文字轮次。
  • file_id 是供应商作用域资源，无法通用跨供应商转换，仍会明确拒绝。

• apps/desktop/src/main/maker-host/codex-proxy-host.ts

  • CHAT_BRIDGE_DEFAULT_CAPABILITIES 当前没有 imageInput。
  • chatBridgeCapabilitiesForRoute() 仅在 HTTPS 且命中已验证的官方 hostname/model 组合时加入 imageInput: 'image_url'，包括 Moonshot Kimi K3、火山方舟 Doubao Seed 1.6+ 和指定 DashScope Qwen 模型。
  • 非白名单自定义路由没有消费模型级 supportsImageInput，这才是视觉自定义网关被本地拒绝的直接缺口。

• packages/responses-chat-bridge/src/types.ts

  • 当前主干的 isUnsupportedResponsesImageErrorPayload() 只识别 bridge 自己产生的结构化 unsupported_feature 及 Codex 包装形态。
  • fix(codex-proxy): enable image_url by default in Chat Completions bridge #3368 扩展上游错误识别、排除图片内容无效错误，这部分有独立用户价值；但它不能把未知供应商的任意 4xx 文案变成可靠能力协议，因此不适合作为全局 fail-open 的唯一安全边界。

为什么当前恢复链路不足以支撑全局 fail-open

#1329 已修复图片失败后的恢复，但其桥接层保护依赖一个关键条件：当当前路由没有 imageInput 能力时，历史回放中的图片才会被视为不可转换并裁剪。

若 #3368 把 imageInput: 'image_url' 设为全局默认，纯文本上游即使已经返回能力拒绝，下一次请求中的历史图片在 bridge 看来仍然“可转换”，因而会继续作为 image_url 发往上游。#3368 的讨论也已明确承认这个剩余边界，需要额外的 session/provider 状态才能让后续回放停止带图。

因此，“上游拒绝后客户端可优雅恢复”目前只对当前附件重试路径有部分依据，尚不足以证明包含历史回放的会话能够稳定恢复。既然仓库已有不扩大默认能力面的模型级 opt-in 方案，没有必要先接受这一回归风险。

建议验收

1. 自定义 Codex + openai-chat + 当前模型显式 supportsImageInput: true：URL 与 data URL 图片都转换为 image_url 并到达真实上游。
2. 混合文字/图片的顺序与 detail 保持不变。
3. 同一供应商下视觉模型与纯文本模型能力互不污染。
4. 同名模型位于不同供应商时，仅采用当前 provider/model 的声明。
5. 未声明或显式为 false 的非白名单路由继续 fail-closed。
6. 现有 Moonshot、火山方舟与 DashScope 官方成功路径不回归。
7. file_id 图片继续明确拒绝。
8. 图片过大、格式损坏、无效 URL 等内容错误不触发剥图重试。
9. 明确的模型能力拒绝可以恢复，且历史回放不再重复发送已拒绝图片、不产生重试循环。
10. 至少对一个真实视觉端点和一个真实纯文本端点完成端到端验证。

相关记录

• fix(codex): complete Responses to Chat bridge capabilities #895：已合并 Responses → Chat 图片转换，并明确采用“显式能力开启、未知线路 fail-closed”的边界；证明缺少的不是转换实现，同时构成当前产品/架构先例。
• fix(desktop): allow opted-in Chat bridge images #2698：已实现自定义供应商中 Codex openai-chat 的按模型图片能力 opt-in，直接覆盖 openai-chat 桥接因硬编码白名单丢弃图片输入，第三方兼容网关一律无法传图 #2371、Chat Completions 协议模型发送图片失败：input_image 不被 Responses→Chat Completions 桥接支持 #3306 所反映的缺口；当前仍开放，待维护者确认并需要同步最新主干。
• 维护者确认：#2698 自定义供应商图片输入开关扩展 #2738：针对 fix(desktop): allow opted-in Chat bridge images #2698 的产品/UI 确认记录；已有研究结论支持模型级开关，并指出它比供应商级或全局开关更适合混合模型网关。
• fix(desktop): 修复 DeepSeek 图片失败后会话无法恢复 #1329：已合并图片失败后的历史裁剪与重试恢复；其恢复语义依赖未声明图片能力时的 fail-closed，不能直接为全局 fail-open 提供保障。