GEMS
lcqysl/GEMS加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
图1：GEMS项目Logo — 一颗由技能与记忆驱动的AI图像生成「宝石」
你用过 Midjourney、DALL·E 或者 Stable Diffusion 吗？你有没有遇到这种情况：prompt 写得特别详细，AI 生成的图却总是漏掉一两个关键元素——要么颜色不对，要么物体位置反了，要么文字渲染糊成一团。
这背后的根本原因是：现有的主流文生图模型大多采用「单次推理」模式，给定 prompt 直接输出图像，没有任何自我反思和迭代优化的能力。 面对复杂、多约束的图像需求，一次生成往往难以同时满足所有条件。
GEMS（Generative Experience Multimodal System）登场了。它是 2026 年由何泽峰（He Zefeng）等研究者提出的全新框架，核心思路是：给图像生成配上一个大语言模型 Agent，让 Agent 像一个专业设计师一样，理解需求 → 分解任务 → 迭代优化 → 记忆经验，最终生成高质量图像。
GEMS 的诞生背后是近两年 AI 领域一个明确趋势：从「让模型更强」转向「让模型更像人一样工作」。 传统图像生成模型像是一个只会一次出图的工具，而 GEMS 将其包裹在一个 Agent 框架中，使其拥有了：
项目基于 arXiv:2603.28088 论文，代码托管于 GitHub，目前已有 140+ Stars，被标记为 agent、generation、multimodal、reasoning 等 AI 前沿领域。
用户输入 prompt 后，GEMS 首先调用 Skill Router（技能路由器）判断是否需要激活专业技能。这一决策由一个 MLLM（多模态大语言模型）驱动，系统内置了四类可复用的技能（Skills）：
| 技能名称 | 触发条件 | 核心能力 |
|---|---|---|
| aesthetic_drawing | 用户要求「艺术」「大师级」「获奖作品」 | 融合8维美学评价体系，重写 prompt |
| creative_drawing | 用户要求「创意」「酷」「超现实」「梦幻」 | 6原则增强创造力和概念深度 |
| spatial | 涉及多物体布局、空间关系（左右、上下、遮挡等） | 10维空间推理体系精确定位 |
| text_rendering | prompt 包含引号文字、logo、标语等 | 6维度保障文字准确渲染 |
Skill 的加载和解析由 SkillManager 统一管理，通过正则表达式解析 SKILL.md 规范文件，架构上非常便于扩展——只需在 agent/skills/ 目录下新建子目录并编写符合规范的 SKILL.md 即可添加新技能。
无论是否触发技能，GEMS 都会将原始 prompt 交给 MLLM 分解为一系列可以用「是/否」回答的验证问题。
举例： 原始 prompt："一只黑猫坐在红色沙发上，背景是城市夜景"
分解后的验证问题：
这种「可验证问题」的设计是整个系统的关键——有了它，GEMS 才能在后续轮次中精确判断哪些条件满足了，哪些没满足。
这是 GEMS 最有技术含量的部分。默认最多 5 轮迭代，每轮包含：
Step A — 图像生成（generate）： 调用外部图像生成 API（支持 Qwen-Image-2512 或 Z-Image-Turbo），基于当前 prompt 生成图像。
Step B — 多维验证（verify_image）： 将生成的图像和之前分解出的验证问题全部提交给 MLLM（Kimi-K2.5），MLLM 以多图模式同时评估所有问题，给出「yes/no」判断。验证过程使用线程池并行（最多10个并发），提升效率。
Step C — 经验提取（Summarize Experience）： 如果有任何问题未通过，MLLM 被要求总结本轮经验：哪些成功了，哪些失败了，下一轮应该采取什么策略。摘要长度限制在 100 词以内，压缩为紧凑的经验记录。
Step D — Prompt 优化（Refine Prompt）： MLLM 结合完整的历史记录（包含之前生成的图像）和经验摘要，生成新的优化 prompt。新 prompt 必须：
如此往复，直到所有验证问题均通过，或达到最大迭代次数。
「最佳图像」追踪机制： 每一轮结束后，系统会记录已通过验证问题的数量，如果当前轮次通过数超过历史最佳，则更新最佳图像。最终返回的不是最后一轮的图像，而是历史最佳图像，确保即使迭代到后期发生了回归，也能输出最优结果。
GEMS 整体是一个 Python 包，核心依赖：
| 组件 | 技术选型 | 作用 |
|---|---|---|
| MLLM 服务 | Kimi-K2.5（通过 Sglang 部署） | 多模态推理、问题分解、验证、反思 |
| 图像生成服务 | Qwen-Image-2512 / Z-Image-Turbo（Diffusers） | 图像生成 |
| 推理框架 | PyTorch | GPU 加速、多卡并行 |
| API 封装 | FastAPI + uvicorn | 多 GPU 推理服务 HTTP 化 |
| Agent 框架 | 自研 BaseAgent + GEMS | 记忆管理、技能路由、迭代控制 |
多 GPU 并行： 图像生成服务（qwen_image.py / z_image.py）使用 Python multiprocessing，在 8 张 GPU 上同时启动独立推理进程，通过 FastAPI 的异步队列协调任务分配。8 卡 A100 集群下，单张图像生成分辨率可达 1328×1328（Qwen）或 1024×1024（Z-Image）。
推理 API 设计： MLLM 调用（think() / think_with_thought()）使用 OpenAI 兼容接口，将 base64 编码的图像注入多模态消息，实现了一次 HTTP 请求中同时传递文本 prompt 和图像内容。
GEMS 在三个标准图像生成评测集上进行了评估：
评估脚本（eval/GenEval2.py）支持 256 worker 并行处理，最大化利用多卡集群，在给定数据集 geneval2_data.jsonl 上批量运行 GEMS 并记录图像路径到 image_paths.json，支持断点续跑（已有记录自动跳过）。
尽管 GEMS 在技术层面设计精妙，但它也面临一些现实问题：
1. 硬件门槛极高： 默认配置需要 8 卡 A100/H100 集群，这对于个人开发者和中小团队来说几乎不可能本地部署。这意味着 GEMS 目前更像是一个「学术研究参考框架」而非「工业级解决方案」。
2. 依赖外部模型权重： 项目代码中多处出现 path/to/... 占位符，意味着用户需要自行准备 Kimi-K2.5、Qwen-Image-2512、Z-Image-Turbo 的模型权重，增加了上手难度。
3. 迭代延迟： 5 轮迭代意味着每次图像生成可能涉及 5 次 MLLM 推理 + 5 次图像生成，总耗时可能达到分钟级别，远高于单次生成的即时反馈。
4. 缺少 Web UI： 目前 GEMS 完全没有用户界面，需要通过 Python API 或命令行调用，这对于非技术用户来说门槛较高。
GEMS 的出现代表了一个新的研究方向：生成式 Agent（Generative Agent）。传统上，Agent 架构主要用于规划、推理、工具调用等任务，而 GEMS 证明了这套框架同样可以应用于创造性任务——图像生成。
从更宏观的角度看，GEMS 所代表的多模态 Agent 路线，与 OpenAI 的 GPT-4V、Anthropic 的 Claude 3、以及国内月之暗面的 Kimi 系列一脉相承：让 AI 不只是回答问题，而是能够规划、执行、反思、优化，完成复杂的多步骤任务。 这一趋势正在从纯文本领域向多模态领域快速蔓延。
如果你关注 AI 前沿，GEMS 是一个值得深入研究的技术样本——它的 Skill 扩展机制、迭代优化循环和记忆压缩策略，都可以在其他 Agent 系统中复用。
项目主页： https://gems-gen.github.io/ 论文： arXiv:2603.28088 GitHub： https://github.com/lcqysl/GEMS