雙生 Agent 組織運行架構：通用 Runtime 與 Native Runtime 的分化

Twin Agentic Organizational Runtime Architecture: The Divergence of General-OS Runtime and Native Runtime

系列： ANDO Twin Runtime Series
篇次： 01 / 05
作者： Neo.K
機構： EveMissLab／一言諾科技有限公司
版本： v0.1
日期： 2026-08-23
文件類型： 理論論文 / 架構定位論文
狀態： 公開初稿

摘要

當 Agentic AI 從單一工具逐步轉向持續運作的多智能體組織時，傳統問題不再只是「模型能力是否足夠」，而開始轉變為：組織狀態應存在於何處、權限如何授予與撤銷、任務如何跨 Agent 延續、驗證如何脫離單一模型自述，以及人類是否仍必須充當所有工作轉移的低階觸發器。

既有 ANDO（AI-Native Distributed Organization）方向已提出一套以 canonical state、task graph、delegation envelope、checkpoint、ledger、verification 與 commit gate 為核心的 Agent 組織運行語義。然而，若將這套架構只理解為某一個特定 Web Dashboard、SQLite 應用或某一種作業系統上的程式，便會把「組織語義」與「運行載體」混為一談。

本文提出「雙生 Agent 組織運行架構」（Twin Agentic Organizational Runtime Architecture）。其核心主張是：同一套 Agent 組織語義，應允許在兩種不同運行基底上形成平行實作。一條是面向 Windows、Linux、macOS 與既有企業軟體生態的 General-OS Runtime；另一條則是面向 world-native / state-native 作業環境的 Native Runtime。兩者不是 Lite 與 Pro 的線性產品分級，也不是舊系統與新系統的簡單替代，而是相同 semantic kernel 在不同 substrate 上的兩種 realization。

本文進一步提出 semantic kernel、substrate projection、semantic equivalence、impedance cost、bridge density、native collapse 與 migration continuity 等概念，用以描述何種能力應由兩條產品線共享，何種結構則應由底層運行環境決定。本文亦指出：通用 Runtime 並非等待 Native Runtime 成熟前的臨時過渡品。只要既有作業系統、企業資料庫、瀏覽器、API、檔案系統與生產流程仍具有大規模現實基礎，General-OS Runtime 就具有長期獨立的商業與工程價值。

關鍵詞

Agentic AI、AI-Native Distributed Organization、Agent Runtime、Native Runtime、General-OS Runtime、Semantic Kernel、Delegation、Verification、HDUS、World-Native Computing、Human-on-the-Bridge

1. 問題提出

目前多數 AI 應用仍以「模型或 Agent 是主要中心」為預設。典型架構可寫成：

Human \rightarrow Agent \rightarrow Tool \rightarrow Result.

即使進一步加入多 Agent，常見形式仍只是：

Human \rightarrow ManagerAgent \rightarrow WorkerAgents.

這類架構改善了單一模型的工作分解能力，卻沒有根本回答一個更重要的問題：

若 Agent 可以被替換、重啟、升級、分工甚至死亡，組織本身究竟存在於哪裡？

若 canonical state 仍存在某個模型上下文，則：

AgentFailure \Rightarrow OrganizationMemoryFailure.

若每個任務轉移仍必須由人類輸入「繼續」、「交給下一個」、「再試一次」，則：

Human = Scheduler + Router + RetryTrigger + ContextBridge.

這形成 Human-Kernel Anti-Pattern。

ANDO 的基本回答是：

\boxed{ State \neq Agent \neq Authority \neq Commit }

並將人類的角色由 operational kernel 轉為 governance bridge：

\boxed{ HumanOutOfOperationalLoop + HumanOnTheBridge. }

然而，進一步的問題隨即出現：這套架構應該綁定在什麼作業系統與運行環境？

若答案只有「一個 Python + SQLite + Web Dashboard 應用」，那麼 ANDO 就被誤縮成某個特定產品實作。

若答案只有「未來全部改成 Native OS / World OS」，則又忽略了現有 Windows、Linux、macOS、瀏覽器、企業資料庫與 SaaS 生態的巨大安裝基礎。

本文因此提出第三種答案：

\boxed{ OneSemanticCore \rightarrow TwinRuntimeRealizations }

2. 雙生架構的核心定義

2.1 Semantic Kernel

定義 ANDO 的語義核心：

\mathcal S_{ANDO} = ( State, Task, Agent, Delegation, Authority, Budget, Checkpoint, Artifact, Verification, Receipt, Commit, Event, HumanBridge ).

此處的 $\mathcal S_{ANDO}$ 不指定：

資料庫一定是 SQLite；
UI 一定是 Web；
runtime 一定是 Python；
作業系統一定是 Windows；
state 一定以檔案形式存在；
Agent 一定經由 HTTP API 呼叫。

因此：

\boxed{ SemanticKernel \neq ImplementationStack. }

2.2 General-OS Runtime

定義 General-OS Runtime：

R_G = \pi_G(\mathcal S_{ANDO},\Sigma_G),

其中 $\Sigma_G$ 表示 conventional operating-system substrate，例如 Windows、Linux、macOS、filesystem、browser、local database、REST / IPC、enterprise SaaS、local model server 與 cloud API。

$\pi_G$ 是將 ANDO 語義投影到既有計算環境的 realization map。

2.3 Native Runtime

定義 Native Runtime：

R_N = \pi_N(\mathcal S_{ANDO},\Sigma_N),

其中 $\Sigma_N$ 是 world-native / state-native substrate。

在這種環境中，原本必須透過外部橋接實現的概念，可能直接成為底層原生物件，例如：

WorldState, Artifact, AgentPresence, AuthorityEdge, CommitEvent, Session, Observer, History.

因此 Native Runtime 不必複製 General-OS Runtime 的 UI 或資料結構。

3. 「雙生」不等於「兩套互不相關的產品」

若兩條產品線只共享品牌，卻不共享語義，則它們只是兩套不同程式。

本文要求更強條件：

\boxed{ R_G \sim_{\mathcal S} R_N }

其中 $\sim_{\mathcal S}$ 表示 semantic equivalence。

直觀而言，若同一個 canonical organizational state $X$ 同時被投影到兩種 runtime：

X_G=\pi_G(X),

X_N=\pi_N(X),

則在忽略 substrate-specific metadata 後，兩者對核心組織問題應給出相容答案，例如某 task 是否 Completed、某 delegation 是否 Revoked、child authority 是否超越 parent、某 artifact 是否有適用 verification、某 commit 是否有合法 receipt。

因此需要 abstraction operators：

\alpha_G:R_G\rightarrow\mathcal S_{ANDO},

\alpha_N:R_N\rightarrow\mathcal S_{ANDO}.

若：

\alpha_G(X_G) = \alpha_N(X_N),

則稱兩者在 ANDO semantic domain 上等價。

4. 第一原則：共享語義，不共享外觀

錯誤設計方式是要求 Native Runtime 也必須長得像 Web Dashboard，或要求 General-OS Runtime 模擬 Native World 的全部結構。

本文主張：

\boxed{ SharedSemantics + DivergentEmbodiment. }

例如 General-OS Runtime 中：

Artifact
=
database row
+
filesystem path
+
sha256

但 Native Runtime 中可能是：

Artifact
=
world-native persistent object
+
history lineage
+
authority binding

只要兩者能投影回相同 semantic contract，就不要求內部結構一致。

5. General-OS Runtime 為何不是過渡產品

設 conventional ecosystem 的現實安裝基礎為：

B_G(t),

Native ecosystem 的安裝基礎為：

B_N(t).

只要在相當長時間內：

B_G(t)\gg B_N(t),

General-OS Runtime 就仍具有獨立 deployment value。

其現實理由包括企業既有 Windows 工作站、歷史資料庫、ERP / CRM / office suite、瀏覽器平台、官方 API、雲端 SaaS、既有檔案格式、使用者學習成本、IT 管理制度與 hardware driver。

因此：

\boxed{ LegacyInstalledBase \neq TemporaryNoise. }

它是市場結構的一部分。

6. Compatibility Surface

定義 General-OS Runtime 的 Compatibility Surface：

\mathcal C_G = \{ Filesystem, Browser, API, Database, DesktopApp, EnterpriseService, LocalModel, CloudModel \}.

通用 Runtime 的任務不是把這些系統全部重寫，而是建立：

AgenticOrganization \leftrightarrow ExistingSoftwareWorld.

例如：

ANDO \rightarrow BrowserAdapter \rightarrow ExistingWebService.

或：

ANDO \rightarrow FileAdapter \rightarrow LegacyProjectDirectory.

因此通用版的橋接層較多，不代表它是錯誤架構。

7. Native Runtime 的核心價值：Bridge Elimination

General-OS Runtime 中，典型工作可能經過：

Agent \rightarrow RuntimeAPI \rightarrow Database \rightarrow Filesystem \rightarrow UI.

定義 bridge set：

\mathcal B(R) = \{b_1,b_2,\ldots,b_n\}.

定義 Bridge Density：

D_B(R) = \frac{|\mathcal B(R)|}{N_{semantic\ transitions}+\epsilon}.

再定義 Impedance Cost：

C_I(R) = \sum_{b\in\mathcal B(R)} ( C_{serialization} + C_{synchronization} + C_{translation} + C_{failure} + C_{governance} ).

Native Runtime 的主要工程優勢之一，是可以令部分橋接：

b_i \rightarrow \varnothing.

本文稱之為：

\boxed{ NativeCollapse. }

8. Native Collapse 不等於 Semantic Collapse

Native integration 不代表可以取消 ANDO 的概念邊界。

以下仍必須成立：

State \neq Agent \neq Authority \neq Commit.

以及：

ExecutionState \neq VerificationState \neq CommitState.

因此：

\boxed{ BridgeElimination \neq SemanticCollapse. }

9. Portable Semantic Kernel

定義 Portable Semantic Kernel：

\mathcal K_P \subseteq \mathcal S_{ANDO}.

最低內容至少包括：

Canonical Entity Identity；
State Revision；
Task DAG semantics；
Delegation lineage；
Authority monotonicity；
Budget monotonicity；
Checkpoint semantics；
Artifact identity / digest / lineage；
Receipt semantics；
Verification requirement / result semantics；
Commit classes；
Event history；
Revocation；
Human escalation。

這些語義應在兩種 runtime 間保持穩定。

相對地，SQL table layout、HTML template、CSS、filesystem path、Windows Registry、browser DOM、HDUS renderer、native spatial layout、IPC transport 與 provider SDK 都不應被視為 portable kernel 的一部分。

10. Twin Evolution 與 Semantic Drift

設：

R_G(t)

與：

R_N(t)

分別表示兩條 runtime 隨時間演化。

若完全獨立演化，可能出現：

SemanticDrift = d( \alpha_G(R_G), \alpha_N(R_N) ).

當：

SemanticDrift \rightarrow Large,

雙生架構便退化為兩套不相容產品。

因此需要：

\boxed{ CoEvolutionProtocol. }

其核心不是要求 feature parity，而是要求 semantic compatibility。

11. Feature Parity 與 Semantic Parity

General-OS Runtime 可能有 browser automation、Windows integration、Office adapter；Native Runtime 可能有 world-native object transition、spatial session state 與 native observer semantics。

因此：

FeatureSet_G \neq FeatureSet_N

完全合理。

真正需要的是：

SemanticParity \approx 1.

例如兩邊都理解 Delegation Revoked，但一邊透過 database event 實現，一邊透過 native authority edge invalidation 實現。

12. Migration Continuity

設 General-OS runtime state：

X_G.

希望存在 migration operator：

M_{G\rightarrow N} : X_G \rightarrow X_N.

要求至少保留：

Identity, Lineage, Authority, History, Artifacts, Verification, Commit.

理想條件：

\alpha_G(X_G) \approx \alpha_N(M_{G\rightarrow N}(X_G)).

反方向也可能存在：

M_{N\rightarrow G},

但 Native Runtime 可能含有 General-OS 無法原生表示的資訊，因此不一定可完全無損。

13. Loss-Annotated Projection

若 Native object 包含 General-OS 無法完整保存的 world-native field，projection 必須產生：

LossManifest.

例如：

preserved:
  task_id
  authority
  artifact
  verification
  commit_history

degraded:
  spatial_native_relation

omitted:
  renderer_private_cache

因此 migration 本身也應是可審計事件。

14. 雙生產品的商業分工

General-OS Runtime 的核心賣點：

不必更換作業系統；
可接既有企業軟體；
可部署於現有 Windows / Linux infrastructure；
可逐步導入；
adoption friction 低；
可作為企業 Agent orchestration layer。

Native Runtime 的核心賣點：

更低 bridge density；
更深 canonical-state integration；
更直接的 Agent-world interaction；
更高 persistent world continuity；
更低 context reconstruction cost；
更少 compatibility impedance。

因此不是：

CheapProduct \rightarrow PremiumProduct.

而是：

\boxed{ CompatibilityOptimized \parallel NativeIntegrationOptimized. }

15. 為何不能要求所有人先遷移 Native Runtime

定義：

AdoptionCost = MigrationCost + LearningCost + SoftwareLoss + ITRisk.

若：

AdoptionCost > ExpectedAgenticBenefit,

Native Runtime 即使技術上更深，也未必有足夠市場滲透。

General-OS Runtime 因此扮演：

\boxed{ LowFrictionEntryPoint. }

16. 為何也不能只保留 General-OS Runtime

若只維護 compatibility runtime，則長期承受：

C_I(R_G)>0.

而某些限制不是增加更多 adapter 就能消失，例如 state 本身不是 OS-native、Agent identity 只是 application metadata、authority 只是 application permission、world continuity 需要額外重建。

Native Runtime 因此提供：

\boxed{ ArchitecturalEscapePath. }

17. 雙生架構與 Human Sovereignty

不論 $R_G$ 或 $R_N$ ：

DelegatedAuthority \neq TransferredSovereignty.

以及：

A_{child} \subseteq A_{parent}.

Native integration 越深，越需要確保 revocation、audit、authority boundary、Human Queue、incident freeze 與 explicit escalation。

18. Twin Invariants

T1 — Semantic Separation

State \neq Agent \neq Authority \neq Commit.

T2 — No Authority Inflation

A_{child} \subseteq A_{parent}.

T3 — History Preservation

Migration \not\Rightarrow HistoryDeletion.

T4 — Verification Preservation

Verification migration 若退化，必須留下 degradation record。

T5 — Explicit Loss

Loss>0 \Rightarrow LossManifest\neq\varnothing.

T6 — Runtime Independence

任一 runtime 故障不應改寫 semantic kernel 的歷史真值。

19. 可觀測雙生等價

定義 organizational probes：

\mathcal P = \{p_1,p_2,\ldots,p_m\}.

例如：

is_task_complete(T)；
authority_of(D)；
latest_applicable_verification(A)；
commit_eligibility(A,W1)；
revocation_descendants(D)。

若：

\forall p\in\mathcal P, \quad p(R_G) = p(R_N),

則兩個 runtime 在此 probe set 上 operationally semantically equivalent。

20. 三層產品架構

ANDO 可以被分為：

\boxed{ ANDOCoreSemantics \rightarrow ANDORuntime \rightarrow ANDONative }

其中：

ANDO Core Semantics

負責規範 state、delegation、authority、verification、ledger、commit 與 migration。

ANDO Runtime

負責 conventional OS 的可部署商業 realization。

ANDO Native

負責 world-native / HDUS-native realization。

21. 開發順序

合理順序：

SemanticDefinition \rightarrow GeneralRuntimeMVP \rightarrow NativeProjection \rightarrow ConformanceLayer.

General Runtime 可以先驗證 delegation / verification / commit semantics 並形成 benchmark；Native Runtime 再吸收已被驗證的 semantic contracts。

22. General Runtime 不應成為 Native Runtime 的設計枷鎖

SQLite 中存在 delegations table，不代表 Native Runtime 也必須有同名 table。

真正不可丟失的是：

DelegationSemantics.

因此 Native design 的正確方法是：

SemanticContract \rightarrow NativeReconstruction,

而不是：

ExistingCode \rightarrow LiteralPort.

23. 從 Porting 到 Re-Embodiment

本文建議未來 Native 版本採：

ReEmbodiment

概念，而不是簡單 port。

因此：

\boxed{ NativeANDO = ReEmbodiment(ANDOSemantics,NativeSubstrate). }

24. 一個重要推論

隨兩條產品線成熟：

FeatureDivergence(t)

可以增加。

但：

SemanticDrift(t)

應被壓低。

理想狀態：

\frac{d}{dt}FeatureDivergence>0,

同時：

SemanticDrift\rightarrow 0.

也就是：

越來越不像同一套 UI，卻越來越確定它們仍是同一個 ANDO。

25. 與 Agent Economy 的關係

General Runtime 可以成為：

ExistingEconomy \leftrightarrow AgentOrganization

的橋梁。

Native Runtime 則可能形成：

AgentOrganization \subseteq NativeComputationalWorld.

兩者共同支持 persistent organizational identity、delegated economic work、verified artifact production、machine-readable authority 與 accountable commit history。

26. 可證偽命題

H1

對大量既有 Windows / enterprise workflow，General-OS Runtime 的導入成本低於要求使用者遷移 Native OS。

H2

當 substrate 可原生承載 state / authority / history 時，Native Runtime 的平均 bridge density 低於 General-OS Runtime。

H3

只要 portable semantic kernel 被明確規範，兩種 runtime 可以在 feature divergence 擴大時仍保持核心 semantic equivalence。

H4

General-OS Runtime 不會因 Native Runtime 出現而立即失去市場價值，因為 installed base、legacy software 與 organization switching cost 具有長期慣性。

H5

若沒有 conformance test 與 migration contract，雙生產品線會逐步發生 semantic fork。

27. 研究與工程議程

後續至少需要：

Portable Semantic Kernel specification；
ANDO conformance test suite；
General-OS Runtime reference implementation；
Native projection mapping；
bidirectional migration schema；
loss manifest format；
semantic-drift detector；
cross-runtime delegation receipt compatibility；
verification portability；
authority lineage portability。

28. 系列中的位置

本篇是五篇系列的總論。

後續四篇：

02. 語義核心與運行載體解耦：Agent 組織系統的 Portable Semantic Kernel

03. 面向既有作業系統的 AI-Native Organization Runtime：Windows-First 相容層與商業部署模型

04. World-Native Agent Organization：HDUS 中的原生 ANDO 與橋接層消解

05. 從通用 Runtime 到 Native World：ANDO 雙生產品線的互操作、遷移與共同演化

另有：

ANDO Twin Product Architecture & Commercial Positioning v0.1

29. 結論

本文提出 ANDO 的雙生運行架構。

其核心不是「未來要不要淘汰 Windows 版」，而是：

同一套 Agent 組織語義，如何在不同計算 substrate 中維持身份，同時允許各自獲得最適合自身環境的實作形式？

因此：

\boxed{ ANDO = SemanticKernel + MultipleValidEmbodiments. }

其中 General-OS Runtime 承擔 compatibility、deployment 與既有市場整合；Native Runtime 承擔 bridge elimination、world-native integration 與新型計算環境的深度能力。

兩者不是互相取代，而是：

\boxed{ CompatibilityOptimizedRuntime \parallel NativeIntegrationOptimizedRuntime. }

最終真正需要長期保持一致的，不是 UI、程式語言或資料庫，而是：

\boxed{ State, Authority, Delegation, Verification, History, Commit, Sovereignty. }

這些才構成 ANDO 作為 Agent 組織系統的身份核心。

文件狀態

系列： ANDO Twin Runtime Series
篇次： 01 / 05
版本： v0.1
狀態： 公開初稿
下一篇： 《語義核心與運行載體解耦：Agent 組織系統的 Portable Semantic Kernel》