无限画布 infinite-canvas：把 AI 生图工作流搬进浏览器画布的开源实验品
AI AI Agent 代理 OpenAI chatgpt2api grok2api flow2api newapi 。
秒懂
- 它是什么？
- 无限画布是一个面向图片创作的开源工作台，将画布编排、AI 生图、参考图编辑和提示词库集中在一个界面。本文基于仓库文档分析其机制、部署方式与当前阶段的适用边界。
- 适合谁用？
- 无限画布适合那些愿意接受频繁变更、习惯在浏览器里直接操作 AI 生图流程的个人创作者，尤其是已经拥有 OpenAI 兼容 API 的用户。它不适合需要稳定数据格式、团队协作或生产级交付的团队，因为项目明确警告不保证历史数据兼容。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 9 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
一个把生图流程搬进画布的工作台
无限画布解决的是图片创作过程中反复切换工具的痛点。通常创作者要在生图网站、参考图编辑器、聊天助手和素材文件夹之间来回搬运文件。这个项目把画布编排、AI 图片生成、参考图编辑、对话助手、提示词库和素材沉淀放进同一个界面。它的目标用户是那些需要连续迭代视觉方案的创作者，比如插画师、概念设计师或 AI 绘画爱好者。项目首页定位明确，面向图片创作，不是通用 AI 聊天工具。它把节点拖拽、缩放、连线和撤销重做这些画布操作，与 AI 生图请求直接绑定，让结果能插回画布继续编辑。
浏览器直连 API，本地 Agent 通过 MCP 操作画布
项目机制的核心是浏览器前台直连你配置的 OpenAI 兼容接口。文档明确说 AI API Key、Base URL、画布、素材和生成记录默认保存在浏览器本地，这意味着所有请求都从浏览器直接发出，没有后端代理。这样做的好处是部署简单，隐私数据不出本地，但坏处是浏览器跨域限制可能成为障碍，而且 API Key 暴露在浏览器环境里。另一个关键机制是本地 Canvas Agent，它通过 MCP 协议连接 Codex 或 Claude Code，让 Agent 能直接操作当前画布。Codex app 插件安装后会自动注册 MCP 并尝试拉起本地 Agent。这种设计把 AI 生图和代码型 Agent 分成两条路径，一条走浏览器 API 调用，另一条走本地进程，两者通过画布这个中间层协调。
Docker 与本地开发两条部署路径
项目提供两种启动方式。本地开发需要先克隆仓库，然后进入 web 目录，用 bun 安装依赖并启动开发服务器。命令是 git clone、cd web、bun install、bun run dev。Docker 部署更简单，克隆后直接运行 docker compose up -d，默认端口 3000，访问 http://localhost:3000。首次打开后进入右上角配置，填入 OpenAI 兼容的 Base URL 和 API Key。如果默认调用方式与你的 API 不兼容，可以自定义生图或视频脚本。文档特别提到这个项目处于开发阶段，不保证历史数据兼容，各种本地存储格式都可能直接调整。这对部署者是一个明确警告，升级版本可能丢失或损坏已有数据。
插件系统与提示词库的灵活性
项目内置了插件系统，支持通过 URL 动态安装、启用、更新和卸载远程节点插件，并提供 TypeScript SDK 供开发者自行编写画布节点插件。这意味着用户不必等待主项目更新，就可以扩展新的画布节点类型。提示词库方面，内置 7 个开源提示词来源，并支持自定义标准 JSON 来源，由浏览器前端直连并缓存到 IndexedDB。这个设计把提示词管理也纳入画布工作流，减少切换窗口的次数。但插件系统也带来风险，远程插件本质上是执行外部代码，用户需要信任插件来源。文档没有提及插件沙箱或权限隔离机制，这可能是安全隐患。
当前阶段的硬伤：数据兼容性无保障
README 开头就放置了一个 CAUTION 块，明确说项目处于开发阶段，不保证历史数据兼容，各种本地存储格式都可能直接调整。这是最诚实的声明，也是最关键的局限。如果你把生成记录、画布布局和素材都保存在浏览器本地，一旦版本更新改变了 IndexedDB 或本地存储的结构，旧数据可能无法读取。文档建议如果需要稳定维护自己的分支，自行 fork 后独立开发。此外，浏览器直连 API 的方式意味着所有请求都受浏览器同源策略限制，如果你的 API 服务没有配置 CORS 头，前端请求会失败。自定义脚本调用可以缓解一部分问题，但需要额外配置。对于依赖 API 中转站或自建服务的用户，兼容性需要逐一验证。
与 ComfyUI 或纯 API 工作流的差异
一个现实的替代方案是使用 ComfyUI 配合 API 中转服务。ComfyUI 采用节点图方式编排生图流程，节点更底层，控制粒度更细，但学习曲线陡峭。无限画布把节点抽象为画布上的图片、文本和参考图，更偏重创作流程而非技术参数。另一个替代是直接用 OpenAI 兼容 API 写脚本调用，配合本地文件管理，这种方式灵活但缺乏可视化画布。无限画布的优势在于把对话助手、提示词库和画布编辑整合在一起，减少工具切换。但 ComfyUI 有庞大的社区生态和稳定的数据格式，而无限画布目前更像一个快速迭代的个人项目。如果你需要的是可复现的复杂工作流，ComfyUI 可能更合适。
维护成本与许可证的实际含义
仓库信息显示主分支默认分支为 main，最近一次推送在 2026 年 8 月，版本号已到 v0.16.0，说明开发活跃。但频繁的版本迭代也意味着 API 和存储格式可能频繁变化。文档明确说本地存储格式可能调整，维护者建议需要稳定分支的用户自行 fork。许可证方面，仓库元数据显示为 AGPL-3.0，但 README 中写的是 MIT License，两者冲突。AGPL-3.0 要求如果通过网络提供服务，必须开源修改后的代码，这对商业闭源使用有较大限制。而 README 声称 MIT 允许闭源商业使用，这种矛盾需要用户自行向维护者确认。在许可证未澄清之前，企业用户应谨慎将项目集成到商业产品中。
编辑结论
无限画布适合那些愿意接受频繁变更、习惯在浏览器里直接操作 AI 生图流程的个人创作者，尤其是已经拥有 OpenAI 兼容 API 的用户。它不适合需要稳定数据格式、团队协作或生产级交付的团队，因为项目明确警告不保证历史数据兼容。决定采用前，请先确认你的 API 是否支持 OpenAI 协议，并检查自定义脚本调用是否能覆盖你的特殊接口。若你依赖长期可维护的工作流，建议 fork 后自行维护，或者先等待项目进入稳定版本。最终判断：这是一个功能丰富但尚未定型的实验性工具，适合尝鲜，不适合作为关键生产依赖。
社区笔记