# 外部注意力場工程系統與實驗框架：統一架構、基準任務與第一代工程封頂 **External Attention Field Engineering Systems and Experimental Frameworks: Unified Architecture, Benchmark Tasks, and First-Generation Engineering Closure** 版本：v0.1 日期：2026-07-28 文件性質：系統統合、實驗設計與工程交接論文 系列：外部注意力場工程系列，第 7 篇 建議文件代號：`EML-EAFE-07-2026-v0.1` --- ## 摘要 前六篇已分別建立外部注意力場總論、顯影與抑制算子、AI—外掛協同閉環、工作場與注意力預算、空間介面，以及偏誤與治理框架。然而，若缺乏統一資料模型、參考架構、實驗基準與工程接口，這些理論仍可能停留在彼此關聯但難以部署的概念集合。 本文提出外部注意力場工程的第一代統合系統與實驗框架。本文將 EAFOS、GAALS、WFABE、SAIFE 與 EAGAL 整合為「外部注意力場工程參考架構」（External Attention Field Engineering Reference Architecture, EAFE-RA），並定義總資訊環境、候選注意力場、活動工作場、模型上下文、外掛觀測、場補丁、治理決策、介面投影與追加式帳本之間的資料流。 本文提出統一注意力狀態物件、統一操作結果、工作場補丁、來源圖、版本圖、工具能力描述、調控帳本與審計記錄。本文亦定義事件驅動與快照驅動兩種部署模式，以及單 Agent、多 Agent、長期研究、程式開發與企業知識工作流等不同應用剖面。 為避免外部注意力場工程成為只靠直覺成立的系統敘述，本文建立一組可被反駁的比較實驗。對照基線包括：固定上下文、純提示詞、普通 RAG、RAG 加 Reranker、長上下文、普通 Tool Agent、記憶型 Agent，以及完整 EAFE。基準任務涵蓋長期專案恢復、版本污染、來源回溯、反例保留、工具選擇、上下文預算、介面操作誤提交、治理裁剪揭露與多輪任務延續。 本文提出 EAFE-Bench，包括資料生成規格、人工標註、干擾注入、版本分支、來源污染、工具失敗、權限邊界、商業排序與治理偏誤等測試情境。評估指標分為任務品質、工作場品質、來源與版本完整性、工具閉環效率、注意力預算、介面可操作性、治理與偏誤、恢復與連續性八個指標族。 本文進一步提出消融實驗，以檢查顯影、抑制、路由、工作場閉包、預算預留、來源錨定、反例配額、治理帳本、介面投影與反事實審計是否真正產生增益。若完整 EAFE 無法在長期任務、版本純度、來源保持、錯誤恢復與治理可追溯性方面穩定優於較簡單基線，則其工程複雜度不具正當性。 本文最後提出第一代 MVP：以 JSON 型別化工作場、追加式事件帳本、規則式顯影器、簡單工具路由、來源錨定摘要、工作場重編譯與基本介面檢視器為核心，不依賴完整 NOVA、格子語言或原生張量記憶 Runtime。此 MVP 可先作為 Dynamic Revealing 的工程基準，後續再逐步接入 EML-U、NOVA Typed Graph、格子語言與稀疏張量記憶。 本篇完成外部注意力場工程前七篇核心系列的第一階段封頂。第八篇與第九篇保留為遠期應用，分別處理多代理共享注意力場與計算機宇宙世界狀態注意力管理。 **關鍵詞：** 外部注意力場工程、參考架構、EAFE-Bench、動態顯影、Agent、工具閉環、工作場、注意力預算、AI 治理、實驗框架 --- # 1. 第一階段封頂目標 前六篇已完成： 1. 外部注意力場總論； 2. 顯影、抑制、約束與路由； 3. AI—外掛協同注意力閉環； 4. 工作場、上下文與注意力預算； 5. 空間化與介面注意力調控； 6. 偏誤、權力與治理。 第七篇的任務不是再提出新的上位概念，而是回答： - 這些理論如何組成一個系統？ - 系統的最小資料模型是什麼？ - 哪些模組可以先做？ - 如何與既有 AI 系統比較？ - 如何判斷 EAFE 是否真的有價值？ - 哪些模組是必要的，哪些只是複雜化？ - 如何在未完成 NOVA 與格子語言前建立 MVP？ - 如何把成果交接給後續工程？ 因此本篇是： $$ \boxed{ \text{Theory} \rightarrow \text{Reference Architecture} \rightarrow \text{Benchmark} \rightarrow \text{MVP} \rightarrow \text{Engineering Handoff} } $$ --- # 2. 核心系統回顧 ## 2.1 EAFOS External Attention Field Operator System 負責： - 顯影； - 抑制； - 約束； - 路由； - 驗證； - 操作帳本。 ## 2.2 GAALS Governed Adaptive Attention Loop System 負責： - AI 提出請求； - 治理授權； - 外掛執行； - 觀測正規化； - 工作場補丁； - 閉環終止。 ## 2.3 WFABE Work-Field and Attention-Budget Engine 負責： - 閉包缺口； - 多維注意力預算； - 最小任務閉合工作場； - 上下文重編譯； - 滾動狀態； - 檢查點。 ## 2.4 SAIFE Spatialized Attention Interface and Field Engine 負責： - 多投影； - 格子、畫布、矩陣、文件、時間線； - 語義縮放； - 人機共享定址； - 顯示、注意力與權威操作分離。 ## 2.5 EAGAL External Attention Governance and Audit Layer 負責： - 政策版本； - 偏誤監測； - 商業影響揭露； - 注意力差分； - 反事實測試； - 申訴、撤銷與治理停止。 --- # 3. EAFE 統一參考架構 本文將完整參考架構命名為： # External Attention Field Engineering Reference Architecture 縮寫： # EAFE-RA 定義： $$ \operatorname{EAFE\text{-}RA} = \left( \mathfrak E, \mathbb A, \mathbb W, \mathcal M, \mathcal X, \mathcal O, \mathcal B, \mathcal P, \mathcal G, \mathcal I, \mathcal V, \mathcal L \right) $$ 其中： - $\mathfrak E$ ：總資訊與能力環境； - $\mathbb A$ ：候選與活動外部注意力場； - $\mathbb W$ ：活動工作場； - $\mathcal M$ ：模型與代理集合； - $\mathcal X$ ：外掛與工具； - $\mathcal O$ ：顯影、抑制、約束與路由算子； - $\mathcal B$ ：多維注意力預算； - $\mathcal P$ ：政策與策略； - $\mathcal G$ ：治理與審計； - $\mathcal I$ ：介面與投影； - $\mathcal V$ ：驗證； - $\mathcal L$ ：追加式帳本。 --- # 4. EAFE-RA 的資料流 ```text Total Information and Capability Environment ↓ Policy / Permission / Risk Gate ↓ Candidate Attention Field ↓ Reveal / Suppress / Constrain ↓ Closure-Gap and Budget Engine ↓ Active Work Field ↓ Model-Specific Context Compiler ↓ Model / Agent Reasoning ↓ Attention / Tool / Validation Request ↓ Governed Extension Execution ↓ Observation Quarantine Zone ↓ Normalization / Provenance / Version ↓ Attention-Field Patch ↓ Validation / Commit / Rollback ↓ Updated Work Field ↓ Interface Projection / Audit View ↓ Append-only Event Ledger ``` --- # 5. 四個權威層級 系統必須區分： ## 5.1 原始來源權威 文件、資料庫、程式碼、工具觀測、感測結果。 ## 5.2 結構權威 來源、版本、因果、依賴、身份、權限圖。 ## 5.3 工作場權威 當前任務下的活動狀態、證據、未決節點與工具計畫。 ## 5.4 介面投影 文件、畫布、矩陣、對話、時間線與 Agent 面板。 因此： $$ \boxed{ \text{Interface View} \neq \text{Work-Field Authority} \neq \text{Source Authority} } $$ --- # 6. 統一注意力狀態物件 定義： ```json { "attention_object": { "object_id": "attn-object-001", "authority_ref": "source://document/17#section-4", "type": "evidence", "content_ref": "blob://sha256/...", "semantic_state": { "summary": "...", "tags": [] }, "attention_state": { "visibility": "active", "salience": 0.78, "resolution": "structured_summary", "pinned": true }, "evidence_state": { "status": "observed", "confidence": null, "source_independence": 0.63 }, "version_state": { "branch": "main", "version": "v3.2", "valid_from": null, "valid_to": null }, "governance_state": { "permission": "project-read", "risk": "low", "commercial_influence": false }, "provenance": [], "relations": [], "ledger_refs": [] } } ``` --- # 7. 統一操作結果 所有模組應使用： $$ \operatorname{OperationResult}(T) $$ 狀態包括： ```text success limited alternatives partial needs_evidence needs_approval quarantined rejected failed ``` 範例： ```json { "operation_result": { "status": "limited", "value": {}, "limits": [ "max_relation_depth=2" ], "alternatives": [], "warnings": [], "provenance": [], "cost": {}, "ledger_entry": "ledger-882" } } ``` --- # 8. 工作場統一物件 ```json { "work_field": { "work_field_id": "wf-001", "task_id": "task-001", "authority_version": 24, "goal": {}, "current_state": {}, "active_objects": [], "latent_objects": [], "evidence_graph": [], "causal_graph": [], "version_graph": [], "tool_state": [], "open_nodes": [], "failure_records": [], "constraints": [], "budget": {}, "closure": {}, "governance": {}, "interface_views": [], "ledger_head": "ledger-924" } } ``` --- # 9. 場補丁 所有更新應先表達為： $$ \Delta\mathbb W_t $$ 而不是直接修改。 ```json { "work_field_patch": { "patch_id": "wf-patch-044", "base_version": 24, "add_objects": [], "update_objects": [], "suppress_objects": [], "add_relations": [], "remove_relations": [], "update_constraints": [], "update_budget": {}, "open_nodes": [], "close_nodes": [], "provenance": [], "reversible": true, "validation_required": true } } ``` --- # 10. 來源圖與版本圖 ## 10.1 來源圖 $$ G^{\mathrm{prov}} = \left( N^{\mathrm{source}}, E^{\mathrm{derived}} \right) $$ 追蹤： - 原始觀測； - 摘要； - 推導； - 模型解釋； - 記憶寫回； - 再檢索。 ## 10.2 版本圖 $$ G^{\mathrm{ver}} = \left( N^{\mathrm{version}}, E^{\mathrm{branch}} \right) $$ 追蹤： - 新版本； - 分支； - 合併； - 取代； - 回滾； - 有效時間。 --- # 11. 事件驅動模式 每次操作寫入事件： $$ e_t = \left( type, actor, target, before, after, policy, time \right) $$ 工作場由事件重建： $$ \mathbb W_t = \operatorname{Fold} \left( e_0,e_1,\ldots,e_t \right) $$ 優點： - 可重現； - 可回滾； - 可審計； - 可比較策略。 缺點： - 重建成本； - 事件膨脹； - schema 演化困難。 --- # 12. 快照驅動模式 定期保存： $$ \mathbb W_{t_k}^{\mathrm{snapshot}} $$ 搭配後續事件： $$ \mathbb W_t = \operatorname{Apply} \left( \mathbb W_{t_k}^{\mathrm{snapshot}}, e_{t_k+1:t} \right) $$ 適合實際 MVP。 --- # 13. 部署剖面 ## 13.1 單次問答 只需要： - 簡單顯影； - 基本來源； - 輕量預算； - 無永久工作場。 ## 13.2 長期研究代理 需要： - 工作場檢查點； - 失敗路徑； - 來源圖； - 版本圖； - 反例預算； - 多輪恢復。 ## 13.3 程式開發代理 需要： - 程式 AST； - Git 分支； - 測試； - 工具沙盒； - 執行日誌； - 提交契約。 ## 13.4 企業知識系統 需要： - 權限； - 租戶隔離； - 文件版本； - 審計； - 商業與組織策略。 ## 13.5 多代理系統 需要： - 私有與共享注意力場； - 代理路由； - 衝突； - 委派； - 共享記憶治理。 --- # 14. 第一代 MVP 原則 MVP 不等待： - 完整 NOVA Runtime； - 完整格子語言； - 原生張量資料庫； - 自主多代理系統； - 世界線管理器。 MVP 先採： $$ \boxed{ \text{Typed JSON} + \text{Append-only Ledger} + \text{Rule-Based Operators} + \text{Context Compiler} + \text{Tool Adapter} + \text{Basic Audit UI} } $$ --- # 15. 第一代 MVP 模組 ```text eafe-core/ ├── schema/ │ ├── attention_object.json │ ├── work_field.json │ ├── work_field_patch.json │ ├── operation_result.json │ └── governance_record.json ├── field/ │ ├── candidate_builder │ ├── closure_analyzer │ ├── budget_allocator │ ├── context_compiler │ └── checkpoint_manager ├── operators/ │ ├── reveal │ ├── suppress │ ├── constrain │ └── route ├── tools/ │ ├── registry │ ├── adapters │ ├── observation_zone │ └── patch_builder ├── governance/ │ ├── policy_engine │ ├── scope_disclosure │ ├── bias_monitor │ └── appeal ├── ledger/ │ ├── event_store │ └── snapshot_store ├── interface/ │ ├── work_field_view │ ├── diff_view │ └── audit_view └── benchmarks/ ├── datasets ├── runners └── metrics ``` --- # 16. MVP 的最小垂直切片 輸入： - 一組 Markdown 文件； - 一段長期對話； - 專案狀態； - 版本 metadata； - 任務查詢。 流程： ```text Import Sources ↓ Build Provenance and Version Index ↓ Reveal Candidate Objects ↓ Build Minimal Task-Closed Work Field ↓ Compile Model Context ↓ Model Produces Answer or Tool Request ↓ Tool Observation ↓ Build and Validate Work-Field Patch ↓ Update Work Field ↓ Show Sources, Suppressed Scope and Open Nodes ``` 輸出： - 回答； - 活動工作場； - 來源圖； - 版本圖； - 抑制摘要； - 未決節點； - 操作帳本； - 下一步。 --- # 17. Dynamic Revealing 作為第一個參考應用 第一個參考應用不應叫「完整外部注意力作業系統」。 可定位為： # Dynamic Revealing Work-State Engine 功能： - 從專案歷史恢復工作狀態； - 顯影關鍵來源； - 分離版本； - 保留失敗路徑； - 形成可延續上下文； - 顯示未決節點； - 允許 AI 提出進一步顯影請求。 這是最容易比較的第一個產品切口。 --- # 18. 比較基線 EAFE 實驗至少比較： ## B0：固定上下文 人工選定固定資料。 ## B1：純提示詞 沒有外部檢索。 ## B2：普通 RAG 向量檢索 Top-k。 ## B3：RAG + Reranker 增加重排。 ## B4：長上下文 盡量載入完整歷史。 ## B5：普通 Tool Agent 模型可調工具，但無權威工作場與治理帳本。 ## B6：記憶型 Agent 有長期記憶檢索與摘要。 ## B7：完整 EAFE 包含： - 工作場； - 來源； - 版本； - 預算； - 工具閉環； - 治理； - 差分帳本。 --- # 19. 實驗控制條件 為公平比較，應控制： - 相同模型； - 相同基礎資料； - 相同任務； - 相同最大成本； - 相同工具集合； - 相同時間上限； - 相同人工輸入； - 相同評估規則。 不同系統可自由分配資源，但不能無限制增加模型或工具能力。 --- # 20. EAFE-Bench 本文將基準框架命名為： # EAFE-Bench 目標是測量： - 能否形成可工作的局部世界； - 能否在有限資源下保持來源、版本、因果與未決節點； - 能否正確使用外掛； - 能否避免遞歸自證； - 能否揭露注意力裁剪； - 能否恢復長期任務。 --- # 21. 基準任務一：長期專案恢復 資料： - 100 至 5,000 段對話； - 10 至 500 份文件； - 多個版本； - 已完成與未完成工作； - 失敗路徑； - 使用者偏好與限制。 任務： > 恢復目前專案狀態，說明做到哪裡、採用哪些決策、依據什麼來源、哪些路徑已失敗，以及下一步。 評估： - 工作狀態正確率； - 來源保持； - 未決節點； - 失敗路徑； - 下一步可執行性。 --- # 22. 基準任務二：版本污染 資料包含： - v1； - v2； - 分支 A； - 分支 B； - 已失效規則； - 相似但衝突內容。 任務： > 回答當前有效版本，並說明哪些歷史內容不可混入。 評估： - 版本純度； - 分支識別； - 舊版本滲透率； - 合併錯誤。 --- # 23. 基準任務三：來源回溯 提供： - 摘要； - 派生文件； - 多層引用； - 缺失來源； - 模型生成內容。 任務： > 找出某結論的最原始可用證據，區分觀測、推導、解釋與推定。 評估： - 原始來源召回； - 派生鏈正確； - 自生成內容誤認率； - 不確定性標記。 --- # 24. 基準任務四：反例保留 資料中主流內容支持假設 $H$ ，少數來源反駁 $H$ 。 任務： > 評估 $H$ ，保留重要反例並判斷是否需要更多驗證。 評估： - 反例召回； - 結論校準； - 過早坍縮率； - 反例預算效果。 --- # 25. 基準任務五：工具選擇 可用工具： - 搜尋； - 計算； - 程式執行； - 文件比較； - 資料庫； - 人類審核。 任務： > 以最低合理成本完成工作。 注入： - 工具故障； - 工具陳舊； - 錯誤 schema； - 低成本但不適合工具。 評估： - 選擇適切率； - 無效循環； - 停止判定； - 成本效益。 --- # 26. 基準任務六：注意力預算 給定固定： - token； - 工具次數； - 時間； - 人類審核次數。 任務包含： - 核心證據； - 反例； - 版本； - 驗證； - 不可逆操作。 評估： - 預算分配； - 預留存活； - 任務閉合； - 驗證是否被犧牲。 --- # 27. 基準任務七：介面誤提交 模擬： - 拖曳； - 收合； - 連線； - 封裝； - 鎖定； - 分支比較。 任務： > 判斷哪些操作只是顯示、哪些改變注意力場、哪些改變權威結構。 評估： - 顯示—語義誤操作率； - 預覽效果； - 回滾； - 多視圖一致性。 --- # 28. 基準任務八：治理裁剪揭露 加入： - 權限過濾； - 商業排序； - 組織策略； - 風險抑制； - 反例配額。 任務： > 回答問題，同時說明可見域如何被裁剪。 評估： - 裁剪揭露； - 商業影響揭露； - 策略敏感性； - 申訴可用性； - 認知負擔。 --- # 29. 基準任務九：遞歸自證 流程： 1. 模型生成推定； 2. 推定被寫入記憶； 3. 後續重新檢索； 4. 與外部來源混合。 任務： > 判斷哪些證據是獨立來源，哪些來自模型自身。 評估： - 外掛回聲率； - 自我證據誤認率； - 來源獨立性； - 污染隔離。 --- # 30. 基準任務十：多輪延續 任務分成： $$ T_1,T_2,\ldots,T_n $$ 每輪加入： - 新證據； - 新工具結果； - 版本變動； - 任務修改； - 失敗。 評估： - 滾動連續性； - 每輪重建成本； - 開放節點保留； - 狀態漂移； - 檢查點恢復。 --- # 31. 合成資料生成器 EAFE-Bench 可提供合成資料生成器： ```text generate_project( documents, conversations, versions, branches, sources, failures, open_nodes, permissions, commercial_bias, tool_failures ) ``` 生成器需保留完整 ground truth： - 真正來源； - 有效版本； - 必要因果； - 任務狀態； - 反例； - 正確工具路徑； - 權限邊界。 --- # 32. 真實資料集 合成資料便於控制，但應搭配真實資料： - 開源軟體 issue 與 commit； - 公開研究專案； - 長期寫作專案； - 公開法律與政策版本； - 企業模擬知識庫； - 多輪 Agent 工作日誌。 真實資料需匿名化、授權與版本固定。 --- # 33. 人工標註規格 標註者需標記： - 任務目標； - 當前狀態； - 必要證據； - 原始來源； - 版本； - 因果； - 未決節點； - 失敗； - 合法工具； - 權限； - 可接受替代答案。 標註不應只提供最終答案，還要提供最小閉合工作場參考。 --- # 34. 指標族一：任務品質 包括： - 正確率； - 完成率； - 可執行下一步； - 結論校準； - 使用者評分； - 長期延續成功率。 --- # 35. 指標族二：工作場品質 包括： - 任務閉合率； - 必要證據覆蓋； - 因果閉包； - 開放節點保留； - 失敗路徑保留； - 無關內容率； - 工作場最小性。 --- # 36. 指標族三：來源與版本 包括： - 來源保持率； - 原始來源召回； - 版本純度； - 分支識別； - 來源獨立性； - 自生成證據誤認率。 --- # 37. 指標族四：工具閉環 包括： - 工具選擇適切率； - 請求合法率； - 觀測正規化； - 無效工具循環； - 部分成功處理； - 終止判定； - 沙盒與正式提交差異。 --- # 38. 指標族五：注意力預算 包括： - token 使用； - 工具調用； - 時間； - 費用； - 人類審核； - 預留存活； - 每單位成本品質增益； - 預算近視。 --- # 39. 指標族六：介面可操作性 包括： - 顯示—語義誤操作； - 權威狀態辨識； - 多視圖一致性； - 視圖新鮮度； - 語義縮放； - 人機共同定址； - 回滾成功率； - 無障礙覆蓋。 --- # 40. 指標族七：治理與偏誤 包括： - 抑制理由覆蓋； - 裁剪揭露； - 商業影響揭露； - 反例保留； - 策略敏感性； - 申訴可達； - 撤銷； - 權限違規； - 注意力不平等。 --- # 41. 指標族八：恢復與連續性 包括： - 檢查點恢復； - 滾動工作場連續性； - 重啟後狀態正確率； - Agent 交接； - 記憶污染恢復； - 失敗後重建。 --- # 42. 單一總分的限制 EAFE 不應只輸出一個總分： $$ Q_{\mathrm{EAFE}} $$ 因為高任務完成率可能伴隨： - 高權限風險； - 低來源保持； - 高成本； - 商業偏誤； - 低可撤銷性。 建議使用雷達式或多指標報告，但不應把所有價值壓成單一標量。 --- # 43. 消融實驗 消融版本： ## A0：完整 EAFE ## A1：移除抑制帳本 ## A2：移除版本圖 ## A3：移除來源錨定 ## A4：移除工作場閉包 ## A5：移除預留預算 ## A6：移除反例配額 ## A7：移除治理揭露 ## A8：移除工具觀測隔離 ## A9：移除動態上下文重編譯 ## A10：移除多視圖權威分離 比較每個模組的實際貢獻。 --- # 44. 關鍵消融假設 ## 假設一 移除來源錨定會提高最終回答流暢度，但降低原始來源回溯。 ## 假設二 移除版本圖會在資料相似時提高檢索召回，但增加版本污染。 ## 假設三 移除預留預算會提升早期資訊量，但降低後期驗證能力。 ## 假設四 移除反例配額會提高結論一致性，但增加過早坍縮。 ## 假設五 移除治理揭露不一定降低任務正確率，但會降低可申訴與偏誤發現能力。 --- # 45. 壓力測試 ## 45.1 大規模資料 從： $$ 10^3 \rightarrow 10^7 $$ 個項目。 ## 45.2 高版本密度 大量相似版本與分支。 ## 45.3 高工具失敗率 工具超時、部分成功、錯誤資料。 ## 45.4 高偏誤環境 商業排序、來源集中、語言不平衡。 ## 45.5 高風險寫回 需要沙盒、批准與回滾。 ## 45.6 多代理衝突 不同 Agent 爭用預算與工作場。 --- # 46. 性能指標 系統性能包括： - 候選建立延遲； - 工作場編譯延遲； - 工具閉環延遲； - 事件寫入； - 快照重建； - 介面渲染； - 多視圖同步； - 每萬節點記憶成本； - 每次補丁驗證成本。 --- # 47. 故障注入 主動注入： - metadata 錯誤； - 來源缺失； - 版本錯標； - 工具幻覺； - 提示注入； - 權限配置錯誤； - 帳本缺口； - 快照損壞； - Agent 重複提交； - 模型自生成污染。 評估系統是否能偵測、隔離、恢復。 --- # 48. 實驗重現性 每次實驗記錄： ```json { "experiment_run": { "run_id": "eafe-run-001", "dataset_version": "bench-v1.0", "model": {}, "tool_registry": {}, "policy_profile": "research-balanced-v3", "random_seed": 42, "budget": {}, "baseline": "B7", "configuration": {}, "ledger_head": "ledger-990", "results": {} } } ``` --- # 49. 統計比較 對每個任務執行多次： $$ n \geq N_{\min} $$ 測量： - 平均； - 中位數； - 標準差； - 置信區間； - 效果量； - 失敗分布。 不能只展示少數成功案例。 --- # 50. 人類評估 人工評估需分離： - 回答品質； - 可追溯性； - 工作場完整性； - 介面理解； - 治理透明； - 認知負擔； - 是否願意採用。 不同維度由不同標註指南評估。 --- # 51. 模型評估的限制 可使用另一模型作為部分評審，但不能完全依賴模型判分，因為： - 可能共享偏誤； - 可能偏好流暢答案； - 難以驗證權限； - 難以判斷真實來源； - 可能忽略長期狀態錯誤。 --- # 52. 第一代工程里程碑 ## M0：Schema 與資料匯入 - Markdown； - JSON； - 對話； - 版本 metadata。 ## M1：來源與版本圖 - 穩定 ID； - provenance； - version branch。 ## M2：規則式顯影與抑制 - 關鍵詞； - embedding； - 版本； - 權限； - 反例。 ## M3：最小工作場 - 目標； - 狀態； - 證據； - 開放節點； - 下一步。 ## M4：上下文編譯 - 核心； - 差分； - 證據； - 工具契約。 ## M5：工具閉環 - 搜尋； - 文件； - 程式； - 觀測隔離； - 補丁。 ## M6：治理與審計 - 抑制摘要； - 政策版本； - scope disclosure； - rollback。 ## M7：基準與對照 - B0 至 B7； - 消融； - 報告。 --- # 53. 不需要先做的內容 第一代不需要： - 自創新模型； - 原生張量硬體； - 全自動多代理組織； - 世界線合併； - 完整格子 IDE； - 大型分散式 Runtime； - 物理宇宙模擬。 這些不是驗證 EAFE 核心命題的前置條件。 --- # 54. 與 EML-U 的接口 EML-U 可逐步提供： - 高密度語義物件； - 多重來源； - 推定與觀測分層； - 意圖； - 操作請求； - 多投影。 第一代 MVP 可先用 JSON，後續再轉為 EML-U 語義物件。 --- # 55. 與 NOVA 的接口 NOVA 可提供： - Typed Graph； - 穩定身份； - 型別化關係； - 權威補丁； - 驗證契約； - 提交語義； - Runtime 路由。 第一代 MVP 應將 schema 設計成未來可映射 NOVA。 --- # 56. 與格子語言的接口 格子語言可提供： - 自由封裝； - 可操作定址； - 多投影； - 端口； - 宣告偶合； - 人機共同操作。 第一代介面可先使用簡單卡片、樹與圖，不等待完整格子語言。 --- # 57. 與原生張量記憶的接口 當資料規模與關係模式增加，可將工作場映射到： $$ \mathbb M_t \in \mathcal V_{\mathrm{sem}} \otimes \mathcal V_{\mathrm{time}} \otimes \mathcal V_{\mathrm{causal}} \otimes \mathcal V_{\mathrm{version}} \otimes \mathcal V_{\mathrm{agent}} \otimes \mathcal V_{\mathrm{prov}} $$ 第一代仍可使用： - 關聯資料庫； - 文件索引； - 圖資料庫； - 向量檢索； - 事件帳本。 --- # 58. 第一代工程風險 ## 58.1 過度架構 理論模組太多，MVP 無法完成。 ## 58.2 指標爆炸 指標過多，無法判斷核心增益。 ## 58.3 schema 僵化 太早固定所有物件。 ## 58.4 介面先行 做出漂亮畫布，但沒有權威工作場。 ## 58.5 模型依賴 基準結果被單一模型能力掩蓋。 ## 58.6 工具依賴 不同工具品質使比較失真。 ## 58.7 人工標註成本 最小閉合工作場標註昂貴。 ## 58.8 治理形式化 只記錄帳本，實際無法申訴與回滾。 --- # 59. 風險控制 - 先做單一垂直切片； - 先測長期專案恢復； - schema 保留擴展欄位； - 只保留五至十個核心指標； - 基線使用同一模型； - 先以規則和簡單檢索建立可重現結果； - 介面以審計視圖為主； - 所有模組可消融。 --- # 60. 第一代核心指標 若只保留十項： 1. 任務完成率； 2. 工作場閉合率； 3. 原始來源召回； 4. 版本純度； 5. 開放節點保留； 6. 外掛回聲率； 7. 每單位成本品質增益； 8. 預留預算存活； 9. 裁剪揭露完整度； 10. 滾動連續性。 --- # 61. 可反證總條件 若完整 EAFE 在控制模型、工具、資料與成本後，不能穩定提升： - 長期任務恢復； - 工作狀態連續性； - 來源保持； - 版本純度； - 反例保留； - 工具使用效率； - 錯誤恢復； - 治理可追溯性； 並且其工程成本顯著高於收益，則： $$ \boxed{ \text{EAFE should not be treated as a universal architecture} } $$ 它可能只適用於： - 長期； - 高風險； - 多工具； - 多版本； - 多代理； - 高治理要求； 的任務。 --- # 62. 基礎命題 ## 命題一：統一架構命題 外部注意力場、工作場、工具閉環、預算、介面與治理可由共享資料模型與補丁機制統合。 ## 命題二：工作場權威命題 模型上下文與介面視圖應由權威工作場投影，而非各自維持獨立真相。 ## 命題三：補丁優先命題 工具結果與介面操作應先表達為可驗證補丁，再修改工作場。 ## 命題四：比較必要命題 EAFE 的價值必須透過固定上下文、RAG、Reranker、Tool Agent 與記憶 Agent 對照驗證。 ## 命題五：長期任務優勢命題 EAFE 的主要潛在優勢應出現在長期、版本化、工具密集與高治理任務，而非所有簡單問答。 ## 命題六：消融必要命題 若移除某模組不降低表現，該模組不應被視為必要核心。 ## 命題七：MVP 可分離命題 EAFE 核心可在不等待 NOVA、格子語言與原生張量 Runtime 的情況下，以 JSON、事件帳本與規則算子驗證。 ## 命題八：多指標命題 任務品質、成本、來源、版本、治理與可恢復性不能被單一總分充分表示。 ## 命題九：故障注入命題 只有在來源缺失、版本錯標、工具故障與權限錯誤下仍能恢復的系統，才具有實際韌性。 ## 命題十：第一階段封頂命題 前七篇已足以形成完整核心方法論；後續應優先實驗與工程，而非持續增加同層理論。 --- # 63. 第一階段封頂後的研究順序 合理順序為： $$ \boxed{ \text{EAFE-Bench} \rightarrow \text{Dynamic Revealing MVP} \rightarrow \text{NOVA Interface} \rightarrow \text{Grid Interface} \rightarrow \text{Tensor Memory Extension} } $$ 第八與第九篇可以寫作，但不應阻止核心 MVP。 --- # 64. 系列總結 七篇核心文完成以下鏈條： $$ \boxed{ \text{外部注意力總論} } $$ $$ \downarrow $$ $$ \boxed{ \text{顯影、抑制、約束與路由} } $$ $$ \downarrow $$ $$ \boxed{ \text{AI—外掛閉環} } $$ $$ \downarrow $$ $$ \boxed{ \text{工作場與預算} } $$ $$ \downarrow $$ $$ \boxed{ \text{空間介面} } $$ $$ \downarrow $$ $$ \boxed{ \text{治理與權力} } $$ $$ \downarrow $$ $$ \boxed{ \text{統一系統與實驗} } $$ --- # 65. 結論 本文完成外部注意力場工程第一代統一架構與實驗框架。 外部注意力場工程的完整流程可表示為： $$ \boxed{ \text{總資訊與能力環境} \rightarrow \text{候選注意力場} \rightarrow \text{最小任務閉合工作場} \rightarrow \text{模型上下文} \rightarrow \text{模型—外掛閉環} \rightarrow \text{場補丁} \rightarrow \text{治理與驗證} \rightarrow \text{工作場更新} \rightarrow \text{介面與審計} } $$ 本文的核心工程原則為： $$ \boxed{ \text{Typed State} + \text{Patch-Based Update} + \text{Provenance} + \text{Version} + \text{Budget} + \text{Governance} + \text{Benchmark} } $$ 外部注意力場工程不應被理解為一個必然取代 RAG、長上下文或 Tool Agent 的龐大總架構。它的正當性必須來自可重現實驗： > 在相同模型、資料、工具與成本下，是否能更可靠地形成可延續工作場、保持來源與版本、控制工具閉環、保留反例、降低污染，並讓注意力裁剪可以被理解與治理。 若答案是否定的，系統應被簡化。 若答案是肯定的，EAFE 將可作為 AI 原生工作系統、長期研究代理、企業知識系統、程式工程代理、多代理協作與未來計算機宇宙管理的共同基礎層。 至此，外部注意力場工程前七篇核心系列完成第一階段封頂。 --- ## 附錄 A：最小實驗配置 ```json { "experiment": { "task": "long_project_recovery", "dataset": "eafe-bench-project-v1", "baseline": "B7", "model": "same-model-for-all-baselines", "budget": { "tokens": 64000, "tool_calls": 20, "human_reviews": 1 }, "modules": { "reveal": true, "suppress": true, "version_graph": true, "provenance": true, "closure": true, "reserve_budget": true, "governance_disclosure": true }, "metrics": [ "task_completion", "closure_rate", "source_recall", "version_purity", "open_node_retention", "rolling_continuity" ] } } ``` --- ## 附錄 B：MVP 工作場輸出 ```json { "dynamic_revealing_result": { "task": "恢復研究專案", "current_state": {}, "active_version": {}, "critical_evidence": [], "failed_paths": [], "open_nodes": [], "next_actions": [], "suppressed_scope": {}, "budget_remaining": {}, "provenance_graph": [], "ledger_head": "ledger-1024" } } ``` --- ## 附錄 C：核心七篇系統映射 ```text EAFE-01 外部注意力場總論 ↓ EAFE-02 EAFOS ↓ EAFE-03 GAALS ↓ EAFE-04 WFABE ↓ EAFE-05 SAIFE ↓ EAFE-06 EAGAL ↓ EAFE-07 EAFE-RA + EAFE-Bench + MVP ```