不再堆 AI 工具:Infinite Canvas 想用一张画布接管生图、视频和 Agent

用 AI 做一组视觉内容，最麻烦的往往不是“生成”本身。

提示词写在聊天窗口，参考图散落在下载目录，生图用一个网站，改图换另一个模型，视频再交给第三个平台。尝试十几轮以后，真正难回答的不是哪张最好，而是：这张图用了哪个提示词、参考了哪张素材、改过哪些参数？

开源项目 Infinite Canvas 想解决的，正是这种创作链路碎片化。

它不训练新的图片或视频模型，而是把文本、图片、视频、生成配置和 Agent 都变成画布节点。一次创作不再是一串难以追溯的聊天记录，而是一张能查看上下游关系、继续分叉迭代的工作流图。

截至 2026 年 10 月 27 日，basketikun/infinite-canvas 在 GitHub 获得约 9245 Star、2166 Fork，采用 MIT 许可证；最新正式版为 v0.20.0，主分支仍在持续更新。

它不是模型，而是 AI 视觉创作的工作台

Infinite Canvas 的界面看起来像设计工具，但它更接近一套面向 AI 创作的可视化编排系统。

画布目前可以放入图片、文本、视频、音频和生成配置等内容。节点可以拖动、缩放、分组和连线，也支持小地图、撤销重做、复制粘贴、导入导出。文本节点可以保存提示词，图片节点可以作为参考图，生成配置节点则负责选择模型、比例、分辨率和生成数量。

连线不是装饰。它代表素材之间的依赖关系：一段提示词进入生成节点，产出多张图片；其中一张再与新的文本连接，继续做改图或视频。创作者可以沿着线路回看每个结果从哪里来，也可以在任意节点旁边开一条新分支。

项目目前支持 OpenAI 兼容的文本与图像接口，也提供视频、音频、自定义生图和视频调用脚本。它更像模型之上的“控制台”：模型负责生成，画布负责保存上下文、组织素材和记录过程。

一张图为什么比一段对话更适合迭代

聊天式 AI 有一个天然限制：过程是线性的。

当你说“保留人物，换成雨夜背景”，模型只看得到当前对话里的上下文。继续修改几轮后，哪些要求来自原始设定，哪些只是某次尝试，越来越难区分。

画布式工作流则允许并行。

同一张参考图可以连接不同风格提示词；同一组角色设定可以生成多个场景；满意的分支继续向下扩展，失败分支留在原地，不会覆盖之前结果。对于角色一致性、产品视觉方案、分镜探索和批量素材生产，这种结构比“不断追问同一个聊天框”更容易复盘。

v0.20.0 还加入了缩略图元素列表、悬停预览、节点重新生成策略、默认图片和视频分辨率等能力。它们听起来不如“Agent 自动创作”吸睛，却直接影响大画布能否长期使用：当节点变多，定位、预览和避免误覆盖，往往比再接一个模型更重要。

Agent 能操作画布，但不是网页里的万能机器人

项目的另一条主线是 Canvas Agent。

它是运行在用户电脑上的本地服务，通过 MCP 把画布工具暴露给 Codex。安装后，Agent 可以读取当前画布、创建文本节点、应用一批节点操作，或者搭建“提示词—参考图—生成配置”的流程。

这里要注意两个边界。

第一，网页侧边栏当前主要开放的是 Codex。仓库虽然保留了 Claude Code 适配代码和 MCP 接入说明，但网页侧边栏尚未把 Claude 入口正式开放。

第二，Agent 不是远程云服务。Canvas Agent 默认只监听 127.0.0.1，启动时生成连接 Token；网页首次连接后还会记录 Origin，其他来源不能直接复用。真正修改画布前，网页侧仍有二次确认。

这套设计的价值，不是让 Agent 在后台“随便画”，而是让它在一个有结构的画布里工作。人负责选择方向和审核结果，Agent 负责创建节点、连接上下文和执行重复编排。

“数据在本地”不等于没有安全风险

Infinite Canvas 不要求注册账号。画布、素材、生成记录、Base URL 和 API Key 默认保存在浏览器本地，AI 请求也由浏览器直接发往用户配置的模型服务，不经过项目自己的中心服务器。

这对个人创作者很友好：部署一个静态 Web 应用就能使用，也不用把素材先上传到项目方后台。

但“保存在本地”不是“永远安全”。至少有三点需要注意。

一是浏览器环境本身。 API Key 存在页面可访问的本地存储里，只适合个人设备或可信环境。共享电脑、公共部署和来源不明的浏览器扩展，都可能扩大风险。

二是远程节点插件。 项目允许通过 URL 安装第三方插件。官方安全文档明确说明：插件代码直接运行在 Web 应用页面中，能够访问页面数据，包括本地保存的 AI API Key。这不是隔离沙箱。安装插件前的确认提示只能提醒用户，不能把恶意代码变安全。

三是自定义调用脚本。 它可以帮助项目适配不同中转站和私有接口，但脚本同样会接触请求参数与凭据。不要从陌生来源复制执行，也不要把生产密钥交给未经审查的脚本。

因此，更稳妥的做法是为画布单独创建低额度 API Key，限制可用模型和消费上限；第三方插件只从可信仓库安装；对外提供实例时，不要把个人密钥预置在浏览器配置中。

本机验证：核心 Agent 测试通过，前端类型检查暴露回归

本次调研固定在主分支提交 9cd3deac，并与正式版 v0.20.0 的提交 3a6b64b6 分开核验。

Canvas Agent 的依赖安装、126 项自动化测试和 TypeScript 构建均通过。测试覆盖多标签页画布隔离、MCP 工具路由、写操作互斥、配置文件权限、Skill 修改保护、日志凭据脱敏等关键行为。

Web 前端的 15 项测试全部通过，Vite 生产构建也成功。但 tsc --noEmit 类型检查未通过：model-script-editor.tsx 使用的 Modal 样式字段与当前安装的 Ant Design 类型不兼容。构建产物同时提示主 JavaScript 文件约 3.74MB，仍有明显的拆包优化空间。

这不代表应用无法运行，却说明主分支不是“所有检查全绿”的稳定产品。仓库 README 也明确提醒：项目仍处于开发阶段，本地存储格式可能直接调整，历史数据不保证兼容。重要画布应定期导出备份，而不是只留在一个浏览器配置中。

谁适合用，谁不适合

Infinite Canvas 适合希望把多模型视觉创作过程保留下来的人：需要反复比较提示词、角色设定、参考图和视频分镜的内容团队；愿意自己配置 API、理解模型差异的个人创作者；以及想让 Codex 参与素材编排的开发者。

如果只是偶尔生成一张图，它可能比聊天框更复杂。若企业需要多人权限、审计、密钥托管、稳定的数据迁移和集中式资产管理，当前版本也还不够。它没有把模型费用变没，也没有自动解决版权、肖像权和生成内容合规问题。

它真正降低的是另一种成本：找回创作过程的成本。

结语

AI 创作工具越来越多，真正稀缺的开始不是“再接一个模型”，而是把灵感、素材、参数、结果和修改路径组织起来。

Infinite Canvas 的方向值得关注，因为它把生成结果重新放回工作流：每张图不再只是下载目录里的一个文件，而是有来源、有上下游、可以继续编辑的节点。

它还年轻，前端类型检查、包体积、插件信任模型和数据兼容性都有现实问题。但如果你已经厌倦在多个网站之间复制提示词、下载素材、重找参数，一张能够记录完整路径的画布，可能比“全能生成按钮”更接近真正的生产工具。

资料来源

• • 项目文档：https://canvas.best/docs
• • 安全策略：https://github.com/basketikun/infinite-canvas/blob/main/SECURITY.md