# AI Native 游戏开发工作站方案 EpeeKit ## —— 以 Agent 编排为核心的专业游戏开发工厂 --- ## 1. 项目定义 ### 1.1 终极愿景 本项目的终极形态是： **AI Native 游戏开发工作站** 它面向游戏研发全流程，目标是在统一的项目空间中，逐步支持： * 2D 游戏资产生产 * 3D 资产与动画资产生产 * 音频与语音资产生产 * 配置与结构化内容生成 * 游戏设计与内容策划辅助 * 项目知识、工作流、技能模板的沉淀与复用 这个终极愿景成立的前提不是“一个模型做所有事”，而是： **用统一的 Agent 语义层、项目层和资产层，去编排多种不同范式的底层能力。** 也就是说，统一的是“用户入口”和“系统组织方式”，不是底层模型范式本身。 --- ### 1.2 当前阶段目标 当前阶段的第一个明确 milestone 是： **解决 2D 游戏资产的工程化生产问题** 并且只聚焦于其中最有价值、最能形成能力闭环的一部分，而不是一开始覆盖全部游戏研发任务。 EpeeKit 方案下，第一阶段的核心定义为： > 通过对话式 Agent + 受控工作流系统 + 资产管理系统，完成 2D 游戏资产的可控生成、编辑、一致性维护、训练沉淀与项目级复用。 --- ### 1.3 核心产品定位 本系统不是： * 单纯的聊天生图工具 * 单纯的节点工作流工具 * 单纯的模型管理平台 而是： **以 Agent 编排为核心的游戏资产生产系统** 它的本质是把： **自然语言需求 → 结构化任务 → 受控工作流 → 结果评估 → 资产沉淀** 串成一个稳定闭环。 --- ## 2. 核心设计原则 --- ### 2.1 统一语义层，不统一底层范式 系统要统一的是： * 用户表达方式 * 任务理解方式 * 资产组织方式 * 项目上下文 * 约束与复用方式 系统不追求统一的是： * 图像模型内部结构 * 3D 生成范式 * 音频生成范式 * 配置生成范式 这意味着未来扩展到 3D、动画、音频时，依然可以沿用同一个 Agent 和项目系统，但底层执行链路会不同。 --- ### 2.2 Agent 负责理解与编排，不直接“自由设计工作流” Agent 的职责是： * 理解意图 * 追问必要信息 * 选择模板 * 填充参数 * 解释结果 * 引导修改 Agent 不应直接拥有无限自由的工作流设计权。 否则系统会迅速陷入组合爆炸和不可维护状态。 所以，系统必须建立： * **任务中间层（Task IR）** * **工作流注册表（Pipeline Registry）** * **资产约束系统（Style / Character / Project Constraints）** Agent 的行为边界是： > 在受控模板和约束系统内进行选择、补全和编排，而不是任意发明执行逻辑。 --- ### 2.3 默认简单，逐层开放 系统应当对普通用户隐藏复杂度，但不能永久隐藏控制权。 因此产品必须支持三层使用模式： #### 模式 A：自然语言驱动 适合普通用户，用户只描述想要什么。 #### 模式 B：引导式修订 系统给出结果后，用户通过自然语言做精修，例如： * 头发颜色更冷一点 * 构图别那么满 * 表情更阴郁 * 武器做得更夸张 #### 模式 C：高级控制 在用户需要时，开放： * 参数面板 * 中间节点可见 * 控制图输入 * 模板选择/切换 * 高级实验模式 默认路径必须简单，但不是彻底黑盒。 --- ### 2.4 风格一致性不是单模型问题，而是资产系统问题 系统不应把风格一致性寄托于某一个模型“自动学会”。 EpeeKit 明确认为，风格一致性和角色一致性都必须由系统层共同实现： * 风格集 * 角色参考组 * 可选 LoRA * 结构控制 * 多候选评估 * 项目级约束 也就是说，一致性是“生成 + 约束 + 资产沉淀”的联合能力。 --- ### 2.5 第一阶段收敛，未来阶段扩张 EpeeKit 不再追求“第一版做万能平台”，而是明确采用： **阶段收敛、体系扩张** 第一阶段只验证 2D 资产的可控生产系统。 一旦核心中间层、模板系统、资产系统跑通，后续才向 3D、动画、音频扩展。 --- ## 3. 产品范围与阶段路线 --- ### 3.1 阶段划分 #### Phase 0：验证期 目标：用最少能力验证 Agent + 工作流 + 资产沉淀是否能形成闭环。 #### Phase 1：2D 资产生产系统 目标：形成可用的 2D 游戏资产生产系统。 #### Phase 2：角色一致性和项目风格系统强化 目标：将角色一致性、风格一致性、训练中心做成系统能力。 #### Phase 3：扩展到 3D / 动画 / 音频 / 配置 目标：沿用统一的 Agent 与项目层，扩展底层能力域。 --- ### 3.2 第一阶段建议聚焦范围 第一阶段不做所有 2D 资产，而是优先做这些： * 角色立绘（全身 / 半身 / 头像） * 道具 / 武器 / 图标 * 场景概念图 * 同角色多变体生成 * 风格 LoRA / 角色 LoRA 基础训练 这几类任务共同覆盖了： * 风格控制 * 结构控制 * 一致性需求 * 批量候选 * 训练复用 * 项目资产归档 是最适合形成闭环的一组任务。 --- ### 3.3 第一阶段暂不重点做的内容 * 复杂团队协作系统 * 多模型自由混编的高级实验系统 * 全类型 ControlNet 能力全集 * 文档/Skill 系统的完整产品化 * 3D / 动画 / 音频 * 自动一键完成整套游戏生产 这些都属于未来扩展方向，不应干扰第一阶段的产品收敛。 --- ## 4. 系统总架构 --- ### 4.1 总体架构 系统可以抽象为以下 7 层： 1. 用户交互层 2. Agent 语义层 3. 任务中间层（Task IR） 4. 工作流编排层 5. 模型执行层 6. 评估与质检层 7. 资产与项目层 --- ### 4.2 高层数据流 ```text 用户输入 → Agent理解与追问 → 生成 Task IR → 映射到 Pipeline Template → 填充参数与约束 → 执行生成 / 编辑 / 训练 → 评估与筛选 → 返回结果 → 沉淀到项目资产库 ``` --- ## 5. 关键中间层设计 这是 EpeeKit 最重要的部分。 --- ### 5.1 Task IR：任务中间层 Task IR 是系统的核心抽象层。 它的作用是把不稳定的自然语言请求，转成稳定、受控、可验证的任务描述。 Task IR 至少应包含以下字段： * task_type：任务大类 * asset_type：资源类型 * project_id：所属项目 * style_id：目标风格 * character_id：目标角色（可选） * consistency_level：一致性要求 * input_references：参考图集合 * structure_control_type：结构控制类型 * output_specs：尺寸、比例、透明背景等 * workflow_template_id：匹配到的模板 * generation_policy：批次、候选数、评估策略 * editable_flags：是否允许后续高级编辑 示例： ```json { "task_type": "asset_generation", "asset_type": "character_full_body", "project_id": "proj_x", "style_id": "anime_dark_fantasy_v1", "character_id": "char_001", "consistency_level": "high", "input_references": ["ref_a", "ref_b"], "structure_control_type": "pose", "output_specs": { "resolution": "1024x1536", "background": "transparent_optional" }, "workflow_template_id": "character_consistent_v1", "generation_policy": { "candidate_count": 4, "rerank": true } } ``` --- ### 5.2 Pipeline Registry：工作流注册表 系统不能允许无限自由组合工作流。 因此必须有一个注册表，所有可执行工作流都以模板方式注册。 每个模板应包含： * 模板 ID * 支持的任务类型 * 支持的输入字段 * 所需模型组件 * 默认参数范围 * 支持的约束 * 适用场景说明 * 成本级别 * 输出格式定义 例如： * character_base_v1 * character_consistent_v1 * item_icon_v1 * scene_concept_v1 * style_transfer_v1 * lora_training_style_v1 默认情况下，Agent 只能从注册表中选模板，而不能自己发明模板。 --- ### 5.3 Constraint Layer：约束层 约束层用于防止系统漂移。 它把“风格”“角色”“项目规范”变成系统级条件，而不是散落在 prompt 里的脆弱文本。 约束来源包括： * 项目约束 * 风格约束 * 角色约束 * 输出规范约束 * 成本与策略约束 例如： * 某项目只能使用指定风格集 * 某角色必须绑定参考组 * 某任务必须输出透明背景 * 某类任务默认限制候选数 * 某阶段不允许自由实验模式 这层会显著提升可控性。 --- ## 6. Agent 系统设计 --- ### 6.1 Agent 的职责 Agent 在 EpeeKit 中承担以下角色： * 对话理解器 * 任务拆解器 * 缺失信息追问器 * 模板选择器 * 参数填充器 * 修改解释器 * 项目上下文读取器 --- ### 6.2 Agent 不应直接承担的职责 Agent 不应： * 自由生成任意工作流图 * 直接产生不受控参数全集 * 代替所有图像评估逻辑 * 代替项目约束系统 * 代替用户的最终审美判断 Agent 是“编排核心”，不是“唯一智能体”。 --- ### 6.3 Agent 的三段式执行逻辑 #### 第一步：意图分类 判断任务属于哪一类： * 新建角色 * 生成变体 * 修图 * 风格迁移 * 训练 LoRA * 批量导出 #### 第二步：结构化填充 将用户输入填入 Task IR。 #### 第三步：模板匹配与执行策略选择 根据任务类型、项目约束、成本策略，选择合适模板。 --- ### 6.4 修改闭环设计 用户通常不会说参数，只会说感受。 所以系统要支持“自然语言修改闭环”。 例如用户说： * 脸还是不够像之前那个角色 * 武器太普通 * 颜色更偏冷色 * 构图留白多一点 系统需要将这些转为： * 角色参考权重增强 * 风格强度提高 * 光照与色温调节 * 构图相关约束调整 这层是 EpeeKit 必须具备的，不然用户会在第一轮结果后流失。 --- ## 7. 模型执行层设计 --- ### 7.1 总体策略：双栈路线 EpeeKit 建议采用双栈路线，而不是单押一种底模。 #### 主力工程栈 适合可控、成熟、工程化能力强的任务。 #### 高质量增强栈 适合质量更高、复杂度更高的任务。 这样做的目的不是炫技，而是兼顾： * 稳定性 * 可控性 * 生态成熟度 * 质量上限 --- ### 7.2 第一阶段建议执行栈 #### 主执行栈 * SDXL 系列为主 * 参考图风格注入 * ControlNet * img2img / inpaint * LoRA 加载 * 批量候选生成 #### 增强栈 * 更高质量的图像模型作为后续增强路线 * 用于高质量角色图、复杂编辑或特定高价值任务 --- ### 7.3 工作流执行引擎 建议将工作流执行层与业务后端解耦。 可以采用： * 一个适合复杂节点编排和快速试验的执行引擎作为主工作流引擎 * 同时为未来服务化保留标准化 Python / API 管线 这样可以兼顾： * 快速实验 * 模板沉淀 * 后续服务化 --- ## 8. 风格一致性与角色一致性系统 这是 EpeeKit 的核心壁垒之一。 --- ### 8.1 真实能力边界 必须非常客观地说： #### 当前 AI 可以较稳定做到的 * 风格层面的一致 * 颜色体系和材质倾向一致 * 同一项目下相似视觉语言 #### 当前 AI 可以中等程度做到的 * 同一角色的相似脸部 * 同一角色的服装和关键符号保留 * 同一角色的有限变体 #### 当前 AI 很难天然做到的 * 任意角度下完全统一的角色身份 * 任意姿态和复杂场景下完全稳定的角色 * 像 3D rig 那样严格的一致性 所以系统必须承认现实边界，采用工程组合策略，而不是幻想靠单一模型解决。 --- ### 8.2 一致性系统的三层结构 #### A. Style Layer：风格层 定义项目风格，不建议仅靠 prompt 文字描述。 组成包括： * 风格 ID * 风格参考集 * 可选风格 LoRA * 风格 embedding * 风格描述元数据 #### B. Character Layer：角色层 定义项目中的角色身份。 组成包括： * 角色 ID * 角色参考组 * 角色描述元数据 * 可选角色 LoRA * 角色关键视觉要素 #### C. Constraint Layer：约束层 规定生成任务必须使用哪些风格和角色资源，以及允许偏移的范围。 --- ### 8.3 风格集和角色参考组怎么做 #### 风格集 不要用单张图定义风格。 应使用一个风格参考集，至少包含若干能代表该风格核心特征的图。 作用： * 让风格定义更稳 * 避免单图偏差 * 为评估层提供参考 #### 角色参考组 角色不能只绑定一张正面图。 建议包含： * 正面 * 半侧面 * 半身 * 表情变化 * 关键服饰细节 作用： * 提供更稳定的角色身份锚点 * 为一致性生成提供多参考依据 --- ### 8.4 一致性生成策略 角色或风格一致性任务应优先使用组合策略： * 角色参考组 * 风格参考组 * 可选 LoRA * 结构控制 * 多候选生成 * 自动筛选 * 必要时局部修补 不要把一致性问题只交给 prompt。 --- ## 9. ControlNet、参考图和编辑系统 --- ### 9.1 ControlNet 的定位 EpeeKit 中，ControlNet 更偏内部控制能力，而不是用户直接面对的核心产品对象。 用户不需要理解所有 ControlNet 类型。 系统应根据任务自动选择适当的结构控制方式。 例如： * 人物姿态类任务：优先 pose * 轮廓与结构锁定：优先 canny / line * 局部构图控制：通过图生图或局部编辑完成 第一阶段不应追求支持所有控制类型，而应只保留最有价值的少数几类。 --- ### 9.2 图生图与局部编辑 图生图和局部编辑在系统中非常关键，因为它们决定了： * 第一轮生成结果不满意时是否能延续修改 * 是否能在不重来的前提下保住已有价值 * 是否能形成真正的“生产”而不是“重抽奖” 因此 EpeeKit 必须支持： * 基础 img2img * 局部 inpaint * 遮罩上传或自动生成 * 结果版本回溯 --- ## 10. 训练中心设计 --- ### 10.1 训练中心不是“附属功能”，而是沉淀系统能力的核心 训练中心的意义在于让系统逐渐具备： * 项目专属风格 * 角色专属视觉身份 * 更高的一致性和复用能力 所以训练中心必须是产品化模块，不是裸露的训练入口。 --- ### 10.2 第一阶段建议支持的训练类型 * 风格 LoRA * 角色 LoRA 第一阶段不建议铺开太多训练类型。 --- ### 10.3 训练中心应包含的功能 * 批量上传参考图 * 项目归属绑定 * 自动去重 * 自动质量检查 * 基础数据清洗建议 * 训练模板选择 * 训练任务排队 * 训练状态监控 * 训练结果对比预览 * 模型版本管理 * 回滚与弃用机制 --- ### 10.4 自动化边界 用户应尽量以“选图”为主，而不是理解训练细节。 但系统不宜在第一版完全黑盒自动训练。 更合理的是： #### 第一阶段 半自动： * 系统自动检查 * 用户最终确认训练集和目标 #### 第二阶段 增强自动化： * 自动风格聚类 * 自动样本筛选 * 自动参数推荐 * 自动评估报告 --- ## 11. 评估与质检层 --- ### 11.1 为什么必须有评估层 如果没有评估层，系统就只是自动点生成按钮。 评估层的作用是： * 从多张候选图中筛出更优结果 * 检测风格偏移 * 检测角色偏移 * 减少人工挑图成本 * 为训练和模板优化积累反馈数据 --- ### 11.2 评估层组成 评估层建议包括： #### A. 语义匹配评分 评估结果是否符合任务目标。 #### B. 风格相似度评分 与风格参考集进行相似度计算。 #### C. 角色一致性评分 与角色参考组进行一致性评估。 #### D. 规则检查 例如： * 人脸异常 * 手部异常 * 边缘问题 * 构图越界 * 背景不符合规范 * 透明背景是否正确 #### E. 人工确认 最终审美结论仍需要人参与，尤其在高价值资产场景。 --- ### 11.3 评估层的产品作用 评估层不是只给用户看分数，而是用来支持： * 自动 rerank * 自动重试策略 * 模板优化 * 训练效果比较 * 项目质量控制 --- ## 12. 项目与资产系统 --- ### 12.1 项目是系统最重要的组织单位 用户的核心工作对象不应是“单次会话”，而应是“项目”。 每个项目中应包含： * 风格系统 * 角色系统 * 资源历史 * 模板集合 * 训练模型 * 参考库 * 输出规范 * 任务记录 --- ### 12.2 资产类型 项目资产至少包括： * 原始参考图 * 风格集 * 角色参考组 * 生成结果图 * 编辑结果图 * 控制图 * 遮罩图 * LoRA 模型 * 任务记录 * 模板副本 --- ### 12.3 项目模板机制 系统内模板应分成两类： #### 平台官方模板 经过验证、默认推荐、参数范围受控。 #### 项目自定义模板 从官方模板 fork 后形成，允许项目内部沉淀自己的生产路线。 这解决了“既要收敛，又要可扩展”的矛盾。 --- ## 13. 用户体验设计 --- ### 13.1 用户主路径 第一阶段的理想体验应是： 1. 用户创建项目 2. 选择或建立风格 3. 创建角色或导入参考 4. 通过对话描述需求 5. 系统自动匹配模板并生成候选 6. 用户选图或自然语言修改 7. 结果沉淀为项目资产 8. 后续继续派生使用 --- ### 13.2 三层交互界面 #### 层 1：对话界面 面向大多数用户。 #### 层 2：任务说明卡 向用户展示系统理解到的内容，例如： * 当前任务类型 * 风格 * 角色 * 输出规格 * 使用的模板 #### 层 3：高级面板 用于： * 选择控制图 * 查看候选参数 * 编辑模板 * 进入实验模式 这样可以避免纯黑盒的不信任感。 --- ## 14. 技术实现建议 --- ### 14.1 后端 建议使用 Python 为主的服务栈，负责： * Agent 调度 * 任务中间层处理 * 模板匹配 * 任务排队 * 训练任务管理 * 资产元数据管理 需要具备： * 标准 API 层 * 异步任务队列 * 数据库 * 对象存储 * 缓存系统 --- ### 14.2 工作流执行层 建议将复杂工作流引擎独立成执行层服务。 业务层只通过模板和参数调用，不直接耦合节点细节。 这样做的好处是： * 易于替换模型 * 易于扩展新 pipeline * 易于控制权限和版本 --- ### 14.3 前端 建议采用项目工作台形态，而不是纯聊天形态。 基本结构可以是： * 左侧：项目与资产 * 中间：对话与任务区 * 右侧：结果、候选、编辑和高级面板 --- ## 15. 风险与应对 --- ### 15.1 风险一：产品野心过大导致失焦 #### 风险 想同时做 2D、3D、动画、音频、策划，导致第一阶段无法落地。 #### 对策 坚持阶段化路线，第一阶段只验证 2D 资产生产闭环。 --- ### 15.2 风险二：Agent 失控 #### 风险 LLM 直接输出不稳定工作流与参数。 #### 对策 使用： * Task IR * 模板注册表 * 强 schema * 校验器 * 项目约束 --- ### 15.3 风险三：一致性效果被高估 #### 风险 误以为单模型可以稳定解决风格和角色一致性。 #### 对策 明确采用系统级组合策略： * 风格集 * 角色参考组 * 结构控制 * 可选 LoRA * 自动筛选 * 局部修补 --- ### 15.4 风险四：训练质量不稳定 #### 风险 用户上传垃圾数据导致 LoRA 训练无效。 #### 对策 训练中心产品化，加入数据检查、模板、预览、版本管理。 --- ### 15.5 风险五：工作流数量爆炸 #### 风险 自由组合导致不可维护。 #### 对策 默认只允许模板化使用。 实验模式单独隔离。 --- ### 15.6 风险六：成本失控 #### 风险 多轮生成、自动重试、训练任务导致资源占用过高。 #### 对策 即使短期不以盈利为目标，也要以可持续为前提。 应建立： * 候选数上限 * 成本等级 * 模板成本标签 * 项目资源策略 * 任务缓存与复用策略 --- ## 16. 第一阶段的最小成功闭环 EpeeKit 认为第一阶段最值得追求的不是“功能多”，而是一个强闭环。 建议定义为： > 用户在项目内，通过自然语言创建一个 2D 角色；系统生成若干候选；用户通过自然语言继续修改；系统保持风格和角色一致性；最终导出角色相关资源并沉淀到项目资产库。 这个闭环至少要包含： * 项目空间 * 风格选择 * 角色定义 * 对话生成 * 候选筛选 * 自然语言修改 * 结果沉淀 * 可复用派生 如果这个闭环做得足够好，系统就具备生命力。 --- ## 17. EpeeKit 最终结论 这套方案的本质，不是做一个“更会聊天的生图工具”，而是建立一种新的研发范式： **用 Agent 作为统一语义入口，用模板化工作流作为执行骨架，用项目与资产系统作为长期记忆和约束，从而把 AI 资产生产从“临时创作”推进到“工程化生产”。** 它的关键不在于某一个模型，而在于三件事是否成立： * **Task IR** * **Pipeline Registry** * **Project / Style / Character Asset System** 只要这三者成立，系统就不会只是一个 demo，而会逐步变成真正可扩展的游戏资产生产平台。