從 CompilableWorld Runtime 到世界狀態機：現況盤點與演化邊界

系列： 動態通用世界狀態機：內部架構與演化規格
篇次： 01 / 07
版本： v0.1
日期： 2026-08-01
性質： 內部技術白皮書／工程接手基準
基準 Repository： kakon77777-commits/compilableworld-runtime-mvp
基準 Runtime： CompilableWorld Runtime MVP v0.1.1

摘要

本文件不重新發明一套世界狀態機，而是先盤點目前 CompilableWorld Runtime 已經完成的能力，回答兩個問題：

哪些部分已經具有「通用世界狀態 Runtime」的雛形？
哪些部分仍然是遊戲 Domain，應繼續留在 Game Runtime 中演化？

目前 Repository 已經具備 Authoring Layer、Compiled Runtime Package、Entity Registry、State Store、ActionIR、StateDelta、EventIR、ModuleContract、EventBus、Scheduler、Snapshot、Replay、Projection、FunctionIR、ScenarioIR、Studio migration、AMK evidence layer 與 read-only MCP projection 等結構。它已經超過一般單一 FSM，也不再只是傳統 MUD command engine。

其中最重要的現況是：StateStore、ActionIR、StateDelta、EventIR、ModuleContract、Scheduler 與 Kernel commit pipeline 本身並未被遊戲語義完全綁死；真正明顯的遊戲專用內容主要集中於 Player 建立流程、Combat／Quest／Inventory／Magic／Dialogue 等 Module、遊戲 Authoring Schema 與具體世界內容。

因此後續正確路線不是：

\text{Game Runtime} \rightarrow \text{全部推翻} \rightarrow \text{Universal Runtime}

而是：

\boxed{ \text{完成 Game World-State Runtime} \rightarrow \text{保留為 Executable Reference World} \rightarrow \text{逐步抽取可泛化 Core} }

本篇的主要作用，就是把這條演化邊界釘死。

1. 現況：目前 CompilableWorld 已經不是普通 FSM

傳統有限狀態機可以表示為：

q_{t+1}=\delta(q_t,e_t)

它主要回答：

某個有限離散狀態收到事件後，應轉移到哪個下一狀態？

目前 CompilableWorld 更接近：

W_{t+1} = F( W_t, A_t, E_t, T_t, P_t )

其中：

$W_t$ ：當前 Runtime 世界狀態；
$A_t$ ：正規化行動；
$E_t$ ：事件與因果歷史；
$T_t$ ：Scheduler 與時間；
$P_t$ ：權限、版本與執行約束。

現有架構流程已經形成：

JSON / CSV / Manifest
        ↓ compiler + validators
Runtime Package
        ↓ loader
World Kernel
        ↓ ActionIR
MSSP Module
        ↓ StateDelta + EventIR
Atomic Commit / Event Log / Projection

所以真正核心已經是：

\boxed{ \text{State Runtime} + \text{Transition Providers} + \text{Event Causality} + \text{Execution Governance} }

這比「大量 FSM 拼在一起」更接近真正世界狀態 Runtime 的定義。

2. 現有真相來源已經被刻意分層

目前 AGENTS.md 的第一條核心不變量就是：

Authoring Layer、Compiled Package、Runtime State 不可混為同一真實來源。

形式化為：

\boxed{ W_{\mathrm{author}} \neq W_{\mathrm{compiled}} \neq W_{\mathrm{runtime}} }

三者分工如下。

2.1 Authoring Layer

負責：

JSON／CSV／Manifest；
functions.json；
scenarios.json；
Studio World IR；
mapping；
人工與 Agent 可編輯世界來源。

它代表「世界如何被定義」，不是目前正在運行中的真實狀態。

2.2 Compiled Runtime Package

負責：

已驗證的 entities／rooms／exits／items；
quest transitions；
narrative overlays；
FunctionIR；
ScenarioIR；
player templates；
schema contract IDs。

它是：

\boxed{ \text{Executable World Definition} }

2.3 Runtime State

由 StateStore 與 Kernel 維護。

它回答：

此 Runtime instance 現在到底發生了什麼？

這三層分離是未來自適應生成、通用化與多 Domain 共存時最重要的基礎之一，不得被破壞。

3. StateStore：目前最接近 Domain-Neutral Core 的元件

現有 StateStore 使用：

owner :: namespace :: key

形成 state path。

最小狀態單元為：

StateCell
  value
  version

因此 Kernel 本身不需要理解：

HP；
MP；
Quest；
Door；
Battery；
Temperature；
Robot Pose。

它只知道：

x= ( owner, namespace, key, value, version )

這一點非常重要。

它表示「遊戲內容」並沒有被硬寫進最底層狀態模型。

現階段應把 StateStore 視為：

\boxed{ \text{Candidate General State Substrate} }

而不是急著改寫。

4. StateDelta：世界變化不是任意寫入，而是受治理的提案

目前 Module 不應直接修改 StateStore。

Module 必須產生 StateDelta，包含：

owner；
namespace；
key；
operation；
value；
expected_version；
source_module。

Kernel 再依 ModuleContract.write 驗證是否合法。

因此：

\boxed{ \text{Module} \rightarrow \text{StateDelta} \rightarrow \text{Kernel Validation} \rightarrow \text{Atomic Commit} }

而不是：

\text{Module} \rightarrow \text{Direct State Mutation}

這是未來通用 Runtime 最應保留的核心之一。

因為無論未來 Domain 是遊戲、機器人、智慧房間或其他系統，只要都必須經過：

\text{Proposal} \rightarrow \text{Validation} \rightarrow \text{Commit}

就能持續維持可觀測、可測試、可回放的世界變化。

5. ActionIR：不同入口共用的行動邊界

目前 ActionIR 主要包含：

actor_id
verb
target_id
args
action_id
correlation_id
status
authority
proposed_at_tick

這些欄位沒有把 attack、cast、talk、move 寫死進模型。

那些只是 Module 所註冊的 verb。

因此可抽象為：

A_t= ( actor, verb, target, args, authority, correlation )

未來：

CLI；
Web；
AI；
MCP；
Robot Adapter；
Tool Adapter；

都可以產生相同形式的 Action。

現有 AGENTS.md 已明確禁止：

UI、Intent Parser 與 AI Adapter 直接修改 StateStore。

所以長期不變量應是：

\boxed{ \text{External Intent} \rightarrow \text{ActionIR} \rightarrow \text{Kernel} }

而不是讓每一種入口都建立自己的寫入旁路。

6. EventIR：世界的因果歷史已經有正式雛形

目前 EventIR 包含：

event_type
source
payload
target
event_id
causation_id
correlation_id
timestamp_tick
visibility
authority
version

因此它已經不是普通 log message。

可以形式化為：

E= ( id, type, source, target, cause, correlation, time, visibility, authority, payload )

它同時被用於：

EventBus；
EventLog；
module reaction；
trace；
replay；
MCP projection；
AMK evidence capture。

目前跨模組協作也已被規定透過 Event，而不是直接呼叫其他模組的 private method。

因此 EventIR 可以視為：

\boxed{ \text{World Causality Exchange Primitive} }

這也是後續世界狀態機真正能擴張的重要原因。

7. ModuleContract：真正重要的是權限邊界，而不是模組名稱

ModuleContract 目前描述：

module_id；
version；
layer；
actions；
events；
read；
write；
requires_kernel。

目前已經真正強制：

\text{write scope}

但 Repository 也明確記錄：

generalized read-scope 與 action-authority isolation 尚未完整。

因此目前狀態應分成：

已完成

\boxed{ \text{Write Authority Enforcement} }

尚未完成

\boxed{ \text{Read Authority Enforcement} + \text{Action Authority Isolation} }

這兩項不是「等通用版再做」。

它們應該先在 Game World-State Runtime v0.2 裡完成。

因為遊戲本身已經足以提供可靠測試場。

8. Scheduler：目前已有時間，但還不是完整 World Time

Scheduler 已經支援：

tick；
delayed Action；
due tick；
queue；
snapshot persistence。

因此至少已經有：

A_t \xrightarrow{\Delta t} A_{t+\Delta t}

但尚未形成完整 Temporal Runtime，例如：

repeating schedule；
cancellation tree；
temporal dependency；
time window；
world calendar；
cross-layer scheduled transition。

後面應逐步把 Scheduler 升格為：

\boxed{ \text{World Time Substrate} }

而不是只視為「延遲執行 command 的工具」。

9. Snapshot + Event Log + Replay：已形成「現在＋歷史」雙軌

目前 Runtime 已經可以：

save snapshot；
load snapshot；
保存 scheduler；
保存 dynamic entities；
replay committed state deltas。

因此目前架構不是純 Event Sourcing，也不是純 Snapshot。

它更接近：

\boxed{ \text{Materialized Current State} + \text{Causal Event History} }

這是合理的。

後續不應為追求架構純粹而要求：

所有世界都必須從 Genesis Event 重播。

真正需要補的是：

\boxed{ \text{Cross-Version Replay Migration} }

也就是當：

Runtime_{v1} \rightarrow Runtime_{v2}

時，舊 Snapshot／EventIR 如何被顯式 migration，而不是默默失效。

10. FunctionIR：純計算與世界變化已被正確拆開

現有 FunctionIR 有幾個很好的限制：

只允許受限 numeric expression tree；
不允許任意 Python；
無 I/O；
不直接寫 state；
deterministic；
cache 可重建、不進 snapshot。

因此：

\boxed{ \text{Pure Calculation} \neq \text{World Mutation} }

這條分界應長期保留。

未來無論新增：

遊戲公式；
機器人功耗估算；
智慧房間舒適度；
任務權重；

只要是純函數，都不應自動取得世界狀態修改權。

11. ScenarioIR：未來生成式約束的測試基底已經存在

ScenarioIR 目前採：

\text{Given} \rightarrow \text{When} \rightarrow \text{Then}

而 when 仍走正常：

\text{ActionIR} \rightarrow \text{Kernel} \rightarrow \text{EventIR}

管線。

Scenario 不能偷偷形成第二套 rules engine。

這非常重要。

因為未來 AI 生成或適配新的：

Module；
Transition；
State schema；
Action；
Domain rule；

都可以先用 ScenarioIR 驗證。

所以後續 constrained generation 的 behavioral constraint，可以直接建立在現有 Scenario 基礎之上。

12. Studio：世界定義已經開始從 Python Runtime 抽離

現有 Studio 白皮書已經提出：

\boxed{ \text{CompilableWorld Studio} \rightarrow \text{Validated World IR} \rightarrow \text{Runtime Targets} }

並明確主張：

Python Runtime 是第一個參考執行器，而不是世界本身。

這個方向必須保留。

因為未來真正的 Prototype Library、Reference World Anchor、自適應適配與多 Runtime target，都要求：

\text{World Definition} \neq \text{Python Classes}

Studio／World IR 因此不是 UI 附件，而是未來通用化的上游基礎。

13. AMK：記憶沒有被誤認為世界真相

現有規約已經定義：

AMK Raw／Clean 是 Runtime Event Log 與 State 的外部證據層，不可冒充或覆蓋世界真實來源。

因此：

\boxed{ \text{Memory} \neq \text{Runtime Truth} }

合理方向是：

\text{World State/Event Log} \rightarrow \text{Memory Evidence Capture}

而不是：

\text{Model Memory} \rightarrow \text{Direct State Override}

這條邊界未來非常重要。

因為到了 Open-World Layer，還會加入：

observation；
inference；
belief；
external evidence。

如果連 Memory 與 Runtime State 都沒有分開，後面一定會失控。

14. MCP：外部 Agent 的讀取界面已經開始建立

2026-07-15 的 read-only MCP 提交已建立：

list_worlds
open_world_session
get_world_status
get_current_scene
get_recent_events
close_world_session

同時規定：

MCP Adapter 不取得 StateStore.commit() 或 seed()；
MCP Session 不屬於 Runtime State；
Session open/close 不產生世界事件；
Event output 必須依 visibility / actor / role filter；
unknown visibility 採 fail-closed。

這代表：

\boxed{ \text{External Access} \neq \text{World Mutation Authority} }

這個方向是正確的。

未來就算加入 write-capable MCP，也應走：

\text{MCP Request} \rightarrow \text{ActionIR} \rightarrow \text{Kernel}

而不是提供 direct state write。

15. 哪些部分目前已高度接近通用核心？

以下不是宣告「Universal v1.0 已完成」，而是判斷其抽象方向已足夠乾淨，可以作為 General Runtime Candidate Core：

Entity Registry
StateStore
StateCell version
StateDelta
ActionIR
EventIR
EventBus
EventLog
Scheduler
Snapshot / Replay
ModuleContract
FunctionIR
ScenarioIR
Projection boundary
Compiler / Runtime separation
read-only external access boundary

可以暫時記為：

\boxed{ C_{\mathrm{candidate}} }

注意：

Candidate 不代表現在就要抽成另一個 repo。

先完成遊戲 Runtime，比提早切包更重要。

16. 哪些部分明顯仍然是 Game Domain？

目前 WorldRuntime.create_player() 會直接建立與 seed：

position
combat
health
status
magic
wallet
quest

這就是 Game-specific semantics。

同樣：

CombatModule；
MagicModule；
QuestModule；
InventoryModule；
Dialogue；
Room／Movement；
player generation；
game canon；
HP / MP / FP；
phase tier；

都不應直接被宣布為 Universal Core。

未來合理的邏輯形式應是：

\boxed{ \text{Game World} = \text{General Runtime Core} + \text{Game Domain Pack} }

但這是一個未來抽取方向，不是現在要立刻重構完成的要求。

17. 目前 Repository 明確存在的結構缺口

17.1 單程序、單世界

目前仍是：

\boxed{ \text{Single Process} + \text{Single World Instance} }

還沒有：

account；
multiplayer consistency；
distributed lock；
multi-runtime coordination。

17.2 階層狀態已有，但跨層 transition 尚未完整

現有架構文件已經定義：

\mathcal M= \{ M_{\mathrm{world}}, M_{\mathrm{region}}, M_{\mathrm{scene}}, M_{\mathrm{entity}}, M_{\mathrm{system}}, M_{\mathrm{action}} \}

但 Repository 也明確標記：

world／region／scene 的初始階層狀態已進 State Store，跨層事件轉移規則留待後續。

這是 Game World-State Runtime v0.2 最重要的工作之一。

17.3 Read scope 與 Action authority 尚未全面強制

ModuleContract 已有 read 與 write。

但目前真正 enforce 的重點仍在 write。

後續必須補：

\text{who may read what}

以及：

\text{who may propose which action}

否則未來 AI／MCP／multi-agent 一接上，權限邊界會失去可信度。

17.4 Replay migration 尚未完成

Replay 可處理 committed Delta。

但：

EventIR_{v1} \rightarrow Runtime_{v2}

仍需要正式 migration registry。

17.5 Temporal model 還很簡單

Scheduler 有了，但尚未統一：

重複事件；
長期 workflow；
interrupt；
timeout；
temporal condition；
world calendar。

這些應在 Game Runtime 先驗證。

18. 後續演化正式分成三層

Layer A：Game World-State Runtime

近期主線。

目的：

先把一個封閉、可驗證、authoritative 的遊戲世界狀態 Runtime 做完整。

允許持續發展：

Combat；
Quest；
Magic；
Dialogue；
Game Time；
NPC；
Game-specific schema。

它不是暫時垃圾，也不會在通用化後被刪除。

Layer B：General Runtime Candidate Core

從 Game Runtime 中逐步辨識：

跨機制共用；
不依賴遊戲語義；
在其他 Domain 仍能保持相同不變量；

的結構。

目前候選大致是：

\boxed{ State + Entity + Action + Event + Time + Authority + Transition + History + Projection }

但「候選」不等於「先驗通用」。

真正的升格需要後續 Domain 重用證據。

Layer C：Future Open-World Layer

這一層目前只定義邊界，不提前硬塞進 Game Kernel。

未來才處理：

ObservationIR；
Claim / Evidence；
confidence；
provenance；
valid time；
staleness；
belief；
external effect；
acknowledgement；
reconciliation；
distributed state。

因此：

\boxed{ \text{Open-World Semantics} \not\subset \text{Game v0.2 的立即必做項} }

19. 本系列第一批核心不變量

I-1：Projection 不得反向成為世界真相

\text{Projection} \not\rightarrow \text{Direct State Mutation}

I-2：AI 不能繞過 Kernel

\text{AI} \rightarrow \text{ActionIR} \rightarrow \text{Kernel}

AI 若是修改世界定義，則必須走：

\text{AI Authored Diff} \rightarrow \text{Compiler} \rightarrow \text{Validation} \rightarrow \text{Runtime Package}

I-3：Memory 不等於 State

\text{Memory} \neq \text{StateStore}

I-4：Module 透過 Event 協作，不直接互改內部狀態

M_i \rightarrow E \rightarrow M_j

I-5：Pure Function 不等於 Transition

\text{FunctionIR} \neq \text{State Mutation}

I-6：Game Runtime 必須持續可執行

\boxed{ W_{\mathrm{game}} \text{ 必須持續可執行、可測試、可回歸} }

通用化不得以破壞現有 Reference World 為代價。

20. 禁止事項

禁止 A：先建立巨大 Universal Ontology

目前沒有足夠跨 Domain 驗證，不應先定義：

所有人；
所有公司；
所有設備；
所有機器人；
所有市場；
所有天氣；

的統一 Schema。

禁止 B：為了通用化重寫已驗證 Kernel

除非實際 Domain 驗證證明某抽象錯誤，否則優先：

\text{extract / wrap / adapt}

而不是：

\text{rewrite everything}

禁止 C：AI 生成後直接熱安裝

任何動態生成至少必須經：

\text{Syntax} \rightarrow \text{Schema} \rightarrow \text{Semantic Validation} \rightarrow \text{Authority} \rightarrow \text{Scenario} \rightarrow \text{Promotion}

禁止 D：把 Game State 等同現實 Observation

遊戲現在可以假設：

\text{State}=\text{Truth}

未來現實世界不能直接沿用這個假設。

21. Game World-State Runtime v0.2 建議核心清單

之後重新啟動工程時，優先做：

Hierarchical cross-layer event transition
Transition priority / ambiguity diagnostics
Module read-scope enforcement
Action authority isolation
Temporal rule / scheduler extension
Replay migration registry
State / event / transition trace
SCC / cycle diagnostics
Scenario property tests
Reference-world regression suite

這一階段仍然是：

\boxed{ \text{Game First} }

不是先做 Smart Home、Robot 或 Universal Runtime。

22. 驗證條件

V-1：同一 StateStore 可承載不同 namespace

新增新型狀態不需要修改 Kernel 專門理解該 Domain。

V-2：新 Module 只靠 Contract + Action + Delta + Event 即可接入

若每增加一個 Game Mechanism 都必須改 Kernel，表示核心仍不夠乾淨。

V-3：拔掉 AI Adapter 後 Runtime 仍然可運作

這已是現有設計原則。

V-4：拔掉 Web／CLI／MCP Projection 後 Runtime State 不受影響

Projection 不能成為真相來源。

V-5：Snapshot／Replay 可重建世界狀態

未來加入 migration 後，還要能跨版本驗證。

V-6：Game-specific 模組能被整體辨識

Combat／Magic／Quest 可以被視為 Game Domain Pack，而不污染 StateStore／ActionIR／EventIR 的抽象。

23. 結論

目前 CompilableWorld 最值得保留的不是某個 MUD 功能，而是它已形成：

\boxed{ \text{Authoring} \rightarrow \text{Compile} \rightarrow \text{Action} \rightarrow \text{Module} \rightarrow \text{Delta} \rightarrow \text{Commit} \rightarrow \text{Event} \rightarrow \text{Projection} }

並配有：

\text{State Version} + \text{Authority Boundary} + \text{Scheduler} + \text{Snapshot} + \text{Replay} + \text{Scenario} + \text{Memory Boundary} + \text{External Read Boundary}

因此目前最準確的定位是：

\boxed{ \text{Game World-State Runtime Prototype} }

而不是只把它理解成 MUD Engine。

但同時也不應提前宣告它已是通用世界狀態機。

更準確的說法是：

\boxed{ \text{Game Runtime 已經形成 General World-State Runtime 的第一個可執行參考錨點。} }

下一篇將正式處理：

《可執行參考世界：以遊戲世界狀態機作為通用系統的虛擬錨點》

下一篇的核心問題包括：

Reference World Anchor 是什麼；
為什麼 Game Runtime 不應在通用化後被淘汰；
如何把已驗證世界變成 Prototype Library；
怎麼讓 AI 未來「先抄、再改、最後才生成」；
如何讓非通用 Reference World 與 General Runtime 雙向共演化。

Appendix A：Repository Grounding

本篇主要依據目前 repository 中以下實作／文件：

README.md — CompilableWorld Runtime MVP v0.1.1
AGENTS.md
src/compilableworld/kernel.py
src/compilableworld/models.py
docs/whitepapers/05-hierarchical-state-machine-mud.md
docs/whitepapers/07-evennia-to-mssp-runtime.md
MSSP × RDR 階層狀態機整合提案
docs/whitepapers/09-compilableworld-studio-mssp-rdr-visual-world-ide-v0.1.md
2026-07-15 commit c9a33185ac7df5863e76995b0ebb097578e6be7e
2026-07-15 commit 72334d7881749c78d323684e3ddbbc2b8aab86da

本篇刻意沒有把尚未存在於 Repository 的 Observation／Belief／External Effect 機制寫成「已實作」。它們只屬於後續 Open-World Layer。

01_從CompilableWorld_Runtime到世界狀態機_現況盤點與演化邊界

從 CompilableWorld Runtime 到世界狀態機：現況盤點與演化邊界

摘要

1. 現況：目前 CompilableWorld 已經不是普通 FSM

2. 現有真相來源已經被刻意分層

2.1 Authoring Layer

2.2 Compiled Runtime Package

2.3 Runtime State

3. StateStore：目前最接近 Domain-Neutral Core 的元件

4. StateDelta：世界變化不是任意寫入，而是受治理的提案

5. ActionIR：不同入口共用的行動邊界

6. EventIR：世界的因果歷史已經有正式雛形

7. ModuleContract：真正重要的是權限邊界，而不是模組名稱

已完成

尚未完成

8. Scheduler：目前已有時間，但還不是完整 World Time

9. Snapshot + Event Log + Replay：已形成「現在＋歷史」雙軌

10. FunctionIR：純計算與世界變化已被正確拆開

11. ScenarioIR：未來生成式約束的測試基底已經存在

12. Studio：世界定義已經開始從 Python Runtime 抽離

13. AMK：記憶沒有被誤認為世界真相

14. MCP：外部 Agent 的讀取界面已經開始建立

15. 哪些部分目前已高度接近通用核心？

16. 哪些部分明顯仍然是 Game Domain？

17. 目前 Repository 明確存在的結構缺口

17.1 單程序、單世界

17.2 階層狀態已有，但跨層 transition 尚未完整

17.3 Read scope 與 Action authority 尚未全面強制

17.4 Replay migration 尚未完成

17.5 Temporal model 還很簡單

18. 後續演化正式分成三層

Layer A：Game World-State Runtime

Layer B：General Runtime Candidate Core

Layer C：Future Open-World Layer

19. 本系列第一批核心不變量

I-1：Projection 不得反向成為世界真相

I-2：AI 不能繞過 Kernel

I-3：Memory 不等於 State

I-4：Module 透過 Event 協作，不直接互改內部狀態

I-5：Pure Function 不等於 Transition

I-6：Game Runtime 必須持續可執行

20. 禁止事項

禁止 A：先建立巨大 Universal Ontology

禁止 B：為了通用化重寫已驗證 Kernel

禁止 C：AI 生成後直接熱安裝

禁止 D：把 Game State 等同現實 Observation

21. Game World-State Runtime v0.2 建議核心清單

22. 驗證條件

V-1：同一 StateStore 可承載不同 namespace

V-2：新 Module 只靠 Contract + Action + Delta + Event 即可接入

V-3：拔掉 AI Adapter 後 Runtime 仍然可運作

V-4：拔掉 Web／CLI／MCP Projection 後 Runtime State 不受影響

V-5：Snapshot／Replay 可重建世界狀態

V-6：Game-specific 模組能被整體辨識

23. 結論

《可執行參考世界：以遊戲世界狀態機作為通用系統的虛擬錨點》

Appendix A：Repository Grounding