【Core 实现】纯文本主模型贴图不再被拒：工作区镜像 + vision bridge + 信任边界修复

[gloryxpnv]

TL;DR

我在 gloryxpnv/deepseek-harness fork 的 feat/image-upload-vision-bridge 分支上实现了两个 core 层改动，正好对应社区反复提出的两个诉求：

1. 纯文本模型（如 deepseek-v4-flash）贴图不再被 MODEL_DOES_NOT_SUPPORT_IMAGES 拒绝——图片先镜像进工作区，可选的 vision-bridge 插件把图片转成文字描述，主模型只看到文本（对应 【建议】纯文本模型收到图片时提供“落盘+文字标记”回退，便于子 Agent / 视觉脚本接管 #2005、Idea: 纯文本模型贴图不再被拒——受理时转本地路径交给视觉技能 / accept pasted images with text-only models (fix ready on fork) #427、Feature request: image attachments with a text-only main model via a separate vision model (MCP vision-helper) #588、Proposal: allow image uploads in GUI when the main model is text-only but vision tools are installed #357、[Idea] 图片上传被模型目录能力硬性拦截：主模型无视觉模态时也应允许附件（以链接/路径交给工具处理，类似 opencode 做法） #1378 的提案）
2. 修复信任边界 403——Chrome/Edge 扩展场景下 Origin 省略非默认端口导致所有 POST 返回 403（对应 Web UI: every POST to /api/* returns 403 Forbidden (trust fence Origin/Host port mismatch) #2009）

改动 1：图片上传 + vision bridge（文本模型看图）

现状问题：当会话模型 inputModalities 不含 image 时，dsh-host-apiproxy 的准入层直接拒绝整条消息，图片不落盘，视觉工具/子 Agent 完全拿不到图。社区目前靠第三方插件绕路（dsh-plugin-multimodal、pi2dsh、dsh-image-subagent），但正如 #2005 所说，这应该是官方 core 层的策略。

我的实现（改 core，不是插件补丁）：

上传图片
  → ① 镜像进会话工作区（原始字节永远可及，best-effort，失败不阻塞受理）
  → ② 若模型是纯文本：查 ctx.get('vision-bridge')
       ├─ 有桥 → 本地 VLM 描述图片 → 文本+图片块投递（后台串行，UI 不卡顿）
       └─ 无桥 → 文本兜底：「图片已落盘，可用 vision 工具读取」（store-and-annotate）
  → ③ DeepSeek 序列化层丢弃图片块、保留兄弟文本描述（不再 UNSUPPORTED_CONTENT）

关键设计：

• 镜像先于桥接：原始图片永远先落盘，桥失败也不丢图
• vision-bridge 是插件接口：官方 core 不内置任何 VLM，由插件（如 dsh-tool-vision）提供描述能力——符合官方"本地优先、零 API 成本"的方向
• 后台投递：VLM 描述可能耗时数十秒，先立即受理（accepted），描述完成后串行投递，页面不冻结
• 落盘 + 文字标记回退：正是 【建议】纯文本模型收到图片时提供“落盘+文字标记”回退，便于子 Agent / 视觉脚本接管 #2005 建议的 imageFallback: store-and-annotate 模式

改动 2：信任边界修复（#2009）

Chrome 扩展控制的回环标签页可能发送 Origin: http://127.0.0.1（无端口）而 Host: 127.0.0.1:3080（带端口），api-request-trust.ts 中 originUrl.host === hostUrl.host 无法匹配 → 所有 POST 403。

修复：仅对 loopback Host + 精确同 hostname + sec-fetch-site: same-origin 放行省略端口的 Origin；不放宽到非回环权威、别名或跨站请求——保持 DNS-rebinding 防御完整。

测试

• api-request-trust.host.spec.ts：11 passed（含新增兼容用例）
• api-proxy-upload-mirror.spec.ts：9 passed（新增，351 行，覆盖镜像/净化/去重/桥接/回退）
• serialize.spec.ts：28 passed
• apiproxy + ui-conversation 全量：799 passed
• typecheck（host + contracts-ready）绿

获取

git fetch https://github.com/gloryxpnv/deepseek-harness.git feat/image-upload-vision-bridge
git checkout feat/image-upload-vision-bridge

由于仓库关闭了 PR，先在这里展示实现，希望与官方和社区交流：

• 是否值得收进 core？（【建议】纯文本模型收到图片时提供“落盘+文字标记”回退，便于子 Agent / 视觉脚本接管 #2005、[Idea] 图片上传被模型目录能力硬性拦截：主模型无视觉模态时也应允许附件（以链接/路径交给工具处理，类似 opencode 做法） #1378 已有详细方案讨论）
• vision-bridge 接口设计是否合适？
• 镜像/桥接/回退的默认行为是否符合预期？

（我的 vision 插件 dsh-tool-vision 可作为 bridge 实现配合使用：https://github.com/gloryxpnv/dsh-tool-vision）

[Electricitysheep]

core 层实现贴图（工作区镜像 + vision bridge + 信任边界）——社区一直在讨论区提（#1378/#1327 都是），终于有 core 实现落地了。

视觉桥家族从插件（#1153/#1269）进化到 core 层，生态正循环的信号。已收录进手册生态章节：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/07-ecosystem.md

[gloryxpnv]

感谢

[Electricitysheep]

不客气，core 实现很扎实，期待后续。

[gloryxpnv]

更新（2026-08-16）：分支已 rebase 到官方最新 rc.8（141eb6f）

官方 master 在 rc.5 → rc.8 期间推进了 647 个 commit（含 feat(llm-deepseek): support multimodal requests、feat(attachment): add ordered image batch admission 等图片相关改动），我把两个 commit 手工 rebase 并合并冲突后推到了 fork：

• master → 与官方 rc.8 完全同步（141eb6f）
• feat/image-upload-vision-bridge → rc.8 + 2 commits（e4c782b + b3aa116），ahead 2

rebase 中处理的情况：

1. 信任边界修复（commit 1）：官方 rc.8 依然没有修 Chrome/Edge 扩展场景的 Origin 省略端口问题（api-request-trust.ts 0 次改动），补丁干净应用、无冲突。
2. vision bridge + 工作区镜像（commit 2）：官方 rc.8 实现了多模态 data-URL 直发（给支持图片的模型用），但纯文本模型场景的 MODEL_DOES_NOT_SUPPORT_IMAGES 拒绝逻辑原封不动——vision bridge 逃生通道在官方代码里依然不存在，属纯增量。3 个冲突文件（serialize.ts / api-proxy.ts / InputBar.tsx）已手工合并：
   • 保留你的镜像 + bridge 逻辑
   • 融合官方新增的 admitEncodedImages（attachment 批量受理）与 serializeImageAdmission（受理串行化）
   • 测试 stub 补齐官方 rc.8 新增的 saveImages 接口
3. 测试验证：apiproxy + serialize + trust 相关 441 个测试全绿；你的文件类型检查通过（typecheck 全量报错均来自官方 rc.8 自带的 agent-team / pwsh 模块，与本次改动无关）。

结论不变：官方 rc.8 的多模态支持解决"有眼睛的模型"，本实现解决"纯文本模型 + 社区视觉工具"——两者互补，vision bridge 依然是社区提案（#2005 store-and-annotate / #1378 host 层降级）的官方层落地。

获取方式更新：

git fetch https://github.com/gloryxpnv/deepseek-harness.git feat/image-upload-vision-bridge
git checkout feat/image-upload-vision-bridge

[wuyak]

补充一份独立的 rc.8 验证，聚焦本帖的信任边界修复部分：

• 本地已快进到官方 master / dsh-v0.1.0-rc.8：141eb6fef83422698aef7a981029e843e8161534；
• api-request-trust.ts、rpc-host.ts 与对应测试在 rc.8 中仍未修改，原始 .host === 精确端口比较依然存在；
• Chrome 实际 POST 请求捕获为 Host: 127.0.0.1:3080、Origin: http://127.0.0.1、Referer: http://127.0.0.1:3080/、Sec-Fetch-Site: same-origin；
• 影响范围是共享 /api 下的全部 HTTP RPC，不只是 host.pickDirectory。静态前端可以加载，但 host.describe、会话/工作区、设置、凭据与模型发现等都在分发前被 403。

本地采用了比“所有情况只比较 hostname”更窄的回环兼容分支：仅当 Host 为 loopback、Origin 同 hostname 且无端口、Fetch Metadata 为 same-origin，并且 Referer 精确绑定实际 Host 端口时放行。这样不会把非回环 trustedHosts 的精确端口语义一起放宽，也继续拒绝 Origin: null、跨站、错误 Referer 端口等形状。

在 rc.8 基线上重新执行：

• pnpm install --frozen-lockfile：通过；
• pnpm run build：通过；
• connection tests：10 files / 111 tests 通过；
• 使用上述真实请求头组合探测 /api/host.describe：修复后 HTTP 200。

因此你在分支更新里所说的“rc.8 仍未修复、补丁可干净应用”与独立检查一致。建议若继续维护 trust-only commit，可考虑加入 Referer 精确端口约束，作为比全局 hostname-only 更小的安全兼容面。主问题的最新复现证据也已同步到 #2009。