ComfyUI 平台化 SaaS 后端实践

ComfyUI 内容生产平台后端，是把节点图工作流封装成受权限、计费、节点白名单和对象存储约束的多租户内容生产能力层。

我和朋友最近做了一个合作 SaaS 项目，目标用户是个人创作者、MCN / 工作室和企业内部内容团队。项目刚开发完，还没进入生产环境，所以这篇不写用户规模，也不写上线效果，只讲后端怎么把 ComfyUI 从「工程师工具」收敛成平台能力。

一开始最容易被低估的地方是：接通 /prompt 很快，但那只是把一张节点图扔给 ComfyUI。真正要做成产品，问题才刚开始。

直接暴露节点图，会把平台边界打穿

ComfyUI 原生的心智是节点图。工程师用它很顺手，因为节点、模型、参数、输出都摆在眼前，坏了也知道从哪儿查。

但 SaaS 用户不应该直接面对这套东西。

一个创作者要的是「生成某种风格图片」或者「把图片变成某种规格」，不是理解某个自定义节点会读哪些文件、吃多少显存、输出什么结构。管理员也不能每次都靠口头约定告诉用户哪些参数能填、哪些节点不能碰。

所以我没有把 ComfyUI 包成薄皮 UI，而是在中间加了「能力」这一层。

一个能力要声明参数 schema、输出 schema、资源画像和节点依赖。发布时会检查这些契约是否完整，也会检查工作流实际用到的每个 class_type 是否都在白名单里。少声明一个节点，就发布不了。

这个设计牺牲了一点灵活性。新增节点时要同步维护依赖，角色权限里也要放行。但它换来的是平台能提前知道：这个能力允许什么输入，会产出什么东西，大概消耗什么资源，哪些角色可以用。

能力不是 JSON 包装，而是权限和成本的原子单元

如果只是把 ComfyUI workflow JSON 存进数据库，平台仍然不知道怎么计费、怎么限流、怎么让不同组织隔离。

我最后把任务创建链路拆成几步：

用户请求
  -> 能力与角色权限校验
  -> 并发与积分检查
  -> 预扣积分
  -> 参数注入到 workflow JSON
  -> 提交 ComfyUI
  -> 刷新状态与迁移产物

这里有个重要取舍：先扣积分，再跑任务。

后扣费的用户体感更自然，但生成类任务会消耗真实算力。平台如果先跑再扣，失败路径会很难算清楚。预扣之后，问题转移到另一边：提交失败、执行失败要能退款，退款要幂等，余额不能靠一个可被写坏的字段维护。

所以余额不是用户表上的数字，而是积分事件账本求和：sum(delta_credits)。任务成本也不是随手写死，而是 max(1, round(default_cost_credits * credits_multiplier))。这不是什么复杂金融系统，但对一个多租户生成平台来说，够朴素，也够可追。

生产流要放在 ComfyUI 外面

内容生产并不只有「生成」。

真实流程里会有参数选择、生成、文本格式化、人工审核、再次处理等动作。它们不全适合塞进一张 ComfyUI 图。尤其是人工审核和跨能力的数据传递，如果都藏在节点图里，平台就很难解释一次生产流为什么停住、哪个节点失败、用户下一步该做什么。

于是生产流被做成后端里的 DAG。

节点之间靠 input_mapping 传数据，来源包括 static、run_input、preference 和 node_output。运行时用 Kahn 拓扑排序找就绪节点。node_output 只能引用上游节点，不能反向偷看还没执行的结果。

这套 DAG 没有一开始就做得很重。transform 目前只支持有限的文本格式化，manual_review 更像一个人工卡点。

我觉得这个收窄是对的。平台化的第一步不是把所有编排想象都做完，而是先把能力契约、权限、计费、状态和产物安全跑通。

最像小问题的地方，反而最危险

对象存储迁移里有个细节，我很庆幸一开始就写了测试。

ComfyUI history 会返回产物的 filename 和 subfolder。直觉上，拿这两个字段拼出路径，读文件，上传 MinIO，就结束了。

问题是：如果返回的是 ../secret.png 呢？如果是 /tmp/secret.png 呢？如果 subfolder 是 ../ 呢？

测试里专门覆盖了这些输入。平台的处理方式是在调用 MinIO 前就拦截：先拒绝绝对路径，再把拼出的路径 resolve() 成真实路径，最后确认它仍然在配置的输出目录里。不满足就抛 output_path_forbidden。

这类代码没有产品截图，也不适合拿出来做演示。但多租户系统里，它比很多漂亮功能都重要。因为一旦对象迁移默认相信 runtime 返回值，权限、计费和组织隔离都会被绕开。

这套系统现在的边界

这个项目目前是后端核心链路开发完成，还没有生产环境数据。我不会把它写成已经验证过的规模化平台。

能确认的是：能力契约、任务执行、积分账本、权限边界、对象迁移、路径逃逸防护和生产流 DAG 已经形成了后端基础框架。不能确认的是：真实用户会如何设计生产流、哪些能力会被高频复用、成本模型是否需要调整、哪些节点白名单会在真实使用中暴露新问题。

如果以后继续做，我会优先补两件事：一条可展示的典型生产流 DAG，以及生产试点后的真实运行数据。没有这些，商业向叙事就应该克制。

我的判断是，把 ComfyUI 产品化时，最难的不是把 prompt 发出去，而是决定哪些自由度必须收起来。节点图越自由，平台治理层就越重要。