AI创作工作台：整合ComfyUI、Skills、MCP与Agent的设计实践

我花两个月搭了一个 AI 操作系统把 ComfyUI、Skills、MCP、Agent 全部揉进同一个画布里。这篇文章不是为了展示我多能折腾而是想认真聊聊当这些能力不再是四个独立的 GitHub 仓库而是装进同一个工作台之后AI 创作流程会变成什么样。如果你正在折腾 ComfyUI 工作流、写 AI Skills、连 MCP Server或者想做一个自己的 Agent 项目建议先把这篇文章收藏起来。它不只是一份功能导览更是一份把画图、批量处理、自动化脚本、外部工具接入全部串起来的设计笔记。1. 为什么我觉得 AI 创作工具需要一次“系统级”整合先说你最熟悉的场景。以前我们要完成一个 AI 漫剧项目大概需要准备这些东西一个 SD/ComfyUI 环境负责生成角色立绘和场景图。一个表情/动作分层工具把人物和背景拆开。一个写脚本的 LLM Agent帮我们把剧情变成分镜。一个批处理系统把几百张图片统一风格、统一尺寸。一个工具连接层让上面的各种能力之间能互相调用。这些工具每个都能打但组合起来很痛苦。ComfyUI 的工作流只能在图生图内部转Agent 只能做文本推理MCP Server 只负责接通某个外部服务Skills 只是给 Agent 加几个预设工具。你要让一张图经过“角色生成—表情替换—背景分层—批量导出”这条链路需要自己写胶水代码要在不同工具之间来回切换还要忍受每次导入导出时丢参数、丢风格、丢元数据。DX-OS 想做的是把这一整套问题收进同一个系统。它的核心思路不是再做一个小工具而是做一个带统一画布、统一上下文、统一工具协议的 AI 创作环境。听起来有点大但本质上解决的是“流程碎片化”这一点。从我的实践体验来看这个方向比“再加一个单体工具”更接近未来。2. DX-OS 到底是什么一个可以跑通“想法到成品”的 AI 工作台先说结论DX-OS 不是一个严格意义上的操作系统它更像一个 AI 原生创作工作台。它把 ComfyUI 的图像生成链路、Agent 的任务推理能力、Skills 的工具封装范式、MCP 的外部服务接入协议全部整合在一个可视化界面里用户不用再为了做一张图、跑一个自动化流程而在多个软件之间反复横跳。它的几个核心模块值得分开理解模块解决什么问题传统做法无限画布将多个任务、多张图片、多个环节集中在同一空间管理在文件夹里来回导出导入图片分层把角色、背景、前景、表情等元素拆分处理手工 PS 抠图或依靠通用分割模型ComfyUI 工作流集成复用成熟的图生图/文生图工作流单独打开 ComfyUI 界面手动切换 APISkills 技能封装把固定操作步骤变成 Agent 可调用的技能每次写临时 prompt 或独立运行脚本MCP 接入统一连接外部数据、画板、设计工具、文档库各自官方插件/API互不兼容Agent 调度理解用户意图并编排上面的所有能力各工具之间无统一调度这样设计真正带来的变化是数据不用再靠人搬运上下文不用再靠复制粘贴多个 AI 任务可以在同一份上下文里协作。用一个具体例子解释“AI 漫剧”这个场景。传统漫剧制作流程里你要先写剧情再画分镜再出角色图然后逐张调整表情。DX-OS 的做法是你把剧情和角色设定写进 AgentAgent 调用 ComfyUI 工作流生成初始立绘然后在画布里把立绘分层成背景、角色主体、表情层接着遍历全部的分镜画面做批量表情替换最后统一输出成漫画分页。整个过程的所有中间产物都在一个空间里你可以随时回头看某一层发生了哪些变化也可以随时把某个步骤抽出来重新跑。3. 核心能力拆解一无限画布和图片分层为什么不是锦上添花无限画布这个概念在 Figma、FigmaJam 里很常见但在 AI 生成工具里是另一种意思。它要解决的不只是“我可以在空白处再拖一张图”而是为生成流程提供一个可以对照、排列、回溯的工作空间。在一个漫剧项目里你可能有几十个分镜每个分镜又有角色 A、角色 B、背景、表情变体。传统工具里这些图通常按文件夹组织文件名一长就分不清。DX-OS 的无限画布里你可以把每一页分镜当成一个区块把角色立绘放在固定区域把每一张变体生成图直接拖到对应位置。视觉上非常直观而且生成结果可以带着参数和 prompt 信息一起保留。图片分层模块则是把一张成品图拆成不同语义层。这个分层其实复用了一部分 ComfyUI 里常见的语义分割能力但产出的不是一张调色后的图而是一组可编辑的图层。也就是说出图之后你可以继续修不像以前那样重新抽卡。从实际使用价值来看图片分层最有用的两个场景一个是表情/口型替换一个是背景和角色的独立二次编辑。AI 漫剧很依赖前一个能力角色立绘做好之后只要把表情层替换掉就能生成同一个角色在不同情绪下的画面不需要重画整个人物。4. 核心能力拆解二ComfyUI 集成到底比其他方案好在哪ComfyUI 在 AI 绘画圈里已经是很成熟的工作流引擎。它的核心特点是节点化工作流图生图、图生视频、LoRA 切换、ControlNet 控制、超分等操作都可以用一个个节点串起来。它的问题是工作流一复杂界面就变得很难管理而且它本身不具备“任务调度”和“多模态内容组织”的能力。DX-OS 的做法不是重新发明一套节点引擎而是把 ComfyUI 作为底层执行引擎嵌入系统。用户可以在 DX-OS 里调用工作流、切换模型、跑图同时把工作流产生的图片自动放进画布。这样相当于把 ComfyUI 的能力搬到了一个更大的环境里让图片生成不再是终点而是整个创作流程的原材料工厂。一个典型工作流设计建议是这样文生图节点负责生成角色初始形象。Prompt 建议写清楚人物性别、年龄、服装、发型、色调并开启固定种子方便之后做相同风格的变体。LoRA 节点负责锁定角色风格同一角色在不同分镜中使用同一个 LoRA可以保持角色一致性。表情/姿态节点通过 ControlNet 控制表情和动作不改变人物整体外观。图像分层节点输出 role 层、background 层、style 层。保存节点自动输出到画布指定区域并带上 prompt、模型名、seed 等元信息。从工程角度讲这样的集成让“跑一次 ComfyUI 工作流”从“得到一张图”变成了“得到一个带上下文的图像资产”。这个转变对批量创作项目非常关键因为它让后端的 Agent、Skills、MCP 都可以基于统一的图像资产去工作而不是互相之间传一堆文件名。5. 核心能力拆解三Skills 在 DX-OS 里到底扮演什么角色Skills 最近非常火。所谓 AI Skills本质上是把 Agent 需要重复执行的某类任务预定义成一套结构化的技能包包含步骤、提示词、规则、参数模板和示例。它和直接写 prompt 的区别是Skills 是可复用、可分享、可编程的任务模板。在 DX-OS 这样一个把所有工具都放在一起的系统里Skills 的价值会被放大很多。因为 Skills 不只是给 LLM 一段话而是可以触发系统里的具体能力比如运行一个 ComfyUI 工作流、调节图片图层、调用某个 MCP 工具、向某个外部服务发起请求。举个例子一个“一致化角色立绘生成”的 Skill 可以包含以下内容{ name: consistent-character-design, description: 生成保持角色一致性的立绘并输出到指定画布区域, input: { character_description: string, num_variants: integer, style_reference: image }, steps: [ { type: comfyui.run_workflow, workflow_id: character_base, params: { prompt: {character_description}, seed: fixed } }, { type: image.layer_split, target: base_output, layers: [character, background] }, { type: canvas.place_asset, target: character_sheet } ], output: { assets: [layered_character_sheet] } }这里并没有指定某个 ComfyUI 内部 API 的具体参数因为不同环境版本会不一样。但你可以看到Skill 的结构化本质意味着它完全可以和画布、图层、MCP 联动。这样的 Skills 已经不是“给 ChatGPT 的一句模板话术”而是一个系统级执行脚本。很多人在写 AI Skills 时会犯一个错误把 Skills 写得像一篇好 prompt。它确实需要好 prompt 作为内核但更重要的是步骤编排和输出定义。Skills 的价值在于任务可以被标准化执行可以被评价、收藏、复用。就像前端开发的 Skills 会把“创建新页面”拆成一份模板列表加一套代码生成规则而不是简单地说“帮我写一个页面”。6. 核心能力拆解四MCP 接入如何打通外部工具链MCPModel Context Protocol已经是 Agent 工具接入的主流协议。它解决的是“模型如何安全地调用外部工具”的问题。MCP Server 负责暴露能力MCP Client 负责连接模型通过工具调用完成具体操作。市面上大量生态工具都在做 MCP Server比如设计稿工具、文档服务、浏览器自动化服务等。DX-OS 提供的是一个可以统一管理多个 MCP Server 的环境。你不需要每次在命令行里手动启动 server也不用关心如何把 MCP 的工具注册进 Agent系统会帮你维护工具列表和调用上下文。对比一下有 MCP 和没有 MCP 的差异。没有 MCP 时你的 Agent 只能读文字、写文字碰到外部数据只能通过手写 API 调用去接。有了 MCP 之后Agent 可以直接使用已经对接好的工具比如在图生图的过程中读取某个设计稿里的颜色和布局信息或者把生成结果自动上传到某个素材库。在实际接入时我建议把 MCP Server 分成两类管理生产型 MCP文档查询、数据库查询、搜索接口稳定优先配置要写清楚超时时间和错误处理。创作型 MCP设计稿信息读取、图片参考库、图层信息查询这类 MCP 通常和画布功能绑定适合放在可视化操作区。MCP 和 Skills 很容易被搞混。简单区分一下Skills 是给 Agent 用的可复用任务封装MCP 是给 Agent 用的外部工具接入协议。一个 Skill 可以在步骤里调用多个 MCP 工具MCP 工具也可以被多个 Skill 复用。7. Agent 编排当 ComfyUI、Skills、MCP 被同一个大脑调度DX-OS 里的 Agent 和普通聊天机器人有本质区别。它不是一个只会生成文字回复的模型而是一个能够编排多个工具的任务执行器。它需要理解用户意图把需求拆解为步骤然后逐步调用 ComfyUI、Skills、MCP 中的能力最终把产物汇总回画布。一个相对完整的 Agent 任务流程可以这样描述用户输入帮我生成一个主角为红发少女的 AI 漫剧第一话分镜共 6 页反派是机械将军。Agent 解析提取角色设定、分镜数量、风格要求判断需要先建角色资料再生成场景再排版分镜。Agent 调用 Skill先调用 consistent-character-design Skill生成红发少女的固定立绘。Agent 调用 ComfyUI针对每个分镜页面运行 background generation 工作流生成场景底图。Agent 调用图像分层将角色和背景图层合并同时保留独立图层以便后续修改。Agent 调用 MCP如果需要外部灵感图或资料参考可以通过已连接的 MCP Server 拉取。Agent 输出在画布上形成一个完整的第 1 话分镜草稿并把所有参数和中间产物记录在项目日志里。这个流程看上去不复杂但实现上最大的挑战是状态管理。ComfyUI 跑完一次工作流会产生哪些输出、图片放在哪个图层、哪个分镜还缺表情这些状态信息必须被 Agent 感知和记录。DX-OS 把画布作为共享状态空间恰好降低了这部分实现难度。如果你在自己做 Agent 项目可以重点参考“画布即状态”这个设计理念。它比让 Agent 靠文件路径去理解上下文要可靠得多因为文件的组织方式只有你能理解而画布上的位置关系对 Agent 来说更直观、更适合用视觉模型理解。8. 关于 AI 漫剧一个最适合验证这套系统的场景为什么要专门提 AI 漫剧因为它是同时依赖“图片生成质量”、“角色一致性”、“批量自动化”和“内容编排”的高难度场景。不是说用 AI 生成几张好看图片就够了漫剧需要连贯的叙事、稳定的角色造型、统一的场景风格以及大量分镜图片。在 DX-OS 中做 AI 漫剧我推荐的流程是第一步建立角色资产库。在画布里为每个主要角色建立一个区域调用分层功能把立绘拆成“头部、身体、表情、特效”等层以后做任何变体都从这个资产库出发。第二步搭建场景素材库。用 ComfyUI 的图生图或 ControlNet 批量生成不同地点、不同时间、不同天气的背景图。背景图尽量不包含人物方便以后和角色层合成。第三步设计分镜脚本。用 Agent 写剧本把每个分镜的文字描述、对话、镜头语言都写成结构化 JSON不要只写纯文本。第四步批量执行分镜生产。Agent 根据分镜脚本自动为每一页调用 ComfyUI 工作流合成角色和背景插入对话气泡最后输出整页漫剧图。第五步人工审美筛选与参数回填。AI 自动生成的结果不可能百分百合格人需要做的是在画布里快速对比不同版本选择更满意的结果并把对应 seed 和参数回填给 Agent方便生成后续页面时保持一致性。这套流程最关键的并不是 ComfyUI 有多强而是整个系统里信息流是通的。角色资产、背景素材、分镜脚本、生成参数、中间产物所有东西都在同一个上下文里Agent 才能在每一步做出相对合理的决策。9. Skills、MCP、Agent 的最佳组合方式如果你在搭建自己的 Agent 工具链这里有一个比较稳妥的组合思路可以直接迁移到 DX-OS 或类似的系统设计中。第一层是工具层解决“能做什么”。包括 ComfyUI 工作流、MCP Server、文件操作工具、网络请求工具。这一层只负责提供能力不做决策。第二层是技能层解决“怎么做”。把经常使用的固定流程封装成 Skills。Skill 是工具层之上的模板它定义了步骤、输入、输出和异常处理方式。好的 Skill 应当像函数一样有明确的接口而不是一段模糊的文字描述。第三层是智能层解决“该做什么”。Agent 根据用户需求选择和组合技能并监控执行过程。Agent 不一定需要很强的推理能力但一定要有很好的“按规格办事”能力每个 Skill 需要哪些输入、输出到哪里、异常时如何处理。关于 Skill 和 MCP 的关系再强调一次MCP 解决连接Skill 解决编排。很多项目里开发者花时间实现了一堆 MCP Server最后发现 Agent 还是不会用因为缺少一个把它们串成任务的 SKill 层。反过来只写 Skill 不接 MCPAgent 就只能在系统内部绕圈无法使用外部数据和真实服务。实际项目中我更推荐先确定业务场景中最常用的 3 到 5 个任务把它们封装成 Skill再为每个 Skill 搭配必要的 MCP 工具。不要一上来就把所有能接的工具全部接进来工具列表太长反而会增加 Agent 的误判率而且会增大 token 消耗。10. 使用建议与容易踩坑的地方这套系统刚出来资料不多我基于实践整理了几条使用建议也提醒大家注意几个容易踩坑的地方。第一ComfyUI 模型和工作流版本要先在标准 ComfyUI 环境跑通。不要一上来就把复杂工作流塞进 DX-OS。DX-OS 的定位是流程编排层底层节点的调试最好还是回到原始环境做否则出错时很难分辨是节点问题还是编排问题。第二图片分层前先确认素材质量。分层功能对素材质量有较高要求如果原图的边缘细节太差分层后很容易出现断边、残留背景等缺陷。建议在 ComfyUI 工作流中先做一次高清修复或细节增强再进入分层环节。第三Agent 的上下文要用模块化方式管理。不要把一个项目的所有信息一股脑丢给 Agent。实验下来按“角色设定、场景设定、分镜脚本、风格规范”四个模块管理上下文Agent 的稳定性明显更高。第四MCP 接入要管控权限和超时。生产环境使用 MCP 时至少配置连接超时和重试策略。外部服务如果延迟过高Agent 任务会被卡住导致整个工作流失败。可以给关键 MCP 调用设置一个兜底提示:比如在规定时间内没有返回结果就让 Agent 跳过这个工具并记录原因。第五善用日志和中间产物回溯。DX-OS 这类系统能做复杂任务编排意味着它也会产生大量中间结果。建议每跑完一个环节就随手命名并保存关键产物不要等最后再统一整理。因为一旦任务中途失败你可能需要定位到具体哪一张图、哪一个参数出了问题。11. 对整个 AI 创作工具生态的一些思考花两个月做 DX-OS收获最大的不是跑了多少张图而是让我对 AI 创作工具的下一步沉淀了一个判断未来的 AI 创作环境不会是一个孤立的大模型应用而是一个把不同能力连接起来的创作系统。基础大模型只会越来越强但真正决定用户体验的是系统层怎么把这些模型、工作流、工具协议和任务编排组织好。ComfyUI 证明了可视化工作流的价值但它缺少任务调度和系统扩展能力。Skills 证明了任务模板化的价值但只有连接真实工具系统才能发挥威力。MCP 在解决工具接入统一性的问题但如果没有上层编排它只会变成一堆 API 列表。Agent 代表了未来的交互方向但 Agent 的实用性取决于它身后有多少可调用的可靠工具。DX-OS 把这些能力放进同一个系统之后我最大的感受是过去我们要学一堆工具、写一堆胶水代码才能把一个自动化的 AI 创作流程跑通。而如果这种整合设计走向成熟创作者可以把更多精力放在内容和审美上而不是放在环境配置和工具拼接上。这不是说每个 AI 爱好者都要去搞一个自己的 AI 操作系统。更现实的做法是在你自己的项目里借用这套设计思路把 ComfyUI 当成执行引擎把 Skills 当成命令模板把 MCP 当成外部工具接入层让 Agent 做调度中心。这套架构思想比任何具体产品都更值得长期积累。