21 KiB
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 层：
- 用户交互层
- Agent 语义层
- 任务中间层（Task IR）
- 工作流编排层
- 模型执行层
- 评估与质检层
- 资产与项目层
4.2 高层数据流
用户输入
→ 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：是否允许后续高级编辑
示例：
{
"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 用户主路径
第一阶段的理想体验应是：
- 用户创建项目
- 选择或建立风格
- 创建角色或导入参考
- 通过对话描述需求
- 系统自动匹配模板并生成候选
- 用户选图或自然语言修改
- 结果沉淀为项目资产
- 后续继续派生使用
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，而会逐步变成真正可扩展的游戏资产生产平台。