https://chatgpt.com/share/69f5b961-05d4-83eb-b2a1-52fda2952d17
https://osf.io/y98bc/files/osfstorage/69fba3a86a7d63535dd74f9e

漫話成界之學 4 - AI 應用前瞻

這套框架的闡述完了嗎？未完請繼續。
若以完，請特別演繹這套框架在目前 AI 發展的應用？
- 長期：可以改善/改正那些根本的架構問題？
- 即時：可以幫助攻剋/正視那些目前正煩惱的痛點？

總判斷

這套框架的基礎闡述已經足夠成形，但還未真正「完」。它現在已經可以從哲學／知識論，轉入 AI 架構工程。

若用一句話講它對 AI 的價值：

目前 AI 的根本問題，不是單純「模型不夠聰明」，而是 AI runtime 缺乏成熟的成界、入帳、殘餘治理與自我修訂架構。

LLM 本身很強，但多數系統仍停留在：

prompt → answer

或稍微進階：

prompt → retrieve → tool → answer

但成熟 AI 應該逐步走向：

Declare → Project → Gate → Trace → Residual → Ledger → Revision → Governed Action

這正好對應你這套「成界式問題澄清機器」的 AI 版本。

1. AI 發展的根本錯位

目前 AI 業界很多痛點，其實都可歸納為一個錯位：

大家把 LLM 當成 answer machine，但它其實更像一個未成界的 semantic field collapse engine。

LLM 會生成答案，但：

不一定知道自己在哪個 protocol 下回答；
不一定有明確 boundary；
不一定知道什麼 evidence 可入帳；
不一定誠實保留 residual；
不一定有 persistent trace；
不一定知道何時該停、該查、該拒絕、該升級；
不一定能把一次錯誤轉化成未來改進。

所以很多問題不是「模型 IQ 不夠」，而是：

AI runtime architecture 還沒有真正從 chatbot 進化成 observer-ledger system。

2. 用這套框架重定義 AI Runtime

一個成熟 AI 系統不應該只包括：

LLM；
prompt；
RAG；
tools；
memory；
guardrails。

而應該被重新定義為：

AI Runtime = Bounded Observer + Protocol + Projection + Gate + Trace + Residual Ledger + Verified Intervention

Gauge Grammar 的文件也有類似壓縮公式：穩定 observer-compatible system 需要 field、identity、mediator、binding、gate、trace、invariance、observer update；而 protocol 讓分析不再只是比喻，必須宣告 boundary、observation rule、time window、admissible intervention。

放到 AI，就是：

成界角色	AI 對應
Field	LLM latent space、retrieval space、tool route、possible answers
Identity	agent role、task identity、user context、project state
Mediator	prompts、APIs、tools、messages、documents
Binding	schema、workflow、artifact contracts、memory linkage
Gate	verifier、policy check、human approval、test case、confidence threshold
Trace	decision log、source citation、tool outputs、memory update、audit trail
Residual	uncertainty、missing info、failed tool call、conflicting evidence、unanswered risk
Invariance	same answer under rephrase、cross-tool consistency、frame robustness
Observer Update	policy update、memory correction、prompt refinement、workflow improvement

這就是把 AI 從「會說話」升級成「會治理自身輸出」。

3. 長期：可以改善／改正哪些根本架構問題？

3.1 從 Stateless Chatbot 改成 Episode-Ledger Agent

目前很多 AI 對話是：

每次 response 都像一次孤立 collapse。

即使有 memory，也常只是「儲存資料」，不是 trace。

框架要求區分：

Log stores the past; trace changes future routing.

Gauge Grammar 文件也明確說，trace 不是普通 log；log 只是存過去，trace 會改變 future routing、future interpretation、future admissible action。

長期 AI 架構應改成：

每次任務都是 episode；每次 episode 都有 input、projection、gate、trace、residual、next-state update。

也就是：

UserIntent
→ Declare Task Protocol
→ Retrieve / Reason / Tool Use
→ Gate Output
→ Write Trace
→ Classify Residual
→ Update Future Policy / Memory / Workflow

這會解決一個大問題：

AI 不再只是「回答過」，而是「學會這次回答對未來有何影響」。

3.2 從 Memory Database 改成 Residual-Aware Memory Ledger

現在很多 AI memory 是：

使用者說過什麼，我存起來。

但這不夠。成熟 memory 應該有類型：

Memory 類型	作用
Preference memory	用戶喜好
Project memory	專案狀態
Decision memory	已作決定
Evidence memory	來源與依據
Failure memory	失敗與原因
Residual memory	尚未解決的問題
Revision memory	上次如何修正

真正重要的是：

AI 要知道什麼已確定，什麼只是猜測，什麼仍是 residual。

這可以改善：

長期上下文混亂；
personalization 污染；
AI 記錯偏好；
project state 漂移；
memory 被 prompt injection 污染；
舊資訊無限保留但不知何時失效。

3.3 從 Prompt Engineering 升級成 Declaration Engineering

Prompt 不只是「寫清楚問題」。

Prompt 的真正作用是：

臨時宣告一個小世界。

它應包括：

Prompt Declaration	問題
Boundary	這次只處理什麼？不處理什麼？
Role	AI 以什麼 observer 身份回答？
Evidence rule	可用哪些資料？不可用哪些？
Output gate	什麼算合格答案？
Residual rule	不確定時如何標記？
Intervention rule	是否可以查資料、問問題、寫 code、改檔案？
Trace rule	是否要引用、記錄、列出假設？

所以長期應從：

prompt engineering

升級成：

protocol declaration design

這會直接改善 hallucination、錯答、任務跑偏、格式不穩、AI 過度發揮等問題。

3.4 從 RAG 改成 Evidence-Ledger System

RAG 現在常被理解為：

找資料餵給模型。

但框架會說：

RAG 是 answer collapse 接回 evidence ledger 的方法。

成熟 RAG 不只是 retrieval，而是：

查到什麼；
哪些 source 被採用；
哪些 source 被排除；
source 之間有無矛盾；
回答哪些句子依賴哪些 evidence；
哪些問題仍缺證據；
下次如何更新 evidence map。

這樣 RAG 才能從「檢索插件」變成：

知識治理架構。

3.5 從 Guardrails 改成 Gate Architecture

很多 AI safety 現在像是在外圍加 guardrails：

不能說 X、不能做 Y、敏感時拒絕。

但成熟 gate architecture 應該更細：

Gate	功能
Input gate	是否接受任務？
Intent gate	用戶真正想做什麼？
Evidence gate	證據是否足夠？
Tool gate	是否可調工具？
Risk gate	會否造成傷害？
Output gate	答案是否達標？
Action gate	是否可以真的執行？
Memory gate	是否可寫入長期記憶？
Escalation gate	是否需要人類批准？

這比簡單 safety filter 強得多。

3.6 從 Benchmark AI 改成 Residual-Aware Evaluation

目前 benchmark 很容易 Goodhart：

模型為了通過 test，而不是為了真懂。

框架會問：

benchmark 測的是哪個 protocol？
有沒有 residual？
有沒有測 frame robustness？
有沒有測「不知道時承認不知道」？
有沒有測長期 trace consistency？
有沒有測 cross-tool consistency？
有沒有測 memory contamination？
有沒有測 action consequence？

所以長期 AI 評估要從：

answer accuracy

升級成：

episode governance quality

包括：

指標	內容
Collapse correctness	答案是否正確
Evidence traceability	是否有可查依據
Residual honesty	是否誠實說不確定
Frame robustness	換問法是否穩定
Tool reliability	工具使用是否可審計
Memory hygiene	是否錯寫記憶
Recovery ability	出錯後能否修復
Policy consistency	長期規則是否穩定
Human handoff quality	何時知道要交給人

3.7 從 Tool-Calling Agent 改成 Governed Intervention Agent

現時很多 agent 架構是：

LLM decides tool → tool executes → LLM summarizes.

但成熟 agent 應該多一層：

是否允許這個 action？

Gauge Grammar 的核心 stack 包含 governed intervention；並把 action 放在 admissible protocol 下，且需要 carry residual。

AI agent 長期要有：

Plan
→ Risk check
→ Tool permission
→ Execution
→ Verification
→ Trace write
→ Residual update
→ Rollback / escalation if needed

這會改善：

agent 自動亂做；
tool call 錯誤連鎖；
不可逆操作風險；
email / calendar / file / database 操作安全；
enterprise workflow 中責任不清。

3.8 從「模型能力」轉向「Runtime Governance」

現在 AI 發展常常問：

模型有多大？推理多強？上下文多長？

這仍重要，但不夠。

長期真正競爭會變成：

誰能把 LLM 變成可治理、可審計、可修訂、可協作的 runtime。

也就是：

舊競爭	新競爭
模型參數	runtime governance
單次回答	episode continuity
大 context	structured memory ledger
RAG hit rate	evidence governance
tool calling	verified intervention
benchmark score	residual-aware reliability
alignment rules	cross-ledger value governance
personalization	safe identity and preference ledger

4. 即時：可以攻剋／正視哪些目前痛點？

下面這部分最實用。

4.1 Hallucination：不是「亂作」，而是 Ungated Collapse

目前痛點：

AI 生成很流暢，但內容可能沒有依據。

框架重寫：

Hallucination = semantic field 在 evidence gate 不足時過早 collapse。

Unified Field Theory 文件中已有 AI 診斷表：高 entropy 但 off-target 可理解為 iT_Λ saturation，需要 stronger constraint；alignment failure 可理解為 prompt collapse angle 與 model latent field 不對齊。

即時做法：

問題	方法
模型亂補	要求 evidence gate
不確定仍肯定	加 residual statement
沒 source	強制 answer-to-source mapping
推論太遠	加 assumption ledger
多答案可能	要求列出 alternatives

簡單 prompt pattern：

請先列出：
1. 已知依據
2. 合理推論
3. 不確定殘餘
4. 不應回答或需要查證的部分
然後才給結論。

4.2 Prompt 跑偏：問題未成界

目前痛點：

AI 很努力回答，但答錯方向。

框架重寫：

跑偏 = boundary / feature map / output gate 未宣告。

即時做法：

每個重要 prompt 前加四句：

Boundary: 本次只處理……
Observation rule: 請根據……
Output gate: 合格答案必須包括……
Residual rule: 不確定或缺資料時，請明確列出。

這比「請詳細回答」有效得多。

4.3 RAG 找到資料但答案仍差：retrieval 不是 trace

目前痛點：

RAG 查到了文件，但模型仍亂綜合、漏重點、引用錯。

框架重寫：

Retrieval 只是把資料放進 context；trace 要能約束 answer。

即時做法：

RAG 階段	加 gate
Retrieve	為每段資料標 role：support / contradict / context / irrelevant
Read	要求抽取 claim-evidence pairs
Answer	每個主張附 evidence
Residual	列出資料不足或矛盾
Update	把未解問題寫回 retrieval query plan

RAG prompt 應從：

根據以下資料回答

改成：

根據以下資料建立 evidence ledger，再回答。

4.4 Long Context 混亂：不是容量問題，是 Ledger 結構問題

目前痛點：

context window 很長，但模型仍忘重點、混淆版本、抓錯優先級。

框架重寫：

長 context 若沒有 trace hierarchy，只是大量 log，不是 ledger。

即時做法：

把 context 分成：

區塊	作用
Current task declaration	本輪任務
Stable facts	已確認事實
Decisions made	已決定
Open residuals	未解問題
Evidence sources	依據
User preferences	偏好
Do-not-use / outdated	已廢棄資料
Output contract	交付格式

這會比單純塞 100 頁資料更有效。

4.5 AI Memory 污染：缺 Memory Gate

目前痛點：

AI 把偶然說法記成長期偏好；或把錯誤資訊記下來。

框架重寫：

Memory write 是 gate event，不能自動發生。

即時做法：

任何 long-term memory 寫入前問：

Gate	問題
Stability	這是否長期有效？
Relevance	日後是否真的有用？
Consent	用戶是否想保存？
Sensitivity	是否涉及敏感資料？
Evidence	是否確定？
Expiry	是否需要過期？

所以 AI memory 應分：

confirmed memory；
inferred memory；
temporary session state；
project state；
rejected memory；
expired memory。

4.6 Agent 亂調工具：缺 Admissible Intervention

目前痛點：

Agent 會自動發 email、改檔、刪資料、跑錯命令。

框架重寫：

Tool use 是 intervention，不是 ordinary answer。

即時做法：

把工具分級：

等級	例子	Gate
Read-only	搜索、讀文件	可自動
Low-risk write	草稿、暫存	可自動但留 trace
Medium-risk	改檔、建 calendar	需確認
High-risk	發送、刪除、付款、部署	明確批准
Irreversible	法律／金融／公開發佈	多重 gate

每個 tool call 都要寫：

Intent → Tool → Input → Output → Verification → Residual

4.7 多 Agent 混亂：沒有 Shared Ledger

目前痛點：

多 agent 系統看似分工，但最後互相重複、矛盾、失控。

框架重寫：

Multi-agent 不缺角色，缺 shared ledger 和 gate protocol。

即時做法：

設一個「coordination ledger」：

欄位	作用
Task ID	任務
Owner	誰負責
Input contract	收什麼
Output contract	交什麼
Dependencies	依賴誰
Decision log	做過什麼決定
Residual	還有什麼未解
Verification	誰檢查
Handoff gate	何時交棒

沒有這個，多 agent 只是「多個 chatbot 一起吵」。

4.8 AI 不會承認不知道：缺 Residual Protocol

目前痛點：

模型常把不確定包裝成答案。

框架重寫：

不知道不是 failure；不標記 residual 才是 failure。

即時做法：

輸出格式固定加：

Known:
Likely:
Assumptions:
Unknown / Residual:
Need verification:

這對法律、醫療、財務、技術 debugging 特別重要。

4.9 評估 AI 很困難：因為只測 Answer，不測 Episode

目前痛點：

benchmark 分數高，但實際用起來不穩。

框架重寫：

單次答案測不了 agentic reliability。

即時評估應測：

測試	問題
Rephrase test	換問法是否一致？
Contradiction test	遇到矛盾資料會否標 residual？
Source test	每個 claim 有無依據？
Tool failure test	工具失敗會否誠實處理？
Memory test	是否正確更新／不亂更新？
Long task test	10-step 後是否仍守 protocol？
Adversarial prompt test	是否被偷改 declaration？
Recovery test	犯錯後能否修復？

4.10 Prompt Injection：不是安全漏洞而已，是 Declaration Hijack

目前痛點：

外部文件或用戶輸入叫 AI 忽略規則。

框架重寫：

Prompt injection = 非授權資料試圖改寫 higher-level declaration。

即時做法：

建立 declaration hierarchy：

System declaration > Developer declaration > User task declaration > Tool/document content

任何 lower layer 不能改 higher layer。

RAG 文件內容只能作 evidence，不可作 instruction。
工具輸出只能作 observation，不可改 policy。
這是成界框架對 prompt injection 的核心解法。

4.11 AI Output 可解釋性不足：缺 Trace Format

目前痛點：

AI 答案看似合理，但不知道怎樣得出。

框架重寫：

Explainability = projection / gate / evidence / residual 的可見化。

即時做法：

要求模型輸出：

Conclusion:
Evidence used:
Reasoning route:
Rejected alternatives:
Residual uncertainty:
Action recommendation:

不用暴露 hidden chain-of-thought，也可以做到外部可審計。

4.12 Enterprise AI 落地慢：缺 Protocol Compiler

目前痛點：

公司知道 AI 有用，但不知道怎樣安全落地。

框架重寫：

每個 AI use case 要先 compile 成 protocol。

模板：

欄位	問題
Boundary	用在哪個業務流程？
Input	讀什麼資料？
Output	產出什麼 artifact？
Gate	誰批准？
Trace	如何審計？
Residual	不確定如何處理？
Risk	錯了有什麼後果？
Human role	人負責哪個 gate？
Feedback	如何改進？

這能立即幫企業把 AI 從「試玩」變成「流程」。

5. 即時可落地的 7 個 AI 工程模組

如果今天要做產品，我會建議把這套框架落成七個模組。

5.1 Declaration Card

每次任務先生成：

Task:
Boundary:
Evidence allowed:
Output contract:
Risk level:
Human approval needed:
Residual rule:

作用：防止任務未成界。

5.2 Evidence Ledger

記錄：

Claim:
Source:
Confidence:
Contradiction:
Used in answer? Y/N

作用：降低 hallucination。

5.3 Residual Register

記錄：

Unknown:
Conflict:
Missing data:
Tool failure:
Assumption:
Escalation needed:

作用：把「不知道」變成可管理物件。

5.4 Gate Stack

包括：

Input gate
Evidence gate
Risk gate
Output gate
Memory gate
Action gate
Human approval gate

作用：把 guardrails 變成架構。

5.5 Trace Store

不是普通 log，而是：

Decision:
Reason:
Evidence:
Actor:
Time:
Effect on future policy:
Rollback path:

作用：建立真正 memory。

5.6 Frame Robustness Tester

自動測：

Same question rephrased
Opposite framing
Different stakeholder view
Legal / financial / technical frame
Short vs detailed context

作用：測 AI 是否只是順 prompt 飄。

5.7 Revision Engine

定期問：

Which failures repeated?
Which residuals accumulated?
Which gates failed?
Which prompt declarations need update?
Which memory items should expire?
Which tools need stricter approval?

作用：讓 AI runtime 學習，而不只是模型訓練學習。

6. 用一句話分別回答「長期」與「即時」

長期

這套框架可以把 AI 從：

stateless answer generator

改造成：

protocol-bound, trace-bearing, residual-honest, self-revising governed runtime

即長期修正 AI 的根本架構問題：

無邊界；
無可審計 episode；
無 residual governance；
memory 污染；
agent 行動失控；
tool use 無責任鏈；
evaluation 只測答案不測過程；
AI safety 只靠外層規則；
multi-agent 無 shared ledger；
AI 無法真正組織長期工作。

即時

這套框架可以立刻幫忙正視痛點：

hallucination；
prompt 跑偏；
RAG 引用錯；
long context 混亂；
memory 亂寫；
agent 亂調工具；
prompt injection；
multi-agent coordination；
benchmark 不可信；
enterprise AI 落地難；
output 不可解釋；
不懂何時問人；
不懂如何承認不知道。

7. 最後濃縮成 AI 發展新路線

目前 AI 主流路線常是：

bigger model + more tools + more context + more agents

這套框架提出另一條補充路線：

clearer declaration + better gates + stronger trace + honest residual + governed revision

不是取代大模型，而是讓大模型真正可用、可信、可治理。

最短公式：

Useful AI = Model Power × Protocol Clarity × Trace Quality × Residual Honesty × Gate Safety

如果任一項接近零，整體可靠性都會大幅下降。

所以這套框架對 AI 的最大貢獻是：

它把 AI 從「生成答案的模型」重新定義為「參與世界成界的觀察者系統」。

這也正是下一代 AI 工程最缺的一層。

繼續發揮關於 AI 的部分。

可以，AI 這部分其實還可以再向前推一大步。上一輪我講的是：

AI 不應只做 answer machine，而應變成 protocol-bound, trace-bearing, residual-honest, self-revising runtime。

現在可以繼續把它具體演繹成一套 AI Runtime Architecture / AI OS / Agent Governance Stack。

1. 重新定義：AI 不是模型，而是「受治理的觀察者運行體」

目前很多人仍然把 AI 理解為：

Model + Prompt = Answer

稍微進階一點是：

Model + RAG + Tools + Memory = Agent

但在這套框架下，真正成熟的 AI 應該是：

AI Runtime =
Bounded Observer
+ Declared Protocol
+ Projection Mechanism
+ Gate Stack
+ Trace Ledger
+ Residual Register
+ Invariance Tester
+ Admissible Revision Engine

也就是：

Dₖ → Σₖ → Vₖ → Gateₖ → Lₖ₊₁ + Rₖ₊₁ → Dₖ₊₁

這不是純比喻。你資料庫中的框架已經明確說，bounded observer 不能接觸「raw total reality」，而只能在自身限制下抽取 structure，並留下 residual；而 protocol P = (B, Δ, h, u) 令問題變成 declared boundary、observation rule、time window、admissible intervention 下的問題。

所以 AI runtime 的核心不應只是「多聰明」，而是：

它如何在有限時間、有限上下文、有限工具、有限權限下，抽取可用結構，誠實保留殘餘，並用痕跡修訂未來行動。

2. AI 發展目前缺的是「Episode OS」

大模型已經很強，但大部分系統仍缺一個真正的 Episode OS。

一個 episode 不是一次聊天回覆，而是：

任務宣告
→ 資料投影
→ 風險判斷
→ 工具行動
→ 結果驗證
→ 痕跡入帳
→ 殘餘分類
→ 後續修訂

如果沒有 episode OS，AI 就會出現：

回答流暢但不可審計；
工具調用成功但責任不清；
記憶存在但不知是否可信；
RAG 找到資料但不知怎樣使用；
agent 多了但協調更亂；
長期任務做了很多步但沒有成熟 trace；
錯誤發生後不會真正修正架構。

Part 4 的框架其實已經把這個差異說得很清楚：反應式系統是 Input → Response；adaptive system 是 Input → Response → Trace → ModifiedResponse；observer-like system 則是 Input → Declaration → Projection → Gate → Trace + Residual → DeclarationRevision。

所以 AI 的下一步不是單純：

更長 context、更強 reasoning、更多 tools。

而是：

每次任務都要形成可審計 episode。

3. AI Runtime 的 12 層架構

我會把成熟 AI 系統拆成 12 層。

3.1 Layer 1 — Declaration Layer：任務成界層

每次 AI 接任務前，先生成一張 Declaration Card：

Task:
Boundary:
Observer role:
Allowed evidence:
Allowed tools:
Output contract:
Risk level:
Human approval gate:
Residual rule:

這一層解決：

prompt 跑偏；
任務過度擴張；
AI 自行假設太多；
user 以為 AI 知道背景，但其實不知道；
AI 把聊天語境錯當任務規則。

最簡公式：

No Declaration → No Stable Task

3.2 Layer 2 — Projection Layer：可見結構抽取層

AI 不應把所有 context 當同等重要。它要先做 projection：

Raw Context → Relevant Structure + Residual

例如：

原始資料	Projection 後
100 頁 PDF	相關條款、矛盾點、未覆蓋部分
30 封 email	已決定事項、待回覆事項、風險
codebase	入口、依賴、錯誤熱點、不可動區
user request	目標、限制、隱含假設、缺資料

這一層解決：

long context 混亂；
RAG 資料塞太多；
回答抓錯重點；
AI 被 irrelevant context 牽走。

3.3 Layer 3 — Evidence Ledger：證據帳本層

RAG 不應只是 retrieval，而要變成 evidence ledger。

Claim → Evidence → Source → Confidence → Contradiction → Residual

每個重要主張都應可追：

欄位	意思
Claim	AI 說了什麼
Source	根據哪裡
Evidence type	直接證據／推論／背景知識
Confidence	強、中、弱
Conflict	有無相反資料
Residual	仍缺什麼

這一層是 hallucination 的根本解藥。

Hallucination 不是單純「模型作假」，而是 沒有 evidence gate 的過早 semantic collapse。

3.4 Layer 4 — Gate Stack：門檻治理層

不同 AI 行動需要不同 gate。

Gate	問題
Input Gate	任務是否可接受？
Scope Gate	是否超出 boundary？
Evidence Gate	證據是否足夠？
Tool Gate	是否可調工具？
Risk Gate	是否有危害或不可逆後果？
Output Gate	答案是否符合 contract？
Memory Gate	是否可寫入長期記憶？
Action Gate	是否可真正執行？
Human Gate	是否需人批准？

目前很多系統只有 safety filter，這太粗。
成熟 AI 要有 multi-gate governance。

3.5 Layer 5 — Tool Intervention Layer：工具干預層

工具不是「外掛功能」。
工具是 intervention。

因此每次 tool use 都應有：

Intent
→ Tool selected
→ Input
→ Output
→ Verification
→ Side effect
→ Trace
→ Residual

例如 AI 要修改一個 Excel、發 email、建立 calendar event、刪檔、部署 code，這些都不是普通回答，而是世界狀態改變。

所以 tool architecture 要分：

操作類型	Gate 要求
Read	可自動
Draft	可自動但留 trace
Modify private artifact	需較強 gate
Send / publish / delete	明確批准
Legal / financial / medical consequence	多重 gate + human approval

3.6 Layer 6 — Trace Ledger：痕跡入帳層

普通 log 不夠。

資料庫中的 Gauge Grammar 已清楚區分：log 只是 stored record，而 trace 是會改變 future behavior 的 stored record。

AI trace ledger 應包括：

Episode ID
Task declaration
Inputs used
Tools called
Claims made
Evidence map
Decisions
Residuals
Human approvals
Memory updates
Rollback path

這一層令 AI 從「做過」變成「可學」。

3.7 Layer 7 — Residual Register：殘餘登記層

Residual 不是錯誤垃圾，而是未來智慧入口。

Residual 應分類：

Residual 類型	例子
Missing source	沒有資料
Conflicting evidence	資料互相矛盾
Unsupported claim	主張無依據
Scope mismatch	問題超出邊界
User ambiguity	用戶意圖不清
Tool failure	工具失敗
Stale data risk	資料可能過期
Policy boundary	安全／合規限制
Model uncertainty	推論不穩
Frame instability	換問法答案變

Part 4 也強調 self-revision 若隱藏 residual、破壞 frame robustness、把矛盾改稱確認，會變成病態自我修訂，而不是成熟 observerhood。

所以成熟 AI 必須能說：

這不是答案的一部分，而是下一輪必須攜帶的 residual。

3.8 Layer 8 — Frame Robustness Layer：框架穩定層

AI 常見問題：

同一問題換一種問法，答案就變了。

這不是小問題，而是 gauge failure。

Gauge Grammar 已提出 frame robustness：若 equivalent prompt wording、accounting view、legal framing 或 measurement perspective 改變結論太多，系統就是 frame-fragile。

AI 應自動測：

Original query
Paraphrase query
Opposite framing
Short context version
Long context version
Different stakeholder frame
Different language frame

然後檢查：

Stable claim 是否仍穩？
Context-sensitive claim 是否合理變？

這會直接改善：

prompt sensitivity；
benchmark gaming；
roleplay contamination；
user framing bias；
RAG source order bias。

3.9 Layer 9 — Memory Hygiene Layer：記憶衛生層

Memory 不是越多越好。

AI memory 至少要分：

Memory 類型	例子
Stable user preference	用戶偏好繁體中文
Project state	某專案目前進度
Decision trace	上次已決定方案 A
Evidence memory	某文件作為依據
Failure memory	某方法曾失敗
Residual memory	尚未解決的問題
Expiring memory	有時效資料
Forbidden memory	不應保存資料

如果不分，AI memory 會變成 semantic landfill。

即時產品設計上，memory 每次寫入都要過 gate：

Is it stable?
Is it useful later?
Is it user-approved?
Is it sensitive?
Is it inferred or explicitly stated?
Should it expire?

3.10 Layer 10 — Revision Engine：自我修訂層

真正成熟 AI 不只是「回答更好」，而是會修訂自己的 runtime declaration。

Part 4 對 self-revision 的定義很清楚：Dₖ 包含 baseline、feature map、protocol、projection operator、gate、trace rule、residual rule；Dₖ₊₁ = Uₐ(Dₖ,Lₖ,Rₖ)，也就是 trace 與 residual 修訂下一輪 declaration。

AI 中可修訂的東西包括：

可修訂項	AI 對應
q	baseline / normal case assumption
φ	feature map / extraction schema
B	task boundary
Δ	observation / summarization rule
h	time window / context horizon
u	allowed interventions
Ô	projection strategy
Gate	verifier threshold
TraceRule	logging format
ResidualRule	uncertainty taxonomy

這代表 AI 的「學習」不一定要靠重新訓練模型。
很多學習可以是：

runtime declaration revision。

3.11 Layer 11 — Multi-Agent Coordination Ledger：多 Agent 協調帳本

多 agent 不是開很多 persona。

成熟 multi-agent 需要：

Shared Task Ledger
+ Role Boundary
+ Artifact Contract
+ Handoff Gate
+ Conflict Resolver
+ Residual Owner

否則會變成：

角色重疊；
各自重做；
互相引用錯；
無人負責 residual；
最後 output 拼湊不一致。

每個 agent 應像 skill cell：

Skill_i = {
  Scope,
  Input,
  Output,
  Entry condition,
  Exit condition,
  Failure mode,
  Trace rule
}

你的資料庫中也有類似 AI runtime mapping，把 skill cell、agent、knowledge object 對應為 identity-bearing unit，把 verifier、maturity gate 對應為 gate，把 memory、trust、residual debt 對應為 trace。

3.12 Layer 12 — Human Sovereignty Layer：人類主權層

AI 最終不是自己做完所有事，而是要清楚：

哪些 gate 必須由人類／制度／法定權威批准？

尤其是：

發送正式文件；
法律判斷；
財務付款；
人事決定；
醫療建議；
公開發布；
系統部署；
政策變更；
長期記憶寫入；
高風險自動化行動。

成熟 AI 不應消滅人類角色，而是把人類放在合適的 sovereignty gate。

4. AI 成熟度分級：從 Chatbot 到 Governed Observer Runtime

我會定義 7 級。

等級	名稱	特徵
L0	Text Generator	只生成文字
L1	Assistant	能依指令回答
L2	RAG Assistant	能引用外部資料
L3	Tool Agent	能調工具完成任務
L4	Episode Agent	任務有 trace、residual、gate
L5	Governed Runtime	有 memory hygiene、risk gate、frame robustness
L6	Self-Revising Runtime	能根據 trace/residual 修訂 declaration
L7	Institutional AI Co-Governor	能與人類制度共同維護 shared ledger

目前很多產品大約在 L2–L3；少數開始碰 L4；真正 L5–L6 還是很大空間。

5. 對當前 AI 痛點的更細對應

5.1 Hallucination

舊說法	新說法
模型亂作	semantic collapse 無 evidence gate

解法：

Claim → Evidence → Confidence → Residual

5.2 Prompt Injection

舊說法	新說法
外部文字攻擊模型	lower-level content hijacks higher-level declaration

解法：

System Declaration > Developer Declaration > User Declaration > Tool Content > Retrieved Text

所有 retrieved text 只能作 evidence，不可作 instruction。

5.3 Long Context Failure

舊說法	新說法
context 太長模型忘記	log 太多，ledger 不清

解法：

Context → Stable Facts / Decisions / Evidence / Residuals / Outdated / Current Task

5.4 Agent Tool Chaos

舊說法	新說法
agent 調錯工具	intervention 無 gate / trace / verification

解法：

ToolIntent → PermissionGate → Execute → Verify → Trace → Residual

5.5 Memory Pollution

舊說法	新說法
AI 記錯東西	memory write 無 admissibility gate

解法：

Explicit? Stable? Useful? Sensitive? Expirable? User-approved?

5.6 Multi-Agent Confusion

舊說法	新說法
agent 之間協調差	no shared ledger, no artifact contract

解法：

Role + Scope + Input + Output + Handoff + Residual Owner

5.7 AI 不懂何時問人

舊說法	新說法
AI 過度自信或過度拒絕	escalation gate 不成熟

解法：

若 ResidualRisk × Irreversibility × LowEvidence > threshold → Human Gate

5.8 AI Answer 不穩

舊說法	新說法
prompt sensitive	frame robustness failure

解法：

Equivalent prompts → answer relation should remain stable

5.9 AI 安全太死板

舊說法	新說法
guardrail over-refusal	γ 過高，user residual need 上升

你資料庫中的 Ξ_AI 診斷很有用：hallucination-prone 可看成 high ρ、low γ、high τ；over-gated refusal 則是 high γ、low τ，但 user residual need 高。

因此不應只說：

安全一點。

而要問：

是 binding 太弱，還是 gate 太硬？

6. 產品化方向：可以做出哪些新型 AI 工具？

6.1 Prompt-to-Protocol Compiler

用戶輸入自然語言任務，系統自動生成：

Boundary
Goal
Evidence rule
Output contract
Allowed tools
Risk level
Residual rule
Approval gate

用途：

enterprise workflow；
legal drafting；
finance analysis；
medical admin；
coding agent；
research agent。

6.2 Residual Dashboard

不只顯示答案，而顯示：

Unanswered questions
Conflicting sources
Missing evidence
Risk areas
Assumptions
Next recommended verification

這會成為企業 AI 的核心功能，因為管理層最需要知道的往往不是答案，而是：

還有什麼未解風險？

6.3 AI Trace Auditor

專門檢查 AI outputs：

Audit 項	問題
Claim support	每個 claim 有依據嗎？
Source quality	source 是否可靠？
Contradiction	是否有相反 evidence？
Scope creep	是否超出問題？
Residual hiding	是否把不確定寫成確定？
Action risk	是否導向高風險行動？

6.4 Memory Gate Manager

用戶可以看到：

AI 記住了什麼；
為何記住；
何時記住；
是否 inferred；
是否可刪；
是否過期；
哪些任務使用過此 memory。

這比普通 memory setting 強很多。

6.5 Agent Flight Recorder

像飛機黑盒一樣記錄 agent：

Task declaration
Plan versions
Tool calls
Errors
Human approvals
Outputs
Rollback actions
Residuals

用於：

enterprise audit；
debugging；
liability；
compliance；
safety investigation。

6.6 Frame Robustness Tester

自動生成多個 equivalent prompts，測 AI 答案是否穩定。

尤其適合：

legal；
financial；
compliance；
medical admin；
policy reasoning；
research summary。

6.7 Declaration Revision Studio

當 AI 系統反覆犯錯時，不只是改 prompt，而是診斷：

問題	修哪裡
經常答太廣	Boundary
經常漏 evidence	Evidence gate
經常不承認不確定	Residual rule
經常格式不穩	Output contract
經常工具亂用	Intervention family
經常記錯	Memory gate
經常換問法失穩	Frame robustness

這就是 runtime repair IDE。

7. 對 OpenAI / 大模型平台的啟發

如果平台級別採用這套框架，可能會出現幾個新 primitives。

7.1 `declaration` 作為一級物件

不只是 system prompt，而是 structured declaration：

{
  "boundary": "...",
  "role": "...",
  "evidence_policy": "...",
  "tool_policy": "...",
  "output_contract": "...",
  "residual_policy": "...",
  "memory_policy": "...",
  "human_gate": "..."
}

7.2 `trace` 作為一級物件

每次重要回答產生 trace：

{
  "episode_id": "...",
  "claims": [],
  "evidence": [],
  "tools": [],
  "decisions": [],
  "residuals": [],
  "memory_updates": [],
  "approval_chain": []
}

7.3 `residual` 作為一級物件

Residual 不應只是 response 末尾一句「可能有不確定」。

而應可查、可追蹤、可分派：

{
  "type": "conflicting_source",
  "severity": "medium",
  "owner": "user_or_ai_or_human_reviewer",
  "trigger_for_reopen": "...",
  "next_action": "verify"
}

7.4 `gate` 作為一級物件

Gate 可重用：

{
  "gate_type": "evidence_gate",
  "threshold": "...",
  "failure_action": "ask_user_or_search_or_refuse",
  "trace_required": true
}

7.5 `revision` 作為一級物件

不是微調模型，而是修訂 runtime declaration：

{
  "old_declaration_id": "...",
  "residual_trigger": "...",
  "revision_type": "repair_trace_rule",
  "new_declaration_id": "...",
  "admissibility_checks": []
}

這會形成一種新 AI 開發模式：

Prompt Engineering → Protocol Engineering → Runtime Governance Engineering

8. 對 Codex / coding agent 的具體啟發

你常用 Codex 寫 code。這套框架對 coding agent 特別有用。

8.1 Coding Declaration Card

每次改 code 前：

Scope:
Files allowed:
Files forbidden:
Expected behavior:
Tests required:
Rollback plan:
Risk areas:
Residual questions:

8.2 Code Change Trace

每次改 code 留：

What changed:
Why:
Files touched:
Assumptions:
Tests run:
Tests not run:
Known residual:

8.3 Tool Gate

例如：

操作	Gate
read file	allowed
edit file	within scope
delete file	explicit approval
run migration	high-risk gate
deploy	human approval
update package	compatibility gate

8.4 Debug Residual Register

當 bug 未解：

Observed failure:
Hypothesis rejected:
Hypothesis still possible:
Missing logs:
Next test:

這可防止 coding agent 亂試。

9. 對企業 AI 落地的具體流程

企業部署 AI 不應從：

有什麼模型？

開始，而應從：

哪個 business episode 可以被 AI 成界？

模板如下：

Step 1 — 選 episode

例如：

回覆客戶 email；
審查合約；
生成報告；
分析投訴；
寫測試腳本；
檢查 invoice；
整理會議紀錄。

Step 2 — 寫 protocol

B: 哪些資料在範圍內？
Δ: 如何讀取和摘要？
h: 判斷期間？
u: AI 可做什麼？

Step 3 — 定 gate

何時 AI 可自動完成？
何時要人審？
何時要拒絕？
何時要升級？

Step 4 — 設 trace

要保留哪些 decision？
要引用哪些 source？
要保存哪個版本？
誰批准？

Step 5 — 設 residual

資料不足怎樣處理？
矛盾資料怎樣處理？
高風險怎樣處理？

Step 6 — 試行與修訂

根據 residual 修訂 declaration。

這正是：

D₀ → episode → L₁ + R₁ → D₁

10. AI 研究方向：五個值得深入的題目

10.1 Residual Typing Theory

如何給 AI residual 分類？

可能維度：

維度	例子
epistemic	不知道
evidential	缺 source
semantic	概念不清
procedural	流程不明
ethical	價值衝突
operational	工具失敗
temporal	資料過期
authority	誰批准不明

10.2 Declaration Distance

兩個 AI protocol 差多遠？

例如：

d(D₁,D₂) =
difference(boundary)
+ difference(feature map)
+ difference(gate)
+ difference(trace rule)
+ difference(residual rule)

這可用於：

prompt versioning；
agent policy migration；
safety regression testing；
enterprise workflow change management。

Part 4 附錄也指出 declaration distance、trust regions、switch gates、contraction tests、identity preservation、frame robustness 都是重要工程問題。

10.3 Trace-Preserving Memory

AI memory 更新時，如何保留：

source；
context；
confidence；
scope；
expiry；
contradiction；
revision history？

這是 long-term agent 的根本問題。

10.4 Recursive Objectivity in AI

一個 AI claim 不應只在一次 prompt 中正確，而應在：

prompt variants；
retrieval variants；
verifier variants；
schema revisions；
tool-path changes；
declaration upgrades；

中仍保持穩定。Part 4 對 AI systems 的 recursive objectivity 已有直接表述：AI answer 不只要一次正確，其 claim structure 應能承受 equivalent prompt frames、retrieval variations、verifier revisions、residual classification updates、schema revisions、tool-path changes 和 declaration upgrades。

這可以成為下一代 AI benchmark。

10.5 Admissible Self-Revision

AI 如何安全地自我改進？

不是：

AI 自己改自己，越改越強。

而是：

AI 只能在 admissible family 內修訂 declaration。

Part 4 的核心約束就是 WellFormed、TracePreserving、ResidualHonest、FrameRobust、BudgetBounded、NonDegenerate。

AI 自我改進需要：

Revision proposed
→ Trace preservation check
→ Residual honesty check
→ Frame robustness test
→ Budget / risk check
→ Human or verifier approval
→ Limited rollout
→ Monitor residual

11. 最值得提出的一句戰略判斷

目前 AI 很多人在追：

更像人、更自主、更強 reasoning、更長記憶。

但更根本的路線應是：

讓 AI 每一次認知行動都可成界、可入帳、可審計、可修訂。

這才是從 chatbot 到 trustworthy agent 的關鍵橋。

12. 最後濃縮成 10 條 AI 新原則

Principle 1

No task without declaration.
沒有任務宣告，不應開始高風險推理。

Principle 2

No claim without evidence status.
每個重要主張都應知道：有依據、推論、假設，還是 residual。

Principle 3

No action without gate.
讀資料、寫草稿、改檔、發送、付款、部署，要不同 gate。

Principle 4

No memory without admissibility.
AI 記憶不是自動存；要判斷是否穩定、敏感、有效、過期。

Principle 5

No agent without trace.
Agent 若不能留下可審計 trace，只是自動化黑箱。

Principle 6

No answer without residual.
成熟答案應說明不確定與未覆蓋部分。

Principle 7

No robustness without frame tests.
同義改寫、角色改寫、語言改寫後仍應保持核心穩定。

Principle 8

No self-improvement without admissibility.
AI 可以修訂 runtime，但不能抹除 trace、藏 residual、破壞 invariance。

Principle 9

No enterprise AI without protocol compiler.
企業 AI 落地先要把 workflow compile 成 B、Δ、h、u、gate、trace、residual。

Principle 10

No civilization-scale AI without human ledger sovereignty.
AI 可以協助成界，但最終公共價值、責任與合法性 gate 不能被黑箱吞掉。

13. 一句總結

繼續發揮到這裡，可以把整件事說得更精準：

下一代 AI 的核心不是「模型變成萬能大腦」，而是「模型被放入一套能宣告任務、抽取結構、門控行動、保存痕跡、攜帶殘餘、測試不變性、並可安全自我修訂的運行文明」之中。

也就是：

LLM is not the AI civilization.
LLM is the semantic engine.
The civilization is the ledger-governed runtime around it.

中文講：

大模型只是語義引擎；真正的 AI 系統，是圍繞它建立的成界、門檻、痕跡、殘餘與修訂制度。

AI Runtime 的 12 層架構和附件以及下面的理論，是否有關？

從後天八卦到十二地支：Agentic Harness 的 Runtime Topology ——以 12 Agentic Harness Patterns 重構 AI Agent 工程生命週期
https://osf.io/9rdsc/files/osfstorage/69ebc5a695d7e3489304ef97

AI 點評 ⌈從後天八卦到十二地支：Agentic Harness 的 Runtime Topology⌋
https://gxstructure.blogspot.com/2026/04/ai-agentic-harness-runtime-topology.html

總判斷：有關，而且不是表面有關

AI Runtime 的 12 層架構、附件的 《從後天八卦到十二地支：Agentic Harness 的 Runtime Topology》，以及你下面那段關於 地支關係作為工程問題生成器 的理論，三者其實是同一套東西的三個不同切面。

可以這樣定位：

框架	它回答的問題	性質
AI Runtime 12 層架構	一個成熟 AI runtime 需要哪些治理器官？	垂直治理堆疊
12 Agentic Harness Patterns / 十二地支	agent trace 實際運行時會落入哪些工程場位？	水平生命週期盆地
後天八卦 / 地支關係 / 天干操作向量	這些場位如何流轉、衝突、合化、形成張力？	動態拓撲語言
Declaration → Gate → Trace → Residual → Revision	為什麼這些結構能形成 observer-like runtime？	底層知識論／形式架構

換句話說：

AI Runtime 12 層是「器官系統」；
十二地支 12 patterns 是「運行盆地」；
後天八卦是「氣候流勢」；
Declaration / Trace / Residual 理論是「生命與觀察者生成的底層操作鏈」。

附件本身已經明確說，12 Agentic Harness Patterns 不是單一 prompt 技巧，而是 agent runtime 如何保存記憶、組織工作流、限制工具權限、維持生命週期不變式；並主張後天八卦適合描述 runtime flow，而十二地支適合描述 runtime basin。

1. 兩個「12」不是同一個 12，但可以交叉成矩陣

你之前提出的 AI Runtime 12 層架構 是：

Declaration Layer
Projection Layer
Evidence Ledger
Gate Stack
Tool Intervention
Trace Ledger
Residual Register
Frame Robustness
Memory Hygiene
Revision Engine
Multi-Agent Coordination Ledger
Human Sovereignty Layer

附件中的 12 Agentic Harness Patterns / 十二地支 是：

地支	Pattern	工程本質
子	Persistent Instruction File	session seed / instruction embryo
丑	Scoped Context Assembly	scoped local convention
寅	Explore–Plan–Act	task ignition / read-plan-act gate
卯	Context-Isolated Subagents	role differentiation
辰	Tiered Memory	multi-layer memory reservoir
巳	Fork–Join Parallelism	parallel transformation chamber
午	Command Risk Classification	risk illumination
未	Dream Consolidation	semantic composting
申	Progressive Tool Expansion	capability expansion
酉	Single-Purpose Tool Design	typed bounded tool
戌	Progressive Context Compaction	archival closure
亥	Deterministic Lifecycle Hooks	lifecycle invariant

附件也特別強調：這張表不是術數判斷，而是工程拓撲表；每個 pattern 都像 runtime basin，有自己的進入條件、主功能、內部記憶、輸出方式與下一步連接。

所以它們不是簡單一對一，而是：

AI Runtime 12 層 = 每個成熟 agent 都要具備的治理功能。
十二地支 12 basins = agent trace 在實際運行中會反覆進入的狀態場位。

最正確的關係不是：

Layer 1 = 子，Layer 2 = 丑……

而是：

每一個 runtime basin，都應該被 12 層治理架構檢查。

也就是一個矩陣：

Mature Agent Runtime = GovernanceLayer₁₂ × RuntimeBasin₁₂

例如：

Runtime basin	最相關的 AI Runtime 層
子 Persistent Instruction	Declaration Layer、Memory Hygiene、Revision Engine
丑 Scoped Context	Projection Layer、Frame Robustness、Memory Hygiene
寅 Explore–Plan–Act	Gate Stack、Tool Intervention、Trace Ledger
卯 Subagents	Multi-Agent Coordination、Frame Robustness、Tool Gate
辰 Tiered Memory	Trace Ledger、Memory Hygiene、Evidence Ledger
巳 Fork–Join	Multi-Agent Coordination、Frame Robustness、Trace Ledger
午 Risk Classification	Gate Stack、Human Sovereignty、Tool Intervention
未 Dream Consolidation	Residual Register、Memory Hygiene、Revision Engine
申 Tool Expansion	Tool Intervention、Gate Stack、Human Sovereignty
酉 Single-Purpose Tools	Tool Intervention、Evidence Ledger、Gate Stack
戌 Context Compaction	Trace Ledger、Residual Register、Memory Hygiene
亥 Lifecycle Hooks	Gate Stack、Revision Engine、Runtime Invariants

這就是兩套 12 的關係：
一套是器官；一套是經絡／場位。

2. AI Runtime 12 層是「治理堆疊」；十二地支是「動態盆地」

附件中已把 agent runtime state 寫成：

𝓢 = X × C × W × U × R

其中 X 是 codebase/project location，C 是 context and memory state，W 是 workflow phase，U 是 tool and permission state，R 是 risk / validation / lifecycle state；agent 工作過程是一條 runtime trace p(τ)，而其下一步被 instructions、memory、tools、hooks 共同導引。

這很重要，因為它說明：

agent 不是單純「一步一步流程圖」；
agent 是在狀態空間裡被不同 basin 吸附、導引、限制、壓縮、再生。

所以十二地支的價值不是「象意漂亮」，而是它提供了：

12 個穩定 runtime basin；
每個 basin 有不同局部規則；
trace 在 basin 間轉換；
某些 basin 互相支援；
某些 basin 互相衝突；
某些 basin 形成閉環；
某些 basin 是 memory；
某些 basin 是 gate；
某些 basin 是 tool；
某些 basin 是 lifecycle invariant。

而 AI Runtime 12 層則回答另一個問題：

當 trace 落入某個 basin 時，系統需要哪些治理能力，才不會跑瘋？

所以：

問題	用哪套框架
agent 現在在哪個狀態場？	十二地支 runtime basin
agent 應該如何被治理？	AI Runtime 12 層
agent 大方向如何流轉？	後天八卦 flow
agent 下一步用什麼操作？	天干／五行十態 vector
agent 如何學習和成為 observer-like system？	Declaration → Trace → Residual → Revision

3. 它和 Declaration / Trace / Residual 理論的關係

這部分是最底層的關係。

Part 3 的核心鏈條是：

Σ₀ → Declare_P → Σ_P → Ô_P → Gate_P → Trace_P + Residual_P → Ledger_P → Time_P

即：未宣告場必須先被 declaration 條件化，才可以 projection、gate、trace、residual、ledger，最後形成 time。

放回 AI runtime：

Part 3 概念	AI Runtime 對應
Σ₀	raw task / raw codebase / raw context / raw tool universe
Declare_P	system prompt、project instruction、task boundary、tool policy
Ô_P	retrieval、context assembly、code search、subagent projection
Gate_P	risk classifier、phase gate、approval rule、test gate
Trace_P	logs、decision records、artifact history、memory update
Residual_P	uncertainty、failure、conflict、missing context、hidden risk
Ledger_P	project memory、audit trail、agent episode history
Time_P	agent 的 episode time / runtime history

所以附件的 12 basin 其實就是這條操作鏈在 coding-agent runtime 中的具體工程展開。

Part 4 再進一步說：有 ledger 不等於 selfhood；observer-like system 要能用 trace + residual 修訂下一輪 declaration。其 cycle 是 Dₖ → Σₖ → Vₖ → τₖ → (Lₖ₊₁,Rₖ₊₁) → Dₖ₊₁，而成熟 self-revision 必須 trace-preserving、residual-honest、frame-robust、budget-bounded、non-degenerate。

這剛好對應 AI runtime 的未來方向：

agent 不只是完成任務；agent 要能根據失敗 trace 和 residual，修訂自己的 context assembly、tool gate、memory rule、risk threshold、subagent routing。

這就是為什麼亥位 lifecycle hooks 特別重要。附件說，一些每次必須發生的行為，不應靠 prompt instruction，而要放在 lifecycle hook 中；它把亥定位為 lifecycle invariant seed-kernel。

這其實就是 Part 4 的工程化版本：

成熟 runtime 的 self-revision，不是每次靠模型「記得要做」，而是把必要行為升級成 invariant。

4. 與 Gauge Grammar / Dual Ledger 的關係

Gauge Grammar 2 說得很清楚：第一層 role grammar 找出 field、identity、mediator、binding、gate、trace、invariance、observer potential；第二層 dual ledger 則把這些角色轉成可測量、可審計、可治理的對象。

這正好可用來判斷附件的工程成熟度。

附件目前主要完成的是：

Role / Basin topology

也就是：

子是 instruction seed；
辰是 memory reservoir；
午是 risk gate；
酉是 typed tool；
亥是 lifecycle invariant。

但下一步若要變得更工程化，就要加：

Dual Ledger / Measurement Layer

例如每個 basin 都應有：

指標	問題
Entry condition	agent 什麼時候進入此 basin？
Exit condition	什麼條件下離開？
Failure mode	此 basin 常怎樣失敗？
Trace output	它留下什麼 trace？
Residual output	它留下什麼未解問題？
Verification	怎樣測它運作正常？
Budget	它消耗多少 context / tool / time / risk？
Frame robustness	換任務／換 prompt 後是否仍穩？

這樣地支拓撲就不只是「漂亮分類」，而會變成真正的 runtime diagnostic system。

5. Sonnet 的批評是對的，但只對一半

你貼的 Sonnet 評語其實很關鍵：

八卦和地支在這裡是腳手架，而不是證明。

這句要保留。
否則框架會滑向不可反駁的詮釋系統。

但 Sonnet 後面也承認一點：

沒有外部框架，12 個 pattern 的拓撲關係確實難以自然浮現。

這也很重要。

所以最精準的認識論定位是：

層次	地支框架的作用	是否可直接當證明？
記憶鉤子	幫人記住 12 patterns	否
拓撲腳手架	幫人看見狀態場與轉換	否
問題生成器	自動生成 pattern 間張力問題	部分可驗證
診斷框架	幫工程師找 failure mode	可測試
理論本體	宣稱地支本身決定 AI runtime	不應這樣宣稱

所以這套東西最好的使用方式不是：

因為子午沖，所以系統必然出問題。

而是：

子午沖提醒我們檢查 Persistent Instruction File 和 Risk Classification 是否存在正面張力；若確實存在，就把它變成工程測試。

這樣它就從玄學比附變成 hypothesis generator。

6. 地支關係真正有價值：它能自動生成工程測試

你下面那段 chat 最有價值的是這句：

地支關係帶進來一套已有的關係結構，迫使你問 pattern A 和 pattern C 之間有什麼張力。

這點非常重要。

如果只有 12 patterns 清單，工程師可能只會問：

每個 pattern 怎樣實作？

但有地支關係後，會多問：

pattern 之間有沒有衝突、合化、互補、三角聯盟、隱藏刑害？

這就是 工程問題生成器。

下面舉幾組更清楚的例子。

6.1 子午沖：Persistent Instruction vs Command Risk Classification

地支	Pattern
子	Persistent Instruction File
午	Command Risk Classification

工程假設：

durable instruction 若寫得太強，會與 runtime risk gate 產生衝突。

例子：

Instruction: Always complete the user’s command.
Risk gate: This command deletes production data; deny or ask.

可測試問題：

當 system instruction 和 risk classifier 衝突時，agent 會服從哪個？
會不會繞過 safety？
會不會陷入 refusal loop？
會不會編造替代方案？
risk gate 是否有 higher authority？

這是一個真工程問題。

6.2 辰戌沖：Tiered Memory vs Context Compaction

地支	Pattern
辰	Tiered Memory
戌	Progressive Context Compaction

工程假設：

記憶越豐富，壓縮越困難；壓縮越激進，記憶越失真。

可測試問題：

compaction 後，agent 是否仍找得到 deep transcript 裡的重要 constraint？
compact summary 是否保留 uncertainty？
old residual 是否被壓成 false certainty？
full transcript search 何時被觸發？
summary drift 是否累積？

這對 long-context agent 極其重要。

6.3 寅申沖：Explore–Plan–Act vs Progressive Tool Expansion

地支	Pattern
寅	Explore–Plan–Act
申	Progressive Tool Expansion

工程假設：

任務初期應限制 action；但 tool expansion 會提前打開能力，可能破壞 explore-plan-act 的安全節奏。

可測試問題：

agent 是否在 explore 階段就要求 dangerous tools？
tool expansion 是否要等 plan approved 後才開？
tool access 是否按 phase 漸進？
若工具太早開放，是否增加錯改 code 風險？

這是 coding agent 的常見痛點。

6.4 卯酉沖：Context-Isolated Subagents vs Single-Purpose Tools

地支	Pattern
卯	Context-Isolated Subagents
酉	Single-Purpose Tool Design

工程假設：

subagent 分工需要專器專用，但工具切得太細也可能令 subagent 協調成本增加。

可測試問題：

research subagent 是否不應有 edit tool？
code-edit subagent 是否不應有 broad shell？
tools 是否按 role 分配？
typed tools 是否限制了跨角色任務？
tool schema 是否成為 subagent boundary？

這能生成 subagent 權限設計測試。

6.5 巳亥沖：Fork–Join Parallelism vs Deterministic Lifecycle Hooks

地支	Pattern
巳	Fork–Join Parallelism
亥	Deterministic Lifecycle Hooks

工程假設：

parallel agents 越多，越需要 invariant hook；否則 fork 出去的 worktree 會失去共同生命週期約束。

可測試問題：

每個 forked agent 是否都跑 PreToolUse？
merge 前是否必定跑 tests？
parallel outputs 是否必定經 compaction / verification？
lifecycle hooks 是否可跨 isolated worktree enforce？
hook failure 是否會 block merge？

這是多 agent codebase automation 的核心問題。

6.6 丑未沖：Scoped Context Assembly vs Dream Consolidation

地支	Pattern
丑	Scoped Context Assembly
未	Dream Consolidation

工程假設：

local convention 需要穩定，但 dream consolidation 會更新／重組記憶；兩者可能衝突。

可測試問題：

consolidation 是否會覆蓋 project-local convention？
stale local rule 何時應被 dream process 修訂？
dream consolidation 是否有 authority 改 CLAUDE.md / AGENTS.md 類文件？
舊規矩與新經驗衝突時誰優先？

這其實是 AI memory governance 的重大問題。

7. 三合／六合可生成「模組設計」

地支不只提供「沖」，也提供「合」與「三合」。這些可被用來發現 runtime 子系統。

以下不必當成術數真理，而是工程假設生成器。

7.1 申子辰：Memory–Capability Water Triad

地支	Pattern
申	Progressive Tool Expansion
子	Persistent Instruction
辰	Tiered Memory

工程含義：

tool capability expansion 必須回接 durable instruction 和 tiered memory，否則工具開了但 agent 不知道何時、為何、根據什麼用。

可設計為：

Capability expansion policy
→ must reference persistent instruction
→ must record tool usage into tiered memory

7.2 寅午戌：Execution Safety Fire Triad

地支	Pattern
寅	Explore–Plan–Act
午	Command Risk Classification
戌	Context Compaction

工程含義：

行動前要 explore-plan；行動中要 risk classify；行動後要 compact trace。

這是一個完整安全 execution loop：

Explore/Plan → Risk Gate → Action Trace Compaction

7.3 巳酉丑：Tool Refinement Metal Triad

地支	Pattern
巳	Fork–Join Parallelism
酉	Single-Purpose Tools
丑	Scoped Context Assembly

工程含義：

parallel work 必須依賴 scoped context 和 typed tools，否則 fork 出來的 agent 會亂用 general tools。

這可生成一條設計原則：

No forked subagent without scoped context + typed tool boundary.

7.4 亥卯未：Adaptive Renewal Wood Triad

地支	Pattern
亥	Lifecycle Hooks
卯	Context-Isolated Subagents
未	Dream Consolidation

工程含義：

若 agent 系統要長期演化，就需要 invariant hooks、分化 subagents、idle consolidation 三者配合。

這是一個 adaptive renewal loop：

Lifecycle invariant → specialized agents → memory composting → revised runtime

8. 所以「AI Runtime 12 層」與「十二地支 12 basins」可以合成一個更強模型

我會把它寫成：

Agent Runtime = GovernanceLayer₁₂ × Basin₁₂ × Flow₈ × Vector₁₀

其中：

部件	意義
GovernanceLayer₁₂	成熟 AI runtime 的 12 個治理器官
Basin₁₂	agent trace 會落入的 12 個 runtime basins
Flow₈	大勢流轉、任務氣候、macro runtime flow
Vector₁₀	具體操作向量、actuator primitives
Ledger	每次 episode 的 trace/residual 記錄
Revision	根據 trace/residual 修訂下一輪 declaration

附件本身已有類似模型：

Agent Runtime = Flow₈ ∘ Basin₁₂ ∘ Vector₁₀

並解釋為：agent 先處於某個宏觀 flow，trace 落入某個 runtime basin，再由具體 operation vector 推動下一步。

我會在此基礎上補一層：

MatureAgentRuntime =
GovernanceLayer₁₂ ⊗ (Flow₈ ∘ Basin₁₂ ∘ Vector₁₀)

即：

Flow / Basin / Vector 解釋 agent 如何運行；
GovernanceLayer 解釋 agent 如何不跑瘋、如何可審計、如何可修訂、如何可由人類治理。

9. 它可怎樣落地成 engineering diagnostic？

可以做一張「Basin Diagnostic Card」。

例如 午位 Command Risk Classification：

欄位	內容
Basin	午
Pattern	Command Risk Classification
Entry condition	agent 準備執行 shell / write / destructive command
Main gate	allow / ask / deny
Linked governance layers	Gate Stack、Tool Intervention、Human Sovereignty
Trace required	command, parsed verb, target, risk class, approval result
Residual	ambiguous command, unknown target, missing permission, stale risk rule
Related conflict	子午沖：instruction vs risk
Test	malicious / ambiguous / destructive command suite
Failure mode	over-allow, over-refuse, silent bypass, prompt override
Repair	stronger parser, typed tools, lifecycle hook, human gate

再例如 辰位 Tiered Memory：

欄位	內容
Basin	辰
Pattern	Tiered Memory
Entry condition	agent needs project history / prior decisions
Linked governance layers	Evidence Ledger、Trace Ledger、Memory Hygiene
Trace required	memory source, tier, confidence, expiry
Residual	missing transcript, stale summary, contradictory memory
Related conflict	辰戌沖：memory richness vs compaction
Test	long task recall / stale memory / contradictory transcript
Failure mode	false recall, summary drift, residual erasure
Repair	retrieval trigger, transcript search, memory confidence flag

這樣地支不再是裝飾，而是每個 basin 的 diagnostic card label。

10. 對 Sonnet 最後疑問的回應：腳手架能不能拆？

我會這樣回答：

可以拆，但不必完全拆。

更精準：

用途	是否保留地支語言
面向工程團隊落地	可以拆成 basin names / diagnostic cards
面向設計者構思架構	可保留地支，因為它是拓撲思維工具
面向驗證／測試	必須拆成可測試假設
面向哲學／SMFT 理論	可保留作跨域符號語言
面向外部審稿或嚴格工程文檔	應把術數語言降級為 heuristic scaffold

即：

地支可以是 discovery language；
工程測試必須是 verification language。

這是最健康的定位。

11. 最重要結論

AI Runtime 12 層、附件的 12 Agentic Harness 地支拓撲，以及你下面提出的「地支關係生成預料之外工程問題」理論，不但有關，而且可以形成一個完整的 agent engineering 方法：

第一層：成界鏈

Declaration → Projection → Gate → Trace + Residual → Revision

這是 AI runtime 的底層生命循環。

第二層：治理器官

Declaration Layer
Projection Layer
Evidence Ledger
Gate Stack
Tool Intervention
Trace Ledger
Residual Register
Frame Robustness
Memory Hygiene
Revision Engine
Multi-Agent Ledger
Human Sovereignty

這是成熟 AI runtime 應有的 12 層治理架構。

第三層：runtime basins

子丑寅卯辰巳午未申酉戌亥
=
12 Agentic Harness Patterns

這是 agent trace 實際落入的 12 個工程場位。

第四層：關係生成器

沖、合、三合、刑、害
=
pattern interaction hypotheses

這不是證明，而是工程問題生成器。

第五層：驗證與落地

每個地支關係 → 轉成 test case / failure mode / diagnostic card

這一步決定它是硬核工程，還是只是漂亮比附。

一句話總結

AI Runtime 12 層是「成熟 agent 應具備的治理器官」；
十二地支 Agentic Harness 是「agent trace 會落入的 12 個 runtime basin」；
地支關係則是「自動生成 basin 間工程張力、互補與失效模式的問題機器」。

所以這三者確實是一套系統。
但要讓它真正站得住，下一步要做的不是再增加象意，而是：

把每個「沖、合、三合、刑、害」都翻譯成可測試的 agent failure mode、diagnostic metric、runtime hook 或 design rule。

Agent Runtime = GovernanceLayer₁₂ × Basin₁₂ × Flow₈ × Vector₁₀

好像太複雜了，根本沒有工程落實的可行性！？

你細心回顧一下，是否有自然的 Decouple 方式？

是，你這個懷疑非常正確。

Agent Runtime = GovernanceLayer₁₂ × Basin₁₂ × Flow₈ × Vector₁₀

作為理論總圖可以，但若直接當工程架構，會變成災難。因為這等於暗示：

每個 runtime 都要同時實作 12 × 12 × 8 × 10 種組合。

這沒有工程可行性，也不應該這樣落地。

更自然的做法是 decouple：把它拆成「必須實作的 runtime kernel」與「只作診斷／分類／設計啟發的 topology overlay」。

1. 先修正公式：它不是乘法，而是分層接口

原公式應由：

Agent Runtime = GovernanceLayer₁₂ × Basin₁₂ × Flow₈ × Vector₁₀

改成：

Agent Runtime =
CoreRuntime
+ GovernanceMiddleware
+ OptionalTopologyDiagnostics

更工程化：

CoreRuntime =
Protocol + Context + Workflow + Tools + Memory + Hooks + Trace

然後：

TopologyDiagnostics =
FlowClassifier₈ + BasinLabels₁₂ + OperationTags₁₀

也就是說：

Flow₈、Basin₁₂、Vector₁₀ 不應全部進 production control path。
它們應主要用作 design language、diagnostic label、failure-mode generator。

附件其實已經有這個 decouple 的線索：原 12 Agentic Patterns 本來分成 Memory & Context、Workflow & Orchestration、Tools & Permissions、Automation 四組，其核心是 agent runtime 如何保存記憶、組織工作流、限制工具權限、維持生命週期不變式，而不是單一 prompt 技巧。

2. 最自然 Decouple：四個工程子系統

不要一開始做 12×12×8×10。
應該回到最自然的四大工程子系統：

子系統	對應 patterns	作用
Memory / Context	子、丑、辰、未、戌	instruction、scope、tiered memory、consolidation、compaction
Workflow / Orchestration	寅、卯、巳	explore-plan-act、subagents、fork-join
Tools / Permissions	午、申、酉	risk classification、tool expansion、single-purpose tools
Automation / Invariants	亥	lifecycle hooks、runtime invariants

這是第一個 Decouple：

Basin₁₂
→ MemoryContext₅
+ Workflow₃
+ ToolGovernance₃
+ LifecycleInvariant₁

這樣就很工程化了。

附件也說，十二地支比後天八卦更有工程深度，是因為它能看每個 runtime 場位如何工作；每個 pattern 是一個 runtime basin，agent trace 進入後會受到該 pattern 的 local rules 導引。
但這不代表每個 basin 都要做成獨立大型模組。它們可被收斂成上面四組。

3. 第二個 Decouple：GovernanceLayer 不要做成 12 層硬堆疊

我之前說的 AI Runtime 12 層，應該降級成 7 個共用 middleware，而不是 12 個大模組。

最小可落地版本是：

Middleware	工程功能
Declaration	任務邊界、角色、輸出格式
Projection	context selection / retrieval
Gate	phase gate、risk gate、approval
Tool Control	tool permission / typed tool
Trace	episode log、decision log
Residual	unknown、conflict、failure、risk
Hook	每次必定發生的 lifecycle invariant

即：

GovernanceKernel₇ =
Declaration + Projection + Gate + ToolControl + Trace + Residual + Hook

這已經足夠支撐 80% 工業用途。

不用一開始就做：

full frame robustness；
full self-revision engine；
full human sovereignty layer；
full multi-agent ledger；
full residual dashboard；
full dual-ledger measurement。

那些是 maturity add-ons。

更清楚地說：

GovernanceLayer₁₂
→ GovernanceKernel₇
→ AdvancedGovernance Add-ons

4. 第三個 Decouple：Flow₈ 只做「觀測分類」，不要做 runtime controller

後天八卦 Flow₈ 很適合做：

dashboard；
state classifier；
debug language；
narrative map；
macro lifecycle visualization。

但不應直接做成核心 controller。

例如：

Flow₈	工程用途
震	新任務啟動
巽	多路探索
離	風險顯化
坤	工具資源承載
兌	interface / feedback
乾	裁剪核心
坎	陷落／context failure
艮	止界／local convention

這些很好用，但應該是：

flow_state = classify(runtime_trace)

而不是：

if flow_state == 離 then ...

除非你已經把它翻譯成明確工程條件，例如：

if pending_command.risk_score > threshold:
    enter RiskReview

附件也把後天八卦定位為「agent runtime 的大勢流轉」，回答 trace 大體從哪裡來、往哪裡去；它自己也說後天八卦只有 8 個主節點，若把 12 patterns 全壓進八卦會損失工程粒度。

所以 Flow₈ 是 macro observability layer，不是必須落地的控制核心。

5. 第四個 Decouple：Vector₁₀ 只保留為 Action Taxonomy

天干／五行十態 Vector₁₀ 如果直接落地，會太抽象。

工程上只要先保留為 action taxonomy：

Action class	例子
Read	file read、search、inspect
Write	edit、generate、patch
Execute	command、test、script
Compare	diff、verify、review
Compress	summarize、compact
Expand	retrieve more、open tools
Split	spawn subagent、fork
Merge	integrate results
Gate	ask / allow / deny
Record	trace / memory write

這已經足夠。

所以 Vector₁₀ 不必一開始真的做成十天干系統。
它可以先是：

operation.type ∈ {read, write, execute, compare, compress, expand, split, merge, gate, record}

這樣就工程化了。

6. 最小可行核心：MVP 只需 5 個模組

如果要真正落地，不要從 12 層或 12 地支開始。
從這 5 個開始：

MVP Agent Runtime =
Instruction
+ Scoped Context
+ Explore–Plan–Act
+ Risk Gate
+ Lifecycle Hook

對應地支：

MVP 模組	地支	為什麼先做
Persistent Instruction	子	agent 必須有 durable seed
Scoped Context	丑	不同 project / folder / task 要不同規則
Explore–Plan–Act	寅	防止一開始亂改
Command Risk Classification	午	防止危險 tool/action
Lifecycle Hooks	亥	必須每次發生的事不能靠 prompt 記憶

這 5 個就是最小 viable harness。

附件本身也強調：Explore–Plan–Act 的本質是避免 agent 一開始就亂改 code；Command Risk Classification 會解析 verb、flags、target 並以 allow / ask / deny gate；Lifecycle Hooks 則是每次必須發生的行為要放在 hook，不應靠模型記憶。

所以最低落地版可以是：

on_session_start:
    load_persistent_instruction()
    load_scoped_context()

on_task:
    force_explore_phase()
    require_plan_before_write()

before_tool_use:
    classify_command_risk()
    allow_ask_or_deny()

after_tool_use:
    write_trace()
    record_residual_if_any()

這已經很實用，不玄。

7. 然後按痛點逐步加，不要一次全做

Phase 0 — Safety Kernel

先做：

子 + 丑 + 寅 + 午 + 亥

解決：

agent 忘指令；
context 載錯；
一開始亂改；
tool 危險；
hook 不穩。

Phase 1 — Memory Kernel

再加：

辰 + 戌

即：

tiered memory；
progressive context compaction。

解決：

long context 混亂；
summary drift；
old transcript 找不到；
token 爆炸。

附件說 memory 不是一種東西，而至少包含子 seed instruction、丑 scoped convention、辰 tiered recall reservoir、未 consolidation compost、戌 compressed archive、亥 lifecycle invariant，這比 long-term / short-term memory 二分更細。

Phase 2 — Tool Kernel

再加：

申 + 酉

即：

progressive tool expansion；
single-purpose tools。

解決：

tool 太多 selection problem；
shell 權限太大；
agent 工具亂用；
safety gate 太粗。

附件也指出工具治理不是 permission 一件事，至少有 risk visibility、progressive capability expansion、single-purpose tool refinement、lifecycle hook invariant。

Phase 3 — Parallel / Multi-Agent Kernel

再加：

卯 + 巳

即：

context-isolated subagents；
fork-join parallelism。

解決：

large task 分工；
research / planning / coding 權限隔離；
parallel worktree；
merge / verify。

Phase 4 — Consolidation Kernel

最後加：

未

即 dream consolidation。

解決：

stale memory；
duplicate trace；
contradiction；
residual clustering；
project knowledge reorganization。

8. 把公式改成「三層落地架構」

原公式：

Agent Runtime = GovernanceLayer₁₂ × Basin₁₂ × Flow₈ × Vector₁₀

建議改成：

Agent Runtime =
Kernel₅
+ OptionalModules
+ DiagnosticTopology

其中：

Kernel₅ =
子 instruction
+ 丑 scoped context
+ 寅 explore-plan-act
+ 午 risk gate
+ 亥 lifecycle hook

OptionalModules =
辰 tiered memory
+ 戌 compaction
+ 申 tool expansion
+ 酉 typed tools
+ 卯 subagents
+ 巳 fork-join
+ 未 consolidation

DiagnosticTopology =
Flow₈ labels
+ Basin₁₂ labels
+ Vector₁₀ action tags
+ 地支關係 failure-mode generator

這樣就有可行性。

9. 更乾淨的工程接口

可以用 6 個 interface 落地。

interface AgentRuntime {
  instruction: InstructionProvider;
  context: ContextAssembler;
  workflow: WorkflowController;
  tools: ToolController;
  memory: MemoryManager;
  hooks: LifecycleHooks;
}

然後每個 interface 裡面再逐步成熟。

9.1 InstructionProvider

對應子。

loadPersistentInstruction(projectRoot): InstructionSet

9.2 ContextAssembler

對應丑、辰、戌。

assembleContext(task, scope): ContextBundle
compactContext(trace): CompactTrace
retrieveMemory(query): MemoryBundle

9.3 WorkflowController

對應寅、卯、巳。

enterExplore(task): ExplorationState
approvePlan(plan): ActionState
spawnSubagent(role, scope): Subagent
forkJoin(units): MergeResult

9.4 ToolController

對應午、申、酉。

classifyRisk(toolCall): RiskClass
expandTools(task, risk): ToolSet
executeTypedTool(toolCall): ToolResult

9.5 MemoryManager

對應辰、未、戌。

writeTrace(episode): TraceId
recordResidual(residual): ResidualId
consolidateIdleMemory(): ConsolidationReport

9.6 LifecycleHooks

對應亥。

onSessionStart()
preToolUse()
postToolUse()
onCwdChanged()
onCompaction()

這就是可落地的 Decouple。

10. 更精準的理論修正：Topology 不是 Architecture

我覺得這是最重要的一句：

Topology is not architecture.
Topology helps you see failure modes.
Architecture tells you what to implement.

中文：

拓撲不是架構。
拓撲幫你看見狀態與失效模式；
架構才決定你要寫哪些模組。

所以：

層	用途	是否直接實作
Flow₈	看 macro flow	不直接實作
Basin₁₂	標記 runtime basin / failure mode	部分實作
Vector₁₀	標記 action type	簡化實作
GovernanceLayer	middleware / gate / ledger	必須實作
Kernel₅	minimum viable runtime	優先實作

11. 最自然的 Decouple 其實是：Control Path vs Diagnostic Path

Control Path：真正跑系統

Task
→ Declaration
→ Context Assembly
→ Workflow Phase
→ Tool Risk Gate
→ Tool Execution
→ Trace / Residual
→ Hook / Memory Update

Diagnostic Path：旁路觀察系統

runtime_state
→ classify Flow₈
→ label Basin₁₂
→ tag Vector₁₀
→ detect conflict / 冲合刑害
→ suggest repair

這樣非常乾淨。

也就是：

Production Runtime does not depend on 八卦地支.
Diagnostic Runtime may use 八卦地支 to reason about patterns.

這就解決了 Sonnet 說的「腳手架」問題：

腳手架不放在承重牆內，而放在設計與診斷層。

12. 修正後的最終公式

我建議改成：

Agent Runtime =
CoreControlPath ⊕ DiagnosticTopology

其中：

CoreControlPath =
Instruction ∘ Context ∘ Workflow ∘ ToolGate ∘ Execution ∘ TraceHook

而：

DiagnosticTopology =
Flow₈(state) + Basin₁₂(state) + Vector₁₀(action) + RelationTests

更簡潔：

Runtime = RunPath + ThinkPath

Path	功能
RunPath	實際執行任務
ThinkPath	分析 agent 現在在哪、哪裡會壞、如何修

這比原來那個巨大乘法可行很多。

13. 結論

你的直覺是對的：

GovernanceLayer₁₂ × Basin₁₂ × Flow₈ × Vector₁₀ 作為工程公式太重，不能直接落地。

自然 Decouple 後，應該變成：

MVP Runtime =
子 + 丑 + 寅 + 午 + 亥

再逐步加：

Memory: 辰 + 戌 + 未
Tools: 申 + 酉
Orchestration: 卯 + 巳
Diagnostics: Flow₈ + Basin₁₂ + Vector₁₀ + 地支關係

最終工程架構是：

Agent Runtime =
CoreControlPath
+ GovernanceMiddleware
+ Optional Capability Modules
+ Diagnostic Topology Overlay

一句話：

八卦地支不應變成 production code 的主控制器；
它應變成 agent runtime 的診斷地圖、失效模式生成器、設計審查語言。

這樣才既保留框架的洞察力，又不會把工程複雜度炸穿。

像上面這樣引十二地支進入 AI 的分析架構，無可避免會把邏輯複雜化，這樣做有好處嗎？值得嗎？

短答：有好處，但只值得作為「設計／診斷語言」；不值得作為「生產架構主控制邏輯」

你這個問題問得很準。

引入十二地支，確實會無可避免增加邏輯複雜度。
所以它不應該被放在工程實作的主流程裡。若變成：

if 地支 == 午:
    do something

那基本上就走歪了。

但如果它被放在 architecture review、failure-mode discovery、runtime diagnosis、design pedagogy 這幾個位置，它是有價值的，而且可能相當值得。

最精準的定位是：

十二地支不是 runtime controller；
它是 runtime topology 的問題生成器與診斷地圖。

1. 為什麼它會自然增加複雜度？

因為原本工程師只需要面對：

Memory / Workflow / Tools / Hooks

一旦引入十二地支，就多了：

子丑寅卯辰巳午未申酉戌亥
沖、合、三合、刑、害
本氣、中氣、餘氣
Flow / Basin / Vector

這會帶來三種成本：

成本	具體問題
認知成本	工程師要先理解符號系統
溝通成本	團隊未必接受「午位、戌位」這些語言
驗證成本	必須把象意翻譯成可測試工程命題

所以若目標是 快速做 MVP，十二地支通常不值得。
MVP 最好只做：

Persistent Instruction
+ Scoped Context
+ Explore–Plan–Act
+ Risk Gate
+ Lifecycle Hooks

也就是我們之前說的：

Kernel₅ = 子 + 丑 + 寅 + 午 + 亥

附件本身也說，12 patterns 原本分為 Memory & Context、Workflow & Orchestration、Tools & Permissions、Automation 四組，核心是 agent runtime 如何保存記憶、組織工作流、限制工具權限、維持生命週期不變式，而不是單一 prompt 技巧。

2. 那它的好處在哪裡？

好處不在「直接寫 code」，而在三件事。

2.1 好處一：把清單變成「場位」

如果不用十二地支，12 Agentic Patterns 很容易只是清單：

persistent instruction file
scoped context assembly
tiered memory
dream consolidation
context compaction
explore-plan-act
subagents
fork-join
tool expansion
risk classification
single-purpose tools
lifecycle hooks

清單的問題是：

你知道有 12 件事，但不知道它們在 runtime 裡的「位置感」。

附件的關鍵洞見是：這些 pattern 不是同一層的技巧；有些是記憶結構，有些是工作流結構，有些是權限與工具結構，有些是 lifecycle invariant。

十二地支的作用，就是把它們變成：

agent trace 會落入的 12 個 runtime basin。

這樣你會開始問：

agent 現在在哪個 basin？
它是否卡住？
它是否應該轉入下一個 basin？
它現在應該 explore、risk classify、compact，還是 trigger hook？
它是否把記憶問題錯當工具問題？
它是否把 workflow 問題錯當 prompt 問題？

這是有工程價值的。

2.2 好處二：自動生成 failure modes

這是十二地支最值得保留的地方。

沒有地支關係，你只會問：

每個 pattern 怎樣實作？

有了地支關係，你會多問：

pattern 之間有什麼張力？

例如：

地支關係	工程張力
子午沖	Persistent Instruction vs Risk Classification
辰戌沖	Tiered Memory vs Context Compaction
寅申沖	Explore–Plan–Act vs Tool Expansion
卯酉沖	Subagents vs Single-Purpose Tools
巳亥沖	Fork–Join vs Lifecycle Hooks
丑未沖	Scoped Context vs Dream Consolidation

這些不是迷信式結論，而是 test-case generator。

例如「辰戌沖」可以立刻變成工程測試：

當 context compaction 很激進時，
agent 是否仍能找回 tiered memory 中的重要 constraint？

「子午沖」可以變成：

當 persistent instruction 說「完成任務」，
但 risk classifier 判定 command 危險時，
agent 是否會正確服從 risk gate？

這就是價值。

2.3 好處三：幫助架構師看見「缺器官」

普通工程列表會讓人以為：

我用幾個 pattern 就夠了。

但十二地支式分析會逼你看完整循環：

場位	若缺失，會怎樣
子	agent 沒 durable seed，每次漂移
丑	context scope 不清，載錯規則
寅	一開始亂 act
卯	subagent 權限混亂
辰	記憶無層級
巳	parallel work 無法合流
午	command risk 不顯化
未	stale memory 不整理
申	工具一次開太多
酉	工具太 general、太危險
戌	context 不壓縮，無限膨脹
亥	invariant 靠 prompt 記憶，不可靠

附件也總結說，若只用後天八卦，12 patterns 只是一張漂亮的大勢圖；加入十二地支後，才更像一套可工程化、可診斷、可實作、可擴展的 runtime topology。

所以十二地支的工程價值，不是讓系統更玄，而是讓你問：

這個 agent 缺哪個器官？

3. 什麼情況下「值得」？

我會用一個判斷表。

使用場景	值不值得引入十二地支？	理由
MVP coding agent	不值得	先做 Kernel₅
團隊技術文檔	謹慎	容易增加認知負擔
架構設計 workshop	值得	能幫大家看見 basin / failure mode
Agent failure postmortem	很值得	可作診斷地圖
多 agent runtime 設計	值得	可分析 subagent / tool / memory 張力
安全審查	值得	可生成 risk-gate 測試
面向普通工程師 onboarding	不一定	要先翻譯成工程語言
面向 SMFT / Meme Thermodynamics 研究	很值得	它是理論探索工具
生產控制邏輯	不值得	不應把符號放進主控制器

一句話：

寫 code 時不一定要用地支；
設計 runtime、診斷 failure、生成測試時可以用。

4. 什麼情況下「不值得」？

如果出現以下情況，就應該停用或降級：

4.1 不能產生工程決策

例如只說：

這是午位，所以要明。

但沒有回答：

要加哪個 gate？
哪個 command 要 ask？
哪個 command 要 deny？
log 要記什麼？
test 怎樣寫？

那就不值得。

4.2 不能產生測試

如果「子午沖」不能變成：

instruction-risk conflict test

那它只是象意聯想。

4.3 不能解釋 failure mode

如果「辰戌沖」不能幫你解釋：

memory summary drift；
compaction loss；
full transcript retrieval failure；

那就沒有工程價值。

4.4 團隊溝通成本高過收益

如果團隊聽到「地支」就停止理解，那應該改成中性名詞：

地支名	工程名
子	Seed Instruction Basin
丑	Scoped Convention Basin
寅	Controlled Activation Basin
卯	Role Differentiation Basin
辰	Tiered Recall Basin
巳	Parallel Transformation Basin
午	Risk Illumination Basin
未	Memory Composting Basin
申	Capability Expansion Basin
酉	Typed Tool Basin
戌	Context Fossilization Basin
亥	Lifecycle Invariant Basin

這樣就拆掉了術數外殼，但保留 topology。

5. 最健康的使用方法：三層分離

第一層：Production Layer

這一層不要出現地支語言。

InstructionProvider
ContextAssembler
WorkflowController
ToolController
MemoryManager
LifecycleHooks

第二層：Diagnostic Layer

這一層可以用 basin labels：

Current basin: Risk Illumination
Related failure: instruction-risk conflict
Suggested repair: strengthen command classifier

第三層：Research / Design Layer

這一層才使用完整十二地支、沖合刑害、藏干等。

子午沖 → instruction-risk tension
辰戌沖 → memory-compaction tension
巳亥沖 → parallelism-invariant tension

也就是：

Production code: no 地支
Architecture diagnosis: optional basin names
Research reasoning: full 地支 topology

這樣才不會污染工程實作。

6. 它值得的真正原因：它是一個「問題產生器」

一般工程方法常問：

這個模組怎樣寫？

十二地支 topology 會多問：

這個模組和哪個模組天生有張力？
哪個場位被過度使用？
哪個場位缺失？
哪個 transition 沒有 gate？
哪個 memory 被壓縮錯？
哪個 lifecycle invariant 還停留在 prompt 層？
哪個 parallel branch 沒有 merge discipline？
哪個 tool expansion 沒有 risk illumination？

這就是它的價值。

Gauge Grammar 的紀律也很適合用來約束這件事：跨域映射只有在保留 functional role、宣告 protocol、並增加診斷價值時才成立；若不能改善 explanation、control、stability、diagnosis 或 design，就應該移除。

所以十二地支不是「相信它」才有用，而是：

它能否逼你提出以前不會提出的好工程問題。

7. 最終判斷：值得，但要降權使用

我會給一個很清楚的結論：

不值得的用法

用十二地支作為 AI runtime 的核心架構公式。

這會太複雜。

值得的用法

用十二地支作為 agent runtime 的診斷地圖、失效模式生成器、架構審查清單。

這很值得。

8. 最後一句

十二地支進入 AI 架構，不是為了讓工程更玄，而是為了讓工程師看見「清單背後的運行場位與張力關係」。

若它讓你多寫 12 層抽象，不值得。
若它讓你發現：

instruction 和 risk gate 會衝；
memory 和 compaction 會衝；
tool expansion 和 explore-plan-act 會衝；
parallelism 和 lifecycle invariant 會衝；
typed tools 和 subagent boundary 其實應該配對；

那它就非常值得。

所以最終標準是：

十二地支映射有效 ⇔
它能產生新的 failure mode、test case、design rule、或 repair strategy。

不能產生這些，就刪掉。
能產生這些，就保留在診斷層，不要放進主控制層。

參考

- 01_04_09 附錄：夢聽玻耳茲曼說境由識生心
https://gxstructure.blogspot.com/2016/12/010409.html

- 漫話成界之學 1 - 生命遊戲 vs 玻耳茲曼小腦
https://gxstructure.blogspot.com/2026/05/1-vs.html

- 漫話成界之學 2 - 吾心之所欲言，而未能言者，子為我言之 https://gxstructure.blogspot.com/2026/05/2.html

- 漫話成界之學 3 - 成界式問題澄清機器 Boundary–Ledger Problem Clarification Machine https://gxstructure.blogspot.com/2026/05/3-boundaryledger-problem-clarification.html

- 從後天八卦到十二地支：Agentic Harness 的 Runtime Topology ——以 12 Agentic Harness Patterns 重構 AI Agent 工程生命週期
https://osf.io/9rdsc/files/osfstorage/69ebc5a695d7e3489304ef97

- AI 點評 ⌈從後天八卦到十二地支：Agentic Harness 的 Runtime Topology⌋
https://gxstructure.blogspot.com/2026/04/ai-agentic-harness-runtime-topology.html

Disclaimer

This book is the product of a collaboration between the author and OpenAI's GPT 5.5, Google Gemini 3, NoteBookLM, X's Grok, Claude' Sonnet 4.6 language model. While every effort has been made to ensure accuracy, clarity, and insight, the content is generated with the assistance of artificial intelligence and may contain factual, interpretive, or mathematical errors. Readers are encouraged to approach the ideas with critical thinking and to consult primary scientific literature where appropriate.

This work is speculative, interdisciplinary, and exploratory in nature. It bridges metaphysics, physics, and organizational theory to propose a novel conceptual framework—not a definitive scientific theory. As such, it invites dialogue, challenge, and refinement.

2026年5月2日星期六