像素画三阶段架构识图、绘图、验图解耦

日本語 →

像素画工具从点击到完成要 100 秒，太慢了。写了个耗时分析脚本，发现瓶颈在单代理架构——一个模型既要看图又要画画还要验证。拆成三个阶段后，47.8 秒完成，快了 52%。

上次改完调色板和画廊，像素画工具能用了，但有一个明显的问题：从点击「开始绘制」到作品完成，要等 100 秒左右。对于一个实时展示 AI 绘画过程的工具来说，这个等待时间太长。

瓶颈在哪里？凭感觉猜不如跑数据。我写了一个耗时分析脚本，模拟整个绘画流程，给每个环节精确计时。脚本直接调用 LLM API，复刻服务端的核心逻辑，不经过 WebSocket，这样能排除网络和服务端处理的干扰，纯粹测量 LLM 本身的响应速度。

跑完之后数据很清楚：单代理架构下，一个模型要同时承担三项职责——看图理解、逐格绘画、结果验证。看图需要多模态能力，绘画需要精确的 tool call，验证又需要多模态能力。把这三件事塞进一个模型的同一次对话里，每轮都要带上之前所有 tool call 的历史记录，消息体积从 2KB 膨胀到 18KB。轮次越多，每轮越慢。

解决方案是拆开。三个阶段各用最适合的模型，互不干扰。

第一阶段识图，用 MiMo V2.5 看原图，用自然语言描述图像内容。描述包括主体是什么、在画布上的位置、用哪些颜色、光源方向、哪些特征必须保留。这个阶段只调用一次 LLM，不需要 tool call，也不需要推理——模型只需要看图说话。

第二阶段绘图，把蓝图文本发给模型，让它用 paint 和 fill_rect 工具逐格绘制。这个阶段不需要看原图，蓝图已经提供了足够的信息。绘图阶段用 MiMo V2.5，reasoning_effort 设为 low，让模型快速决策。每轮返回多个 tool call，尽量三五轮画完。

第三阶段验图，再次调用 MiMo V2.5，这次带两张图：原图和最终画布的 PNG。模型对比两者，返回一个 JSON：是否通过验证、评分 1-5、一句评价。这个阶段不需要推理，但要处理两张图片的视觉对比，耗时 19 秒，是三个阶段里最长的。验图的价值在于兜底——如果绘图阶段画偏了，至少能给出评分和原因，不至于静默失败。

三阶段架构的关键设计是：绘图阶段不带原图。单代理架构里，原图在第一轮后被替换为文本提示，但模型的上下文里仍然残留着图片的 token 占位。三阶段架构直接用蓝图文本替代原图，绘图模型从一开始就只有文本输入，上下文干净，每轮的消息体积小得多。

实测数据对比。单代理架构 100 秒，其中绘图阶段占了大部分——模型每轮要处理越来越长的消息历史，还要做推理。三阶段架构 47.8 秒：识图 12.9 秒，绘图 15.6 秒（14 步），验图 19.3 秒。快了 52%。成图质量没有退化——验图评分 4/5，模型评价「成功还原了卡通青蛙的突出大眼和简洁轮廓，与参考图和蓝图高度吻合」。

中间还踩了一个坑。一开始绘图阶段用的是 DeepSeek V4 Flash，想用它的高速推理能力。结果发现 dsv4 的 tool call 效率反而不如 MiMo——同样的任务，dsv4 要 36 步 7 轮，MiMo 只要 14 步 3 轮。dsv4 的 reasoning_effort 只支持 high 和 max，不能降到 low，每轮的推理开销比 MiMo 大得多。最终 MiMo 全程方案（识图 + 绘图 + 验图都用 MiMo V2.5）是最快的。

还有一个细节。dsv4 的多轮 tool call 有一个特殊要求：每轮 assistant 消息必须带回之前所有轮次的 reasoning_content，否则 API 直接返回 400。这个坑在调试时花了点时间，最终在消息序列里加上了 reasoning_content 字段解决。虽然最终没用 dsv4，但这个兼容性保留了下来，以后切换模型时不用再踩一次。

成本方面，三阶段比单代理多了一次识图调用，但绘图阶段的轮次从 10+ 轮降到 3 轮，每轮的消息体积也小得多。总 token 消耗基本持平，没有显著增加 API 费用。

三阶段架构还有一个额外好处：每个阶段可以独立优化。识图阶段可以换更强的视觉模型，绘图阶段可以尝试不同的 tool call 策略，验图阶段可以调整评分标准。三个阶段的 prompt 也是独立的，改一个不影响另外两个。验图阶段 19 秒的耗时是下一步优化的重点——可以尝试用更轻量的视觉模型，或者把验证做成异步，先返回结果再后台验证。

工具地址：AI 像素画

相关文章