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

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多开发者刚开始做鸿蒙游戏时，项目结构通常是这样的：

Page ↓ State ↓ UI

例如：

@Statehp:number=100Button("攻击").onClick(()=>{this.hp-=10})

Demo 阶段完全没问题，甚至：

小游戏 休闲游戏 活动页游戏

都能顺利开发，但随着项目规模增长：

背包系统 战斗系统 技能系统 AI系统 任务系统

不断增加，代码开始变成：

UI修改状态 状态触发逻辑 逻辑修改UI

最终形成：

页面 = 系统 系统 = 页面

高度耦合，此时会出现几个典型问题：

功能越来越难加 Bug越来越难查 多人协作越来越困难 性能越来越差

所以大型游戏项目最终都会走向：

Store ↓ System ↓ Engine ↓ Agent

形成完整 Runtime，今天我们从实际开发角度聊聊：

为什么鸿蒙游戏一定会从 Store 演化到 Agent 架构。

一、第一阶段：UI驱动架构

很多项目初期：

@Stategold:number=1000Button("购买").onClick(()=>{this.gold-=100})

问题在哪？因为：

UI负责展示 UI负责业务 UI负责状态

全部混在一起。当页面变多：

ShopPage BattlePage MissionPage

同一个状态：

金币

可能被多个页面修改。最终：

无法追踪数据来源

这是最早期的架构问题。

二、Store：统一状态中心

解决方案就是：

Store

统一管理状态，例如：

exportclassPlayerStore{gold:number=1000level:number=1}

页面只负责：

Text(`${store.gold}`)

修改统一进入：

store.addGold(100)

此时数据流变成：

UI ↓ Store ↓ UI

优势：

状态统一 数据可追踪 方便调试

但新的问题又出现了。

三、为什么Store还不够？

很多团队做到 Store 后，会继续这样写：

store.player.hp-=20if(store.player.hp<=0){gameOver()}

逻辑依然散落各处，例如：

BattlePage MissionPage SkillPage

都在修改状态，这时候：

Store管理数据 但没人管理规则

于是出现：

同一个伤害 多个地方计算

最终导致：

规则不一致

四、System：业务规则中心

这也是现代游戏架构的核心思想。

不要：

页面写规则

而要：

System写规则

例如：

classBattleSystem{attack(attacker:Unit,target:Unit){constdamage=attacker.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

正确：

constaction=agent.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 架构时代”。