vision-subagent

视觉子代理（Vision Sub-agent）

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

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

触发条件

• 主模型 read_image 报错拒读（如 deepseek-v4-flash 不声明图像输入）
• 需要查看某张图片的实际内容、核对图片质量、或基于图片内容做判断，但主模型看不了

原理

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 })

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

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

已验证候选（示例）：opencode-go/mimo-v2.5、kimi-coding/kimi-for-coding、kimi-coding/kimi-for-coding-highspeed（均 text+image，经济型）。

用法模板

用 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 原因 → 修改动作 → 重审结果"写进审查/核验记录，供追踪与验收。