用 Gemini 3.1 Flash Lite Image 配合 MCP 协议实现图像有状态编辑的实操心得
简单来说，这套方案让 AI Agent 具备了 Stateful（有状态）的图像编辑能力。以前的操作逻辑是“生成 → 丢弃 → 再生成”，而现在变成了在原图基础上进行迭代。比如我先让它画一个赛博朋克风格的厨房，在确认基础构图没问题后，直接发一句“在窗边加个霓虹灯拉面招牌”，它会在保持原图绝大部分元素不变的情况下，精准地把招牌加上去，而不是重新随机生成另一个厨房。
在技术实现层面，这个工作流由两部分构成：首先是基于 FastMCP 搭建的服务器，它充当了中转站，负责调用 Google 的 API；其次是 Codex 的 skill 配置，定义了 Agent 在什么场景下触发哪个工具。
这里最核心的逻辑在于对 Interactions API 中 interaction_id 的管理。要实现有状态编辑，必须遵循一套严格的 ID 链条：
首先，在第一次调用 create 接口时，必须明确设置 store=True。只有这样，服务器才会返回一个唯一的 interaction_id。随后的所有修改请求，只要在 Payload 中携带这个 ID，模型就能在服务端维持视觉上下文，知道你在指哪张图。
但这里有一个关键的细节：每次编辑操作完成后，服务端都会产生一个新的 ID。你必须在下一次请求中使用这个最新的 ID 才能接续对话。如果你尝试使用旧的 ID，就会产生版本分叉，导致编辑效果失效或出现逻辑混乱。
在实际部署和调优过程中，我踩了两个比较深的坑，分享给大家避雷：
第一是关于比例锁定的问题。图像的长宽比（比如 16:9 或 1:1）必须在首次生成时就确定死。在后续的编辑请求中，如果你尝试更改比例，像素连续性会直接崩溃，出来的图会出现严重的拉伸或拼接痕迹。
第二是关于思考等级（Thinking levels）的参数设置。翻看 API 文档时，你会看到 minimal 和 medium 这两个选项，但在实际调用 gemini-3.1-flash-lite-image 模型时，传入这两个值会直接触发 HTTP 400 错误。经过多次实测，目前该模型仅支持 low（适用于快速出草图）和 high（适用于复杂渲染或需要精准文字呈现的场景）这两个值。
如果你想在自己的 Codex 环境中跑通这套流程，核心逻辑其实都集中在 server.py 中。通过 FastMCP 将 API 封装成工具，然后在 Codex 侧配置对应的 skill 即可。
这种有状态的编辑能力在公司内部做 UI 原型快速迭代时效率极高。它把 AI 绘画从“抽卡游戏”变成了“指令协作”，我们不再需要把大量时间浪费在 Prompt 的微调和权重计算上，而是可以直接像指挥美工一样，通过简单的对话完成视觉方案的快速打磨。
