视觉子代理（Vision Sub-agent）

当主模型不支持图像输入（read_image 会拒读，如纯文本模型）时，用 workflow 派生一个指定视觉模型的子代理来"看"图——它可以用 read_image 读取图片，再根据你的要求描述内容或审查质量并返回结论。

本 skill 是全局可用的看图方案，任何预设/会话/项目都可加载，不限定业务场景。

触发条件（先判断，再决定用不用本 skill）

先试一下：直接调 read_image，或查 llm.resolveModelInfo(provider, model) 的 inputModalities。

• ✅ 主模型支持图像（inputModalities 含 image）→ 直接 read_image 读图即可，不必派子代理（更快、少一层）。注意能力靠配置声明——若报 does not declare image input，先按本文末"图像能力靠配置声明"排查，可能只是配置漏声明。
• ❌ 主模型不支持图像（read_image 拒读）→ 用本 skill 派生视觉子代理来看图。
• 🔀 仍值得用子代理的两种情形：① 想要独立/隔离的看图结论（不让主模型既产出又自查）；② 想用更便宜的视觉模型替代主模型读图。

原理

DeepSeek Harness 的 workflow 工具允许在 agent() 上独立指定 provider 与 model。只要选一个当前部署里真正支持图像输入的模型（其 inputModalities 含 image），派生的子代理就能用 read_image 读取并处理图片。

不同部署注册的视觉模型名可能不同，不要硬编码模型名，应先探测。

如何找可用的视觉模型

用 llm 服务遍历各 provider 的模型，过滤出 inputModalities 含 image 的：

// 思路：遍历 provider -> resolveModelInfo -> 过滤 inputModalities 含 'image'，得到 { provider, model }
const vision = /* inputModalities 含 'image' 的 {provider, model} */
await agent(prompt, { provider: vision.provider, model: vision.model })

成本优先（重要）：识图/看图是高频、轻量任务，优先选择便宜的经济型视觉模型，不要使用贵的大模型。具体原则：

• 首选：deepseek-official/deepseek-flash（DeepSeek V4.1 Flash，官方"快·高效·经济"定位，text+image）、kimi-coding/kimi-for-coding（K2.7 Code）、kimi-coding/kimi-for-coding-highspeed 等经济型视觉模型。
• 避免：kimi-coding/k3、k3-256k 这类旗舰/大上下文模型——识图不需要它们的强推理与长上下文，成本不划算。除非便宜模型全部不可用且任务确需更强能力，才考虑它们。
• 换部署后先探测：按"便宜视觉模型优先 → 经济型 → 旗舰兜底"的顺序选。
• 同一批图片审查应尽量一次性派发（一次 workflow 调用审多张），减少调用次数与成本。

已验证候选（示例）：deepseek-official/deepseek-flash、kimi-coding/kimi-for-coding、kimi-coding/kimi-for-coding-highspeed（均 text+image，经济型）。

⚠️ 图像能力靠配置声明：模型的 inputModalities 在配置里默认是 ["text"]。若某模型实际支持读图却被拒（read_image 报 "does not declare image input"），检查其配置是否声明了 image（DSH 的 dsh-llm-deepseek 等适配器本身支持图像，声明后即可读图）。

用法模板

用 workflow 派发看图子代理（provider/model 替换为探测到的可用视觉模型）：

await agent(
  '用 read_image 工具读取 <图片绝对路径>，然后完成任务：<你的具体诉求，如描述内容 / 审查质量 / 判断是否达标>，并结构化返回结论。',
  { provider: '<探测到的provider>', model: '<探测到的视觉 model>' }  // 指定视觉模型
)

把"任务诉求"填进 prompt，子代理会先看图，再按你的要求输出。例如：描述图里有什么、检查是否有空白/遮挡/文字重叠、核验图与某条结论是否一致等。

输出约定（建议）

按需要求子代理给出结构化结果，例如：

• 内容描述：图中关键元素、布局、文字/标题等
• 质量核验：是否空白、模糊、遮挡/重叠、要素缺失
• 目标核对：图是否支撑它要支撑的结论或任务
• 判定：PASS / FAIL，FAIL 时给原因与改进建议

复验闭环（FAIL → 修改 → 重审，强制）

图片核验不通过后，必须进入"修改-重审"循环，直到 PASS，才算完成。 不得"审一次出个 FAIL 就当作已核验"。

规则：

1. FAIL 即回退修改：子代理返回 FAIL 时，按它给出的缺陷与改进建议，把图片退回给制作/修改图片的一方进行修改。
2. 修改后必须重审：每次修改后，重新派发识图子代理对修改后的图完整复审一遍，不能只让修改方自称"改好了"。
3. 循环直至 PASS：复审 FAIL 则继续"修改 → 重审"，直到 PASS 为止；每次重审都记录结论（哪一版图、审了什么、结果）。
4. 有界兜底（可选）：可约定最大重审轮次（如 ≤3 轮）；超限仍不 PASS 时，如实标记"多次修改未通过核验，存在持续缺陷"，不得降级成"视为通过"。
5. 记录留痕：把每次"FAIL 原因 → 修改动作 → 重审结果"写进审查/核验记录，供追踪与验收。

示例：某项目的一张图初检通过（非空、有内容），但在与文字结论的一致性核查中发现坐标/内容被裁剪造成误导（图上表现与结论相反）→ 判定 FAIL → 修改后重审 → PASS。这类问题纯文本主模型发现不了，必须靠复验闭环兜住。

兜底

• 若探测不到任何 inputModalities 含 image 的模型，如实标记"此环境无视觉模型，看图受限"，不要假装通过。
• 主模型若是纯文本模型，直接 read_image 报错属预期行为；此时用本方案派生视觉子代理即可。
• 本 skill 只负责"让图能被看/被审"。若还需要用与主模型不同厂商的模型做内容/推理审查，那是另一个维度（独立模型审查），可与本方案组合使用。