# 動態通用世界狀態機 v0.x：演化閉環、升格機制與後續工程路線 **系列：** 動態通用世界狀態機：內部架構與演化規格 **篇次：** 07 / 07 **版本：** v1.0 **日期：** 2026-08-01 **性質：** 內部技術白皮書／第一批封頂與後續工程總規格 **基準 Repository：** `kakon77777-commits/compilableworld-runtime-mvp` --- # 摘要 前六篇已經分別建立： 1. Game World-State Runtime 的現況邊界； 2. Executable Reference World； 3. Universal / Adaptable / Specific 三層語義； 4. Prototype-Anchored Adaptive Composition； 5. Residual Generation 與 Generative Constraint Stack； 6. Observation / Belief / External Effect 的 Open-World Layer。 因此最後一篇不再增加另一批巨大新概念，而是把整體收斂成一個可演化、可驗證、可回退的工程閉環。 本系列所稱的「動態通用世界狀態機」，不是： > 一個事先知道所有世界 Schema 的巨大 Runtime。 也不是： > 一個讓 AI 在 live world 裡自由重寫規則的自生成系統。 更準確的定義是： $$ \boxed{ \text{Dynamic General World-State Runtime} = \text{Stable Execution Core} + \text{Executable Reference Worlds} + \text{Evidence-Carrying Prototypes} + \text{Adaptive Composition} + \text{Constrained Residual Generation} + \text{Optional Open-World Semantics} + \text{Promotion / Demotion Loop} } $$ 其中「通用」不是一次性設計決定，而是經由跨 Domain 重用與驗證逐步形成。 因此整個演化循環為： $$ \boxed{ P_n \rightarrow C_n \rightarrow D_n \rightarrow V_n \rightarrow E_n \rightarrow P_{n+1} } $$ 其中： - $P_n$ ：目前 Prototype / Core； - $C_n$ ：Composition / Adaptation； - $D_n$ ：Domain Deployment； - $V_n$ ：Validation / Regression； - $E_n$ ：Evidence； - $P_{n+1}$ ：經驗證後更新的 Prototype / Core。 這意味著通用性本身是： $$ \boxed{ \text{Evidence-Driven Generalization} } $$ 而不是： $$ \text{Abstract Naming} \rightarrow \text{宣告 Universal} $$ 最後，本篇將後續工程明確分成幾個階段：先完成 Game World-State Runtime v0.2，再把 Game 世界正式封裝為 Reference World，之後才實作 Prototype Registry 與 Adaptive Composer；Open-World Layer 第一個非遊戲驗證 Domain 建議採 Smart Room，而不是立即跳到大型 Robot；真正抽離 General Core 則放在第二 Domain 已證明能共用 Kernel 後。 --- # 1. 第一批七篇最後收斂出的系統 可以把整個架構寫成： $$ \boxed{ \mathcal{W} = ( K, R, P, C, G, O, E ) } $$ 其中： - $K$ ：Stable World Kernel； - $R$ ：Executable Reference Worlds； - $P$ ：Prototype Library； - $C$ ：Adaptive Composer； - $G$ ：Constrained Generative Layer； - $O$ ：Optional Open-World Layer； - $E$ ：Evidence / Promotion System。 這七個部分不應被合併成一個巨型模組。 --- # 2. Stable World Kernel：不追求知道所有世界，而追求維持不變量 Kernel 的角色仍然不是： > 理解所有 Domain。 而是維持最小執行不變量。 目前候選核心可以概念上寫成： $$ K= ( Entity, State, Action, Event, Time, Authority, Transition, History, Projection, Contract ) $$ 但這些詞要維持窄語義。 例如 Kernel 可以知道： > Module 無權修改 write scope 外的 State。 但不需要知道： > `combat.hp` 和 `robot.battery` 哪一個更重要。 所以： $$ \boxed{ \text{Kernel Generality} = \text{Invariant Generality} } $$ 不是名詞越抽象越通用。 --- # 3. Reference Worlds：通用系統永遠保留具體世界 如果只剩抽象 Core，系統會逐漸失去： - 長流程 evidence； - regression； - boundary cases； - failure corpus； - realistic module composition。 因此至少保留： $$ R= \{ R_{\mathrm{game}}, R_{\mathrm{smartroom}}, R_{\mathrm{robot}}, \ldots \} $$ 第一個是目前 Game Runtime。 未來第二個才是 Smart Room。 每個 Reference World 都必須： - compile； - run； - snapshot； - replay； - scenario； - regression； - 保存 known failures。 所以： $$ \boxed{ \text{General Runtime} \not\Rightarrow \text{Concrete Worlds Disappear} } $$ 恰恰相反，Reference Worlds 越多，通用性證據才越強。 --- # 4. Prototype Library：通用化的真正中介層 前面三層語義中： $$ D_{\mathrm{adaptable}} $$ 最終會成為整個系統最有價值的一層。 例如： - lifecycle； - location； - ownership / custody； - resource； - task transition； - timed state； - availability； - authority template； - dependency； - reconciliation pattern。 這些不是 Universal Core，也不是某個 Domain 的硬編碼。 所以： $$ \boxed{ \text{Prototype Library} = \text{Reusable Behavior Knowledge} } $$ 而不是 snippet collection。 --- # 5. 動態通用化真正的閉環 本系列正式採用： $$ \boxed{ \text{Reference} \rightarrow \text{Extract} \rightarrow \text{Reuse} \rightarrow \text{Adapt} \rightarrow \text{Validate} \rightarrow \text{Promote / Demote} } $$ 詳細循環如下： ```text Executable Reference World ↓ discover recurring pattern ↓ Prototype Candidate ↓ second-domain adaptation ↓ scenario + regression ↓ evidence record ↓ promotion decision ↓ Adaptable / Universal ↓ used by later worlds ↓ new failures / exceptions └───────────────→ revision or demotion ``` 因此通用化不是單向。 --- # 6. Promotion 與 Demotion 必須同時存在 如果只允許： $$ S \rightarrow A \rightarrow U $$ 系統會逐漸把錯誤假設永久固化。 所以正式需要： $$ \boxed{ S \leftrightarrow A \leftrightarrow U } $$ 其中： - $S$ ：Domain-Specific； - $A$ ：Adaptable Prototype； - $U$ ：Universal Core / Contract。 新 Domain 若證明某個原本 Universal 的假設不成立，就必須允許： $$ U\rightarrow A $$ 甚至： $$ A\rightarrow S $$ 這不是失敗。 這正是： $$ \boxed{ \text{Evidence-Driven Architecture} } $$ 應有的行為。 --- # 7. Promotion Record：通用性不能只有版本號 每一次升格至少應保存： $$ \Pi= ( candidate, source\ domains, invariants, tests, failures, decision, reviewer, version ) $$ 例如： ```yaml promotion: candidate: prototype.timed_state@0.3 from: adaptable to: universal_candidate evidence: domains: - game - smart_room regression: game: pass smart_room: pass invariants: - explicit_clock_domain - deterministic_expiry_semantics unresolved: - distributed_clock ``` 這樣日後才知道： > 當初為什麼它被升格？ --- # 8. Promotion Level 不要直接二元化 可以先分成熟度： ```text experimental reference-local cross-domain-candidate adaptable-stable universal-candidate universal-stable deprecated ``` 因此： $$ \boxed{ \text{Promotion} \neq \text{Specific → Universal 一步跳} } $$ 這對未來 AI 自動管理 Prototype 特別重要。 --- # 9. Evidence Ledger：整個系統的核心治理資產 未來應有： $$ \boxed{ \text{Generalization Evidence Ledger} } $$ 至少記錄： - Reference source； - Prototype lineage； - Domain 使用； - Scenario； - regression； - failures； - semantic deviations； - authority deviations； - migration issues； - promotion； - demotion； - deprecation。 這個 Ledger 比「AI 說它很通用」可靠得多。 --- # 10. 通用性評估不是只算使用次數 可以概念化： $$ G(P) = f( N_D, I_C, V_B, R_F, A_C, T_C, F_E ) $$ 其中： - $N_D$ ：Domain diversity； - $I_C$ ：invariant consistency； - $V_B$ ：behavioral validation； - $R_F$ ：regression-free evidence； - $A_C$ ：authority compatibility； - $T_C$ ：temporal compatibility； - $F_E$ ：failure evidence coverage。 使用很多次，只提高其中一個維度。 所以： $$ \boxed{ \text{Frequency} \neq \text{Universality} } $$ --- # 11. 動態通用化也不等於自動修改 Universal Core 即使 AI 發現： > 三個 Domain 都有某 pattern。 它只能提出： $$ \text{Promotion Candidate} $$ 不能直接修改 Kernel。 流程仍是： $$ \boxed{ \text{Evidence} \rightarrow \text{Promotion Proposal} \rightarrow \text{Regression} \rightarrow \text{Review} \rightarrow \text{Core Change} } $$ Universal Core 的 mutation authority 應是整個系統最高等級之一。 --- # 12. Core Change 應比 Domain Patch 更保守 可以定義： $$ Risk_{\mathrm{core}} > Risk_{\mathrm{prototype}} > Risk_{\mathrm{domain}} $$ 不是說 Domain action 永遠風險比較低，而是： > 一個錯誤 Core 修改會影響所有 Domain。 所以 Core promotion 至少要求： - multi-reference regression； - migration plan； - backward compatibility； - semantic diff； - rollback plan； - explicit version change。 --- # 13. General Runtime 不應成為「會自己不斷長大」的單一程式 動態通用化比較好的物理結構是： ```text core/ reference_worlds/ prototypes/ domains/ composer/ constraints/ adapters/ evidence/ ``` 而不是： ```text universal_runtime.py ``` 不斷塞入更多邏輯。 所以： $$ \boxed{ \text{Generality Through Composition} > \text{Generality Through Monolith Growth} } $$ --- # 14. 第一階段工程：先完成 Game World-State Runtime v0.2 這是重新啟動專案後最優先的一段。 現在不要先做 Prototype AI Composer。 先補 Game Runtime 自己尚未完成的世界狀態能力。 核心清單： 1. hierarchical cross-layer transitions； 2. transition priority / ambiguity diagnostics； 3. Module read-scope enforcement； 4. Action authority isolation； 5. scheduler / temporal rule extension； 6. replay migration registry； 7. state / event / transition trace； 8. SCC / cycle diagnostics； 9. Scenario property / generative tests； 10. full Reference regression suite。 這一階段的目標是： $$ \boxed{ \text{Game World} \text{ 能長時間穩定地作為 Reference World} } $$ --- # 15. 為什麼 Hierarchical Transition 應排第一？ 原架構已經有： $$ M_{\mathrm{world}}, M_{\mathrm{region}}, M_{\mathrm{scene}}, M_{\mathrm{entity}}, M_{\mathrm{system}}, M_{\mathrm{action}} $$ 但真正跨層事件規則還沒有完成。 如果這部分沒做完，就無法充分驗證： - 宏事件如何影響區域； - 場景事件如何影響 Entity； - Entity reaction 如何回饋系統； - 多 Module 是否產生 cycle； - priority 如何仲裁。 而這正是未來 General World-State Runtime 最重要的「世界」性。 --- # 16. Game v0.2 完成 Gate 只有以下條件大致成立，才進 Reference formalization： $$ \boxed{ G_{\mathrm{game-v0.2}}=1 } $$ 建議 Gate： - cross-layer transition 有正式 contract； - ambiguity 可診斷； - read / write / action authority 基本完整； - scheduler 可處理核心 temporal case； - snapshot/replay 有 migration path； - trace 可以定位因果； - cycle/SCC 可觀測； - full regression 可一鍵執行。 --- # 17. 第二階段工程：把 Game 正式封裝為 Reference World v0.1 這一階段不增加大量新 gameplay。 主要建立工程資產。 需要： - Reference World Manifest； - Capability List； - Prototype Candidate List； - Scenario Corpus； - Known Failure Corpus； - Trace Corpus； - Contract Versions； - Regression Entry Point。 目標： $$ \boxed{ \text{Game Runtime} \rightarrow \text{Game Reference World} } $$ 不是改變它的行為，而是讓它變成可比較、可引用、可檢索的錨點。 --- # 18. Reference v0.1 完成 Gate 至少： - reference manifest 可解析； - world / runtime / contract version 可追蹤； - regression suite 固定； - known failures 有記錄； - Prototype Candidate 可定位來源； - snapshot/replay fixture 可保存； - CI 或本地命令可重跑 Reference。 --- # 19. 第三階段工程：Prototype Registry v0.1 這時才把前面反覆出現的結構正式放進 Prototype Registry。 第一批不要太多。 建議只取： - lifecycle； - location； - ownership； - task transition； - resource； - timed state； - authorized action。 每個 Prototype 都需要： $$ P= ( Contract, Parameters, Invariants, Scenario, Evidence, Lineage ) $$ 不是抽一個 base class 就算完成。 --- # 20. Prototype v0.1 先不追求 Universal 第一批都標： ```text reference-local ``` 或： ```text adaptable-candidate ``` 只有 Game evidence。 這樣可以避免： > 第一個 Domain 才跑過，就宣布 universality。 --- # 21. 第四階段工程：Adaptive Composer v0.1 這一階段才開始實作第 4 篇。 第一版只需要： $$ \boxed{ \text{Decision Support} } $$ 流程： ```text RequirementIR → retrieve candidate prototypes → compatibility analysis → composition graph → conflict report → residual spec → composition report ``` 先不要 auto-deploy。 --- # 22. Composer v0.1 的最小能力 只需要回答： 1. 哪些 Universal Core 可直接用？ 2. 哪些 Prototype 是候選？ 3. 哪些是 L0 / L1 / L2 / L3？ 4. 哪些 namespace collision？ 5. 哪些 verb collision？ 6. 哪些 authority mismatch？ 7. 哪些 temporal mismatch？ 8. residual 到底是什麼？ 9. generation risk 多大？ 這就已經很有價值。 --- # 23. 第五階段工程：Generated Candidate Patch / Constraint Pipeline 接著實作第 5 篇。 新增： - Candidate Patch Manifest； - semantic diff； - risk tier； - Syntax Gate； - Schema Gate； - Semantic Gate； - Authority Gate； - Behavioral Gate； - Regression Gate； - promotion metadata； - rollback metadata。 這一步後 AI 才開始真正生成 residual。 --- # 24. 生成 v0.1 仍以 Authoring-Time 為主 第一版模式： $$ \boxed{ \text{Generate} \rightarrow \text{Compile} \rightarrow \text{Deploy} } $$ 不要一開始做： $$ \text{Live Runtime} \rightarrow \text{Self-Modify Structure} $$ 這可大幅降低 debug 難度。 --- # 25. 第六階段工程：Smart Room Open-World Reference v0.1 Game Reference 穩定後，建立第二 Domain。 建議 Smart Room，而不是直接 Robot。 最小 Entity： - person； - room； - light； - door； - temperature sensor； - phone / controller。 最小 Open-World 能力： - observation； - stale data； - conflict； - authority； - delayed action； - external effect； - acknowledgement； - reconciliation。 --- # 26. Smart Room 必須盡量使用 Fake / Simulated Adapter 起步 最初不需要真的接門鎖。 可以： ```text FakeLightAdapter FakeDoorAdapter FakePresenceSensor ``` 先證明： $$ \boxed{ \text{Open-World Semantics} } $$ 成立。 之後再接 WoT / MQTT / REST 等真實 adapter。 這會比一開始處理硬體故障快很多。 --- # 27. Smart Room 的核心 E2E Gate 至少完成： ```text presence observation → fusion → occupancy state → delayed rule → authorized external effect → acknowledgement → post-effect observation → reconciliation ``` 這一條跑通，就第一次真正證明： $$ \boxed{ \text{Game Core} + \text{Open-World Layer} } $$ 可以支援第二 Domain。 --- # 28. 第二 Domain 才是 Universal Extraction 的真正起點 這是一個非常重要的 Roadmap 決定。 在 Smart Room 之前： > 只做 Candidate Universal。 在 Smart Room 之後，才有資格比較： $$ K_{\mathrm{game}} $$ 與： $$ K_{\mathrm{smartroom}} $$ 如果兩者使用相同： - StateStore； - ActionIR； - EventIR； - Scheduler base； - ModuleContract； - Snapshot； - Scenario； - Projection boundary； 而不需要改變其核心語義， 才有比較強的證據： $$ \boxed{ K_{\mathrm{shared}} \rightarrow \text{General Core Candidate} } $$ --- # 29. 第七階段工程：General Core Extraction 此時才進行 physical refactor： ```text src/ core/ game/ openworld/ adapters/ ``` 或另 package。 但這一步的順序是： $$ \boxed{ \text{Semantic Evidence} \rightarrow \text{Physical Extraction} } $$ 不是反過來。 --- # 30. Core Extraction Gate 必須同時滿足： - Game Reference regression pass； - Smart Room regression pass； - shared IR semantics 不變； - Domain-specific code 可清楚分離； - migration path 完整； - no hidden dependency from core back to Game； - package boundary 可測。 --- # 31. Robot Domain 應放在 General Core 之後或同步晚期 Robot 會一次引入： - continuous control； - perception uncertainty； - multi-rate loop； - safety； - localization； - actuator failure； - local autonomy； - device network partition。 如果太早做，很容易把： > 世界狀態 Runtime 問題 和： > robotics control 問題 混在一起。 因此： $$ \boxed{ \text{Game} \rightarrow \text{Smart Room} \rightarrow \text{Robot} } $$ 是更乾淨的驗證階梯。 --- # 32. Robot Domain 的作用不是證明所有 Robot 都能用 它主要用來壓測： - Open-World Observation； - fast-changing state； - External Effect； - safety authority； - local vs external brain； - multi-clock； - interrupted task； - partial connectivity。 所以它是： $$ \boxed{ \text{Embodied Stress Test Domain} } $$ 而不是「General Runtime 的終極用途」。 --- # 33. 後續可加入的其他 Domain 如果之後真的要驗證更廣泛通用性，可以依序挑語義差異大的領域。 例如： ### Agent Workflow 驗證： - task； - tool； - permission； - external API； - long-running state。 ### Simulation 驗證： - purely synthetic multi-world； - deterministic replay； - branch / counterfactual。 ### Business Process 驗證： - approval； - custody； - audit； - external authoritative state。 但不需要一次全部做。 --- # 34. Domain Selection 應最大化「新語義」，不是最大化數量 選下一個 Domain 的目標不是： > 我已經支援 10 個 Domain。 而是： > 新 Domain 能不能揭露上一個 Domain 沒有暴露的假設？ 所以可以定義： $$ \operatorname{Value}(D) = \operatorname{NovelSemantics}(D) - \operatorname{IntegrationCost}(D) $$ Smart Room 的價值就在於： - 成本不高； - 但一次引入 Observation / Effect / Authority / staleness。 --- # 35. Development Branch Policy 未來重新開始工程時，建議至少概念上分： ```text main game-next generalization-lab ``` 或等價工作流。 原因： - Game 主線仍要能跑； - Generalization experiment 可以失敗； - Prototype extraction 不應阻斷 gameplay 修復。 所以： $$ \boxed{ \text{Experiment} \neq \text{Immediate Mainline} } $$ --- # 36. Generalization Lab 的作用 `generalization-lab` 可以容納： - Prototype Registry； - RequirementIR； - Composer； - Open-World Candidate； - semantic diff； - Smart Room。 只有通過 Gate 才回 main/core。 這與前面 Candidate Patch 思想完全一致。 --- # 37. 版本策略：不要把研究里程碑假裝成正式產品版本 本篇用 v0.x 表示工程階段，但不要求 repo 真的照以下版本號發行。 概念里程碑可以是： ```text M0 Current Game Runtime Baseline M1 Game World-State v0.2 M2 Game Reference World M3 Prototype Registry M4 Adaptive Composer M5 Constraint / Candidate Patch M6 Smart Room Open-World M7 General Core Extraction M8 Robot Stress Test ``` 這比現在先承諾： ```text v0.2 = 某日期 v0.3 = 某日期 ``` 更穩健。 --- # 38. 每個 Milestone 都應有「不要做什麼」 ## M1 不做 - Open-World； - Robot； - Prototype AI composer。 ## M2 不做 - 自動升格 Universal。 ## M3 不做 - auto-deploy。 ## M4 不做 - live structural mutation。 ## M5 不做 - Tier 4/5 auto-promotion。 ## M6 不做 - 大型 robotics control。 這可以防止每一階段再次膨脹。 --- # 39. 技術債務與功能擴張應分流 重新啟動 Game Runtime 後，可能仍會出現： - gameplay bug； - CLI bug； - schema bug； - content mismatch。 不要把所有 bug 都解釋成： > General Runtime 需要重構。 應區分： $$ \boxed{ \text{Local Bug} \neq \text{Architectural Evidence} } $$ 只有反覆出現、跨 Domain 的問題，才值得推動 Core 變更。 --- # 40. Failure Evidence 是 Generalization Loop 的輸入 過去 generic status effect 增加新 state write path，因 `ModuleContract.write` 沒同步而被 Kernel 擋下。 這不是單純 bug。 它可以產生一個更高階 evidence： > Prototype 或 generated module 如果新增 state path，必須同步產生 authority diff 與 live-kernel validation obligation。 因此： $$ \boxed{ \text{Failure} \rightarrow \text{Invariant Candidate} } $$ 但同樣需要多次驗證才進 Universal。 --- # 41. 最終 Generalization Loop 整個動態通用系統的真正循環可以寫成： $$ \boxed{ \begin{aligned} R_n &\rightarrow P_n \rightarrow C_n \rightarrow W_n\\ &\rightarrow V_n \rightarrow F_n \rightarrow E_n\\ &\rightarrow \operatorname{Promote/Demote} \rightarrow (R_{n+1},P_{n+1},K_{n+1}) \end{aligned} } $$ 其中： - $R$ ：Reference Worlds； - $P$ ：Prototype Library； - $C$ ：Composition； - $W$ ：New World / Domain； - $V$ ：Validation； - $F$ ：Failure Corpus； - $E$ ：Evidence Ledger； - $K$ ：Kernel / Core。 因此 Kernel 也可以演化，但只能經完整閉環。 --- # 42. 「動態」真正有三種層次 本系列最後把 Dynamic 分成三級。 --- ## D1：Dynamic State 目前已存在。 $$ S_t\rightarrow S_{t+1} $$ 例如： - player moves； - HP changes； - quest changes； - scheduler fires。 --- ## D2：Dynamic Composition 本系列下一階段主力。 $$ R_q \rightarrow P_1\oplus P_2\oplus\cdots \rightarrow W_{\mathrm{candidate}} $$ 世界結構根據需求被組合。 --- ## D3：Dynamic Generalization 最終較成熟能力。 $$ \text{Repeated Evidence} \rightarrow \text{Prototype/Core Evolution} $$ 也就是： > 系統會因成功重用與失敗反例而修正自己認為「什麼是通用」。 這才是本系列真正意義上的： $$ \boxed{ \text{Dynamic General World-State Runtime} } $$ --- # 43. D3 不應被理解為無限制 Self-Modification D3 的每一次 Core 變更仍要經： - evidence； - proposal； - regression； - migration； - review； - promotion。 所以： $$ \boxed{ \text{Adaptive} \neq \text{Uncontrolled} } $$ 而： $$ \boxed{ \text{Self-Improving} \neq \text{Self-Authorizing} } $$ 這兩條非常重要。 --- # 44. AI 在成熟系統中的角色 AI 未來可以參與： - Requirement normalization； - Prototype retrieval； - similarity search； - semantic mapping； - composition planning； - residual generation； - scenario generation； - failure diagnosis； - repair； - promotion suggestion； - documentation。 但 AI 不應自動擁有： - Core write authority； - unrestricted live StateStore authority； - Tier 4/5 promotion authority； - physical effect unrestricted authority。 因此： $$ \boxed{ \text{AI Intelligence} \neq \text{Runtime Authority} } $$ 這和前一個具身 AI 系列的「能力與權力分離」是一致的架構原則。 --- # 45. 人工 Review 未來也可以被多 Agent Review 逐步取代，但 Gate 不能消失 早期： ```text AI proposal → human review ``` 後期可能： ```text author agent → verifier agent → static compiler → scenario engine → policy agent → human only on high risk ``` 但： $$ \boxed{ \text{Reviewer May Change} \neq \text{Review Boundary Disappears} } $$ 這也是生成治理長期應維持的原則。 --- # 46. 通用世界狀態機真正的「基底」是什麼？ 到這裡可以正式回答。 不是： ```text 一套巨大的所有世界 schema ``` 也不是： ```text 一個大型 LLM ``` 而是： $$ \boxed{ \text{General Substrate} = \text{Stable Contracts} + \text{State / Event / Action Kernel} + \text{Evidence-Carrying Reuse} + \text{Constrained Adaptation} } $$ 這個基底允許不同世界： - 共用真正相同的； - 參數化近似相同的； - 保留真正不同的； - 在遇到未知時受約束生成。 --- # 47. 通用不代表所有 Domain 都要共用同一實作 兩個 Domain 可以共享： $$ \text{Prototype Contract} $$ 但各自使用不同 implementation。 例如： ```text TimedStatePrototype ``` Game 用 tick。 Smart Room 用 wall clock。 Robot 用 monotonic local timer。 所以： $$ \boxed{ \text{Semantic Reuse} \neq \text{Binary Reuse} } $$ 這點對跨語言、跨平台 Runtime 也很重要。 --- # 48. Python Runtime 的未來定位 現有 Python Runtime 應繼續作為： $$ \boxed{ \text{Reference Executor} } $$ 而不是永遠唯一的 World Runtime。 如果 Studio / World IR / Contract 穩定，未來可以有： - Python； - Rust； - browser； - embedded； - server； - simulation target。 但這是後期問題。 目前不用因為「未來多 Runtime」就提前重寫 Python。 --- # 49. 第一批封頂後最應避免的五件事 1. 不要立刻把 repo 全拆成 Universal package； 2. 不要立刻做大型 Robot； 3. 不要立刻做 auto-generating live rules； 4. 不要建立巨大萬物 ontology； 5. 不要為了理論完整再新增十幾篇文件而不回到工程。 這七篇的目的，就是讓後面能回去做。 --- # 50. 第一批完成後的最小工程待辦 如果幾週或幾個月後重新回來，只看這一節也應能重新開始。 優先順序： ```text [1] freeze / verify current repo baseline [2] build full Game regression entry point [3] hierarchical cross-layer transitions [4] read-scope + action authority [5] temporal / scheduler improvements [6] replay migration registry [7] trace + SCC / cycle diagnostics [8] Game Reference Manifest + failure corpus [9] Prototype Registry first seven patterns [10] Composer as report-only tool [11] Candidate Patch + Constraint pipeline [12] Smart Room with fake adapters [13] compare Game / Smart Room shared semantics [14] only then extract General Core ``` 這是本系列最重要的實作摘要。 --- # 51. 最終系統形式化 到第一批封頂，可以把系統表示為： $$ \boxed{ \mathcal{G}_t = ( K_t, R_t, P_t, C_t, X_t, O_t, E_t ) } $$ 其中： - $K_t$ ：當前 Stable Kernel； - $R_t$ ：Reference Worlds； - $P_t$ ：Prototype Library； - $C_t$ ：Composition / Adaptation； - $X_t$ ：Constrained Generative Layer； - $O_t$ ：Open-World Semantics； - $E_t$ ：Evidence Ledger。 它的演化不是： $$ K_t \xrightarrow{\mathrm{AI}} K_{t+1} $$ 而是： $$ \boxed{ (K_t,R_t,P_t) \xrightarrow{\mathrm{Domain}} W \xrightarrow{\mathrm{Validation}} E \xrightarrow{\mathrm{Promotion}} (K_{t+1},R_{t+1},P_{t+1}) } $$ 因此： $$ \boxed{ \text{Generalization} = \text{Validated Evolution} } $$ --- # 52. 最終架構圖 ```text ┌────────────────────────┐ │ Stable World Kernel │ │ State / Action / Event │ │ Time / Authority / IR │ └───────────┬────────────┘ │ ┌───────────────────┼────────────────────┐ │ │ │ ▼ ▼ ▼ Reference Worlds Prototype Library Open-World Layer Game / SmartRoom reusable patterns Observation/Effect │ │ │ └───────────┬───────┴────────────┬───────┘ ▼ │ Adaptive Composer │ │ │ ▼ │ Residual Spec │ │ │ ▼ │ Constrained Generation │ │ │ ▼ │ Candidate World Patch │ │ │ ▼ │ Compiler / Authority / Scenario │ │ │ ▼ │ Candidate Package │ │ │ ▼ │ Domain World ◄──────────┘ │ ▼ Regression / Failure / Trace │ ▼ Evidence Ledger │ ▼ Promote / Demote Proposal │ └──────────────► Core / Prototype vNext ``` --- # 53. 系列最後的核心判斷 從「有限狀態機」走到「世界狀態機」，第一個轉變是： $$ \text{Single State Machine} \rightarrow \text{Composable World State Runtime} $$ 從「遊戲世界狀態機」走到「通用世界狀態機」，第二個轉變不是： $$ \text{更多 Schema} $$ 而是： $$ \boxed{ \text{Reusable Invariants} + \text{Parameterized Patterns} + \text{Domain-Specific Freedom} } $$ 再從「通用」走到「動態通用」，第三個轉變是： $$ \boxed{ \text{Generalization Itself Becomes a Governed Runtime Process} } $$ 也就是系統不只運行世界。 它還維護： > 哪些世界結構已經被證明值得重用、哪些只是暫時假設、哪些需要客製、哪些應因新證據被降格。 --- # 54. 最終結論 本系列最終不主張： > 建立一個可以描述一切的萬能世界模型。 它主張的是另一件更工程化的事： > **建立一個能穩定運行具體世界、保存已驗證原型、重用成功結構、尊重領域差異、在未知處受約束生成，並根據跨 Domain 證據持續修正自身通用化邊界的世界狀態 Runtime。** 最終可以寫成： $$ \boxed{ \text{Dynamic General World-State Runtime} = \text{Stable Core} + \text{Evolving Evidence Boundary} } $$ 其中： - Core 不因每次新需求亂動； - Prototype 可以逐步演化； - Domain 可以保持特殊性； - AI 可以幫忙生成； - 生成不能自己取得權力； - Open World 可以承認未知與衝突； - 通用性必須有證據； - 錯誤的通用化可以被降格。 而目前 CompilableWorld Game Runtime 的角色也因此被完整確定： $$ \boxed{ \text{它不是等待被 Universal Runtime 淘汰的舊原型，} } $$ 而是： $$ \boxed{ \text{Dynamic General World-State Runtime 的第一個 Executable Reference World。} } $$ 第一批 7 篇至此封頂。 --- # Appendix A：後續工程 Milestones ## M0 — Current Baseline 現有 `compilableworld-runtime-mvp`。 ## M1 — Game World-State v0.2 Hierarchy / Authority / Time / Migration / Trace。 ## M2 — Game Reference World Manifest / Scenario / Failure / Evidence。 ## M3 — Prototype Registry 第一批 parameterized patterns。 ## M4 — Adaptive Composer RequirementIR / retrieval / composition / residual report。 ## M5 — Generative Constraint Pipeline Candidate Patch / semantic diff / risk / promotion / rollback。 ## M6 — Smart Room Open-World Observation / Effect / Reconciliation / fake adapters。 ## M7 — General Core Extraction Game + Smart Room shared semantics 驗證後才實體拆分。 ## M8 — Robot Stress Test 具身、多時間尺度、安全與連線斷裂壓測。 --- # Appendix B：本系列 7 篇的功能分工 ## 01 現況與邊界 回答： > 現有 Runtime 到底已經有哪些世界狀態基底？ ## 02 Executable Reference World 回答： > 為什麼非通用 Game Runtime 不應被淘汰？ ## 03 三層語義 回答： > 哪些應通用、哪些參數化、哪些客製？ ## 04 Adaptive Composition 回答： > 新需求進來時，怎麼先抄再改，最後才生成？ ## 05 Generative Constraint 回答： > AI 生成後怎樣才有資格成為可執行世界？ ## 06 Open-World Layer 回答： > Runtime 不再擁有全部 truth 時怎麼辦？ ## 07 Evolution Loop 回答： > 整套系統怎樣從 Game Reference 逐步走到 Dynamic General Runtime？ --- # Appendix C：Repository Freshness Check 2026-08-01 重新查核 `kakon77777-commits/compilableworld-runtime-mvp` 最近提交。 最新仍為： - `72334d7881749c78d323684e3ddbbc2b8aab86da` — read-only MCP、world projection、event visibility； - `c9a33185ac7df5863e76995b0ebb097578e6be7e` — Studio authoring contracts、AMK、atomic snapshot restore、regression。 因此本系列在封頂時仍以 2026-07-15 的 Runtime 基線作為工程現況；Prototype Registry、Adaptive Composer、Generated Candidate Patch、Open-World Observation / External Effect 等仍屬後續規格，不誤寫成 Repository 已完成能力。