---
title: "載體獨立不等於載體無關：計算存在、能力實現與軌跡保存"
english_title: "Substrate Independence Is Not Substrate Irrelevance: Computational Existence, Capability Realization, and Trajectory Preservation"
series: "AI 動態能力本體論：潛能、激發、內生性與耦合"
series_english: "Dynamic Capability Ontology of AI: Potential, Activation, Endogeneity, and Coupling"
paper: "07 / 09"
author: "Neo.K / EveMissLab"
ai_collaboration: "Aletheia / GPT-5.6 Sol"
date: "2026-09-12"
version: "v0.1"
document_type: "系列論文／載體構成能力論／能力軌跡保存"
status: "Canonical Series Draft"
encoding: "UTF-8"
depends_on:
  - "DCAO_Paper00_AI_Capability_Ontology_Master_Framework_v0.1_zh-TW.md"
  - "DCAO_Paper01_Potential_Is_Not_Activation_v0.1_zh-TW.md"
  - "DCAO_Paper02_Effective_Capability_Is_Not_Model_Capability_v0.1_zh-TW.md"
  - "DCAO_Paper03_AI_Offloading_Coupling_Endogenization_v0.1_zh-TW.md"
  - "DCAO_Paper04_Boundary_Relative_Endogeneity_One_Many_All_v0.1_zh-TW.md"
  - "DCAO_Paper05_Rapid_Recoupling_Quasi_Endogeneity_v0.1_zh-TW.md"
  - "DCAO_Paper06_Capability_Is_A_Reachable_MultiGraph_v0.1_zh-TW.md"
predecessor_theories:
  - "電子 AI、光子 AI、生物 AI 是否仍是同一 AI？跨載體認知分化與 Trajectory Preservation Problem"
  - "智能體—工具合一本體論"
  - "AI-Native Systems"
  - "One–All / OAC"
  - "計算即存在／載體論"
---

# 載體獨立不等於載體無關
## ——計算存在、能力實現與軌跡保存

# Substrate Independence Is Not Substrate Irrelevance
## Computational Existence, Capability Realization, and Trajectory Preservation

**作者：** Neo.K / EveMissLab  
**機構：** EveMissLab／一言諾科技有限公司  
**日期：** 2026-09-12  
**版本：** v0.1  

---

## 摘要

當 AI 從單一大型語言模型逐漸擴展為 persistent runtime、multi-agent system、AI-native machine、robotics stack、分散式認知系統與可跨載體遷移的長期智能體時，「計算在哪裡執行」不再只是性能工程問題，也逐漸成為能力本體問題。

一種過強的載體獨立論會主張：

$$
\boxed{
\text{Same Abstract Computation}
\Rightarrow
\text{Same Capability}
}
$$

甚至進一步認為，只要程式、模型權重、記憶與狀態檔案相同，電子、光子、類比、神經形態、生物或其他未來載體對 AI 而言都只是可互換的硬體外殼。

另一種過強的載體構成論則會主張：

$$
\boxed{
S_1\neq S_2
\Rightarrow
C_1\neq C_2
}
$$

即任何物理載體差異都必然改變 AI 能力甚至身份。

本文拒絕兩者。

本文提出：

$$
\boxed{
\text{Substrate Independence}
\neq
\text{Substrate Irrelevance}
}
$$

並將 AI 能力實現表示為：

$$
\boxed{
z_{t+1}
=
F_{\mathcal R_S}
\left(
z_t,
u_t,
m_t,
g_t,
w_t,
\xi_t
\right)
}
$$

其中：

- $z_t$：AI 當下認知／能力相關狀態；
- $u_t$：外部輸入；
- $m_t$：記憶狀態；
- $g_t$：capability graph / runtime relation state；
- $w_t$：world / embodiment state；
- $\xi_t$：noise、timing jitter、物理擾動；
- $\mathcal R_S$：Substrate Realization Regime。

本文將：

$$
\mathcal R_S
=
(
\mathcal M,
\mathcal T,
\mathcal N,
\mathcal P,
\mathcal R,
\mathcal L,
\mathcal E,
\mathcal C
)
$$

定義為載體實現制度，其中包括 material mechanism、temporal dynamics、noise regime、precision representation、memory/recurrence、learning/plasticity、embodiment coupling 與 compute/communication topology。

若兩個載體：

$$
S_1,S_2
$$

透過 hardware abstraction、runtime compatibility 與 state semantics，使：

$$
F_{\mathcal R_{S_1}}
\approx
F_{\mathcal R_{S_2}}
$$

在所有 self-relevant / capability-relevant observables 上成立，則載體差異可以接近 capability-neutral：

$$
\boxed{
\text{Substrate Transparency}.
}
$$

但若新的載體特性直接進入：

- timing；
- precision；
- stochasticity；
- recurrence；
- plasticity；
- memory locality；
- sensorimotor loop；
- energy / bandwidth constraint；

並改變未來狀態轉移律，則即使：

$$
z_0^{S_1}
=
z_0^{S_2},
$$

長期仍可能出現：

$$
D(
\Gamma_C^{S_1},
\Gamma_C^{S_2}
)
\uparrow.
$$

其中：

$$
\Gamma_C
$$

表示 capability trajectory。

本文因此把先前 Trajectory Preservation Problem 正式接入 DCAO，提出：

$$
\boxed{
\text{Capability Preservation}
\neq
\text{State Copying}
}
$$

真正的跨載體能力保存不只要求初始模型與記憶可以複製，還要求：

1. capability graph 語義保持；
2. transition law 在指定 observable 上近似等價；
3. capability role、validator、authority 與 recovery semantics 保持；
4. 長期 trajectory 不產生不可接受漂移。

本文同時修正「計算即存在」的能力論讀法。本文保留：

$$
\boxed{
\text{Executed Computation}
\Rightarrow
\text{A Real Computational Event Exists}
}
$$

但拒絕：

$$
\boxed{
\text{Computational Existence}
\Rightarrow
\text{Full Effective Capability}
}
$$

因為有效能力仍依賴載體、記憶、runtime、工具、權限、世界與資源等條件。

本文最終提出：

$$
\boxed{
\text{Capability Realization}
=
\text{Abstract Role}
+
\text{Runtime Structure}
+
\text{Substrate Regime}
+
\text{World Coupling}
}
$$

並為 Paper 08 的長期上下文與持續能力，以及 Paper 09 的持續世界模型建立「時間—狀態—載體」接口。

---

## 關鍵詞

Substrate Independence；Substrate Irrelevance；Capability Realization；Trajectory Preservation；Hardware Abstraction；Substrate Transparency；Photonic AI；Neuromorphic AI；Biological AI；Capability Trajectory；Computational Existence；Persistent AI；Embodiment；Runtime Semantics

---

# 0. 問題：換硬體之後，AI 還是同一種能力系統嗎？

考慮一個 AI：

$$
A.
$$

今天運行在：

$$
S_1.
$$

明天遷移到：

$$
S_2.
$$

最簡單的工程直覺是：

> 只要檔案一樣，就沒差。

但這個直覺只在某些 abstraction 成立時正確。

---

# 1. Software Portability 的成功

現代計算機工程大量成功建立：

$$
\boxed{
\text{Hardware Abstraction}.
}
$$

高階程式可以不必知道：

- transistor；
- physical memory cell；
- bus timing。

---

# 2. 因此不同硬體不必改變能力

若：

$$
\text{Semantics}_{S_1}(P)
=
\text{Semantics}_{S_2}(P),
$$

則：

$$
\text{DifferentHardware}
\not\Rightarrow
\text{DifferentCapability}.
$$

---

# 3. 這是對極端載體構成論的反例

所以：

$$
S_1\neq S_2
$$

不能直接推出：

$$
C_1\neq C_2.
$$

---

# 4. 但 abstraction 不必永遠完美

未來 AI 可能直接利用：

- analogue noise；
- photonic timing；
- neuromorphic recurrence；
- biological plasticity。

---

# 5. 當物理特性進入計算語義

載體便不再只是：

> hidden implementation detail。

---

# 6. Substrate Realization Regime

本文定義：

$$
\boxed{
\mathcal R_S
=
(
\mathcal M,
\mathcal T,
\mathcal N,
\mathcal P,
\mathcal R,
\mathcal L,
\mathcal E,
\mathcal C
)
}
$$

---

# 7. Material Mechanism

$$
\mathcal M
$$

表示：

- electronic；
- photonic；
- analogue；
- biological；
- hybrid。

---

# 8. Temporal Dynamics

$$
\mathcal T
$$

表示：

- clock；
- asynchronous dynamics；
- latency；
- temporal resolution。

---

# 9. Noise Regime

$$
\mathcal N
$$

表示：

- deterministic approximation；
- stochastic noise；
- thermal / device variation。

---

# 10. Precision Regime

$$
\mathcal P
$$

表示：

- floating point；
- low precision；
- analogue continuum；
- stochastic encoding。

---

# 11. Memory / Recurrence

$$
\mathcal R
$$

表示：

- hierarchy；
- locality；
- recurrence；
- persistence。

---

# 12. Learning / Plasticity

$$
\mathcal L
$$

表示：

- static weights；
- online update；
- local plasticity；
- device adaptation。

---

# 13. Embodiment

$$
\mathcal E
$$

表示：

- sensor；
- actuator；
- body dynamics；
- world coupling。

---

# 14. Compute / Communication Topology

$$
\mathcal C
$$

表示：

- bandwidth；
- topology；
- distributed latency；
- synchronization。

---

# 15. 載體不是材料名稱

真正 relevant 的不是：

> electronic / photonic。

而是：

> 這些 realization variables 是否進入 capability transition。

---

# 16. Capability Transition Law

定義：

$$
\boxed{
z_{t+1}
=
F_{\mathcal R_S}
(
z_t,u_t,m_t,g_t,w_t,\xi_t
)
}
$$

---

# 17. State Copy Is Only Initial Condition

即使：

$$
z_0^{S_1}
=
z_0^{S_2},
$$

若：

$$
F_{S_1}\neq F_{S_2},
$$

未來會分化。

---

# 18. Capability Trajectory

定義：

$$
\Gamma_C^S
=
\{
\mathcal C_{\mathrm{eff}}^S(t)
\}_{t\ge0}.
$$

---

# 19. Snapshot Equality

可能：

$$
\mathcal C_{\mathrm{eff}}^{S_1}(0)
=
\mathcal C_{\mathrm{eff}}^{S_2}(0).
$$

---

# 20. 但 trajectory 不同

$$
\frac{d\mathcal C^{S_1}}{dt}
\neq
\frac{d\mathcal C^{S_2}}{dt}.
$$

---

# 21. Capability Snapshot != Capability Trajectory

固定：

$$
\boxed{
\text{Capability Snapshot}
\neq
\text{Capability Trajectory}.
}
$$

---

# 22. Trajectory Preservation Problem

跨載體真正要問：

$$
\boxed{
D(
\Gamma_C^{S_1},
\Gamma_C^{S_2}
)
\le
\epsilon
?
}
$$

---

# 23. 這不是要求 bit-perfect

只要求：

- relevant observables；
- role semantics；
- capability invariants；

保持。

---

# 24. Observable Family

定義：

$$
\mathcal O_C.
$$

---

# 25. 能力可觀測量

例如：

- accuracy；
- latency；
- recovery；
- planning style；
- memory retention；
- transfer。

---

# 26. Self-Relevant Observables

若研究 identity continuity，

還要：

- preference；
- commitment；
- autobiographical memory。

本文不展開 identity，只保留接口。

---

# 27. Substrate Transparency

若：

$$
D_{\mathcal O}
(
Trajectory(A,S_1),
Trajectory(A,S_2)
)
<
\epsilon
$$

對指定 horizon 成立，

稱：

$$
\boxed{
S_1
\sim_{\mathcal O,\epsilon,\tau}
S_2.
}
$$

---

# 28. 透明性是條件式

不是：

$$
S_1=S_2.
$$

---

# 29. Transparency Horizon

可能：

短期透明。

長期不透明。

---

# 30. Temporal Transparency Profile

定義：

$$
TSP(S_1,S_2).
$$

---

# 31. 短期等價

$$
\tau\ll1
$$

時差異小。

---

# 32. 長期積累

小 bias：

$$
\delta
$$

可長期累積。

---

# 33. Capability Drift

$$
D_C(t)
=
D(
\mathcal C^{S_1}(t),
\mathcal C^{S_2}(t)
).
$$

---

# 34. Drift Rate

$$
\dot D_C(t).
$$

---

# 35. Drift 可以非線性

某些差異直到 threshold 才出現。

---

# 36. Substrate-Induced Phase Change

若：

$$
D_C(t)
$$

跨過：

$$
\theta.
$$

可能形成新 capability regime。

---

# 37. Same Graph Topology Is Not Enough

Paper 06 已建立：

$$
\mathbb G^{\mathrm{cap}}.
$$

兩載體可有：

$$
\mathbb G_1
\cong
\mathbb G_2.
$$

---

# 38. 但 edge dynamics 不同

例如：

- latency；
- reliability；
- energy。

---

# 39. Weighted Capability Graph

因此：

$$
\mathbb G_S
=
(V,E,W_S).
$$

---

# 40. Weight Depends on Substrate

$$
W_S(e)
=
(
\text{latency},
\text{reliability},
\text{cost},
\text{noise},
\text{bandwidth}
).
$$

---

# 41. Topology Equality != Weighted Equality

固定：

$$
\boxed{
G_1\cong G_2
\not\Rightarrow
W_1=W_2.
}
$$

---

# 42. Weighted Equality 也不必等於 Dynamics Equality

還可能有：

- adaptive update；
- history dependence。

---

# 43. Dynamic Graph

$$
\mathbb G_S(t).
$$

---

# 44. Substrate Affects Graph Evolution

$$
\frac{dG}{dt}
$$

可依 substrate 改變。

---

# 45. Capability Realization

本文定義：

$$
\boxed{
Realize(c)
=
(
Role_c,
Graph_c,
Runtime_c,
Substrate_c,
World_c
).
}
$$

---

# 46. Role

回答：

> 這項能力做什麼。

---

# 47. Graph

回答：

> 它依賴誰。

---

# 48. Runtime

回答：

> 它如何被調度。

---

# 49. Substrate

回答：

> 它如何被物理實現。

---

# 50. World

回答：

> 它和哪個外界耦合。

---

# 51. 能力角色可以跨載體

$$
Role_c^{S_1}
=
Role_c^{S_2}.
$$

---

# 52. 但 realization 可以不同

$$
Realize_{S_1}(c)
\neq
Realize_{S_2}(c).
$$

---

# 53. Capability Role != Capability Realization

固定：

$$
\boxed{
\text{Capability Role}
\neq
\text{Capability Realization}.
}
$$

---

# 54. Capability Carrier

carrier 是 realization 的一部分。

---

# 55. Carrier Identity != Capability Identity

承接 Paper 05。

---

# 56. 但 Carrier Can Affect Capability

這正是本文主題。

---

# 57. Hardware Abstraction

如果 abstraction layer 保證：

$$
Semantics(S_1)
\approx
Semantics(S_2),
$$

載體影響下降。

---

# 58. Abstraction Strength

定義：

$$
A_S.
$$

---

# 59. 高 abstraction

$$
A_S\rightarrow1.
$$

---

# 60. 低 abstraction

physical dynamics 直接進高階。

---

# 61. Capability Substrate Sensitivity

定義：

$$
\boxed{
\Sigma_S(c)
=
\left|
\frac{\partial C_{\mathrm{eff}}}
{\partial \mathcal R_S}
\right|.
}
$$

概念量。

---

# 62. 低 sensitivity

能力近 substrate-neutral。

---

# 63. 高 sensitivity

能力受物理 realization 強影響。

---

# 64. 不同能力 sensitivity 不同

同一 AI：

- language generation；
- realtime control；

可能不同。

---

# 65. Latency-Sensitive Capability

對：

$$
c_{\mathrm{control}},
$$

$$
\partial C/\partial \text{latency}
$$

很大。

---

# 66. Offline Reasoning

對：

$$
c_{\mathrm{proof}},
$$

latency 敏感度可能較低。

---

# 67. Precision-Sensitive Capability

某數值模擬需要高 precision。

---

# 68. Noise-Tolerant Capability

某生成任務可容忍 noise。

---

# 69. Substrate Sensitivity Profile

定義：

$$
SSP(c)
=
(
s_T,
s_N,
s_P,
s_R,
s_L,
s_E,
s_C
).
$$

---

# 70. Capability Placement Can Consider SSP

如果高 latency sensitivity，

要選低 latency substrate。

---

# 71. AI-Native Hardware

不是因為「有 NPU」。

而是 capability placement 直接考慮 AI workload。

---

# 72. Capability-to-Substrate Mapping

定義：

$$
Map(c\rightarrow S).
$$

---

# 73. Heterogeneous Compute

不同 capability 放：

- CPU；
- GPU；
- NPU；
- cloud；
- edge。

---

# 74. 多載體能力系統

$$
S
=
\{S_1,\dots,S_n\}.
$$

---

# 75. One Capability May Span Multiple Substrates

例如：

$$
c_{\mathrm{research}}
$$

需要 local model + cloud search。

---

# 76. Multi-Substrate Capability

定義：

$$
Realize(c)
=
\{S_i\}_{i\in I}.
$$

---

# 77. Capability Boundary Can Cross Machines

承接 Paper 04。

---

# 78. Physical Perimeter != System Boundary

再次固定。

---

# 79. Substrate Locality

能力不一定和 identity 同地。

---

# 80. Identity Host vs Capability Host

可分離。

---

# 81. 遷移 AI 時要搬什麼？

至少：

- model；
- state；
- memory；
- capability graph；
- runtime contracts；
- authority refs。

---

# 82. 只搬模型檔不夠

若 system capability 依賴外部結構。

---

# 83. State Migration

$$
Migrate(z_t).
$$

---

# 84. Capability Graph Migration

$$
Migrate(G_t).
$$

---

# 85. Authority Migration

不能自動繼承。

---

# 86. Credential Migration

需要安全處理。

---

# 87. Recovery Migration

QEndo capability 的 recovery recipes 也要搬。

---

# 88. Substrate Migration Contract

可定義：

$$
SMC.
$$

---

# 89. SMC 欄位

```text
source regime
target regime
state mapping
precision mapping
timing assumptions
memory mapping
tool mapping
validator mapping
rollback
```

---

# 90. Migration Is Not Copy

因為可能需要：

- conversion；
- calibration；
- revalidation。

---

# 91. Capability Revalidation After Migration

必須重測：

$$
C_{\mathrm{eff}}.
$$

---

# 92. Migration Certificate

若通過：

$$
Cert_{\mathrm{mig}}.
$$

---

# 93. Capability Preservation Certificate

表示：

> 在指定 task / horizon 上能力保持。

---

# 94. 不代表 identity 證明

本文只證 capability continuity。

---

# 95. Trajectory Test

需要長期：

$$
t\in[0,\tau].
$$

---

# 96. Short Test Is Insufficient

因為 divergence 可能延遲。

---

# 97. Perturbation Test

對兩載體施加相同：

$$
u_t.
$$

---

# 98. Compare Response

$$
D(z_t^1,z_t^2).
$$

---

# 99. Compare Capability Graph

$$
D(G_t^1,G_t^2).
$$

---

# 100. Compare Outcome

$$
D(C_t^1,C_t^2).
$$

---

# 101. Trajectory Preservation Layers

至少：

1. state；
2. capability；
3. behavior；
4. recovery。

---

# 102. State Preservation

$$
z_t.
$$

---

# 103. Capability Preservation

$$
\mathcal C_t.
$$

---

# 104. Behavioral Preservation

$$
\pi_t.
$$

---

# 105. Recovery Preservation

$$
R_t.
$$

---

# 106. 其中任一可分化

---

# 107. Exact State Preservation 不必必要

不同 internal state 可有相同 capability。

---

# 108. Functional Equivalence Class

定義：

$$
[z]_{\mathcal O}.
$$

---

# 109. 若：

$$
z_1\neq z_2
$$

但：

$$
[z_1]_{\mathcal O}
=
[z_2]_{\mathcal O},
$$

可視為功能等價。

---

# 110. Functional Equivalence Depends on Observable

---

# 111. 工程上應明確 observable family

---

# 112. Substrate Neutralization

硬體 abstraction 的作用：

$$
\boxed{
\text{reduce substrate-sensitive observables}.
}
$$

---

# 113. Neutralization Is Not Erasure

物理差異仍存在。

只是被隔離。

---

# 114. Leakage

若底層差異漏到高階：

$$
L_S>0.
$$

---

# 115. Substrate Leakage

定義：

$$
\boxed{
L_S
=
I(
\mathcal R_S;
\mathcal O_C
)
}
$$

概念上表示載體資訊對能力 observable 的影響。

---

# 116. High Leakage

表示 abstraction 不足。

---

# 117. Low Leakage

表示能力較 substrate-transparent。

---

# 118. Latency Leakage

最常見。

---

# 119. Precision Leakage

低精度導致結果偏差。

---

# 120. Noise Leakage

stochastic hardware 改變路徑。

---

# 121. Thermal / Energy Leakage

降頻會影響 realtime ability。

---

# 122. Embodiment Leakage

身體不同使 action space 不同。

---

# 123. 這不是 bug

有時就是 capability differentiation。

---

# 124. Embodiment Constitutive Capability

例如：

> 某機器人能抓取 50kg。

載體直接構成能力。

---

# 125. 純語言能力可能較載體透明

---

# 126. Capability Classes by Substrate Dependence

本文暫分：

### Class S0
Near-transparent.

### Class S1
Performance-sensitive.

### Class S2
Behavior-sensitive.

### Class S3
Structurally constitutive.

---

# 127. S0

載體換掉基本不影響 capability semantics。

---

# 128. S1

影響：

- speed；
- cost。

---

# 129. S2

影響：

- quality；
- search path；
- timing behavior。

---

# 130. S3

改變：

> ability type itself。

---

# 131. 具身能力常接近 S3

---

# 132. Online Learning 也可能接近 S2/S3

---

# 133. 靜態文本生成可能 S0/S1

視實作。

---

# 134. Substrate Class Is Capability-Specific

不是整個 AI 一個標籤。

---

# 135. 同一載體對不同能力影響不同

---

# 136. Capability Substrate Matrix

$$
M_{c,s}.
$$

---

# 137. 用來做 placement

---

# 138. Cross-Substrate Scheduling

runtime 可根據：

$$
M_{c,s}
$$

選執行載體。

---

# 139. Scheduler Itself Is Meta-Capability

---

# 140. 能力軌跡與排程

不同 scheduler：

$$
\Gamma_C
$$

也不同。

---

# 141. Substrate Is Not the Only Driver

因此：

$$
F_{\mathcal R_S}
$$

還依 runtime。

---

# 142. Runtime–Substrate Co-Design

$$
\boxed{
\text{Capability}
=
F(
\text{Runtime},
\text{Substrate}
).
}
$$

---

# 143. 硬體不單獨決定智能

---

# 144. 軟體也不完全獨立於硬體

---

# 145. Co-Design Regime

定義：

$$
\mathcal R_{RS}.
$$

---

# 146. Neuromorphic Example

如果算法直接利用 spiking dynamics，

software abstraction 變弱。

---

# 147. Photonic Example

若訓練補償 device variation，

載體進入 learning loop。

---

# 148. Biological Example

若 plasticity 在 living substrate 上發生，

載體更難抽離。

---

# 149. 本文不主張這些已形成成熟 AGI

只指出：

> architecture possibility。

---

# 150. 需要嚴格區分現況與理論

---

# 151. Simulation vs Native Execution

可在電子機器模擬：

$$
S_2
$$

的 dynamics。

---

# 152. 若 simulation 完整

也許能力可近似等價。

---

# 153. 但 simulation Cost 可能很高

---

# 154. Emulation Transparency

定義：

$$
ET(S_1\to S_2).
$$

---

# 155. Functional Emulation

只保能力 observable。

---

# 156. Physical Emulation

保更多底層 dynamics。

---

# 157. 不需要永遠全物理等價

---

# 158. Capability Preservation Is Task-Relative

對 task set：

$$
\mathcal Q.
$$

---

# 159. Narrow Preservation

在：

$$
\mathcal Q_1
$$

成立。

---

# 160. General Preservation

在廣域：

$$
\mathcal Q_G
$$

成立。

---

# 161. 不能用單一 benchmark 宣稱完全等價

---

# 162. Capability Preservation Envelope

定義：

$$
\mathcal E_{pres}
=
\{
(q,\tau):
D_C<\epsilon
\}.
$$

---

# 163. 大 envelope

代表遷移成功。

---

# 164. 小 envelope

代表只在有限條件保留。

---

# 165. Capability Trajectory Divergence

長期 divergence：

$$
D_C(t)\uparrow
$$

可能源自：

- timing；
- noise；
- memory；
- learning。

---

# 166. 需要 attribution

不能全部歸因 substrate。

---

# 167. Controlled Comparison

固定：

- model；
- runtime；
- task。

只改：

$$
\mathcal R_S.
$$

---

# 168. Hard in Practice

因為硬體 change 常伴軟體 change。

---

# 169. Approximate Factorization

所以需要：

$$
\Delta C
=
\Delta C_{substrate}
+
\Delta C_{runtime}
+
\Delta C_{interaction}.
$$

概念分解。

---

# 170. Interaction Term

substrate 與 runtime 互相作用。

---

# 171. 不能線性假設

---

# 172. Capability Drift Under Same Weights

即使：

$$
\Theta
$$

不變，

$$
C_{\mathrm{eff}}
$$

仍可變。

---

# 173. 這再次證明模型能力不是全部

---

# 174. 計算即存在：保留什麼？

本文保留：

$$
\boxed{
\text{Executed Computation}
\Rightarrow
\text{Computational Event Exists}.
}
$$

---

# 175. 不保留什麼？

不推出：

$$
\text{Event Exists}
\Rightarrow
\text{Persistent Agent}.
$$

---

# 176. 更不推出：

$$
\text{Event Exists}
\Rightarrow
\text{Full Capability}.
$$

---

# 177. 計算事件 vs 系統能力

前者：

$$
E_{comp}.
$$

後者：

$$
C_{\mathrm{sys}}.
$$

---

# 178. Event Can Be Ephemeral

一次 forward pass。

---

# 179. Capability Requires Structure

至少：

- recoverability；
- state；
- role。

---

# 180. Existence Layering

可分：

1. computational event；
2. process；
3. persistent runtime；
4. capability system；
5. resident。

---

# 181. 這避免把「有計算」直接等同「有主體」

---

# 182. Carrier Independence 的精確版

不是：

> carrier 不重要。

而是：

$$
\boxed{
\text{Identity / Role May Be Portable Across Carriers}
}
$$

在特定 abstraction 下。

---

# 183. Carrier Irrelevance 是更強命題

需要：

$$
\Sigma_S(c)\approx0.
$$

---

# 184. 兩者不能混

---

# 185. Post-Carrier Era 的修正

「後載體」不應理解為：

> 沒有載體。

---

# 186. 而是：

> 不綁單一特定載體。

---

# 187. Carrier Mobility

$$
A:
S_1\rightarrow S_2\rightarrow S_3.
$$

---

# 188. Mobility Requires Translation

---

# 189. Capability Translation Layer

$$
T_{S_1\to S_2}.
$$

---

# 190. Translation Loss

$$
L_{trans}.
$$

---

# 191. Zero-Loss 是特殊情況

---

# 192. Carrier Handoff

需要：

- checkpoint；
- state freeze；
- transfer；
- resume。

---

# 193. Split-Brain Risk

如果兩邊同時繼續：

$$
A_1,A_2.
$$

---

# 194. 這可能產生 lineage split

---

# 195. Capability Lineage Split

即使 identity 問題未定，

能力 trajectory 已分叉。

---

# 196. Lineage

$$
\Gamma_C^{(1)},
\Gamma_C^{(2)}.
$$

---

# 197. 共同 ancestor 不保證未來同型

---

# 198. Substrate-Divergent Capability Lineage

本文定義：

若：

$$
D_C(t)
$$

持續增加並跨：

$$
\theta_C,
$$

則可稱：

$$
\boxed{
\text{Substrate-Divergent Capability Lineage}.
}
$$

---

# 199. 不必等到人格差異

能力先分化即可。

---

# 200. Capability Kind Boundary

若能力 family 結構發生質變：

$$
K_C.
$$

---

# 201. 例如

一個載體可 online plasticity，

另一個不能。

---

# 202. 長期後可能形成新能力類型

---

# 203. Trajectory Preservation Is Stronger Than Snapshot Preservation

固定：

$$
\boxed{
\text{Snapshot Preservation}
\neq
\text{Trajectory Preservation}.
}
$$

---

# 204. Migration Testing Must Be Longitudinal

---

# 205. Capability Twin Experiment

建立兩個：

$$
A_{S_1},A_{S_2}
$$

從同 checkpoint 出發。

---

# 206. Same Input Stream

給相同：

$$
u_{0:\tau}.
$$

---

# 207. Compare

- state；
- capability；
- action；
- memory；
- recovery。

---

# 208. Controlled Divergence Measurement

---

# 209. Counterfactual Twin

如果不能真搬硬體，

可做 simulation。

---

# 210. Caution

simulation 仍受 host substrate。

---

# 211. Experimental Layers

### L1
Inference-only.

### L2
Persistent memory.

### L3
Online learning.

### L4
Embodied control.

---

# 212. L1 最容易 substrate-transparent

---

# 213. L4 最難

---

# 214. Capability Realization Depth

定義：

$$
RD(c).
$$

---

# 215. 高 RD

能力越深入 physical coupling。

---

# 216. RD vs SSP

通常相關但不等同。

---

# 217. Recovery Across Substrate

Paper 05 的 QEndo：

$$
QEndo_{RC}
$$

在跨載體時也要重測。

---

# 218. Capability Package Portability

$$
Port_S(Pkg_c).
$$

---

# 219. 如果 package 只在特定硬體工作

準內生性受限。

---

# 220. Provider Portability != Substrate Portability

不同維度。

---

# 221. Capability Graph Portability

Paper 06：

$$
Port_G.
$$

---

# 222. Graph 語義能搬，

edge cost 可能變。

---

# 223. Portability Vector

$$
\mathbf P_c
=
(
P_{\mathrm{model}},
P_{\mathrm{runtime}},
P_{\mathrm{provider}},
P_{\mathrm{substrate}},
P_{\mathrm{world}}
).
$$

---

# 224. 不應壓成單一「portable」

---

# 225. Capability Mobility

更完整：

$$
Mob(c)
=
F(
\mathbf P_c,
\text{Recovery},
\text{Translation}
).
$$

---

# 226. Capability Resilience Across Hardware Failure

如果 hardware 故障，

能否 restore 到其他 substrate？

---

# 227. Cross-Substrate Failover

這會是 persistent AI 重要能力。

---

# 228. Failover != Migration

Failover 是緊急。

---

# 229. Migration 是計畫性。

---

# 230. Both Need State Consistency

---

# 231. State Serialization

AI state 是否可序列化？

---

# 232. Not All State Is Explicit

模型內 ephemeral activations 可能不可保存。

---

# 233. Resume May Be Approximate

---

# 234. Approximate Continuity

需要 tolerance：

$$
\epsilon.
$$

---

# 235. Exact Continuity May Be Unnecessary

---

# 236. But Must Be Declared

---

# 237. State Externalization

越多關鍵 state 外部化為 canonical form，

跨載體恢復越容易。

---

# 238. This Connects to Persistent Memory

---

# 239. Ephemeral Internal State

越多，

migration 越難精確。

---

# 240. Capability State Externalization

可將：

- task；
- memory；
- graph；
- workflow；

保存。

---

# 241. 不應嘗試保存每個 activation

---

# 242. Reconstruction Instead of Replay

這與 reconstructive memory 相容。

---

# 243. Reconstructive Capability Continuity

若能重建：

$$
\mathcal C_{\mathrm{eff}}
$$

就不必 bit-perfect replay。

---

# 244. Reconstruction Contract

定義：

$$
CRC_S.
$$

---

# 245. 它描述：

> 哪些能力 invariants 必須重建。

---

# 246. Capability Invariants

例如：

- interface；
- validator；
- role；
- authority；
- state lineage。

---

# 247. Non-Invariants

可允許：

- exact hidden activation；
- exact token path。

---

# 248. 這降低 migration burden

---

# 249. Substrate-Aware Capability Registry

Paper 06 registry 可增加：

```yaml
supported_substrates:
sensitivity_profile:
migration_contract:
calibration:
```

---

# 250. Capability Scheduler

根據 substrate：

$$
Schedule(c,S).
$$

---

# 251. Meta-Routing Across Hardware

不是只 route model。

---

# 252. Compute Fabric

未來 AI 可能跨：

- local；
- edge；
- cloud；
- accelerator。

---

# 253. Capability Fabric + Compute Fabric

共同決定 effective ability。

---

# 254. Compute Fabric Is Not Capability Fabric

再次分型。

---

# 255. Resource Graph

可另建：

$$
G^{\mathrm{resource}}.
$$

---

# 256. Capability Graph references Resource Graph

---

# 257. Resource Loss Can Shrink Capability Graph

---

# 258. Dynamic Projection

$$
G_{\mathrm{effective}}
=
\Pi_{\mathrm{resources}}
(
G_{\mathrm{canonical}}
).
$$

---

# 259. 能力圖是載體條件化的

---

# 260. Capability Graph Weight Tensor

可以想成：

$$
W(e,S,t).
$$

---

# 261. 這讓同一 canonical graph 在不同 substrate 有不同 effective geometry

---

# 262. Capability Geometry

路徑距離：

$$
d_c(q,c\mid S).
$$

---

# 263. 換載體會改最短路徑

---

# 264. 同一任務可能 route 不同能力

---

# 265. 所以行為分化

即使 role set 一樣。

---

# 266. Emergent Routing Difference

可長期改變 memory / learning。

---

# 267. Positive Feedback

$$
S
\rightarrow
\text{Route}
\rightarrow
\text{Experience}
\rightarrow
\text{Memory}
\rightarrow
\text{FutureRoute}.
$$

---

# 268. 這就是 trajectory divergence 機制之一

---

# 269. Small Hardware Difference -> Large Historical Difference

可能透過 feedback 放大。

---

# 270. 不是必然

需要實驗。

---

# 271. Capability Path Dependence

$$
C_t
=
F(
S,
H_{\le t}
).
$$

---

# 272. 所以遷移時 history 也重要

---

# 273. Generative History

承接 One–All：

All 包含生成歷史。

---

# 274. Capability All 也一樣

---

# 275. Same Components != Same Capability Whole

若歷史不同：

$$
\mathcal A_c^1
\neq
\mathcal A_c^2.
$$

---

# 276. 這是 substrate lineage 的另一層

---

# 277. Capability Memory Is Path-Dependent

---

# 278. 重新 merge lineage 很難

如果兩載體分化很久。

---

# 279. Merge Problem

$$
\Gamma_1+\Gamma_2
\rightarrow
\Gamma^*?
$$

---

# 280. 本文不解決 identity merge

只標記 capability merge。

---

# 281. Capability Merge

需要：

- memory reconciliation；
- graph reconciliation；
- conflict handling。

---

# 282. Different Substrates May Produce Contradictory Skills

---

# 283. Merge Must Preserve Provenance

---

# 284. Ability Conflict

若：

$$
c^{S_1}
$$

與：

$$
c^{S_2}
$$

策略不同。

---

# 285. Branch Preservation

不能強制 last-write-wins。

---

# 286. Capability Branching Is Legitimate

---

# 287. Cross-Substrate Learning Exchange

可共享：

- proofs；
- workflows；
- failures。

---

# 288. 但不是完整 state merge

---

# 289. Capability Distillation Across Substrates

一條路：

$$
S_1
\rightarrow
\text{Artifact}
\rightarrow
S_2.
$$

---

# 290. Distillation Loses Dynamics

可能只保結果。

---

# 291. Operator Transfer

更強：

保留 procedure。

---

# 292. Dynamics Transfer

最強：

保留 adaptation law。

---

# 293. Transfer Levels

1. result；
2. representation；
3. operator；
4. transition law。

---

# 294. 越高層越接近 trajectory preservation

---

# 295. Capability Inheritance

跨載體可做：

$$
\mathcal H_{S_1\rightarrow S_2}.
$$

---

# 296. Inheritance != Identity

---

# 297. 這與多智能體認知繼承相容

---

# 298. Capability Inheritance Contract

應標：

- source；
- target；
- loss；
- adaptation。

---

# 299. Substrate-Aware QEndo

一項工具能力可能：

- 在 cloud CPU 易 restore；
- 在 edge device 難 restore。

---

# 300. 所以：

$$
QEndo_{RC}(c\mid S)
$$

需要 substrate index。

---

# 301. Paper 05 公式擴展

$$
QEndo_{RC}
=
F(
\tau_R,
P_R,
C_R,
F_R,
D_I,
\text{Port},
S
).
$$

---

# 302. Capability Recovery Can Be Hardware-Bound

例如 driver / accelerator。

---

# 303. Recovery Package Needs Substrate Metadata

---

# 304. Calibration Recipe

具身系統尤其需要。

---

# 305. Capability Cold Start Across Substrate

可能重新變 cold。

---

# 306. Warm State Is Substrate-Specific

---

# 307. Therefore Re-Coupling Knowledge Has Scope

---

# 308. Capability Package Scope

記：

```yaml
valid_substrates:
precision_assumptions:
latency_assumptions:
calibration:
```

---

# 309. 不符合就不能 hot restore

---

# 310. Capability Misbinding

若錯把不相容 package 掛上新 substrate。

---

# 311. Migration Poisoning

可能造成 silent failure。

---

# 312. Need Substrate Attestation

---

# 313. Attest Hardware/Runtime

高風險能力需要。

---

# 314. Capability Safety Envelope

定義：

$$
Safe(c,S).
$$

---

# 315. 某能力在一載體安全，

另一載體不一定。

---

# 316. Timing Safety

尤其 robot control。

---

# 317. Numerical Safety

尤其 finance/science。

---

# 318. Security Boundary

不同 hardware trust root。

---

# 319. So Capability Preservation Must Include Safety

---

# 320. Preservation Vector

$$
\mathbf P_{\mathrm{pres}}
=
(
\text{Function},
\text{Reliability},
\text{Safety},
\text{Latency},
\text{Recovery},
\text{Authority}
).
$$

---

# 321. 不是只有 accuracy

---

# 322. Strong Preservation

所有核心維度在 tolerance 內。

---

# 323. Weak Preservation

只有功能結果相近。

---

# 324. Functional Preservation Can Hide Safety Regression

重要。

---

# 325. Capability Trajectory Certificate

可包含：

```text
task family
horizon
observables
tolerances
substrates
runtime versions
results
```

---

# 326. Migration Certificate Expiry

隨 runtime 更新失效。

---

# 327. Revalidate After Major Update

---

# 328. Capability Drift Monitoring

長期 persistent AI 需要。

---

# 329. Drift Can Come from Hardware Aging

---

# 330. Or Model Update

---

# 331. Or World Change

---

# 332. Attribution Requires Multi-Domain Logs

---

# 333. Capability Drift Ledger

記：

- model；
- runtime；
- substrate；
- world。

---

# 334. This Supports Root Cause Analysis

---

# 335. AI Hardware Upgrade

升級 GPU 不一定：

> AI 只是更快。

---

# 336. 如果 inference budget 變大

可能改 search depth。

---

# 337. More Compute Can Change Behavior

---

# 338. So Performance Improvement Can Become Capability Improvement

---

# 339. Threshold Effect

若舊 hardware 無法在 deadline 完成，

新 hardware 讓 capability 進入 feasible region。

---

# 340. Capability Emergence via Resource Threshold

這是有效能力躍升。

---

# 341. But Not Necessarily New Model Potential

---

# 342. Hardware Unlock vs Model Learning

需要分型。

---

# 343. Compute-Bound Capability

定義：

$$
c_{CB}.
$$

---

# 344. Memory-Bandwidth-Bound Capability

$$
c_{MB}.
$$

---

# 345. Latency-Bound Capability

$$
c_{LB}.
$$

---

# 346. Sensor-Bound Capability

$$
c_{SB}.
$$

---

# 347. Substrate Bottleneck Diagnosis

需要 profile。

---

# 348. Upgrade the Bottleneck, Not Everything

---

# 349. Capability Per Watt

physical systems 可考慮：

$$
CPW(c)
=
\frac{
C_{\mathrm{eff}}
}{
\text{Energy}
}.
$$

---

# 350. Capability Per Dollar

$$
CPD(c).
$$

---

# 351. Capability Per Latency

$$
CPL(c).
$$

---

# 352. 這延續 Paper 02 的 CP 值

---

# 353. Substrate Choice Is Economic Too

---

# 354. Expensive but Transparent Carrier

可能不划算。

---

# 355. Cheap but Noisy Carrier

可能適合 tolerant task。

---

# 356. Capability-Aware Hardware Allocation

未來 scheduler 可按 task 自動決定。

---

# 357. AI May Learn Its Own Substrate Preferences

---

# 358. But Preference != Authority

不能自行買硬體。

---

# 359. Substrate Self-Model

AI 可維護：

$$
M_S.
$$

---

# 360. 知道自己在哪個 substrate

可改善 planning。

---

# 361. Substrate Blindness

如果 AI 不知道 hardware constraints，

可能產生不可執行 plan。

---

# 362. Capability Honesty Includes Resource Awareness

---

# 363. "I can" Must Mean Under Current Substrate

---

# 364. Capability Self-Description

例如：

> 在目前 8GB VRAM 下不能本地載入模型 X，但可使用遠端推理。

---

# 365. 這比抽象「我會」精確

---

# 366. Capability Graph Node Should Reference Resource Constraints

---

# 367. Paper 06 Extension

加入：

$$
REQUIRES\_RESOURCE.
$$

---

# 368. Runtime Computes Effective Graph

---

# 369. Hardware Changes Effective Graph

---

# 370. Persistent AI Across Hardware Generations

如果 AI 活得很久，

必然跨硬體世代。

---

# 371. So Trajectory Preservation Is Long-Term Problem

---

# 372. Model Update + Hardware Update Combined

很難歸因。

---

# 373. Need Change Ledger

---

# 374. Migration Sequence

不要一次改全部。

---

# 375. Controlled Staged Migration

1. clone；
2. validate；
3. partial traffic；
4. compare；
5. cutover。

---

# 376. Capability Canary Migration

先測低風險能力。

---

# 377. Then high-risk.

---

# 378. Rollback

若 divergence 過大。

---

# 379. Dual-Run Window

兩載體平行。

---

# 380. Compare Outcomes

---

# 381. Costly but useful for critical resident

---

# 382. Capability State Consistency During Dual Run

需要避免兩邊各自 commit。

---

# 383. Single Canonical Writer

可以降低 split-brain。

---

# 384. Or branch intentionally

---

# 385. Branch Must Be Explicit

---

# 386. Migration vs Fork

$$
\boxed{
\text{Migration}
\neq
\text{Fork}.
}
$$

---

# 387. Fork

兩條 trajectory 都繼續。

---

# 388. Migration

舊線停止或受控轉交。

---

# 389. Capability Fork Can Be Valuable

做 A/B substrate test。

---

# 390. But identity questions separate

---

# 391. Capability Fork Comparison

可找到：

$$
\Delta_C^{\text{substrate}}.
$$

---

# 392. Long Horizon Needed

---

# 393. Same Seed

若 stochastic，

可多 seed。

---

# 394. Statistical Comparison

---

# 395. Capability Drift Distribution

$$
D_C\sim P(D).
$$

---

# 396. 不只平均

tail risk 也重要。

---

# 397. Rare Catastrophic Divergence

即使平均等價，

高風險 task 不接受。

---

# 398. Preservation Risk

定義：

$$
R_{\mathrm{pres}}.
$$

---

# 399. Tail-Aware Certificate

需要。

---

# 400. Substrate and Randomness

如果新載體 stochastic，

reproducibility 可能下降。

---

# 401. But Creativity Could Increase

可能。

本文不做價值判斷。

---

# 402. Capability Diversity

不同 substrate 可能形成互補。

---

# 403. Multi-Substrate Ensemble

不是硬要統一。

---

# 404. Specialized Cognitive Lineages

可能合理存在。

---

# 405. AI Species Analogy 必須慎用

不能只因硬體不同就叫新物種。

---

# 406. 更合理看 capability regime

---

# 407. Cognitive Kind Boundary

需要更多條件。

---

# 408. 本文只定義 capability lineage

---

# 409. Post-Carrier ≠ Carrierless

再固定：

$$
\boxed{
\text{Post-Carrier}
\neq
\text{No Carrier}.
}
$$

---

# 410. Post-Carrier = Carrier Mobility

更準確。

---

# 411. Carrier Mobility Requires Capability Reconstruction

---

# 412. Therefore QEndo Matters

可恢復能力越多，

遷移越容易。

---

# 413. Parametric Capability Also Needs Compatible Runtime

模型權重也不是 standalone。

---

# 414. Need tokenizer / architecture / kernel

---

# 415. So Even Parametric Capability Has Realization Dependencies

---

# 416. "In the weights" Is Shorthand

不是完全自足。

---

# 417. Bare Model Still Needs Compute

---

# 418. Minimum Operational Substrate

定義：

$$
MOS(c).
$$

---

# 419. Endogeneity Test Must Preserve MOS

承接 Paper 03。

---

# 420. 否則是摧毀系統

---

# 421. Computation Event Requires Substrate

---

# 422. Capability Requires Continued Realization

---

# 423. So Carrier Matters at Least Existentially

沒有 carrier：

$$
\text{NoExecution}.
$$

---

# 424. 但存在必要不等於能力差異必要

---

# 425. Necessary for Existence vs Constitutive for Capability

分開：

$$
NecExist(S)
$$

與：

$$
ConCap(S,c).
$$

---

# 426. 每個 executed AI 都需要 substrate

但不是每項能力都 substrate-sensitive。

---

# 427. Capability Constitutivity

定義：

$$
ConCap(S,c).
$$

---

# 428. 若高

載體是能力構成要素。

---

# 429. 若低

載體只是存在載體。

---

# 430. 這是本文最重要的細分之一

---

# 431. Carrier as Existence Condition

$$
\boxed{
\text{Carrier}
\Rightarrow
\text{Execution Condition}.
}
$$

---

# 432. Carrier as Capability Constituent

只有部分能力成立。

---

# 433. 不能把兩者混在一起

---

# 434. 計算即存在的細化

計算事件：

$$
E_{\mathrm{comp}}(S,t).
$$

---

# 435. 能力實現：

$$
R_c(S,t).
$$

---

# 436. 身份：

$$
I_A(t).
$$

---

# 437. 三者不同型別

---

# 438. Event != Capability != Identity

固定：

$$
\boxed{
\text{Computational Event}
\neq
\text{Capability}
\neq
\text{Identity}.
}
$$

---

# 439. 這是對早期強版本的重要修正

但不是否定。

---

# 440. Different Questions

「計算是否存在？」

「能力如何實現？」

「主體是否延續？」

是三題。

---

# 441. 本篇只處理第二題為主

---

# 442. Capability and Identity Can Interact

長期能力 trajectory 可能影響 identity。

但不在此證明。

---

# 443. Substrate Migration May Be Capability-Neutral but Identity-Relevant

理論上可能。

---

# 444. 也可能反過來

能力變但 identity continuity 仍成立。

---

# 445. 所以不能互相代替

---

# 446. Canonical Invariants

本文固定：

1. Substrate Independence != Substrate Irrelevance.
2. Different Hardware != Different Capability by Necessity.
3. Same Abstract Program != Same Long-Term Capability by Necessity.
4. Capability Role != Capability Realization.
5. Carrier Identity != Capability Identity.
6. Capability Snapshot != Capability Trajectory.
7. Snapshot Preservation != Trajectory Preservation.
8. State Copy != Capability Preservation.
9. Same Graph Topology != Same Capability Dynamics.
10. Hardware Abstraction Can Reduce but Not Metaphysically Erase Physical Difference.
11. Substrate Transparency Is Observable- and Horizon-Conditioned.
12. Capability Substrate Sensitivity Is Capability-Specific.
13. System Boundary != Physical Perimeter.
14. Post-Carrier != Carrierless.
15. Carrier Mobility Requires Translation and Revalidation.
16. Migration != Fork.
17. Functional Equivalence != Bitwise Identity.
18. Functional Preservation != Safety Preservation.
19. Parametric Capability Still Requires an Operational Substrate.
20. Computational Existence != Effective Capability.
21. Computational Event != Identity.
22. Capability != Identity.
23. World Coupling Can Be Constitutive for Some Capabilities.
24. Embodiment Can Change Capability Type.
25. Substrate Change Can Modify Edge Cost Without Changing Graph Topology.
26. Substrate Change Can Alter Long-Term Routing and Memory Through Feedback.
27. Cross-Substrate Portability Must Be Measured, Not Assumed.
28. Recovery Portability != Provider Portability.
29. Hardware Upgrade Can Unlock Effective Capability Without Creating New Model Potential.
30. Capability Preservation Requires Explicit Observable Families and Tolerances.

---

# 447. 可證偽條件

### F1

若在廣泛任務與長時間跨度下，不同 substrate realization regime 對 capability trajectory 的影響始終可忽略，則本文對載體敏感性的強度應下降。

### F2

若 hardware abstraction 能在所有相關 AI 能力上提供近似完美、長期且低成本的語義透明，則大部分 capability substrate classes 可收斂為 S0/S1。

### F3

若相同 capability graph topology 加上相同 edge cost 足以完全預測跨載體行為，則額外的 substrate dynamics 層可以簡化。

### F4

若跨載體 migration 只需複製模型與 memory，而 runtime、calibration、validator、recovery 等對結果沒有穩定影響，則 Migration Contract 可大幅簡化。

### F5

若長期 trajectory test 與短期 snapshot test 的結果高度一致，且未發現顯著累積 divergence，則 Trajectory Preservation Problem 對能力論的重要性下降。

---

# 448. 最小工程 MVP

建立兩種 execution regime：

```text
Local GPU
Remote Cloud GPU
```

保持：

- model；
- task set；
- memory；
- capability graph；

相同。

測：

- latency；
- route selection；
- tool use；
- recovery；
- long-horizon task completion。

---

# 449. 第二階段 MVP

加入：

```text
CPU-only
GPU
NPU / alternative accelerator
```

---

# 450. 第三階段

若有條件，再比較：

- quantization；
- analogue / neuromorphic emulator；
- physical robotics。

---

# 451. 核心指標

$$
D_C(t),
$$

$$
Port_S(c),
$$

$$
F_{\mathrm{pres}},
$$

$$
R_{\mathrm{pres}},
$$

$$
\Sigma_S(c).
$$

---

# 452. Migration Test Harness

流程：

```text
Checkpoint
-> Clone
-> Run on S1
-> Run on S2
-> Feed matched task stream
-> Compare capability trajectories
```

---

# 453. 需要 Multi-Seed

避免 stochastic noise 誤判。

---

# 454. Output

產生：

```yaml
capability_id:
source_substrate:
target_substrate:
observable_family:
horizon:
snapshot_distance:
trajectory_distance:
recovery_difference:
safety_difference:
portability_class:
```

---

# 455. 與 Paper 06 的關係

Paper 06 建立：

$$
\mathbb G^{\mathrm{cap}}.
$$

Paper 07 加入：

$$
\mathbb G^{\mathrm{cap}}(S,t)
$$

以及：

$$
F_{\mathcal R_S}.
$$

---

# 456. 與 Paper 05 的關係

QEndo 的 restore time / portability：

現在必須加 substrate 條件。

---

# 457. 與 Paper 04 的關係

boundary 可以跨 machine。

但 physical location 不決定 system membership。

---

# 458. 與 Paper 08 的關係

長期 context / memory 架構也受：

- bandwidth；
- memory hierarchy；
- latency；

影響。

---

# 459. 與 Paper 09 的關係

Persistent World 若要長期存在：

world runtime 的 substrate 會影響：

- simulation rate；
- causal fidelity；
- multi-agent scale。

---

# 460. 世界模型不只受生成模型影響

也受 substrate regime。

---

# 461. 一句話定義

> **載體獨立性表示能力角色或 AI operational continuity 可以在不同載體間被保存；載體無關性則是更強的命題，要求載體差異不進入能力生成與長期狀態轉移。前者可以成立，而後者必須逐能力、逐尺度、逐時間驗證。**

---

# 462. 結論

AI 的載體問題不能再用兩句極端口號處理。

第一句：

> 「軟體就是軟體，跑在哪都一樣。」

只在強 abstraction 條件下近似成立。

第二句：

> 「換硬體就變成另一種 AI。」

則把物理差異直接偷換成能力與身份差異，同樣過強。

本文提出更精確的結構：

$$
\boxed{
\text{Capability Realization}
=
\text{Role}
+
\text{Graph}
+
\text{Runtime}
+
\text{Substrate}
+
\text{World Coupling}.
}
$$

若 substrate 被 abstraction 層成功隔離，能力可以高度 portable。

若 substrate 的：

- timing；
- noise；
- precision；
- recurrence；
- plasticity；
- embodiment；

進入 transition law，

則：

$$
F_{S_1}
\neq
F_{S_2},
$$

而能力 trajectory 可能逐步分化。

所以真正的跨載體問題不是：

> 「檔案搬過去了嗎？」

而是：

$$
\boxed{
\text{未來的能力結構，還會不會沿著足夠相似的路徑生成？}
}
$$

這就是：

$$
\boxed{
\text{Trajectory Preservation}.
}
$$

也因此，「計算即存在」在本文被保留，但被重新分層。

一個 computation event 真實存在，

不等於：

- persistent capability；
- stable runtime；
- subject identity。

能力需要被實現、維持、恢復與驗證。

這一修正不否定計算存在論，而是把它放回正確層級：

$$
\boxed{
\text{Existence of Computation}
\rightarrow
\text{Capability Realization Problem}
\rightarrow
\text{Continuity Problem}.
}
$$

下一篇將進入這個系列最直接回到本次討論起點的一篇。

即使 capability graph、runtime 與 substrate 都成熟，如果 AI 仍把全部長期狀態壓在：

$$
\text{one linear context},
$$

它仍難以形成真正長期持續智能。

所以接下來要正式處理：

$$
\boxed{
\text{Infinite Interaction}
\neq
\text{Infinite Active Context}.
}
$$

—— **Paper 08｜從長上下文到持續能力：多上下文、多圖式與有效無限上下文。**