AI 原生程式語義媒介運算執行時架構

AI-Native Program Semantic Mediation Runtime Architecture

版本： v0.1
作者： Neo.K
機構： EveMissLab
日期： 2026-09-15
狀態： 核心架構定義稿 / Product Ontology Transition

公司： 一言諾科技有限公司

摘要

既有 AI Coding Agent、IDE、靜態分析器、程式語言工具鏈與 Repository Analyzer，大多仍以「原始碼」作為主要輸入與主要操作對象。即使 AI 已能讀取大型專案、產生程式碼、修改檔案、執行測試與建立 Pull Request，其工作流本質仍常維持：

\text{Source Code} \rightarrow \text{AI Reasoning} \rightarrow \text{Source Code}

此模型對小型程式與局部修改十分有效，但當軟體系統開始包含大型 Repository、Runtime Trace、API Schema、Database Schema、Build Artifact、Binary Artifact、Configuration、Documentation、Policy、Deployment State 與多種 AI Agent 時，單純以原始碼作為唯一媒介會逐漸失去通用性。

本文提出「AI 原生程式語義媒介運算執行時」（AI-Native Program Semantic Mediation Runtime, 以下簡稱 PSMR）架構。其核心主張是：

未來 AI 不應直接把所有軟體工件都當作文字程式碼處理，而應透過一個統一的語義媒介運算層，將不同來源轉換為可追溯、可比較、可運算、可驗證、可重新投影的 Semantic Workspace。

整體架構可表示為：

\boxed{ \text{Input} \rightarrow \text{Semantic Workspace} \rightarrow \text{Operators} \rightarrow \text{Workflow Runtime} \rightarrow \text{Projection} \rightarrow \text{Verification} }

其中輸入不限制於 Source Code；輸出也不限制於 Source Code。程式碼只是眾多輸入／輸出投影之一。

PBSOI CISG v1.0 在此架構中不再等同於整個產品，而被重新定位為第一個成熟的 Program Semantic Operator Stack：負責將 Repository 與 Git/PR 轉換為 evidence-grounded program semantic graph，並提供 Semantic Diff、Impact Analysis、Defect Detection、Motif Analysis 與 Incremental Recompute 等能力。

本文進一步定義六個核心 Contract：Input Adapter Contract、Semantic Object Contract、Operator Contract、Workflow Contract、Projection Contract 與 Evidence & Authority Contract。只要新模組遵守這些 Contract，未來即可接入 Source、Runtime、Artifact、Schema、Documentation、Intent、AI Agent 或其他分析器，而不必持續把所有能力硬塞進單一 analyzer。

一、問題的提出

1.1 現代 AI Coding 仍然過度 Source-Centric

目前多數 AI Coding Workflow 可以概括為：

Repository
→ Search Files
→ Read Source
→ Infer Structure
→ Modify Source
→ Run Tests
→ Return Patch

這種模式的最大限制是：

\boxed{ \text{Program Understanding} \approx \text{Repeated Source Interpretation} }

也就是每一次任務，AI 都必須重新從原始碼中恢復：

module；
dependency；
call；
state；
effect；
contract；
runtime assumption；
architecture intent。

當 Repository 規模變大，這會導致：

\text{Repository Size} \gg \text{Model Context}

以及：

\text{Repeated Interpretation Cost} \gg \text{Semantic Reuse}

因此，真正需要被提升的不是單次模型能力，而是 AI 與軟體世界之間的媒介層。

1.2 軟體不是只有 Source Code

現實軟體系統至少可能包含：

Source Repository；
Git Commit；
Pull Request；
Patch；
Test；
Configuration；
API Schema；
OpenAPI；
Database Schema；
Migration；
Build Artifact；
Runtime Trace；
Log；
Profile；
Package Manifest；
Dependency Lock；
Documentation；
Architecture Spec；
Security Policy；
Deployment State；
Binary / Compiled Artifact；
Existing Semantic Graph；
Human Intent；
AI Generated Change。

因此：

\boxed{ \text{Software} \neq \text{Source Code Only} }

若產品只能處理 Source Repository，它最多是一個強大的 Repository Analyzer，而不是通用的 AI-native software medium。

二、核心重新定位：從 Analyzer 到 Mediation Runtime

2.1 Analyzer 模型

傳統 Analyzer：

A : X \rightarrow Y

例如：

\text{Repository} \rightarrow \text{Report}

它通常具有固定 Input 與固定 Output。

2.2 Mediation Runtime 模型

本文提出：

\mathcal R : (W,O,\Pi) \rightarrow W'

其中：

$W$ ：Semantic Workspace；
$O$ ：Semantic Operators；
$\Pi$ ：Workflow / Projection / Policy；
$W'$ ：更新後的 Semantic Workspace。

也就是系統不只是「分析一次」，而是維持一個可被持續操作的軟體語義世界。

2.3 PSMR 的基本定位

PSMR 不應被理解為：

IDE；
Compiler；
Decompiler；
Static Analyzer；
Reverse Engineering Tool；
LLM Agent；
Repository Viewer。

它更接近：

\boxed{ \text{Software Semantic Bus} }

任何合法來源都可以透過 Adapter 進入；

任何 AI、Human、Tool 都可以透過 Operator 操作；

任何結果都可以透過 Projection 輸出。

三、總體架構

整體架構定義為六層：

\boxed{ I \rightarrow W \rightarrow O \rightarrow R \rightarrow P \rightarrow V }

其中：

$I$ ：Input Layer；
$W$ ：Semantic Workspace；
$O$ ：Semantic Operator Layer；
$R$ ：Workflow Runtime；
$P$ ：Projection Layer；
$V$ ：Verification / Authority Layer。

完整形式：

\boxed{ \text{Input Adapters} \rightarrow \text{Semantic Workspace} \rightarrow \text{Semantic Operators} \rightarrow \text{Workflow Runtime} \rightarrow \text{Output Projections} \rightarrow \text{Verification / Authority} }

四、Input Layer：輸入不再等於 Source Code

4.1 Input Adapter Contract

所有輸入必須先轉換成統一的 Evidence Artifact：

A_k : X_k \rightarrow E_k

其中 $X_k$ 可以是任意合法軟體工件。

$E_k$ 至少包含：

E_k = ( C, I, P, A, Q )

其中：

$C$ ：content / extracted structure；
$I$ ：identity；
$P$ ：provenance；
$A$ ：authority / permission；
$Q$ ：uncertainty / confidence。

4.2 Source Adapter

輸入：

X_{\mathrm{source}} = \text{Repository / File / Git Revision}

輸出：

E_{\mathrm{source}}

可包含：

path；
source hash；
language；
revision；
source span；
parser result。

PBSOI CISG v1.0 即屬於此路徑的成熟實作。

4.3 Runtime Adapter

輸入：

trace；
log；
profiling event；
runtime state；
call trace。

輸出：

E_{\mathrm{runtime}}

可建立：

G_R

並與：

G_C

疊合。

4.4 Schema Adapter

輸入：

OpenAPI；
JSON Schema；
database schema；
protobuf；
GraphQL schema；
package manifest。

輸出：

E_{\mathrm{schema}}

形成：

contract；
type；
boundary；
compatibility relation。

4.5 Documentation / Intent Adapter

輸入：

README；
design document；
issue；
specification；
human natural language intent；
AI plan。

輸出：

E_{\mathrm{intent}}

但必須區分：

\text{Author Claimed} \neq \text{Implementation Observed}

4.6 Artifact Observation Adapter

若沒有 Source Code，但存在合法、授權、可觀測 Artifact，PSMR 應保留統一接口：

A_{\mathrm{artifact}} : X_{\mathrm{artifact}} \rightarrow E_{\mathrm{artifact}}

產品核心本身不必等同於特定逆向工具。

它只要求：

外部工具若能合法產生結構化觀測結果，PSMR 可以接受這些結果。

因此系統保持：

\boxed{ \text{Observation Interface} }

而不是把某種特定分析方式寫死在核心。

五、Semantic Workspace：AI 看到的軟體世界

本文定義：

W = ( A, G, K, H, U, C )

其中：

5.1 Artifacts

A

保存：

source；
schema；
trace；
artifact；
document；
patch；
build output。

5.2 Semantic Graphs

G

可以包含：

CISG；
data-flow graph；
state graph；
effect graph；
motif graph；
runtime graph；
intent graph；
dependency graph。

5.3 Contracts

K

包含：

type contract；
API contract；
state invariant；
policy；
security rule；
test contract；
intent constraint。

5.4 History

H

保存：

Git history；
semantic diff；
runtime evolution；
defect birth / death；
motif evolution；
review fingerprint。

5.5 Unknown

U

是 first-class structure。

包括：

unresolved call；
unknown runtime target；
missing source；
ambiguous mapping；
conflicting evidence。

核心原則：

\boxed{ \text{Unknown} \neq \text{False} }

5.6 Capability / Authority

C

描述：

可以讀什麼；
可以執行什麼；
可以修改什麼；
可以投影什麼；
哪些效果被禁止。

AI 不應因為能理解某個操作，就自動獲得執行該操作的權限。

六、Semantic Operator Layer

傳統模式：

analyze(repository)

未來應改為：

O_i : W \rightarrow (W',\Delta,E)

其中：

$W'$ ：新 workspace；
$\Delta$ ：語義差分；
$E$ ：operator evidence。

6.1 基礎 Operator

第一組 Operator 可包含：

observe
parse
resolve
normalize
bind
slice
compare
diff
impact
detect
classify
match_motif
trace
simulate
execute
generate
project
repair
validate

6.2 Operator Contract

每個 Operator 必須聲明：

O = ( I, O, R, K, C, Q )

其中：

$I$ ：required input types；
$O$ ：output types；
$R$ ：required relations / context；
$K$ ：preserved invariants；
$C$ ：required capabilities；
$Q$ ：uncertainty behavior。

6.3 Operator 不必由 AI 實現

Operator 可以是：

deterministic algorithm；
compiler；
graph algorithm；
symbolic executor；
LLM；
external service；
human approval step。

因此：

\boxed{ \text{AI-Native} \neq \text{Everything Must Be AI} }

AI-native 的真正含義是：

AI 可以把這些 Operator 組合成工作流，而不必重新理解所有底層格式。

七、Workflow Runtime

7.1 Workflow 本身是一級資料

傳統 Agent 過程常只有 log。

PSMR 應把 workflow 表示為：

\Pi_T = ( V_O, E_O )

其中節點是 Operator，邊表示資料依賴與執行順序。

7.2 Task Trace

每個 Operator 執行產生：

T_i = ( O_i, I_i, Y_i, V_i, P_i, Q_i )

其中：

$O_i$ ：operator identity；
$I_i$ ：input artifact IDs；
$Y_i$ ：output artifact IDs；
$V_i$ ：tool / model version；
$P_i$ ：policy / permission；
$Q_i$ ：uncertainty。

7.3 AI-Native Provenance

例如：

Intent
→ Locate Motif
→ Impact Closure
→ Constraint Extraction
→ Generate Semantic Delta
→ Project To Source
→ Run Tests
→ Re-analyze
→ Verify

應保存為 machine-readable workflow graph。

因此未來可以回答：

為什麼改這段程式？

而不是只得到：

AI 決定這樣改。

八、Projection Layer：輸出也不等於 Source Code

8.1 Projection Contract

定義：

P_j : W \rightarrow Y_j

其中 $Y_j$ 可以是：

source；
patch；
PR；
test；
report；
graph；
schema；
documentation；
runtime policy；
executable graph；
machine API。

8.2 Source Code 是 Projection

修改程式時，未來更理想的形式是：

I \rightarrow \Delta W \rightarrow \pi_L(\Delta W) \rightarrow C'

而不是直接：

I \rightarrow C'

8.3 Closed-Loop Reprojection

產生 $C'$ 後：

C' \xrightarrow{\rho_L} W'

再驗證：

\Delta W \stackrel{?}{\approx} W'-W

形成：

\boxed{ \text{Intent} \rightarrow \text{Semantic Delta} \rightarrow \text{Projection} \rightarrow \text{Reconstruction} \rightarrow \text{Verification} }

九、Verification / Authority Layer

9.1 Evidence Classes

至少區分：

Q = \{ \text{Observed}, \text{Inferred}, \text{Claimed}, \text{Unknown}, \text{Conflict} \}

9.2 Authority

來源也必須有 authority：

A_{\mathrm{source}}

A_{\mathrm{intent}}

A_{\mathrm{runtime}}

A_{\mathrm{human}}

A_{\mathrm{AI}}

不同來源不能直接覆寫彼此。

9.3 Capability

執行效果需要 Capability。

例如：

\operatorname{FileDelete}

需要：

\operatorname{Cap}_{\mathrm{filesystem-delete}}

Operator Runtime 應在 capability 不足時停止，而不是讓 AI 自行提升權限。

十、六個核心 Contract

PSMR 的通用性不應來自支援無限多格式，而應來自少數穩定 Contract。

Contract 1：Input Adapter Contract

任意來源如何變成 evidence。

Contract 2：Semantic Object Contract

node、edge、state、effect、contract、unknown 如何表示。

Contract 3：Operator Contract

一個 operator 吃什麼、產生什麼、保持什麼、需要什麼 capability。

Contract 4：Workflow Contract

operator 如何組成 DAG、如何 checkpoint、如何重跑、如何恢復。

Contract 5：Projection Contract

workspace 如何投影成 source、patch、report、API、graph。

Contract 6：Evidence & Authority Contract

哪些是 observed、inferred、claimed、unknown；誰可以修改哪些層。

十一、PBSOI CISG v1.0 的新定位

目前 PBSOI CISG v1.0 已經具備：

Repository analysis；
CISG；
data/state closure；
semantic diff；
impact engine；
defect detection；
motif；
Git/PR review；
persistent cache；
safe partial recompute；
semantic fragment cache；
evidence rebasing。

因此它應被重新定位為：

\boxed{ \text{PBSOI CISG} = \text{Program Semantic Operator Stack} }

而不是整個產品本體。

11.1 PBSOI Operator Stack

可以提供：

observe_source
build_cisg
build_dataflow
build_state_regions
semantic_diff
impact
detect_defects
match_motifs
incremental_recompute
rebase_evidence

11.2 未來其他 Operator Stack

例如：

Runtime Stack

observe_trace
build_runtime_graph
runtime_diff
runtime_drift

Schema Stack

parse_schema
contract_diff
compatibility_check

Intent Stack

extract_intent
build_intent_graph
intent_to_contract

Projection Stack

semantic_delta_to_patch
graph_to_source
graph_to_tests

十二、Human-Facing 與 AI-Facing 必須分離

12.1 Human-Facing

人類需要：

Project Review；
Findings；
Impact；
Semantic Diff；
Graph；
Evidence；
PR Review。

12.2 AI-Facing

AI 不應透過 HTML 操作系統。

AI-facing interface 應提供：

query_subgraph
get_evidence
impact
semantic_diff
find_motif
get_contract
propose_delta
validate_delta
project_delta

12.3 Context Efficiency

AI 不必一次吃：

G

的全部節點。

而可以查：

G[S]

即與當前任務相關的 semantic slice。

這直接降低：

\text{Repository Context Cost}

十三、通用工作流

13.1 Understanding

Input Artifact
→ Observe
→ Normalize
→ Build Semantic Workspace
→ Query / Slice
→ Explain

13.2 Modification

Intent
→ Locate Semantic Region
→ Impact
→ Constraints
→ Generate Semantic Delta
→ Validate Delta
→ Project To Source
→ Reconstruct
→ Re-verify

13.3 PR Review

Base Revision
+
Head Revision
→ Semantic Diff
→ Impact Scope
→ New Defects
→ Review Fingerprint
→ Human Review

13.4 No-Source Artifact Workflow

Authorized Artifact
→ External Observation Adapter
→ Evidence Objects
→ Partial Semantic Workspace
→ Analysis Operators
→ Unknown Preservation

不要求 Source Code 必須存在。

十四、AI 原生的真正定義

本文將 AI-native software runtime 定義為：

系統的主要操作介面不是特定檔案格式或固定 UI，而是一組 AI 可以查詢、組合、驗證與重新投影的語義物件與運算算子。

因此：

\boxed{ \text{AI-Native} = \text{Semantic Objects} + \text{Composable Operators} + \text{Machine-Readable Workflow} + \text{Evidence} }

而不是：

\text{AI-Native} = \text{Chat UI}

十五、設計原則

15.1 Source 非唯一輸入

Source 是主要來源之一，但不是唯一來源。

15.2 Code 非唯一輸出

Code 是主要投影之一，但不是唯一輸出。

15.3 Unknown 一級化

未知不能被模型填補成假事實。

15.4 Operator 可替換

底層能力可以替換，不應綁死單一模型或單一 parser。

15.5 Provenance 不可丟失

任何高階結論都應能回到 evidence。

15.6 Capability 顯式

理解能力與執行權限必須分離。

15.7 Semantic Delta 優先

修改應優先表示為：

\Delta W

再投影成 code patch。

15.8 Projection 可逆優先

若可能，應支援：

W \rightarrow C \rightarrow W'

並驗證：

W\approx W'

十六、與 PBSOI 理論的關係

PBSOI 建立：

P^\ast \xrightarrow{\pi_L} C_L \xrightarrow{\rho_L} \widehat{P^\ast}

PSMR 則將此提升為：

X_k \xrightarrow{A_k} W \xrightarrow{O} W' \xrightarrow{P_j} Y_j

因此 PBSOI 可以被視為 PSMR 中：

\boxed{ \text{Program Source Projection / Inversion Domain} }

的第一個成熟實作。

十七、產品架構草案

AI-Native Program Semantic Mediation Runtime
│
├─ Input Adapters
│  ├─ Source Repository
│  ├─ Git / PR
│  ├─ Runtime Trace
│  ├─ API / Schema
│  ├─ Documentation / Intent
│  └─ Authorized Artifact Observation
│
├─ Semantic Workspace
│  ├─ Artifacts
│  ├─ Semantic Graphs
│  ├─ Contracts
│  ├─ History
│  ├─ Unknown / Conflict
│  └─ Capability / Authority
│
├─ Semantic Operators
│  ├─ PBSOI CISG Stack
│  ├─ Runtime Stack
│  ├─ Schema Stack
│  ├─ Intent Stack
│  └─ Projection Stack
│
├─ Workflow Runtime
│  ├─ DAG Execution
│  ├─ Checkpoint
│  ├─ Cache
│  ├─ Provenance
│  └─ Policy
│
├─ Output Projections
│  ├─ Source / Patch
│  ├─ Pull Request
│  ├─ Tests
│  ├─ Graph
│  ├─ Report
│  └─ Agent API
│
└─ Verification / Authority
   ├─ Evidence
   ├─ Contracts
   ├─ Capabilities
   ├─ Validation
   └─ Human Approval

十八、第一階段實作邊界

PSMR v0.x 不應一開始實作全部來源。

第一階段只需要把現有 PBSOI CISG v1.0 包進新的 Runtime Contract。

最小範圍：

\boxed{ \text{Source Repository} + \text{Git / PR} + \text{Semantic Workspace} + \text{PBSOI Operators} + \text{AI-facing API} }

先驗證：

AI 是否能透過 Workspace / Operator API 工作，而不是重新閱讀 repository。

十九、第二階段

再加入：

\text{Runtime Trace Adapter}

形成：

G_C \leftrightarrow G_R

並開始真正實作：

runtime drift；
static/runtime reconciliation；
state/effect observation。

二十、第三階段

加入：

\text{Intent Adapter}

與：

G_I

形成：

G_I \leftrightarrow G_C \leftrightarrow G_R

完成 PBSOI Paper 08 的三圖一致性工程化。

二十一、長期形態

最終 PSMR 不應只是 coding tool。

它可以成為：

\boxed{ \text{AI 與軟體世界之間的通用語義運算層} }

其角色類似：

OS 提供 process / file / memory abstraction；
database 提供 table / transaction abstraction；
PSMR 提供 artifact / semantic graph / contract / operator / workflow abstraction。

因此 AI 不必每次重新發明：

怎麼讀這個軟體？

而可以直接問：

我要在這個 Semantic Workspace 上做什麼運算？

二十二、結論

PBSOI CISG v1.0 證明了：

\text{Repository} \rightarrow \text{Semantic Structure}

可以成為真正可用的產品。

但下一個產品本體不應只是：

\text{Better Repository Analyzer}

而應是：

\boxed{ \text{AI-Native Program Semantic Mediation Runtime} }

其核心不再是「程式碼」，而是：

\boxed{ \text{Input} \rightarrow \text{Semantic Workspace} \rightarrow \text{Operator Workflow} \rightarrow \text{Projection} \rightarrow \text{Verification} }

Source Code 仍然重要。

但它只是：

\text{Input Projection}

也是：

\text{Output Projection}

而真正位於中心的是：

\boxed{ W = ( \text{Artifacts}, \text{Graphs}, \text{Contracts}, \text{History}, \text{Unknown}, \text{Authority} ) }

也就是一個 AI、人類與工具都可以共同操作的軟體語義世界。

PBSOI CISG v1.0 因此不被取代。

它被重新定位為：

\boxed{ \text{PSMR 的第一個成熟 Program Semantic Operator Stack} }

這個轉換使未來 Source、Runtime、Schema、Intent、Artifact、Agent 與其他分析工具都可以接入同一個工作流，而不必持續把所有功能堆進單一 Analyzer。

最終產品的核心問題也因此改變。

不再是：

AI 能不能讀懂這個 Repository？

而是：

AI 是否可以透過一個穩定、可追溯、可組合、可驗證的語義媒介層，直接運算軟體本身？