OpenCode Senses

一句话定位

给纯文本模型的编码 agent 装一双眼睛：本地跑一个小视觉模型，把截图转成结构化文字 注入提示词，让没有多模态能力的便宜模型也能"看图、读字、定位元素"。

做这个东西的人

itsmeadarsh2008 的个人开源项目，MIT 许可，npm 已发布（opencode-senses），v0.1.3。 服务对象是 OpenCode——SST 团队的开源终端编码 agent（GitHub 165k+ star），支持 75+ 模型商， 包括纯文本模型。2026-07-19 建仓，38 个提交。

判断：作者选择的切口很准——OpenCode 支持用便宜/纯文本模型跑编码 agent， "给文本模型补视觉"正好卡在这条路线的痛点上。作者背景未披露。

它到底能做哪几件事

• 13 个视觉工具 → OCR（可分 all/code/error 三种提取）、目标检测、区域定位、分割、裁剪、 放大、颜色分析、图像对比、标注、元数据、反向图像搜索、状态检查
• 自动注入 → 你给 agent 附加一张图，插件自动分析（结构化场景读取 + 标题 + 精确 OCR）， 把结果以 <SENSES> 文本块注入模型提示词——模型不需要调用任何工具就能"看到"
• 本地推理 → 默认 Moondream 2（峰值约 4.5GB 显存，适配 6GB 卡），可选 Moondream 3.1 (9B)； 模型权重约 3.9GB，首次调用慢，热缓存后典型响应低于 1 秒
• 注入防护 → 图片内容一律包在"不可信数据"守卫里，截图里写的"忽略之前的指令"会被当数据 而不是指令
• 隐私 → 图像和分析不出本机，无 API key，免费

它明确不做：不做多模态模型替代品，不做云端服务，不做通用视觉问答——只做 "把视觉事实抽成文本证据"这一件事。

它在替代什么旧行为

• 为看图而换多模态模型 → 以前纯文本模型看不了图，想看就得切换到付费的多模态 API； Senses 让本地小模型抽 OCR/坐标/颜色，纯文本模型照常用
• 手动抄错误信息 → 报错截图以前要靠人把文字敲进对话；senses_ocr(kind="error") 直接提取纯净错误文本
• 描述图片靠人 → 给 agent 传设计稿/截图，以前要么人能说清楚、要么模型猜； 现在先 OCR 再描述，模型拿到的是事实不是猜测

它把"视觉能力"从模型侧移到了工具侧——能力不升级模型，升级的是给模型喂的事实。

商业模式

未披露/免费。 MIT 开源、npm 分发、无付费层、无 API 收费，成本是用户自己的 GPU。

判断：这是插件生态里典型的"分发换生态"打法——不直接赚钱，赌 OpenCode 生态起来后 自己成为视觉层的默认选项。这类项目的问题是：平台自己推出官方视觉支持，插件价值立即归零。

硬数字

• 26 star / 0 fork / 0 open issue（2026-08-14 抓取），v0.1.3，38 个提交，2026-07-19 建仓
• Moondream 2 峰值显存约 4.5GB；权重约 3.9GB；热缓存响应低于 1 秒
• 13 个工具；MIT；npm 已发布
• HN：8 分、2 评论
• 使用量、下载量：未披露

四维评估

判断

机制值得关注，产品验证不足。 "结构化感知 + 文本注入"是对纯文本/低成本模型补能力的最省方式——不换模型、不付 API 费、 可本地跑。对做 agent 产品的人，这条"把外部事实先抽成结构化文本再喂给模型"的管线 比强上多模态更省钱、更可控。

它最有价值的设计是注入防护。 把截图内容当作不可信数据包裹，防止提示注入—— 这是多数视觉 agent 完全没做的一层，而它恰恰是截图场景里最容易被攻击的地方。

天花板：Moondream 2 级别的模型能力有限，复杂 UI 理解会到顶；而 26 星、0 fork 说明 它还没建立起任何生态位。OpenCode 官方一旦自带视觉，它就是第一个被替换的。

下一步看什么

① 是否被 OpenCode 官方收录到插件推荐，star 是否过百 ② 热缓存 sub-second 在真实项目（如截图转前端）中是否成立 ③ 有没有第三方基于它构建"视觉 agent"工作流（被依赖的指标）

可借鉴的做法

产品逻辑：给纯文本/低成本模型补能力，优先考虑"本地小模型抽结构化事实（OCR、bbox、 颜色）再以文本注入"，而不是强上多模态。注入内容一律用"不可信数据"守卫包裹，防提示注入。 这条对做 agent 产品的人直接可用。

定价结构：无。免费开源。

结论

有待观察。 机制可迁移，产品验证不足。三个月后拿上面三条回头验证。