企业官网建设流程全解析

我花两个月搭了一个 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 的外部服务接入协议，全部整合在一个可视化界面里，用户不用再为了做一张图、跑一个自动化流程而在多个软件之间反复横跳。

它的几个核心模块值得分开理解：

这样设计真正带来的变化是：数据不用再靠人搬运，上下文不用再靠复制粘贴，多个 AI 任务可以在同一份上下文里协作。

用一个具体例子解释“AI 漫剧”这个场景。传统漫剧制作流程里，你要先写剧情，再画分镜，再出角色图，然后逐张调整表情。DX-OS 的做法是，你把剧情和角色设定写进 Agent，Agent 调用 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 接入如何打通外部工具链

MCP（Model 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 不接 MCP，Agent 就只能在系统内部绕圈，无法使用外部数据和真实服务。

实际项目中，我更推荐先确定业务场景中最常用的 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 做调度中心。这套架构思想比任何具体产品都更值得长期积累。