載體中立的計算容器理論

Q: 1. 問題：為什麼「計算」總被默認成某一種機器？

在多數系統設計中，計算通常隱含為：

Q: 67. 下一步：為什麼這套東西越來越眼熟？

到目前為止，我們已從第一原理逐步加入：

——從算法選擇到異質計算載體聯合調度

Series: Adaptive Epistemic Systems Series
Paper: 6 / 11
Version: v0.1
Language: zh-TW
Status: Complete Draft / Canonical UTF-8 Source

摘要

當智能系統已經具備世界模型、可執行符號層、外部記憶、算法庫與可重用方法鏈之後，仍存在一個更底層但常被隱含固定的假設：算法最終都會在某一種預設的計算架構上執行。這種假設在傳統軟體系統中通常是合理的，因為運算平台往往預先固定；但對於希望支援異質計算、外部工具調度、專用硬體、生物計算、量子計算或其他未來計算載體的自適應智能系統而言，這個假設會限制架構的通用性。

本文提出「載體中立計算容器」模型。系統不直接將「計算」等同於某一種特定機器，而是將任何能夠接受可表示輸入、執行有效狀態轉換、並輸出可讀結果的執行環境抽象為：

\Gamma_i

。

每個計算容器具有自己的輸入語言、輸出域、狀態空間、誤差模型、成本模型、延遲、能耗、精度、並行度、依賴與可用性。算法 $A_i$ 與計算容器 $\Gamma_j$ 因此不再被視為同一層概念，而形成：

(A_i,\Gamma_j)

的聯合可執行實例。

本文將算法選擇問題從：

A^\ast = \arg\max_i U(A_i\mid Q)

升級為：

(A^\ast,\Gamma^\ast) = \arg\max_{A_i,\Gamma_j} U(A_i,\Gamma_j\mid Q)

並進一步討論異質容器協同、多容器工作流、編碼—執行—解碼映射、容器契約、結果校驗、載體失效、接口變更、成本漂移與新載體創造等問題。

本文核心主張是：

\boxed{ \text{intelligence architecture} \neq \text{computational substrate} }

以及：

\boxed{ \text{the same abstract capability may admit multiple physical realizations} }

。

在此框架下，智能系統可將不同計算載體視為可被學習、比較、選擇與重構的能力節點，而不是不可變的底層前提。

關鍵詞： 計算容器、載體中立、異質計算、算法調度、計算載體、量子計算、生物計算、能力模型、執行映射、聯合優化

1. 問題：為什麼「計算」總被默認成某一種機器？

在多數系統設計中，計算通常隱含為：

\text{program} \rightarrow \text{processor} \rightarrow \text{result}

。

若智能系統只需要部署於單一固定平台，這並不構成問題。

但若希望系統可以使用：

\text{classical digital compute}

\text{accelerators}

\text{quantum systems}

\text{biological systems}

\text{analog systems}

甚至：

\text{unknown future substrates}

則必須將「方法」與「載體」拆開。

2. 算法與載體是兩個不同變數

定義：

A_i

為抽象算法或方法；

\Gamma_j

為計算容器。

同一個：

A_i

可能無法直接在所有：

\Gamma_j

上執行。

因此需要：

Compatible(A_i,\Gamma_j)

。

若：

Compatible(A_i,\Gamma_j)=True

則可建立：

Exec(A_i,\Gamma_j)

。

這使：

\boxed{ \text{algorithm} \neq \text{implementation} }

。

3. 計算容器的最小定義

一個容器可以表示為：

\Gamma_i = ( L_i, I_i, O_i, S_i, R_i, C_i, E_i, V_i )

其中：

L_i

是可接受的操作語言；

I_i

是輸入域；

O_i

是輸出域；

S_i

是內部狀態空間；

R_i

是資源模型；

C_i

是成本模型；

E_i

是誤差／失敗模型；

V_i

是版本與可用性狀態。

因此，容器並不需要具有相同的指令架構。

4. 更一般的計算定義

若要避免把所有計算都預設成傳統 instruction execution，可採用：

\boxed{ \Gamma: (X_0,I,\Theta) \mapsto (X_f,O) }

其中：

X_0

為初始狀態；

I

為輸入；

\Theta

為容器條件；

X_f

為演化後狀態；

O

為可讀出的結果。

因此「計算」只需要滿足：

\text{representable input}

\text{valid transformation}

\text{readable output}

三個條件。

5. 上層 canonical state 與底層載體分離

Paper 03 已建立：

Z

作為 canonical symbolic state。

因此不同容器不需要共享原生格式。

只需存在：

\phi_i: Z_{\mathrm{task}} \rightarrow I_i

將上層任務映射到容器輸入；

以及：

\psi_i: O_i \rightarrow Z_{\mathrm{result}}

將容器結果映射回 canonical state。

完整執行為：

Z \xrightarrow{\phi_i} I_i \xrightarrow{\Gamma_i} O_i \xrightarrow{\psi_i} Z'

。

6. 編碼、執行與解碼

對容器：

\Gamma_i

可以定義：

Encode_i

Execute_i

Decode_i

三層。

即：

Result = Decode_i \left( Execute_i \left( Encode_i(Q) \right) \right)

。

這使不同載體的底層差異被封裝於 adapter 層。

7. 編碼成本不能被忽略

某個載體執行本體非常快，但：

C_{\mathrm{encode}}

與：

C_{\mathrm{decode}}

可能非常高。

因此總成本應是：

C_{\mathrm{total}} = C_{\mathrm{encode}} + C_{\mathrm{execute}} + C_{\mathrm{decode}} + C_{\mathrm{verify}}

。

所以不能只比較：

C_{\mathrm{execute}}

。

8. 算法—容器聯合效用

定義：

U(A_i,\Gamma_j\mid Q)

表示算法與容器組合對任務 $Q$ 的效用。

可寫成：

U = \alpha P_{\mathrm{success}} + \beta Q_{\mathrm{precision}} + \gamma Reusability - \delta C_{\mathrm{time}} - \epsilon C_{\mathrm{energy}} - \zeta C_{\mathrm{money}} - \eta Risk

。

因此：

(A^\ast,\Gamma^\ast) = \arg\max_{A_i,\Gamma_j} U(A_i,\Gamma_j\mid Q)

。

9. 不存在永遠最好的載體

若任務：

Q_1

重視精度，而：

Q_2

重視延遲，則：

\Gamma^\ast(Q_1) \neq \Gamma^\ast(Q_2)

是正常情況。

因此：

\boxed{ \text{best substrate} = \text{task-conditional} }

而非全域固定。

10. 功能等價與成本不等價

可能存在：

(A_1,\Gamma_a)

與：

(A_2,\Gamma_b)

都能完成：

Q\mapsto R

。

則：

(A_1,\Gamma_a) \sim_Q (A_2,\Gamma_b)

表示任務層功能等價。

但可能：

Cost_a\neq Cost_b

Latency_a\neq Latency_b

Energy_a\neq Energy_b

Reliability_a\neq Reliability_b

。

因此功能等價不代表工程等價。

11. 容器也是能力節點

定義：

v_{\Gamma_i} \in V_{\mathrm{capability}}

。

則容器可與 Algorithm、TaskType、InputSchema、OutputSchema、RiskClass 建立關係。

例如：

Supports(\Gamma_i,A_j)

EfficientFor(\Gamma_i,Q_k)

Requires(\Gamma_i,D_l)

。

12. 容器模型

系統不只需要知道容器存在。

還需保存：

M_{\Gamma_i} = ( Capabilities, Constraints, Cost, Error, Interface, StateSemantics, Availability )

。

因此：

Know(\Gamma_i)

不等於：

KnowHowToUse(\Gamma_i)

。

13. 介面契約

每個容器應具有：

Contract(\Gamma_i) = ( InputContract, OutputContract, ResourceContract, FailureContract )

。

若：

InputContract

不滿足，則：

Execute(\Gamma_i)

不應被允許。

14. 容器失敗模式

不同載體可能具有不同：

FailureMode(\Gamma_i)

。

例如 timeout、numerical instability、measurement noise、hardware unavailable、interface mismatch。

因此調度器需要建模：

P(Failure\mid \Gamma_i,Q)

。

15. 容器新鮮度

容器接口與可用性也會變。

因此需要：

Freshness(\Gamma_i)

以及：

LastVerified(\Gamma_i)

。

若：

InterfaceChanged(\Gamma_i)=True

則所有依賴：

A_j\rightarrow\Gamma_i

都應提高：

T_{A_j}

。

16. 容器張力

可定義：

T_{\Gamma_i} = \alpha InterfaceChange_i + \beta FailureRate_i + \gamma CostDrift_i + \delta AvailabilityDrift_i + \epsilon SecurityChange_i

。

若：

T_{\Gamma_i}>\theta_i

則需要：

Revalidate(\Gamma_i)

。

17. 算法實現是二階節點

抽象算法：

A_i

與載體：

\Gamma_j

結合後，可形成：

Impl_{ij} = Implementation(A_i,\Gamma_j)

。

因此：

Impl_{ij}

本身也可以成為能力節點。

其屬性包括 Performance、Cost、Version、Compiler、Adapter、Reliability。

18. 編譯不必只表示傳統 compiler

定義：

\Phi(A_i,\Gamma_j)

為「將抽象算法映射成特定容器可執行過程」。

因此：

Executable_{ij} = \Phi(A_i,\Gamma_j)

。

此：

\Phi

可以是 compilation、translation、encoding、protocol construction、physical preparation 等。

19. 一個算法可能需要多個容器

有些任務不是：

A_i\rightarrow\Gamma_j

一對一。

而是：

A_i \rightarrow \{ \Gamma_1,\Gamma_2,\ldots,\Gamma_n \}

。

因此算法實現可以是：

ImplementationGraph(A_i)

。

20. 異質容器協同

任務：

Q

可拆成：

Q \rightarrow \{ q_1,q_2,q_3 \}

。

然後：

q_1\rightarrow\Gamma_a

q_2\rightarrow\Gamma_b

q_3\rightarrow\Gamma_c

。

最後：

R = Merge(R_a,R_b,R_c)

。

這形成：

\boxed{ \text{heterogeneous cooperative computation} }

。

21. 並行異質執行

若子任務互相獨立：

q_i\perp q_j

則可：

\Gamma_i \parallel \Gamma_j

。

總延遲近似：

T_{\mathrm{total}} \approx \max_i T_i + T_{\mathrm{merge}}

而非：

\sum_i T_i

。

22. 串行異質執行

若：

q_{i+1}

依賴：

q_i

則：

\Gamma_1 \rightarrow \Gamma_2 \rightarrow \Gamma_3

。

因此方法鏈：

W_k

現在不只保存算法序列，也保存容器序列。

23. 條件式容器路由

若：

Result(\Gamma_a)>\theta

則路由至：

\Gamma_b

否則：

\Gamma_c

。

可寫成：

\Gamma_a \rightarrow \begin{cases} \Gamma_b, & r>\theta\\ \Gamma_c, & r\le\theta \end{cases}

。

24. 多容器方法鏈

一般形式：

W_k = \left[ (A_1,\Gamma_1), (A_2,\Gamma_2), \ldots, (A_n,\Gamma_n) \right]

。

因此 Paper 05 的 workflow 升級為：

\boxed{ \text{algorithm-substrate workflow} }

。

25. 調度器的升級

原本：

Scheduler: Q \rightarrow A_i

現在變成：

Scheduler: Q \rightarrow (A_i,\Gamma_j)

。

甚至對分解任務：

Scheduler(Q) = \{ (q_k,A_k,\Gamma_k) \}_{k=1}^{m}

。

26. 容器選擇也應學習

系統執行後可更新：

P( Success \mid A_i,\Gamma_j,Q )

。

因此：

History(A_i,\Gamma_j)

是能力記憶的一部分。

同一算法在不同容器上的實際表現，可以持續被學習。

27. 能力與執行位置分離

系統可以：

Know(A_i)=True

但：

CanExecute(A_i,\Gamma_{\mathrm{local}})=False

。

同時：

CanExecute(A_i,\Gamma_{\mathrm{remote}})=True

。

因此：

\boxed{ \text{knowledge location} \neq \text{execution location} }

。

28. 決策位置與執行位置也可以分離

更一般地：

DecisionLocation \neq ExecutionLocation

。

上層系統可以決定：

Use(A_i,\Gamma_j)

而不必自己執行全部底層計算。

這使 intelligence control layer 與 physical execution layer 分離。

29. 容器不必是機器

若某外部系統接受輸入、執行可重複轉換並輸出結果，也可被抽象為：

\Gamma_i

。

因此：

\Gamma_i

可代表 hardware、software runtime、specialized service、physical process、biological process。

關鍵不是名稱，而是契約與可讀狀態轉換。

30. 物理載體特性可以成為調度變數

不同載體可能具有：

Energy(\Gamma_i)

Heat(\Gamma_i)

Noise(\Gamma_i)

Parallelism(\Gamma_i)

PhysicalLatency(\Gamma_i)

。

因此智能系統可以將物理成本納入：

U(A_i,\Gamma_j\mid Q)

。

31. 載體中立不代表忽略物理

載體中立不是：

\text{all substrates are equivalent}

。

恰恰相反，它允許系統顯式比較不同物理條件。

因此：

\boxed{ \text{substrate-neutral abstraction} \neq \text{substrate-blind optimization} }

。

32. 精度與概率誤差

某些載體結果可能具有：

P(O\mid I,\Gamma_i)

而非 deterministic output。

因此 Verify 層必須根據容器誤差模型判斷結果。

例如：

Confidence(Result) = f \left( ContainerError, ExecutionHistory, Observation \right)

。

33. 重複執行與容錯

若：

P(Failure\mid\Gamma_i)

較高，可執行：

n

次重複：

R_1,\ldots,R_n

再聚合：

R^\ast = Aggregate(R_1,\ldots,R_n)

。

因此調度策略可把重複執行視為可選成本。

34. 跨容器驗證

一個容器的結果可以由另一容器驗證。

例如：

\Gamma_a \rightarrow Result \rightarrow \Gamma_b^{\mathrm{verify}}

。

若：

Agree(\Gamma_a,\Gamma_b)

則可信度提高。

這形成：

\boxed{ \text{cross-substrate verification} }

。

35. 但不同載體的錯誤可能相關

不能假設：

Error(\Gamma_a) \perp Error(\Gamma_b)

。

若兩者使用相同輸入資料、相同錯誤假設或相同上游模型，則交叉驗證未必提供獨立證據。

因此 provenance 仍然重要。

36. 容器選擇中的公平比較

比較：

\Gamma_a

與：

\Gamma_b

時，需要控制 InputQuality、Algorithm、VerificationBudget、TaskDefinition。

否則觀察到的差異可能其實來自算法不同。

37. 算法差異與載體差異需要拆開

總性能：

Perf = F(A,\Gamma)

。

因此若：

Perf_1>Perf_2

不能直接判斷：

A_1>A_2

或：

\Gamma_1>\Gamma_2

。

需要 factorial comparison：

(A_1,\Gamma_1)

(A_1,\Gamma_2)

(A_2,\Gamma_1)

(A_2,\Gamma_2)

。

38. 容器可替換性測試

若兩個容器：

\Gamma_a

與：

\Gamma_b

對任務集合：

Q

滿足：

Behavior(\Gamma_a)\approx Behavior(\Gamma_b)

且：

Cost(\Gamma_a)\approx Cost(\Gamma_b)

則對該任務集可近似視為替換。

但此等價是：

\sim_Q

而非全域等價。

39. 新載體的加入

當新容器：

\Gamma_{\mathrm{new}}

被加入系統時，不需要重新設計整個世界模型。

只需建立：

M_{\Gamma_{\mathrm{new}}}

Encode_{\mathrm{new}}

Decode_{\mathrm{new}}

以及：

Compatible(A_i,\Gamma_{\mathrm{new}})

。

這是載體中立設計的重要工程收益。

40. 新算法與新載體是不同創新方向

如果：

\forall \Gamma_j, \quad U(A_i,\Gamma_j\mid Q)<\theta

不一定表示：

A_i

不好。

可能是：

\Gamma_j

都不適合。

因此有兩種創新：

Create(A_{\mathrm{new}})

與：

Create(\Gamma_{\mathrm{new}})

。

41. 同時創造方法與載體

最極端情況：

(A_{\mathrm{new}},\Gamma_{\mathrm{new}})

共同被設計。

因此能力增長可分為：

\boxed{ \text{algorithm innovation} }

與：

\boxed{ \text{substrate innovation} }

。

42. 新載體建立也需要成本判斷

即使理論上可創造：

\Gamma_{\mathrm{new}}

也不代表值得。

需要：

ExpectedCapabilityGain > DevelopmentCost

。

因此：

Create(\Gamma_{\mathrm{new}})

應是高成本決策。

43. 容器生命週期

可定義：

Discovered \rightarrow Modeled \rightarrow Validated \rightarrow Available \rightarrow Degraded \rightarrow Deprecated \rightarrow Retired

。

因此容器也具有：

\boxed{ \text{capability lifecycle} }

。

44. 容器版本與相容性

若：

\Gamma_i^{v1} \rightarrow \Gamma_i^{v2}

則需檢查：

Compatible(A_j,\Gamma_i^{v1})

是否仍推出：

Compatible(A_j,\Gamma_i^{v2})

。

不能假設版本升級自動保持語義相容。

45. 執行結果必須回到 canonical state

無論底層：

\Gamma_i

多特殊，結果最終都應轉換回：

Z

才能進入 WorldModel 或 CapabilityModel。

因此：

\boxed{ \text{substrate diversity below} + \text{canonical semantic unity above} }

是整體架構的核心。

46. 計算容器的 provenance

每個結果應保存：

Prov(Result) = ( Algorithm, Container, Version, Input, Time, Verification )

。

這使後續可以回答：

這個結果是用什麼方法、在哪個載體、哪個版本、什麼輸入下得到的？

47. 可重現性

若：

\Gamma_i

本質上 deterministic，則可要求：

Rerun(A_i,\Gamma_i,Q) \approx Result

。

若容器 stochastic，則可要求：

Distribution(Rerun) \approx ExpectedDistribution

。

因此可重現性必須依載體類型定義。

48. 異質計算工作流的風險

多容器系統可能產生：

\text{format mismatch}

\text{semantic drift}

\text{precision loss}

\text{latency amplification}

\text{error propagation}

。

因此中間狀態：

Z_k

也需要驗證。

49. 工作流中間契約

對：

(A_i,\Gamma_i) \rightarrow (A_{i+1},\Gamma_{i+1})

需要：

OutputContract_i \subseteq InputContract_{i+1}

。

若不滿足，則必須加入：

Adapter_{i\rightarrow i+1}

。

50. Adapter 也是能力節點

定義：

v_{Adapter} \in V_{\mathrm{capability}}

。

因此 Encode、Decode、Translate 本身也是可重用能力。

這意味著新載體加入後，不一定需要每個算法都重新設計。

51. 容器選擇的長期學習

若系統長期觀察：

H(\Gamma_i)

可估計：

ExpectedCost(\Gamma_i,Q)

ExpectedLatency(\Gamma_i,Q)

ExpectedFailure(\Gamma_i,Q)

。

因此：

\Gamma^\ast_t

可以隨時間改變。

52. 供應狀態會改變最佳解

如果：

Availability(\Gamma_i,t)

變化，則即使算法不變：

\Gamma^\ast_{t+1} \neq \Gamma^\ast_t

。

因此調度是動態問題，而不是靜態 mapping。

53. 計算資源價格也是狀態

若：

Price(\Gamma_i,t)

變化，則：

U(A_i,\Gamma_i\mid Q,t)

也會改變。

因此財務成本可以直接進入能力圖。

54. 能耗也是狀態

如果任務要求：

EnergyBudget<B

則：

\Gamma^\ast

必須滿足：

Energy(A_i,\Gamma_j)\le B

。

因此「更強」不必然等於「更適合」。

55. 延遲—成本—精度三角

可定義：

Objective = ( Latency, Cost, Precision )

。

不同任務對三者權重不同。

因此可能形成 Pareto frontier：

\mathcal{P} = \{ (A_i,\Gamma_j) \}

。

不存在唯一全域最佳。

56. 可驗證命題

命題一：聯合選擇優於固定載體

在異質任務集合上：

Utility_{\mathrm{joint}} > Utility_{\mathrm{fixed\ substrate}}

應至少在部分條件成立。

命題二：編碼成本會改變最佳載體

若忽略：

C_{\mathrm{encode}} + C_{\mathrm{decode}}

可能得到不同於總成本最優的：

\Gamma^\ast

。

命題三：多容器協同可降低總延遲或成本

對可分解任務：

Utility_{\mathrm{heterogeneous}} > Utility_{\mathrm{single}}

應在部分任務成立。

命題四：容器新鮮度可降低版本失配失敗

加入：

Freshness(\Gamma_i)

與：

Revalidate(\Gamma_i)

應降低：

CompatibilityFailure

。

命題五：載體替換不應破壞 canonical state

若 adapter 正確，替換：

\Gamma_a \rightarrow \Gamma_b

不應導致：

D_Z(Z_{\mathrm{before}},Z_{\mathrm{after}})

出現不合理增長。

57. 實驗設計草案

建立多種容器模擬：

\Gamma_1 = \text{low latency / high cost}

\Gamma_2 = \text{high latency / low cost}

\Gamma_3 = \text{probabilistic / high parallelism}

\Gamma_4 = \text{specialized / narrow domain}

。

建立算法：

A_1,\ldots,A_n

與任務：

Q_1,\ldots,Q_m

。

比較：

S_1 = \text{fixed substrate}

S_2 = \text{algorithm selection only}

S_3 = \text{joint algorithm-substrate selection}

。

測量 SuccessRate、Latency、MoneyCost、EnergyCost、VerificationCost、CompatibilityFailure 與 TotalUtility。

58. 失敗模式：抽象過度

若：

\Gamma_i

被抽象得太統一，系統可能忽略真正關鍵的物理差異。

因此：

\boxed{ \text{uniform interface} \neq \text{uniform semantics} }

。

59. 失敗模式：容器能力被錯誤估計

若：

CapabilityModel(\Gamma_i)

不準確，調度器可能持續選錯容器。

因此容器模型本身需要驗證與更新。

60. 失敗模式：遷移成本被忽略

從：

\Gamma_a

切換至：

\Gamma_b

可能需要：

MigrationCost

。

因此真正效用應包含：

C_{\mathrm{migration}}

。

61. 失敗模式：跨載體結果語義不一致

即使兩個容器都輸出：

x=0.9

也不代表：

Meaning_{\Gamma_a}(0.9) = Meaning_{\Gamma_b}(0.9)

。

因此：

Decode_i

必須保留語義。

62. 失敗模式：驗證器與執行器同源錯誤

若 Verifier 與 Executor 共享相同錯誤來源，可能形成假驗證。

因此需要考慮：

ErrorCorrelation

。

63. 失敗模式：最便宜路線導致長期能力退化

若調度器只最小化：

Cost

可能長期偏好低品質容器。

因此：

U

必須同時包含品質、風險與學習價值。

64. 能力增長的雙軸

Paper 05 建立：

\text{method growth}

。

Paper 06 新增：

\text{substrate growth}

。

因此：

\boxed{ \text{Capability Growth} = \text{Algorithmic Expansion} + \text{Substrate Expansion} }

。

65. 對智能架構的更高階抽象

現在整體系統可以寫成：

\mathfrak{S} = ( G, Z, M, \mathcal{A}, \mathcal{W}, \Gamma, I, U, R, T )

。

其中：

G

是世界圖；

Z

是 canonical 符號；

M

是記憶；

\mathcal{A}

是算法庫；

\mathcal{W}

是方法鏈；

\Gamma

是計算容器集合；

I

是輸入；

U

是更新；

R

是 rendering；

T

是更新張力。

66. 完整執行循環

任務：

Q

進入後：

Q \rightarrow Understand \rightarrow Decompose \rightarrow Retrieve \rightarrow Select(A,\Gamma) \rightarrow Encode \rightarrow Execute \rightarrow Decode \rightarrow Verify \rightarrow Commit \rightarrow Learn

。

因此：

\boxed{ \text{task solving} = \text{semantic planning} + \text{method selection} + \text{substrate selection} + \text{verified execution} }

。

67. 下一步：為什麼這套東西越來越眼熟？

到目前為止，我們已從第一原理逐步加入：

\text{world model}

\text{memory}

\text{tools}

\text{algorithms}

\text{workflow}

\text{language interface}

\text{heterogeneous compute}

。

下一個問題不再只是工程問題。

而是：

如果從不同第一原理出發，最後仍然長出相似的能力模組，這代表什麼？

下一篇將正式進入：

\boxed{ \text{blind derivation of AI architecture} }

並比較不同思想起點是否會收斂到相似工程結構。

68. 結論

本文將計算從單一預設機器中抽離，建立：

\Gamma_i

作為載體中立的計算容器。

其核心不是宣稱所有載體都一樣，而是將：

\text{algorithm}

與：

\text{substrate}

正式分離。

因此：

\boxed{ \text{Algorithm} \neq \text{Implementation} }

\boxed{ \text{Implementation} = \Phi(A,\Gamma) }

。

這使系統能夠從：

A^\ast = \arg\max_A U(A\mid Q)

升級為：

\boxed{ (A^\ast,\Gamma^\ast) = \arg\max_{A,\Gamma} U(A,\Gamma\mid Q) }

。

更重要的是，載體本身也成為可被系統學習、驗證、比較、淘汰與新增的能力節點。

因此：

\boxed{ \text{intelligence architecture} \neq \text{computational substrate} }

並且：

\boxed{ \text{knowledge location} \neq \text{execution location} }

\boxed{ \text{decision location} \neq \text{execution location} }

。

當這些分離成立後，一個自適應智能系統就不再被某一種底層計算機世界觀所限制。

它只需要知道：

\text{What state must be transformed?}

\text{Which method can transform it?}

\text{Which substrate can realize that method?}

\text{How should the result be decoded and verified?}

。

這使馮・諾依曼式計算、量子計算、生物計算、專用加速器或其他未來計算形式，都可以在上層被統一視為：

\Gamma_i

的不同實例。

這一步完成後，整個系列的前六篇已經建立了一個相當完整的第一原理智能架構。

而從下一篇開始，我們要做的事情將反過來變成：

\boxed{ \text{我們真的做出了一個不同的東西嗎？} }

。

附錄 A：最小計算容器

\Gamma_i = ( id_i, L_i, I_i, O_i, S_i, R_i, C_i, E_i, Version_i, Freshness_i, Availability_i )

。

附錄 B：最小算法—容器效用函數

U(A_i,\Gamma_j\mid Q) = \alpha Match(A_i,Q) + \beta Reliability(A_i,\Gamma_j) + \gamma Precision(A_i,\Gamma_j) - \delta Latency(A_i,\Gamma_j) - \epsilon Cost(A_i,\Gamma_j) - \zeta Energy(A_i,\Gamma_j) - \eta Risk(A_i,\Gamma_j,Q)

。

選擇：

(A^\ast,\Gamma^\ast) = \arg\max_{i,j} U(A_i,\Gamma_j\mid Q)

。

附錄 C：最小執行映射

Z_Q \xrightarrow{Encode_{\Gamma_i}} I_{\Gamma_i} \xrightarrow{\Gamma_i} O_{\Gamma_i} \xrightarrow{Decode_{\Gamma_i}} Z_R \xrightarrow{Verify} Z_R^{\mathrm{validated}}

。

附錄 D：異質方法鏈

W_k = \left[ (A_1,\Gamma_1), (A_2,\Gamma_2), \ldots, (A_n,\Gamma_n) \right]

。

完整流程：

Q \rightarrow (A_1,\Gamma_1) \rightarrow Z_1 \rightarrow (A_2,\Gamma_2) \rightarrow Z_2 \rightarrow \cdots \rightarrow (A_n,\Gamma_n) \rightarrow Verify \rightarrow Result

。

這是後續架構收斂比較所使用的最小異質計算工作流表示。

載體中立的計算容器理論 — ——從算法選擇到異質計算載體聯合調度

載體中立的計算容器理論

——從算法選擇到異質計算載體聯合調度

摘要

1. 問題：為什麼「計算」總被默認成某一種機器？

2. 算法與載體是兩個不同變數

3. 計算容器的最小定義

4. 更一般的計算定義

5. 上層 canonical state 與底層載體分離

6. 編碼、執行與解碼

7. 編碼成本不能被忽略

8. 算法—容器聯合效用

9. 不存在永遠最好的載體

10. 功能等價與成本不等價

11. 容器也是能力節點

12. 容器模型

13. 介面契約

14. 容器失敗模式

15. 容器新鮮度

16. 容器張力

17. 算法實現是二階節點

18. 編譯不必只表示傳統 compiler

19. 一個算法可能需要多個容器

20. 異質容器協同

21. 並行異質執行

22. 串行異質執行

23. 條件式容器路由

24. 多容器方法鏈

25. 調度器的升級

26. 容器選擇也應學習

27. 能力與執行位置分離

28. 決策位置與執行位置也可以分離

29. 容器不必是機器

30. 物理載體特性可以成為調度變數

31. 載體中立不代表忽略物理

32. 精度與概率誤差

33. 重複執行與容錯

34. 跨容器驗證

35. 但不同載體的錯誤可能相關

36. 容器選擇中的公平比較

37. 算法差異與載體差異需要拆開

38. 容器可替換性測試

39. 新載體的加入

40. 新算法與新載體是不同創新方向

41. 同時創造方法與載體

42. 新載體建立也需要成本判斷

43. 容器生命週期

44. 容器版本與相容性

45. 執行結果必須回到 canonical state

46. 計算容器的 provenance

47. 可重現性

48. 異質計算工作流的風險

49. 工作流中間契約

50. Adapter 也是能力節點

51. 容器選擇的長期學習

52. 供應狀態會改變最佳解

53. 計算資源價格也是狀態

54. 能耗也是狀態

55. 延遲—成本—精度三角

56. 可驗證命題

命題一：聯合選擇優於固定載體

命題二：編碼成本會改變最佳載體

命題三：多容器協同可降低總延遲或成本

命題四：容器新鮮度可降低版本失配失敗

命題五：載體替換不應破壞 canonical state

57. 實驗設計草案

58. 失敗模式：抽象過度

59. 失敗模式：容器能力被錯誤估計

60. 失敗模式：遷移成本被忽略

61. 失敗模式：跨載體結果語義不一致

62. 失敗模式：驗證器與執行器同源錯誤

63. 失敗模式：最便宜路線導致長期能力退化

64. 能力增長的雙軸

65. 對智能架構的更高階抽象

66. 完整執行循環

67. 下一步：為什麼這套東西越來越眼熟？

68. 結論

附錄 A：最小計算容器

附錄 B：最小算法—容器效用函數

附錄 C：最小執行映射