# 分層因果完成論：宏觀—中觀—微觀的工作、錯誤與驗證配置 ## Hierarchical Causal Completion Theory: Allocating Work, Failure, and Verification Across Macro, Meso, and Micro Scales **系列：** AI 原生全域完成方法論 **篇次：** 02 / 03 **作者：** Neo.K with Aletheia **機構：** EveMissLab／一言諾科技有限公司 **版本：** v0.1 **日期：** 2026-09-11 **文件類型：** 方法論論文／Agent Completion & Verification Theory --- ## 摘要 當代 AI Agent 在軟體工程與複雜任務執行中，逐漸出現一種新的低效率：**所有錯誤被當成同等重要，所有不確定性被當成潛在 blocker，所有局部異常都可能觸發全域驗證。** 這種工作方式表面上極度嚴謹，實際上卻忽略複雜系統最基本的因果事實： > **不同節點對整體結果的影響並不相同。** 一個 API contract 錯誤、一個資料模型錯誤與一個 UI padding 偏差，雖然都可以稱為「問題」，但它們對系統的因果影響半徑、跨模組傳播能力、可逆性與完成阻塞程度完全不同。 本文提出「分層因果完成論」（Hierarchical Causal Completion Theory, HCCT），將既有 FDCS（Fractal Dynamic Causal Systems）中的宏觀—中觀—微觀尺度、跨層因果傳播與因果權重思想，轉化為 AI Agent 的工作執行、錯誤分類、驗證配置與完成判定方法。 FDCS 原本已反對將宏觀、中觀、微觀變量扁平化在單一因果圖中，要求 Agent 先判定因果變量位於什麼尺度、向上影響宏觀、向下約束微觀，或只在同層橫向互動。 本文將此原則轉化為： $$ \boxed{ \text{Micro Failure} \not\Rightarrow \text{Macro Failure} } $$ 並進一步提出： $$ \boxed{ \text{Validation Effort} \propto \text{Causal Impact} \times \text{Actual Risk} } $$ 因此，驗證資源不應平均分配，更不應由「問題是否存在」決定，而應由： - 所在尺度； - 因果中心性； - 影響半徑； - 依賴數量； - 可逆性； - 風險； - 不確定性； - 失敗外溢； 共同決定。 本文同時建立「因果 blocker 判準」、「錯誤升格閘門」、「完成容差區」、「全域不變量」、「局部技術債合法化」與「跨尺度重新開啟條件」，使 Agent 可以在保留嚴謹性的同時，不再因低影響微觀問題無限阻塞整體完成。 --- # 1. 問題：現在的 Agent 把所有問題都放在同一層 一般 Agent 工作流很容易形成： ```text 發現問題 ↓ 問題存在 ↓ 需要修正 ↓ 需要重新驗證 ↓ 可能影響其他東西 ↓ 再做完整檢查 ``` 這個流程隱含了一個錯誤假設： $$ \forall e_i,\quad I(e_i)\approx I(e_j). $$ 也就是所有 error 的重要度近似相等。 但真實系統明顯不是如此。 例如： ```text A. Authentication contract 錯誤 B. Database schema 錯誤 C. API return field 名稱錯誤 D. 一個 log 訊息不精確 E. 一個非關鍵 UI margin 差 2px ``` 五者都「有問題」。 但不能推出： $$ B_A=B_B=B_C=B_D=B_E. $$ 其中 $B$ 表示 blocker strength。 如果 Agent 對全部問題使用相同驗證與阻塞政策，它會產生： $$ C_{\text{verification}} \uparrow $$ 同時： $$ \frac{dC_{\text{completion}}}{dt} \downarrow. $$ --- # 2. FDCS 的基本啟發：因果不是扁平圖 FDCS-CausalOps 已指出，一般 Agent 分析複雜系統時常出現： 1. 扁平化錯誤； 2. 靜態化錯誤； 3. 過度預測錯誤。 其中第一種即把宏觀、中觀、微觀變量放在同一層處理。 FDCS 建立： ```text M = Macro E = Meso I = Micro ``` 並允許繼續遞歸。 因此一個節點不是只有： $$ v_i. $$ 它還應具有尺度： $$ L(v_i) \in \{M,E,I\}. $$ 甚至： $$ L(v_i) = (M,I,E) $$ 可表示嵌套尺度。 這個思想套到工程中非常直接。 --- # 3. 軟體工程的宏觀、中觀、微觀 ## 3.1 宏觀層 Macro 宏觀層決定系統「是什麼」。 例如： - 產品目的； - 技術域； - 核心架構； - 資料所有權； - 安全邊界； - 主要 Runtime； - deployment topology； - state model； - 核心 invariants； - 對外 contract。 形式上： $$ M = \{ G, D, A, S, B, I \} $$ 其中： - $G$：Goal； - $D$：Technology Domain； - $A$：Architecture； - $S$：State model； - $B$：Major boundaries； - $I$：Global invariants。 宏觀錯誤通常具有： $$ R_{\text{propagation}}\gg0. $$ --- ## 3.2 中觀層 Meso 中觀層描述系統如何被組織成可工作的子結構。 例如： - service； - module； - package； - subsystem； - API interface； - database table family； - workflow； - integration contract； - shared library； - deployment component。 定義： $$ E = \{ m_1,m_2,\ldots,m_k \}. $$ 中觀層最重要的是： $$ \text{Contract} + \text{Dependency} + \text{Integration}. $$ 中觀錯誤可能污染一群節點，但不必然推翻整個產品。 --- ## 3.3 微觀層 Micro 微觀層包括： - 函數； - method； - expression； - local state； - UI element； - error text； - formatting； - local optimization； - isolated edge case； - test fixture； - log； - internal naming。 其集合為： $$ I = \{ i_1,i_2,\ldots,i_n \}. $$ 大部分微觀錯誤應具有： $$ R_{\text{propagation}}\approx0. $$ 但注意： > **微觀不等於不重要。** 例如一個一行的 cryptographic check、pointer arithmetic、financial rounding rule 或 permission comparison，表面上很小，卻可能具有巨大因果影響。 因此尺度只是第一個維度。 --- # 4. 尺度不等於重要度 本文強調： $$ \boxed{ \text{Scale} \neq \text{Impact} } $$ 一個 macro decision 通常具有較大影響，但不保證所有 macro decision 都 critical。 一個 micro line 通常局部，但也可能控制整個系統。 因此對每個問題 $e_i$，需要建立影響向量： $$ \mathbf I(e_i) = ( S_i, C_i, R_i, D_i, V_i, U_i ) $$ 其中： - $S_i$：Scale； - $C_i$：Causal centrality； - $R_i$：Propagation radius； - $D_i$：Dependency reach； - $V_i$：Reversibility； - $U_i$：Uncertainty。 --- # 5. 因果影響半徑 定義錯誤 $e$ 的因果影響集合： $$ \Gamma(e) = \{ v_j \mid e\leadsto v_j \}. $$ 其影響半徑可以近似寫為： $$ R_C(e) = |\Gamma(e)|. $$ 若： $$ R_C(e)\approx1, $$ 則錯誤高度局部。 若： $$ R_C(e)\gg1, $$ 則可能是中觀或宏觀問題。 例如： ```text 拼字錯誤 → 一個畫面 ``` 通常： $$ R_C\approx1. $$ 而： ```text shared authentication middleware defect → every protected endpoint ``` 則： $$ R_C\gg1. $$ 因此，Agent 發現一個問題後的第一個問題不應是： > 「要不要修？」 而應是： > **「它能影響什麼？」** --- # 6. Dependency Cone 對節點 $v_i$ 定義 downstream dependency cone： $$ DC^+(v_i) = \{ v_j \mid v_i\rightsquigarrow v_j \}. $$ 以及 upstream cone： $$ DC^-(v_i) = \{ v_j \mid v_j\rightsquigarrow v_i \}. $$ 這與先前 Surgical Replacement 的 minimum dependency cone 思路相容。 錯誤修復不應先展開整個 repository。 應先計算： $$ DC(e). $$ 如果： $$ |DC(e)|\ll|V|, $$ 驗證應集中於： $$ DC(e) + \partial DC(e), $$ 而不是： $$ V_{\text{whole}}. $$ 這得到本文第一個工程原則： $$ \boxed{ \text{Validate the causal cone, not automatically the entire universe.} } $$ --- # 7. 跨層因果衰減 FDCS 原本提出跨尺度影響不是固定，而會受到層級距離、時間與語境調節。 其工程形式可簡化為： $$ W_{ij} = W_0 \lambda^d f(t) g(x), $$ 其中 $d$ 是層級距離。FDCS 原方法即使用跨層因果衰減來避免從微觀現象直接過度推論宏觀結果。 套用軟體工程： $$ \text{micro} \rightarrow \text{meso} \rightarrow \text{macro} $$ 每跨一層都應重新證明： $$ W_{\text{up}}>\theta. $$ 因此： $$ \boxed{ \text{Local defect} \not\Rightarrow \text{Subsystem defect} } $$ 以及： $$ \boxed{ \text{Subsystem defect} \not\Rightarrow \text{Architecture defect}. } $$ --- # 8. AI 最常犯的錯誤：無證據升格 假設 Agent 發現： ```text one malformed edge input ``` 它可能產生： ```text edge input failure → validation concern → reliability concern → security concern → architecture concern → global blocker ``` 但這個鏈條只有在每一條箭頭都有證據時才成立。 形式上： $$ e_0 \rightarrow e_1 \rightarrow e_2 \rightarrow e_3 $$ 需要： $$ P(e_{k+1}\mid e_k,E) \geq\theta_k. $$ 不能因為： $$ P>0 $$ 就當成： $$ P\approx1. $$ 本文將沒有充分因果證據的問題升格稱為： # Causal Escalation Error 即： $$ \boxed{ \text{Possibility} \Rightarrow \text{Blocker} } $$ 的錯誤。 --- # 9. 錯誤升格閘門 一個 micro issue 只有符合至少一項條件，才允許升格至 meso 或 macro： 1. 破壞共享 contract； 2. 影響多個 downstream dependency； 3. 違反 global invariant； 4. 造成不可逆資料破壞； 5. 擴散到權限、安全或財務邊界； 6. 造成主要 user journey 失敗； 7. 使 build／runtime 無法啟動； 8. 表明相同根因存在於多個模組； 9. 使核心 state 不一致； 10. 其 failure probability × consequence 超過指定閾值。 定義升格函數： $$ E(e) = \mathbf 1 [ C(e)\lor D(e)\lor I(e)\lor R(e) ]. $$ 若： $$ E(e)=0, $$ 則錯誤保持原尺度。 --- # 10. Blocker 不是「存在問題」 本文將 blocker 定義為： $$ B(e)=1 $$ 當且僅當 $e$ 阻止： $$ G_{\text{required}} $$ 中的必要目標達成。 因此： $$ \boxed{ \text{Issue Exists} \not\Rightarrow \text{Blocker} } $$ 這個區分極重要。 Agent reviewer 可以發現： - improvement； - warning； - edge case； - cleanup； - future optimization； - possible refactor； 但它們不應自動進入： $$ \mathcal O_{\text{blocking}}. $$ --- # 11. Blocker Qualification 令： $$ B_Q(e) = w_1C + w_2D + w_3R + w_4S + w_5U - w_6V. $$ 其中： - $C$：causal centrality； - $D$：dependency reach； - $R$：risk； - $S$：severity； - $U$：uncertainty multiplier； - $V$：reversibility。 當： $$ B_Q(e)\geq\theta_B $$ 才可標記： ```text BLOCKING ``` 否則應是： ```text LOCAL_FIX NON_BLOCKING DEFERRED OPTIONAL OBSERVE ``` --- # 12. 全域不變量比局部完美更重要 系統應先建立一組： $$ \mathcal I_G = \{ I_1,\ldots,I_n \}. $$ 例如： ```text 資料不遺失 身份不可錯配 事件追加具原子性 核心 API contract 穩定 產品主流程可完成 權限不能越界 ``` 如果一個微觀問題： $$ e_i $$ 不破壞： $$ \mathcal I_G, $$ 且不阻塞必要目標，則它可以存在於： $$ \text{Completed System} $$ 中。 這不是降低品質。 而是承認： $$ \boxed{ \text{Completion} \neq \text{Zero Imperfection}. } $$ --- # 13. 全域完成允許局部技術債 令未解問題集合： $$ E_{\text{open}} = E_{\text{critical}} \cup E_{\text{noncritical}}. $$ 若： $$ E_{\text{critical}}=\varnothing $$ 且： $$ \forall e\in E_{\text{noncritical}}, \quad R_C(e)<\theta_R, $$ 則可以： $$ GC=1. $$ 換句話說： $$ \boxed{ E_{\text{open}}\neq\varnothing \not\Rightarrow GC=0. } $$ 只要剩餘項目： - 已知； - 已分類； - 非關鍵； - 不破壞核心 contract； - 不構成立即責任； 即可合法進入 backlog。 --- # 14. 完成容差區 本文定義： # Completion Tolerance Zone $$ \mathcal T_C $$ 包含： - cosmetic issue； - local optimization； - optional refactor； - low-impact edge case； - noncritical warning； - future feature； - redundant documentation improvement； - known but bounded technical debt。 若： $$ e_i\in\mathcal T_C, $$ 則： $$ B(e_i)=0. $$ 除非新證據使其跨越： $$ \theta_B. $$ --- # 15. 驗證不是平均配置資源 對問題 $e_i$，驗證資源： $$ V_i $$ 應為： $$ \boxed{ V_i = f( C_i, R_i, D_i, U_i, Ir_i ) } $$ 其中 $Ir_i$ 是 irreversibility。 可簡化為： $$ V_i \propto I_G(e_i) \times \operatorname{Risk}(e_i). $$ 因此： ### 高因果權重 - schema； - permissions； - architecture； - persistent state； - public API； 需要強驗證。 ### 中因果權重 - module contract； - integration； - shared utility； - data transformation； 需要結構驗證。 ### 低因果權重 - local helper； - cosmetic； - internal naming； - isolated rendering； 可以局部測試、抽樣或直接修復。 --- # 16. 宏觀驗證 Macro validation 主要驗： $$ \mathcal I_G. $$ 典型項目： - 產品主目的是否成立； - 技術域是否仍合適； - 核心 state 是否一致； - 安全／權限邊界是否成立； - 核心 architectural contract 是否成立； - major end-to-end path 是否可完成。 Macro validation 不應浪費大量時間檢查： ```text 每個 variable name 每個局部 format 每個非關鍵 edge case ``` --- # 17. 中觀驗證 Meso validation 關注： $$ \text{Contract} + \text{Boundary} + \text{Integration}. $$ 例如： ```text API ↔ Service Service ↔ Database Frontend ↔ Backend Module A ↔ Module B Worker ↔ Queue ``` 最重要的是： $$ V(A,B), $$ 而不是只證明： $$ V(A)=1,\quad V(B)=1. $$ 這與 MACR v0.6 的 cross-file pair topology 完全一致：真正需要證明的不是 A 與 B 各自正確，而是： $$ V(A,B)=1. $$ --- # 18. 微觀驗證 Micro validation 主要使用： - unit test； - local assertion； - targeted static check； - small witness； - local reproduction； - type check； - isolated runtime observation。 目標不是： $$ \text{Proof of Universe}. $$ 而是： $$ \operatorname{Resolve}(e_i). $$ 一旦： $$ \text{LocalTest}=\text{Pass} $$ 且： $$ \text{AdjacentInvariant}=\text{Pass}, $$ 則應停止。 --- # 19. 驗證停止條件 驗證活動本身也需要 stop condition。 定義第 $k$ 輪驗證的新資訊： $$ \Delta E_k. $$ 若： $$ \Delta E_k\rightarrow0 $$ 且： $$ \mathcal O_{\text{critical}}=\varnothing, $$ 則： $$ \boxed{ \text{StopVerification}. } $$ 否則就會形成： $$ V_1 \rightarrow V_2 \rightarrow V_3 \rightarrow \cdots $$ 但： $$ \operatorname{InformationGain}(V_n)\rightarrow0. $$ 這就是「驗證癖」的形式來源之一。 --- # 20. Reviewer 無權創造 Scope 令原始任務範圍： $$ \Omega_0. $$ Reviewer 發現問題： $$ e. $$ 只有： $$ e\in\operatorname{Closure}(\Omega_0) $$ 才可以成為原任務義務。 如果： $$ e\notin\operatorname{Closure}(\Omega_0), $$ 它只能成為： ```text future concern recommendation out-of-scope new task ``` 不能自行變成： ```text BLOCKER ``` 因此： $$ \boxed{ \text{Reviewer does not own the scope.} } $$ Scope authority 屬於： - 原始契約； - 使用者； - 授權產品規格； - 明確政策。 --- # 21. 假想 edge case 不是 blocker 假設 reviewer 想到： $$ h_i. $$ 如果它只滿足： $$ P(h_i)>0, $$ 但沒有： - evidence； - plausible path； - relevant user scenario； - required invariant； - material consequence； 則不能升格。 需要： $$ P(h_i) \times \text{Impact}(h_i) \geq \theta. $$ 否則： $$ h_i\in\text{Hypothetical}. $$ --- # 22. 因果證據階梯 Agent 可以使用： ```text L0 — imagined possibility L1 — plausible mechanism L2 — reproducible local witness L3 — cross-component propagation L4 — global invariant violation L5 — observed production/system impact ``` 一般 blocker 至少應要求： $$ L\geq L_2 $$ 或高後果情境中的： $$ L_1\times \text{Risk}\gg0. $$ 不能： $$ L_0\Rightarrow \text{BLOCK}. $$ --- # 23. Error Gravity 本文定義「錯誤重力」： $$ G_e = C_e \cdot D_e \cdot R_e \cdot (1-V_e). $$ 其中： - $C_e$：causal centrality； - $D_e$：dependency reach； - $R_e$：risk； - $V_e$：reversibility。 高 $G_e$ 問題會吸引較多： - 高階模型注意力； - reviewer； - tests； - human oversight； - remediation resources。 低 $G_e$ 問題則應： $$ \text{repair locally}. $$ 這樣才能讓 Agent 注意力與實際結構對齊。 --- # 24. 高階模型應該看高重力節點 高階模型具有昂貴但強大的： $$ A_{\text{global}}. $$ 它最適合： - architecture； - cross-module contract； - causal root； - system state； - technology selection； - completion judgment。 而不是： ```text 格式 小型 helper 局部 lint 重複 micro-test ``` 因此： $$ \boxed{ \text{ModelCapability} \leftrightarrow \text{CausalScale}. } $$ 高階模型應主要處理高全域權重節點。 微觀工作可以動態交給： - code worker； - 小模型； - local model； - deterministic tool； - compiler； - formatter。 --- # 25. Root Cause 比 Error Count 更重要 若測試出現： $$ 100 $$ 個 failures， 不表示有： $$ 100 $$ 個問題。 可能存在： $$ r_1 $$ 使： $$ r_1 \rightarrow \{ e_1,\ldots,e_{80} \}. $$ 因此優先級應根據： $$ \operatorname{RootCauseCoverage}(r) = |\Gamma(r)|. $$ 而不是： ```text 按照測試輸出順序一個一個修 ``` 這與 Global-First 中的 batched repair 完全一致。 --- # 26. 因果批次修復 流程應為： ```text Global validation ↓ Failure set ↓ Causal clustering ↓ Root causes ↓ Repair root causes ↓ Targeted revalidation ``` 形式上： $$ E = \{ e_1,\ldots,e_n \}. $$ 建立 partition： $$ E = C_1\cup C_2\cup\cdots C_k, $$ 每個 cluster 對應： $$ r_j. $$ 修： $$ r_j $$ 而不是逐一修： $$ e_i. $$ --- # 27. 反向傳播只到必要層級 一個 micro fix 後，validation propagation 應停止在： $$ L_{\max}(e). $$ 若 local fix 不影響 meso contract： $$ I\not\rightarrow E, $$ 則： $$ V_{\text{macro}}=0. $$ 如果影響 module contract： $$ I\rightarrow E, $$ 驗 meso。 只有： $$ E\rightarrow M $$ 時才重新做 macro validation。 因此： $$ \boxed{ \text{Validation propagation follows causal propagation.} } $$ --- # 28. Reopen Condition 完成並不意味永遠不可重開。 若新證據： $$ E_{\text{new}} $$ 使原本： $$ B(e)=0 $$ 變成： $$ B(e)=1, $$ 則可以： $$ \text{Completed} \rightarrow \text{Reopened}. $$ 例如： - production incident； - dependency change； - new requirement； - security disclosure； - scale increase； - runtime upgrade。 因此完成是： $$ \text{snapshot-relative}. $$ --- # 29. 完成狀態應分層 單一： ```text done ``` 不足。 本文建議： ```text macro_status meso_status micro_status verification_status ``` 例如： ```yaml completion: macro: complete meso: complete micro: critical: complete noncritical_open: 7 verification: sufficient ``` 這比： ```text partial ``` 更精確。 因為： $$ \text{7 個 cosmetic issue} $$ 不等於： $$ \text{產品只完成一半}. $$ --- # 30. Global Completion Score 可以定義： $$ GC = w_M C_M + w_E C_E + w_I C_I - P_B, $$ 其中： - $C_M$：Macro closure； - $C_E$：Meso closure； - $C_I$：critical micro closure； - $P_B$：blocking penalty。 通常： $$ w_M>w_E>w_I. $$ 但實際權重由任務決定。 最重要的是： $$ \text{noncritical micro imperfection} $$ 不應具有無限負權重。 --- # 31. 分層工作資源配置 對工作 $w_i$： $$ \text{Priority}(w_i) = \text{Impact} \times \text{Urgency} \times \text{Dependency} \times \text{Risk}. $$ 資源配置： $$ \text{Resource}(w_i) \propto \text{Priority}(w_i). $$ 因此： ```text Macro critical → strongest architect model Meso integration → strong / specialized model Micro bounded → cheap worker / deterministic tool ``` 這可以直接與 MACR 的 dynamic role-model binding 接合。 MACR 已經將 worker 選擇定義為 role-specific qualification、執行成本、驗證成本、latency、risk 與 task-fit 的共同選擇。 --- # 32. 分層驗證拓撲 可建立： $$ V_T = ( V_M, V_E, V_I ). $$ 其中： ### $V_M$ Macro ```text architecture witness global invariant major E2E state integrity ``` ### $V_E$ Meso ```text integration test contract test cross-file invariant boundary validation ``` ### $V_I$ Micro ```text unit test local witness static check targeted regression ``` 不應全部使用： $$ V_M. $$ --- # 33. 驗證降級也是正常能力 如果問題從： $$ \text{Macro} $$ 被證明只是： $$ \text{Micro}, $$ 則驗證應： $$ V_M \rightarrow V_I. $$ 這叫： # Validation Downgrade 它不是偷懶。 而是： $$ \boxed{ \text{Evidence reduced the causal scope.} } $$ 成熟 Agent 不只會 escalation，也必須會 de-escalation。 --- # 34. 微觀細節不應反向綁架架構 一個很重要的錯誤模式是： ```text local implementation difficulty → modify shared contract → modify architecture → modify product behavior ``` 這叫： # Bottom-Up Accidental Architecture 也就是： $$ \text{implementation convenience} \rightarrow \text{architecture}. $$ 正常流程應該先問： $$ \text{這個 micro difficulty 是否真的證明 macro assumption 錯？} $$ 如果不是，就： $$ \text{fix micro}. $$ 不要為了讓一個 helper 好寫而改整個世界。 --- # 35. 宏觀也不能無視微觀證據 反方向同樣成立。 如果大量 micro failures： $$ e_1,e_2,\ldots,e_n $$ 呈現共同模式： $$ \exists r: r\rightarrow e_i, $$ 則它們可能構成： $$ \text{Meso/Macro evidence}. $$ 所以： $$ \boxed{ \text{Micro does not automatically determine Macro,} } $$ 但： $$ \boxed{ \text{Repeated correlated Micro evidence can update Macro.} } $$ 這就是動態因果。 --- # 36. 完成優先不是品質放棄 分層因果完成論可能被誤解成： > 小 bug 不管。 這是錯誤的。 本文真正主張： $$ \boxed{ \text{Repair priority} \neq \text{Moral value of correctness}. } $$ 所有錯誤都可以修。 但不是所有錯誤都需要： - 同一時刻修； - 同一模型修； - 同一驗證強度； - 阻塞同一交付。 工程是資源配置問題。 --- # 37. 因果完成矩陣 可以建立： | Scale | Impact | Action | |---|---|---| | Macro | High | Immediate blocker | | Macro | Low | Review / architecture note | | Meso | High | Integration blocker | | Meso | Low | Scheduled repair | | Micro | High | Critical targeted repair | | Micro | Low | Local fix / backlog | 因此： $$ \text{Scale} + \text{Impact} $$ 共同決定狀態。 --- # 38. 高風險微觀例外 某些 micro 問題必須升級。 例如： ```text if user.role == "admin": ``` 若比較條件有錯， 雖然只有一行，但： $$ \text{CausalCentrality}\gg0. $$ 因此： $$ \text{Micro} + \text{HighImpact} \rightarrow \text{GlobalAttention}. $$ 這再次說明： $$ \text{Micro}\neq\text{Trivial}. $$ --- # 39. 驗證預算 令總驗證預算： $$ B_V. $$ 合理配置： $$ B_V = B_M + B_E + B_I. $$ 應滿足： $$ B_M:B_E:B_I $$ 依任務而變。 不應： $$ B_I\rightarrow\infty. $$ 否則大量預算會被低影響問題吸收。 --- # 40. Completion Budget 同樣定義完成資源： $$ B_C. $$ 每增加一個 refinement： $$ r_k $$ 都有： $$ \Delta U_k. $$ 若： $$ \Delta U_k < C(r_k), $$ 且： $$ B(r_k)=0, $$ 則應停止。 這與 GCPR 的 marginal improvement stop condition 相容。 --- # 41. Agent 的新問題順序 Agent 發現問題後，應按順序問： ```text 1. 這是什麼問題？ 2. 位於哪個尺度？ 3. 影響哪些節點？ 4. 是否跨 boundary？ 5. 是否破壞 global invariant？ 6. 是否可逆？ 7. 是否真的 blocking？ 8. 要驗證到哪一層？ 9. 修復後需要重新驗哪些東西？ 10. 修完是否已可以停止？ ``` 而不是： ```text 發現問題 → 全部重跑 ``` --- # 42. Hierarchical Completion Loop 本文提出完整循環： $$ \boxed{ \begin{aligned} \text{Observe} &\rightarrow \text{Scale Classify}\\ &\rightarrow \text{Causal Locate}\\ &\rightarrow \text{Impact Estimate}\\ &\rightarrow \text{Blocker Qualify}\\ &\rightarrow \text{Repair}\\ &\rightarrow \text{Bounded Verify}\\ &\rightarrow \text{Recompute Completion}. \end{aligned} } $$ 如果： $$ B=0 $$ 則： $$ \text{ContinueCompletion}. $$ 如果： $$ B=1, $$ 才進： $$ \text{BlockAndRepair}. $$ --- # 43. 與 Global-First 的結合 Paper 01 前面已經建立： $$ \text{Technology Domain} \rightarrow \text{Global Build}. $$ 本文再加入： $$ \text{Hierarchical Causal Attention}. $$ 完整流程變成： $$ \boxed{ \begin{aligned} \text{Intent} &\rightarrow \text{Technology Domain}\\ &\rightarrow \text{Global Architecture}\\ &\rightarrow \text{Global Instantiation}\\ &\rightarrow \text{Macro Validation}\\ &\rightarrow \text{Meso Integration}\\ &\rightarrow \text{Micro Repair}\\ &\rightarrow \text{Causal-Weighted Verification}\\ &\rightarrow \text{Global Completion}. \end{aligned} } $$ --- # 44. 與動態 Agent Routing 的接口 每個問題 $e_i$ 可生成： ```yaml task: scale: micro causal_impact: low dependency_radius: local risk: low required_capability: code_fix verification: targeted ``` 則 router 可以選： $$ M_{\text{cheap}}. $$ 如果： ```yaml scale: macro causal_impact: high architecture: affected ``` 則： $$ M_{\text{frontier}} + \text{ArchitectRole}. $$ 因此： $$ \boxed{ \text{Task routing should follow causal scale.} } $$ --- # 45. 五項核心原理 ## 原理一：尺度分離 $$ \boxed{ \text{Macro}\neq\text{Meso}\neq\text{Micro}. } $$ 不可把所有問題放在同一平面。 --- ## 原理二：因果升格需要證據 $$ \boxed{ \text{Possibility} \not\Rightarrow \text{Global Impact}. } $$ --- ## 原理三：驗證跟隨因果 $$ \boxed{ \text{ValidationRadius} \approx \text{CausalRadius}. } $$ --- ## 原理四：局部不完美可與全域完成共存 $$ \boxed{ \text{LocalImperfection} \land \text{GlobalInvariant} = \text{CompletionPossible}. } $$ --- ## 原理五：高階注意力應保留給高因果權重節點 $$ \boxed{ \text{AttentionBudget} \propto \text{CausalGravity}. } $$ --- # 46. 最終命題 分層因果完成論最終反對的是一個極其簡單、但正在大量 Agent 工作流中出現的錯誤： > **有問題，所以不能完成。** 更正確的判斷應該是： > **有什麼問題？它在哪一層？它真正影響什麼？它是否破壞必要目標？** 因此： $$ \boxed{ \text{Problem existence} \neq \text{Completion failure}. } $$ 以及： $$ \boxed{ \text{Micro failure} \neq \text{Macro failure}. } $$ 完成不是把整個系統磨到沒有任何可挑剔之處。 完成是在既定 scope 中： $$ \boxed{ \text{Macro invariants closed} + \text{Meso contracts closed} + \text{Critical micro obligations closed} } $$ 而低影響問題可以被明確知道、明確分類、明確延後。 --- # 結論 AI 的全域注意力能力若只是被拿來「找到更多問題」，那並沒有真正發揮它的價值。 全域注意力真正重要的能力應該是： > **知道哪些問題重要，哪些問題只屬於局部。** 一個成熟的高階 AI 應該能同時看見： ```text 整個系統 ↓ 關鍵子系統 ↓ 局部節點 ``` 並保持： $$ \text{Macro} \leftrightarrow \text{Meso} \leftrightarrow \text{Micro} $$ 之間的因果關係。 它不應因為看到一個微觀異常，就立即將全世界重新送進驗證。 也不應因為宏觀架構看起來漂亮，就忽略大量一致的微觀反證。 真正的能力是： $$ \boxed{ \text{Scale awareness} + \text{Causal weighting} + \text{Proportional verification} + \text{Completion judgment}. } $$ 這也將直接通往本系列第三篇： # 《AI 原生工作組織論》 下一篇將把： - 高階 AI 的架構師責任； - 壓縮全局智能； - 天選打工人； - MACR 動態模型路由； - 雙生架構； - 子 Agent 按需展開； - 宏／中／微任務分配； - Global-First implementation； - Global Completion Supervisor； 統合成一套完整的 AI 原生工作組織架構。