deepseek-harness 进阶：给纯文本模型装上读图和画图的手眼
🛠️ 架构图（显眼入口）：DeepSeek Harness 视觉 + 生图 架构图
资金有限，先给模型装上"眼"和"手"
上篇文章里我体验了 deepseek-harness 的插件模式，做了一个贪吃蛇小游戏。这次想更进一步——解决一个更实际的问题：DeepSeek 的主模型是纯文本的，看不了图，也画不了图。
对于一个"什么都想试试"的开发者来说，多模态能力的缺失是个不小的遗憾。但正版的多模态模型价格不便宜，我这有限的资金只够装两个插件：一个负责"读图"，一个负责"画图"。这篇文章记录一下折腾的过程，以及一些关于插件生态的碎碎念。
读图插件：给模型装上"眼"
第一个要解决的是"看不见"的问题。思路是这样的——既然 DeepSeek 主模型是纯文本的，那就找一个会看图的多模态模型，把图片"翻译"成结构化文字，再喂给 DeepSeek。
视觉链路（读图）
├── DeepSeek-V4-Pro（纯文本模型）
│ └── 调用 modlens_read_image 插件
├── @liustack/modlens（dsh bundle 插件）
│ └── 通过 OpenAI 兼容协议，把图片发给 Kimi k3
├── Kimi k3（api.moonshot.cn/v1，多模态）
│ └── 返回结构化 JSON 证据
├── 结构化证据
│ ├── ocr.full_text —— 识别出的全文
│ ├── layout.regions —— 版面区域
│ └── semantics.entities —— 语义实体
└── 结果：纯文本 DeepSeek "看懂"了图片内容
这套链路实测通过——我拿一张带文字的测试图，Kimi 成功读出了图里的全文，DeepSeek 再基于这些文字做后续处理。相当于给纯文本模型外挂了一个"读图助手"。
画图插件：给模型装上"手"
第二个是"画不出"的问题。生图插件用的是阿里云百炼的 wanx 模型，DeepSeek 把文字描述传给插件，插件调用百炼的接口，生成 PNG 图片落到工作区。
生图链路（画图）
├── DeepSeek-V4-Pro
│ └── 调用 generate_image 工具（prompt / size / n）
├── @local/dsh-genimg（本次会话新写的原生插件，零第三方依赖）
│ └── 原生异步 API（非 OpenAI 兼容）
├── 百炼 DashScope · wanx2.1-t2i-turbo
│ └── image-synthesis 异步任务 + 轮询 + OSS 签名 URL
└── 结果：PNG 图片下载到工作区
这条链路也实测通过——wanx 大概 6 秒出一张图，399KB。速度和质量都在可接受范围内，关键是它让纯文本的 DeepSeek 也能"画图"了。
关于架构图：本想用生图模型，结果翻车了
做这个架构图的时候，我本来想"以毒攻毒"——用刚接好的生图插件直接生成一张架构图，多省事。于是我用千问的大模型试了一下。
结果……效果很差。生成的图里文字是乱的，架构关系也画不清楚，与其说是架构图，不如说是一团糊在一起的颜色块。我一度怀疑是不是模型选错了，或者 prompt 写得不够好，反复调了几次都不行。
最后放弃了"AI 生成架构图"这条路，老老实实手写了一个 HTML 架构图。反而发现手写的好处很多——文字清晰、布局可控、还能加上配色和动画。这个架构图就部署成了独立页面，你可以点开看：
👉 DeepSeek Harness 视觉 + 生图 架构图
这次翻车也让我想明白一件事：生图模型擅长的是"画"（渲染视觉），不擅长"排版"（组织信息）。架构图这种信息密集、逻辑性强的图，恰恰是文字排版占主导，生图模型反而处理不好。术业有专攻，该手写的还是得手写。
"一切皆插件"的理念，越想越有意思
用到现在，我对 deepseek-harness "一切皆插件"的理念越来越认同。纯文本模型本身有边界，但通过插件，你可以给它装上任何想要的"手"和"眼"——读图、画图、搜索、调 API、操作文件，理论上没有上限。
但转念一想，又忍不住琢磨：这会不会是梁文锋（DeepSeek 创始人）的"阳谋"？把 harness 做成一个开放的插件平台，让用户自己动手开发插件、补齐功能、打造一款"用户自己喜欢的产品"。DeepSeek 官方只提供最核心的模型和插件框架，剩下的交给社区和用户自己长出来。
这种模式有点像 App Store——平台方搭好地基，开发者百花齐放。对用户来说，你想要的任何能力，要么已经有人做了插件，要么自己写一个也不难。对一个技术追求者来说，这确实是一种很迷人的产品哲学。
当然，这纯粹是我个人的猜测。也许官方就是单纯想做个好用的 Agent 框架，没想那么多。但不管怎样，"一切皆插件"带来的自由度和可扩展性，是实打实的。
最后，吐槽一下今天的模型 API 涨价
写到这里，本来心情还不错，结果打开用量面板看了一眼，瞬间就破防了。
模型的 API 价格今天涨了，而且不是小涨——价格翻了好几倍。看着用量统计和总消费金额，心里五味杂陈：
我的模型用量和总消费金额截图
对个人开发者来说，API 涨价的影响是直接的。本来就精打细算地控制 token 消耗，这一涨价，很多原本"随便试试"的玩法都得三思了。工具虽好，但每一分钱都是真金白银，涨价这件事，真的挺让人伤心的。
不过伤心归伤心，该用还是得用。只能希望这些钱花得值——做出的东西、学到的知识，能对得起这个成本。
说明：文中提到的模型名称、插件版本、价格等信息基于我个人当时的使用情况，仅供参考。