从Store到Agent：鸿蒙游戏逻辑与渲染分层架构设计

网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、第一阶段UI驱动架构二、Store统一状态中心三、为什么Store还不够四、System业务规则中心五、Engine统一调度系统六、逻辑层与渲染层彻底分离七、Agent出现以后发生了什么八、AISystem架构设计九、Action驱动架构十、鸿蒙游戏Agent Runtime十一、实战项目推荐目录结构总结引言很多开发者刚开始做鸿蒙游戏时项目结构通常是这样的Page ↓ State ↓ UI例如Statehp:number100Button(攻击).onClick((){this.hp-10})Demo 阶段完全没问题甚至小游戏 休闲游戏 活动页游戏都能顺利开发但随着项目规模增长背包系统 战斗系统 技能系统 AI系统 任务系统不断增加代码开始变成UI修改状态 状态触发逻辑 逻辑修改UI最终形成页面 系统 系统 页面高度耦合此时会出现几个典型问题功能越来越难加 Bug越来越难查 多人协作越来越困难 性能越来越差所以大型游戏项目最终都会走向Store ↓ System ↓ Engine ↓ Agent形成完整 Runtime今天我们从实际开发角度聊聊为什么鸿蒙游戏一定会从 Store 演化到 Agent 架构。一、第一阶段UI驱动架构很多项目初期Stategold:number1000Button(购买).onClick((){this.gold-100})问题在哪因为UI负责展示 UI负责业务 UI负责状态全部混在一起。当页面变多ShopPage BattlePage MissionPage同一个状态金币可能被多个页面修改。最终无法追踪数据来源这是最早期的架构问题。二、Store统一状态中心解决方案就是Store统一管理状态例如exportclassPlayerStore{gold:number1000level:number1}页面只负责Text(${store.gold})修改统一进入store.addGold(100)此时数据流变成UI ↓ Store ↓ UI优势状态统一 数据可追踪 方便调试但新的问题又出现了。三、为什么Store还不够很多团队做到 Store 后会继续这样写store.player.hp-20if(store.player.hp0){gameOver()}逻辑依然散落各处例如BattlePage MissionPage SkillPage都在修改状态这时候Store管理数据 但没人管理规则于是出现同一个伤害 多个地方计算最终导致规则不一致四、System业务规则中心这也是现代游戏架构的核心思想。不要页面写规则而要System写规则例如classBattleSystem{attack(attacker:Unit,target:Unit){constdamageattacker.attack-target.defense target.hp-damage}}此时Store 负责状态 System 负责规则职责开始明确数据流UI ↓ System ↓ Store ↓ UI五、Engine统一调度系统当系统越来越多BattleSystem SkillSystem MissionSystem AISystem新的问题出现谁决定执行顺序例如攻击 ↓ 扣血 ↓ 死亡判定 ↓ 任务更新如果顺序错误Bug立即出现因此需要Game Engine统一调度例如classGameEngine{update(){battleSystem.update()missionSystem.update()aiSystem.update()}}形成Engine ↓ System ↓ Store架构。六、逻辑层与渲染层彻底分离这里是很多鸿蒙项目最大的架构升级。错误写法battleSystem.attack()Text(${player.hp})逻辑直接依赖 UI问题无法复用 无法测试 无法迁移正确做法Logic Runtime Render Runtime分离逻辑层battleSystem.attack()只修改store.player.hp渲染层Text(${store.player.hp})只负责展示此时逻辑不知道UI UI不知道逻辑完全解耦。七、Agent出现以后发生了什么传统游戏玩家产生行为驱动世界例如点击攻击 ↓ 执行攻击但 Agent 游戏不同行为来源开始增加玩家 NPC Agent 自动系统例如NPC决定巡逻 NPC决定对话 NPC决定攻击这些行为不再来自Button点击而来自Agent Decision八、AISystem架构设计Agent不能直接修改Store这是很多项目最容易踩的坑。错误agent.run()store.hp-20正确constactionagent.decide()engine.dispatch(action)统一进入Action Queue例如{type:ATTACK,target:1001}然后Engine ↓ BattleSystem ↓ Store执行这样玩家行为 Agent行为 脚本行为全部统一。九、Action驱动架构到了 Agent 阶段项目通常会引入Action机制例如interfaceAction{type:stringpayload:any}所有状态变化必须由Action触发例如dispatch({type:PLAYER_ATTACK})而不是store.hp-10直接修改优势行为可追踪 支持回放 支持录像 支持同步这也是大型游戏常用方案。十、鸿蒙游戏Agent Runtime最终形成如下结构Agent │ Agent Runtime │ Action │ Engine │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ BattleSystem SkillSystem MissionSystem │ Store │ ArkUI Render这里Agent负责行为生成System负责规则执行Store负责状态管理ArkUI负责界面渲染形成完整闭环。十一、实战项目推荐目录结构src ├── engine │ ├── GameEngine.ts │ ├── ActionQueue.ts │ ├── store │ ├── PlayerStore.ts │ ├── BattleStore.ts │ ├── systems │ ├── BattleSystem.ts │ ├── SkillSystem.ts │ ├── MissionSystem.ts │ ├── agent │ ├── AgentRuntime.ts │ ├── NPCPlanner.ts │ ├── ui │ ├── BattlePage.ets │ ├── MainPage.ets这样业务逻辑 运行时 状态管理 界面渲染完全独立。总结很多鸿蒙游戏项目后期出现的问题。本质不是ArkUI不够强而是架构没有分层从技术演进角度看UI驱动 ↓ Store ↓ System ↓ Engine ↓ Action ↓ Agent Runtime这是现代游戏架构的自然演进路径。未来随着AI NPC World Model Agent Game不断普及真正驱动游戏世界运行的已经不再是页面而是Store System Agent Runtime这也意味着鸿蒙游戏开发正在从“页面开发时代”逐渐进入“Runtime 架构时代”。