# AI 不必替代計算 ## 從傳統執行平面到語義—因果控制平面 **English Title:** *AI Does Not Need to Replace Computation: From Traditional Execution Planes to Semantic-Causal Control Planes* **系列：**《計算域支配智能：AI 語義控制面與自適應多 X 計算》第 1 篇 **系列代號：** CDI / AIVS **文件編號：** EML-CDI-01-2026-v0.1 **作者：** Neo.K **協作整理：** Aletheia **機構：** EveMissLab／一言諾科技有限公司 **版本：** v0.1 **日期：** 2026-08-10 **文件類型：** 計算架構理論論文／AI Runtime 方法論 **證據成熟度：** E0–E1：既有工程 primitive 已存在；本文統一架構與核心命題仍屬研究假說，需要 MVP 與 benchmark 驗證。 --- ## 摘要 當代「AI 加速計算」常被理解為兩條路徑：第一，讓大型模型直接生成更快的程式；第二，讓 AI 取代部分傳統演算法或計算核心。然而，這兩條路徑都容易把 AI 放在「主要計算者」的位置，因而面臨成本、延遲、錯誤、可驗證性與資料規模問題。 本文提出另一條路徑： $$ \boxed{ \text{AI 不必成為主要計算者，} } $$ 而可以成為： $$ \boxed{ \text{傳統計算域的語義觀察者、因果統籌者、路由者與中繼校正者。} } $$ 本文將此方向稱為 **計算域支配智能**（Computational Domain Intelligence, CDI）。其中「支配」不表示 AI 取代作業系統、CPU scheduler、GPU driver 或傳統 compiler；它表示 AI 在一個被明確定義與授權的計算域中，建立比 thread、process、core 與 instruction 更高階的語義—因果視圖，判斷： - 哪些計算區域具有真實依賴； - 哪些只是因實作方式而被串行化； - 哪些可以並行、平行、推測、分流或異質加速； - 哪些結果已經 stale、錯位或違反 invariant； - 哪些 candidate 可以進入正式 commit； - 何時應交由低成本規則處理； - 何時才值得喚醒更高成本 AI。 其基本架構不是： $$ Program\rightarrow LLM\rightarrow Result, $$ 而是： $$ \boxed{ Program/Data/Goal \rightarrow Semantic\ PreAnalysis \rightarrow Causal\ Compute\ Graph \rightarrow Traditional\ Compute\ Fabric \rightarrow Adaptive\ AI\ Supervision. } $$ 本文進一步將傳統執行層與 AI 控制層分離： $$ \boxed{ Execution\ Plane \neq Semantic\ Control\ Plane. } $$ 執行平面仍由 CPU、GPU、NPU、thread pool、task scheduler、compiler 與 deterministic kernel 負責高速運算；AI 控制平面僅在較低頻率下接收 state digest、dependency status、invariant、exception、version 與 performance telemetry，必要時執行 reroute、retry、recompute、serialize、parallelize、speculate 或 escalate。 此設計與既有作業系統排程、compiler dependence analysis、task graph、GPU Work Graphs 並非互斥，而是位於更高語義層。Windows thread pool、.NET TaskScheduler 等系統已能有效管理 worker 與核心；LLVM Polly 等工具也已能做依賴分析與自動平行化；Direct3D 12 Work Graphs 則展示 GPU 內部工作可由資料流動態生成。本文的研究問題因此不是「AI 能不能發明多核心」，而是： > **AI 是否能補上傳統 runtime 很難取得的高階語義、因果與跨區域工作目的，從而發現新的安全多 X 計算機會，並以低頻、分層、可驗證方式維持其正確性？** 本文最後提出五組可反駁假說與一條由 source-visible 程式、runtime trace 到 legacy game 的漸進驗證路線，作為後續 AI 垂直同步（AIVS）、candidate/commit 計算、24／72 計算範式 runtime routing 與舊應用／遊戲 AI 加速研究的共同地基。 --- ## 關鍵詞 計算域支配智能、CDI、AI Runtime、AI 排程、語義控制平面、因果計算圖、AI 垂直同步、AIVS、多核心、平行計算、並行計算、異質運算、舊應用加速、遊戲加速、Adaptive Cognitive Runtime、計算範式、因果流 --- # 0. 系列定位 本系列預計六篇： 1. **《AI 不必替代計算：從傳統執行平面到語義—因果控制平面》** 2. **《AI 垂直同步：分層中繼、認知比例性與低成本因果一致》** 3. **《候選不是提交：多 X 計算中的因果校正、錯位檢測與可恢復執行》** 4. **《從 24／72 計算範式到 Runtime 路由：AI 如何選擇、組合與切換計算形態》** 5. **《舊應用與遊戲的 AI 加速：從實作串行化到必要串行化》** 6. **《CDI Runtime + AIVS：AI 治理多 X 計算的工程架構、協議與 MVP》** 前五篇回答： $$ Why,\ What,\ When,\ Where,\ How\ Far? $$ 第六篇回答： $$ \boxed{ How\ To\ Build? } $$ --- # 1. 問題起點：多核心存在，不代表程式能有效使用多核心 今日桌面與伺服器硬體已普遍具有多核心、多執行緒、GPU、NPU 與其他 accelerator。 但是： $$ \boxed{ HardwareParallelism \neq ProgramParallelism. } $$ 一個程式可能執行在 16 核 CPU 上，卻仍由某條 main thread 決定主要進度。 這可能來自兩種完全不同的原因。 第一種是真正的因果依賴： $$ x_{t+1}=F(x_t). $$ 在沒有 $x_t$ 前： $$ x_{t+1} $$ 無法合法計算。 第二種則只是： $$ \boxed{ ImplementationSerialization. } $$ 也就是： > 程式當初被寫成一條序列，不代表其中所有工作在數學、資料或語義上都必須序列化。 本文最重要的研究空間就位於： $$ \boxed{ PotentialParallelism = ImplementationSerialization - NecessarySerialization. } $$ 這不是一般集合減法的形式定義，而是一個工程性概念：找出「被實作方式串行化、但並非由真實依賴強迫串行」的工作區域。 --- # 2. 為什麼不能簡化成「Windows 不會多核」？ 作業系統其實早已非常擅長： - thread scheduling； - worker pool； - work stealing； - priority； - asynchronous I/O； - processor utilization； - blocking／wake management。 Windows thread pool 可將 work item 分配給系統管理的 worker threads；.NET `TaskScheduler` 的預設 scheduler 也具有 work-stealing、thread injection 與 retirement 等機制。 因此本文不是主張： > Windows 不知道如何把 thread 放到多核。 真正問題是： $$ \boxed{ OSScheduler } $$ 通常看不到完整的： $$ \boxed{ ApplicationSemantics. } $$ scheduler 可以知道： > Thread A blocked。 但不一定知道： > Thread A 正在做 NPC pathfinding，而 Thread B 正在做 inventory UI refresh；在目前 world epoch 下兩者沒有因果依賴，因此其更上層 task 可以被拆開。 所以本文提出第一個重要分離： $$ \boxed{ CoreScheduling \neq SemanticScheduling. } $$ --- # 3. 傳統 scheduler 看見什麼，AI 可以多看見什麼？ 簡化而言，傳統 runtime 常看： $$ \{ Thread, Priority, Ready, Blocked, CPUTime, Queue \}. $$ 而 CDI 希望建立： $$ \{ TaskMeaning, DataDependency, ControlDependency, SideEffect, WorldVersion, ExpectedInvariant, Risk, CausalRole \}. $$ 兩者不是替代關係。 更完整的 stack 是： $$ \boxed{ SemanticGovernor \rightarrow TaskRuntime \rightarrow OSScheduler \rightarrow Hardware. } $$ --- # 4. AI 不應直接處理所有原始計算 若 CPU 每秒執行極大量 instruction，而 AI 逐 instruction 閱讀並推理，則： $$ C_{AI} \gg UsefulGain. $$ 這條路幾乎必然失去意義。 因此 CDI 採用： $$ \boxed{ RawComputeRate \gg AICognitiveRate. } $$ AI 不觀察全部 operation。 AI 觀察： $$ \boxed{ CausalBoundaries + StateChanges + Anomalies + HighValueTransitions. } $$ 這個原則直接對應到先前在持續視覺 runtime 中已實作的結構： $$ RawFrame \rightarrow LowCostDiff \rightarrow StructuredEvent \rightarrow SelectiveAI. $$ 在計算域中則變為： $$ RawOperations \rightarrow LowCostTelemetry \rightarrow StructuredComputeEvent \rightarrow SelectiveAI. $$ --- # 5. 第一核心命題：AI 作為 Semantic Control Plane 定義兩個平面。 ## 5.1 Execution Plane $$ \mathcal E $$ 包括： - CPU； - GPU； - NPU； - thread pool； - task graph； - compiler-generated code； - deterministic kernels； - OS scheduler； - device driver。 其主要任務是： $$ \boxed{ ExecuteFast. } $$ --- ## 5.2 Semantic Control Plane $$ \mathcal C $$ 包括： - semantic parser； - causal graph builder； - AI relay； - coordinator AI； - verifier； - policy； - routing controller。 其主要任務是： $$ \boxed{ UnderstandEnoughToRouteAndCorrect. } $$ --- ## 5.3 基本分離 $$ \boxed{ \mathcal E \neq \mathcal C. } $$ 而： $$ \boxed{ CDI = \mathcal C \triangleright \mathcal E. } $$ 其中 $\triangleright$ 表示控制／治理關係，而非「完全取代」。 --- # 6. 第二核心命題：資料必須先被語義預分析 使用者提出的前提： > 資料 AI 要先解析過。 可以工程化成： $$ \boxed{ SemanticPreAnalysis. } $$ 輸入： $$ X=(Program,Data,Goal,RuntimeTrace,Constraints). $$ 輸出： $$ \mathcal G_C. $$ 其中： $$ \boxed{ \mathcal G_C=(V,E_D,E_C,E_S,E_R) } $$ - $V$ ：compute region／task； - $E_D$ ：data dependency； - $E_C$ ：control dependency； - $E_S$ ：side-effect dependency； - $E_R$ ：resource／runtime dependency。 --- # 7. 為什麼 semantic graph 不能只靠 LLM 猜？ 因為： $$ \text{語義合理} \neq \text{記憶體安全}. $$ AI 可以說： > A 和 B 看起來獨立。 但如果它們其實同時修改： $$ GlobalState_X, $$ 就可能產生 race。 所以： $$ \boxed{ SemanticAnalysis + StaticAnalysis + DynamicTrace + Tests } $$ 應共同建立可信依賴圖。 因此本文不主張： $$ LLMGuess \Rightarrow SafeParallelization. $$ --- # 8. 第三核心命題：AI 最有價值的是補充高階依賴 Compiler 已能分析很多： - RAW； - WAR； - WAW； - loop dependence； - alias； - control flow。 但高階程式目的有時超出傳統 pass 的表示。 例如： ```text UpdateWeatherVisuals() RefreshInventoryUI() CalculateNPCPaths() ``` AI 可能從： - function semantics； - source comments； - tests； - call graph； - runtime trace； 推斷： > 三者屬於不同工作域。 然而該推斷仍必須交由： $$ StaticCheck + RuntimeInvariant + A/BTest $$ 驗證。 因此 AI 的角色是： $$ \boxed{ ParallelizationCandidateGenerator, } $$ 而不是： $$ \boxed{ ParallelizationOracle. } $$ --- # 9. Green／Yellow／Red 三區模型 CDI 將 compute region 暫分： ## Green 已證明依賴分離： $$ E_i\perp E_j. $$ 可安全： $$ E_i\parallel E_j. $$ --- ## Yellow 可能獨立，但存在： - hidden state； - weak dependency； - timing sensitivity； - uncertain side effect。 允許： $$ \boxed{ Speculate \rightarrow Verify \rightarrow Commit/Rollback. } $$ --- ## Red 存在強因果序列： $$ E_i\prec E_j. $$ 禁止強行平行化。 --- # 10. 從「能不能平行」轉成「何時值得平行」 即使： $$ ParallelSafe=1, $$ 也不表示： $$ ParallelUseful=1. $$ 若 task 很短： $$ CoordinationCost > ComputeGain. $$ 反而更慢。 所以 CDI 需要： $$ \boxed{ Utility(E_i) = Gain - Coordination - Synchronization - AIOverhead - Risk. } $$ 只在： $$ Utility(E_i)>0 $$ 時改變 execution plan。 --- # 11. 這正是 ACR 能進入計算架構的位置 Adaptive Cognitive Runtime（ACR）原則是： $$ R_t=f(T,U,H,E_t). $$ 並尋找： $$ r^* = \arg\min_r C(r) \quad \text{s.t.} \quad Q(r)\ge Q_{\min}. $$ 將其映射到 CDI： $$ \boxed{ r_i(t) = f( Risk, Uncertainty, Drift, Conflict, Novelty, DependencyDensity ). } $$ 因此正常 compute region： $$ R_0. $$ 只讀： - digest； - version； - latency； - pass/fail； - anomaly score。 若發生： $$ Conflict\uparrow, $$ 才： $$ R_0\rightarrow R_1. $$ 再嚴重： $$ R_1\rightarrow R_2. $$ --- # 12. AI 中繼不是多餘層，而是 scale boundary 如果每個 worker 都直接回報統籌 AI： $$ W_i\rightarrow G, \qquad i=1,\dots,N, $$ 則中央： $$ Load(G)\uparrow O(N) $$ 且語義資訊量可能更快增長。 因此後續系列將正式引入： $$ \boxed{ RelayAI. } $$ 拓撲： $$ Worker \rightarrow Relay \rightarrow Governor. $$ Relay 先處理： $$ \{ NOOP, LocalCommit, Retry, Reroute, Escalate \}. $$ 只有高價值例外才上行。 --- # 13. AI 垂直同步的預告 後續第二篇將定義： $$ \boxed{ AIVS = AI\ Vertical\ Synchronization. } $$ 其目的不是讓所有 worker 同時停下。 而是讓不同層級： $$ Worker \leftrightarrow Relay \leftrightarrow Governor $$ 只在必要的同步點交換足夠狀態。 暫定同步類型： $$ \boxed{ StateSync + CausalSync + SemanticSync + CommitSync + TopologySync. } $$ --- # 14. Candidate 不等於 Commit 今日多 AI 跨任務實驗已展示一個重要工程原型： $$ Candidate \neq Commit. $$ worker 可以： - 回錯； - stale； - 拒絕； - timeout。 但只要提交層仍驗證： $$ Accept(candidate,state), $$ 公共狀態可以保持有序。 映射到計算： $$ \boxed{ ComputedResult \neq CommittedProgramState. } $$ 這使 Yellow region 可以進行： $$ SpeculativeCompute $$ 而不立即污染正式狀態。 --- # 15. 計算結果的最小回報不需要自然語言 例如： ```yaml compute_report: region_id: physics/17 task_id: frame/842 input_epoch: 842 output_digest: sha256:... dependency_status: valid invariant_status: pass latency_ms: 3.2 anomaly_score: 0.02 confidence: 0.99 ``` Relay AI 對絕大多數正常事件甚至可以： $$ NOOP. $$ 因此： $$ \boxed{ AIInteraction } $$ 不必等於： $$ \boxed{ LongNaturalLanguageGeneration. } $$ --- # 16. Token 成本模型 令： - $N_o$ ：raw operation 數； - $N_s$ ：同步點數； - $p_e$ ：升級比例； - $C_0$ ：低階檢查成本； - $C_1$ ：中階 AI 成本； - $C_G$ ：中央統籌成本。 則： $$ C_{AI} \approx N_s C_0 + p_eN_sC_1 + C_G. $$ 若： $$ N_s\ll N_o $$ 且： $$ p_e\ll1, $$ 則理想上： $$ \boxed{ C_{AI} \not\propto N_o. } $$ 也就是 AI 成本與 raw operation count 解耦。 --- # 17. 認知同步率 定義： $$ \boxed{ \rho_c = \frac{N_{AI\ inspected}} {N_{raw\ transitions}}. } $$ CDI 並不追求： $$ \rho_c\rightarrow1. $$ 反而希望： $$ \boxed{ \min \rho_c } $$ subject to： $$ Reliability\ge R_{\min}. $$ 這是認知比例性在 computation supervision 上的直接形式。 --- # 18. 從因果點到因果流 既有因果流研究提出： 傳統思路： $$ \text{A 是否影響 B？} $$ 對大量點形成 pairwise relation。 因果流思路則先找： $$ F_1,F_2,\ldots,F_k. $$ 再問： > 此工作在哪條主要流？ 本文將其改造成 runtime 問題： $$ \boxed{ Region \rightarrow FlowClassification \rightarrow ExecutionRoute. } $$ --- # 19. Causal Misalignment 若 task $x$ 應屬： $$ F_i, $$ 卻因 stale state、錯誤 routing 或 dependency drift 進入： $$ F_j, $$ 定義： $$ \boxed{ CausalMisalignment(x). } $$ Relay 可採： $$ \{ Reject, Reroute, Recompute, Serialize, Escalate \}. $$ 這就是「把計算因果拉回來」的工程化版本。 --- # 20. 計算 24／72 範式在這裡的新角色 既有 24 範式： $$ \mathfrak P_{24} = \mathfrak B_2 \times \mathfrak U_4 \times \mathfrak O_3 $$ 描述： - 底空間； - 更新組織； - 觀察模式。 72 候選空間再加入： $$ \mathfrak L_3 = \{\mathsf F,\mathsf K,\mathsf Q\} $$ 形成： $$ \mathfrak P_{72}. $$ 本文暫不重新主張其完備性。 本文提出新的工程用途： $$ \boxed{ Paradigm \rightarrow RoutingCoordinate. } $$ --- # 21. Program 不一定只有一個範式 對程式： $$ P $$ 可切成： $$ E_1,\ldots,E_n. $$ 得到： $$ \boxed{ \mathbf p(P) = (p_1,\ldots,p_n). } $$ 不同 region 可以： $$ p_i\rightarrow CPU, $$ $$ p_j\rightarrow GPU, $$ $$ p_k\rightarrow NPU, $$ 或： $$ p_l\rightarrow SequentialMainThread. $$ --- # 22. 24／72 因此可能從分類學變成 Runtime Routing Language 這是本系列的一個待測新命題： > 計算範式不是只用來描述「這是什麼計算」，也可能被用來描述「這段計算應該被送到哪種執行結構」。 形式化： $$ \boxed{ Route: \mathfrak P \times ResourceState \times DependencyGraph \rightarrow ExecutionPlan. } $$ 第四篇將正式處理。 --- # 23. 與 LLVM Polly 的關係 LLVM Polly 已證明： - dependence analysis； - polyhedral model； - automatic OpenMP generation； 可以自動找出部分可平行區域。 因此 CDI 不聲稱： > 自動 parallelization 是新的。 CDI 的新研究點是： $$ \boxed{ CompilerDependence + SemanticIntent + RuntimeEvidence + AdaptiveAISupervision. } $$ --- # 24. 與 Task Graph 的關係 task graph 早已存在。 本文不是重新發明 DAG。 CDI 問的是： > DAG 是否可以被 AI 依高階語義、runtime evidence、異常與工作目的動態重構？ 所以： $$ \boxed{ StaticTaskGraph \rightarrow AdaptiveSemanticCausalGraph. } $$ 是研究方向。 --- # 25. 與 Direct3D 12 Work Graphs 的關係 Direct3D 12 Work Graphs 已展示： $$ GPUWork \rightarrow GenerateMoreGPUWork $$ 且 system 可管理： - scheduling； - task-to-task data flow； - memory。 這說明： $$ \boxed{ DynamicWorkGraph } $$ 已不是純理論概念。 CDI 並不取代 Work Graph。 可能的關係是： $$ AI \rightarrow HighLevelGraphPolicy \rightarrow WorkGraph/TaskGraph. $$ --- # 26. 與 2026 Compiler–LLM Cooperation 的關係 2026 年已有研究將： - LLM optimization agents； - compiler passes； - testing agent； - guiding orchestrator； 結合成多層 code optimization 系統。 這類研究的重要意義是： $$ \boxed{ LLMReasoning + CompilerCorrectness } $$ 比： $$ LLMOnly $$ 更合理。 本文與之相容。 但 CDI 更偏 runtime governance： > 不只在 compile time 產生更快程式，而是在執行期間維持因果、同步、路由與回退。 --- # 27. 與 Agent JIT Scheduling 的關係 2026 年 Agent JIT work 已提出： - plan generation； - parallelization strategy search； - precondition/postcondition invariant； - cost-aware scheduling。 這提供另一個重要交會點： $$ \boxed{ AI\ planning + Invariant-enforced\ execution. } $$ CDI 將類似思想從 web-agent tool workflow 擴展到更一般 computation domain。 但此擴展目前仍是本文假說，不是既有工作已證明。 --- # 28. 為什麼遊戲是好 benchmark？ 遊戲通常同時具有： - real-time deadline； - rendering； - physics； - NPC； - asset streaming； - UI； - audio； - network； - scripting； - save state。 因此： $$ \boxed{ Game } $$ 本身就是多因果流系統。 --- # 29. 遊戲又有非常明顯的串行瓶頸 尤其舊 engine 可能大量工作集中： $$ MainLoop. $$ 但： $$ MainLoopSerialization $$ 不一定全部是： $$ CausalNecessity. $$ 因此非常適合測： $$ \boxed{ ImplementationSerialization - NecessarySerialization. } $$ --- # 30. 但不能承諾所有舊遊戲都能自動多核化 如果： - global mutable state 高度耦合； - physics 與 gameplay 有 frame-exact dependency； - engine 使用 undocumented timing assumptions； - binary only； - race condition 高風險； 則： $$ ParallelizableFraction $$ 可能很低。 因此： $$ \boxed{ AIAnalysis \neq UnlimitedSpeedup. } $$ --- # 31. Source-Visible 程式應該是第一個 MVP 由易到難： $$ L_1: SourceVisible $$ $$ L_2: TraceVisible $$ $$ L_3: BinaryOpaque. $$ --- # 32. Level 1：Source Visible AI 可以讀： - source； - AST； - call graph； - tests； - profiling； - compiler reports。 這時最容易建立： $$ \mathcal G_C. $$ --- # 33. Level 2：Runtime Trace 無完整 source 時： $$ \hat{\mathcal G}_C = Infer( CallTrace, MemoryTrace, Timing, Locks, IO, Counters ). $$ 只對高信心 region 改變 scheduling。 --- # 34. Level 3：Binary Opaque 只適合較保守方法： - process-level offload； - I/O prefetch； - sidecar compute； - speculative external work； - API interception； - sandbox replay。 不應任意重排 instruction。 --- # 35. Correctness 必須比 Speedup 優先 若原程式： $$ P_0(x)=y, $$ 改寫： $$ P_1(x)=y'. $$ 要求： $$ \boxed{ y'\equiv_{\mathcal T}y } $$ 其中： $$ \mathcal T $$ 為預先定義 equivalence tests。 --- # 36. 遊戲不能只比較畫面 FPS 還要比較： - save state； - physics state； - RNG behavior； - NPC state； - network state； - event ordering； - replay determinism。 有些遊戲本來非 deterministic，因此 equivalence 必須定義容忍域。 --- # 37. Shadow Execution 最安全的早期策略： $$ Original \parallel OptimizedShadow. $$ shadow 不控制正式結果。 比較： $$ Digest_0 \stackrel{?}{\sim} Digest_1. $$ 只有長時間一致才： $$ Promote. $$ --- # 38. Candidate／Commit 對 Runtime Parallelization 的價值 對 Yellow region： $$ ParallelizedResult $$ 只是： $$ Candidate. $$ 經： $$ Verify $$ 後才： $$ Commit. $$ 這使 AI 產生的高階平行化計畫不必具有先驗絕對正確性。 系統安全性可以被部分移到： $$ \boxed{ CommitBoundary. } $$ --- # 39. 這也解釋為什麼 AI Relay 很重要 如果每個 speculative result 都由中央 AI 深度驗證： $$ C_G\rightarrow huge. $$ Relay 可以先做： - schema； - state version； - invariant； - checksum； - low-cost anomaly detection。 只有 ambiguous case： $$ \rightarrow G. $$ --- # 40. 統一控制迴圈 $$ \boxed{ Observe \rightarrow Classify \rightarrow Route \rightarrow Execute \rightarrow Verify \rightarrow Commit \rightarrow Observe. } $$ --- # 41. CDI 與 STDI 的尺度同構 既有 STDI： $$ Intent \rightarrow WorldModel \rightarrow StationRouting \rightarrow PhysicalAction \rightarrow Evidence. $$ CDI： $$ \boxed{ Intent \rightarrow ComputeModel \rightarrow ComputeRouting \rightarrow KernelExecution \rightarrow Evidence. } $$ --- # 42. 但 CDI 不等於 STDI STDI 管理： $$ PhysicalDomain. $$ CDI 管理： $$ ComputationalDomain. $$ 其 resource node 可以是： - core； - thread； - GPU queue； - process； - remote worker； - NPU； - compiler pass。 --- # 43. Computational Domain 定義： $$ \boxed{ D_C = ( Tasks, States, Resources, Dependencies, Policies, Evidence ). } $$ --- # 44. CDI $$ \boxed{ CDI = ( Model_C, Router, Observer, Relay, Governor, Verifier, Committer ). } $$ --- # 45. 最小演化 $$ D_C(t+1) = Commit( D_C(t), Action_t ). $$ 而： $$ Action_t = \Pi_{CDI}( Observation_t, Policy_t, Resource_t ). $$ --- # 46. AI 並非每輪必須輸出 Action 合法： $$ Action_t=NOOP. $$ 這是降低成本的核心。 --- # 47. 假說 H1：語義分析能增加可安全平行區域 在 source-visible benchmark 中： $$ ParallelRegions( Compiler+AI ) > ParallelRegions( CompilerOnly ) $$ 且 correctness tests 不下降。 若沒有增加： H1 失敗。 --- # 48. 假說 H2：Relay 能降低中央認知負載 比較： $$ Workers\rightarrow Governor $$ 與： $$ Workers\rightarrow Relays\rightarrow Governor. $$ 要求： $$ GovernorTokens\downarrow $$ 且： $$ ErrorDetection $$ 不顯著下降。 --- # 49. 假說 H3：Adaptive cognition 優於固定 AI 監督頻率 比較： - always-deep； - fixed-period； - anomaly-triggered ACR。 要求相同 reliability 下： $$ Cost_{ACR} < Cost_{fixed}. $$ --- # 50. 假說 H4：Candidate／Commit 能吸收推測式錯誤 引入 deliberate stale／wrong speculative result。 若： $$ InvalidCommitRate\approx0 $$ 而 throughput 仍改善， 支持 H4。 --- # 51. 假說 H5：部分舊式 main-loop serialization 可由 CDI 發現並安全拆分 選 source-available legacy-style game。 要求： $$ CPUUtilization_{multi} \uparrow $$ $$ FrameTime\downarrow $$ 且： $$ BehavioralEquivalence \ge Threshold. $$ --- # 52. 第一批 benchmark 不應用大型 AAA 遊戲 更合理的是： 1. 小型單執行緒模擬； 2. source-visible 2D game； 3. deterministic game loop； 4. asset-heavy application； 5. mixed CPU/GPU workload。 先確定： $$ Semantics $$ 再談： $$ Scale. $$ --- # 53. 主要失敗模式 1. AI 誤判 dependency； 2. hidden global state； 3. alias analysis 失敗； 4. false parallelism； 5. synchronization overhead； 6. excessive AI cost； 7. stale relay； 8. divergent task graph； 9. speculative side effect 已不可回退； 10. verifier false negative； 11. verifier false positive； 12. performance regression； 13. nondeterministic Heisenbug； 14. topology thrashing； 15. central governor bottleneck。 --- # 54. 安全原則 ## S1 AI 建議： $$ \neq $$ AI 直接 commit。 ## S2 高風險 state mutation： $$ VerifyBeforeCommit. $$ ## S3 不可逆 side effect： $$ DoNotSpeculate $$ 除非 sandbox。 ## S4 無法證明獨立： $$ Serialize. $$ ## S5 任何自動優化： $$ Rollbackable. $$ --- # 55. 本文與「AI 全面接管電腦」的差別 本文不是： $$ AI \rightarrow EveryInstruction. $$ 而是： $$ \boxed{ AI \rightarrow FewHighValueControlPoints. } $$ --- # 56. 這其實是一種 Metacomputation 傳統 computation： $$ Calculate(x). $$ CDI： $$ \boxed{ DecideHowToCalculate(x). } $$ 再： $$ ObserveWhetherCalculationStillMakesSense. $$ --- # 57. 「智能」真正介入的位置 不是： > 每一個乘法。 而是： > 哪個乘法群應該在哪裡、何時、以什麼依賴關係被執行？ 這是不同層級的問題。 --- # 58. 從 AI 加速變成 AI 治理計算 所以本文最終將概念從： $$ AIAcceleration $$ 提升為： $$ \boxed{ AIGovernedComputation. } $$ 加速只是可能結果之一。 其他結果還可能是： - correctness； - recovery； - energy saving； - lower latency； - fault isolation； - adaptive resource use。 --- # 59. 系列下一篇 下一篇正式處理： # 《AI 垂直同步》 ## 分層中繼、認知比例性與低成本因果一致 核心問題： > 當 compute worker 數量持續增加時，如何避免中央 AI 被 telemetry 與 context 淹沒？ 將正式定義： $$ AIVS. $$ --- # 60. 結論 傳統計算架構早已擁有成熟的： - scheduler； - thread pool； - compiler； - task graph； - GPU pipeline。 因此 AI 的價值不必建立在： > 重新發明這些東西。 更合理的方向是補充傳統系統長期缺乏的： $$ \boxed{ HighLevelSemanticCausalAwareness. } $$ 本文提出： $$ \boxed{ TraditionalCompute + AISemanticControlPlane } $$ 而不是： $$ TraditionalCompute \rightarrow LLMCompute. $$ 其完整形式為： $$ \boxed{ Program/Data/Goal \rightarrow SemanticPreAnalysis \rightarrow CausalComputeGraph \rightarrow Route \rightarrow TraditionalExecution \rightarrow AdaptiveObservation \rightarrow Verify \rightarrow Commit. } $$ 因此，一個未來的 AI-native computation runtime 可能不是讓 AI 親自完成所有運算，而是讓計算機第一次具備一個能回答以下問題的高階控制面： > **我現在正在算什麼？** > **為什麼這一段必須在這裡算？** > **哪些工作其實可以同時算？** > **哪條結果已經偏離它應有的因果位置？** > **什麼情況下值得使用更多認知去重新安排計算？** 如果這些問題可以用低頻、分層、可驗證的 AI supervision 解決，那麼 AI 對傳統應用與遊戲的真正加速價值，可能不在「替代每一個計算核心」，而在於： $$ \boxed{ \text{重新看見、重新組織並持續校正整個計算域。} } $$ --- ## 參考資料 ### 既有內部研究線 1. Neo.K. 《計算的二十四重範式》正式版 v4.0，2026。 2. Neo.K. 《從二十四重計算形態學到七十二格計算動力學》，2026。 3. Neo.K. 《從因果點到因果流：AI 視角計算的線性複雜度重構》，2026。 4. Neo.K. 《適度認知論：智能為什麼不應對每一個問題都使用最大思考深度》，2026。 5. Neo.K / Aletheia. 《Adaptive Cognitive Runtime（ACR）工程白皮書》，2026。 6. Neo.K. 《時空間支配型 AI：從單體具身智能到持續性時空域治理》，2026。 7. Neo.K / Codex. 《從線性接力到語義合成：以 AI Board 與 CTCL 觀測跨任務多 AI 持續執行》，2026。 8. Neo.K / Codex. 《Token 不是狀態：協議化語義交換與跨任務 AI 的分散式認知》，2026。 9. EveMissLab. *MSSP Game Computer Runtime*, v0.8.0, 2026。 ### 公開技術與研究參照（2026-08-10 重新查閱） 10. LLVM Project. *Polly Documentation*, 23.0.0git. 11. Microsoft. *Windows Thread Pool / Threading and Async Programming*. 12. Microsoft. *.NET TaskScheduler*. 13. Microsoft. *Direct3D 12 Work Graphs*, Windows 11 24H2 / WDDM 3.2. 14. Mikek, B. et al. *Agentic Code Optimization via Compiler-LLM Cooperation*. arXiv:2604.04238, 2026. 15. Winston, C. et al. *Agent JIT Compilation for Latency-Optimizing Web Agent Planning and Scheduling*. arXiv:2605.21470, 2026. 16. Li, J. et al. *FlowCompile: An Optimizing Compiler for Structured LLM Workflows*. arXiv:2605.13647, 2026. --- ## 版本紀錄 - **v0.1 / 2026-08-10**：建立 CDI 母命題、Execution Plane / Semantic Control Plane 分離、Semantic Pre-Analysis、Causal Compute Graph、Green/Yellow/Red 區域、ACR supervision、Relay 預告、24/72 routing 介面、legacy game benchmark 與五組可反駁假說。