让 Claude Desktop 调用 Codex 出图：我做了一个 MCP 桥接工具
把本机 Codex 出图接入 Claude Desktop，看似只是多加一个工具，实际还要处理长任务等待、图片回传和原图保存。记录一次 MCP 桥接的实现、测试结果与当前限制。
我想在 Claude Desktop 里聊着聊着就调用本机 Codex 出图：文字生成也好，带参考图修改也好，最好能直接看到预览，还能找到保存下来的原图。
我的解决办法是做一个本机 MCP 桥接：Claude 把出图需求交给工具，工具启动 Codex CLI，再把预览图和原图路径交回来。
这听起来像是把两个程序连起来，但实际做的时候，有三个具体问题绕不开：出图比一次工具调用等得久，原图不适合直接塞进对话，以及生成的文件需要稳定地交给用户。
2026 年 10 月 22 日的本机记录显示，纯文字出图和带参考图改图都通过，单张约 1.5—3 分钟。这是当时的少量实测，不是速度保证；换机器、网络、提示词或参考图，结果都可能不同。
一、要连接的是什么
这个工具的路径很直接：
Claude Desktop
→ MCP 工具 generate_image
→ 本机 Node.js 桥接进程
→ codex exec 调用 Codex 内置出图能力
→ 保存原图，返回预览和文件路径MCP 可以理解为让客户端发现并调用外部工具的一套协议。Claude 负责理解用户要什么、调用工具；桥接程序负责启动本机 Codex 和整理结果；出图由 Codex 的图像生成能力完成。
服务端是一个 Node.js 文件，没有引入第三方 Node 依赖，通过标准输入和输出交换 JSON-RPC 消息。当前打包的是 Windows 版本，运行需要 Node.js 和已安装、已登录的 Codex。它调用的是本机已有的能力，不是自建图片模型。
这个工具目前是我的本地实现，代码和安装包没有随本文公开发布。下面记录的是实现思路和使用方式，不把它当成现成的公共下载教程。
二、为什么需要两个工具
第一次设计时，最容易想到的是：收到提示词，启动 Codex，等图片出来，再把结果返回。
但笔记里的单张出图耗时是 1.5—3 分钟，而客户端的一次工具请求可能在等待约 60 秒后超时。如果一直等，图可能还在生成，调用方却已经认为这次请求失败了。
我把它拆成两个操作：
| 工具 | 做什么 |
|---|---|
generate_image | 创建任务并等待一段时间；完成就返回结果，没完成就返回任务编号 |
get_image_result | 根据任务编号查询结果；仍在运行时可以继续等待 |
每次默认最多等待 45 秒，可指定等待时间，上限为 50 秒。达到等待上限不等于停止出图：任务继续在桥接进程里运行，Claude 可以用返回的 job_id 再查询。
服务端还设了 10 分钟的任务超时。任务完成、失败和仍在运行都有不同的返回内容；失败时返回错误信息，避免把“还没出图”和“已经失败”混为一谈。
这里有个当前限制：任务状态只保存在进程内存里。服务重启后，旧的任务编号就找不到了，需要重新发起。这个方案适合本机工具，还不是可恢复的任务队列。
三、提示词、参考图和 Codex 怎么交接
generate_image 的必填参数只有提示词；还可以传画幅比例、参考图的本机路径、保存目录、文件名和数量。代码把数量限制在 1—4 张。
桥接程序启动 codex exec 时，把提示词通过标准输入交给子进程，参考图则通过 --image 参数传入。这样提示词不用拼进命令行参数，少处理一层转义问题。
调用时使用只读沙箱和临时会话，并让 Codex 专注调用出图工具。桥接程序本身仍需要创建临时目录、读取生成文件并将结果复制到目标目录，所以这里的“只读”是 Codex 子进程的沙箱设置，不代表整个桥接程序不写文件。
代码优先使用配置的 Codex 路径；在 Windows 上也会查找桌面版附带的可执行文件，找不到再尝试命令行中的 codex。工具的默认转发模型写在配置里，可以修改；这不应被理解成更换了底层图像生成模型。
四、为什么同时返回预览和原图
出图结束后，用户通常有两个不同需求：在聊天里马上看效果，以及把图片用于后续工作。
如果每次都把大图直接塞进工具返回内容，对话负担会很重；如果只返回文件路径，又得离开聊天窗口才能确认结果。于是我分成两份：
- 本地文件：把生成文件复制到配置的输出目录，返回路径；文件重名时自动加序号。
- 聊天预览：在 Windows 上尝试把图片缩到最长边不超过 1024 像素的 JPEG，再作为图片内容返回。
10 月 22 日的笔记里，预览约 60KB；这是一次记录，不是固定大小。预览生成失败时，代码会尝试直接返回较小的原始文件；超过大小上限时可能只返回路径。因此，看到路径但没看到预览，不一定意味着没有生成图片。
另一个细节是文件格式：代码会检查文件头，识别内容实际上是 WebP 的情况。检测到 WebP 时，有 FFmpeg 就尝试转成 PNG；没有则按 WebP 扩展名保存。文件名和内容格式尽量保持一致，避免后续打开时产生误解。
五、一次调用是什么样
在我的 Claude Desktop 里，可以直接提出类似这样的要求：
调用 Codex 出图，生成一张白底咖啡杯产品图，并把图片展示出来。
客户端调用 generate_image 后，如果图片还没生成完，工具返回任务编号；然后客户端用 get_image_result 查询。完成后，返回内容包含可用的预览和保存路径；如果预览不可用，至少需要检查返回的文件路径和错误信息。
带参考图时，提供的是本机可访问的图片路径。服务端会先检查路径是否存在，再把参考图交给 Codex。我的本机笔记记录了文字出图和参考图改图都通过，但没有留下完整的逐次耗时和样本统计，所以这里不推断成功率，也不比较图像质量。
六、现在还缺什么
这个工具解决的是我眼前的本机工作流，离可以随意分发还有距离：
- 平台范围：安装包标注 Windows；目前没有跨平台的完整验证。
- 重启恢复：任务存在内存中，服务重启后不能继续用旧编号查询。
- 并发归属：正常情况下按 Codex 的会话目录找图；找不到时会按任务开始时间搜索新图。多个任务同时运行时，兜底搜索存在混入其他任务图片的风险，适合串行使用，不能把归属当成已严格保证。
- 数量与效果：数量和比例通过提示交给 Codex，代码会限制请求数量，但没有保证生成数量、画幅或视觉效果一定满足要求。
- 前置条件：依赖本机 Codex 安装、登录状态和可用出图能力；配置变化、软件版本和网络状态都可能影响结果。
这些限制比一句“支持自动出图”更重要：它们决定了什么时候能放心用，什么时候需要先检查结果。
写在最后
这次最大的收获不是多了一个按钮，而是把一个跨程序流程拆清楚：谁接收需求，谁执行长任务，调用方怎么知道任务仍在运行，以及最终文件交给谁。
对个人工具来说，能跑通一次只是开始。能解释等待、失败、文件归属和恢复边界，才更容易在下一次使用时知道该不该相信结果。
相关阅读
版权与声明
本站所有内容仅代表作者个人观点，与作者供职的公司、客户或其他关联机构无关。
本文除特别声明外，采用 CC BY-NC-SA 4.0 许可协议。转载或改编请署名、附原文与许可证链接，并标明改动；不得用于商业用途，演绎作品须以相同许可发布。
评论