Avatar

本文讲述了 AI 绘图项目 Grimoire 从硬编码 Workflow、MCP 到 Skill 的技术演进与范式转变。

Grimoire 的演变历程：从 Bot 到 MCP 再到 Skill
1950 words
LLM/Agent

了解我的人都知道我是 AI 绘图的忠实拥趸，因为我经常厨到冷门角色。尽管 AI 绘图的风评褒贬不一，但量大管饱这一块确实无可质疑。

目前 AI 绘图主要有扩散模型和多模态大模型自回归两条路线。后者（例如 Nano Banana 和 GPT-Image-2）虽然具备更强的语义理解能力，但是它们通常难以微调风格、指令遵循比较迷惑，而且非常贵；扩散模型作为老资历，代表性的 Stable Diffusion 有非常多的变种，甚至还可以微调自己想要的画风，缺点就是必须使用 Danbooru 标签去描述画面，对自然语言的支持不太好。

扩散模型的这个问题就很麻烦。这让我想把脑海中的画面落实成图片时，还要先去标签网站上检索标签、再手动组织提示词。特别是在复杂图像中，往往需要几十上百个标签。

所以我就在想，为什么不能使用 AI 去替代这些重复劳动呢？于是就有了 Grimoire 的灵感。

1 Grimoire Bot：最初的绘图工作流

回想一下人工步骤：

  1. 先有一个想象中的画面

  2. 把这个画面拆解成画风、环境、视角、人物、表情、动作、细节等要素

  3. 去标签网站挨个查找 Tag

  4. 把 Tag 填到对话框中，完成绘图

如果把这些步骤翻译成工作流——

  • 把自然语言需求交给大模型

  • 大模型拆解画面，分析主体、风格、背景、构图要求

  • 大模型检索标签、构造并返回提示词

  • 工作流接收大模型构造好的提示词，调用模型生图

  • 返回图片

虽然这套工作流看起来确实解决了手动查标签的痛苦，但很快我就遇到了瓶颈：硬编码的工作流太死板了。

例如，我只是想微调一下提示词，就只能把原话发给它，重新查找标签、生成提示词。但第二次生成的提示词往往和第一次大相径庭，因为大模型是无状态的，它并不知道上一次的提示词是什么。

再比如，我只想让它帮我优化一下标签，而不急着生图；或者我想在中间加入一个“根据标签反查角色设定以防 OOC” 的步骤，我就必须去修改整个工作流的代码。这种线性工作流限制了大模型的动态推理能力，让 AI 沦为了一个传话筒。

像这样的意外情况还有很多。我甚至为此设计了一套数据库结构和状态机去应对各种边界情况。为了让一个无状态的 LLM 记住它刚刚画了什么，我不得不手动在数据库里去维护一堆 session_id、current_step、以及一长串历史 Tag 的上下文。

当我最后的精力也在这个过程中耗尽时，我就意识到该改变了。

2 Grimoire MCP：从固定工作流中解放

虽然 MCP 这个概念在 2024 年底就出现了，但当时我确实没意识到这会给 Grimoire 带来一些转机。直到 2026 年初，OpenClaw 和 Nanobot 等个人通用 Agent 的迅速走红，我才意识到这是对传统工作流模式的降维打击。

于是我将 Grimoire Bot 的核心功能重构为了 Grimoire MCP。这个 MCP 只负责一件事：接收提示词、发送到 NovelAI 生成图片、把图片发回来。然后我把这个 MCP 交给 Nanobot，它就会根据我的输入，自主决定何时该去查标签、何时该去构造提示词。

更重要的是，它完全解决了固定工作流中最严重的问题。我让它去把上一幅图的白天改为夜晚，它就会从记忆中读取对应的提示词、做一下微小的改动，而不是像固定工作流那样死板地执行任务。

而且 Grimoire MCP 还可以和其它 MCP 完成一些有趣的联动，例如 https://github.com/SuzumiyaAkizuki/DanbooruSearchOnline。这个 MCP 可以检索标准 Danbooru 标签，从此避免了模型瞎编不存在的标签。

到这里，似乎 MCP 已经足够完成任务了，但是我觉得还不够好。例如，每次我都要给模型强调如何构造提示词；例如，我需要在服务器上 24h 运行着一个 MCP Server。

这时候，一个更轻量的方案出现了。

3 Grimoire Skill：可能是最终解决方案

Skills 这个概念是 2025 年 10 月提出的，现在已经成为了各种 Agent 的首选。

Skills 可以理解为重复流程的封装。就比如，我每次绘图时，都要给 Agent 一遍又一遍地说“先去检索标签再画图，不要自己编标签”。而在有了 Skills 后，Agent 就能遵循规定好的流程、使用规定好的能力去画图。

这解决了 Grimoire 存在的第一个问题。

本质上，Skills 就是一系列 Markdown 文件和 Python/JavaScript/Bash 脚本的集合。当用不到它们的时候，Agent 只能拿到 Skills 的名称和描述。只有在需要用到某个 Skill 时，这个 Skill 才会动态加载进 Agent 的上下文中。这被称为渐进式披露。

最终，我把 Grimoire MCP 再次重构为了 Grimoire Skill。这个 Skill 只有三个文件：SKILL.md、generate_image.py 和 get_balance.py ，分别用来指导 Agent 使用、生图、查询余额。

当我让 Agent 去画一幅图时，Agent 先自主查询标签、构造提示词，然后在后台拉起 Python 运行时，将组装好的 Payload 喂给 NovelAI API，Agent 拿到图片后直接发给我。整个过程中没有任何长连接服务运行，招之即来，挥之即去。

Grimoire Skill 带来了两个巨大的工程优势。

其一是按需使用带来的资源节省。对于一个最简单的 MCP 来说，也要在后台常驻几十到几百 MB 的内存，而 Skill 的常驻内存占用是 0，因为它就是一堆文件。这对于我的 2G 内存的服务器来说简直是天上掉馅饼。

其二是极简的环境。得益于 uv 和 PEP 723 内联元数据规范，Skill 的外部依赖可以做到按需调用，不必为了给一个脚本配一个虚拟环境：

#!/usr/bin/env -S uv run
# /// script
# requires-python = ">=3.12"
# dependencies = [
#   "httpx>=0.28.1",
# ]
# ///

9 总结

Grimoire 的三次迭代本质上是控制权移交与工程复杂度收敛的过程：

| 阶段 | 核心逻辑 | 灵活性 | 资源开销 | 交互体验 | | Grimoire Bot | 线性工作流 | 极低，硬编码全部逻辑 | 高（24h 运行工作单一的 Bot） | 机械且死板，几乎无法处理边界 | | Grimoire MCP | Agent 工具集 | 高，大模型可自主决策 | 较高（24h 常驻 MCP Server） | 灵活，但仍需配置 MCP | | Grimoire Skill | Agent 说明手册 | 极高，大模型自主调用 | 极低（静态文件） | 丝滑，安装时下载文件、不再需要时直接删除 |

回头看 Grimoire 的这三轮迭代，其实就是整个大模型应用生态的缩影。

最开始，我们把 AI 当成传统软件看，试图用硬编码的** **Workflow 去驯服它，结果被它的随机性折磨。

后来 MCP 给了 AI 手和脚，让它能够自己去探索世界，但它过于沉重，挤占了本就不多的上下文和内存。

直到 Skill 出现，轻量、无感，成为 AI 抬手即来的肌肉记忆。