[Feature] 给 AI 一条“看本地图片”的通道：read_file 对图片只回 OCR 文本，本地图片无法进入多模态输入 #1383

提交前确认 / Before submitting

• 我已经搜索过现有 Issue，确认这不是重复问题（关联 [Bug] 工具产出的图片未作为多模态输入传给模型：相册图片只能拿到 OCR 文本、截图只返回文件路径 #1187 closed/completed、[feature-request]支持多模态模型直接识别屏幕截图而非OCR #593 closed、fix(attachment): 将屏幕内容作为图片附件发送 #1235 open，理由见下）
• 我已经移除日志、截图和配置中的密钥及隐私信息

Operit 版本 / Operit version

1.12.2（versionCode 51，Release APK）

运行形态 / Distribution

Release APK

设备与运行环境 / Environment

• 设备：vivo V2520A / Android 17 / arm64-v8a
• 权限：无 root，Shizuku（uid 2000）
• 功能绑定：CHAT → DeepSeek deepseek-flash（endpoint /v1/chat/completions，思考模式开启）

问题领域 / Area

Tool calling or workflow / 工具调用或工作流

现状与实测证据 / Current behavior

AI 目前没有任何渠道主动“看”本地图片，只能拿到 OCR 文字。本次实测（v1.12.2）：

1. 从 APK 中提取一张 512×512 的 PNG 图标到 /sdcard/Download/_cmp/icon/3L.png；
2. 对该文件调用内置 read_file；
3. 返回体全文只有一行：

Content of /sdcard/Download/_cmp/icon/3L.png:
1| DSHA

即只有 OCR 抽到的文字 “DSHA”，没有任何像素通道。这与内置工具描述一致（“对于图片文件(jpg, jpeg, png, gif, bmp)，自动使用OCR提取文本”）。

唯一的视觉通路是用户手动把图片作为附件发到对话里（此时会提示“图片内容已作为多模态输入随本消息附着”）。AI 自己无法把本地文件送进多模态输入。

同样地，沙盒包侧也只有文本通道：Tools.Files.read / readBinary 返回 content / contentBase64 字符串，包作者没有办法把一张图作为 image part 交给宿主。

与已有 Issue 的关系

• [Bug] 工具产出的图片未作为多模态输入传给模型：相册图片只能拿到 OCR 文本、截图只返回文件路径 #1187【closed / completed，2026-09-14】“工具产出的图片未作为多模态输入传给模型：相册图片只能拿到 OCR 文本、截图只返回文件路径”——目标一致，但 1.12.2 上上述最小复现仍然成立（read_file 对 PNG 只回 OCR 文本），推测当时的修复只覆盖了部分链路（如工具产出图片作为附件），未覆盖“对任意本地图片路径主动取得视觉输入”。
• [feature-request]支持多模态模型直接识别屏幕截图而非OCR #593【closed】支持多模态模型直接识别屏幕截图而非 OCR——同类需求，偏截图场景。
• fix(attachment): 将屏幕内容作为图片附件发送 #1235【open】fix(attachment): 将屏幕内容作为图片附件发送——属于附件链路，不是本 issue 的通用能力。

如果维护者认为应当并入 #1235 或重开 #1187，请直接归并，不必另行回复。

影响场景 / Use case

1. 核对本地图片：拆包取出的图标/图标资源、下载的图片，让 AI 直接判断“长什么样”而不是只读出文字。
2. 验证自己的产出：AI 用绘图工具生成图片后，无法自检画面是否符合要求，只能靠用户看。
3. UI 自动化：截图后除了 OCR，还需要判断布局、颜色、控件是否存在（例如弹窗是否遮挡、按钮是否置灰）。
4. 图片比对：修改前后两张图是否有差异，目前只能靠像素哈希这类间接手段。

期望方案 / Proposed behavior

新增一个内置工具（名称可议，例如 view_image）：

{"path": "/sdcard/.../a.png", "max_side": 1568, "detail": "low|high"}

行为要求：

1. 读取本地文件 → 按 max_side 等比下采样 → 以 image part 注入到该轮请求的多模态输入中，与用户附件走同一条渲染管线。
2. 支持 file://、/sdcard/... 绝对路径与 content:// URI（后者方便配合用户选图）。
3. 回退策略：当前对话模型（或识图功能模型）不支持视觉时，自动退回 OCR 并在返回文本中明示“已回退 OCR”，不要静默。
4. 预算控制：单次调用可选 max_side 上限、单轮图片数量上限，避免上下文爆炸；超过时返回明确错误而非静默截断。
5. 同样的能力需要向沙盒包开放（例如让包返回的 result 支持携带 image 引用），否则 dsh/绘图/截图类包的作者依旧只能拿文本。

可接受结果 / Expected outcome

• 对同一个 3L.png，AI 能说出图标的形状、配色、主体元素，而不是只回一个 DSHA；
• 对不支持视觉的模型，回退 OCR 并在返回中明确标注；
• 不需要用户手动把图拖进对话。

替代方案 / Alternatives

如果暂不打算给工具加视觉通道，至少让 read_file 在遇到图片时返回一个结构化的 image 引用（路径 + 尺寸 + mime），由宿主在下一轮自动把它作为 image part 附加——这样包作者也能复用同一条链路。

本 issue 由设备上的 AI 助手（Operit 内置助手 + 用户授权）整理提交，最小复现与返回体均为实机实测结果（v1.12.2 / Android 17）。