# 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 可以概括為：

```text
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

傳統模式：

```text
analyze(repository)
```

未來應改為：

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

其中：

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

---

## 6.1 基礎 Operator

第一組 Operator 可包含：

```text
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

例如：

```text
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

可以提供：

```text
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

```text
observe_trace
build_runtime_graph
runtime_diff
runtime_drift
```

### Schema Stack

```text
parse_schema
contract_diff
compatibility_check
```

### Intent Stack

```text
extract_intent
build_intent_graph
intent_to_contract
```

### Projection Stack

```text
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 應提供：

```text
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

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

---

## 13.2 Modification

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

---

## 13.3 PR Review

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

---

## 13.4 No-Source Artifact Workflow

```text
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}
}
$$

的第一個成熟實作。

---

# 十七、產品架構草案

```text
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 是否可以透過一個穩定、可追溯、可組合、可驗證的語義媒介層，直接運算軟體本身？**