网罗开发 （小红书、快手、视频号同名）

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

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

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

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

引言

如果你做过游戏开发，无论是：

• Unity
• Unreal
• Cocos
• HarmonyOS Game

大概率都见过类似架构：

Scene
 ↓
GameObject
 ↓
Component
 ↓
System

甚至很多游戏项目的目录结构都是这样：

Game
 ├─ Scene
 ├─ Entity
 ├─ UI
 ├─ Resource
 └─ Manager

过去二十年，这种架构几乎统治了整个游戏行业。因为当时游戏引擎最重要的任务只有一个：

如何高效渲染世界。

因此：

Scene

天然成为整个游戏的核心。

玩家进入场景：

加载资源
初始化对象
启动逻辑

玩家离开场景：

释放资源
销毁对象
停止逻辑

一切都围绕 Scene 运转，这种模式在过去非常成功。但今天，随着：

• 大模型
• Agent NPC
• World Model
• AI 剧情生成

开始进入游戏行业，越来越多团队发现：

Scene 架构开始出现天花板。

一、Scene 为什么统治了二十年

理解未来之前，先理解过去。传统游戏运行流程：

Player
   ↓
Input
   ↓
Scene
   ↓
Object
   ↓
Render

例如，一个 RPG 游戏：

主城
副本
竞技场
野外地图

本质都是：

Scene Container

即：

场景容器

所有内容都放进去：

NPC
任务
怪物
建筑
UI

例如：

class CityScene {

    npcs: NPC[]

    quests: Quest[]

    buildings: Building[]

}

Scene 既是：

资源容器

也是：

逻辑容器

这种架构最大的优点是：

简单

但简单往往意味着：

边界明显

而 AI 游戏恰恰在打破这些边界。

二、AI NPC 为什么会摧毁传统 Scene 架构

过去的 NPC 本质是什么？答案很简单：

脚本

例如：

if(playerDistance < 5) {

    sayHello()

}

或者：

if(questCompleted) {

    rewardPlayer()

}

所有行为都是：

事件驱动

NPC 本身没有真正的状态，更没有长期记忆。但 Agent NPC 不一样，未来 NPC 很可能拥有：

Memory
Goal
Plan
Relationship
Skill

例如：

class AgentNPC {

    memoryStore: MemoryStore

    goals: Goal[]

    plans: Plan[]

    socialGraph: Graph

}

此时 NPC 已经不是：

场景对象

而是：

运行时实体

即：

Runtime Entity

这是整个架构变化的起点。

三、真正的问题：世界不应该因为玩家离开而停止

这是传统架构最大的漏洞。例如，玩家离开主城：

Scene Unload

那么：

商人停止交易

士兵停止巡逻

农民停止生产

市场停止变化

所有逻辑被冻结，这是因为：

Scene
=
生命周期边界

而未来 AI 游戏最大的特点恰恰是：

世界应该持续运行

例如，玩家下线 3 天，再次登录。系统告诉你：

北方王国发动战争

铁矿价格上涨 35%

商会扩大了经营范围

两个 NPC 已经结婚

注意，这里发生的所有事情：

玩家都没有参与

但世界依然在运转。这时候：

Scene

已经无法承载这种模型。

四、从 Scene Runtime 到 World Runtime

很多团队开始意识到，真正需要长期存在的不是 Scene。

而是：

World State

例如：

interface WorldState {

    economy: EconomyState

    weather: WeatherState

    military: MilitaryState

    diplomacy: DiplomacyState

}

这些状态：

不属于任何场景

却决定整个游戏世界，于是越来越多新游戏开始出现 World Runtime 架构。

核心思想：

世界持续运行

场景只是投影

即：

World
 ↓
Scene

而不是：

Scene
 ↓
World

这是一次非常重要的架构反转。

五、为什么 World Runtime 还不够

很多开发者看到这里会认为：

World Runtime

已经解决问题了，实际上还没有。因为未来游戏不仅有世界，还有：

任务
目标
上下文
Agent

举个例子，玩家正在经营一个王国。此时：

建设城市

发展经济

训练军队

扩张领土

这些行为实际上构成：

当前工作空间

即：

Game Workspace

六、Workspace Runtime 才是下一代游戏核心

很多人第一次看到 Workspace 会觉得：

不就是存档吗？

其实完全不是，存档记录的是：

过去

Workspace 维护的是：

现在

例如：

interface GameWorkspace {

    activeTasks: Task[]

    activeAgents: Agent[]

    activeContext: Context

    currentGoal: Goal

}

它记录：

玩家正在做什么

Agent 正在做什么

世界正在做什么

这才是真正的运行时。

七、Agent Runtime 如何接管游戏系统

传统任务系统：

策划配置
      ↓
玩家触发
      ↓
任务完成

未来任务系统：

Agent发现问题
      ↓
生成任务
      ↓
寻找执行者
      ↓
推动世界变化

例如，世界模型检测：

粮食短缺

Agent Runtime 自动创建：

粮食运输任务

随后：

商人Agent接单

护卫Agent护送

农民Agent扩产

整个流程无需脚本配置。

八、鸿蒙为什么特别适合这种架构

这是最有意思的部分，因为鸿蒙天生拥有：

分布式软总线

以及：

跨设备状态同步

未来游戏可能变成：

手机
 ↓
创建王国

PC
 ↓
管理经济

平板
 ↓
查看战争地图

迁移的不是：

页面

而是：

Workspace Runtime

例如：

workspace.transfer(deviceId)

切换设备后：

任务继续

世界继续

Agent继续

这其实已经超出了传统手游的范畴。

九、未来游戏引擎会变成什么样

过去二十年，游戏引擎关注：

Render Pipeline

未来十年，游戏引擎关注：

Runtime Pipeline

可能形成这样的架构：

Workspace Runtime
          ↓
World Runtime
          ↓
Agent Runtime
          ↓
Game System
          ↓
Render System

注意：

Render

第一次不再位于最顶层，因为未来最重要的问题已经不是：

如何显示世界

而是：

如何运行世界

总结

过去二十年，游戏行业一直在解决：

如何让世界看起来更真实。

未来十年，游戏行业将开始解决：

如何让世界真正活起来。

从架构角度看，过去：

Scene
 ↓
Object
 ↓
Render

未来：

Workspace
 ↓
World Runtime
 ↓
Agent Runtime
 ↓
Render

这不仅仅是一次技术升级，而是一次游戏架构范式的变化。

当 Agent 开始接管 NPC、当 Workspace 开始管理世界状态、当 Runtime 开始驱动任务流。真正的下一代鸿蒙游戏，可能已经不再是一个“场景集合”。

而是一个：

持续运行的智能世界。