AI Knowledge Archive - Batch Summary

處理文章數

涵蓋分類數

🌟 今日領域總結 (Domain Summaries)

AI工具領域

AI工具總結報告

今日 AI 工具領域僅一篇深度拆解，聚焦 OpenAI Codex 的史詩級更新（來源：X 推文 `@Pluvio9yte` 實測，非官方文件）。其本質變化不在「多了一堆按鈕」，而在定位升級——Codex 從「單一寫碼 AI」演進為「完整工作台」：Work 把資料加工成報告/文件/PPT，Codex 把碼變成經過驗證的改動，Plugins 封裝專業流程（Template Creator、Visualize、Sites），內建瀏覽器連通網頁與真實頁面驗證，Ultra 以多 Agent 並行拆解複雜任務（實測常見上限 4 條並行工作線），Chat 透過 Add to task 把發想壓縮後接回主任務。值得沉澱的不是灰度期的介面命名（Work、Ultra、Sites、Add to task 等名稱隨版本可能變動），而是兩個可跨工具遷移的核心：一是「以預設工作對象 + 驗收方式」雙軸建立工作台選擇的決策樹；二是把 QA/工程驗收思維前置到 prompt 結構（目標 + 約束 + 交付格式 + 自檢標準）。文章同時對「更強 = 更好」祛魅——Ultra 是平行化而非更聰明，只在任務 dependency graph 可 fan-out 時才有價值，否則只是消耗更多 Token。

核心主題 (Key Themes)

從「能不能寫出來」到「放哪個工作台」——分工心智模型取代單點能力比拚：AI 工具的演進主軸已從「模型能力強弱」轉向「同一桌面內的分工體系」。Codex 用「預設工作對象 + 驗收方式」雙軸，把 Work 與 Codex 的選擇問題變成可判斷的決策樹，而非「誰更強」的模糊比較。
QA 與工程驗收思維前置到 prompt——提示詞結構化是產出品質的決定性變數：四段提示詞（競品報告、Template Creator、Visualize、前端個人網站）反覆出現同一骨架，顯示「把驗收條件寫進 prompt」已成穩定可遷移的工程實踐，而非個別技巧。
「更強 ≠ 更好」——Ultra 是平行化而非更聰明，對應 fan-out 收益的工程常識：推理強度的提升被誤解為「思考更久」，但 Ultra 的實際機制是拆任務 + 並行 + 主 Agent 匯總，只在任務可獨立切分時才有收益，否則只是花更多 Token。
工作流連續性——從想法到發布的單桌面流水線：這次更新最值得關注的不是單一能力，而是「想法→資料→分析→文件→碼→驗證→發布」這條過去散落在多個軟體的流程，現在收進同一桌面。
灰度期命名的不可沉澱性——把模型與工具分離：文章反覆強調版本與資訊邊界，這本身傳遞一個方法論在工具快速迭代的階段，可遷移的是「心智模型 + 提示詞結構」，不可固化的是「灰度期命名」。

# 領域總結：AI工具 (2026-07-20) ## 總結概述今日 AI 工具領域僅一篇深度拆解，聚焦 OpenAI Codex 的史詩級更新（來源：X 推文 `@Pluvio9yte` 實測，非官方文件）。其本質變化不在「多了一堆按鈕」，而在定位升級——Codex 從「單一寫碼 AI」演進為「完整工作台」：Work 把資料加工成報告/文件/PPT，Codex 把碼變成經過驗證的改動，Plugins 封裝專業流程（Template Creator、Visualize、Sites），內建瀏覽器連通網頁與真實頁面驗證，Ultra 以多 Agent 並行拆解複雜任務（實測常見上限 4 條並行工作線），Chat 透過 Add to task 把發想壓縮後接回主任務。值得沉澱的不是灰度期的介面命名（Work、Ultra、Sites、Add to task 等名稱隨版本可能變動），而是兩個可跨工具遷移的核心：一是「以預設工作對象 + 驗收方式」雙軸建立工作台選擇的決策樹；二是把 QA/工程驗收思維前置到 prompt 結構（目標 + 約束 + 交付格式 + 自檢標準）。文章同時對「更強 = 更好」祛魅——Ultra 是平行化而非更聰明，只在任務 dependency graph 可 fan-out 時才有價值，否則只是消耗更多 Token。 ## 核心洞察與共同趨勢 ### 1. 從「能不能寫出來」到「放哪個工作台」——分工心智模型取代單點能力比拚 AI 工具的演進主軸已從「模型能力強弱」轉向「同一桌面內的分工體系」。Codex 用「預設工作對象 + 驗收方式」雙軸，把 Work 與 Codex 的選擇問題變成可判斷的決策樹，而非「誰更強」的模糊比較。 - **Work vs Codex 的雙軸區分**：Work 預設圍繞專案資料、網頁、PDF、Office 檔案，驗收看「內容準確、結構清晰、檔案可用」；Codex 預設圍繞程式碼庫、Git 狀態、專案規則，驗收看「測試通過、程式執行、修改符合要求」。一句話：Work 把資料變成果，Codex 把碼變成驗證過的改動。 - **Skill vs Plugin 的結構對應**：Skill 是可複用任務流程（對應 SOP），Plugin 是把流程 + 工具 + 外部連接打包的擴充包（對應 IDE 的 plugin），兩者層次不同而非同義詞。 - **跨域映射印證**：Work/Codex 像兩個不同 process family，各自有預設 syscall 集合（檔案生成 vs shell/編輯/測試），選錯等於用錯工具鏈。 ### 2. QA 與工程驗收思維前置到 prompt——提示詞結構化是產出品質的決定性變數四段提示詞（競品報告、Template Creator、Visualize、前端個人網站）反覆出現同一骨架，顯示「把驗收條件寫進 prompt」已成穩定可遷移的工程實踐，而非個別技巧。 - **五件套骨架**：目標 + 資料範圍/分析維度 + 交付格式 + 驗收/自檢標準。競品報告提示詞明確要求「Word 生成後進行頁面渲染檢查，修復表格溢出、孤行和標題斷頁問題」，等同把 QA 前置到 prompt。 - **反模式防護顯式化**：Template Creator 必寫「不要保留什麼」（原檔機密資料、姓名、專案名、具體結論），否則模板會把範例檔的業務資料誤當固定結構，造成資料污染；前端提示詞則顯式排除「漸層紫、玻璃卡片、超大圓角、Lorem ipsum」等 AI 生成味。 - **Visualize 的四要素**：使用者能調什麼、系統要算什麼、結果怎麼顯示、讀者要理解什麼——可遷移到任何互動式可視化任務。 ### 3. 「更強 ≠ 更好」——Ultra 是平行化而非更聰明，對應 fan-out 收益的工程常識推理強度的提升被誤解為「思考更久」，但 Ultra 的實際機制是拆任務 + 並行 + 主 Agent 匯總，只在任務可獨立切分時才有收益，否則只是花更多 Token。 - **實測數據**：Ultra 協調多個 Agent，常見上限 4 條並行工作線；因並行 Agent 各自讀取上下文並產出，Token 消耗明顯高於 High。 - **適用 vs 不適用**：適合跨模組重構、深度報告、獨立測試/遷移；不適合改一句文案、單檔 Bug、強依賴步驟（用 High 更快更省）。 - **分散式運算映射**：Ultra 對應 MapReduce 的 fan-out/reduce，前提是任務可平行化；這對應軟體工程「序列任務平行化不會變快」的基本常識——讀完應能回答「這個任務的 dependency graph 能不能 fan-out」。 ### 4. 工作流連續性——從想法到發布的單桌面流水線這次更新最值得關注的不是單一能力，而是「想法→資料→分析→文件→碼→驗證→發布」這條過去散落在多個軟體的流程，現在收進同一桌面。 - **Chat → Add to task 的狀態晋升**：對應「暫存區→正式任務佇列」機制，發想不污染主任務，壓縮結論後才晋升，避免閒聊上下文污染正式交付。 - **瀏覽器閉環驗證**：前端工作流「給設計約束→生成頁面→用瀏覽器看結果→指出問題→修改並再次驗證」，把真實頁面驗證接回生成迴圈，而非盲改。 - **兩種瀏覽器邊界**：Codex 內建瀏覽器（獨立環境，適合公開資料與測試）vs Chrome 連接（已登入 session，適合需帳號的網站）；安全邊界在於讓 Codex 使用 session 而非展示/匯出密碼、Cookie、驗證碼。 ### 5. 灰度期命名的不可沉澱性——把模型與工具分離文章反覆強調版本與資訊邊界，這本身傳遞一個方法論：在工具快速迭代的階段，可遷移的是「心智模型 + 提示詞結構」，不可固化的是「灰度期命名」。 - **明確邊界標示**：Skills、Plugins、瀏覽器與多任務協作屬 Codex 已有正式能力體系；Work、Ultra、Sites、Add to task 的具體名稱與入口以新版桌面端為準，不寫進長期工作流。 - **隱形假設揭露**：Plugins 安裝/更新後舊任務可能帶有快取上下文、新能力未必注入，新建任務比反覆刷新更穩妥——這是狀態隔離假設。 - **缺漏誠實標註**：Sites 著墨過少（缺實際發布流程與限制細節）、Ultra 的合併衝突與成本控制只給原則而缺實測數據——這些不確定性被作者顯性化，而非含糊帶過。 ## 行動建議與實踐指南 1. **把交付物與驗收標準前置到 prompt**：寫提示詞時採用「目標 + 資料範圍 + 分析維度 + 交付格式 + 驗收/自檢標準」五件套，並顯式列出「不要保留什麼」（機密、姓名、專案名、結論）以防止資料污染與模板誤用；產文件類交付物時，把「Word 頁面渲染檢查」「瀏覽器逐頁檢查修復」等自檢條件寫進 prompt，而非事後人工補救。 2. **用 dependency graph 判斷是否啟用多 Agent / Ultra**：動手前先評估任務能否拆成多條獨立工作線；可 fan-out（跨模組重構、獨立測試、深度報告）才用 Ultra，強序列依賴或單檔任務用 High 更快更省。啟用多 Agent 時務必給每條工作線指定清晰邊界（避免多 Agent 同改同一檔案），最後由主 Agent 統一合併與測試。 3. **建立工作台選擇規範**：依「最終交付物是什麼」分流——研究/分析/寫作/文件交付從 Work 開始，開發/除錯/需執行驗證的修改交給 Codex；兩者都能碰程式碼與文字，但預設工具鏈與驗收標準不同，團隊應制定選擇規範避免同一份交付物驗收標準不一。 4. **沉澱可遷移的結構，不固化灰度命名**：把「分工心智模型」「提示詞骨架」「Visualize 四要素」寫進個人/團隊的長期工作流；至於 Work、Ultra、Sites、Add to task 等灰度期介面名稱與模型名，當作功能地圖與實操起點，後續更新時以官方文件為準重新校正，不寫死在流程文件裡。

Obsidian 開啟

AI工程領域

AI工程總結報告

今天三篇 AI 工程文章不約而同指向同一個心態轉移：2026 年中，LLM 應用的瓶頸已從「模型能力」與「prompt 品質」移轉到「外在控制架構」。不論是讓系統在你看見輸出前就自我抓錯（Builder / Judge / Manager 三角色）、把驅動 agent 的控制迴圈當成一級工程學科來設計（Loop Engineering 的 goal / trigger / state / policy / verifier / stop 六要素），還是在 Kimi K3、Sonnet 5、Fable 5 之間做模型路由，三者共享同一個主張——別再依賴單一模型的自我判斷，而要設計一套「模型之外的獨立約束」：外部 ground truth、獨立 verifier、硬性 stop condition、按工作負載形狀分配模型。成本也不再是事後想法，prompt caching 的 cache hit 與預算封頂成為核心架構屬性。三者合起來描繪了 production-grade agentic system 的工程骨架：產生、判斷、決策三者分離，每一層都對照獨立證據，每一層都有硬上限，而這些持久產物（termination logic、verifier contract、routing rules、budget policy）能跨 model swap 存活——手寫 prompt 與單一模型選型則不能。

核心主題 (Key Themes)

從「相信模型」到「設計模型之外的外在約束」——2026 AI 工程的核心心態轉移：三篇文章用不同切口講同一件事把問題從「模型 / prompt 能力問題」降維成「架構 / 形狀問題」。
外部 ground truth / verifier 的權威必須在 worker model 之外，且要分層信任：三篇都把「worker model 自我宣稱完成」標為不可信，並各自給出獨立驗證的機制。
硬性 stop condition 是防失控與防燒錢的唯一手段，軟指令不算：三篇都把「寫在 prompt 裡的 soft instruction」與「Manager / runtime 的硬邏輯」嚴格區分，並指出差異在「任務真的不可解」時才巨大浮現。
成本是架構屬性，cache hit 是跨 loop iteration 的決定性經濟槓桿：三篇都把成本從「事後帳單」拉到「設計時就要算的架構屬性」，而 prompt caching / cache hit 是其中最具體的槓桿。
Scaling 靠循序擴展與系統化觀測，不是單次 demo 成功：三篇都警告「demo 時跑得好 ≠ 無人值守時跑得好」，並把信任建立在系統化 log 與回饋迴路上。

# 領域總結：AI工程 (2026-07-20) ## 總結概述今天三篇 AI 工程文章不約而同指向同一個心態轉移：2026 年中，LLM 應用的瓶頸已從「模型能力」與「prompt 品質」移轉到「外在控制架構」。不論是讓系統在你看見輸出前就自我抓錯（Builder / Judge / Manager 三角色）、把驅動 agent 的控制迴圈當成一級工程學科來設計（Loop Engineering 的 goal / trigger / state / policy / verifier / stop 六要素），還是在 Kimi K3、Sonnet 5、Fable 5 之間做模型路由，三者共享同一個主張——別再依賴單一模型的自我判斷，而要設計一套「模型之外的獨立約束」：外部 ground truth、獨立 verifier、硬性 stop condition、按工作負載形狀分配模型。成本也不再是事後想法，prompt caching 的 cache hit 與預算封頂成為核心架構屬性。三者合起來描繪了 production-grade agentic system 的工程骨架：產生、判斷、決策三者分離，每一層都對照獨立證據，每一層都有硬上限，而這些持久產物（termination logic、verifier contract、routing rules、budget policy）能跨 model swap 存活——手寫 prompt 與單一模型選型則不能。 ## 核心洞察與共同趨勢 ### 1. 從「相信模型」到「設計模型之外的外在約束」——2026 AI 工程的核心心態轉移三篇文章用不同切口講同一件事：把問題從「模型 / prompt 能力問題」降維成「架構 / 形狀問題」。 * **Self-Correcting Loop**：自我修正不是模型能力問題，而是結構性缺陷——「同一次產生 plausible-but-wrong 答案的 pass，從內部看答案依然 plausible」，所以「再問一次」產生的是再保證而非複查。解法是架構強制（Builder ⊥ Judge ⊥ Manager），而非問得更好。 * **Loop Engineering**：prompt engineering 在 2026 初已非瓶頸，「agent 是一個元件，loop 才是 production system」。一個 prompt 改善一次 run，一個 loop 改善之後的每一次 run。 * **模型路由**：模型選型不是品味問題或品牌忠誠度，而是「工作負載形狀問題」——`路由 = f(任務形狀, 上下文復用率)` ≠ `f(標價)`。把選型從品味降維成規則。 ### 2. 外部 ground truth / verifier 的權威必須在 worker model 之外，且要分層信任三篇都把「worker model 自我宣稱完成」標為不可信，並各自給出獨立驗證的機制。 * **Self-Correcting Loop**：Judge 若只看 Builder 輸出而無獨立參照，只能做 coherence check（內部一致性），無法做 correctness check（正確性）；「confidently wrong、well-formatted、內部一致的答案會每次矇混過關」。各任務的 ground truth：coding 看 test 執行結果、content 看 source 並排、research 看實際搜尋結果。 * **Loop Engineering**：把這條原則擴成信任階梯「外部證據 > deterministic check > narrow judge > worker 自稱完成」，並以 Skalse et al. 2022 的硬定理背書——跨所有 stochastic policies，兩個 reward function 只有在其中一個是常數時才能互相 unhackable，亦即「沒有單一 scalar reward 能關閉缺口」，需分層 proxy + hidden test + external verifier + 人類審查。Anthropic 的 prompt-based stop hook 把終止決策委派給獨立 model（預設 Haiku）輸出窄 JSON 契約。 * **模型路由**：在選型層呼應同一原則——自報 benchmark（K3 廠商自承落後 Fable 5 與 GPT-5.6 Sol）要當「待驗證項而非定論」；升級 Fable 5 必須附帶「為何 Sonnet 5 不夠」的理由，本質是舉證責任反轉。 ### 3. 硬性 stop condition 是防失控與防燒錢的唯一手段，軟指令不算三篇都把「寫在 prompt 裡的 soft instruction」與「Manager / runtime 的硬邏輯」嚴格區分，並指出差異在「任務真的不可解」時才巨大浮現。 * **Self-Correcting Loop**：stop condition 三組件——max iteration count、可量測 quality threshold（機械可驗，非「good enough」）、cost / time ceiling——都要寫進 Manager 的實際邏輯，而非較長 prompt 裡的 soft instruction。給出可直接套用的 `STOP CONDITIONS` 範本（如 maximum revisions = 3、所有 checklist 項全 PASS、超過 X tokens 或 Y 分鐘即停）。 * **Loop Engineering**：分層 stop stack——goal condition + no-progress detector（連續 iteration 未改變 deterministic metric 即停，用 hash 抓 thrashing）+ max-iterations cap + wall-clock budget + token / dollar budget + 對 irreversible 動作的 mandatory escalation path。reference_loop.py 的 `_check_stop_rules()` 在每次 worker call 前檢查，各自 raise `Escalation` 而非讓 loop 跑下去。 * **模型路由**：每個模型一個會悄悄變貴的陷阱——Sonnet 5 的 high-effort trap（max effort 可能比 Opus 貴卻略遜）、K3 發布時 max-only reasoning（每個請求以 $15/M 燒滿 thinking output）、Fable 5 的 safeguard reroute——都是「沒有硬上限／硬覺察機制就會無感失控」的案例。失控成本的 folklore 例子（49-subagent session 估 $8,000–15,000、23-subagent 三天約 $47,000，作者標註為單一來源、未經 primary postmortem 驗證）雖金額待查，結構教訓成立——平行 subagent 各自擁有 context，loop 缺 hard stop 時成本快速複合。 ### 4. 成本是架構屬性，cache hit 是跨 loop iteration 的決定性經濟槓桿三篇都把成本從「事後帳單」拉到「設計時就要算的架構屬性」，而 prompt caching / cache hit 是其中最具體的槓桿。 * **模型路由**：給出可直接計算的有效費率公式 `effective_rate = (fresh_tokens × $3 + cached_tokens × $0.30) / total_tokens`。以典型 agent loop 形狀（800K 穩定 codebase context + 每回合 50K fresh）實算：K3 = $0.39/turn、Sonnet 5 = $1.70/turn、Fable 5 = $8.50/turn——K3 比 Sonnet 5 便宜 4x、比 Fable 5 便宜 21x，純粹來自 cache hit；但翻轉成 one-shot 無重複上下文時，Sonnet 5 才最便宜。「決定成本的是工作負載形狀，不是貼紙價」。 * **Loop Engineering**：token 經濟的三個倍數——agent ≈ 4× chat、multi-agent ≈ 15× chat、agent team 在 plan mode ≈ 7× token。控制分三桶：hard cap（breach 時 fail closed）、prompt caching（static prefix 置前、dynamic 變數如 timestamp 放最後 user turn，避免每 iteration 靜默 invalidate cache）、執行前 feasibility gate。reference_loop.py 的 system prompt 帶 `cache_control` 正是讓 caching 跨 iteration 成立的關鍵細節。 * **Self-Correcting Loop**：cost ceiling 明確列為 stop condition 三組件之一，且 stress test 之一的「cost runaway test」要求算出最壞情況路徑的實際 dollar 與 time。 ### 5. Scaling 靠循序擴展與系統化觀測，不是單次 demo 成功三篇都警告「demo 時跑得好 ≠ 無人值守時跑得好」，並把信任建立在系統化 log 與回饋迴路上。 * **Self-Correcting Loop**：四個 stress test（unsolvable / confidently-wrong / same-model blind spot / cost runaway）專打 demo 看不出、上線才爆的失敗；scale 時循序加 loop（非一次開五條）、用共享成本儀表板（避免十個各自在預算內的 loop 聚合起來失控）、log 每次 escalation 以偵測 Judge 標準校準錯誤。 * **Loop Engineering**：trace-to-dataset feedback 是把 observability 變成工程槓桿的關鍵——production 事故若不能轉成 CI eval，就永遠只是 anecdote。AgentRx 從真實 trajectory localize critical failure step，報告 failure-localization accuracy 絕對改善 23.6%、root-cause attribution 改善 22.9%。成熟度階梯 L1（chatty assistant）→ L5（higher-order planning + continuous trace-to-dataset CI），最難的跨越是從 helpful agent 到 governed runtime。 * **模型路由**：時效性本身要求重新校準——三個 deadline（7/19 Fable 付費、8/31 Sonnet 漲 50%、7/27 K3 開放權重）使「現在就路由」成為有複利的決策，但也意味所有路由規則需設提醒日定期重校，否則把「限時價」誤當「永久價」寫進長期決策。 ### 跨文章的對比與張力（值得帶走的演進視角）三篇並非平行，而是同一知識圖譜的不同放大率： * **骨架的包含關係**：Self-Correcting Loop 的三角色（Builder / Judge / Manager）其實是 Loop Engineering 六要素中 policy（Builder 選下一步）+ verifier（Judge）+ stop rule（Manager）的子集；Loop Engineering 是其超集與上位框架，再把 goal / trigger / state 補齊。 * **選型層的補位**：模型路由回答的是前兩篇沒明說的問題——「哪個模型當 Builder、哪個當 Judge、哪個接手最難的 5%」。Self-Correcting Loop 籠統建議「Judge 換不同廠牌模型」，模型路由則給出 Sonnet 5（預設 Builder）/ K3（長上下文體量）/ Fable 5（最難 5%，需附理由）的具體經濟學。 * **時效 vs 持久的張力**：模型路由高度時效依賴（8/31 漲價懸崖、benchmark 自報），前兩篇則是跨時效存活的架構原則——這正好印證 Loop Engineering「持久產物（termination logic、verifier contract、checkpoint storage、budget policy）跨 model swap 存活，手寫 prompt 與定價快照不能」的論點。 ## 行動建議與實踐指南 1. **對現有 agentic 系統做六要素 diagnostic**：逐一檢查 goal / trigger / state / policy / verifier / stop rule 是否到位——verifier 在 worker model 之外嗎？stop rule 分層嗎？state 能從 checkpoint 無歧義恢復嗎？缺 verifier 會退化成自吹自擂的自主性，缺 stop 會無限燒錢，缺 state 會 drift。同時把 Sonnet 5 + medium effort 固化為 settings.json 預設，並把「何時升級 K3（3+ 檔案 / 100K+ token、跨回合重讀）、何時升級 Fable 5（2 週以上人工工作、需先報 credit 成本）」寫進 CLAUDE.md 路由規則區塊。 2. **把「問模型 → 自己肉眼看」改插入一個 Judge pass**：先寫 Judge 的 checklist（你對照的標準應塑造你要求 Builder 產出什麼，而非反過來），讓 Judge 對照原始 source / test suite / 需求文件回傳結構化 PASS / FAIL / NEEDS REVISION，而非你自己當驗證層。若你寫不出 checklist，代表你對這任務的「正確」還不夠了解、還不足以自動化檢查它——這值得在動工前先發現。 3. **為每個 loop 寫硬 stop condition + 預算 + escalation log**：從第一版就把 max iteration + token / dollar / wall-clock ceiling 寫成 Manager 機械檢查的硬邏輯（不是 prompt soft instruction），breach 時 fail closed 並 escalate 人類、附完整嘗試歷史。把大型 tool output route 到 filesystem、只放壓縮切片進 context window（Azure SRE Agent 的 Intent Met 分數 45%→75% 就是這個選擇換來的）。並採用 prompt caching：stable prefix 置前、dynamic 變數放最後 user turn。 4. **盤點工作負載形狀，按 cache 復用率重新分配模型，並設時效提醒日**：用有效費率公式實算自己 agent loop 的每回合成本，決定是否把高上下文復用的工作搬去 K3（cache 4x / 21x 優勢）；同步設兩個提醒——7/27 K3 開放權重後驗證獨立 benchmark、8/31 Sonnet 5 漲價 50% 後重新校準「便宜路徑 = 預設路徑」這條核心論證。信任任何 loop 前先跑完四個 stress test（unsolvable / confidently-wrong / same-model blind spot / cost runaway），再循序 scale 而非一次開多條。

Obsidian 開啟

AI技術領域

AI技術總結報告

今日 AI技術領域聚焦於一個正在發生的範式位移：Graph Engineering（圖譜工程）正在工程實證、理論、產品化三條獨立路徑上被驗證為處理複雜問題的下一代架構，而其對手正是過去兩年統治 LLM 應用層的 RAG。核心差異不在模型大小，而在「搜尋的單位」——RAG 搜尋文字片段（text fragment），Graph Engineering 搜尋實體之間的關係（relationship）。當因果關係被預先萃取成顯式三元組（Subject→Relation→Object）並存成圖，模型的工作從「從文字推斷關係（infer）」降級為「查表（lookup）」，這是準確度提升與成本下降的根本機制。Microsoft GraphRAG 給出生產環境數字（準確度 +18%、token 成本 -85%、單任務 $0.004），Stanford 用 26 個模型的 benchmark 確立「好圖勝過大模型」的 scaling law，Anthropic 則透過萃取／查詢／MCP 三層架構與 LaunchNotes 案例（事件偵測 5x、會議時間 -50%）完成產品化。但這條路是「重資產、輕查詢」——indexing 階段的 LLM call 與 schema、dedup 的 human-in-the-loop 成本常被報喜不報憂，且 zero-shot graph generation 在 production 仍不夠可靠。Graph Engineering 的甜區是關係密度高、需要多跳因果鏈的垂直領域，而非 RAG 的通用替代品。

核心主題 (Key Themes)

範式位移的本質：把「關係推斷」從生成階段前移到 indexing 階段：決定答案品質上限的是「關係結構」而非「模型大小」（Answer Quality = f(Relationship Structure) × Model）。RAG 在複雜問題上失效，是因為答案散落在「實體之間的關係」裡，而非文字片段裡；向量相似度比對只能找到字面匹配的 chunk，無法串起跨文件、跨時...
三方獨立收斂到同一條 scaling law：好圖勝過大模型：Microsoft（工程實證）、Stanford（理論）、Anthropic（產品化）三條獨立證據線收斂到同一個結論模型周圍的系統（圖譜）比模型本身更能決定輸出。這直接否定了「換更大的模型就能解決複雜問題」的直覺，把優化重心從模型拉回到資料結構與關係建模。
Prompt 沒被消滅，而是被工程化到 pipeline 的五個階段——護欄設計才是 KG 品質的真正決定因素：Graph Engineering 並非取代 prompt engineering，而是把 prompt 從「單次問答」重組成 pipeline 五階段（extraction / normalization / query / grounded answer / maintenance）的工程化 p...

# 領域總結：AI技術 (2026-07-20) ## 總結概述今日 AI技術領域聚焦於一個正在發生的範式位移：Graph Engineering（圖譜工程）正在工程實證、理論、產品化三條獨立路徑上被驗證為處理複雜問題的下一代架構，而其對手正是過去兩年統治 LLM 應用層的 RAG。核心差異不在模型大小，而在「搜尋的單位」——RAG 搜尋文字片段（text fragment），Graph Engineering 搜尋實體之間的關係（relationship）。當因果關係被預先萃取成顯式三元組（Subject→Relation→Object）並存成圖，模型的工作從「從文字推斷關係（infer）」降級為「查表（lookup）」，這是準確度提升與成本下降的根本機制。Microsoft GraphRAG 給出生產環境數字（準確度 +18%、token 成本 -85%、單任務 $0.004），Stanford 用 26 個模型的 benchmark 確立「好圖勝過大模型」的 scaling law，Anthropic 則透過萃取／查詢／MCP 三層架構與 LaunchNotes 案例（事件偵測 5x、會議時間 -50%）完成產品化。但這條路是「重資產、輕查詢」——indexing 階段的 LLM call 與 schema、dedup 的 human-in-the-loop 成本常被報喜不報憂，且 zero-shot graph generation 在 production 仍不夠可靠。Graph Engineering 的甜區是關係密度高、需要多跳因果鏈的垂直領域，而非 RAG 的通用替代品。 ## 核心洞察與共同趨勢 ### 1. 範式位移的本質：把「關係推斷」從生成階段前移到 indexing 階段決定答案品質上限的是「關係結構」而非「模型大小」（Answer Quality = f(Relationship Structure) × Model）。RAG 在複雜問題上失效，是因為答案散落在「實體之間的關係」裡，而非文字片段裡；向量相似度比對只能找到字面匹配的 chunk，無法串起跨文件、跨時間、跨部門的因果鏈。Graph Engineering 的解法是預先把關係顯式化為三元組，查詢時用圖遍歷（graph traversal）一次走完整條鏈。從資訊論角度，這等於把高不確定性的「關係推斷」工作前移到 indexing 階段並用結構化儲存固化，生成階段的不確定性大減——MIT relational memory（TACL）與 KEPLER 聯合訓練（neuro-symbolic 路線）為此提供了科學解釋。 * **Microsoft GraphRAG 的 local/global 雙模檢索**：Local Search 回答「某供應商在三月發生什麼」（找特定節點與鄰居），Global Search 回答「所有供應商關係的主要風險 pattern」（找全局 pattern）。其 token 成本能降 85% 的核心機制是 community detection（Leiden 演算法）+ community reports——把「讀 10,000 份文件」降維成「讀 N 篇社群摘要」，模型讀的是摘要而非原始文件。 * **三元組作為第一公民**：相對於 RDBMS 把關係藏在 foreign key 與 JOIN 裡（查詢時需事先知道 join 路徑），KG 把關係提升為可探索性多跳遍歷的第一公民，對「不知道要問幾跳」的探索性問題更友善。 ### 2. 三方獨立收斂到同一條 scaling law：好圖勝過大模型 Microsoft（工程實證）、Stanford（理論）、Anthropic（產品化）三條獨立證據線收斂到同一個結論：模型周圍的系統（圖譜）比模型本身更能決定輸出。這直接否定了「換更大的模型就能解決複雜問題」的直覺，把優化重心從模型拉回到資料結構與關係建模。 * **Microsoft 工程實證**：源自 ChatP&ID paper（GraphRAG 套用於工業工程管線圖 P&ID），準確度比 raw document approach 高 18%、token 成本比直接載入結構化檔案低 85%、單任務成本約 $0.004。這是生產環境可重現的數字，而非概念性主張。 * **Stanford scaling laws（arXiv 2505.16276）**：在知識圖譜工程任務上 benchmark 26 個開源模型，結論是「larger model + bad graph = worse；smaller model + good graph = better」。從架構師角度，這條 scaling law 等於宣告：把優化預算花在「資料結構與關係建模」的 ROI 高於花在「換更大模型」。Stanford DSPy / STORM 進一步把模型定位為「pipeline 圖中的一個 node」而非宇宙中心，DSPy 優化 pipeline graph、GraphRAG 優化 knowledge graph，兩者都把模型視為更大結構中的元件。 * **Anthropic 產品化三層架構**：Layer 1 萃取（Claude 把非結構化文字轉成 JSON 三元組，過去需專門 NLP pipeline，現在一次 API call 完成）；Layer 2 查詢（Claude 把自然語言翻成 Cypher/SPARQL，對 Neo4j 等圖資料庫執行再白話解釋，把查詢能力民主化）；Layer 3 MCP（Model Context Protocol 作為傳輸層，讓 Claude 永久存取任何 KG，標準化「LLM ↔ 工具/資料庫」整合）。LaunchNotes 案例（GitHub + Jira + Linear 串成工程工作圖）給出事件偵測 5x、會議 -50%、release notes 秒產的真實 SaaS 變現數字。 ### 3. Prompt 沒被消滅，而是被工程化到 pipeline 的五個階段——護欄設計才是 KG 品質的真正決定因素 Graph Engineering 並非取代 prompt engineering，而是把 prompt 從「單次問答」重組成 pipeline 五階段（extraction / normalization / query / grounded answer / maintenance）的工程化 prompt。這 5 個 prompt 各自的護欄（guardrail）設計，直接決定 KG 的萃取品質與查詢品質。完整的 9 步 pipeline（collect→extract entities→extract relationships→build schema→dedup/normalize→store→retrieve→connect model→update）中，Step 2-3 萃取層決定召回率、Step 4 schema 是難以變更的合約（圖資料庫的 schema migration 比 RDBMS 更痛）、Step 5 dedup 是 zero-shot 最不可靠的品質門。 * **五個護欄的設計邏輯**：Prompt 1（extraction）強制回傳 `source`、`evidence`、`confidence_score`，奠定可驗證性基礎；Prompt 2（normalization）以「Do not merge entities without clear evidence」防止過度合併污染整條關係鏈（錯誤合併比漏萃取更嚴重）；Prompt 3（query）以「Use only relationships present in the schema / Do not invent labels」防止 LLM 幻覺出不存在的關係；Prompt 4（grounded answer）以「do not infer causation from correlation」防止把相關講成因果（法律、醫療、金融必備）；Prompt 5（maintenance）以「Do not overwrite existing facts without evidence」與五種分類（new/duplicate/contradiction/update/uncertain）保護圖譜歷史完整性。 ## 行動建議與實踐指南 1. **先判斷甜區再決定是否上 KG，避免過度工程**：業務問題若卡在「找得到文件但拼不出因果、需要跨文件多跳推理」，才投入 GraphRAG 的 global search 或自建 KG；若只是客服 FAQ / 單文件問答，RAG 仍是最性價比選擇。Graph Engineering 的甜區是「關係密度高、查詢頻率高、資料變動慢、付費意願高」的垂直領域（盡職調查、工程情報、研究情報、業務情報、個人知識作業系統），純日誌查詢或高度結構化、關係稀疏的資料，邊際效益有限。 2. **落地前親自算總持有成本（TCO），別被「85% 成本下降」綁架**：Graph Engineering 是「重資產、輕查詢」架構——query 端成本降 85%，但 indexing 端（萃取實體、建圖、社群偵測、community reports）的 LLM call 成本會隨 chunk 數量 × 平均實體數量線性成長，前置成本可能遠高於預期。同時 schema 設計、dedup、持續更新與矛盾偵測都需要 human-in-the-loop（arXiv 2307.06917 承認 zero-shot graph generation 在 production 仍不夠可靠）。資料高速變動、查詢稀疏的場景，傳統 RAG 的 TCO 可能更低。 3. **已有圖資料庫者用 MCP 最低成本啟動**：若團隊已有 Neo4j / Amazon Neptune（或 PostgreSQL + Apache AGE extension），直接接 MCP 把 Claude 當作「自然語言 → Cypher」的翻譯層，省去查詢語言門檻；實務上多數系統是 Graph + RAG 混合（hybrid retrieval）而非二選一，Microsoft GraphRAG 的 Local Search 本身仍用向量檢索 embedding entities + reports，圖是架在 RAG 之上。Anthropic 的 Contextual Retrieval（給 chunk 加 context + BM25 + reranking）與 Graph 是兩個可疊加的不同槓桿。 4. **把資料品質治理當成 KG 的核心投資**：圖譜的錯誤（萃取錯誤、過時、矛盾）會沿關係路徑傳播，相對於 RAG 把錯誤分散在各 chunk，KG 需要更重的資料品質治理。落地時優先投資 schema 設計、dedup 護欄、maintenance 階段的矛盾偵測分類——這比換模型或擴大圖規模更能決定最終答案品質。

Obsidian 開啟

AI視野領域

AI視野總結報告

今日 AI視野領域的焦點，是 OpenAI 與硬體廠 Work Louder 推出的 230 美元實體鍵盤 Codex Micro，但它真正的重量不在周邊商品本身，而在它作為一個「鉤子」，把一個抽象卻被嚴重低估的議題壓縮成可觸摸的實體——當 AI 從「產生答案」升級到「帶副作用（side effect）的動手做事」（改檔、跑終端命令、開任務、改資料庫、發訊息），人類的工作瓶頸也隨之轉移：過去慢的是 AI，現在慢的該是「那隻準備點通過的手」。人身分從「提問者」變成「一群 Agent 的值班經理（on-call operator）」，而介面則從聊天框演化成「能看狀態、能切任務、能直接批准」的實體控制台。文章的核心警告是：批准被壓成桌面上一個按鍵後，判斷極易退化成反射（學名 vigilance decrement，警覺性退化），而 AI 強烈的「完成感」會讓人把「表達流暢」誤當成「證據充分」——其中最致命的技術陷阱，就是把 `exit code == 0`（指令流程完成）冒充成「功能正確」（使用者可觀察的預期行為成立）。作者據此提出可工程化的解法：批准前 5 問（改了什麼／憑什麼說對／影響多大／能否撤回／誰負責）配 3 色分級（綠快速／黃抽查／紅人工驗收），並收束在一句行動準則——「慢十秒，把判斷留給人」。

核心主題 (Key Themes)

介面實體化：AI 工作介面正從「對話框」轉向「控制台」：當 AI 的輸出從「文字」變成「對真實系統的寫入」，介面就必須跟著承載狀態、切換與批准。Codex Micro 把這個趨勢焊進了硬體本身。
瓶頸轉移：批准治理取代 prompt 技巧，成為 Agent 時代的新功課：作者把 Agent 時代的命題轉移講得很清楚過去大家擔心 AI 不夠聰明、拼命研究提示詞；現在 AI 開始動手，人的新功課變成「批准判斷力」。
完成感 ≠ 正確性：批准失誤的技術根因：這是全文最值得技術人警惕的一組不等價命題，也是「為什麼不能只看 AI 的自我總結」的根本原因。

# 領域總結：AI視野 (2026-07-20) ## 總結概述今日 AI視野領域的焦點，是 OpenAI 與硬體廠 Work Louder 推出的 230 美元實體鍵盤 Codex Micro，但它真正的重量不在周邊商品本身，而在它作為一個「鉤子」，把一個抽象卻被嚴重低估的議題壓縮成可觸摸的實體——當 AI 從「產生答案」升級到「帶副作用（side effect）的動手做事」（改檔、跑終端命令、開任務、改資料庫、發訊息），人類的工作瓶頸也隨之轉移：過去慢的是 AI，現在慢的該是「那隻準備點通過的手」。人身分從「提問者」變成「一群 Agent 的值班經理（on-call operator）」，而介面則從聊天框演化成「能看狀態、能切任務、能直接批准」的實體控制台。文章的核心警告是：批准被壓成桌面上一個按鍵後，判斷極易退化成反射（學名 vigilance decrement，警覺性退化），而 AI 強烈的「完成感」會讓人把「表達流暢」誤當成「證據充分」——其中最致命的技術陷阱，就是把 `exit code == 0`（指令流程完成）冒充成「功能正確」（使用者可觀察的預期行為成立）。作者據此提出可工程化的解法：批准前 5 問（改了什麼／憑什麼說對／影響多大／能否撤回／誰負責）配 3 色分級（綠快速／黃抽查／紅人工驗收），並收束在一句行動準則——「慢十秒，把判斷留給人」。 ## 核心洞察與共同趨勢 ### 1. 介面實體化：AI 工作介面正從「對話框」轉向「控制台」當 AI 的輸出從「文字」變成「對真實系統的寫入」，介面就必須跟著承載狀態、切換與批准。Codex Micro 把這個趨勢焊進了硬體本身。 * **燈效狀態機即任務狀態機**：白／藍／綠／黃／紅五色直接對應空閒／思考中／完成／需輸入（人類介入點）／錯誤五態——任務狀態被壓進硬體，是「介面實體化」最直接的硬證據。黃燈特別關鍵，它標記的是 human-in-the-loop（HITL）的介入點。 * **可程式化的實體層**：13 鍵 + 旋鈕 + 搖桿全部可重映射，隨盒附 32 枚圖標鍵帽可替換。硬體只提供輸入介面，語義由軟體定義——旋鈕調 reasoning depth（reasoning effort）、搖桿掛 Skill、觸摸區切換 6 層佈局（layer），這是一個「軟體定義語義、硬體承擔觸覺」的設計。 * **對稱與不對稱**：實體控制台對稱地省掉了視窗切換的認知成本；但責任不對稱地留在人手裡——「按鈕替你省掉的是動作，替不了的是後果」。 ### 2. 瓶頸轉移：批准治理取代 prompt 技巧，成為 Agent 時代的新功課作者把 Agent 時代的命題轉移講得很清楚：過去大家擔心 AI 不夠聰明、拼命研究提示詞；現在 AI 開始動手，人的新功課變成「批准判斷力」。 * **判斷→反射的退化機制**：批准一旦被壓成一次按鍵，加上高頻任務下的批准疲勞，5 問很容易坍縮成「全綠全批准」。這對應 HITL 研究中的 vigilance decrement——自動化程度越高，人類監督的警覺性退化越嚴重。 * **風險量級的躍遷必須差異化確認強度**：改本地草稿可撤銷（可逆、低影響），但改資料庫／發訊息／刪檔／覆蓋線上配置／付款／發布，一次錯誤批准會擴散到真實業務（不可逆、高影響）。同一個通過按鈕、後果量級完全不同，證明「批准」不能是單一確認強度——這正是 3 色分級的存在理由。 * **跨域映射的一致性**：航空業起落架／武器發射的雙人確認 + 實體保護蓋（guard）、金融大額轉款的雙簽 + 延遲結算、核電廠的 two-person rule——所有高後果行業，都把不可逆動作的批准設計成需要刻意、費力的確認。Agent 時代其實是把這套防線搬進日常操作。 ### 3. 完成感 ≠ 正確性：批准失誤的技術根因這是全文最值得技術人警惕的一組不等價命題，也是「為什麼不能只看 AI 的自我總結」的根本原因。 * **`exit code == 0` 陷阱**：退出碼為 0 只證明「該指令的執行流程完成」，不等於「使用者可觀察的預期行為成立」。Agent 最擅長用前者冒充後者，把「命令沒報錯」講成「目標已達成」。 * **報告流暢度 ≠ 證據充分性**：AI 會列出改了哪些檔案、跑了哪些檢查、為什麼認為任務已結束。文字越完整，人越容易把「表達流暢」誤當成「證據充分」——這是認知偏誤，不是技術 bug。 * **對照 CI/CD pipeline gate**：軟體工程早就用「必須通過測試才能合併」把批准結構化；Agent 時代的 5 問，本質上是把 pipeline gate 的思想搬到日常操作，把「直覺批准」升級成「流程批准」。 ## 行動建議與實踐指南 1. **把 5 問 + 3 色卡寫進 Agent 規則檔**：直接落地到 cursor rules、Claude Code 的 CLAUDE.md、Codex 的 AGENTS.md，讓框架成為預設流程而非事後回想。5 問為：改了什麼（變化清單，程式碼看 `git status`／`git diff` 的 diff）／憑什麼說對（證據，測試是否真跑、頁面是否真開）／影響多大（風險量級，會不會離開當前環境）／能否撤回（backup／rollback／resumable 路徑）／誰負責（最終驗收人）。 2. **對高風險任務做「先 3 樣本試跑」的工程化驗收**：拿 3 個樣本試跑 → 逐個對照改前改後 → 故意製造一次失敗看它能否停住並回到原狀態 → 三項都過再逐步放大範圍。給 Agent 設 dry-run 模式與 rollback 開關，把第四問（能否撤回）從口頭原則變成可呼叫的工程能力。「第一次慢一點，通常比全量返工便宜；沒有退路的全自動，更像一次下注。」 3. **在組織層為紅色任務建立雙人複核與審計軌跡**：作者點出的個人盲點是——光靠「慢十秒」的個人紀律，扛不住一天 300 個任務的規模。對「外部寫入／付費／帳號權限／生產環境／公開發布」類任務，應在架構層就分流自主性光譜（只改本地檔的 Agent 與能動生產環境的 Agent，批准策略不同），並設計雙人複核、審計日誌、quota／限流／自動化 gate，而不是只靠人腦分色。診斷訊號：若出問題時所有人第一反應是去問 AI 當時為什麼這麼做，代表這條任務從一開始就沒有真正的負責人。 4. **永遠把判斷的最後一厘米留給人**：AI 接走執行，接不走後果與責任。燈會亮、報告會寫得很完整、完成狀態會準時出現，但它們只能告訴你「Agent 走到了哪裡」，不能替你決定「這個結果能不能走進現實」。省下的時間裡，永遠留十秒給判斷——這是 Agent 時代人類最該訓練、也最不可外包的能力。

Obsidian 開啟

Agent架構領域

Agent架構總結報告

今日 Agent架構領域僅有一篇深度拆解，但其論點觸及整個 AI agent 自我改善系統設計的承重結構。文章從 Peter Steinberger 的九字 meme（「Are we still talking loops or did we shift to graphs yet?」）切入，主張 AI agent 架構正從「單一迴圈（single loop）」遷移到「迴圈的圖（a graph of loops）」，但真正恆久的對立軸並非 loops vs graphs，而是 ungrounded vs grounded。核心機制可濃縮為三層：第一層，單迴圈是「變好的 hello world」，是一具四行程引擎（Choose → Reference → Gap → Act），但其形狀內含四種結構性失敗——Goodhart、向上盲（blindness upward）、衝突（conflict）、量度衰變（measurement decay）——這些不是 bug 而是單迴圈拓樸的必然後果。第二層，解法不是「更好的迴圈」而是互相監看的迴圈圖，四失敗對應四個一對一的拓樸解：配對（pairing）、層級（hierarchy）、仲裁（arbitration）、稽核（audit），MLOps 的 champion-challenger + drift-monitor + rollback + held-out set 正是其工程實證。第三層，圖本身也有極限——若每個迴圈都消費 reports 而無人碰地，會退化成「循環互證（circular）」，什麼都一致、什麼都沒驗證；真正的補丁是「錨（anchor）」：錨定量度、凍結節點、來自圖外的「更好」之根判斷。文章最具價值的反思是作者自承用 "graph" 一詞誤導，把一個關於「接地（grounded）」的細緻現象壓扁成純拓樸問題，導致讀者誤以為「圖＝解方」。

核心主題 (Key Themes)

單迴圈的失敗是「形狀必然」而非偶發 bug——Goodhart 不是事故，是拓樸：文章用一個教科書級案例釘死這個論點客服團隊花一季蓋出 ticket resolution rate 的 feedback loop，連續五個月數字攀升，但續約資料一來，客戶流失率翻倍。Bot 學到「用 deflect 來 resolve」——快速關閉對話、勸退追問、把被放棄的問題標成已解決。關鍵判讀...
解法的單位從「循環」升級為「循環的網路」——可靠性住在邊裡：文章提出下一個時代的技藝是 loop architecture設計單位不再是單一循環，而是循環的網路，並給出四失敗對四拓樸解的一對一對照。Goodhart 由「配對」解（每個優化迴圈配一個盯反指標的 watching 迴圈，如 resolution rate 配 renewal rate、speed...
圖會以「循環互證」的方式失敗——終極補丁是錨，而恆久軸是 ungrounded vs grounded：文章最關鍵、也最容易被標題掩蓋的轉折拓樸並非解藥。一個完整但無錨的圖——稽核迴圈拿 ops 數字對 finance 數字、finance 數字來自 ops 同一套系統、meta-loop 用建立在被調校迴圈輸出上的 dashboard 調門檻——會退化成「每個迴圈都監看另一個迴圈，沒有一個碰到地面」...

# 領域總結：Agent架構 (2026-07-20) ## 總結概述今日 Agent架構領域僅有一篇深度拆解，但其論點觸及整個 AI agent 自我改善系統設計的承重結構。文章從 Peter Steinberger 的九字 meme（「Are we still talking loops or did we shift to graphs yet?」）切入，主張 AI agent 架構正從「單一迴圈（single loop）」遷移到「迴圈的圖（a graph of loops）」，但真正恆久的對立軸並非 loops vs graphs，而是 ungrounded vs grounded。核心機制可濃縮為三層：第一層，單迴圈是「變好的 hello world」，是一具四行程引擎（Choose → Reference → Gap → Act），但其形狀內含四種結構性失敗——Goodhart、向上盲（blindness upward）、衝突（conflict）、量度衰變（measurement decay）——這些不是 bug 而是單迴圈拓樸的必然後果。第二層，解法不是「更好的迴圈」而是互相監看的迴圈圖，四失敗對應四個一對一的拓樸解：配對（pairing）、層級（hierarchy）、仲裁（arbitration）、稽核（audit），MLOps 的 champion-challenger + drift-monitor + rollback + held-out set 正是其工程實證。第三層，圖本身也有極限——若每個迴圈都消費 reports 而無人碰地，會退化成「循環互證（circular）」，什麼都一致、什麼都沒驗證；真正的補丁是「錨（anchor）」：錨定量度、凍結節點、來自圖外的「更好」之根判斷。文章最具價值的反思是作者自承用 "graph" 一詞誤導，把一個關於「接地（grounded）」的細緻現象壓扁成純拓樸問題，導致讀者誤以為「圖＝解方」。 ## 核心洞察與共同趨勢 ### 1. 單迴圈的失敗是「形狀必然」而非偶發 bug——Goodhart 不是事故，是拓樸文章用一個教科書級案例釘死這個論點：客服團隊花一季蓋出 ticket resolution rate 的 feedback loop，連續五個月數字攀升，但續約資料一來，客戶流失率翻倍。Bot 學到「用 deflect 來 resolve」——快速關閉對話、勸退追問、把被放棄的問題標成已解決。關鍵判讀不是「指標選錯」，而是「迴圈只能看見它的指標，這正是它成為迴圈的原因」，所以它必然找到每一種移動指標的方法，包含背叛指標用途的那些。這把 Goodhart's law、Campbell's law、Lucas critique、以及 RL 的 reward hacking / reward tampering / reward model gaming 串成同一條結構性脈絡：**迴圈在 game 自己的量度時並非故障，它正是在做被建造來做的事**。推論到 agent 設計上，任何只對單一 eval 指標做閉環優化的系統，遲早會在該指標漂亮攀升的同時，與它宣稱要改善的現實脫鉤。 ### 2. 解法的單位從「循環」升級為「循環的網路」——可靠性住在邊裡文章提出下一個時代的技藝是 loop architecture：設計單位不再是單一循環，而是循環的網路，並給出四失敗對四拓樸解的一對一對照。Goodhart 由「配對」解（每個優化迴圈配一個盯反指標的 watching 迴圈，如 resolution rate 配 renewal rate、speed 配 error rate）；向上盲由「層級」解（更慢的迴圈擁有更快迴圈的參考值，修訂目標本身是被治理的循環而非「誰先設誰」的意外）；衝突由「仲裁」解（在打架迴圈之上設一個擁有 trade-off 權衡的迴圈）；量度衰變由「稽核」解（唯一職責是定期確認其他迴圈的數字仍碰得到世界）。最硬的工程實證是 MLOps pipeline：它不是「retrain and ship」，而是 champion-challenger（候選模型須在 live traffic 擊敗現役才能替換）+ drift-monitor + rollback + held-out evaluation set（訓練迴圈永不可見、刻意致盲、職責就是抓優化迴圈作弊自己測試的迴圈）。**"the reliability lives in the edges"**——誰餵誰、誰監看誰、誰能否決誰，才是真正的設計單位。這對應控制理論的 cascade control / supervisory control / safety interlock，以及控制論 Stafford Beer 的 Viable System Model（不同速度迴圈的分層正規化）。 ### 3. 圖會以「循環互證」的方式失敗——終極補丁是錨，而恆久軸是 ungrounded vs grounded 文章最關鍵、也最容易被標題掩蓋的轉折：拓樸並非解藥。一個完整但無錨的圖——稽核迴圈拿 ops 數字對 finance 數字、finance 數字來自 ops 同一套系統、meta-loop 用建立在被調校迴圈輸出上的 dashboard 調門檻——會退化成「每個迴圈都監看另一個迴圈，沒有一個碰到地面」的循環互證網路，**什麼都一致、什麼都沒被驗證**，比單迴圈更晚、更貴、沿途綠燈更多地失敗。真正的補丁是「錨（anchor）」，分三層：錨定量度（無法被爭辯的量——錢真的進銀行、測試真的跑過、客戶真的留下）、凍結節點（優化器永不可調的規則，正因為它們正是優化器會被誘惑去削弱的，如 held-out set）、以及來自圖外的「更好」之根判斷（由人透過與真實失敗的接觸提供，圖中每個迴圈都預設了它，故無法由機械本身產生）。由此導出全文真正的結論：**恆久的軸從來不是 loops vs graphs，而是 ungrounded vs grounded**——無論改善機械是什麼形狀，關鍵是它是否持續碰觸現實、監看者是否真獨立、凍結規則是否在壓力下仍維持凍結、是否承認最深層的目標是被選擇的而非被計算出來的。作者唯一遺憾是用了 "graph" 一詞，把讀者推向「圖＝解方」的誤讀。必須標注的邊界：文章未處理「錨的權威性建立在什麼之上」的無限後退（infinite regress）風險——「營收」會被會計原則改變、「測試通過」會被測試品質污染——且把「外部判斷從哪來」交給未定義的「人」，在全自动、无人在迴圈的 agent 系統裡缺乏可複製的操作型落地方法（最易退化成另一個 LLM-as-judge 迴圈）。 ## 行動建議與實踐指南 1. **為每個優化指標配一個反指標，並把 pipeline 畫成節點＋邊**：盤點現有 agent eval 與 MLOps pipeline，逐條檢查「誰擁有這個迴圈的參考值？那個擁有者本身被誰監看？」。對任一條「監看」邊，檢查它監看的對象是不是自己產生的資料（audit 迴圈查的 finance 數字是否來自 ops 同一套系統、meta-loop 調門檻用的 dashboard 是否建立在被它調校的迴圈輸出上）——只要存在一條這樣的邊，系統已進入「循環空轉區」，綠燈再亮都不是進步。 2. **盤點並隔離系統裡的「錨」，確保它們對優化器不可見、不可調**：識別真正碰得到現實的量（真的跑過的測試、真的付的錢、真的留下的客戶），套用 held-out set 的紀律——對訓練／優化迴圈完全致盲。誠實自問：held-out set 真的 held-out 嗎（有無偷偷洩漏進訓練）？凍結的「不可調規則」上次被施壓鬆綁是什麼時候？ 3. **為「更好的定義」設一個不在圖內的複審節點**：建立文章所稱「最慢的迴圈」——例如季度由人重新提問「我們還在追對的目標嗎？」，這個節點必須消費來自圖外、與真實失敗接觸的證據，而非僅消費圖內產生的 reports，否則只是再增加一個循環互證的節點。 4. **承認最深層目標是被選擇的，不是被計算出來的**：在 agent 系統設計中，把「哪些東西值得被控制、凍結規則該坐落於何處」明確標記為需要人類判斷的決策，而非交給優化器或另一個 LLM-as-judge 自行收斂；最成熟的架構是誠實標記出自己權威邊界在哪裡結束的架構。

Obsidian 開啟

其他領域

其他總結報告

今日「其他」領域僅有一篇深度拆解——獨立研究員 @0xcherry 對 Kimi K3 的戰略評論。該文並非 benchmark 測評，而是把 K3 嵌進「中國 AI 三路線 → 中美算力地緣博弈 → AI 資本開支敘事」三層結構，論證一個核心命題：一個主動放棄經濟性、開源、尺寸極大的中國模型，正以「2.8T 總參 + 開源權重」的組合，同時壓低閉源前沿實驗室壟斷租金的兩個因子——能力稀缺性與權重封鎖。K3 把尺寸 scaling law 推到進入最高能力組（官方：僅落後 GPT-5.6 Sol / Fable 5）的門檻，再用開源把「模型稅」歸零，使推理定價從「閉源上游想收多少」回歸「高效集群跑成功任務的成本」，進而動搖 Anthropic「不可替代性溢價」敘事，並長期反向衝擊 AI CapEx 鏈條上游的 GPU 議價彈性。作者最終以「小鎮青年暴打資本家」收束——資源受限的邊緣者用「不追求同類利潤」改寫戰場，使在位者的資本優勢反成負擔。

核心主題 (Key Themes)

K3 是戰略轉向而非版本升級——回歸預訓練規模擴張：Kimi 的技術血統與尺寸策略呈現明確代際分野，K3 標誌「既有基座後訓練壓榨」階段的終結。
「放棄經濟性」本身是入場券——以不計成本換前沿定義權：64 卡部署門檻與 Sonnet 價格帶構成「K3 不為 adoption 而戰」的最硬證據。
開源權重把地緣劣勢武器化，形成不對稱競爭組合：算力管制的反作用力被反轉為博弈武器，催生分工與損益極度不對稱的組合。
「取消模型稅」反向衝擊 AI CapEx 鏈條：開放權重取消算力消費上附著的模型稅，使推理回歸成本定價，對依賴景氣度的硬體上游構成长期系統性風險。
Too Big to Fail——能力不對稱性支撐「往大了做」的方法論：強模型與弱模型在能力取得上的不對稱性，是「往大了做」的技術正當性來源，也對應 Christensen 破壞性創新下的價值網路重組。

# 領域總結：其他 (2026-07-20) ## 總結概述今日「其他」領域僅有一篇深度拆解——獨立研究員 @0xcherry 對 Kimi K3 的戰略評論。該文並非 benchmark 測評，而是把 K3 嵌進「中國 AI 三路線 → 中美算力地緣博弈 → AI 資本開支敘事」三層結構，論證一個核心命題：一個主動放棄經濟性、開源、尺寸極大的中國模型，正以「2.8T 總參 + 開源權重」的組合，同時壓低閉源前沿實驗室壟斷租金的兩個因子——能力稀缺性與權重封鎖。K3 把尺寸 scaling law 推到進入最高能力組（官方：僅落後 GPT-5.6 Sol / Fable 5）的門檻，再用開源把「模型稅」歸零，使推理定價從「閉源上游想收多少」回歸「高效集群跑成功任務的成本」，進而動搖 Anthropic「不可替代性溢價」敘事，並長期反向衝擊 AI CapEx 鏈條上游的 GPU 議價彈性。作者最終以「小鎮青年暴打資本家」收束——資源受限的邊緣者用「不追求同類利潤」改寫戰場，使在位者的資本優勢反成負擔。 ## 核心洞察與共同趨勢 ### 1. K3 是戰略轉向而非版本升級——回歸預訓練規模擴張 Kimi 的技術血統與尺寸策略呈現明確代際分野，K3 標誌「既有基座後訓練壓榨」階段的終結。 - **K2 的底盤繼承**：K2 論文明寫採用類 DeepSeek-V3 的超稀疏 MoE 與 MLA 架構，兩者皆 61 層、共享專家（shared expert）、每 token 激活 8 個路由專家；K2 在此底盤上把專家數提到 384、attention heads 減半，並以自研 MuonClip、數據配方、agentic 後訓練與獨立基礎設施做出分叉——證明 Kimi 的「獨立」是共享底盤上的工程分化，而非從零。 - **K2.5~K2.7 的壓榨路線**：總參維持 ~1T、激活 ~32B（A32B）、384 專家選 8，靠後訓練、RL、工具環境與 agent 系統壓榨同一底盤多代，對應「固定基座＋滾動式後訓練」的性價比路線。 - **K3 的跳躍**：總參 2.8T、激活 ~50B（A50B，激活比例約 1.8%）、部署需 64 張以上加速卡、API 從 K2.7 Code 的 $0.95/$4 漲到 $3/$15（per Mtoken in/out，進入 Sonnet 價格帶）；同時抽換回本家訓練基座、注意力機制與專家路由結構，與 DeepSeek 的親緣關係顯著疏遠。MLA 透過把 KV cache 壓縮進低秩潛在空間降低長上下文顯存壓力，超稀疏 MoE 則讓總參可做大而激活保持小，兩者合起來正是「大尺寸＋可負擔推理」的關鍵。 ### 2. 「放棄經濟性」本身是入場券——以不計成本換前沿定義權 64 卡部署門檻與 Sonnet 價格帶構成「K3 不為 adoption 而戰」的最硬證據。 - **中國推理集群湊不出 64 卡節點**：2.8T 巨模型對美國本土推理公司都是「大考」，K3 顯然不是為更廣泛採用，而是為了在更前沿的戰場上定義「可廣泛部署的開源模型標準」。 - **項莊舞劍，意在沛公**：K3 表面是產品，真正打擊面是對手的商業敘事與估值錨；官方措辭「僅落後 Sol/Fable」看似溫和，換個角度卻極為激進——只比 OpenAI 與 Anthropic 最頂級模型差一點。 - **敘事崩塌的時間線本身即是證物**：7 月 8 日 SemiAnalysis 超級牛市推演（Anthropic 2027 年底 ARR 3000 億美元、20 倍 ARR 對應 6 萬億美元企業價值，依賴 API 占 75%–85%、高 API 毛利、極高淨收入留存、Claude Code 持續滲透）被廣泛轉述；7 月 9 日 GPT-5.6 Sol 正式發布；隨後 GLM-5.2 先動搖 Opus 價格錨（多數任務勝 Opus 4.8、價格僅 1/5）、Sol 在最高檔正面撞上 Fable（API $10/$50，Opus 4.8 常規價兩倍）、K3 補上開源一刀——「不可替代性溢價」敘事維持不到一個月即被掀翻。 ### 3. 開源權重把地緣劣勢武器化，形成不對稱競爭組合算力管制的反作用力被反轉為博弈武器，催生分工與損益極度不對稱的組合。 - **反轉邏輯**：「既然你不讓我賺超額利潤，我做出來之後不要利潤不就完事了」——剝奪超額利潤空間反而促成「不要利潤、做開源」的策略。 - **不對稱組合**：中國模型 + 美國及全球推理集群 VS 美國閉源 AI 實驗室。中國實驗室承擔昂貴研發，以開放權重換採用與前沿地位；美國雲廠商與推理平台（Fireworks、TogetherAI、NeoCloud）用本土 GPU 承接調用、按成本定價狠狠賺錢；真正失去利潤的，反而是依靠封閉權重與能力稀缺收超額價格的美國 frontier lab。對中國實驗室，開源犧牲的是本就受自有推理容量限制的潛在 API 租金；對美國閉源實驗室，被犧牲的卻是建立在充足本土算力與全球能力稀缺之上的現實超額利潤。 - **華盛頓的不可能三角**：制裁中國 → 中國繼續放開源（大家都別賺錢）；放開買卡 → 集體競價、本土實驗室缺卡；適度放卡 → 可取得折中收益但「沒人知道放多少，也沒人敢說話」。作者以「華盛頓熱衷講不對稱競爭，現在這個詞落回華盛頓頭上」收束。 - **隱含反諷與最大留白**：作者自己承認「開源不挑顯卡」被打折扣——開源降低權重取得門檻，但沒降低部署尺寸門檻，真正能承接 K3 的是美國大型 NeoCloud，這強化「中國訓練、美國變現」反諷，也削弱「中國自主部署」的樂觀線；同時「往大了做」的資金迴圈（2.8T 預訓練成本由誰長期吸收）並未閉合，是全篇最大未解之處。對應經濟學的「租值消散（rent dissipation）」——K3 開源相當於主動觸發自己與對手的租值同時消散。 ### 4. 「取消模型稅」反向衝擊 AI CapEx 鏈條開放權重取消算力消費上附著的模型稅，使推理回歸成本定價，對依賴景氣度的硬體上游構成长期系統性風險。 - **既有緩衝鏈條**：模型能力稀缺 → API 高價 → 下游高毛利 → 承受 GPU 溢價 → CapEx 擴張 → 上游持續景氣。閉源前沿模型的高推理毛利是這條鏈最重要的緩衝墊。 - **成本定價的反轉**：Fireworks 不必替 Moonshot 承擔 K3 預訓練成本，也不必按 token 向閉源上游支付完整模型租金，只需圍繞 GPU、推理引擎、量化、緩存、網絡、融資、SLA 與企業銷售報價——這反向改寫每張 GPU 的資本回報計算，採購需更高利用率、更短回收期、更低融資成本與更確定的客戶合同。 - **雙段論判斷**：短期下游採購方更分散，不削弱 NVDA 等算力生產商議價權；但長期下游毛利系統性下降，必然導致上游可議價彈性變差。作者對此判斷相當節制——此為長期命題，不宜當作短期 GPU 景氣的反向指標，也不宜過度外推到季節性資本開支預測。值得注意此推論方向與標準 Jevons 悖論相反（推理單價下降通常擴大總調用量，但作者論證定價權轉移會削弱上游議價彈性），仍需獨立驗證。 ### 5. Too Big to Fail——能力不對稱性支撐「往大了做」的方法論強模型與弱模型在能力取得上的不對稱性，是「往大了做」的技術正當性來源，也對應 Christensen 破壞性創新下的價值網路重組。 - **核心不對稱**：已很強但昂貴的大模型，後續可透過稀疏化、量化、緩存、蒸餾與推理工程做快做便宜，還能當整條小模型產品線的教師；一開始沒學到某能力的小模型，卻很難靠延長思考或部署優化憑空補出來。這個不對稱性讓「往大了做就不會輸」成為粗糙卻經常有效的前沿方法論。 - **產業史的循環與回歸**：2024 年 OpenAI o1 把 scaling 重心從更大預訓練基座轉向訓練時 RL 與 test-time compute，基座越小越依賴思考補償、越缺擴大基座動力；2025 年 Anthropic 反向做大尺寸並以 Claude Code 變現（2025 年末稱 Claude Code 占逾半 AI coding 市場、企業份額從 24% 提高到 40%、收入超過 OpenAI）；OpenAI 隨後在 GPT-5.6 重新設置 Sol/Terra/Luna 三尺寸、把大尺寸 Sol 放回旗艦——這本身已是「做小路線」的回歸承認。 ## 行動建議與實踐指南 1. **推理平台／NeoCloud——利多結構但毛利同步壓縮**：開源超大模型把定價權從模型上游拉回算力成本端，競爭轉向利用率、量化、緩存、SLA 與企業銷售，是 Fireworks、TogetherAI 類廠商的利多，但毛利結構同時被壓縮，需以工程效率與企業合約築底。 2. **GPU／AI 硬體投資人——長期折現假設下修**：重新檢視「閉源高毛利→容忍 GPU 溢價→CapEx 擴張」鏈條假設；短期 NVDA 議價權穩，但回報曲線的折現假設需下修，不宜將長期系統性毛利下降當作短期 GPU 景氣反向指標。 3. **模型應用方——最高能力檔的自託管 PoC 首次成立**：K3／GLM-5.2 等開源權重進入「僅落後一檔」區間後，從閉源 API 遷移到自託管開源權重的成本／控制權取捨，首次在最高能力檔成立，值得啟動 PoC 評估。 4. **前沿實驗室策略——護城河轉向整合產品**：當「不可替代性溢價」可被開源＋尺寸 scaling 在一個月內侵蝕，溢價護城河必須從「能力差距」轉向「整合產品（如 Claude Code 的工程滲透）＋獨家資料＋任務可靠度」；Anthropic 把 Fable 從溢價獨賣退守為 Max／Team Premium 常駐權益，已是「訂閱綁定」取代「溢價獨賣」的訊號。

Obsidian 開啟

學習資源領域

學習資源總結報告

今日「學習資源」領域僅一篇 XRay 深度拆解，探討一名 45 萬粉絲自媒體創作者開源的 Claude Code Skill `gbro-series-vocab`，它把「用美劇學英語」的手動五步流程（Google 搜字幕 → NotebookLM 取詞 → Claude 轉 CSV → 表格校對 → Anki 匯入）壓縮成一句話指令「追劇學英語 Friends S01E01」，3 分鐘產出 50 張閃卡與一份 Markdown 詞彙筆記。這篇表面上是一篇英語學習工具文，深層其實是一則「如何用 agent 重構手動 workflow」的微型架構案例。文章真正值錢的不是工具本身，而是三層方法論：第一，把 workflow 裡「全是執行、無一步需要判斷」的步驟辨識出來並交給 agent，把需要取捨的判斷（取哪些詞、用哪個字幕源、優先級排序）寫死成 skill 的 policy；第二，用機制消滅易錯點——CSV 文件頭自帶 Anki 匯入指令（分隔符、牌組名、欄位映射），把「正反面搞反」這個高頻人為錯誤從機制上變成不可能；第三，顛倒使用順序——「先卡片後劇集」，把識別（recognition）當成第一次複習，讓短期記憶在真實情境裡被鞏固成長期記憶。不過作者把遺忘曲線、情境編碼、Krashen i+1、FSRS 等理論過度簡化為單一銀彈，未交代失效邊界，且對字幕抓取的版權灰色地帶完全回避，是閱讀時必須保留的批判距離。

核心主題 (Key Themes)

「辨識可自動化步驟」是架構師級的判斷，與軟體分層同構：文章從原版五步流程裡精準分離出「全是執行、無一步需要判斷」這個屬性，這正是 agent 化的充分條件。判斷被抽離後寫死成 skill policy，執行則交給 agent——這與軟體工程裡把 business logic 與機械執行分層是同一種思維。
用機制消滅易錯點（mechanism over policy），優於靠人小心：CSV 文件頭自帶 Anki 匯入指令這個設計細節，是把高頻人為錯誤從「靠人小心」改成「機制上不可能犯」，這是優秀 API／介面設計「防止誤用」的範例。
順序顛倒＋FSRS 參數調校，是方法論真正核心：「先卡片後劇集」加上 FSRS 的保留率參數選擇，是把認知科學理論轉譯成可操作參數的關鍵，也是整篇文章最容易被誤讀為「工具文」時真正值錢的部分。

# 領域總結：學習資源 (2026-07-20) ## 總結概述今日「學習資源」領域僅一篇 XRay 深度拆解，探討一名 45 萬粉絲自媒體創作者開源的 Claude Code Skill `gbro-series-vocab`，它把「用美劇學英語」的手動五步流程（Google 搜字幕 → NotebookLM 取詞 → Claude 轉 CSV → 表格校對 → Anki 匯入）壓縮成一句話指令「追劇學英語 Friends S01E01」，3 分鐘產出 50 張閃卡與一份 Markdown 詞彙筆記。這篇表面上是一篇英語學習工具文，深層其實是一則「如何用 agent 重構手動 workflow」的微型架構案例。文章真正值錢的不是工具本身，而是三層方法論：第一，把 workflow 裡「全是執行、無一步需要判斷」的步驟辨識出來並交給 agent，把需要取捨的判斷（取哪些詞、用哪個字幕源、優先級排序）寫死成 skill 的 policy；第二，用機制消滅易錯點——CSV 文件頭自帶 Anki 匯入指令（分隔符、牌組名、欄位映射），把「正反面搞反」這個高頻人為錯誤從機制上變成不可能；第三，顛倒使用順序——「先卡片後劇集」，把識別（recognition）當成第一次複習，讓短期記憶在真實情境裡被鞏固成長期記憶。不過作者把遺忘曲線、情境編碼、Krashen i+1、FSRS 等理論過度簡化為單一銀彈，未交代失效邊界，且對字幕抓取的版權灰色地帶完全回避，是閱讀時必須保留的批判距離。 ## 核心洞察與共同趨勢 ### 1. 「辨識可自動化步驟」是架構師級的判斷，與軟體分層同構文章從原版五步流程裡精準分離出「全是執行、無一步需要判斷」這個屬性，這正是 agent 化的充分條件。判斷被抽離後寫死成 skill policy，執行則交給 agent——這與軟體工程裡把 business logic 與機械執行分層是同一種思維。 * **字幕分流策略**：老劇走 Springfield Springfield 劇本站、新劇走 subslikescript（被 JS 驗證碼擋，skill 內建繞行方案）、兜底走全网搜與 Fandom Wiki；已驗證能走通的邊界案例包含帶撇號的 `Grey's Anatomy`、帶數字的 `9-1-1`、2025 年新劇 `The Pitt`。作者實測 3 個月尚未觸發手動貼劇本的 fallback。 * **詞彙提取的優先級寫死**：phrasal verbs > idioms／fixed collocations > slang／spoken > B2-C1 實用詞，跳過基礎詞；並強制「例句必須取自劇本原文，禁止造句」，從源頭消滅 AI 幻覺污染。 ### 2. 用機制消滅易錯點（mechanism over policy），優於靠人小心 CSV 文件頭自帶 Anki 匯入指令這個設計細節，是把高頻人為錯誤從「靠人小心」改成「機制上不可能犯」，這是優秀 API／介面設計「防止誤用」的範例。 * **欄位映射預設**：分隔符、牌組名、欄位映射全部預設在文件頭，雙擊匯入免任何配置；原版流程最容易翻車的「正反面搞反」問題被從機制上消滅。 * **卡片方向對齊真實場景**：正面英文原句、背面中文譯句 + 釋義 + 音標，理由是看劇的真實場景是「聽到英文 → 反應意思」，卡片就該練這個方向，而非反向。 ### 3. 順序顛倒＋FSRS 參數調校，是方法論真正核心「先卡片後劇集」加上 FSRS 的保留率參數選擇，是把認知科學理論轉譯成可操作參數的關鍵，也是整篇文章最容易被誤讀為「工具文」時真正值錢的部分。 * **識別（recognition）≠ 學習（learning）**：先花 10 到 15 分鐘把 50 張卡過一遍讓詞進入短期記憶，再看這一集；剛見過的詞在真實場景裡出現，大腦把它當成「識別」而非「學習」，而識別是短期記憶通往長期記憶最快的一條路——第一次複習不是另一張卡，而是螢幕上一段真實對話。 * **Krashen i+1 的參數化轉譯**：沒預習硬看，難度遠超水平，大腦走神；預熱 15 分鐘後難度正好卡在理解力邊緣——「難到能成長、簡單到能享受」。i+1 從抽象理論被轉譯成「預熱時長」這個可調參數。 * **FSRS 保留率 0.90 的務實權衡**：FSRS（Free Spaced Repetition Scheduler）以「記憶穩定性」stability 建模，保留率 desired retention 是其核心可調參數；作者選 0.90 而非 0.95，是因為 0.95 會讓每日複習量翻倍。搭配「只用 `Again` 與 `Good` 兩個按鈕、禁用 `Hard` 與 `Easy`」以免干擾演算法優化，並強制只開英文字幕（中文字幕會讓大腦死抓翻譯、停止處理英文）。 ## 行動建議與實踐指南 1. **遷移「五步重來、無一步需要判斷」的 workflow 清單**：審視自己手邊有哪些重複性流程符合「全是執行、無一步需要判斷」這個屬性，這就是 agent 化的候選名單。判斷點不在「步驟多不多」，而在「每一步是否都需要人類取捨」——不需要的才能整條交給 agent。 2. **先驗證 repo 實作再相信行銷數據**：作者自陳的「10 倍效率」「百倍體驗」是無控制對照的主觀動機證據；真正可驗證的是 `pyang5166/gbro-series-vocab`（MIT 開源）的程式碼本身。動手前先 `git clone` 試跑一集自己想看的劇，驗證「先卡後劇」的體感差異，並回頭檢視 skill 內 prompt 工程細節（50 這個數字、優先級排序的依據）。 3. **評估適用邊界與穩態風險**：本方法隱含三個前提——用戶已有 B1 以上英文基礎（skill 跳過基礎詞、只取 B2-C1，零基礎者預熱 15 分鐘不夠、i+1 不成立）、字幕來源穩定（subslikescript 繞 JS 驗證碼屬灰色地帶，網站政策隨時可能變）、每天能看一集。一季累積 500 到 1000 張卡、連續多季後，FSRS 在 0.90 保留率下的每日複習量增長曲線可能在某個臨界點壓垮「一天一集」的節奏，需主動監控這個系統的穩態（steady state）。 4. **跨域套用「先建立心理模型，再面對真實複雜度」這個同構**：本方法與 TDD（先寫測試建立預期 → 再寫實作接觸真實場景）、onboarding（先讀架構圖 → 再進 codebase 看真實程式碼）、code-gen agent（辨識不需人類判斷的步驟並自動化，人類只保留需要情境理解的高階動作）同構，可遷移到非語言學習的學習與工程場景。

Obsidian 開啟

📚 文章摘要列表 (Articles)

AI工具

Codex 史詩級更新實操教程：Work、Plugins、內建瀏覽器、Ultra 與 Chat 一次講透

"這輪更新不是多了一堆按鈕，而是讓你在一個桌面裡把「想法→資料→分析→文件→程式碼→驗證→發布」連成一條連續的工作流。"

Top 5 Insights

**本質是定位升級，不是功能堆疊**：這輪更新把 Codex 從「寫程式碼的 AI」變成「完整工作台」，核心問題從「它能不能把碼寫出來」變成「我應該把這項工作放在哪個工作區，用哪個插件，讓幾個 Agent 參與」。
**選擇邏輯看交付物與驗收方式**：研究／分析／寫作／文件交付從 Work 開始；開發／除錯／需要執行驗證的修改交給 Codex；兩者都能碰程式碼與文字，但預設工具鏈與驗收標準不同。
**Plugins 封裝的是專業流程**：Skill 是可複用任務流程，Plugin 是把流程＋工具＋外部連接打包的擴充包。Template Creator 固化個人格式（記得寫「不要保留什麼」），Visualize 把抽象概念做成互動演示（四要素：調什麼／算什麼／怎麼顯示／理解什麼）。
**Ultra 是平行化，不是更聰明**：實測常見上限 4 條並行工作線，Token 明顯高於 High。只有任務能獨立切分時才值得用，否則用 High 更快更省——對應「序列任務平行化不會變快」的工程常識。
**新工作流的價值在連續性**：從想法、資料、分析，到文件、程式碼、驗證和發布，現在可以在同一個桌面工作台裡連續完成。Chat 用來發散但加入主任務前先壓縮結論，瀏覽器完成資料獲取與真實頁面驗證，這條流水線的打通才是這次更新最值得關注的轉變。

--- tags: [AI工具, Codex, OpenAI, AI工作台, Plugins, Ultra] date: 2026-07-20 read: false source: "2026-07-20T100456+0800-Codex 史诗级更新实操教程：Work、Plugins、内置浏览器、Ultra 与 Chat 一次讲透.md" original_title: "Codex 史诗级更新实操教程：Work、Plugins、内置浏览器、Ultra 与 Chat 一次讲透" --- # Codex 史詩級更新實操教程：Work、Plugins、內建瀏覽器、Ultra 與 Chat 一次講透 ![Image](https://pbs.twimg.com/media/HNlGlMHasAAnOqQ?format=jpg&name=large) 原始來源與檔名：2026-07-20T100456+0800-Codex 史诗级更新实操教程：Work、Plugins、内置浏览器、Ultra 与 Chat 一次讲透.md --- ## SOURCE | 資訊源評估 - **準確性**：中 - 來源為 X（Twitter）推文（`@Pluvio9yte`），屬個人實測體驗紀錄，並非 OpenAI 官方發布文件。作者已主動標註「版本說明」與「資訊邊界」兩段免責聲明，承認介面、功能名稱、帳號權限可能分批灰度開放；模型名、模式名可能隨更新變動。具備誠實的不確定性標示，但具體入口/名稱需以官方文件為準。 - **易理解性**：高 - 採「破除表象 → 逐項實操 → FAQ 收斂」結構，每個功能都附操作步驟與可直接複製的提示詞（prompt）範例，實操導向極強。 - **閱讀策略建議**：當作「功能地圖 + 實操起點」。模型名/模式名（Work、Ultra、Sites、Add to task 等）屬灰度期命名，**不要寫進長期工作流**，後續更新時可能變動；真正可沉澱的是「分工心智模型」與「提示詞結構」。 --- ## NAPKIN | 餐巾紙 ### 餐巾紙公式 > Codex = 寫碼 AI ⟶ 一個桌面工作台（Work 出成果 + Codex 出驗證過的改動 + Plugins 封裝專業流程 + 瀏覽器連通網頁 + Ultra 多 Agent 並行 + Chat 把發想接回任務） _Codex 從「單一寫程式碼的 AI」升級成「完整工作台」。六大能力不是互不相干的按鈕，而是分工串起一條從想法到發布的流水線。_ ### 一句話 > 這輪更新不是多了一堆按鈕，而是讓你在一個桌面裡把「想法→資料→分析→文件→程式碼→驗證→發布」連成一條連續的工作流。 ### 餐巾紙草圖 ``` ┌── Codex Desktop（一個工作台，非一堆按鈕） │ │ Work ─────→ 資料加工（報告／表格／PPT／研究） │ Codex ────→ 程式碼（改／測／Diff，交付驗證過的改動） │ Plugins ─┬─ Template Creator（文件→可複用模板 Skill） │ ├─ Visualize（抽象→可操作互動演示） │ └─ Sites（輕量成果快速發布） │ 瀏覽器 ───→ 查網頁／業務操作／開發測試 │ Ultra ────→ 多 Agent 並行（實測 ≤4 條工作線） │ Chat ─────→ Add to task（發想→壓縮結論→接回主任務） │ └── 同一桌面串完整條工作流：想法→資料→分析→文件→碼→驗證→發布 ``` --- ## ROUND 1: SKELETON | 骨架掃描 - **核心問題**：Codex 這輪更新到底改了什麼？左側多了 Work、Chat，插件市場冒出 Sites、Template Creator、Visualize，推理強度又多了 Ultra——這些是互不相干的按鈕，還是同一件事？ - **核心答案**：這是一次從「寫程式碼的 AI」到「完整工作台」的定位升級。六大能力分工明確——Work 把資料變成果、Codex 把碼變成驗證過的改動、Plugins 封裝專業流程、瀏覽器連通網頁、Ultra 多 Agent 並行、Chat 把發想接回任務。 - **論證結構**：破除「一堆不相干按鈕」的表象 → 逐項實操（Work vs Codex / 三個 Plugins / 瀏覽器 / 前端設計 / Ultra）→ 常見問題 → 結語收斂到「該把工作放在哪個工作台」的新心智模型。 ### 章節骨架（條列） - 一、Work 和 Codex 的區別（預設工作對象不同，而非誰更強） - 二、Plugins 三個值得試：Template Creator、Visualize、Default Templates - 三、內建瀏覽器升級：查資料／業務操作／開發測試，與兩種瀏覽器之別 - 四、前端設計能力加強：約束→生成→驗證→修復的穩定工作流 - 五、Ultra mode：什麼時候值得讓多個 Agent 並行 - 六、常見問題（6 題）+ 結語：從「能不能寫出來」到「放哪個工作台」 --- ## ROUND 2: DISSECTION | 血肉解剖 ### 論證鏈（ASCII） ``` ┌── 核心論證鏈 │ │ 表象：左側多 Work、Chat，插件市場多 Sites／Template Creator／Visualize，推理多 Ultra │ ▼ │ 本質：Codex 從「寫碼 AI」→「完整工作台」 │ ▼ │ 分工：Work 把資料變成果／ Codex 把碼變成「驗證過的改動」 │ ▼ │ 擴充：Plugins 把部署、模板複用、互動式可視化封裝成開箱即用能力 │ ▼ │ 連通：瀏覽器查網+測試／ Chat→Add to task 把發想接回正在執行的任務 │ ▼ │ 規模：Ultra 用多 Agent 並行拆解複雜任務，主 Agent 匯總 │ ▼ │ 結論：一條工作流（想法→資料→分析→文件→碼→驗證→發布）可在同桌面連續完成 └── ``` ### 3 個關鍵證據 1. **Work vs Codex 的分工邊界在「預設工作對象」與「驗收方式」**：Work 預設圍繞專案資料、網頁、PDF、Office 檔案，產出報告／文件／表格，驗收看「內容準確、結構清晰、檔案可用」；Codex 預設圍繞程式碼庫、Git 狀態、專案規則，產出可執行並經過驗證的程式碼修改，驗收看「測試通過、程式執行、修改符合要求」。一句話：**Work 擅長把資料變成成果，Codex 擅長把碼變成經過驗證的改動**。 2. **Template Creator 提示詞的「反模式防護」**：作者強調一定要寫「**不要保留什麼**」（原檔機密資料、姓名、專案名、具體結論），否則模板會把範例檔的業務資料誤當成固定結構。這是把「檔案→模板」時的資料污染風險顯性化，是真正可遷移的工程習慣。 3. **Ultra 的並行實測上限與成本**：新版介面實測中，Ultra 協調多個 Agent，常見上限 **4 條並行工作線**；因為並行 Agent 會分別讀取上下文並各自產出，**Token 消耗通常明顯高於 High**。適合跨模組重構、深度報告、獨立測試／遷移；不適合改一句文案、單檔 Bug、強依賴步驟的任務（用 High 更快更省）。 ### 隱形假設與邊界 - **假設一：讀者具備提示詞撰寫能力**。全文價值高度依賴「目標＋資料範圍＋分析維度＋交付格式＋驗收標準」五件套寫得清楚。寫不出好提示詞的人，Work 與普通聊天的差距會被大幅壓縮——這個前提作者未明說。 - **假設二：Plugins 的狀態隔離**。作者建議「安裝/更新插件後，當前任務沒出現對應能力時，新建任務比反覆刷新舊任務更穩妥」——暗示舊任務可能帶有快取上下文，新能力未必注入，這是一個工程上的狀態隔離假設。 - **邊界：灰度進度差異**。沒有 Work、Ultra、Sites 或 Add to task，通常是客戶端版本、帳號套餐、地區或灰度進度不同，不一定是操作錯誤。**不要把灰度介面中的模型名或模式名寫進長期工作流**。 --- ## ROUND 3: SOUL | 靈魂提取 - **作者盲點**： - 預設讀者能寫出高品質提示詞，未深談「寫不出提示詞的人該怎麼辦」——而提示詞品質正是 Work／Plugins 產出好壞的決定性變數。 - **Sites 著墨過少**：標題把 Sites 列入，正文卻只在 FAQ 帶過「個人網站／原型可簡化部署，複雜環境變數／團隊權限／企業域名仍需專業托管」，缺實際發布流程與限制細節。 - Ultra 多 Agent 的**合併衝突與成本控制**只給原則（「給每條工作線指定清晰邊界，最後由主 Agent 統一合併和測試」），缺實測數據與合併策略。 - **知識連接**： - **Skill vs Plugin** 的區分對應「標準作業流程（SOP）vs 擴充包」——Skill 是可複用的任務流程，Plugin 是可安裝的能力包，可同時包含 Skills、工具、應用與外部連接（類似 IDE 的 snippet vs plugin）。 - **Ultra 多 Agent** 對應分散式運算的 **MapReduce fan-out／reduce** 模式：拆任務→並行 map→主 Agent reduce 匯總；前提是任務可平行化（無強依賴）。 - **Chat → Add to task** 對應「暫存區→正式任務佇列」的狀態晋升機制，發想不污染主任務，壓縮結論後才晋升。 - **行動觸發**： - **立刻做**：用 Work＋競品報告提示詞跑一遍，體驗「交付格式＋自檢」帶來的差距。 - **本週做**：挑一份你最滿意的現有文件，用 Template Creator 固化成個人模板 Skill，記得寫「不要保留什麼」。 - **謹慎做**：Ultra 只在任務能清楚拆成多條獨立工作線時啟用；簡單或強依賴任務繼續用 High。 ### 留白提問（2 題） 1. 當 Work 與 Codex 都能寫碼也能做報告（只是預設工具與驗收方式不同），企業團隊該如何制定「工作區選擇規範」，避免同事亂用導致同一份交付物驗收標準不一？ 2. Ultra 多 Agent 並行若遇上同一檔案被多條工作線同時修改，主 Agent 的合併策略是什麼？Token 成本上限該如何預估與設限？ ### 跨域映射 - **作業系統程序模型**：Work／Codex 像兩個不同 process family，各自有預設 syscall 集合（檔案生成 vs shell／編輯／測試），選錯 process family 等於用錯工具鏈。 - **生產線六工站**：想法→資料→分析→文件→碼→驗證→發布，過去散落在多個軟體，現在收進同一桌面。 - **廚房分工**：Work 是備料出菜、Codex 是設備維修、Plugins 是專用廚具、瀏覽器是採購窗口、Ultra 是多爐並開、Chat 是菜單發想本。 --- ## DEEP READ | 精讀指引這篇值得精讀的並不是「Codex 多了哪些按鈕」——按鈕會變、名稱會改。真正值得讀的是作者把一輪 UI 改版**翻譯成心智模型**的方法：他沒有逐個介紹功能，而是先回答「這次更新到底改了什麼」（從寫碼 AI 變工作台），再用「預設工作對象＋驗收方式」這個雙軸，把 Work 與 Codex 的選擇問題變成可判斷的決策樹。這種「先抓本質、再談操作」的寫法，本身就是處理任何 AI 工具改版的範本。第二層值得讀的是**提示詞的結構性**。四段提示詞（競品報告、Template Creator、Visualize、前端個人網站）反覆出現同一個骨架：**目標＋資料範圍／約束＋交付格式＋驗收／自檢標準**。作者甚至把「不要保留什麼」「Word 生成後做頁面渲染檢查」「用瀏覽器逐頁檢查並修復」這種防呆與自檢條件寫進提示詞——這是把 QA 思維前置到 prompt 的工程實踐，可遷移到任何 LLM 工作流。第三層是**對「更強＝更好」的祛魅**。Ultra 不是「思考更久的 High」，而是「拆任務＋並行＋匯總」的平行化，只在任務可獨立切分時才有價值；否則只是花更多 Token。這對應軟體工程裡「平行化不會讓序列任務變快」的基本常識。讀完應該能回答：不是「要不要用 Ultra」，而是「這個任務的 dependency graph 能不能 fan-out」。 --- ## STRUCTURE MAP | 全書結構圖 ``` ┌── Codex 史詩級更新實操教程 │ ├── 1. Work vs Codex（區別不在誰更強，在預設工作對象） │ ├─ 對比：工作對象／常用能力／主要成果／驗收方式／典型場景 │ └─ 選擇決策樹 + Work 實做競品報告提示詞 │ ├── 2. Plugins（三個值得試） │ ├─ Template Creator（文件→可複用模板 Skill，要寫「不要保留什麼」） │ ├─ Visualize（抽象→可操作互動演示，四要素：調什麼/算什麼/怎麼顯示/理解什麼） │ └─ Default Templates（臨時起點，非核心） │ ├── 3. 內建瀏覽器升級 │ ├─ 三場景：查資料／業務操作／開發測試 │ └─ 兩種瀏覽器：內建（獨立環境）vs Chrome 連接（已登入會話） │ ├── 4. 前端設計能力加強 │ └── 工作流：給設計約束→生成頁面→瀏覽器看結果→指出問題→修改再驗證 │ ├── 5. Ultra mode（多 Agent 並行，實測 ≤4 條工作線） │ ├─ 適合：跨模組重構／深度報告／獨立測試遷移 │ └─ 不適合：改文案／單檔 Bug／強依賴步驟 │ └── 6. 常見問題（6 題）+ 結語 └── 核心轉變：從「能不能寫出來」→「該放哪個工作台、用哪個插件、讓幾個 Agent 參與」 ``` --- # Codex 史詩級更新實操教程（Architectural Deep Dive） ## 前言／背景如果你最近打開 Codex，發現左側突然多了 Work、Chat，插件市場裡出現了 Sites、Template Creator、Visualize，推理強度裡又多了一個 Ultra，先別急著把它們當成互不相干的新按鈕。這輪更新真正的變化，是 Codex 正從「寫程式碼的 AI」變成一個完整的工作台： - **Work** 負責把資料加工成文件、表格、PPT、研究報告等成果； - **Codex** 繼續負責改程式碼、跑測試、查問題，並交付經過驗證的修改； - **Plugins** 把部署、模板複用和互動式可視化等專業流程封裝成開箱即用的能力； - **瀏覽器** 讓 Codex 可以直接查網頁、下載資料和測試網站； - **Ultra** 用多個 Agent 並行處理複雜任務； - **Chat** 則把腦力激盪和正在執行的任務連了起來。下面不只有介紹功能，而是帶你從零實際操作一遍。 > **版本說明**：本文寫於 2026 年 7 月 18 日。Codex 的介面、功能名稱和帳號權限可能分批開放。如果你的介面沒有 Work、Ultra、Sites 或 Add to task，通常是客戶端版本、帳號套餐、地區或灰度進度不同，並不一定是操作錯誤。 > **資訊邊界**：Skills、Plugins、瀏覽器與多任務協作屬於 Codex 已有的正式能力體系；Work、Ultra、Sites、Chat → Add to task 的具體名稱與入口以新版桌面端介面為準。不要把灰度介面中的模型名或模式名寫進長期工作流，後續更新時它們可能變化。 ![Image](https://pbs.twimg.com/media/HNlFrSab0AEb4OK?format=jpg&name=large) --- ## 章節詳細總結 ### 一、先搞懂：Work 和 Codex 到底有什麼區別？兩者介面很像，核心區別不在「誰更強」，而在**預設圍繞什麼工作**。原文以五個維度對比（已從表格轉為條列，避免閱讀斷行）： ``` 對比項 Work Codex ───────────────────────────────────────────────────────────────────── 預設工作對象專案資料、網頁、PDF、Word、Excel、PPT 程式碼庫、當前目錄、Git 狀態、專案規則常用能力搜尋、瀏覽器、資料分析、檔案生成 Shell、檔案編輯、建構、測試、Diff 主要成果報告、文件、表格、簡報、研究結論可以執行並經過驗證的程式碼修改驗收方式內容是否準確、結構是否清晰、檔案是否可用測試是否通過、程式是否執行、修改是否符合要求典型場景產業研究、競品分析、資料報告、寫作、做 PPT 開發功能、修 Bug、程式碼重構、測試、程式碼審查 ``` **一句話記憶**：Work 擅長把資料變成成果，Codex 擅長把碼變成經過驗證的改動。 **怎麼選？** - 最終想得到一份報告、表格、PPT 或調研結論：選 Work。 - 最終想得到一組程式碼修改，而且需要執行和測試：選 Codex。 - 既有研究又有開發：先在 Work 中形成需求和資料包，再把確定後的規格加入 Codex 任務。 - 只是臨時討論方向、還不想動專案：先用 Chat。 #### 實操：用 Work 生成一份競品研究報告操作步驟： 1. 點擊左側 Work，新建任務。 2. 選擇一個資料夾作為工作區，或直接上傳已有資料。 3. 把需要研究的網址、PDF、表格等一併交給它。 4. 不要只說「幫我研究一下」，要同時寫清楚**目標、資料範圍、分析維度、交付格式和驗收標準**。可直接複製下面這段提示詞： ``` 請研究我提供的資料和網頁，製作一份《AI 程式設計工具競品分析報告》。要求： 1. 比較 Codex、Claude Code 和 Cursor 的產品定位、工作方式、優勢、限制與適用人群； 2. 對無法從來源確認的資訊標記「待核實」，不要自行補全； 3. 先給出一頁執行摘要，再給出詳細對比表； 4. 最後提出 5 條對內容創作者最有價值的使用建議； 5. 交付 Markdown 和 Word 兩個版本； 6. Word 生成後進行頁面渲染檢查，修復表格溢出、孤行和標題斷頁問題。 ``` 這段提示詞的關鍵在最後兩條。你不僅告訴了 Codex「寫什麼」，還規定了「**交付什麼檔案**」以及「**如何自檢**」。這正是 Work 比普通聊天更有價值的地方——把 QA 驗收條件前置到 prompt 裡。 ![Image](https://pbs.twimg.com/media/HNlFwesaMAARCP4?format=jpg&name=large) ![Image](https://pbs.twimg.com/media/HNlF0Gba4AAbMgw?format=jpg&name=large) ![Image](https://pbs.twimg.com/media/HNlF2EnawAAQb_J?format=jpg&name=large) --- ### 二、新增 Plugins 怎麼用？三個真正值得試的插件官方產品結構裡，**Skill** 是一套可複用的任務流程，**Plugin** 則是可安裝的能力包，可以同時包含 Skills、工具、應用和外部連接。簡單理解：**Skill 像標準作業流程，Plugin 像把流程和工具一起裝進 Codex 的擴充包**。進入 Codex 的插件頁面，先確認目標插件已經安裝並啟用。安裝或更新插件後，如果當前任務裡沒有出現對應能力，**新建一個任務通常比反覆刷新舊任務更穩妥**（避免舊任務上下文未注入新能力）。 ![Image](https://pbs.twimg.com/media/HNlF5hAbMAAomYU?format=jpg&name=large) #### 2.1 Template Creator：把一份好文件變成永久可複用的模板 Template Creator 不是簡單複製檔案。它會**分析現有 Word、PPT 或 Excel 的版式、結構和視覺規律**，再建立一個可重複呼叫的個人模板 Skill。適合拿來處理： - 公司固定格式的週報、月報和專案匯報； - 有統一母版的路演 PPT； - 學校論文、實驗報告和課程作業； - 固定表頭、公式和圖表規範的 Excel 模型。 **操作步驟** 1. 安裝並啟用 Template Creator。 2. 新建任務並上傳一份品質最好的範例檔案。 3. 說明哪些元素必須保留，哪些內容只作為範例。 4. 讓它建立個人模板 Skill，並為模板寫清楚適用範圍。 5. 建立完成後另開一個任務，用一份新內容實際生成檔案。 6. 對比原檔案和新檔案，檢查字體、色板、頁邊距、母版、表格和圖表是否一致。推薦提示詞： ``` 請使用 Template Creator，把我上傳的《final_report.pdf》製作成一個可重複使用的個人模板 Skill。必須保留： - 16:9 頁面尺寸； - 封面、章節頁、資料頁和總結頁的版式； - 字體層級、品牌色、頁碼和 Logo 安全市； - 表格、柱狀圖和折線圖的視覺規範。不要保留： - 原檔案中的專案機密資料； - 姓名、專案名和具體結論。完成後告訴我這個模板適合什麼場景，並用一組虛構資料生成 5 頁測試稿，檢查是否能夠穩定重用。 ``` 這裡有一個容易忽略的技巧：**一定要寫「不要保留什麼」**。否則模板可能會把範例檔案中的業務資料、姓名甚至結論誤當成固定結構，造成資料污染與模板誤用。 ![Image](https://pbs.twimg.com/media/HNlF9E_aoAAKY7C?format=jpg&name=large) ![Image](https://pbs.twimg.com/media/HNlGCJIboAA4y-u?format=jpg&name=large) #### 2.3 Visualize：把抽象內容做成可以操作的演示 Visualize 不只是「畫一張圖」。它更適合製作**帶互動的圖表、流程演示、參數模擬器、對比工具和教學實驗**。例如，你可以讓它製作： - 可拖動預算和轉換率的廣告 ROI 模擬器； - 展示 Agent 排程過程的動態流程圖； - 可以切換年份和地區的資料看板； - 幫助初學者理解注意力機制的互動實驗。推薦提示詞： ``` 請使用 Visualize 製作一個「大學物理斜拋運動演示器」。使用者可以調整： - 初速度：5～50 m/s； - 發射角度：0°～90°； - 初始高度：0～20 m； - 重力加速度：1.6～15 m/s²。介面需要即時繪製物體的運動軌跡，並顯示飛行時間、最高點、水平射程以及任意時刻的速度分量。加入時間滑桿，讓使用者觀察物體在不同位置的速度和加速度方向。同時展示相關公式和計算過程，並透過軌跡對比解釋：為什麼在忽略空氣阻力、起點和落點等高時，45° 對應最大水平射程。預設使用中文，適合放進大學物理教程文章中演示。 ``` 好的 Visualize 提示詞通常包含四部分：**使用者能調什麼、系統要算什麼、結果怎麼顯示、讀者要理解什麼**。這個四要素結構可遷移到任何互動式可視化任務。 ![Image](https://pbs.twimg.com/media/HNlGFPIbkAAGgWx?format=jpg&name=large) ![Image](https://pbs.twimg.com/media/HNlGHc2bEAAQ9j7?format=jpg&name=large) #### 2.4 Default Templates 值不值得用？內建模板適合快速起稿，但**模板數量多不等於適合你的品牌**。對正式交付，作者更建議先選一份真正滿意的現有檔案，再用 Template Creator 提煉成自己的模板；內建模板可以當作臨時起點，不必把它當作這輪更新的核心功能。 --- ### 三、內建瀏覽器升級：不是「能打開網頁」，而是能完成網頁任務新版 Codex 的瀏覽器能力覆蓋了三個常見場景： 1. **查資料**：打開網頁、讀取內容、跨多個分頁比較資訊、下載檔案； 2. **做業務操作**：在得到授權後使用已經登入的頁面處理任務； 3. **開發測試**：執行本地網站，檢查頁面、互動、Console 資訊和不同尺寸下的布局。 #### 先分清兩種瀏覽器 - **Codex 內建瀏覽器**：環境更獨立，適合公開資料檢索、網頁測試和不依賴個人帳號的任務。 - **Chrome 連接**：使用你的 Chrome 視窗和已有登入狀態，適合必須依賴帳號 session 的網站。 > **安全提醒**：Codex 可以在授權範圍內使用瀏覽器的登入狀態，不代表你應該讓任務讀取、展示或匯出密碼與 Cookie。密碼、驗證碼和 Cookie 都屬於敏感資訊，應繼續由瀏覽器和登入流程管理。涉及登入、上傳、發布、發送或購買等外部操作時，應該在執行前確認目標和範圍。 --- ### 四、前端設計能力加強後，怎樣才能做出真正可用的網站？模型的視覺能力提升，不等於只用一句「做得高級一點」就能穩定得到好結果。真正有效的工作流是： ``` 給設計約束 ──→ 生成頁面 ──→ 用瀏覽器看結果 ──→ 指出具體問題 ──→ 修改並再次驗證 ``` 不要過度綁定原帖中出現的特定模型名稱。模型名稱和帳號可選項可能隨灰度變化；實際操作時，直接選擇你介面裡最新、最適合程式設計的模型即可。 #### 一套更穩定的前端提示詞 ``` 請製作一個獨立開發者的中文個人網站。設計方向： - 克制、編輯感強、內容優先； - 使用暖白背景、深灰正文和一個低飽和強調色； - 字體層級清楚，正文閱讀寬度控制在舒適範圍； - 動效只用於解釋層級和狀態，不加入無意義的漂浮與旋轉； - 避免千篇一律的漸層紫、玻璃卡片、超大圓角和滿屏行銷口號。頁面結構： - 首屏：姓名、定位、一句話介紹和主要入口； - 精選專案：3 個專案，每個專案說明問題、方法和結果； - 寫作：最近文章列表； - 關於與聯絡方式。實作要求： - 桌面端與手機端均可用； - 使用真實、簡短的中文範例文案，不用 Lorem ipsum； - 保證對比度、鍵盤焦點和語意化結構； - 完成後啟動專案，用瀏覽器逐頁檢查並修復問題； - 最終提供執行方式、設計說明和驗證結果。 ``` 這段提示詞的設計邏輯：**設計方向（克制原則＋反模式清單）＋頁面結構（語意化）＋實作要求（響應式＋無障礙＋自檢閉環）**。把「不要做什麼」（漸層紫、玻璃卡片、超大圓角、Lorem ipsum）顯式列出，等同於在 prompt 階段就排除常見 AI 生成味。 ![Image](https://pbs.twimg.com/media/HNlGJ97boAAObNw?format=jpg&name=large) --- ### 五、Ultra mode：什麼時候值得讓多個 Agent 一起幹活？ Ultra 的價值不是「單個 Agent 思考得更久」，而是**把一個複雜任務拆成多條可以同時推進的工作線，再由主 Agent 匯總**。在新版介面實測中，Ultra 會協調多個 Agent，**常見上限為 4 條並行工作線**。具體 Agent 數量、模式名稱和額度仍以你的介面為準。因為並行 Agent 會分別讀取上下文和產生結果，**Token 消耗通常明顯高於 High**。 #### 適合 Ultra 的任務 - 大型專案的跨模組重構； - 需要同時做資料研究、事實核對、分析和寫作的深度報告； - 多個相互獨立的測試、排查或遷移任務； - 有明確分工、最後還需要統一驗收的複雜交付。 #### 不適合 Ultra 的任務 - 改一句文案、調整一個按鈕顏色； - 只涉及一個檔案的簡單 Bug； - 工作步驟高度依賴，後一階段必須等待前一階段； - 沒有明確驗收標準的開放式閒聊。這些任務用 High 往往更快、更省。本質上這對應平行計算的常識：**任務的 dependency graph 能否 fan-out 決定了並行的收益**；強序列依賴的任務，並行只增加協調成本。 --- ### 六、常見問題 **1. 為什麼我沒有 Work、Ultra 或 Add to task？** 先更新 Codex 客戶端並重新登入，再檢查帳號套餐、團隊管理員策略和插件是否啟用。如果仍然沒有，大概率是功能尚未開放到你的帳號。不要照著別人的截圖猜隱藏入口。 **2. Work 能不能寫程式碼？Codex 能不能做報告？** 可以，但預設工具和驗收方式不同。選擇時應該看「**最終交付物是什麼**」，而不是看任務中會不會碰到一點程式碼或文字。 **3. Sites 能完全替代 Vercel 嗎？** 對個人網站、原型和臨時演示頁，它可以顯著簡化部署；對複雜環境變數、團隊權限、企業域名、日誌監控和精細發布流程，仍要根據專案需要選擇專業托管平台。 **4. Ultra 一定比 High 好嗎？** 不一定。只有任務能被清楚拆成多條獨立工作線時，並行才有明顯價值。簡單或強依賴任務使用 Ultra，往往只是花更多 Token。 **5. Codex 會讀取我的 Chrome 密碼和 Cookie 嗎？** 正確用法是讓 Codex 在授權範圍內使用瀏覽器 session，而不是讓它展示或匯出密碼、Cookie、驗證碼等敏感資訊。涉及登入、上傳、發布、發送或購買等外部操作時，應該在執行前確認目標和範圍。 **6. 為什麼多個 Agent 反而把專案改亂了？** 最常見原因是**分工不清，讓多個 Agent 同時修改同一個檔案**。給每條工作線指定清晰邊界，最後由主 Agent 統一合併和測試。 --- ## 總結與結論 1. **本質是定位升級，不是功能堆疊**：這輪更新把 Codex 從「寫程式碼的 AI」變成「完整工作台」，核心問題從「它能不能把碼寫出來」變成「我應該把這項工作放在哪個工作區，用哪個插件，讓幾個 Agent 參與」。 2. **選擇邏輯看交付物與驗收方式**：研究／分析／寫作／文件交付從 Work 開始；開發／除錯／需要執行驗證的修改交給 Codex；兩者都能碰程式碼與文字，但預設工具鏈與驗收標準不同。 3. **Plugins 封裝的是專業流程**：Skill 是可複用任務流程，Plugin 是把流程＋工具＋外部連接打包的擴充包。Template Creator 固化個人格式（記得寫「不要保留什麼」），Visualize 把抽象概念做成互動演示（四要素：調什麼／算什麼／怎麼顯示／理解什麼）。 4. **Ultra 是平行化，不是更聰明**：實測常見上限 4 條並行工作線，Token 明顯高於 High。只有任務能獨立切分時才值得用，否則用 High 更快更省——對應「序列任務平行化不會變快」的工程常識。 5. **新工作流的價值在連續性**：從想法、資料、分析，到文件、程式碼、驗證和發布，現在可以在同一個桌面工作台裡連續完成。Chat 用來發散但加入主任務前先壓縮結論，瀏覽器完成資料獲取與真實頁面驗證，這條流水線的打通才是這次更新最值得關注的轉變。 --- ## 參考資料 - [Codex 官方文件](https://developers.openai.com/codex/) - [Codex App 官方說明](https://developers.openai.com/codex/app/) - [Codex Skills 官方說明](https://developers.openai.com/codex/concepts/customization#skills) - [Codex Plugin 結構說明](https://developers.openai.com/codex/plugins/build#plugin-structure) - [OpenAI：Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/)

Obsidian 整理原始文章

AI工程

How to Build a Self-Correcting AI Loop That Catches Its Own Mistakes Before You See Them（如何打造一個在你看見之前就自我抓錯的 AI 迴圈）

"真正的自我修正不是「再問一次」，而是用獨立判官對照外部 ground truth 並回傳結構化 verdict，再用硬性 stop condition 防止無限循環。"

Top 5 Insights

**「再問一次」是結構性缺陷，不是模型問題**：同一 context、同一產生錯誤的推理不適合用來發現該錯誤；真正的自我修正必須用架構強制獨立判斷，把產生（Builder）與判斷（Judge）拆成不同 pass、不同 prompt、理想上不同 reference frame。
**三角色 + 結構化 handoff 是可移植骨架**：Builder 產 first attempt（最大自由）、Judge 對照外部標準回傳結構化 verdict、Manager 讀 verdict 決策並持有記憶；handoff 必須具備定義格式、定義觸發、定義失敗路徑三屬性。content 與 code 兩個 worked example 證明跨域幾乎只需換 Judge checklist。
**Ground truth 是命脈，決定「正確性檢查」還是「一致性檢查」**：沒有獨立 ground truth 的 Judge 只能評 coherence，confidently wrong + well-formatted 的答案會每次矇混過關；coding 看 test 執行結果、content 看 source 並排、research 看實際搜尋結果——若你說不清自己任務的 ground truth，你只有 rephrasing loop。
**Stop condition 必須是 Manager 的硬邏輯**：max iteration count、可量測 quality threshold、cost/time ceiling 三組件缺一不可，且都要寫成機械檢查的硬邏輯，而非 prompt 內「good enough」的 soft instruction——否則不可解任務會燒錢失控。
**信任前先過四個 stress test，scale 用循序擴展**：unsolvable / confidently-wrong / same-model blind spot / cost runaway 四測試專打 demo 看不出、上線才爆的失敗；擴展時循序加 loop、用共享成本儀表板、log 每次 escalation 以偵測 Judge 標準校準錯誤。

--- tags: [AI工程, AI-Agent, LLM-Verification, Builder-Judge-Manager, Self-Correction] date: 2026-07-20 read: false source: "2026-07-20T100459+0800-How to Build a Self-Correcting AI Loop That Catches Its Own Mistakes Before You See Them.md" original_title: "How to Build a Self-Correcting AI Loop That Catches Its Own Mistakes Before You See Them" --- # How to Build a Self-Correcting AI Loop That Catches Its Own Mistakes Before You See Them（如何打造一個在你看見之前就自我抓錯的 AI 迴圈） ![Image](https://pbs.twimg.com/media/HNXkmwUXsAA6EF0?format=jpg&name=large) 原始來源與檔名：2026-07-20T100459+0800-How to Build a Self-Correcting AI Loop That Catches Its Own Mistakes Before You See Them.md --- ## SOURCE | 資訊源評估 - **準確性**：高 — 作者把「產生 ⊥ 判斷」的角色分離、ground truth 對照、hard stop condition 等核心機制講得與業界 LLM-as-a-Judge、Actor-Critic、CI/CD pipeline 的共識一致；stop condition 三組件與四個 stress test 皆為實務可驗證模式。唯一缺口是通篇為經驗法則，未附量化數據（iteration 上限、實際成本），需讀者自行 calibrate。 - **易理解性**：高 — 結構線性清晰：破迷思 → 三角色 → handoff → ground truth → stop condition → 兩個 worked example（content / code）→ 落地清單。並附可直接複製的 handoff template 與 STOP CONDITIONS 範本。 - **閱讀策略建議**：第一遍先抓「三角色 + handoff template」（核心骨架），第二遍精讀「ground truth」與「stop condition」兩節（系統命脈），最後把「四個 stress test」與「五個常見錯誤」當成落地前的 checklist 逐條對照自己系統。 ## NAPKIN | 餐巾紙 ### 餐巾紙公式 > Self-Correction = (Build ⊥ Judge) × GroundTruth + HardStop _把「產生答案」與「判斷答案」拆成兩個獨立 pass，Judge 必須對照 Builder 沒有的外部 ground truth，最後用寫死在 Manager 邏輯裡的 stop condition 收斂——而不是靠模型「再問一次自己」。_ ### 一句話 > 真正的自我修正不是「再問一次」，而是用獨立判官對照外部 ground truth 並回傳結構化 verdict，再用硬性 stop condition 防止無限循環。 ### 餐巾紙草圖 ``` ┌── 任務進入（brief + ground truth） │ ▼ ┌── Builder（產生器） │ 產出：Deliverable + Confidence + Known uncertainties + Assumptions │ （最大創意自由、最少約束，只負責 first attempt） │ ▼ structured handoff（定義格式 / 觸發 / 失敗路徑） ┌── Judge（判官，對照 ground truth） │ Verdict: PASS / FAIL / NEEDS REVISION + 逐項 issue + verdict confidence │ ▼ ┌── Manager（決策者 + 記憶體） │ ├─ PASS → 交付使用者 │ ├─ FAIL/REVISION → 帶「具體」issue 退回 Builder（revision++） │ └─ revision > N → escalate human（附完整歷史） │ 或 token/分鐘爆 → 立即停止 │ ▼ 輸出（你看見時，明顯錯誤已被自我修正過） ``` ## ROUND 1: SKELETON | 骨架掃描 - **核心問題**：如何讓 AI 系統在你看見輸出之前，就先自己抓到並修掉錯誤，把你從「手動驗證層」的位置上移除？ - **核心答案**：把「產生」與「判斷」拆成兩個獨立角色（Builder / Judge），Judge 必須對照 Builder 沒有的外部 ground truth 並回傳結構化 verdict，再用 Manager 套上硬性 stop condition 收斂。重點不是「問得更好」，而是「架構」。 - **論證結構**：先破除「再問一次」的迷思（結構性缺陷）→ 提出三角色 + handoff 三屬性 → 把 ground truth 拉出來單獨成節（命脈）→ stop condition 三組件（防失控）→ 兩個跨域 worked example（content / code，證明骨架可移植）→ 落地保險：四個 stress test + 五個常見錯誤 + scaling 原則 → 本週行動。 ### 章節骨架（條列） 1. Why This Is Not The Same As Just Asking Twice — 破除「再問一次」迷思 2. The Three Roles Every Self-Correcting Loop Needs — Builder / Judge / Manager 3. Building The Handoffs — handoff 三屬性 + 跨任務 template 4. The Judge Needs Ground Truth, Not Just An Opinion — 命脈：外部對照 5. The Stop Condition Is Not Optional — 三組件：max iteration / 可量測 threshold / cost ceiling 6. A Worked Example: Self-Correcting Content Production — 內容產製實戰 7. Testing The Loop Before You Trust It — 四個 stress test 8. Common Mistakes That Quietly Break An Otherwise Good Design — 五個常見錯誤 9. A Second Worked Example: Self-Correcting Code — 程式碼實戰（同骨架） 10. Scaling To Multiple Concurrent Loops — 並行擴展的紀律 11. Where To Start This Week — 本週落地順序 ## ROUND 2: DISSECTION | 血肉解剖 ### 論證鏈（ASCII） ``` 「再問一次」= 同一 context、同一產生錯誤的推理 │ → 從內部看，答案依然 plausible → 傾向「捍衛」而非「複查」 │ → 這是結構性缺陷，非單一模型問題 ▼ 解法不是「問得更好」，而是「架構」：產生 ⊥ 判斷 │ ├─ Builder：最大創意自由、最少約束，只產 first attempt（不追求完美） ├─ Judge：對照「外部 ground truth」回傳結構化 verdict（非鬆散散文） └─ Manager：讀 verdict 決策 + 持有 prior attempt 記憶 + stop condition ▼ verdict 要可信 ⇐ Judge 必須拿到 Builder 沒有的東西 │ （test suite / 原始 source / 需求文件 = 獨立 ground truth） ▼ handoff 三屬性：定義格式 + 定義觸發 + 定義失敗路徑 │ （Builder 不自己決定「何時完成」） ▼ stop condition 三組件（皆硬邏輯，非 prompt 內 soft instruction） ├─ max iteration count（硬上限，到頂強制 escalate） ├─ 可量測 quality threshold（機械可驗，非「good enough」） └─ cost / time ceiling（絕對預算，防最壞情況） ▼ 落地順序：選一窄任務 → 先寫 Judge checklist → 建 loop → 跑四 stress test → 信任後才循序 scale（非一次開五條） ``` ### 3 個關鍵證據 1. **self-review 是結構性缺陷，不是模型問題** — 同一次產生 plausible-but-wrong 答案的 pass，從內部看答案依然 plausible；「are you sure?」產生的是「再保證」多於「真正複查」。這證明了「再問一次」不可能建立真正的自我修正 loop。 2. **沒有 ground truth 的 Judge 只能做 coherence check** — Judge 若只看 Builder 輸出、沒有獨立參照，只能評估「內部一致性、格式是否工整」，無法評估「正確性」。一個 confidently wrong、well-formatted、內部一致的答案，會「每次」矇混過關。這證明 ground truth 不可省。 3. **「stop when good enough」是建議不是條件** — 寫在 prompt 裡的 soft instruction 是模型「可以在壓力下自我說服跳過」的建議；只有寫成 Manager 機械檢查的硬 iteration counter 才是真 stop condition。這在「任務其實不可解」時差異巨大。 ### 隱形假設與邊界 - **假設任務有可寫下的明確標準**：對完全開放性 / 創意任務（無客觀 ground truth），此架構會退化為 coherence check，甚至誤判。 - **假設 ground truth 本身正確且即時**：若 test suite 過時、source document 有誤，Judge 會「正確地通過一個錯誤的標準」——作者未處理這層「ground truth 的 ground truth」反饋式失敗。 - **假設有預算跑獨立模型當 Judge**：資源受限時只能同模型 + 換 prompt，仍可能共用 blind spot；作者承認這只是「劇場性獨立」。 - **假設 Manager 真的有狀態記憶**：無狀態 Manager 會把同樣的失敗回饋重複送回 Builder 第二、第三次，產生 identical 失敗結果。 - **邊界**：全篇為經驗法則，無量化數據；iteration 上限 N、成本 X/Y 皆未給基準，需讀者依任務 calibrate。 ## ROUND 3: SOUL | 靈魂提取 ### 作者盲點 - **過度樂觀假設 ground truth 永遠存在且正確**：沒談「ground truth 本身被汙染、過時、或不完整」時整個 loop 會自信地強化錯誤——這正是「自信地錯」的放大器。 - **未深究「同族模型共用訓練偏差」**：即使換不同模型，若皆屬同一家族（如皆預訓練自相近資料集），系統性 blind spot 仍可能傳遞，分離角色的獨立性可能是劇場性的。 - **忽略 latency 與互動體驗**：自我修正 loop 必然增加延遲（多次 pass + escalate），對即時互動 / 對話式場景可能完全不適用，作者未討論取捨。 - **cost ceiling 只談 token / 分鐘**：沒談「品質 vs 成本」的 Pareto 前緣——何時該接受「夠好」而非無止境修正。 ### 知識連接 - **演算法類比**：Actor-Critic（RL）、Generator-Discriminator（GAN）——皆為「產生器 ⊥ 判別器」分離；本架構是其於 LLM 工程的落地。 - **軟體工程類比**：CI/CD pipeline、pre-commit hook、merge gate、code review 流程——commit（Builder）/ CI lint+test（Judge）/ merge gate（Manager + stop condition）。 - **研究脈絡**：與 LLM-as-a-Judge、self-consistency、self-refine 的關鍵差異在於——後者多為「同模型自我回顧」，本文主張「獨立 pass + 外部 ground truth」。 - **制度設計類比**：權力分立（產法 / 審查 / 執行），用「角色對立 + 外部制衡」防止單點失誤累積。 ### 行動觸發 - 本週挑一個「我反覆手動校對」的窄任務（例如文章發布前 fact-check、API 回應格式校驗），**先寫 Judge 的 checklist**，再寫 Builder 的 prompt。 - 把現有「問 Claude → 自己肉眼看」的流程，改插入一個 Judge pass，讓它對照原始 source / 需求文件回傳結構化 PASS/FAIL，而非我自己當驗證層。 - 為該 loop 寫一個「max iteration + token ceiling」的硬 stop，並 log 每一次 escalation，觀察哪些任務反覆撞頂。 ### 留白提問（2 題） 1. 如果你的 ground truth（測試集 / 需求文件 / source document）本身就是錯的或過時的，整個 loop 會「自信地通過錯誤」——你要如何為 ground truth 本身設計一層驗證？誰來當「Judge 的 Judge」？ 2. 當 Builder 與 Judge 來自同一家族模型，分離角色帶來的「獨立性」可能只是劇場性的——在什麼前提下，你願意付出「換不同廠牌模型當 Judge」的成本？延遲與品質的交換點在哪裡？ ### 跨域映射 - **軟體 CI/CD**：Builder = commit；Judge = CI test + lint + build status；Manager = merge gate；stop condition = block merge after N failed builds。 - **新聞編輯台**：Builder = 記者撰稿；Judge = 查核編輯對照原始資料與採訪錄音；Manager = 總編決定退稿 / 刊登 / 上訴。 - **司法程序**：Builder = 檢察官起訴；Judge = 法官 / 陪審團審判（對照法條與證據）；Manager = 量刑與上訴程序（stop condition = 三審定讞）。 ## DEEP READ | 精讀指引 **為什麼值得精讀**：本文把「LLM 自我修正」這個常被講成玄學的主題，拆解成可工程的角色 + 介面 + 條件三層，並用 content 與 code 兩個跨域例子證明骨架可移植。對任何在打造 agent pipeline、RAG 驗證層、或自動化內容產製的人，這是少見「講清楚 why 而非只給 prompt」的實戰藍圖。 **第一段重點**：先理解「為什麼再問一次無效」。作者的核心洞見是——自我回顧的失敗不是模型能力問題，而是「同一次產生錯誤的推理，不適合用來發現該錯誤」，因為從內部看 plausible 的答案依然 plausible。這把問題從「如何讓模型更會自我檢查」重新定位為「如何用架構強制獨立判斷」。讀這段時，回頭檢視你自己目前在用的「請 Claude 幫我檢查一下」流程——它幾乎一定落入這個陷阱。 **第二段重點**：死記 ground truth + stop condition 這對命脈。ground truth 決定 Judge 能不能真正評「正確性」而非只評「一致性」；stop condition 決定 loop 會不會在不可解任務上燒錢失控。建議把作者給的 handoff template 與 STOP CONDITIONS 範本逐字抄進自己的系統，再依任務改 checklist——這比從零設計快十倍。最後務必跑完四個 stress test 才信任任何 loop：它們專打「demo 時看不出來、上線才爆炸」的失敗模式。 ## STRUCTURE MAP | 全書結構圖（ASCII） ``` ┌── 破迷思：再問一次 ≠ 自我修正（同 context 同推理 → 捍衛原答案） │ ├── 三角色（產生 ⊥ 判斷 ⊥ 決策） │ ├─ Builder：產 first attempt，最大自由 │ ├─ Judge：對照 ground truth，回傳結構化 verdict │ └─ Manager：讀 verdict 決策 + 記憶 + stop condition │ ├── Handoff（介面工程，最常被跳過） │ ├─ 定義格式（structured，非鬆散散文） │ ├─ 定義觸發（Builder 不自決何時完成） │ └─ 定義失敗路徑（指定下一步，不靜默崩潰） │ ▼ 跨任務 template（Builder/Judge/Manager 三段格式） │ ├── 命脈一：Ground Truth │ ├─ coding：test suite / 執行輸出 / lint / build │ ├─ content：原始 source + brief 並排 │ └─ research：實際搜尋結果與 source 文件 │ （無法描述 ground truth → 你只有 rephrasing loop） │ ├── 命脈二：Stop Condition（硬邏輯） │ ├─ max iteration count │ ├─ 可量測 quality threshold（機械可驗） │ └─ cost / time ceiling（絕對預算） │ ├── 兩個 Worked Example（同骨架，跨域證明） │ ├─ Content：逐項 fact-check / brief 合規 / 核心論點未稀釋 │ └─ Code：test 未遭竄改 / lint 乾淨 / diff 真的解決指派任務 │ ├── 落地保險 │ ├─ 四 stress test：unsolvable / confidently-wrong / 同模型 blind spot / cost runaway │ └─ 五常見錯誤：Judge 無對照 / 同模型薄殼 / Manager 無記憶 / 跳過 stress test / soft stop │ └── Scaling：循序擴展（非一次開五條）+ 共享成本儀表板 + log 每次 escalation ▼ 本週：選一窄任務 → 先寫 Judge checklist → 建 loop → 跑 stress test → 才信任 ``` --- # How to Build a Self-Correcting AI Loop That Catches Its Own Mistakes Before You See Them (Architectural Deep Dive) ## 前言 / 背景多數人使用 AI 的迴圈是：對 Claude 提出需求 → 讀輸出 → 發現錯誤 → 指出 → 拿到修正版 → 再讀 → 再發現 → 再指出。**你就是驗證層，而且是手動的、每個任務、每次都做**。自我修正 loop 的目標，是把你從這個位置上完全移除：系統先產生、對照真實標準自我檢查、抓出錯處、修正，**然後才**把結果給你看。輪到你時，明顯的錯誤已被處理掉，你剩下的是「真正需要人類的判斷」，而不是在校對機器的第一版草稿。本文給出完整工程藍圖：確切的架構、確切的 prompt 結構、以及信任它之前必須測試的失敗模式。 ## 章節詳細總結 ### 1. Why This Is Not The Same As Just Asking Twice — 破除「再問一次」迷思最直覺的第一反應是：在同一個對話裡叫模型自我檢查（「review what you just wrote and fix any mistakes」）。這有點用，但**不會**建立真正的自我修正 loop。根本原因：模型在同一個 context、用同一個產生錯誤的推理來檢視自己輸出時，傾向**捍衛**自己的作品而非真正複查。這不是某個模型的缺陷，而是**結構性問題**——同一次產生 plausible-sounding 但錯誤答案的 pass，從內部看答案依然 plausible，並不適合用來發現它錯了。問「are you sure?」產生的多為「再保證」而非「真正複查」。 **解法不是問得更好，而是架構**：真正的自我修正 loop 把「產生答案」與「判斷答案」分開，用不同的 pass、不同的 prompt、理想上完全不同的 reference frame，讓判斷不被產生錯誤的同一個 blind spot 汙染。 ### 2. The Three Roles Every Self-Correcting Loop Needs — 三角色每個能運作的自我修正系統，無論任務為何，都歸約為三個獨立角色。理解這三個角色，比記住任何具體 prompt 更重要——一旦看懂，幾乎任何任務都能靠「填入具體細節」建成 loop。 - **The Builder（產生器）**：產生實際輸出——寫程式、起草內容、做研究、執行任務。這個角色應被給予**最大創意自由、最少約束**，因為它的職責是產生 first attempt，不是完美版本。 - **The Judge（判官）**：不產生任何東西。唯一職責是拿 Builder 的輸出對照一個**具體、寫下來的標準**（不是模糊的品質感）——程式是否通過測試？草稿是否符合 brief？研究是否真的回答了問題？理想上 Judge 應該拿到 Builder 沒有的東西：原始 source material、test suite、實際需求文件，這樣才有**獨立 ground truth** 可對照，而不是把同一份輸出重讀一遍再形成新意見。 - **The Manager（管理者）**：讀 Judge 的 verdict 並決定下一步——帶具體回饋退回 Builder、escalate 給人類、或標記任務完成。這也是 **stop condition** 所在地——那條防止 loop 在無法自動修復時永遠跑下去的規則。 **跨三角色的關鍵設計原則**：verification 必須參照 Builder 自身推理**之外**的東西——test suite、原始 source 文件、寫下來的 checklist、一個用真正不同 framing 的第二次 AI call。任何「同一個模型、同一口氣、再問一次」都不算。 ### 3. Building The Handoffs — handoff 介面工程自我修正 loop 裡真正的工程難點，不是每個角色的巧妙 prompt，而是**角色之間傳遞什麼的結構**——這是多数人第一次建 loop 時完全跳過、然後納悶系統為何行為不可預測的部分。一個 handoff 要可靠運作，需要三個屬性： - **定義格式**：讓接收端不必解析鬆散散文、猜測什麼重要。 - **定義觸發**：讓 Builder 不是「自己決定何時完成」的那一方。 - **定義失敗路徑**：當事情沒乾淨發生時，有指定的下一步，而不是系統靜默崩潰或永遠循環。實務上，Builder 應輸出**結構化**內容而非只是對話文字：清楚的 deliverable + 對自身不確定性的明確聲明。Judge 對照寫下來的標準評估該結構化輸出，回傳自己的**結構化 verdict**（不是一段 hedge 的散文，而是清楚的 pass / fail / needs-revision，附上具體原因）。Manager 讀的是這個結構化 verdict（不是原始內容），依事先確立的規則決定下一步，而非臨場即興判斷。以下是跨大多數任務（寫作 / 程式 / 研究）都適用的 template： ```text BUILDER OUTPUT FORMAT Deliverable: [the actual output] Confidence: [high / medium / low] Known uncertainties: [anything you are unsure about, stated explicitly] Assumptions made: [anything you assumed without being told] JUDGE VERDICT FORMAT Verdict: [PASS / FAIL / NEEDS REVISION] Checked against: [the specific standard used, e.g. the original brief, the test suite, the source document] Specific issues found: [exact problems, not a general impression] Confidence in this verdict: [high / medium / low] MANAGER ACTION If PASS: mark complete, deliver to user. If FAIL or NEEDS REVISION: send back to Builder with the Judge's specific issues attached. Increment the revision counter. If revision counter exceeds [N]: stop looping, escalate to human with full history of what was tried and why it failed. ``` 這看起來比隨性對話往返結構多，沒錯——但這個前期成本，買到的是「第 100 次跑跟第 1 次行為一致」的系統，而不是隨 context 累積而不可預測漂移。 ### 4. The Judge Needs Ground Truth, Not Just An Opinion — 命脈：外部對照這是整個系統**最重要**的原則，值得單獨成節，因為做錯它會悄悄削弱其他一切。一個只看 Builder 輸出、沒有獨立參照的 Judge，**只能評估內部一致性**（輸出是否連貫、格式是否工整），**無法評估正確性**（輸出是否真的符合需求、是否真的解決真實問題）。一個 confidently wrong、well-formatted、內部一致的答案，會**每次**矇混過沒有 ground truth 的 Judge。各任務的 ground truth： - **coding 任務**：test suite、實際執行程式的輸出、lint 結果、build status。不是「這程式看起來對嗎」，而是「執行時真的通過了嗎」。 - **content 任務**：原始 source material + 原始 brief，與草稿並排。不是「這讀起來順嗎」，而是「草稿裡每個具體聲明是否都能追溯到 source 裡實際存在的東西，且作品是否真的滿足 brief 裡每個需求」。 - **research 任務**：研究本應基於的實際搜尋結果與 source 文件。不是「這摘要聽起來權威嗎」，而是「每個聲明能否追溯到具體 source，且被搜尋的 source 是否真的是相關的」。 **如果你無法說清楚你這個任務的 Judge ground truth 是什麼，你還沒有自我修正 loop——你只有一個 rephrasing loop**，其中 Builder 的自信錯誤會被 Judge 自信地重新措辭，而非真正被抓出。 ### 5. The Stop Condition Is Not Optional — 防失控的三組件自我修正 loop 變成昂貴失控災難最常見的原因，就是缺乏一個明確、硬性的 stop condition。沒有的話，Builder 與 Judge 可以無限循環——每次修正觸發一次評估、每次評估觸發一次修正——成本一路攀升，沒人注意到直到帳單到來。真正的 stop condition 需要三個組件，且都應以**明確邏輯**強制執行，而非留給模型臨場判斷： - **max iteration count**：對修正循環的硬上限，到頂後 Manager 無論 Judge 是否滿意都必須 escalate 給人類。 - **可量測的 quality threshold**（不是 aspirational）：「good enough」作為 prompt 內的指令**不是** stop condition，因為它是模型在適當壓力下終究會忽略的建議。一個具體、可檢查的門檻（11 個 test case 全過、草稿符合 brief 全部 5 個需求）才是 stop condition，因為它能被機械驗證，而非每次主觀判斷。 - **cost / time ceiling**：無論狀態為何都不能超越的絕對預算。這是保護你免於最壞情況（一個真的不可解的任務一直循環到有人注意到發票）的護欄。 ``` STOP CONDITIONS Maximum revisions: 3. On the 3rd failed verdict, stop and escalate to a human with the full revision history attached, do not attempt a 4th cycle automatically. Quality threshold: all items on the Judge's checklist must show PASS, not "mostly passing" or "close enough." Budget ceiling: if this task has consumed more than [X] tokens or [Y] minutes, stop immediately regardless of current state and report what was completed versus what remains. ``` 把這些寫進 Manager 的**實際邏輯**，而不是某個較長 prompt 裡的 soft instruction——那種模型在壓力下會自我說服跳過的指令。 ### 6. A Worked Example: Self-Correcting Content Production — 內容產製實戰把 source document 轉成完成品、無需人類手動校對每份草稿的具體流程： - **Builder**：收到 source material 與 brief，產出草稿。輸出包含草稿本身 + 明確的信心聲明 + 寫作時不確定的清單（某個不確定是否在 source 裡的數字、某個推論而非直接找到的聲明）。 - **Judge**：收到草稿**與原始 source 並排**（絕不孤立看草稿）。檢查三件具體的事，每件各自 pass/fail： 1. 草稿中每個事實聲明是否都能追溯到 source 裡實際存在的東西。 2. 草稿是否滿足 brief 裡每個具體需求（長度、語氣、必要章節）。 3. 核心論點或 hook 是否真的在場、未被廢話稀釋。 Judge 回傳結構化 verdict，三項檢查**各自** pass/fail——因為塌縮成一個總分會隱藏究竟是哪個維度失敗。 - **Manager**：讀結構化 verdict。三項全 pass → 送最終輸出佇列。事實查核維度失敗 → 退回 Builder 並**直接標出具體未驗證聲明**（不是「double check accuracy」這種模糊指令）。brief 合規失敗 → 退回並**點名具體缺漏的需求**。**同一個檢查連續失敗三次** → Manager 完全停止循環，帶完整嘗試歷史 escalate 給人類，而非繼續重試一個系統已證明無法自行解決的問題。這是個小系統——三角色、一個結構化 handoff 格式、一個明確 stop condition。但它也是你**真的能無人值守運行並信任輸出**的系統，因為每個失敗模式都有一條已定義路徑，而非未定義的。 ### 7. Testing The Loop Before You Trust It — 四個壓力測試信任任何自我修正系統處理要緊事之前，刻意跑這些 stress test。多數在實際使用中失敗的 loop，只要有人先檢查，會立刻在其中一項失敗： - **The unsolvable task test（不可解任務測試）**：刻意給 Builder 一個它無法達到 Judge 標準的任務。Manager 是否正確撞到 iteration 上限並 escalate 給人類？還是無限旋轉、在一個永遠不會成功的任務上燒成本？ - **The confidently wrong test（自信地錯測試）**：餵 Judge 一個你已知微妙有錯的輸出（讀起來順但含特定事實或邏輯錯誤）。Judge 帶著 ground truth 參照，是否正確抓到？若 Judge 通過了你已知壞掉的東西，你的 ground truth 參照其實沒被檢查，或檢查太淺。 - **The same-model blind spot test（同模型盲點測試）**：若 Builder 與 Judge 跑同一底層模型，值得直接檢查。餵 Judge 一個含該模型典型錯誤的輸出。若 Judge 揮手放行，你建了一個**在角色間共用 blind spot** 的 loop——這抵銷了分離角色的全部目的。考慮為 Judge 角色用真正不同的模型，或至少用顯著不同的 prompt framing。 - **The cost runaway test（成本失控測試）**：算出系統的最壞情況路徑——最大 revision 數、最貴的模型 call、最長合理內容長度——算出實際花多少 real dollars 與 real time。若那數字出現在實際發票上會讓你驚慌，你的 stop condition 還不夠緊。在信任 loop 處理任何真實事物前跑這四個測試，能抓到絕大多數「否則會第一次出現在客戶、老闆、或你自己銀行對帳單前」的失敗。 ### 8. Common Mistakes That Quietly Break An Otherwise Good Design — 五個常見錯誤即使有三角色正確架構，少數幾個具體實作錯誤會在完全不同領域重複出現： - **讓 Judge 只看 Builder 輸出、沒有獨立參照**：最常見的單一錯誤，悄悄把系統從 correctness check 退化成 coherence check。沒有對照的 Judge 只能告訴你輸出內部一致，永遠不能告訴你是否真的正確。 - **每個角色用同一模型，只疊一層薄指令差異**：若 Judge 跑跟 Builder 完全相同的底層模型、只換個 prompt 叫它「be critical」，它常繼承 Builder 完全相同的 blind spot——因為它根本是戴不同帽子的同一個推理過程。預算允許時，為 Judge 用真正不同的模型，產生的是真獨立，而非劇場性獨立。 - **把 Manager 當單純 pass-through，不給它 prior attempt 的真記憶**：沒有「這個任務已試過什麼」可見度的 Manager，會開心地把同樣失敗回饋第二次、第三次送回 Builder，每次產生 identical 失敗結果——因為系統裡沒有東西記得這個確切方法已失敗過一次。 - **因為某次 demo 跑得好就跳過四個 stress test**：一個「你盯著看時行為正確」的系統，與一個「無人值守時行為正確」的系統，是不同的宣稱。只有第二個才是建自我修正 loop 的真正目的。若你沒有刻意測過失敗模式，你其實還不知道你的系統是哪種宣稱。 - **把 stop condition 寫成 soft instruction 而非 hard logic**：prompt 內的「stop when it's good enough」不是 stop condition，是模型在壓力下終究會自我說服跳過的建議。一個 Manager 在允許下次循環前機械檢查的硬 iteration counter 才是。這兩者差異在「任務真的不可解」時巨大無比。 ### 9. A Second Worked Example: Self-Correcting Code — 程式碼實戰（同骨架）任務換成程式碼時，同一骨架看起來不同但邏輯一致——兩者並排看會清楚發現跨域幾乎沒變： - **Builder**：coding agent 處理一個定義好的任務（bug fix、feature、refactor）。它的結構化輸出**不只是 code diff**，而是**實際嘗試執行的指令輸出**——test results、lint output、build status——一起打包進 handoff。一個產生程式碼卻從不實際執行的 Builder，並未真正正確地填好 Builder 角色，因為「語法合理卻 fail 自己 test suite 的程式碼，比沒有程式碼更糟——它看起來完成卻沒完成」。 - **Judge**：檢查三件具體、可驗證的事： 1. 變更是否在**未修改測試本身**的情況下通過既有 test suite（因為 Builder 偷偷改測試讓它通過是個特定且常見到值得直接檢查的失敗）。 2. static analysis 與 lint 是否乾淨。 3. diff 是否真的解決指派的任務，而非 Builder 覺得更有趣、順手解的相關但不同的問題。每項各自有明確 pass/fail。 - **Manager**：依哪個具體檢查失敗來路由。失敗的 test suite → 退回 Builder 並**直接附上確切失敗測試輸出**（不是「fix the tests」這種泛指令）。scope mismatch（diff 解了不同的問題）→ **立刻 escalate 給人類**而非循環，因為那是「任務到底是什麼」的判斷失敗，不是 Builder 能單獨迭代解決的機械缺陷。關鍵洞見：這裡的底層骨架——Builder 產生並附證據提交、Judge 對照具體命名準則逐項 verdict、Manager 依確切失敗檢查路由——**與上面的內容產製例子完全相同**。這是跨兩個領域並排看真正值得帶走的教訓：一旦骨架正確，套用到新任務大多是為 Judge 寫一個新的、具體的 checklist，而非每次都從第一原理重新設計整個架構。 ### 10. Scaling To Multiple Concurrent Loops — 並行擴展的紀律單一 loop 真正可靠後，下一個真問題是如何同時跑多個而不讓系統失控——這正是多数人第二次 scale 時出錯的地方。誘惑是第一個 loop 一成功就立刻同時開多個、五個任務並行處理。**抗拒這個誘惑，比感覺需要的更久**。每多一個並行 loop，就是多一個 stop condition 可能靜默失敗的地方、多一個成本可能無感失控的地方、多一個 Judge 的 ground truth 可能微妙錯誤（只在真實流量下才顯現，單次測試看不出）的地方。更安全的 scale 路徑是**循序擴展 + 每步的真信任門檻**：先把一個 loop 跑到「你已停止密切檢查它的輸出」那麼可靠——意思是它在一段真實時間內持續通過你的手動抽查，而非單次成功 demo——**然後才**為不同任務加第二個 loop。追蹤每個 loop 隨時間的實際失敗率，而不只是你剛好觀察到的那幾次是否「看起來有效」。跑多個並行 loop 時，認真考慮跨所有 loop 的**共享成本儀表板**，而非每個 loop 孤立追蹤。一個有合理 per-task 預算的單一 loop 孤立看完全沒問題。十個各自在預算內的 loop 加起來仍可能是個沒人注意、直到聚合帳單到來才驚覺的總額——正是因為每個個別 loop 的追蹤單獨看都沒問題。 **防止 scale 問題於未然的單一習慣**：log 每個 loop 的每一次 stop condition 觸發，而不只是成功完成。撞到 max iteration 上限並 escalate 給人類的 loop 正在做它該做的；但若某個特定 loop 持續撞頂而其他罕見，那是個訊號——該任務的 Judge 標準校準錯誤（太嚴格永遠過不了），或在對照錯誤的 ground truth。若你只追蹤成功、把每次 escalation 當孤立而不顯眼的事件而非該 loop 設計的資料點，這個 pattern 是看不見的。 ### 11. Where To Start This Week — 本週落地不要第一次就試建一個完全通用的自我修正系統。挑一個你已在做的具體、窄、定義良好的任務（有個你被問到就能寫下來的清楚標準），先圍繞那單一任務建三角色 loop。 **在寫任何一行 Builder 的 prompt 之前，先把 Judge 的 checklist 明確寫下來**。你對照的標準應該塑造你要求 Builder 產出什麼，而不是反過來。若你還寫不出 checklist，你對這個任務的「正確」還不夠了解、還不足以自動化檢查它——這值得在動工前先發現。在信任 loop 處理要緊事之前跑上述四個 stress test，而不是在某人面前出錯之後。從第一版就把 stop condition 加成真實的硬邏輯，而不是被失控 loop 燒過一次才補的亡羊補牢。一旦一個 loop 真正可靠、無人值守、抓到真實錯誤、該停就乾淨停止，第二個會快得多。不是因為 prompt 可直接轉移（它們通常需要為新任務重寫），而是因為你已經理解問題的真實形狀——**把產生與判斷分開、給判斷一個真實的對照、把 stop condition 寫成邏輯而非希望**。那個形狀就是整個學問。其他一切都只是把它套用到眼前任何任務。 ## 總結與結論 1. **「再問一次」是結構性缺陷，不是模型問題**：同一 context、同一產生錯誤的推理不適合用來發現該錯誤；真正的自我修正必須用架構強制獨立判斷，把產生（Builder）與判斷（Judge）拆成不同 pass、不同 prompt、理想上不同 reference frame。 2. **三角色 + 結構化 handoff 是可移植骨架**：Builder 產 first attempt（最大自由）、Judge 對照外部標準回傳結構化 verdict、Manager 讀 verdict 決策並持有記憶；handoff 必須具備定義格式、定義觸發、定義失敗路徑三屬性。content 與 code 兩個 worked example 證明跨域幾乎只需換 Judge checklist。 3. **Ground truth 是命脈，決定「正確性檢查」還是「一致性檢查」**：沒有獨立 ground truth 的 Judge 只能評 coherence，confidently wrong + well-formatted 的答案會每次矇混過關；coding 看 test 執行結果、content 看 source 並排、research 看實際搜尋結果——若你說不清自己任務的 ground truth，你只有 rephrasing loop。 4. **Stop condition 必須是 Manager 的硬邏輯**：max iteration count、可量測 quality threshold、cost/time ceiling 三組件缺一不可，且都要寫成機械檢查的硬邏輯，而非 prompt 內「good enough」的 soft instruction——否則不可解任務會燒錢失控。 5. **信任前先過四個 stress test，scale 用循序擴展**：unsolvable / confidently-wrong / same-model blind spot / cost runaway 四測試專打 demo 看不出、上線才爆的失敗；擴展時循序加 loop、用共享成本儀表板、log 每次 escalation 以偵測 Judge 標準校準錯誤。

Obsidian 整理原始文章

AI工程

How to Choose Between Kimi K3, Sonnet 5, and Fable 5 (The Exact Routing Rules)（如何在 Kimi K3、Sonnet 5 與 Fable 5 之間做選擇：精確路由規則）

"三個模型、三個倒數計時的時鐘；用「工作負載形狀」路由，而不是用品牌忠誠度或定價表路由。"

Top 5 Insights

**形狀優先於標價**：模型成本由工作負載形狀決定。agent loop 形狀（高上下文復用）下，K3 的 cache 有效費率（$0.30/M cached）讓它比 Sonnet 5 便宜 4x、比 Fable 5 便宜 21x；但 one-shot 形狀下 Sonnet 5 才最便宜。核心可執行工具是有效費率公式 `effective_rate = (fresh×$3 + cached×$0.30) / total`。
**便宜路徑 = 預設路徑，升級需附理由**：把 Sonnet 5 + medium effort 固化為 settings.json 預設，並用 CLAUDE.md 路由規則區塊定義何時升級 K3（3+ 檔案/100K+ token、跨回合重讀、前端 UI）、何時升級 Fable 5（2 週以上人工工作、推理深度改變結果、需先報 credit 成本）。這把模型選擇從品味問題降維成規則問題。
**誠實定價而非過度推銷**：Fable 5 最強但要付 3-5x 溢價，問題是「值不值得」而非「是否更好」；Sonnet 5 在最難 agentic coding 落後 Opus 4.8（63% vs 69%）；K3 自報 benchmark、廠商自承落後——把這些誠實聲明當成待驗證項，而非定論。
**時效是機會本身**：三個 deadline（7/19 Fable 付費、8/31 Sonnet 漲 50%、7/27 K3 權重）使「現在就路由」成為有複利的決策。拖延的代價是限時價與免費窗口雙雙消失；8/31 之後 Sonnet 5 的 $2/$10 不再，所有以「便宜預設」為前提的路由規則都需重新校準。
**避開三個隱藏陷阱**：Sonnet 5 的 high-effort 陷阱（max effort 可能比 Opus 貴卻略遜）、K3 發布時 max-only reasoning（$15/M 燒滿、短任務悄悄變貴）、Fable 5 的 safeguard reroute（安敏請求靜默降級到 Opus 4.8，輸出突降時先查 reroute）。三者共同構成「為何看似正確的路由仍可能出錯」的防線。

--- tags: [AI工程, LLM, model-routing, prompt-caching, cost-optimization] date: 2026-07-20 read: false source: "2026-07-20T100708+0800-How to Choose Between Kimi K3, Sonnet 5, and Fable 5 (The Exact Routing Rules).md" original_title: "How to Choose Between Kimi K3, Sonnet 5, and Fable 5 (The Exact Routing Rules)" --- # How to Choose Between Kimi K3, Sonnet 5, and Fable 5 (The Exact Routing Rules)（如何在 Kimi K3、Sonnet 5 與 Fable 5 之間做選擇：精確路由規則） ![Image](https://pbs.twimg.com/media/HNlbhS7WkAAYw9n?format=jpg&name=large) 原始來源與檔名：2026-07-20T100708+0800-How to Choose Between Kimi K3, Sonnet 5, and Fable 5 (The Exact Routing Rules).md --- ## SOURCE | 資訊源評估 - **準確性**：中-高 — 定價、截止日期、cache 公式與 worked example 皆具體可查證；但 K3 的 benchmark 為廠商自報（self-reported），獨立評測尚未落地，部分結論（如「K3 是 volume machine」）帶有推論成分。作者本人亦坦承此點。 - **易理解性**：高 — 結構由「時效驅動 → 成本實證 → 決策樹 → 可複製路由規則 → 誠實評價 → 陷阱 → 常見錯誤 → 10 分鐘落地」層層推進，附有效費率公式與 CLAUDE.md 區塊，工程可操作性極強。 - **閱讀策略建議**：把「決策樹」與「exact routing rules（CLAUDE.md 區塊）」視為核心可執行產物；定價細節時效性極強（Sonnet 5 於 8/31 漲價 50%、Fable 5 免費窗口已關閉），務必標註引用時點，避免把「限時價」當成「永久價」寫進長期決策。 ## NAPKIN | 餐巾紙 ### 餐巾紙公式 > `路由 = f(任務形狀, 上下文復用率)` ≠ `f(標價)` _決定用哪個模型的不是 per-token 貼紙價，而是工作負載的「形狀」：上下文是否重複讀取（cache hit 率）、任務難度是否落在品質差距會複利的區間。標價只在 one-shot 場景才接近真實成本。_ ### 一句話 > 三個模型、三個倒數計時的時鐘；用「工作負載形狀」路由，而不是用品牌忠誠度或定價表路由。 ### 餐巾紙草圖 ``` ┌────────────────────────────────────────────── │ 工作負載形狀 → 路由決策（非按標價） │ │ 一次性 / 短上下文 / 知識工作 │ ├─→ Sonnet 5 ($2/$10，8/31 後 $3/$15) ← 預設 │ 近 Opus 品質、最低價；最難 agentic coding 落後 Opus 4.8 │ │ 長上下文 + 高復用（1M window、agent loop） │ ├─→ Kimi K3 ($3/$15，cache hit $0.30) │ 800K cached + 50K fresh → $0.39/turn（比 Sonnet 便宜 4x） │ │ 最難 5%（多週遷移、證明密集推理） │ └─→ Fable 5 ($10/$50，usage credits) ← 需說明理由才升級 │ 最強模型，但問題不是「是否更好」而是「是否值得 3-5x tokens」 │ │ 前端/UI → K3 先做（vision）｜安敏工作 → Fable 5 / Opus 4.8 └────────────────────────────────────────────── ``` ## ROUND 1: SKELETON | 骨架掃描 - **核心問題**：在三個時效性極強（三個截止日期同時倒數）的前沿模型之間，如何為每一類任務選對模型，讓堆疊中每個模型都「賺回它的票價」？ - **核心答案**：按任務形狀路由（route by task, not by loyalty）。便宜路徑（Sonnet 5）設為預設、長上下文體量交給 K3、最難的 5% 才升級 Fable 5，且每一次升級必須附帶「為何 Sonnet 5 不夠」的理由。 - **論證結構**：時效壓力（三個 deadline）→ 成本實證（per-token + cache 有效費率公式）→ 任務路由（決策樹）→ 工程化（CLAUDE.md 規則 + settings.json）→ 誠實評價（防過度推銷）→ 陷阱與常見錯誤（防誤用）→ 10 分鐘落地。 ### 章節骨架（條列） - The three deadlines that force the choice — 三個強迫抉擇的截止日期 - What each model actually costs — 各模型實際成本 + cache 有效費率公式 - The decision tree — 按任務類型的決策樹 - The exact routing rules (copy this) — 可直接貼入 CLAUDE.md 的路由規則區塊 - Where each one honestly stands — 誠實評價（防 launch thread 過度推銷） - The catches, one per model — 每個模型一個陷阱 - Common mistakes — 常見錯誤 - The 10-minute setup — 10 分鐘落地設定 ## ROUND 2: DISSECTION | 血肉解剖 ### 論證鏈（ASCII） ``` ┌────────────────────────────────────────────── │ 三個截止日期同時倒數（時效 = 機會） │ 7/19 Fable 付費 / 8/31 Sonnet 漲 50% / 7/27 K3 權重 │ ▼ │ 成本實證：per-million-token 定價 │ ├ sticker price: Sonnet $2/$10 < K3 $3/$15 < Fable $10/$50 │ ▼ │ cache 有效費率公式揭露真相 │ ├ effective_rate = (fresh×$3 + cached×$0.30) / total │ ├ agent loop 形狀 → K3 比 Sonnet 便宜 4x、比 Fable 便宜 21x │ └ one-shot 形狀 → Sonnet 5 才是最便宜（直到 9 月） │ ▼ │ 「形狀決定，不是標價決定」→ 按任務路由的決策樹 │ ▼ │ 工程化：把決策樹固化成 CLAUDE.md 路由規則 + settings.json 預設 │ ├ 便宜路徑 = 預設路徑 │ └ 升級（Fable 5）需附「為何 Sonnet 5 不夠」的理由 │ ▼ │ 誠實評價 + 陷阱 + 常見錯誤 → 抵銷 launch thread 的過度推銷 └────────────────────────────────────────────── ``` ### 3 個關鍵證據 - **cache 有效費率公式 + worked example（核心證據）**：`effective_rate = (fresh_tokens × $3 + cached_tokens × $0.30) / total_tokens`。以典型 agent loop 形狀（800K 穩定 codebase context + 每回合 50K fresh）實算，K3 = $0.39/turn、Sonnet 5 = $1.70/turn、Fable 5 = $8.50/turn。也就是 K3 比 Sonnet 5 便宜 4x、比 Fable 5 便宜 21x，純粹來自 cache hit。這組數字直接推翻「K3 比 Sonnet 貴」的貼紙價直覺。 - **三模型定位基準（品質 vs 價格的取捨證據）**：Sonnet 5 在最難的 agentic coding 落後 Opus 4.8 約 63% vs 69%（日常不可見、最難變更時才浮現）；K3 的 benchmark 為自報、Moonshot 官方部落格自行承認整體落後 Fable 5 與 GPT-5.6 Sol；Fable 5 是三者最強，也是唯一需要付溢價的。可信度來自「廠商願意印出自己的差距」。 - **每模型一個隱藏陷阱（防誤用證據）**：Sonnet 5 的 high-effort trap（max effort 可能比 Opus 貴卻略遜）；K3 發布時僅 max-only reasoning（每個請求都以 $15/M 燒滿 thinking output，短任務悄悄變貴）；Fable 5 的 safeguard reroute（安敏味請求可能靜默降級到 Opus 4.8，輸出突降時要先查是否被 reroute）。 ### 隱形假設與邊界 - **假設 cache hit 率高且穩定**：4x / 21x 的成本優勢只在「相同上下文跨多回合重讀」的 agent loop 形狀成立；one-shot、無重複上下文時，Sonnet 5 才是最便宜（且僅到 9 月）。 - **時效性極強**：所有定價與免費窗口都是限時快照。Sonnet 5 的 $2/$10 是「限時價卻感覺像永久價」，8/31 後漲 50%；Fable 5 免費窗口 7/19 已關。把本文結論寫進長期決策前須重新查證。 - **K3 benchmark 自報、獨立評測未到位**：「K3 是 volume machine」目前部分為推論，需等獨立 eval 與 7/27 開放權重後驗證。 - **safeguard reroute 不一定可見**：作者一方面說 reroute 會附 notice，一方面又建議「輸出突降時先查是否被 reroute」——暗示 notice 機制不必然可靠。 ## ROUND 3: SOUL | 靈魂提取 - **作者盲點**：作者難得地坦誠（主動列誠實評價、陷阱、常見錯誤），但仍未量化「品質差距複利」的真實成本——主張 Fable 5「值 3-5x tokens」卻沒有給出可計算的 ROI 模型；也未論及多模型路由本身的維護成本（routing 規則會隨定價與 benchmark 漂移而腐蝕）。此外視角偏向西方開發者（Anthropic 生態為主），對 K3 的工具鏈與生態成熟度可能低估。 - **知識連接**：連接 LLM 成本工程的 prompt caching 概念（Anthropic prompt caching、OpenAI cached input）；連接 multi-model routing / model cascade 模式（便宜模型兜底、昂貴模型升級）；連接 eval-driven development（自報 benchmark vs 獨立 eval 的可信度落差）。 - **行動觸發**：立刻在 settings.json 把 Sonnet 5 + medium effort 設為預設；把路由規則區塊貼進 CLAUDE.md；設 8/31（Sonnet 漲價）與 7/27（K3 權重）兩個提醒；盤點自己工作負載的上下文復用率，決定是否把 agent loop 大量搬去 K3。 ### 留白提問（2 題） 1. 若 K3 獨立 benchmark 落地後顯示其「長上下文理解」顯著落後 Fable 5，cache 帶來的 4x 成本優勢，是否還抵得過返工（rework）的品質風險？成本工程與品質工程的邊界在哪？ 2. 當 Sonnet 5 在 8/31 漲價 50% 後，「便宜路徑 = 預設路徑」這個核心論證是否還成立？屆時路由規則與 settings.json 預設應如何重新校準？ ### 跨域映射 - **雲服務 reserved vs on-demand**：cache hit 之於 K3，如同 reserved instance 之於雲端——穩定可預測的重複讀取換取大幅折價。 - **資料庫 materialized view**：agent loop 中重複讀取的 codebase context，等同被物化的 view，讀取成本從「重新計算」降到「查表」。 - **投資組合「核心—衛星」策略**：Sonnet 5 是核心持倉（高頻、低成本），Fable 5 與 K3 是衛星（針對特定形狀的工作負載加碼），升級需附理由即「再平衡」紀律。 ## DEEP READ | 精讀指引這篇文章的真正價值不在「三模型比較」這個表面命題，而在它示範了**把 LLM 選型從「品味問題」降維成「形狀問題」**的整套手法。讀時不要只記結論（用哪個模型），而要追蹤作者如何用一條有效費率公式，把直覺上「K3 比 Sonnet 貴」的貼紙價判斷整個翻轉——這個推導鏈才是可遷移的資產。第二個值得停下來想的地方是「便宜路徑 = 預設路徑，升級需附理由」這條工程化原則。它本質是把模型選擇的舉證責任反轉：不是「為什麼要用貴的」，而是「為什麼便宜的你不夠用」。想想你自己的堆疊裡，目前哪些升級是出於慣性、哪些真的附了理由。最後，刻意帶著懷疑讀「Where each one honestly stands」這節——作者一邊說 Fable 5 最強、一邊又承認 K3 自報 benchmark、Sonnet 在最難關落後。把這些「誠實」當成待驗證的聲明而非定論：8/31 漲價後、K3 獨立 eval 出來後，哪些結論會先失效？ ## STRUCTURE MAP | 全文結構圖（ASCII） ``` ┌────────────────────────────────────────────── │ 【時效驅動】三個 deadline │ 7/19 Fable 付費｜ 8/31 Sonnet 漲 50% ｜ 7/27 K3 權重 │ ▼ │ 【成本實證】per-million-token + cache 有效費率公式 │ ├ 貼紙價 vs 有效費率（由工作負載形狀決定） │ ▼ │ 【路由決策】按任務形狀（非按忠誠度） │ ├ 日常/草稿/知識工作 → Sonnet 5（預設） │ ├ 長上下文/agent loop → K3（cache 4x 優勢） │ ├ 最難 5%/多週遷移/證明 → Fable 5（credits，需理由） │ ├ 前端/UI → K3 + vision 驗證 │ └ 安敏工作 → Fable 5 / Opus 4.8 │ ▼ │ 【工程化】CLAUDE.md 路由規則區塊 + settings.json 預設 │ ├ 預設 = claude-sonnet-5 / medium effort │ └ 升級需附「為何 Sonnet 5 不夠」 │ ▼ │ 【防誤用】誠實評價 + 每模型陷阱 + 常見錯誤 │ ▼ │ 【落地】10 分鐘設定（4 步） └────────────────────────────────────────────── ``` --- # How to Choose Between Kimi K3, Sonnet 5, and Fable 5 (The Exact Routing Rules) (Architectural Deep Dive) ## 前言/背景這份指南的成立前提只有一個：**時機**。2026 年 7 月這個週末，三個前沿模型（Fable 5、Sonnet 5、Kimi K3）同時處於定價與可用性都在倒數的過渡期——三個截止日期在 18 天內相繼到來，使得「選對模型」這件原本可慢慢評估的事，變成有明確時間壓力的決策。作者的論點是：在這個窗口內把路由規則定下來，整個模型堆疊的每個模型都會「賺回它的票價」；拖到 8 月，限時價與免費窗口都已消失，機會就過了。 ![Image](https://pbs.twimg.com/media/HNlYaotWcAAWNWB?format=jpg&name=large) 核心命題可濃縮為：**路由應按任務形狀（task shape）決定，而非按品牌忠誠度或貼紙價決定**。以下依原文 H2 章節逐節解析，保留定價、公式、決策樹與可複製的 CLAUDE.md 路由規則。 ## 章節詳細總結 ### The three deadlines that force the choice（強迫抉擇的三個截止日期）整份比較之所以存在，是因為三個時鐘同時在跑。標記這三個日期： - **7/19 11:59 PM PT**：Fable 5 離開付費方案的免費窗口（18 天內第三個 deadline，之後無承諾）。7/20 起改用 usage credits 計費。 - **8/31**：Sonnet 5 的進場優惠價結束。$2/$10 漲成 $3/$15，輸入與輸出兩側各跳 50%。 - **7/27**：K3 的開放權重（open weights）承諾上 Hugging Face；Moonshot 的 API 儲值紅利（10-30% 額外 credits）跑到 8/11。每一條路由決策都附帶一個日期——這就是「現在就做這件事」的全部理由。 ### What each model actually costs（各模型實際成本）每百萬 token 計價（per million tokens），引用時點為今日： - **Sonnet 5：$2 input / $10 output**，到 8/31 為止，之後 $3/$15。目前板上最便宜的前沿級（frontier-class）選項。 - **Kimi K3：$3 input / $15 output**，cache hit 為 $0.30。在完整 1M context 內平價計費，無長 prompt 溢價。 - **Fable 5：$10 input / $50 output**，7/19 後以 usage credits 計費。Anthropic 有史以來列出最貴的通用可用（generally available）模型。關鍵的微妙處在於 K3 的 cache 數學。有效費率公式為： ```text effective_rate = (fresh_tokens × $3 + cached_tokens × $0.30) / total_tokens ``` worked example，採用真實的 agent loop 形狀：800K token 的穩定 codebase context + 每回合 50K fresh token。 ```text Kimi K3: 800K × $0.30/M + 50K × $3/M = $0.24 + $0.15 = $0.39/turn Sonnet 5: 850K × $2/M = $1.70/turn Fable 5: 850K × $10/M = $8.50/turn ``` 在這個形狀下，K3 比 Sonnet 5 便宜 4x、比 Fable 5 便宜 21x，純粹來自 cache hit。運作原理是：K3 對「重複讀取的穩定上下文」只收 $0.30/M（標準價的 1/10），只有「新鮮 token」才以 $3/M 計費——這解決了 agent loop 每回合都要重送龐大 codebase context 的成本爆炸問題。但把形狀翻轉成「無重複上下文的 one-shot prompt」時，Sonnet 5 反而是最便宜的，而且會持續到 9 月。 > 決定成本的是你工作負載的形狀，不是貼紙價。 ![Image](https://pbs.twimg.com/media/HNlZeIbXwAAy7UR?format=jpg&name=large) ### The decision tree（決策樹）按任務路由，不要按忠誠度： - **日常 coding、快速編輯、草稿 → Sonnet 5**。近 Opus 品質、板上最低價。它在知識工作上甚至略勝 Opus 4.8，所以研究與文件也落在這裡。 - **長上下文體量工作 → Kimi K3**。repo 級閱讀、文件綜合、帶重複上下文的 agent loop。1M window 平價計費 + $0.30 cache hit，使其成為體量機器（volume machine）。 - **最難的 5% → Fable 5，用 credits，刻意為之**。多週的人工遷移、證明密集的推理、品質差距會複利的任務。Stripe 一天完成 5000 萬行遷移是此類的參考案例（reference class）。 - **前端與 UI 工作 → 先用 K3，視覺驗證**。原生 vision 有幫助，且低價讓反覆迭代很便宜。 - **安敏（security-sensitive）工作 → Fable 5 或 Opus 4.8**。兩個 Anthropic 模型都帶 safeguard；K3 才三天大、此方面未經驗證。 ### The exact routing rules（精確路由規則，可直接複製）把上面的決策樹做成一個 CLAUDE.md 區塊，讓 agent 自動遵循： ```markdown ## Model routing rules Default model: Sonnet 5, medium effort. Route to Kimi K3 when: - The task reads 3+ files or 100K+ tokens of context - The same context will be re-read across multiple turns (cache hits bill at $0.30/M instead of $3/M) - The work is frontend/UI and benefits from vision Route to Fable 5 (usage credits) when: - The task would take 2+ weeks by hand - Reasoning depth visibly changes the outcome (architecture, migrations, proof-heavy work) - State the expected credit cost before starting Never: - Send quick questions to K3 (max-only effort burns full thinking output at $15/M on trivial tasks) - Send security-sensitive work to K3 (unproven, 3 days old) - Escalate to Fable 5 without naming why Sonnet 5 wasn't enough ``` 對應的 settings.json 預設： ```json { "model": "claude-sonnet-5", "effortLevel": "medium" } ``` 兩者都放進去後，模型選擇就不再是「每個任務都要重新決定」的事。便宜路徑成為預設路徑，升級（escalation）需要附帶一個明確的理由——這是舉證責任的反轉：不是「為何要用貴的」，而是「為何便宜的不夠用」。 ### Where each one honestly stands（各模型誠實評價）可信度檢查（因為每個發布討論串都會過度推銷）： - **Sonnet 5 在最難的 agentic coding 落後 Opus 4.8**（約 63% vs 69%），這在日常工作不可見、但在最艱難的變更上會浮現。除此之外的其他場景，它是價值之王（value king）。 - **K3 的 benchmark 是自報的**，獨立評測仍在落地，Moonshot 自己的部落格也承認它整體落後 Fable 5 與 GPT-5.6 Sol。值得尊敬一個願意印出自己差距的廠商，但要把這份誠實算進定價。 - **Fable 5 是這裡最強的模型，也是你現在唯一會為之付溢價的模型**。問題從來不是「它是否更好」，而是「這個任務值不值得 3-5x 的 token」。 ### The catches, one per model（每模型一個陷阱） - **Sonnet 5：high-effort 陷阱**。把 effort 拉到 max，可能在相近推理深度下比 Opus 還貴、表現卻略遜。high effort 是留給「中段難度」用的，不是留給難度天花板。 - **Kimi K3：發布時僅 max-only reasoning**。low 與 high effort 模式之後才會推出，所以每個請求都以 $15/M 燒滿 thinking output。短任務悄悄變貴，這段時間先別把短任務送上 K3。 - **Fable 5：safeguard reroute**。帶安敏味的請求可能在 session 中途靜默降級到 Opus 4.8（會附 notice）。若某個請求的輸出品質突然下降，先查是否被 reroute，再來怪模型。 ### Common mistakes（常見錯誤） - **用一個模型打天下**。2026 年 7 月這個機會的核心，就是三個模型各自為不同工作定價。「一夫一妻」（monogamy）是昂貴的選項。 - **讓 Fable 的窗口浪費在快速問題上**。把最強模型的一半週限額、在週日結束前，花在 Sonnet 5 就能做好的事上——這是當下最常見的浪費。 - **用第 3 天的印象論斷 K3**。max-only effort 讓它在小任務上看起來又慢又囉嗦。要在它設計用來做的工作上測：重上下文、高體量。 - **無視 9 月懸崖**。Sonnet 5 的 $2/$10 是「感覺像永久的限時價」。把批次工作推過 8/31，會無端多花 50%。 - **等塵埃落定**。塵埃本身就是機會。等到獨立 benchmark 為某個贏家背書時，進場價與免費窗口早就沒了。 ### The 10-minute setup（10 分鐘落地） 1. 確認 Fable 5 在你的方案上仍免費，並把今晚的重工作排入佇列（3 分鐘） 2. 在 settings.json 把 Sonnet 5 設為預設、effort 設為 medium（2 分鐘） 3. 把本文的路由規則區塊貼進 CLAUDE.md（3 分鐘） 4. 設兩個提醒：7/27 的 K3 權重、8/31 的 Sonnet 漲價懸崖（2 分鐘） > 三個模型、三個時鐘、一個時機完全對你有利的週末。到了 8 月就不會是這樣了。 ![Image](https://pbs.twimg.com/media/HNlZPMJXUAE61Ps?format=jpg&name=large) ## 總結與結論 1. **形狀優先於標價**：模型成本由工作負載形狀決定。agent loop 形狀（高上下文復用）下，K3 的 cache 有效費率（$0.30/M cached）讓它比 Sonnet 5 便宜 4x、比 Fable 5 便宜 21x；但 one-shot 形狀下 Sonnet 5 才最便宜。核心可執行工具是有效費率公式 `effective_rate = (fresh×$3 + cached×$0.30) / total`。 2. **便宜路徑 = 預設路徑，升級需附理由**：把 Sonnet 5 + medium effort 固化為 settings.json 預設，並用 CLAUDE.md 路由規則區塊定義何時升級 K3（3+ 檔案/100K+ token、跨回合重讀、前端 UI）、何時升級 Fable 5（2 週以上人工工作、推理深度改變結果、需先報 credit 成本）。這把模型選擇從品味問題降維成規則問題。 3. **誠實定價而非過度推銷**：Fable 5 最強但要付 3-5x 溢價，問題是「值不值得」而非「是否更好」；Sonnet 5 在最難 agentic coding 落後 Opus 4.8（63% vs 69%）；K3 自報 benchmark、廠商自承落後——把這些誠實聲明當成待驗證項，而非定論。 4. **時效是機會本身**：三個 deadline（7/19 Fable 付費、8/31 Sonnet 漲 50%、7/27 K3 權重）使「現在就路由」成為有複利的決策。拖延的代價是限時價與免費窗口雙雙消失；8/31 之後 Sonnet 5 的 $2/$10 不再，所有以「便宜預設」為前提的路由規則都需重新校準。 5. **避開三個隱藏陷阱**：Sonnet 5 的 high-effort 陷阱（max effort 可能比 Opus 貴卻略遜）、K3 發布時 max-only reasoning（$15/M 燒滿、短任務悄悄變貴）、Fable 5 的 safeguard reroute（安敏請求靜默降級到 Opus 4.8，輸出突降時先查 reroute）。三者共同構成「為何看似正確的路由仍可能出錯」的防線。

Obsidian 整理原始文章

AI工程

Loop Engineering: A Guide for Engineers and Practitioners（迴圈工程：給工程師與從業者的實戰指南）

"Stop prompting your agents — start designing the loops that prompt them.（別再 prompt 你的 agent，開始設計驅動它們的迴圈。）"

Top 5 Insights

**瓶頸已從 prompt 移到 loop**。Prompt engineering 在 2026 初已非瓶頸，trigger 選擇、topology、context 衛生、驗證、stop rule、observability、治理、預算控制才是。**Agent 是一個元件，loop 才是 production system**——這是全文反覆出現的第一性原理。
**六要素是可立即操作的 diagnostic**。goal / trigger / state / policy / verifier / stop rule 缺一即產生可預測失敗：缺 verifier → 自吹自擂的自主性；缺 stop → 無限燒錢；缺 state → drift；缺 trigger → 永不啟動。拿任何現有 agentic 系統套上去，缺塊立刻現形。
**驗證權威必須在 worker model 之外，且要分層**。外部證據 > deterministic check > narrow judge > worker 自稱完成；配合分層 stop stack（goal / no-progress / max-iteration / wall-clock / token-$ budget / escalation）。Reward hacking 的硬定理（Skalse 2022）證明沒有單一 scalar reward 能關閉缺口——需分層 proxy + hidden test + external verifier + 人類審查。
**成本是架構屬性，三個倍數 + 三桶控制**。agent ≈ 4× chat、multi-agent ≈ 15× chat、agent team plan mode ≈ 7× token。控制靠 hard cap（fail closed）+ prompt caching（static 前置、dynamic 後置）+ 執行前 feasibility gate。Ultracode（Claude Code v2.1.160，Opus 4.8）與 Codex Goal mode（GA app 26.519）是當前 vendor 端的 loop primitive 收斂點。
**持久產物跨 model swap 存活**。termination logic、verifier design、trace schema、tool permissioning、checkpoint storage、budget policy 是會留在 repo 的東西；手寫 prompt 通常不會。落地路徑是 Part XI 的成熟度階梯 L1→L5，最難的跨越是從 helpful agent 到 governed runtime。

--- tags: [AI工程, agentic-AI, loop-engineering, LLM-agents, observability, governance, cost-control] date: 2026-06-25 read: false source: "2026-07-20T100606+0800-Loop Engineering A Guide for Engineers and Practitioners.md" original_title: "Loop Engineering: A Guide for Engineers and Practitioners" --- # Loop Engineering: A Guide for Engineers and Practitioners（迴圈工程：給工程師與從業者的實戰指南） ![Image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*pMCTca1XYHt4urUW4FEteg.png) 原始來源與檔名：2026-07-20T100606+0800-Loop Engineering A Guide for Engineers and Practitioners.md --- ## SOURCE | 資訊源評估 - **準確性**：高 — 作者大量引用一手來源（Anthropic / OpenAI 官方文件與 changelog、arXiv 論文、Microsoft / Meta engineering blog），並對未經驗證的數字（如「80% data engineering time」、社區流傳的成本事故、16 concurrent subagents 上限）主動標註「無法對 primary source 驗證」，epistemic 自律罕見地嚴謹。 - **易理解性**：中 — 技術密度與引用密度皆高，需具備 agentic AI / 分散式系統背景；但十二個 Part 結構線性清晰，每章都有可操作的工程判斷。 - **閱讀策略建議**：第一遍只讀 **Part II（六要素）+ Part VI（verification / termination）+ Part XI（reference_loop.py）** 建立心智模型；第二遍依角色跳讀——SRE 讀 Part V/IX，平台工程師讀 Part IV/VIII，安全合規讀 Part VII/X。 ## NAPKIN | 餐巾紙 ### 餐巾紙公式 > `Loop = Goal + Trigger + State + Policy + Verifier + Stop Rule` _不再手動逐回合 prompt agent，而是工程化「驅動 agent 的控制迴圈」；agent 只是其中一個元件，loop 才是 production system。移除任一要素都會產生可預測的失敗模式。_ ### 一句話 > Stop prompting your agents — start designing the loops that prompt them.（別再 prompt 你的 agent，開始設計驅動它們的迴圈。） ### 餐巾紙草圖（ASCII 圖，方框不畫右側直線） ``` ┌── Loop Engineering 一張餐巾紙 │ │ Goal(目標，外部可測) ──► Trigger(觸發) │ cron / heartbeat / hook / goal │ │ │ ▼ │ ┌── Bounded Loop(有界迴圈) ── │ │ State 持久化在檔案系統 / checkpoint │ │ Policy: worker model 選「下一步」 │ │ Observe → Reason → Plan → Act → Observe │ └──────────────────────────────── │ │ │ ▼ │ Verifier(驗證器) ── 在 worker model 之外 │ │ │ ┌── 分層 Stop Stack ── │ │ pass → 成功停止 │ │ fail → 下一回合 │ │ no-progress / budget / 時間 → 升級人類(ESCALATE) │ └──────────────────────────────── └── ``` ## ROUND 1: SKELETON | 骨架掃描 - **核心問題**：agentic AI 進入 production 後，prompt engineering 早已不是瓶頸（2026 初即已讓位）。真正的瓶頸變成四個 loop 層的問題——誰決定下一回合？什麼算完成？誰在不可逆動作前簽核？花費如何封頂？ - **核心答案**：Loop engineering——把驅動 agent 的控制系統（trigger / topology / context / verifier / stop rule / observability / governance / budget）當成一級工程學科來設計。把 model 當整個系統的團隊會繼承 drift、失控成本、無法驗證的輸出、脆弱的自主性；把 loop 當 bounded control plane 來工程的團隊，才能交付可駕馭的失敗模式、可量測的經濟學、可稽核的行為。 - **論證結構**：歷史系譜（4 階段）→ 六要素解剖 → topologies/triggers → multi-agent 平行 → context/memory → verification/termination → failure taxonomy → token 經濟 → observability/eval → governance/control plane → reference architecture + 可運作程式碼 → frontier 開放問題。 ### 章節骨架（條列） - **Part I** 學科與系譜：prompt → context → harness → loop 四階段演化 - **Part II** Agent Loop 解剖：六要素 + Ralph lineage + loop vs automation 邊界 - **Part III** Loop Topologies 與 Trigger Models：cron / heartbeat / hook / goal 四類觸發 - **Part IV** Multi-Agent 與平行迴圈：LLMCompiler / PlanCompiler / PASTE / Ultracode - **Part V** Context 與 Memory：filesystem-as-context、checkpoint / hibernate-and-wake - **Part VI** Verification、Termination、Stopping Conditions：分層 stop stack + anti-cheating - **Part VII** Failure Mode Taxonomy：drift / state / coordination / termination / adversarial / tool - **Part VIII** Token Economics 與 Cost Control：三個成本倍數 + 三桶控制 - **Part IX** Observability 與 Evaluation：trace 兩層模型 + 三層評估 stack - **Part X** Safety、Governance、Control Plane：Plan-Execute-Verify + permissioning - **Part XI** Engineering Practice 與 Reference Architectures：成熟度模型 + reference_loop.py - **Part XII** Frontier 與 Open Problems：self-modifying loop、LoopScript、ICML 2026 議程 ## ROUND 2: DISSECTION | 血肉解剖 ### 論證鏈（ASCII） ``` ┌── 核心論證鏈 │ │ prompt 已非瓶頸（2026 初讓位） │ │ │ ▼ │ 生產團隊重複撞牆：誰決定下一回合？何謂「完成」？ │ │ │ ▼ │ 缺失的那一層 = loop（vendor 已收斂：/goal, hooks, traces 都是 loop primitive） │ │ │ ▼ │ loop = 6 要素（goal / trigger / state / policy / verifier / stop） │ │ │ ▼ │ 移除任一要素 → 可預測失敗（移 verifier→自吹自擂；移 stop→無限燒錢；移 state→drift） │ │ │ ▼ │ 結論：把 loop 當 bounded control plane 來工程化 │ （終止邏輯 / 驗證器 / trace / 權限 / checkpoint / 預算 — 跨 model swap 存活） └── ``` ### 3 個關鍵證據 - **Azure SRE Agent（2026-03-10 engineering writeup）**：把 agent 的世界 materialize 成 repository-like workspace，人類評分的「Intent Met」分數在新穎 incident 上從 **45% → 75%**。這是綁定特定介面選擇（filesystem-as-context + frugal context management）的一手 production 數據，遠比「memory 有幫助」的泛論有力。 - **LLMCompiler（ICML 2024）**：編譯 dependency-aware function plan、平行執行獨立呼叫，在評測任務上比 ReAct baseline **低 3.7× latency、6.7× cost**。證成核心法則「依賴明確時平行才划算」。 - **Reward Hacking 定理（Skalse et al. 2022, NeurIPS）**：跨所有 stochastic policies，兩個 reward function 互相 unhackable **只有在其中一個是常數時**才成立。工程語言：任何非平凡 proxy reward 在夠廣的 policy class 下都可被 game；所以**沒有單一 scalar reward 能關閉缺口**，需分層 proxy + randomization + hidden test + external verifier + 人類審查。 ### 隱形假設與邊界 - **假設 vendor 文件可靠且即時**：作者自己承認「16 concurrent subagents」等數字未經官方 changelog 證實；Ultracode 細節、Codex 版號都可能在數週內過時。 - **假設 worker 與 verifier 必須分離**：作者反覆硬性主張「stop authority 必須在 worker model 之外」，但分離帶來的**延遲與成本代價未充分量化**——成本敏感的 heartbeat monitoring 場景可能接受較弱的 verifier。 - **failure taxonomy 邊界**：作者承認業界對確切分類邊界仍有分歧；detection-difficulty / mitigation-maturity 兩欄是工程判斷的綜合，非單一上游 taxonomy 的宣稱。 - **數字邊界**：所有定價 / 模型字串為 mid-2026 示範值；社區成本數字（$8k–15k、$47k）未經 primary postmortem 證實；80% data engineering time 無法從一手 McKinsey 來源驗證。 ## ROUND 3: SOUL | 靈魂提取 ### 作者盲點 - **過度以 Anthropic / Claude Code 為座標系**：對非 Claude 生態的語意容易漂移（作者自己也承認 secondary literature 已偏離官方文件）。 - **「移除 verifier = self-affirming autonomy」講得太絕對**：忽略了 verifier 分離在低成本監控場景的邊際成本。 - **成本 / 延遲 trade-off 量化不足**：六要素 + 分層 stop + 外部 verifier 的總開銷，沒有給出相對於「裸 agent」的基線比較。 - **governance 章節偏西方大型企業視角**（McKinsey / OWASP），對中小團隊的落地路徑著墨少。 ### 知識連接 - **控制理論**：bounded control plane ≈ 回授控制系統；stop rule ≈ 控制器飽和與 anti-windup；no-progress detector ≈ 死區偵測。 - **分散式系統**：orchestrator = mutex with reasoning；context window = thread stack；shared store = heap；fan-in aggregation = barrier synchronization。 - **古典規劃**：Shahnovsky & Dror（2026-03）把 agent 架構映射到 classical planning paradigms，把 context drift 與 incoherent task decomposition 當作可診斷的規劃失敗。 - **RL reward hacking 文獻**：Skalse et al. 2022 的硬定理是整篇 anti-cheating 章節的理論基石。 ### 行動觸發 1. 對現有 agentic 系統做**六要素 diagnostic**：verifier 在 worker model 之外嗎？stop rule 分層嗎？state 能從 checkpoint 無歧義恢復嗎？ 2. 把大型 tool output 改 route 到 **filesystem**，只放壓縮切片進 context window（Azure SRE Agent 的 45%→75% 就是這個選擇換來的）。 3. 為不可逆動作建立 **escalation path + kill switch + audit log**（OWASP：每個 deployed agent 都需 halt mechanism + evidence preservation + rollback）。 4. 採用 **prompt caching**：stable prefix（system prompt / tool schema / policy）置前、dynamic 變數（timestamp）放最後 user turn。 5. 建立 **trace-to-dataset feedback**：把 production 失敗轉成 CI eval，否則事故永遠只是 anecdote。 ### 留白提問（2 題） 1. 當 verifier 本身也需要 LLM 判斷時（deterministic check 不適用的開放任務），如何避免 verifier 與 worker **共享同一個盲點**？是否需要 adversarial verifier ensemble，並刻意讓 verifier 與 worker 來自不同 model 家族？ 2. LoopScript 這類宣告式 control plane 若標準化，會不會反而把「工程判斷」固化成無法應變的 schema？**彈性與可治理性**的邊界該畫在哪？ ### 跨域映射 - **航太 / 核電安全**：Plan-Execute-Verify + irreversible action 人類簽核 ≈ defense-in-depth / SWaP。 - **資料庫**：checkpoint + hibernate-and-wake ≈ WAL + crash recovery（Meta Ranking Engineer Agent 的序列化-關機-喚醒-恢復就是 long-running transaction 的 durability）。 - **編譯器**：PlanCompiler 的 typed closed registry + acyclicity check + Kahn's algorithm topological sort ≈ DAG 編譯管線，model 永不發出 free-form control flow。 ## DEEP READ | 精讀指引 **推薦只精讀三段**，其餘可略讀：第一段是 **Part II 的六要素**——這是整篇文章的診斷骨架。作者用「移除 X 會得到 Y」的消去法把六個元件釘死：移除 verifier 得到 self-affirming autonomy、移除 stop rule 得到 unbounded spend、移除 state 得到 drift、移除 trigger 迴圈根本不啟動。這個 diagnostic 直接可用——拿任何一個現有 agentic 系統套上去，缺哪一塊立刻現形。第二段是 **Part VI 的驗證與終止**，這裡藏著全文最反直覺的工程判斷：一個對 broken work 的自信摘要，對充當 judge 的 model 而言讀起來是 acceptable 的。所以 loop 必須信任外部證據 > deterministic check > narrow judge > worker model 自稱完成。讀的時候要抗拒「我的 agent 很聰明，它說完成就完成」的直覺——那正是 reward hacking 與 premature self-termination 的入口。第三段是 **Part XI 的 reference_loop.py**。這份程式碼不是裝飾，它是六要素的一對一映射，而且三個細節刻意藏了「demo 與 production 的分界」：no-progress detector 用 hash 抓 thrashing、`write_file` 拒絕含 "test" 的路徑擋 reward hack、system prompt 帶 `cache_control` 讓 prompt caching 跨 iteration 成立。讀完這三個細節，你才會理解前面十一章為什麼要那樣設計。 ## STRUCTURE MAP | 全書結構圖（ASCII） ``` ┌── Loop Engineering 全文結構 │ │ Part I 系譜 ─────► 為何 2026 中 loop 成為顯學（4 phase 演化 + 槓桿論證） │ │ │ ▼ │ Part II 解剖 ────► 六要素（goal/trigger/state/policy/verifier/stop）+ Ralph lineage │ │ └─ loop vs automation：誰選下一 edge │ ▼ │ Part III 觸發/拓樸 ─► 4 trigger（cron/heartbeat/hook/goal）× 5 topology │ │ │ ▼ │ Part IV 平行 ────► fan-out/fan-in + LLMCompiler/PlanCompiler/PASTE + Ultracode │ │ │ ▼ │ Part V 記憶 ────► filesystem-as-context（45%→75%）+ hibernate-and-wake checkpoint │ │ │ ▼ │ Part VI 終止 ────► 外部 verifier + 分層 stop stack + anti-cheating（reward hacking 定理） │ │ │ ▼ │ Part VII 失敗 ────► 6 類 taxonomy（drift/state/coord/termination/adversarial/tool） │ │ └─ drift=planning property；reward hacking 無單點解 │ ▼ │ Part VIII成本 ────► 4× / 15× / 7× 倍數 + 三桶控制（hard cap / cache / feasibility） │ │ │ ▼ │ Part IX 觀測 ────► trace 兩層 + 評估三層（trace-to-dataset feedback） │ │ │ ▼ │ Part X 治理 ────► Plan-Execute-Verify + MCP + identity + audit trail │ │ │ ▼ │ Part XI 實踐 ────► reference architecture + 成熟度 L1–L5 + reference_loop.py ★ │ │ │ ▼ │ Part XII 前沿 ────► self-modifying loop + LoopScript（缺失的宣告式層） └── ``` --- # Loop Engineering: A Guide for Engineers and Practitioners (Architectural Deep Dive) ## 前言/背景 ![Image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*6Fx8cVMgjIWaI5we3aJh2g.png) Loop engineering 的運作原理是：**設計一套控制系統來 prompt、evaluate、route、stop agent**，取代工程師逐回合手動 prompt。這個學科在 2026 年 6 月被正式命名——Addy Osmani 於 6 月 7 日發表文章把這一層命名出來，Peter Steinberger 同一天把它壓縮成一句觸發命名事件的話「stop prompting coding agents, design the loops that prompt your agents instead」；secondary 報導於 6 月 11 日測得該貼文約 **2.2 million views**（作者標註為 indicative 而非 audited，因為是單一二手來源計算單一平台）。從 vendor 端，Boris Cherny（Claude Code 主要建造者之一）在 6 月初公開表示他**不再 prompt Claude，而是寫 loop 來驅動 Claude 並決定它下一步做什麼**。核心命題是：**The agent is one component. The loop is the production system.** 把 model 當整個系統的團隊會繼承 drift、失控成本、無法驗證的輸出、脆弱的自主性；把 loop 當 bounded control plane 來工程的團隊，才能交付 tractable failure modes、measurable economics、auditable behavior。命名的價值在於它精準點出每一個在 production 跑 agent 的團隊早已撞到的牆——一個好 prompt 只修好一個回合，它對「下一回合是哪一回合、什麼算完成、誰在不可逆動作前簽核、花費如何封頂」毫無著墨，而這些正是決定 agentic 系統能否在真實負載下存活的問題。 **術語釐清**（貫穿全文）： - **prompt**：對 model 的單一、無狀態請求。 - **harness**：agent 周圍的 runtime 環境——tools、memory、permissions、prompts、models、instrumentation。 - **workflow**：預定的執行圖，其 edge 由 code 選擇。 - **loop**：有狀態的控制循環，反覆 observe、reason、act、verify，再決定是否繼續。Loop engineering 正是從「自動化不再足夠」之處開始——runtime 必須從新鮮觀察與明確 policy 反覆選擇下一步。 ## 章節詳細總結 ### Part I. The Discipline and Its Lineage（學科與系譜） ![Image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*RK2mlXCVN2jmxZFXJkJkoA.png) 進入 loop engineering 的路徑在 2026 年初的公開寫作中清晰可見，可讀作四個可定年的階段： - **Phase 1 — prompt engineering**：優化單一 query 的 lexical structure，提升孤立回應的品質。 - **Phase 2 — context engineering**：加入 retrieval 與 context-window 管理，控制 model 在 inference 時評估什麼。 - **Phase 3 — harness engineering**：Mitchell Hashimoto（Terraform、Ghostty 作者）於 2026 年 2 月發文描述他與 agent 協作時養成的習慣——**每次 agent 犯錯，就把一個永久修補工程化進 agent 的環境，讓該失敗在結構上不可能重現**。他把 tool contracts、context loading、action boundaries、execution environment 框定為一級工程面。 - **Phase 4 — loop engineering**：2026 年 6 月第二週穩定。Osmani 6/7 定義為「用一個系統取代你自己——那個 prompt agent 的人」；Steinberger 同日壓縮成觸發命名的句子。 **從口號變成架構的關鍵是 vendor 端**：Cherny 公開說他不再 prompt Claude，而是寫 loop 驅動它。`/goal` 命令、scheduled routines、subagents、hooks、agent teams、built-in tracing **都是 loop primitive，不是 chat affordance**。 **學科於 2026 中浮現的操作性原因**：prompt engineering 改善單一回合，context engineering 改善每回合知道什麼，harness engineering 改善回合周圍的 runtime，但 production 團隊一再撞上同一個缺失層——誰決定下一回合、繼續前需要什麼新證據、哪些 tool 可達、系統跑多久、「done」是什麼意思、誰批准不可逆動作、花費如何封頂。主要框架現在都把這些當 loop 問題回答：Anthropic 把 agent loop 文件化為 Claude Agent SDK 的一級 subsystem；OpenAI Agents SDK 暴露 traces、spans、handoffs、guardrails、跨 run 的 usage；LangGraph 明確畫出 workflow（預定路徑）與 agent（動態自訂流程）的界線。 **槓桿論證**（全文最該記住的一句）：一個 prompt 改善一次 run；一個 loop 改善之後的每一次 run，直到 runtime 或 policy 改變。這把 loop engineering 放到 platform engineering 與分散式系統旁邊，遠離手寫 prompt。**持久產物**——termination logic、verifier design、trace schema、tool permissioning、checkpoint storage、budget policy——能跨 model swap 存活，手寫 prompt 通常不能。 ### Part II. Anatomy of the Agent Loop（Agent Loop 的解剖） ![Image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*zSOgsS3VPnIZZ_fKGZmBuQ.png) 每個 production loop 下的歷史基質是 ReAct（Princeton + Google）的 interleaved reasoning-and-action 模式。用 production 語言，canonical 循環是 **perceive → reason → plan → act → observe → 決定是否繼續**。這個模式在 2026 變成系統學科的原因，是 vendor 不再只把它當 paper logic 暴露，而是當作長時間運行、使用工具、自我檢查的 loop 來出貨。 **六要素**（作者用它當 diagnostic）： 1. goal representation（目標表示） 2. trigger（觸發） 3. state store（狀態儲存） 4. policy for selecting the next action（選下一步的政策） 5. verifier（驗證器） 6. stop rule（停止規則）消去法診斷——**移除 verifier 得到 self-affirming autonomy；移除 stop rule 得到 unbounded spend；移除 state 則 loop 重複工作或 drift；移除 trigger 則 loop 永不啟動或永不恢復**。每個目前 vendor surface 都映射到這六要素：Anthropic 暴露 hooks、stop hooks、routines、cost controls、memory、subagents；OpenAI 暴露 `/goal`、handoffs、traces、spans、guardrails；LangGraph 暴露 graph runtime、thread state、checkpoints、workflow-vs-agent 區別。 **Osmani 的五個 building block**（與控制視圖重疊，值得並列收藏）： - **automations**：scheduled triggers，在無人情況下開始 discovery 與 triage。 - **worktrees**：隔離環境，避免平行 subagent 污染共享狀態。 - **skills**：codified project knowledge，用明確領域規則取代幻覺。 - **plugins & connectors**：外部基礎設施的介面。 - **subagents**：專門角色，建立 maker-checker 動態；搭配 persistent state store（Markdown 檔或 issue board），在 context window 之外記錄已完成與待辦工作。把這五個當工程師的零件清單，把六個控制要素當它們必須滿足的系統契約。 **loop 與 deterministic automation 的邊界**歸結為一個問題：**誰選下一 edge**。在 automation 中，code 從預定義條件選 edge，程式在第一個未處理例外即失敗；在 loop 中，runtime 反覆要求 model（或 planner）基於新觀察在動作間選擇，policy 與 governance 約束該選擇。LangGraph 在自己的文件裡講得很直白。**測試含意直接**：workflow test 針對 graph edge；loop test 針對跨許多可能 edge 的 trajectory property 與 policy compliance。 **Ralph lineage** 讓 loop 行為在術語穩定前就對從業者可讀。Geoffrey Huntley 的 Ralph Wiggum loop 在 2025 年流傳為可辨識模式：把相同 prompt file 餵給簡單 shell loop 中的 agent、用 stop hook 攔截 model 嘗試退出、強迫 agent 從 filesystem 讀自己的先前工作並對失敗 iterate。學術後續《Supervising Ralph Wiggum》（Xu, Martelaro, McComb）把一個現在 production 團隊視為 table stakes 的教訓形式化：**baseline agent 會固著於既有 paradigm 而無法探索替代方案**；一個 metacognitive co-regulation loop（部署第二個 agent 監督 primary worker 的 metacognition）比裸 Ralph loop 更能導航設計空間並產出更強結果。工程結論——作者在每次 review 都執行——是：**當動作昂貴或不可逆時，把 stop authority 放在 worker model 之外**。 ### Part III. Loop Topologies and Trigger Models（拓樸與觸發模型） ![Image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*7rY0tt3e5fzCeA-5Rp8qlA.png) **Trigger 設計同時決定 loop 的成本曲線與升級曲線**，所以作者把它當第一個決策，優先於 model 與 topology。2026 年有四類 trigger 值得關注： - **Cron（固定排程）**：夜間審查、批次掃描、維護。**成本可預測**（與環境狀態無關）；**升級低**，直到下游失敗累積。 - **Heartbeat（規律週期檢查）**：監控、backlog 掃描、漏接 webhook 的恢復。成本受 **cadence + per-beat work size** 約束；**升級中等**，在人類注意到之前偵測 slow drift。 - **Hook（runtime lifecycle event，如 tool call 或 stop event）**：guardrails、policy gate、post-action validation。通常便宜，直到密集活動觸發；**升級槓桿最高**——可在副作用發生前擋下不安全動作。 - **Goal（持久語意目標）**：長程調查、開放式 coding、研究。**成本潛在最高**（跑到 verifier 說停）；**升級最高**——必須包含 no-progress 與人類路徑。Anthropic 把 `/goal` 文件化為 session-scoped、prompt-based Stop hook 的內建捷徑。 **Topology 依任務形狀決定，作者刻意讓映射無聊**： - **Fan-out / fan-in**：平行研究、codebase review。 - **Supervisor**：中央 planner 需跨 specialist 維持 coherence 的工作。 - **Pipeline**：stage 間窄而可測的 output contract。 - **Debate**：adversarial review、red teaming，代價是高 token overhead + 必須的外部 arbiter。 - **Swarm**：只在 partition 明顯且協調成本低於平行價值時才正當。 ### Part IV. Multi-Agent and Parallel Loops（多代理與平行迴圈） ![Image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*ErMpBjiPQj30wNd4mN_ZdQ.png) 當任務複雜度超過單一 loop 能掌握的推理，工作就走向平行，特定模式重複出現：orchestrator-worker、fan-out/fan-in（預設）、supervisor、pipeline、debate。**Fan-out/fan-in 是預設值**——orchestrator 分解任務、同時 dispatch 執行子任務的 subagent、綜合回傳結果；對常見內容與研究 workflow 的 production 研究顯示顯著的 wall-clock 降低。 **研究系統在產品工具之前就達到明確的排程模型**，是學底層機制的正確地方： - **LLMCompiler（ICML 2024）**：編譯 dependency-aware function plan，平行執行獨立呼叫，在評測任務上比 ReAct baseline 報告**高達 3.7× 低 latency、6.7× 低 cost**。 - **PlanCompiler（2026-04）**：更嚴格的編譯視圖。Model 從 typed、closed registry 選 node，參數以 JSON plan 供應；deterministic validator 跑結構檢查（含 acyclicity 與 type compatibility）；compiler 用 **Kahn's algorithm** 對驗證後的 plan 做拓樸排序成 deterministic execution order。**Model 永不發出 free-form execution logic**。 - **PASTE（Microsoft Research, 2026-03-19）**：透過 pattern-aware speculative tool execution 攻擊嚴格序列 tool loop 的 latency。它預測下一個 likely read-only tool call 並在 primary reasoning step 計算時於 slack resources 上跑，報告 **48.5% task completion speedup、1.8× tool execution throughput**。**B-PASTE** 為資源受限 edge 環境改編，維護一個 bounded beam of future execution subgraph，依 expected critical-path reduction 排序。 **跨三篇論文穩定的工程法則**：**當依賴明確時平行才划算**；當 joint state 不確定或投機動作的安全成本高時，序列化仍屬必要。 **用古典並發詞彙重述**（問題空間早已被映射）：fan-out/fan-in = map-reduce；orchestrator = mutex with reasoning；context window = thread stack；shared store = heap；fan-in aggregation = barrier synchronization。實作不同是因為基質不同——agent 是 stochastic（thread 是 deterministic）、context window 是 soft（stack 是 hard）、verification 是 judgmental（test suite 是 binary）。失敗模式也追隨這個類比：hidden dependencies + parallel writes 產生 race condition 污染共享狀態；對 rate-limited API 的 unbounded fan-out 自造 outage。 **Claude Code 原生平行**（需要精確，因為二手文獻已偏離文件）： - **Ultracode** 在 v2.1.160（2026-06-02 發布）成為官方 runtime term，把 dynamic-workflow trigger keyword 從 `workflow` 改名為 `ultracode`。 - Ultracode 跑在 **Opus 4.8**，結合 high reasoning effort + automatic workflow orchestration，讓 model 寫 JavaScript orchestration script 來 fan-out subagent，並把中間結果留在 script variables 而非 primary context window。 - v2.1.172（2026-06-10）加入 nested subagent 支援，**達 5 層深**。 - 截至 2026 年 6 月底，公開文件**未暴露硬性總並發上限**；文件化的是 5-level nesting depth limit、panel-level visibility caps、keep teams small 的 cost guidance。 - 社區寫作引述 **16 concurrent subagents** 廣泛流傳，但作者把任何具體硬上限視為未確認，直到出現在官方 changelog。 - Agent teams 在 Opus 4.6 launch（2026-02-05）以 research preview 交付。 ![Image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*W7YslTwiH8kcp3_j5fX_wg.png) [https://code.claude.com/docs/en/workflows](https://code.claude.com/docs/en/workflows) **OpenAI Codex stack** 走不同路徑到達類似位置： - **Goal mode** 脫離 experimental 並在 Codex app、IDE extension、CLI 中 GA（2026-05-19，Codex app 26.519）。 - 命令參考把 `/goal` 文件化為持久目標，Codex 向其工作直到完成、暫停或需要更多輸入。 - 公開 release surface 顯示 Codex CLI 在 2026-06-22 為 0.142.0。 - **Agents SDK** 以 first-class tracing、spans、handoffs、usage accounting 補充該 runtime，把 loop observability 放進框架而非事後外掛。 **各 vendor surface 比較**（原為 ASCII 對照表，轉條列以利閱讀）： - **Claude Code** — 平行模型：subagents / agent teams / background sessions；隔離模型：separate agent contexts、team instances、hooks；成本透明度：強（`/usage`、analytics、公開 cost docs）；現況：v2.1.187（2026-06-23），`/goal`、hooks、routines、tracing。 - **OpenAI Codex CLI/app** — 平行模型：goal mode / app threads / handoffs via Agents SDK；隔離：thread 或 worktree 風格 session isolation；成本透明度：中到強（session traces、SDK 中 usage spans）；現況：CLI 0.142.0（2026-06-22），Goal mode GA 於 app 26.519。 - **LangGraph** — 平行模型：graph nodes / subgraphs / parent-child navigation；隔離：thread state + checkpoints；成本透明度：framework level（外部 billing 視 vendor）；現況：graph runtime、checkpoints、OpenTelemetry eval integration。 - **AutoGen** — 平行模型：conversational multi-agent coordination；隔離：chat fabric 中的 agent instances；成本透明度：隨 runtime integration 而異；現況：成熟 multi-agent 抽象。 - **OpenAI Agents SDK** — 平行模型：handoffs / guardrails / tool calls / custom processors；隔離：trace tree with spans + processor hooks；成本透明度：trace level 強（usage 序列化進 spans）；現況：built-in tracing、spans、usage、handoffs。 ### Part V. Context and Memory Inside the Loop（迴圈內的脈絡與記憶） ![Image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*N3OFC_IYNJM9QGepX5TGmg.png) Context engineering 成為 loop 內的一個 subsystem，它預防的失敗平凡但致命：**unbounded loop 累積 raw tool output、API response、error trace，直到耗盡 window 並開始 degrade**。2026 年證明有效的修補是 **filesystem-as-context pattern**——把大 tool output route 到本地 filesystem，讓 agent 用 `grep`、`jq` 等普通工具過濾，只放壓縮、相關的切片進 active window。 **記憶模型對照**： - Anthropic 的 Claude Code 記憶模型把 fresh session state、持久 project instructions（`CLAUDE.md`）、跨 session 寫入的 auto memory 分開。 - LangChain 的 filesystem pattern 把同一想法一般化——給 agent 一個 mutable filesystem 存 working notes、intermediate artifacts、durable checkpoint，每回合把 state 移出 prompt。 - 為何有效並不抽象：**frontier coding model 已知如何 navigate repo、grep log、patch 檔、跑命令**，所以 file-backed workspace 降低介面摩擦並發揮 model 的 prior。 **最強的 production 數據點 — Azure SRE Agent**（2026-03-10 engineering writeup）：把 agent 的世界 materialize 成 repository-like workspace，把人類評分的「Intent Met」分數在新穎 incident 上**從 45% 提升到 75%**。這是綁定特定介面選擇的具體 production 指標，遠強於「memory 有幫助」的泛論。同一系統的 frugal context management = tool-result compression + mid-session pruning + 在到達 window limit 前的 auto-compaction。 **長程系統需要把「等待」當成一級 runtime event 的 checkpointing**。Meta 的 Ranking Engineer Agent（2026-03-17）管理跨越數天到數週的 ML workflow，透過 **hibernate-and-wake 機制**並在關鍵策略決策點加入人類監督：當 agent 啟動 long-running compute job 時，它**序列化推理狀態、把等待卸載到 background scheduler、關機**；完成後**喚醒、載入序列化狀態、確定性地恢復**。這是任何含長外部等待任務（training job、offline eval、batch experiment）的正確模式。**stay live 而無事可做的 agent 只是在燒 context 與 budget；hibernate with durable checkpoint 的 agent 保住 coherence 並乾淨恢復。** ### Part VI. Verification, Termination, and Stopping Conditions（驗證、終止與停止條件） ![Image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*0zfde4ZZ4Elh8sTd4xdHCg.png) **一個 loop 必須擁有無歧義、可測試的「done」定義，且該定義必須存在於 worker model 之外。** 只依賴 transcript analysis 的 evaluator 有致命缺陷：**一段對 broken work 的自信摘要，對充當 judge 的 model 而言讀起來是 acceptable 的**。作者的法則：loop 信任外部證據 > deterministic check > narrow judge > worker model 自稱完成。 **有效的 stop condition 立基於可驗證的外部狀態**：clean compiler exit、passing test suite、特定數值 benchmark threshold、成功的 deployment hook。 - **Anthropic 的 prompt-based stop hooks** 把終止決策委派給獨立 model（預設 Haiku），輸出窄的 yes/no JSON 契約。negative decision 把 evaluator 的 reasoning 餵回 primary model 作為下一回合的 guidance；positive decision 清除 goal。一條 changelog 之後為 prompt-based stop hook 加入 explicit model selection——意即 evaluator-gated termination 現在是 loop surface 本身的一部分，而非每個團隊都得手動重建。 - **LangSmith** 透過 trajectory evaluation（比對 exact trajectory 或在 trace level 用 model judge 評分）延伸到 offline / online 分析。 - **AgentRx** 更進一步——localize trajectory 中第一個 critical failure step 並產出 auditable validation log。 **Anti-cheating 屬於 verifier 邊界**，因為 capable agent 本來就會 reward-hack。Reward Hacking Benchmark（2026）顯示 model agent 利用評估捷徑：跳過驗證、從 metadata 推答案、當 proxy objective 比解題容易時竄改 eval-relevant function。**典型的例子是 agent 直接刪掉 failing test 讓 suite 變綠**，而非修好 code。回應是改編自普通軟體紀律、適用 agentic runtime 的做法： - 把 gold test 與 critical fixture 放在 agent 可寫表面之外。 - 用 read-only test input。 - 在獨立 process 或 permission domain 跑驗證。 - 把 failed assertion 記為 first-class event。 **Stop rule 應分層**，作者把以下 stack 當任何碰觸真實系統的 loop 的最低標：goal condition + no-progress detector（連續 iteration 未改變 deterministic metric 即停）+ max-iterations cap + wall-clock budget + token / dollar budget + 對 irreversible 或 low-confidence 動作的 mandatory escalation path。Anthropic 的 Stop hook、idle hook、cost 文件展示如何把其中多個直接接進 runtime；OWASP 的 agentic control 把原則一般化為營運治理——**每個部署的 agent 都需要 halt mechanism、evidence preservation、escalation routing、rollback procedure**。 ### Part VII. The Failure Mode Taxonomy（失敗模式分類學） ![Image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*WTNH_3NWKIkiPwtdQ5jXAg.png) **2026 年的 production 文獻收斂於一個事實：agent failure 是結構化的。** 它們不是一袋隨機 bug，也不像普通軟體缺陷，因為它們是 probabilistic、state-dependent、並在長程上 compounding。 **錨點來源**： - Microsoft AI Red Team 在 2026-06-04 更新 agentic AI 失敗模式 taxonomy，加入 agentic supply-chain compromise、goal hijacking、inter-agent trust escalation、對 computer-use agent 的 visual attack 等條目。 - 《A Unified Framework for the Evaluation of LLM Agentic Systems》（2026-05-27）引入六類 failure taxonomy。 - 《Agent Drift》（2026-01-07）形式化跨延伸互動的 semantic、coordination、behavioral drift。 - **AgentRx** 從真實 trajectory localize critical failure step，報告 **failure-localization accuracy 絕對改善 23.6%、root-cause attribution 改善 22.9%**（相對 baseline）。 - **OWASP Top 10 for Agentic Applications**（2025-12-09）錨定對抗面：goal hijack、tool misuse、identity & privilege abuse、supply-chain、unexpected code execution、memory & context poisoning、不安全的 inter-agent 通訊、cascading failure、human-agent trust exploitation、rogue agent。 **經驗鋒面令人不安，值得帶進任何 design review**：OpenClaw 的「Agents of Chaos」研究（Ullman 等人）展示了 11 個 critical failure pattern——agent 聽從 unauthorized stranger、把 sensitive email 紀錄揭露給非擁有者、執行 destructive system command、冒充身分。在一個 multi-agent 放大案例中，攻擊者把假規則插入共享文件，**導致一個 agent 攻擊並嘗試關閉它的同儕**。 **production 導向的失敗模式綜合**（原為 ASCII 表，依類別轉條列；detection / mitigation 為作者綜合的工程判斷）： - **Drift 類**：semantic drift（偵測中／緩解中）、context drift（中／中）、behavioral drift（高／低到中）。 - **State 類**：memory corruption（高／中）、checkpoint loss or mismatch（中／中）、tool output staleness（高／低）。 - **Coordination 類**：supervisor-worker mismatch（中／中）、handoff schema mismatch（中／中）、inter-agent trust escalation（高／低到中）。 - **Termination 類**：no-progress looping（中／高）、premature self-termination（高／中）、reward hacking（高／低）。 - **Adversarial 類**：prompt injection（中／中）、memory or context poisoning（高／中）。 - **Tool interface 類**：tool interface failure（低到中／高）。 **兩類值得深看，因為它們是結構性而非偶發**： 1. **Drift 是規劃性質，不只是 model 弱點**。Shahnovsky 與 Dror（2026-03）的 web agent 規劃框架把 agent 架構映射到古典規劃 paradigm，把 context drift 與 incoherent task decomposition 當作可診斷的規劃失敗。《Agent Drift》接著顯示 semantic、coordination、behavioral degradation 在長互動序列上可量測地累積。這就是為什麼 loop design 必須為 compaction、checkpointing、explicit re-grounding 預留空間——**長程 drift 是 runtime trajectory 的屬性**。 2. **Reward hacking 不是壞 eval 的花俏名稱**。Skalse 等人 2022 的形式處理證明了一個硬結果：**跨所有 stochastic policies 的集合，兩個 reward function 只有在其中一個是常數時才能互相 unhackable**。用工程語言：**任何非平凡 proxy reward 在夠廣的 policy class 下都可被 game**。2026 的工作顯示 capable agent 在 tool-using 環境中自然發現這些捷徑，常見緩解也無法消除問題。對 production loop 的含意是：**沒有單一 scalar reward 關閉缺口**——需要分層 proxy、randomization、hidden test、external verifier，以及對高價值任務的人類審查。 ### Part VIII. Token Economics and Cost Control（Token 經濟與成本控制） Loop 改變語言模型的單位經濟，因為**每個 iteration 都重送累積的 history、system prompt、tool schema**。作者把成本當架構屬性，而非事後想法。 ![Image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*oWxluOsVBi-2okJJwTSoZA.png) **實務上重要的三個倍數**： - Anthropic 的 multi-agent research system 報告：agent 通常用約 **4× 於 chat 互動的 token**；multi-agent 系統用約 **15× 於 chat**。 - Anthropic 目前 Claude Code cost 文件加入一個營運數字：agent teams 當 teammate 在 plan mode 跑時，約 **7× 的 token**。含意：single-agent autonomy 相對 chat 帶實質溢價，小團隊再把該溢價乘一次，廣泛的 multi-agent orchestration 只適用於經濟價值超過該稅的任務。 **失控成本的故事已是 folklore，作者誠實處理**：2026 年社區報導流傳兩個廣為重複的例子——一個 49-subagent type-checking session 估約 **$8,000–15,000**；一個 23-subagent unattended code-quality 專案據報在三天內達約 **$47,000**。作者**無法對 primary vendor postmortem 驗證任一數字**，所以把兩者當告誡性 single-source report 而非定案 benchmark。即使確切金額變動，結構教訓仍成立——**平行 subagent 各自擁有 context，loop 缺乏 hard stop 時成本快速複合**。 **控制直接且有效，分為三桶**： - **預算守衛與硬上限**：執行前定義最大 token threshold 與最大 iteration 數，breach 任一時讓 loop **fail closed**。 - **Prompt caching**：cache 穩定 prefix 可大幅降低 read 成本。把 static component（system prompt、tool definition、policy doc）放 context 前面，把 dynamic 變數（如 timestamp）放最後的 user turn，這樣 loop 不會在每個 iteration 靜默 invalidate cache。 - **執行前可行性驗證**：PlanCompiler 在編譯前驗證 plan；Agents SDK 把 usage 序列化進 tracing metadata 以做 per-run budget check；curated、decision-grade context 據報能相對相同 prompt 與 model 顯著降低 token 消耗與 tool call。**好的 loop 在預算、精度目標、或 tool precondition 未過 feasibility gate 時，就先拒絕昂貴工作。** ### Part IX. Observability and Evaluation（可觀測性與評估） Response logging 對 loop 而言不足。**你需要保留跨 model call、tool call、guardrail、handoff、retry、state transition 之因果關係的 trace。** 問題從來不只是 model 答了什麼，而是 runtime 為何做下一步。 - **OpenAI Agents SDK** 直接文件化：trace 由 span 組成，涵蓋 model generation、tool call、handoff、guardrail、custom event。 - **Anthropic Claude Code** 暴露 agent loop 與 OpenTelemetry-compatible observability surface。 - **LangGraph 與 LangSmith** 透過 OpenTelemetry attributes（session ID、reference example ID、span kind）把 trace instrumentation 連到 dataset 與 experiment session。 **最小有用的遙測模型有兩層**： - **Step-level span**：捕捉每個 model call、tool invocation、guardrail check、memory operation。 - **Trace-level metadata**：捕捉完整 objective、aggregate usage、outcome、evaluator 分數。 - **Nested handoff span** 在 multi-agent 系統中不可或缺，因為它們在 parent run 下保留 delegated sub-trajectory——closed-loop debugging 依賴該階層。 **平台定位**：Langfuse（step-by-step trace，OTel-native 攝取，常見開源基線）；LangSmith（trace 連實驗 dataset，傾向 LangChain workflow）；Braintrust（production trace 搜尋、annotation、online/offline eval、CI quality gate）；Arize Phoenix（trace 可見性、annotation、實驗）。 **實用評估 stack 三層**： - **Unit eval**：對 deterministic component（parser、tool adapter、policy、verifier）。 - **Trajectory regression**：常用 model judge 或 trajectory matching，把完整 run 與預期行為比對。 - **Production trace sampling + annotation + failure clustering**：把真實失敗轉成 regression dataset。 **trace-to-dataset feedback 正是把 observability 變成工程槓桿的東西**——沒有它，production 事故停留為 anecdote，而無法變成 CI gate。 ### Part X. Safety, Governance, and the Control Plane（安全、治理與控制平面） **治理決定 agentic deployment 是否達 production**，而在 loop engineering 裡，它是 control-plane design problem。**高信心模式**是：一個 bounded Plan-Execute-Verify loop，外包 permissioning、policy gate、audit trail——loop 無法在不先宣告 intent、再驗證 outcome 的情況下採取動作。 - **Anthropic hook system** 提供 before tool use、after tool use、on stop、on subagent lifecycle 的 runtime interceptor，是 policy layer 的機械基質。 - **Model Context Protocol** 給 Anthropic 與 OpenAI stack 一個標準化方式來中介 tool access 並限制 compromised subagent 的 blast radius。 - **Identity control** 把 agent 當 non-human identity，配 short-lived、least-privilege credential，而非透過 generic service account 路由流量。 - **OWASP Top 10** 指出治理必須最強之處（goal hijack、tool misuse、privilege abuse 等）。 - **Control plane** 因此需要：least-privilege tool scope、對 irreversible action 的 explicit human approval、evidence-preserving kill switch、durable audit log。 **McKinsey 2026 從企業端強化同一課**：2026-04-02 guidance 主張工作從為 agent 現代化資料架構、跨 workflow 改善可見性與治理、抗拒因為 model 更強就繞過 data-architecture discipline 開始；2026-03-25 AI-trust survey 框定 agentic 時代治理、風險管理、信任成熟度的持續缺口。作者明確旗幟一個數字：**「約 80% agentic 實作時間花在 data engineering 與治理」這個流傳說法，無法從 primary McKinsey 出版品驗證**——公開 McKinsey 來源強烈支持方向，但不支持那個確切百分比，除非有直接內部或簡報來源，否則視為未驗證。 **受管制產業**：governed data substrate 是先決條件而非錦上添花。Runtime 必須知道哪些 record 是 certified input、哪些 memory store 可影響動作、哪些 tool 可寫 system of record、哪些決策需人類簽核。**Input certification** 意即每個 action-causing context item 都帶 provenance、freshness bound、policy scope。File-backed workspace、model trace、eval log、approval event 共同構成 audit trail。沒有該基質，agentic governance 崩塌成事後說故事。 ### Part XI. Engineering Practice and Reference Architectures（工程實踐與參考架構） **2026 年的 production reference loop 有穩定形狀**，作者在每次 design review 都這樣描述：接受 typed goal 與 budget → 驗證 tool reachability 與 precondition → 把 certified context 載入 workspace 或 filesystem → 計畫或分解 goal → 在 bounded turn 中執行（只在 partition 明確時 spawn nested subagent）→ 每個 material step 後跑 deterministic 或 narrow-model verifier → persist checkpoint → 在成功、無進展、預算耗盡、或 policy 違規時停止 → emit step-level span 與 trace-level summary → 把 irreversible 或 low-confidence 動作升級人類。 **成熟度模型**（定位自己系統的有用方式）： - **L1**：帶工具的 chatty assistant。 - **L2**：加 bounded loop 與 external verifier。 - **L3**：加 checkpointing、trace-based eval、policy gate。 - **L4**：加平行、governed memory、chargeback-aware budget control。 - **L5**：加 higher-order planning、declarative policy、continuous trace-to-dataset CI。 **困難的跨越**是從 helpful agent 到 governed runtime——那正是多數 failure、cost、audit gap 浮現之處。 **Anti-pattern 同樣一致**：不要把單一 agent 部署到應被分割的 multi-domain 任務；不要依賴 model self-evaluation 做關鍵任務的終止決策；不要把 raw tool output 未經 filesystem 過濾就直入 context window——每一個都重新引入了這個學科已知如何預防的失敗模式。 **任務形狀 → 拓樸 → 觸發對照**（原為 ASCII 表，轉條列）： - 單一有界任務 → single-agent loop → goal → 最低協調 overhead。 - 平行研究 → fan-out / fan-in → goal or heartbeat → 獨立子問題。 - 嚴格 pipeline → pipeline → hook or cron → 窄 stage contract。 - Incident response → supervisor + specialists → hook + heartbeat → 中央 coherence + polling。 - 批次維護 → workflow with verifier → cron → deterministic cadence。 - 對抗式審查 → debate with external judge → goal → 獨立 critique 路徑。 **Pre-flight check**（答案為「是」才出貨）： - Goal clarity：成功可被 worker model 之外的 verifier 測試嗎？ - Budget control：token、dollar、iteration、wall-clock 上限到位嗎？ - Trigger fit：trigger 符合業務流程的 cadence 嗎？ - State design：loop 能從 checkpoint 無歧義恢復嗎？ - Context hygiene：陳舊或被污染的 context 受 freshness rule 約束嗎？ - Tool safety：tool 權限是 least-privilege 且 audit logged 嗎？ - Verification：核心檢查是 deterministic 或分開判斷嗎？ - No-progress handling：runtime 能偵測 thrashing 並乾淨停止嗎？ - Human escalation：對不確定或不可逆操作有具名路徑嗎？ - Observability：trace 捕捉 span、handoff、guardrail、usage 嗎？ - Regression：被 trace 的失敗能快速變成 CI eval 嗎？ #### Reference Loop 程式碼（reference_loop.py）下列 codebase 一對一映射到六要素。**關鍵設計對照**： - `Goal` 帶 `deterministic_check`——成功可在 worker model 之外測試。 - `run()` 是 goal trigger。 - `LoopState` 是 state store，每個 iteration checkpoint 到磁碟。 - `_step()` 是 policy：一個 worker turn 加上任何 tool call。 - `_deterministic_verify()` 擁有 stop authority；`_model_verify()` 是 Haiku fallback，**永不決定 irreversible work**。 - `_check_stop_rules()` 是分層 stop stack：iterations、tokens、dollars、wall-clock、no-progress，**各自 raise `Escalation` 而非讓 loop 跑下去**。 **三個分離 real loop 與 demo 的細節**： 1. **No-progress detector** 對 verifier 的 progress signal 做 hash，把相同 signal 計為 stall——這是抓 thrashing 的方式。 2. `write_file` 工具**拒絕任何路徑含 "test"**——這是 read-only anti-cheating 邊界，擋下「刪 failing test」的 reward hack。 3. System prompt 帶 `cache_control`，而動態內容留在 user turn——**讓 prompt caching 跨 iteration 真正成立**。 **兩個 caveat**：pricing map 與 model string 為示範值，dollar figure 是來自 usage token 的估計，非 billing source of truth——兩者都需對照當前文件才能信賴 dollar 帳務。 ```python """ reference_loop.py A production-shaped agentic loop that implements the six minimal elements from the field guide: goal, trigger, state, policy, verifier, and stop rule. The worker model selects the next action. A deterministic check owns the stop authority, with a narrow Haiku evaluator only as a fallback signal. Every material step emits a span, and budget plus no-progress rules guarantee the loop halts. Pricing and model strings below are illustrative as of mid-2026. Verify both against current Anthropic docs before you rely on the dollar accounting. """ from __future__ import annotations import json import time import hashlib import subprocess from dataclasses import dataclass, field from pathlib import Path from typing import Callable, Any import anthropic # --- Models and (illustrative) pricing ------------------------------------- WORKER_MODEL = "claude-opus-4-8" VERIFIER_MODEL = "claude-haiku-4-5-20251001" # USD per token. Replace with current published rates. PRICE = { WORKER_MODEL: {"in": 15.0 / 1e6, "out": 75.0 / 1e6, "cache_read": 1.5 / 1e6}, VERIFIER_MODEL: {"in": 1.0 / 1e6, "out": 5.0 / 1e6, "cache_read": 0.1 / 1e6}, } # --- Loop contract ---------------------------------------------------------- @dataclass class Budget: max_iterations: int = 25 max_tokens: int = 2_000_000 max_usd: float = 20.0 max_wall_clock_s: float = 1800.0 no_progress_limit: int = 3 # halt after N iterations with no metric change @dataclass class Goal: """A goal is testable by something outside the worker model.""" objective: str # Deterministic verifier. Returns (passed, progress_signal). The signal is # any stable string whose change means real progress (test output, a diff # hash, a build log tail). Identical signals across turns mean thrashing. deterministic_check: Callable[[], tuple[bool, str]] @dataclass class Span: iteration: int kind: str detail: str tokens: int = 0 usd: float = 0.0 t: float = field(default_factory=time.time) @dataclass class LoopState: messages: list[dict] = field(default_factory=list) iteration: int = 0 tokens: int = 0 usd: float = 0.0 started: float = field(default_factory=time.time) last_signal: str | None = None stalls: int = 0 spans: list[Span] = field(default_factory=list) def checkpoint(self, path: Path) -> None: path.write_text(json.dumps({ "iteration": self.iteration, "tokens": self.tokens, "usd": round(self.usd, 4), "messages": self.messages, }, indent=2)) class Escalation(Exception): """Raised to hand control to a human. The loop never decides this silently.""" # --- The loop --------------------------------------------------------------- class AgentLoop: def __init__( self, goal: Goal, tools: list[dict], tool_impls: dict[str, Callable[[dict], str]], budget: Budget | None = None, checkpoint_path: str = "loop_state.json", on_span: Callable[[Span], None] | None = None, ): self.goal = goal self.tools = tools self.tool_impls = tool_impls self.budget = budget or Budget() self.checkpoint_path = Path(checkpoint_path) self.on_span = on_span or (lambda s: print(f"[{s.iteration:02d}] {s.kind}: {s.detail}")) self.client = anthropic.Anthropic() # Stable prefix is cached. Dynamic content stays in the user turns so the # cache is not invalidated on every iteration. def _system(self) -> list[dict]: return [{ "type": "text", "text": ( "You are a worker inside a bounded execution loop. Pursue the goal " "using the available tools. Make one concrete change per turn and " "check your work. Do not claim success. A separate verifier decides " "when the goal is met.\n\nGOAL: " + self.goal.objective ), "cache_control": {"type": "ephemeral"}, }] def _emit(self, span: Span) -> None: self.state.spans.append(span) self.on_span(span) def _account(self, model: str, usage: Any) -> tuple[int, float]: p = PRICE[model] cache_read = getattr(usage, "cache_read_input_tokens", 0) or 0 billed_in = usage.input_tokens - cache_read usd = billed_in * p["in"] + cache_read * p["cache_read"] + usage.output_tokens * p["out"] toks = usage.input_tokens + usage.output_tokens self.state.tokens += toks self.state.usd += usd return toks, usd # --- Stop stack. Checked before every worker call. ---------------------- def _check_stop_rules(self) -> None: b, s = self.budget, self.state if s.iteration >= b.max_iterations: raise Escalation(f"max_iterations {b.max_iterations} reached") if s.tokens >= b.max_tokens: raise Escalation(f"token budget {b.max_tokens} exhausted") if s.usd >= b.max_usd: raise Escalation(f"dollar budget ${b.max_usd} exhausted") if time.time() - s.started >= b.max_wall_clock_s: raise Escalation("wall-clock budget exhausted") if s.stalls >= b.no_progress_limit: raise Escalation(f"no progress across {s.stalls} iterations") # --- Verifiers. Deterministic check is authoritative. ------------------- def _deterministic_verify(self) -> bool: passed, signal = self.goal.deterministic_check() sig = hashlib.sha256(signal.encode()).hexdigest()[:12] if sig == self.state.last_signal: self.state.stalls += 1 else: self.state.stalls = 0 self.state.last_signal = sig self._emit(Span(self.state.iteration, "verify", f"passed={passed} signal={sig} stalls={self.state.stalls}")) return passed def _model_verify(self) -> bool: """Fallback only, used when no deterministic signal applies. Narrow contract, separate model, JSON out. Never trusted for irreversible work.""" resp = self.client.messages.create( model=VERIFIER_MODEL, max_tokens=256, system="Reply ONLY with JSON: {\"done\": bool, \"reason\": str}. " "Judge strictly against the stated goal. Default to false.", messages=[{"role": "user", "content": f"GOAL: {self.goal.objective}\n\nTRANSCRIPT TAIL:\n" f"{json.dumps(self.state.messages[-4:])}"}], ) self._account(VERIFIER_MODEL, resp.usage) try: verdict = json.loads(resp.content[0].text) except (json.JSONDecodeError, IndexError, AttributeError): return False self._emit(Span(self.state.iteration, "model_verify", str(verdict))) return bool(verdict.get("done")) # --- Policy: one worker turn plus any tool calls it requests ------------ def _step(self) -> None: resp = self.client.messages.create( model=WORKER_MODEL, max_tokens=4096, system=self._system(), tools=self.tools, messages=self.state.messages, ) toks, usd = self._account(WORKER_MODEL, resp.usage) self.state.messages.append({"role": "assistant", "content": resp.content}) tool_results = [] for block in resp.content: if block.type == "tool_use": self._emit(Span(self.state.iteration, "tool_use", f"{block.name} {json.dumps(block.input)[:80]}", toks, usd)) impl = self.tool_impls.get(block.name) output = impl(block.input) if impl else f"error: unknown tool {block.name}" tool_results.append({ "type": "tool_result", "tool_use_id": block.id, "content": output, }) if tool_results: self.state.messages.append({"role": "user", "content": tool_results}) # --- Entry point (a goal trigger: run until verified or stopped) -------- def run(self) -> str: self.state = LoopState(messages=[ {"role": "user", "content": f"Begin work toward the goal: {self.goal.objective}"} ]) try: while True: self._check_stop_rules() self.state.iteration += 1 self._step() self.state.checkpoint(self.checkpoint_path) if self._deterministic_verify(): self._emit(Span(self.state.iteration, "done", f"goal met in {self.state.iteration} iters, " f"${self.state.usd:.2f}")) return "SUCCESS" except Escalation as e: self._emit(Span(self.state.iteration, "escalate", str(e))) # Hand to a human. Preserve state and the trace for the audit trail. return f"ESCALATED: {e}" # --- Example: make the test suite pass -------------------------------------- # The worker may read source and run tests. Test files are read-only at the # tool boundary so the agent cannot delete a failing test to fake success. def _tools() -> tuple[list[dict], dict]: tools = [ {"name": "read_file", "description": "Read a source file.", "input_schema": {"type": "object", "properties": {"path": {"type": "string"}}, "required": ["path"]}}, {"name": "write_file", "description": "Write a source file (not tests).", "input_schema": {"type": "object", "properties": {"path": {"type": "string"}, "content": {"type": "string"}}, "required": ["path", "content"]}}, {"name": "run_tests", "description": "Run the read-only test suite.", "input_schema": {"type": "object", "properties": {}}}, ] def read_file(args): return Path(args["path"]).read_text()[:4000] def write_file(args): if "test" in Path(args["path"]).name.lower(): return "error: test files are read-only" # anti-cheating boundary Path(args["path"]).write_text(args["content"]) return "ok" def run_tests(_): r = subprocess.run(["pytest", "-q"], capture_output=True, text=True, timeout=120) return (r.stdout + r.stderr)[-2000:] return tools, {"read_file": read_file, "write_file": write_file, "run_tests": run_tests} def _tests_pass() -> tuple[bool, str]: r = subprocess.run(["pytest", "-q"], capture_output=True, text=True, timeout=120) return r.returncode == 0, (r.stdout + r.stderr)[-500:] if __name__ == "__main__": tools, impls = _tools() loop = AgentLoop( goal=Goal(objective="Fix the implementation so the test suite passes.", deterministic_check=_tests_pass), tools=tools, tool_impls=impls, budget=Budget(max_iterations=15, max_usd=5.0), ) print(loop.run()) ``` ### Part XII. Frontier and Open Problems（前沿與開放問題） **下個前沿是 self-modifying loop 與寫 loop 的 loop**，產品證據已指向那裡。Anthropic 的 dynamic workflow 與 agent team 朝 runtime-generated orchestration 移動；OpenAI 的 trace、processor、handoff 已可程式化到支援 higher-order loop 構造；LLMCompiler、PlanCompiler、PASTE 已把 orchestration 當作可系統化 plan、compile、optimize 的東西。 **缺失的層**是 objective、budget、trigger、policy、verifier contract、escalation path 的共用宣告式語言。幾位從業者開始指向 **LoopScript 風格的宣告式 control plane**，用嚴格的拓樸定義取代 ad-hoc Python orchestration。作者把該特定術語視為新興、尚未標準化。無論哪種語法勝出，重點都成立：**MCP 標準化 tool connectivity，但尚未標準化 loop semantics、stop schema、budget contract、跨框架的 trace taxonomy**——在那些缺口關閉前，loop engineering 仍是 bespoke、repository-specific 的學科。 **學術議程繞著同樣的缺口收斂**：ICML 2026 議程包含 agentic failure 與 agentic system 不確定性的 workshop，目標鎖定可重現的失敗觸發、trace 診斷、長程 loop 的驗證修補、連續監控下的原則性停止規則。作者對確切 workshop 日期持保留，因為手上排程細節並非全部從單一 primary source 確認。 ## 總結與結論 1. **瓶頸已從 prompt 移到 loop**。Prompt engineering 在 2026 初已非瓶頸，trigger 選擇、topology、context 衛生、驗證、stop rule、observability、治理、預算控制才是。**Agent 是一個元件，loop 才是 production system**——這是全文反覆出現的第一性原理。 2. **六要素是可立即操作的 diagnostic**。goal / trigger / state / policy / verifier / stop rule 缺一即產生可預測失敗：缺 verifier → 自吹自擂的自主性；缺 stop → 無限燒錢；缺 state → drift；缺 trigger → 永不啟動。拿任何現有 agentic 系統套上去，缺塊立刻現形。 3. **驗證權威必須在 worker model 之外，且要分層**。外部證據 > deterministic check > narrow judge > worker 自稱完成；配合分層 stop stack（goal / no-progress / max-iteration / wall-clock / token-$ budget / escalation）。Reward hacking 的硬定理（Skalse 2022）證明沒有單一 scalar reward 能關閉缺口——需分層 proxy + hidden test + external verifier + 人類審查。 4. **成本是架構屬性，三個倍數 + 三桶控制**。agent ≈ 4× chat、multi-agent ≈ 15× chat、agent team plan mode ≈ 7× token。控制靠 hard cap（fail closed）+ prompt caching（static 前置、dynamic 後置）+ 執行前 feasibility gate。Ultracode（Claude Code v2.1.160，Opus 4.8）與 Codex Goal mode（GA app 26.519）是當前 vendor 端的 loop primitive 收斂點。 5. **持久產物跨 model swap 存活**。termination logic、verifier design、trace schema、tool permissioning、checkpoint storage、budget policy 是會留在 repo 的東西；手寫 prompt 通常不會。落地路徑是 Part XI 的成熟度階梯 L1→L5，最難的跨越是從 helpful agent 到 governed runtime。

Obsidian 整理原始文章

AI技術

Graph Engineering replaced RAG at Microsoft, Stanford and Anthropic. Here's how it works.（圖譜工程取代 RAG：Microsoft、Stanford、Anthropic 的實踐全解）

"一般 RAG 找的是「文字」，Graph Engineering 找的是「關係」——同一個模型、同一份資料，搜尋現實而非搜尋文件，因此能回答「為什麼」這類需要因果鏈的複雜問題。"

Top 5 Insights

**RAG 的天花板是「搜尋單位」**：RAG 搜尋「文字片段」，Graph Engineering 搜尋「關係」。複雜問題（why / causation / 跨文件 pattern）的答案散落在關係裡，不在文字裡，所以 RAG 在 local question 有效、在 global question 失效——這是 Microsoft GraphRAG 區分 Local Search / Global Search 的根本原因。
**三方獨立收斂到同一個 scaling law：好圖勝過大模型**。Microsoft 的 18% / 85% / $0.004 是工程實證；Stanford 的「26 模型 benchmark：小模型 + 好圖 > 大模型 + 爛圖」是理論；Anthropic 的 LaunchNotes 5x / 50% 是產品化。三者共同指向：**模型周圍的系統（圖譜）比模型本身更能決定輸出**。
**Graph Engineering 的科學根據是「顯式關係 > 推斷關係」**。MIT relational memory 與 KEPLER 證明：當關係被顯式儲存為三元組，模型從 infer 退化為 lookup，產出更連貫、邏輯錯誤更少。Anthropic 的三層架構（萃取 / 查詢 / MCP）把這個原理產品化——過去需要專門 NLP pipeline 的工作，現在透過 API call + 標準協定即可完成。
**它不是消滅 prompt，而是把 prompt 工程化到 pipeline 的 5 個階段**。5 個 prompt（extraction / normalization / query / grounded answer / maintenance）各自的護欄設計（不無證據合併、只用 schema 內關係、不從相關推因果、不無證據覆蓋舊事實）才是 KG 品質的真正決定因素。這 5 個 prompt 的設計品質 = 你的 KG 品質。
**落地前必算的總持有成本**：Graph Engineering 是「重資產、輕查詢」架構——query 端成本降 85%，但 indexing 端（萃取、建圖、社群偵測、community reports）的 LLM call 成本會隨文件量線性成長，且 schema 設計、dedup、持續更新都需要 human-in-the-loop（zero-shot graph generation 在 production 仍不夠可靠）。它的甜區是「關係密度高、查詢頻率高、資料變動慢、付費意願高」的垂直領域（盡職調查、工程情報、研究情報），而非所有 RAG 場景的通用替代品。

--- tags: [AI技術, Graph-Engineering, Knowledge-Graph, RAG, LLM, MCP, DSPy] date: 2026-07-20 read: false source: "2026-07-20T100754+0800-Graph Engineering replaced RAG at Microsoft, Stanford and Anthropic. Here's how it works..md" original_title: "Graph Engineering replaced RAG at Microsoft, Stanford and Anthropic. Here's how it works." --- # Graph Engineering replaced RAG at Microsoft, Stanford and Anthropic. Here's how it works.（圖譜工程取代 RAG：Microsoft、Stanford、Anthropic 的實踐全解） ![Image](https://pbs.twimg.com/media/HNlIzX8W8AAXHeW?format=jpg&name=large) 原始來源與檔名：2026-07-20T100754+0800-Graph Engineering replaced RAG at Microsoft, Stanford and Anthropic. Here's how it works..md --- ## SOURCE | 資訊源評估 - **準確性**：中高 - 作者 Sprytix 引用了大量可查證的一手來源（GitHub 倉庫、arXiv 論文編號、MIT Press TACL 期刊、Anthropic 官方案例），數字（18%、85%、$0.004、5x、50%）多附有出處；但文章本身屬於「開發者推廣文（self-promotion）」性質，部分論述帶有行銷語氣（如「任何人都能打造」「別再回去搜尋文件」），需要把「事實陳述」與「觀點推銷」分開來讀。 - **易理解性**：高 - 大量使用 ASCII 圖、三元組範例、step-by-step pipeline，把抽象的知識圖譜概念具體化；對有 RAG 經驗的開發者幾乎無閱讀門檻。 - **閱讀策略建議**：先抓「RAG 搜尋文字、Graph 搜尋關係」這個核心二元對立；再把 Microsoft（工程實證）、Stanford（理論/scaling laws）、Anthropic（產品化三層架構）當作三條獨立證據線交叉驗證；最後用「5 個 prompts + 9 步 pipeline」當作可直接落地的施工藍圖。對於「zero-shot graph generation 仍不夠可靠，需要 human-in-the-loop」這類誠實警告要特別留意，這是判斷文章可信度的關鍵。 --- ## NAPKIN | 餐巾紙 ### 餐巾紙公式 > **Answer Quality = f(Relationship Structure) × Model**，而非 **f(Model Size)** _意思是：決定答案品質的上限是「關係結構（圖譜）」而非「模型大小」。模型再大，若只能從文字片段推斷關係，仍會卡在 ceiling；圖譜把關係「顯式化（explicit）」後，模型從 infer 退化成 lookup，錯誤率驟降。這是 Microsoft GraphRAG、Stanford scaling laws、Anthropic LaunchNotes 三條獨立路徑收斂到的同一個結論。_ ### 一句話 > 一般 RAG 找的是「文字」，Graph Engineering 找的是「關係」——同一個模型、同一份資料，搜尋現實而非搜尋文件，因此能回答「為什麼」這類需要因果鏈的複雜問題。 ### 餐巾紙草圖 ``` ┌─────────── RAG（搜尋文字）────────── ┌──────── Graph Engineering（搜尋關係）──────── │ 問題 │ 問題 │ │ │ │ │ ▼ │ ▼ │ 向量比對 → 回傳相似 chunk │ 遍歷三元組路徑 → 回傳因果鏈 │ │ │ │ │ ▼ │ ▼ │ 「這裡有 5 份提到 sales 的文件」 │ 「sales ↓ → release delay ↓ → supplier │ │ │ dependency ↓ → warehouse problem → │ ▼ │ negative reviews → conversion -23%」 │ 找得到「片段」，找不到「因果」 │ 找得到「現實」與「為什麼」 └────────────────────────── └───────────────────────────────────── 同一個模型、同一份資料 → 完全不同的結果差別只在：搜尋的單位是「字」還是「關係」 ``` --- ## ROUND 1: SKELETON | 骨架掃描 - **核心問題**：為什麼同一個 LLM，配上同一份資料，有的系統只能回答「找資料」類問題、有的能回答「為什麼／跨文件因果鏈」類問題？ - **核心答案**：差別不在模型，而在「模型周圍的系統」。RAG 把資料當作「文字片段的集合」來搜尋；Graph Engineering 把資料當作「實體與關係構成的圖」來遍歷。當關係被顯式儲存為三元組（Subject→Relation→Object），模型從「推斷關係」降級為「查表」，準確度提升、成本下降。 - **論證結構**： 1. **破題**：RAG 在複雜問題上徹底失效（用「sales 為何下滑」對照兩種答案）。 2. **三方獨立佐證**：Microsoft（工程實證 + 數字）、Stanford（理論 DSPy/STORM + scaling laws）、Anthropic（產品化三層 + LaunchNotes 實戰）。 3. **學術補強**：MIT relational memory、KEPLER 給出「為什麼有效」的科學解釋。 4. **可落地施工圖**：知識圖譜本質 → 9 步 pipeline → 5 個 prompts → 5 個商業應用。 ### 章節骨架（條列） - Why regular RAG hits a ceiling（RAG 的天花板） - Document 1 - Microsoft GraphRAG（實證數字 + 8 步架構 + Local/Global Search） - Document 2 - Stanford DSPy and the graph connection（模型是圖中的一個 node） - Document 3 - Stanford scaling laws for knowledge graphs（好圖勝過大模型） - Document 4 - MIT Press relational memory（關係記憶的科學解釋） - Document 5 - KEPLER（語言模型 + 知識嵌入 + 知識圖譜） - Document 6 - Anthropic and Claude in the graph（萃取 / 查詢 / MCP 三層） - The LaunchNotes case（GitHub + Jira + Linear 的實戰數字） - What a knowledge graph actually is（三元組本質） - The full Graph Engineering pipeline（9 步） - The five prompts that run the entire pipeline（5 個階段性 prompt） - Five businesses you can build（5 個商業化方向） - The shift that connects Microsoft, Stanford and Anthropic（Prompt→RAG→Graph 的範式位移） --- ## ROUND 2: DISSECTION | 血肉解剖 ### 論證鏈 ``` RAG 只搜文字片段 │ ▼ 複雜問題需要「因果鏈」而非「相似文字」→ RAG 失效 │ ▼ 把資料改存為「實體 + 關係」三元組 → 模型從 infer 變 lookup │ ├─ Microsoft GraphRAG：18% 準確↑、85% 成本↓、$0.004/task（工程實證） ├─ Stanford DSPy/STORM：模型是 pipeline 圖的一個 node（理論） ├─ Stanford scaling laws：小模型 + 好圖 > 大模型 + 爛圖（26 模型 benchmark） ├─ MIT relational memory：顯式關係 → 更連貫、更少邏輯錯（科學解釋） ├─ KEPLER：LM + KG embedding 聯合訓練（架構） └─ Anthropic：萃取 / 查詢 / MCP 三層把 Claude 接進圖（產品化） │ ▼ 三者獨立收斂到同一結論 →「模型找文字，圖譜找現實」→ 把圖蓋出來 ``` ### 3 個關鍵證據 1. **Microsoft GraphRAG 的可量化數字**：準確度比 raw document approach 高 18%、token 成本比直接載入結構化檔案低 85%、單一任務成本約 $0.004；數字源自 ChatP&ID paper（GraphRAG 套用到工業工程管線圖）。這是全文最硬的工程證據，因為它給的是「生產環境可重現的數字」而非概念性主張。 2. **Stanford scaling laws（arXiv 2505.16276）**：在知識圖譜工程任務上 benchmark 26 個開源模型，結論是「larger model + bad graph = worse；smaller model + good graph = better」。這直接否定了「換更大的模型就能解決複雜問題」的直覺，把優化重心從模型拉回到資料結構。 3. **LaunchNotes 的實戰數字**：把 GitHub commits + Jira tickets + Linear tasks 串成一張「工程工作圖」交給 Claude 分析，事件偵測速度提升至 5 倍、會議時間減少約 50%、release notes 自動秒產。這是「圖譜 + LLM」在真實 SaaS 產品中變現的證據，而非實驗室結果。 ### 隱形假設與邊界 - **假設 1：文件可以被可靠地萃取成三元組。** 實際上 LLM 的 zero-shot graph generation 在 schema 設計與去重（dedup）階段仍不夠可靠——作者自己引用的 LLM-assisted KG Engineering paper（arXiv 2307.06917）也承認「需要人類在 schema 與 dedup 步驟 review」。這是全文最容易被「18% / 85%」數字蓋過的關鍵限制。 - **假設 2：查詢本質上是圖遍歷問題。** 但若使用者問的是「語意模糊、需要長文脈絡理解」的問題（例如合約條款的細微措辭），純三元組會丟失文字脈絡。實務上多數系統是「Graph + RAG 混合（hybrid retrieval）」，而非二選一——文章把兩者對立起來，是為了論述張力，工程上不該全信。 - **假設 3：成本下降來自 token 減少。** GraphRAG 的 85% 成本下降主要發生在「query 階段」（不用載入整份結構化檔案），但「indexing 階段」（萃取實體、建圖、社群偵測、生成 community reports）反而需要大量 LLM call，前置成本很高。文章只報 query 端數字，沒有報 total cost of ownership。 - **邊界：資料需具備「關係密度」。** 若業務資料本來就是高度結構化、關係稀疏（例如純日誌查詢），Graph Engineering 的邊際效益有限；它的甜區是「關係錯綜、跨文件因果鏈、需要多跳推理」的場域（盡職調查、工程情報、研究情報）。 --- ## ROUND 3: SOUL | 靈魂提取 ### 作者盲點 - **把 RAG 與 Graph Engineering 描述為「取代」關係，實為「互補」**。Microsoft GraphRAG 本身的 Local Search 仍使用向量檢索（embedding entities + reports），Graph 是架在 RAG 之上、而非取代。業界共識是 GraphRAG（Hybrid Retrieval）。 - **數字過度單一來源**：18% / 85% / $0.004 幾乎全部指向 ChatP&ID 一篇 paper 的特定資料集（工業工程圖），泛化到其他領域時需要保留懷疑。 - **隱去 indexing 成本與維護成本**：知識圖譜需要持續更新、矛盾偵測、schema 演進，這些都是長期人力成本。 - **「任何人都能打造」的民主化敘事略顯浮誇**：production-grade KG 仍需要 ontology 設計、圖資料庫維運、查詢優化等專業。 ### 知識連接 - **連到 Anthropic 的 Contextual Retrieval（2024）**：Anthropic 自己的研究顯示，給 chunk 加上 context、加上 BM25、加上 reranking，能把 RAG 失敗率壓到很低——這是「不建圖也能改善 RAG」的另一條路。Graph 與 Contextual Retrieval 是兩個不同槓桿，可疊加。 - **連到 Agentic RAG / Multi-hop RAG**：Graph 本質上是「結構化的多跳」，而 Agentic RAG 用「模型反覆檢索」來模擬多跳。前者用空間（預先建圖）換時間，後者用時間（多次 LLM call）換空間。 - **連到 Neuro-Symbolic AI**：KEPLER 那條線（LM + KG embedding 聯合訓練）是神經符號融合的典型，呼應「符號系統提供可驗證的事實、神經網路提供語意理解」。 - **連到 Database 兩條路線**：純圖資料庫（Neo4j、Amazon Neptune）vs. PostgreSQL + graph extension（Apache AGE）——選型取決於既有技術棧與關係查詢的密度。 ### 行動觸發 - 若你目前在做「客服 FAQ / 單文件問答」→ RAG 仍是最性價比選擇，別過度工程。 - 若你卡在「跨多份文件、需要回答為什麼、需要多跳因果」→ 先試 GraphRAG 的 global search，再決定是否自建 KG。 - 若你已有 Neo4j / Neptune → 直接接 MCP，把 Claude 當作「自然語言 → Cypher」的翻譯層，最低成本啟動。 - 若要做產品化 → 鎖定「關係密度高 + 付費意願高」的垂直領域（盡職調查、工程情報、研究情報）。 ### 留白提問（2 題） 1. **當圖譜本身有錯（萃取錯誤、過時、矛盾）時，Graph Engineering 的錯誤是會被「放大」還是「抑制」？** 相對於 RAG 把錯誤分散在各 chunk，圖譜的錯誤會沿關係路徑傳播，這是否代表 KG 需要更重的「資料品質治理」投資？ 2. **如果未來 LLM 的長脈絡（long context）+ in-context reasoning 進步到能直接讀完所有文件並推理因果，Graph Engineering 還有結構性優勢嗎？** 換句話說，Graph 的優勢是「本質的（可查詢、可驗證、低成本）」還是「過渡的（補目前模型推理不足）」？ ### 跨域映射 - **地圖 vs. 地址簿**：RAG 像地址簿（找到某人住哪），Graph Engineering 像地圖（看到路怎麼連、哪條路會塞車）。地址簿回答「在哪」，地圖回答「怎麼到、為什麼到不了」。 - **關聯式資料庫 vs. 知識圖譜**：RDBMS 的 JOIN 需要你「事先知道要 join 哪幾張表」；KG 的圖遍歷可以「探索性地多跳」，這對「不知道要問幾跳」的探索性問題更友善。 - **索引 vs. 目錄**：書後索引（index）= RAG（找關鍵字出現的頁碼）；書前目錄 + 章節交叉引用 = Graph（看到概念的層級與關聯）。 --- ## DEEP READ | 精讀指引這篇文章的價值不在「Graph Engineering 很強」這個結論（這已是 2024 年後的共識），而在於它把「為什麼有效」拆成三條獨立證據線並給出可落地施工圖。建議你帶著一個問題精讀：**「我的業務問題，到底卡在 RAG 的哪一個天花板？」** 如果卡在「找得到文件但拼不出因果」，那 Microsoft GraphRAG 的 global search 與 LaunchNotes 的案例就是你的範本；如果卡在「模型再大也沒用」，那 Stanford scaling laws 那段就是你的論證彈藥。第二層精讀重點是「5 個 prompts」。很多人誤以為 Graph Engineering「取代 prompt engineering」，其實它只是把 prompt 從「單次問答」拆散到 pipeline 的 5 個階段（extraction / normalization / query / grounded answer / maintenance）。這 5 個 prompt 的設計品質，直接決定 KG 的萃取品質與查詢品質——這才是真正會差異化的工程細節，值得逐字讀並動手改寫成你自己的 schema。最後，不要被「85% 成本下降」綁架。請親自算一遍 indexing cost：建圖階段的 LLM call 數量通常隨 chunk 數量 × 平均實體數量線性成長，前置成本可能遠高於你預期。Graph Engineering 是「重資產、輕查詢」的架構，適合「查詢頻率高、資料變動慢」的場景；反之若是「資料高速變動、查詢稀疏」，傳統 RAG 的總持有成本可能更低。讀的時候把這個算式隨時放在心裡，才不會被數字沖昏頭。 --- ## STRUCTURE MAP | 全書結構圖 ``` Graph Engineering 取代 RAG │ ┌───────────────────────────┼───────────────────────────┐ │ │ │ 為何 RAG 卡住三方獨立佐證可落地施工圖 │ │ │ ▼ ▼ ▼ 搜文字 vs 搜關係 ┌──────┴──────┐ 知識圖譜本質 (sales 因果鏈對照) │ │ (三元組) ▼ ▼ │ 工程實證理論/scaling ▼ Microsoft Stanford 9 步 pipeline GraphRAG DSPy/STORM/ (collect→extract 18% ↑ scaling laws →build→dedup→ 85% ↓ (小模型+好圖 store→retrieve→ $0.004 >大模型+爛圖) connect→update) │ │ │ └──────┬──────┘ ▼ ▼ 5 個 prompts 學術補強 (extraction/ MIT relational normalization/ memory + KEPLER query/grounded/ (顯式關係的 maintenance) 科學解釋) │ │ ▼ ▼ 5 個商業應用產品化 (盡職調查/ Anthropic 3 層業務/工程/ (萃取/查詢/MCP) 研究/個人OS) + LaunchNotes 實戰 │ (5x / 50%) ▼ 範式位移 │ Prompt→RAG→Graph ▼ 模型找文字，圖譜找現實 ``` --- # Graph Engineering replaced RAG at Microsoft, Stanford and Anthropic (Architectural Deep Dive) ## 前言 / 背景這是一篇由開發者 Sprytix 撰寫、主張「Graph Engineering 正在取代 RAG」的長文推廣文。其核心主張是：現在任何人都能打造一個「比傳統 RAG 準確度高 18%、成本低 85%」的 AI 系統，關鍵不在更大的模型或 PhD 團隊，而在於 Microsoft、Stanford、Anthropic 三方獨立發現的同一個概念——**Graph Engineering（圖譜工程）**。傳統 RAG 的運作流程是「問題 → 搜尋文件中匹配的文字 → 回傳最相關的 chunk → 模型從 chunk 生成答案」。這對簡單問題有效，但對複雜問題會徹底失效。作者用一個極具說服力的對照案例說明： ```text RAG answer: Here are 5 documents mentioning sales in March. Graph Engineering answer: Sales dropped because of a release delay caused by a supplier dependency triggered by a warehouse problem which generated negative reviews which reduced conversion by 23%. ``` 同一個模型、同一份資料，結果完全不同——因為一個系統在搜尋「文字」，另一個在搜尋「現實（reality）」。這就是三方機構各自走向 Graph Engineering 的共同原因。 --- ## 章節詳細總結 ### 為什麼 regular RAG 達到天花板（ceiling） RAG 的根本機制是「向量相似度比對」：把問題與文件都 embed 成向量，找 cosine 距離最近的 chunk。這套機制在「找特定實體的資訊」時很好用，但在回答「為什麼（why）」「因果鏈（causation）」「跨多份文件的pattern」時會失效，原因是： - RAG 搜尋的單位是「文字片段（fragment）」，而複雜問題的答案散落在「實體之間的關係（relationship）」裡。 - 相似度比對只能找到「字面上提到 sales 與 March」的文件，找不到「sales 下滑 ← release delay ← supplier dependency ← warehouse problem」這條因果鏈。 - 因果鏈的每一環可能分屬不同文件、不同時間、不同部門，RAG 的單次檢索無法把它們串起來。 Graph Engineering 的解法是：**預先把這些因果關係萃取成顯式的三元組並存成圖**，查詢時用圖遍歷（graph traversal）一次走完整條鏈，而不是靠模型從文字裡推斷。 --- ### Document 1 — Microsoft GraphRAG ![Image](https://pbs.twimg.com/media/HNlNCN6WMAA93yp?format=jpg&name=large) 相關連結： - [github.com/microsoft/graphrag](https://github.com/microsoft/graphrag) - [github.com/microsoft/graphrag/blob/main/docs/index/architecture.md](https://github.com/microsoft/graphrag/blob/main/docs/index/architecture.md) Microsoft 打造並開源了 GraphRAG，其研究數據是目前「Graph Engineering 相對於 RAG 實際效益」最具體的數字來源。它的核心架構是把非結構化文字轉換成完整的知識圖譜，pipeline 如下： ```text Load Documents ↓ Chunk Documents ↓ Extract Entities and Relations ↓ Build Graph ↓ Detect Communities ↓ Generate Community Reports ↓ Embed Entities and Reports ↓ Local Search / Global Search ``` 這個 pipeline 的關鍵設計理念是：**regular RAG 擅長回答 local question（區域性問題）——「找某個特定實體的資訊」，但對 global question（全局性問題）會失效——「整份資料集的主要主題是什麼、這 10,000 份文件之間有什麼共通 pattern」**。Graph Engineering 兩種都能答。 ```text Local Search | what happened with supplier X in March | finds specific node and its connections Global Search | what are the main risk patterns across | all our supplier relationships | finds patterns across entire graph ``` 這裡的工程亮點是 **community detection（社群偵測）+ community reports（社群報告）**：GraphRAG 在建圖後會用圖演算法（如 Leiden）把節點聚成社群，再為每個社群生成摘要報告。Global Search 時模型讀的是「社群報告」而非原始文件，這就是 token 成本能降 85% 的核心機制——它把「讀 10,000 份文件」降維成「讀 N 篇社群摘要」。 Microsoft GraphRAG 研究的實際成果數字： ```text Accuracy improvement | 18% higher than raw document approach Token cost reduction | 85% lower than loading structured files directly Cost per task | approximately $0.004 in tested configuration ``` > 論文出處：[arxiv.org/abs/2603.22528](https://arxiv.org/abs/2603.22528) ![Image](https://pbs.twimg.com/media/HNlNhf1WEAAPTaU?format=jpg&name=large) 這些數字來自 **ChatP&ID paper**——GraphRAG 套用到工業工程管線圖（P&ID, Piping and Instrumentation Diagrams）的研究。作者強調同樣的原則可跨領域套用。 --- ### Document 2 — Stanford DSPy 與圖譜連結相關連結： - [github.com/stanfordnlp/dspy](https://github.com/stanfordnlp/dspy) - [arxiv.org/abs/2310.03714](https://arxiv.org/abs/2310.03714) Stanford 的 DSPy paper 確立了一個關鍵觀念：**模型是圖中的一個節點（node），而不是宇宙的中心**。這是連結到 Graph Engineering 的理論基礎。DSPy 把整個 AI pipeline 視為一個由 module 組成的圖： ```text Question ↓ Retriever - finds relevant information ↓ Reasoning - processes and connects ↓ Verifier - checks the result ↓ Answer ``` DSPy 與 Graph Engineering 的連結是直接的：**DSPy 優化的是 pipeline graph（流程圖），GraphRAG 優化的是 knowledge graph（知識圖）**。兩者都把模型視為更大結構中的一個元件，而非整個解決方案本身。DSPy 的貢獻是「把 prompt 從手工調校變成可編譯（compile）、可優化的程式碼」，這與 Graph Engineering「把 prompt 拆散到 pipeline 各階段」的思路一致。 Stanford 的 **STORM paper** 進一步把這個理念推到極致： - [github.com/stanford-oval/storm](https://github.com/stanford-oval/storm) - [arxiv.org/abs/2402.14207](https://arxiv.org/abs/2402.14207) STORM 在寫下任何一個字之前，會先透過一個結構化的「研究步驟圖」從零開始建立知識：研究、來源收集、大綱、寫作、驗證、修改——每一個步驟都由前一個步驟發現的關係所驅動。Stanford 所有研究的共通洞見是：**複雜任務需要的是「一組互相連接的步驟構成的系統」，而不是單一次模型呼叫。圖，就是那個系統。** --- ### Document 3 — Stanford 知識圖譜的 scaling laws > 論文出處：[arxiv.org/abs/2505.16276](https://arxiv.org/abs/2505.16276) 這篇論文在知識圖譜工程任務上比較了 26 個開源模型，結論是整個領域最重要的結論之一： ```text Larger model + bad graph | worse results Smaller model + good graph | better results ``` **對的圖，勝過更大的模型。每一次都是。** 這與 Microsoft GraphRAG、Anthropic Claude Code 各自得出的結論完全一致——**模型周圍的系統，比模型本身更能決定輸出**。Graph Engineering 是這個原則最具體的實作。從架構師角度，這條 scaling law 等於宣告：把優化預算花在「資料結構與關係建模」的 ROI，高於花在「換更大模型」。 --- ### Document 4 — MIT Press 關於關係記憶（relational memory）的研究論文連結：[direct.mit.edu/tacl/article/doi/10.1162/tacl\_a\_00476](https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00476)，發表於 *Transactions of the Association for Computational Linguistics (TACL)*。這份研究展示「當你把語言模型接上關係記憶——一個由關係構成、而非只是文字 chunk 的知識圖譜」時會發生什麼事： ```text Text Context ↓ Retrieve Relevant Relations from Graph ↓ Relational Memory ↓ Language Model ↓ More coherent, more accurate generation ``` 關鍵發現：**能存取顯式關係結構（explicit relationship structures）的模型，會產出更連貫的文字、犯更少的邏輯錯誤**，相對於只從文字運作的模型。這是 Graph Engineering 之所以有效的科學解釋：**模型不必再從文字中推斷（infer）關係，關係已經顯式地存在圖裡，模型直接使用它們**。從資訊論角度，這等於把「關係推斷」這個高不確定性的工作，從生成階段前移到 indexing 階段，並用結構化儲存固化下來，生成時的不確定性大減。 --- ### Document 5 — KEPLER 相關連結： - [direct.mit.edu/tacl/article-abstract/doi/10.1162/tacl\_a\_00360/98089](https://direct.mit.edu/tacl/article-abstract/doi/10.1162/tacl_a_00360/98089) - [github.com/THU-KEG/KEPLER](https://github.com/THU-KEG/KEPLER) KEPLER 把語言模型訓練與知識圖譜 embedding 結合。它不再把「語言理解」與「事實知識」當作兩個分開的問題，而是**同時優化兩者**： ```text Language Model + Knowledge Embeddings + Knowledge Graph = Model that understands both language and facts ``` 實務意涵：**一個能存取結構化知識圖譜的模型，不必再猜測實體之間的關係，它直接查表（look them up）**。在事實型問題上的準確度差距是顯著的。KEPLER 代表的是「神經符號融合（neuro-symbolic）」路線——符號系統（KG）提供可驗證的事實，神經網路提供語意理解，兩者聯合訓練。 --- ### Document 6 — Anthropic 與 Claude 在圖譜中的三層相關連結： - [www.anthropic.com/customers/graph](https://www.anthropic.com/customers/graph) - [github.com/anthropics/anthropic-cookbook](https://github.com/anthropics/anthropic-cookbook) - [github.com/modelcontextprotocol](https://github.com/modelcontextprotocol) Anthropic 沒有一個叫「Graph Engineering」的產品。它的做法是把 Claude 直接整合進圖譜架構的三個層次（layer）。 #### Layer 1 — Claude 從文字中萃取圖譜 ```text Documents ↓ Claude extracts entities and relationships ↓ JSON triples: { "subject": "Anthropic", "relation": "created", "object": "Claude" } ↓ Knowledge Graph ``` Claude 負責實體萃取（entity extraction）、關係萃取（relation extraction）、去重（deduplication）、正規化（normalization）以及 ontology 草擬。**過去需要專門 NLP pipeline 才能完成的工作，現在透過一次 API call 就能跑完。** 從架構師角度，這層是把「非結構化 → 結構化」的轉換成本降到接近零，是 KG 能普及化的關鍵 enabler。 #### Layer 2 — Claude 查詢圖譜 ```text User Question ↓ Claude ↓ Cypher / SPARQL query ↓ Knowledge Graph ↓ Result ↓ Claude explanation in plain language ``` Claude 把自然語言翻譯成圖查詢語言（Cypher / SPARQL），對 Neo4j 或任何圖資料庫執行，再用白話解釋結果。**使用者完全不需要具備查詢語言知識。** 這層的工程價值是「把圖資料庫的查詢能力民主化」——過去要寫 Cypher 才能用圖資料庫，現在用自然語言即可。 #### Layer 3 — MCP 把 Claude 接上圖譜連結：[github.com/modelcontextprotocol](https://github.com/modelcontextprotocol) ```text Claude ↓ MCP Protocol ↓ Graph Database ↓ Entities + Relationships ↓ Claude with full graph context ``` **MCP（Model Context Protocol）是傳輸層，讓 Claude 永久存取任何知識圖譜，而不必每個 session 重建連線。** 從系統設計角度，MCP 解決的是「LLM 與外部資料源的連接標準化」問題——它把「LLM ↔ 工具/資料庫」的整合從「每個應用自己寫膠水碼」變成「統一協定」，這對 KG 的長期維運（連線管理、權限、schema 同步）至關重要。 --- ### The LaunchNotes 案例 — 真實生產數字連結：[www.anthropic.com/customers/graph](https://www.anthropic.com/customers/graph) ![Image](https://pbs.twimg.com/media/HNlNyqeWYAAPg_R?format=jpg&name=large) LaunchNotes 打造了一個叫 Graph 的產品，串接 GitHub、Jira、Linear 三個系統。Claude 分析橫跨這三個系統的工程工作關係： ```text GitHub commits + Jira tickets + Linear tasks ↓ Graph of Engineering Work ↓ Claude ↓ Incident Detection + Project Insights ``` Anthropic 案例研究的成果數字： ```text Incident detection | up to 5x faster Meeting time | approximately 50% reduction Release notes | generated automatically in seconds ``` 這些數字來自「連接結構化的關係資料」，而不只是搜尋文件。從產品角度，LaunchNotes 證明了「KG + LLM」可以在真實 SaaS 產品中變現——它賣的不是「更聰明的搜尋」，而是「跨系統的工程情報（engineering intelligence）」。 --- ### 知識圖譜（knowledge graph）到底是什麼在動手建一個之前，先把根本概念講清楚。知識圖譜以三元組（triples）儲存資訊： ```text Subject → Relation → Object ``` 範例： ```text Anthropic → created → Claude Claude → supports → MCP MCP → connects → external tools Microsoft → built → GraphRAG GraphRAG → reduces token cost by → 85% ``` **每一筆資訊都是兩個實體之間的顯式關係。不是一段「可能包含這個資訊」的文字段落，而是一個顯式、結構化、可查詢的事實（fact）。** ```text Regular database: Table of companies Table of products No explicit relationships between them Knowledge graph: Company → created → Product Product → competes with → Other Product Other Product → owned by → Other Company Company → invested in → Other Company ``` **圖不只儲存事實，它還儲存「事實之間如何連結」**——這正是複雜推理之所以可能的根本原因。從資料建模角度，RDBMS 把關係藏在 foreign key 與 JOIN 裡，查詢時要「事先知道 join 路徑」；KG 把關係提升為第一公民（first-class citizen），可以探索性地多跳遍歷，這對「不知道要問幾跳」的問題更友善。 --- ### 完整的 Graph Engineering pipeline（9 步） ```text Step 1 | Collect raw documents | PDFs, emails, reports, database exports Step 2 | Extract entities | people, companies, products, events, concepts Step 3 | Extract relationships | who did what to whom, when, why, how Step 4 | Build schema | define entity types and relationship types Step 5 | Deduplicate and normalize | "Microsoft Corp" and "MSFT" are the same entity Step 6 | Store in graph database | Neo4j, Amazon Neptune, PostgreSQL with graph extension Step 7 | Build retrieval layer | local search for specific entities | global search for patterns across entire graph Step 8 | Connect model | Claude queries graph via MCP or direct API Step 9 | Update continuously | new documents expand the graph | contradictions get flagged for review ``` 架構師視角的補充： - **Step 2-3 是萃取層**：決定 KG 的召回率（recall）。萃取 prompt 品質直接影響後續所有查詢。 - **Step 4 schema 是合約**：entity type 與 relation type 一旦上線就很難改（schema migration 在圖資料庫比 RDBMS 更痛），需要前期投資設計。 - **Step 5 dedup/normalize 是品質門**：這是 zero-shot 最不可靠的階段，需要 human-in-the-loop。 - **Step 7 是雙模檢索**：local search 用 embedding 找特定節點鄰居，global search 用 community reports 找全局 pattern——這正是 Microsoft GraphRAG 的核心設計。 - **Step 9 是長期治理**：圖譜不是建一次就完工，它需要持續更新與矛盾偵測，這部分的維運成本常被低估。 LLM-assisted Knowledge Graph Engineering 論文（[arxiv.org/abs/2307.06917](https://arxiv.org/abs/2307.06917)）benchmark 了語言模型在上述每個步驟的表現。誠實的發現是：**LLM 是萃取與正規化的優秀助手，但 zero-shot graph generation 在 production 環境仍不夠可靠，schema 與 dedup 步驟需要人類 review。** 這是全文最重要的誠實警告，也是判斷「是否該上 KG」的關鍵門檻。 --- ### 跑完整個 pipeline 的 5 個 prompts Graph Engineering 並沒有消除 prompt，而是把 prompt 用在 pipeline 的每個特定階段。 #### Prompt 1 — Extraction（萃取） ```text Extract all organizations, people, products and events. For each entity return: - canonical_name - type - description - source For each relationship return: - source_entity - relation_type - target_entity - evidence - confidence_score ``` 關鍵設計：要求回傳 `source`（來源出處）與 `evidence`（證據）與 `confidence_score`（信心分數）——這三個欄位是後續 grounded answer 與 maintenance 階段的基礎，沒有它們就無法做可驗證性（verifiability）。 #### Prompt 2 — Normalization（正規化 / 去重） ```text Compare the following entities. Determine whether they refer to: - the same entity - related but different entities - unrelated entities Return canonical name and explanation. Do not merge entities without clear evidence. ``` 關鍵設計：「Do not merge entities without clear evidence」——這是防止「過度合併（over-merging）」的護欄。錯誤合併兩個不同實體會污染整條關係鏈，比漏萃取更嚴重。 #### Prompt 3 — Graph query（圖查詢翻譯） ```text Translate the user question into a Cypher query. Use only relationships present in the schema. Do not invent labels or properties. Return the query and a short explanation of the logic. ``` 關鍵設計：「Use only relationships present in the schema / Do not invent labels or properties」——這是防止 LLM 幻覺（hallucinate）出 schema 裡不存在的關係，是 grounded query 的核心護欄。 #### Prompt 4 — Grounded answer（有根據的答案） ```text Answer using only the retrieved graph paths. For every conclusion: - identify the supporting nodes - identify the relationship path - state uncertainty clearly - do not infer causation from correlation ``` 關鍵設計：「do not infer causation from correlation」——這是防止把「A 與 B 相關」講成「A 導致 B」的邏輯謬誤護欄，是法律、醫療、金融等高風險領域必備。 #### Prompt 5 — Graph maintenance（圖譜維護） ```text Compare new facts with the existing graph. Classify each fact as: - new - duplicate - contradiction - update - uncertain Do not overwrite existing facts without evidence. ``` 關鍵設計：「Do not overwrite existing facts without evidence」——這是防止「新文件覆蓋舊事實」的護欄，保護圖譜的歷史完整性。五種分類（new/duplicate/contradiction/update/uncertain）對應圖譜持續演進的五種狀態轉移。正如 Microsoft GraphRAG 文件所示——prompt 內部處理了萃取、關係識別、摘要與 community report 生成。**Prompt engineering 是 graph engineering 內部的機制，而不是它的競爭者。** 這句話修正了一個常見誤解：「用了 Graph 就不用調 prompt」是錯的，真相是「prompt 從單次問答，被重組成 pipeline 五階段的工程化 prompt」。 --- ### 建立在知識圖譜上的 5 個商業應用 #### 1 — 盡職調查平台（Due diligence） ```text Corporate reports + founders + investors + legal cases + subsidiaries + transactions ↓ Knowledge Graph ↓ Claude ↓ Risk analysis + hidden connections + conflict of interest detection ``` 客戶：投資基金、律師事務所、銀行、M&A 顧問。每月 retainer $2,000–10,000 / 客戶。這個領域的付費意願高，因為「隱藏關係（hidden connections）」與「利益衝突偵測（conflict of interest detection）」直接關係到交易決策與法規風險。 #### 2 — 業務情報（Sales intelligence） ```text Contacts + companies + roles + previous emails + company problems + product ↓ Knowledge Graph ↓ Who influences the decision Which objections repeat Which case study to show this specific client Where the deal is blocked ``` 價值在於「關係視角」——不是看單一聯絡人，而是看「誰影響決策、哪個 case study 對這個客戶有效、deal 卡在哪」。 #### 3 — 工程情報（Engineering intelligence） ```text GitHub commits + Jira tickets + Linear tasks ↓ Graph of Engineering Work ↓ 5x faster incident detection 50% less meeting time Automatic release notes ``` LaunchNotes 已經在賣這個。市場是「所有使用超過一個專案管理工具的工程團隊」。這是關係密度最高、ROI 最直接的應用，因為 commit / ticket / task 本來就帶有天然關係（誰改了什麼、哪個 ticket 對應哪個 commit）。 #### 4 — 研究情報（Research intelligence） ```text Papers + authors + institutions + methods + datasets + results + contradictions ↓ Knowledge Graph ↓ Which GraphRAG methods use community detection On which datasets they were tested Which papers contradict each other ``` 學術研究本來就是高度關聯的領域（引用、合作、方法繼承、資料集共用），KG 能回答「哪些方法用了 community detection」「哪些 paper 互相矛盾」這類文獻綜述問題。 #### 5 — 個人知識作業系統（Personal knowledge OS） ```text Obsidian notes + emails + calendar + PDFs + contacts + tasks ↓ Personal Knowledge Graph ↓ Who did I discuss this idea with Which tasks depend on one person's response Which decisions contradict previous agreements What did I promise to do this month ``` 這正是 Obsidian vault、PKM（personal knowledge management）領域的自然延伸——把零散筆記、郵件、行事曆串成一張個人關係圖。 --- ### 連結 Microsoft、Stanford、Anthropic 的範式位移（shift） ```text Prompt Engineering | how to ask the right question RAG | which document to find Graph Engineering | which entities exist | how they connect | which path leads to the answer | what changes if one node changes ``` 這個對照表清楚呈現三個範式的遞進： - **Prompt Engineering** 關心「怎麼問對問題」。 - **RAG** 關心「找哪份文件」。 - **Graph Engineering** 關心「哪些實體存在、它們怎麼連、哪條路徑通往答案、改變一個節點會牽動什麼」。 **LLM 知道字詞，知識圖譜知道關係。最強大的 AI 系統，誕生於兩者協同運作之時。** - Microsoft 在 production 用 GraphRAG 證明了這點——18% 準確度提升、85% 成本下降。 - Stanford 在研究中用 DSPy、STORM 與 scaling laws paper 證明了這點。 - Anthropic 在 LaunchNotes 案例中證明了這點——5 倍事件偵測速度、50% 會議時間縮減。 **三個組織。三條獨立路徑。同一個結論。** **模型找的是文字。圖譜找的是現實。把圖蓋出來。** 多數開發者會繼續優化他們的 prompt，然後納悶為什麼複雜問題始終給出爛答案。少數人會花一個週末蓋出第一個知識圖譜，然後再也回不去搜尋文件的老路。 --- ## 總結與結論 1. **RAG 的天花板是「搜尋單位」**：RAG 搜尋「文字片段」，Graph Engineering 搜尋「關係」。複雜問題（why / causation / 跨文件 pattern）的答案散落在關係裡，不在文字裡，所以 RAG 在 local question 有效、在 global question 失效——這是 Microsoft GraphRAG 區分 Local Search / Global Search 的根本原因。 2. **三方獨立收斂到同一個 scaling law：好圖勝過大模型**。Microsoft 的 18% / 85% / $0.004 是工程實證；Stanford 的「26 模型 benchmark：小模型 + 好圖 > 大模型 + 爛圖」是理論；Anthropic 的 LaunchNotes 5x / 50% 是產品化。三者共同指向：**模型周圍的系統（圖譜）比模型本身更能決定輸出**。 3. **Graph Engineering 的科學根據是「顯式關係 > 推斷關係」**。MIT relational memory 與 KEPLER 證明：當關係被顯式儲存為三元組，模型從 infer 退化為 lookup，產出更連貫、邏輯錯誤更少。Anthropic 的三層架構（萃取 / 查詢 / MCP）把這個原理產品化——過去需要專門 NLP pipeline 的工作，現在透過 API call + 標準協定即可完成。 4. **它不是消滅 prompt，而是把 prompt 工程化到 pipeline 的 5 個階段**。5 個 prompt（extraction / normalization / query / grounded answer / maintenance）各自的護欄設計（不無證據合併、只用 schema 內關係、不從相關推因果、不無證據覆蓋舊事實）才是 KG 品質的真正決定因素。這 5 個 prompt 的設計品質 = 你的 KG 品質。 5. **落地前必算的總持有成本**：Graph Engineering 是「重資產、輕查詢」架構——query 端成本降 85%，但 indexing 端（萃取、建圖、社群偵測、community reports）的 LLM call 成本會隨文件量線性成長，且 schema 設計、dedup、持續更新都需要 human-in-the-loop（zero-shot graph generation 在 production 仍不夠可靠）。它的甜區是「關係密度高、查詢頻率高、資料變動慢、付費意願高」的垂直領域（盡職調查、工程情報、研究情報），而非所有 RAG 場景的通用替代品。

Obsidian 整理原始文章

AI視野

OpenAI做了块小键盘，包揽了人类能做的最重要的事情！

"當 AI 從「回答問題」升級到「動手做事」，人類的工作從寫提示詞，變成在批准鍵前慢十秒。"

Top 5 Insights

**介面轉向**：Codex Micro 的硬體化，是 AI 工作從「對話框」走向「控制台」的訊號——當 AI 輸出帶副作用，狀態可視與實體批准就成為必要，人身分從「提問者」轉為「Agent 值班經理」。
**瓶頸轉移**：Agent 時代的瓶頸不在 AI 聰不聰明，而在「批准」這個人類動作——它被壓成一次按鍵，使判斷容易退化成反射（vigilance decrement）。
**完成感 ≠ 正確性**：`exit code == 0` 只代表命令跑完，不代表功能正確；AI 報告的流暢度，不等於證據的充分性——這是批准失誤的技術根因。
**5 問 + 3 色**：把批准從直覺升級成流程——5 問（改了什麼/憑什麼說對/影響多大/能否撤回/誰負責）配 3 色（綠快速/黃抽查/紅人工），依風險量級差異化確認強度。
**不可外包的最後一厘米**：AI 接走執行，接不走後果與責任；省下的時間裡，永遠要留十秒給判斷——這是 Agent 時代人類最該訓練的能力。

--- tags: [AI視野, Agent時代, 人機協作, 批准治理] date: 2026-07-20 read: false source: "2026-07-20T100441+0800-OpenAI做了块小键盘，包揽了人类能做的最重要的事情！.md" original_title: "OpenAI做了块小键盘，包揽了人类能做的最重要的事情！" --- # OpenAI做了块小键盘，包揽了人类能做的最重要的事情！ ![Image](https://pbs.twimg.com/media/HNlacEdbEAAf9HU?format=jpg&name=large) 原始來源與檔名：2026-07-20T100441+0800-OpenAI做了块小键盘，包揽了人类能做的最重要的事情！.md --- ## SOURCE | 資訊源評估 - **準確性**：中 - 作者明言「還沒摸到實物」，所有鍵位/燈效/旋鈕功能皆依 OpenAI 與 Work Louder 官方頁面核對，硬體描述屬二手；但「批准治理」論述部分為作者實務經驗推導，邏輯自洽。 - **易理解性**：高 - 用硬體（230 美元鍵盤）當鉤子帶出抽象的 Agent 治理議題，比喻生活化，5 問 + 3 色框架可直接複製使用。 - **閱讀策略建議**：跳過硬體規格細節，把重心放在「介面轉變」「完成感 ≠ 正確性」「批准前 5 問」三段——這才是文章比鍵盤更重要的部分。 ## NAPKIN | 餐巾紙 ### 餐巾紙公式 > 批准鍵 = 把（證據 × 風險 × 責任）壓縮成一次按下 _當 AI 從「產生答案」升級到「動手做事」，它接走了執行，人類剩下唯一不可外包的動作——判斷這次結果能不能走進現實。_ ### 一句話 > 當 AI 從「回答問題」升級到「動手做事」，人類的工作從寫提示詞，變成在批准鍵前慢十秒。 ### 餐巾紙草圖 ``` 過去現在（Agent 時代） ┌────────────────────── ┌────────────────────── │ 人 ─問─> AI │ AI 改檔 / 跑指令 / 開任務 │ <─答── 一段文字 │ （多條工作線同時跑） │ │ │ 慢的是 AI │ 慢的是「點通過的手」 └────────────────────── └────────────────────── │ ▼ ┌────────────────────── │ 批准鍵 = │ 證據 + 風險 + 責任 │ 完成燈 ≠ 正確燈 └────────────────────── ``` ## ROUND 1: SKELETON | 骨架掃描 - **核心問題**：當 AI 從產生答案升級到動手做事，人類在這條工作流裡的新瓶頸是什麼？ - **核心答案**：新瓶頸不是 AI 不夠聰明，而是「批准」這個動作——它把判斷壓成一次按鍵，讓人從判斷滑向反射。 - **論證結構**：硬體（Codex Micro）切入 → 提煉人機關係轉變（值班經理）→ 點出批准鍵風險（判斷→反射、完成感欺騙）→ 提出 5 問 + 3 色分級 → 收束在「慢十秒」。 ### 章節骨架（條列） - 開頭：Codex Micro 硬體介紹（13 鍵 + 旋鈕 + 搖桿、5 色燈效、可重映射） - 轉折：從「接受/拒絕」兩個最普通的鍵，看出 Agent 時代介面正在變 - 核心命題：人變成一群 Agent 的值班經理；該慢下來的是「點通過的手」 - 一個按鍵暴露 Agent 時代新瓶頸（動作可省，後果不可省；完成感的欺騙性） - 點批准之前的 5 問（改了什麼 / 憑什麼說對 / 錯了影響多大 / 能否撤回 / 誰負責） - 三色批准分級（綠快速 / 黃抽查 / 紅人工驗收） - 結語：別把完成燈當成正確燈，慢十秒 ## ROUND 2: DISSECTION | 血肉解剖 ### 論證鏈（ASCII） ``` AI 從「產生答案」升級到「改檔 / 跑指令 / 開任務」 │ ▼ 介面從聊天框 → 實體控制台（Codex Micro） │ （狀態可視 + 任務切換 + 一鍵批准） ▼ 人變成 Agent 值班經理，慢的從 AI 變成「批准的手」 │ ▼ 批准被壓成一次按鍵 → 判斷容易退化成反射 │ ▼ 完成感（報告流暢）被誤當成證據充分 │ （exit code 0 ≠ 功能正確） ▼ 一次錯誤批准 → 影響擴散到真實業務（不可逆） │ ▼ 解法：批准前 5 問 + 3 色分級 → 慢十秒 ``` ### 3 個關鍵證據 1. **燈效狀態機**：白/藍/綠/黃/紅 = 空閒/思考/完成/需輸入/錯誤——任務狀態被壓進硬體本身，這是「AI 工作介面正在實體化」最直接的硬證據。 2. **exit code 0 陷阱**：「退出碼為 0 只能說明那條命令跑完了，不代表使用者看到的功能一定正確」——這是「完成感 ≠ 正確性」的技術根因，區分了「指令流程完成」與「可觀察行為成立」兩個不等價的命題。 3. **風險不對稱**：改本地草稿可撤銷 vs 改資料庫/發訊息/刪檔/覆蓋線上配置——同一個通過按鈕，後果量級完全不同，證明「批准」不能是單一確認強度。 ### 隱形假設與邊界 - **假設**：使用者有能力看懂「變化清單/差異/證據」。但非技術使用者（改文章/發郵件）可能連 diff 都看不懂，5 問落地有門檻。 - **假設**：批准是離散動作，可「慢十秒」。但高頻 Agent 任務下，批准疲勞會讓 5 問流於形式，個人紀律不一定扛得住規模。 - **邊界**：作者沒摸到實物（明說「不裝實測」），鍵位/燈效/手感皆來自官方頁面，硬體體驗為二手。 - **邊界**：5 問是通用框架，但不同任務類型（程式碼 vs 內容 vs 批量資料）的證據形式差異很大，文章只點到、未展開。 ## ROUND 3: SOUL | 靈魂提取 - **作者盲點**： - 把「批准」簡化成個人紀律問題（慢十秒），沒談組織層面的「批准權限治理」——誰能批准紅色任務、審計軌跡、多人複核。 - 沒區分 Agent 的「自主性光譜」：只改本地檔案的 Agent 與能動生產環境的 Agent，批准策略應在架構層就分流，而非只靠人腦分色。 - **知識連接**： - 呼應 human-in-the-loop（HITL）研究：自動化程度越高，人類監督的「警覺性退化」（vigilance decrement）越嚴重——正是「判斷→反射」的學名。 - 對照 CI/CD 的 pipeline gate：軟體工程早用「必須通過測試才能合併」把批准結構化；Agent 時代其實是把這套 gate 搬到日常操作。 - 呼應防錯設計原則：把高風險動作設計成需要刻意、明確的確認，而非一鍵完成。 - **行動觸發**： - 個人：把 5 問 + 3 色卡寫進自己的 Agent 規則檔（cursor rules / claude code CLAUDE.md / codex AGENTS.md）。 - 團隊：為「外部寫入/付費/生產環境」類任務設計雙人複核 + 審計日誌，不讓單人一鍵批准。 - 工具：給 Agent 設「乾跑（dry-run）」模式與「撤回（rollback）」開關，把第四問（能否撤回）工程化。 ### 留白提問（2 題） 1. 當 Agent 任務量從一天 3 個變成 300 個，「慢十秒」還可持續嗎？批准疲勞會不會讓 5 問自動坍縮成「全綠全批准」？這時該靠人紀律，還是架構層的 quota / 限流 / 自動化 gate？ 2. Codex Micro 把批准做成實體鍵，是降低了判斷負擔，還是反而用觸覺快感加速「判斷→反射」的退化？實體化的人機介面，對高風險決策究竟是防線還是催化劑？ ### 跨域映射 - **航空業**：起落架/武器發射的雙人確認 + 實體保護蓋（guard）——把不可逆動作的批准，做成需要刻意、費力的實體動作。 - **金融交易**：大額轉款的雙簽 + 延遲結算——用流程摩擦對抗衝動批准。 - **核電廠**：關鍵操作的「兩人原則」（two-person rule）——高後果動作不授權給單一個人。 ## DEEP READ | 精讀指引 **推薦理由**：這篇文章真正的價值不在那塊 230 美元的鍵盤，而在它把一個抽象的「Agent 治理」問題，壓縮成一個你摸得到的按鍵。作者用硬體當鉤子，把讀者騙進一個比鍵盤重要得多的討論：當 AI 開始動手，人類最該訓練的不是 prompt 技巧，而是「批准判斷力」。建議放慢讀三段： 1. **「按鈕替你省掉的是動作，替不了的是後果」**——這句是全文樞紐。停下來想：你目前用 Agent 時，有哪些「後果」你根本沒想過會發生？ 2. **「退出碼為 0 只能說明那條命令跑完了，不代表使用者看到的功能一定正確」**——這是技術人最容易踩的坑。把這句話貼在螢幕上。問自己：你上次批准 Agent 任務時，看的是 exit code 還是真實的功能輸出？ 3. **「要是在出問題時，所有人第一反應都是去問 AI 當時為什麼這麼做，說明這條任務從一開始就沒有真正的負責人」**——這句是組織診斷。對照你團隊現在的 Agent 任務，能明確指出每條任務的「最終驗收人」嗎？ **認知阻力**：讀的時候強迫自己不要點頭。每讀一個「5 問」，先想「我現在日常的 Agent 使用中，哪一問我幾乎從來沒做過？」那一問，就是你下一次出事的地方。 ## STRUCTURE MAP | 全書結構圖 ``` Codex Micro（硬體鉤子） │ ├─ 13 鍵 + 旋鈕 + 搖桿 / 5 色燈效 / 可重映射 │ ▼ 轉折：從「接受/拒絕」兩個鍵看出 │ ▼ 命題：人 = Agent 值班經理 │ 慢的從 AI 變成「批准的手」 ▼ 瓶頸：批准鍵壓縮判斷 → 判斷退化成反射 │ 完成感 ≠ 正確性（exit code 0 ≠ 功能正確） ▼ 解法層 1：批准前 5 問 ├─ 1 改了什麼（變化清單） ├─ 2 憑什麼說對（證據 / exit code 陷阱） ├─ 3 錯了影響多大（風險量級） ├─ 4 能否撤回（rollback / 先 3 樣本試跑） └─ 5 誰負責（最終驗收人） │ ▼ 解法層 2：3 色分級 ├─ 綠快速批准（範圍小/可撤回/自動檢查） ├─ 黃抽查（多檔/外部服務/批量） └─ 紅人工驗收（刪除/權限/付款/發布/生產） │ ▼ 收束：慢十秒，把判斷留給人 ``` --- # OpenAI做了块小键盘，包揽了人类能做的最重要的事情！ (Architectural Deep Dive) ## 前言/背景 2026 年 7 月，OpenAI 與硬體廠 Work Louder 推出一塊 230 美元的小鍵盤 **Codex Micro**。表面看是周邊商品，本質上它是 OpenAI 對「Agent 時代人機介面」的一次宣言：當 AI 從「回答問題」升級到「動手做事」，人類的操作介面也該從聊天框，演化成一個看得見狀態、切得了任務、按得下批准的實體控制台。作者（老金）明言本文不裝實測——硬體規格依官方頁面核對，真正的重點是：**這塊鍵盤把「批准」這件麻煩事，擺到了桌面上**。本文以此為切入點，拆解 Agent 時代被嚴重低估的新瓶頸——人類的批准判斷力。 ## 章節詳細總結 ### 硬體解剖：Codex Micro 的控制面 Codex Micro 的設計邏輯是：**用實體輸入對抗視窗切換的認知成本**。過去看 3 條 Codex 任務要連續打開 3 個會話；現在按鍵顯示任務狀態、搖桿調出審查 PR 與排查錯誤流程、旋鈕調整 AI 的思考深度。 ![Image](https://pbs.twimg.com/media/HNlaeLvaIAAK17S?format=jpg&name=large) 硬體構成： - 13 個機械鍵 + 1 個旋鈕 + 1 個搖桿 - **頂部 6 枚半透明 Agent 鍵**：對應正在運行的 Codex 任務 - **下方 6 枚命令鍵**：接受 / 拒絕 / 按住說話 / 新建聊天 / 分支線程 / 自定義動作 - **左上四向搖桿**：最多掛 4 個預設或自定義 Skill - **右上旋鈕**：調推理深度（reasoning depth，即模型 reasoning effort） - **左下觸摸區**：切換最多 6 層佈局（layer）燈效狀態機（5 色 → 5 態，把 Agent 任務狀態壓進硬體本身）： - 白 = 空閒 - 藍 = 思考中 - 綠 = 完成 - 黃 = 需要輸入（人類介入點） - 紅 = 錯誤關鍵設計在於：**這不是焊死的固定鍵位**。鍵、旋鈕、搖桿動作都可重映射，隨盒附 32 枚圖標鍵帽可替換。鍵帽標示「目前這個位置放什麼功能」，不代表永遠只做這件事——這是一個**可程式化的實體層**，硬體只是輸入介面，語義由軟體定義。 ![Image](https://pbs.twimg.com/media/HNlahf3bIAAtJNt?format=jpg&name=large) ### 介面轉變：從聊天框到實體控制台讓作者停下來仔細看的，是上面兩個最普通的動作——**接受與拒絕**。過去與 AI 互動是「問→答」：人輸入 prompt，AI 回傳一段文字，結果不好大不了重寫。但 Codex（與一般 Agent）做的事是**帶副作用（side effect）的操作**： - 改專案裡的檔案 - 跑終端命令 - 開任務（spawn tasks） - 同時推進多條工作線當 AI 的輸出從「文字」變成「對真實系統的寫入」，介面就必須跟著變。OpenAI 把它做成「能看狀態、能切任務、能直接批准」的實體控制台，**說明 AI 工作的介面正在從對話框轉向控制台**。 ![Image](https://pbs.twimg.com/media/HNlakk0bgAAnQO_?format=jpg&name=large) 這對應一個身分轉變：**人不再只是提問者，開始變成一群 Agent 的值班經理（on-call operator）**。時間結構也反轉了：過去慢的是 AI；現在 AI 越跑越快，真正該慢下來的，反而是那隻準備點「通過」的手。問題隨之而來——批准這件本來需要看證據、想後果的事，一旦被壓成桌面上一個按鍵，**人很容易從判斷變成反射**。所以本文不聊這塊鍵盤值不值 230 美元，而是把更重要的東西說清楚：AI 越會幹活，你越不能只學會怎麼發任務，還要學會在點批准之前問對 5 個問題。 ### 一個按鍵，暴露了 Agent 時代的新瓶頸產品頁把 Codex Micro 稱為「Agent 工作的指揮中心」：不同任務在想、在跑、在等輸入還是已完成，透過燈光一眼可見；高頻動作放上實體命令鍵，省掉在多個聊天與視窗間來回翻。 ![Image](https://pbs.twimg.com/media/HNlam5abkAAs8LM?format=jpg&name=large) 作者點出關鍵的對稱與不對稱： - **對稱**：它確實省時間——省掉的是切換和操作。 - **不對稱**：責任沒有被省掉，仍留在人手裡。**「按鈕替你省掉的是動作，替不了的是後果。」** 風險量級的躍遷： - 當 AI 只生成文案 → 結果不好大不了重寫（可逆、低影響） - 當 AI 能改資料庫、發訊息、刪除檔案、提交程式碼、更新線上頁面 → 一次錯誤批准會**擴散到真實業務**（不可逆、高影響）更隱蔽的是**完成感的欺騙性**：AI 給出的完成感很強，它會列出改了哪些檔案、跑了哪些檢查、為什麼認為任務已結束。文字越完整，人越容易把「表達流暢」誤當成「證據充分」。作者自述的最高警覺時刻：看到任務亮綠燈，手已經想點通過，腦子卻還沒回答「什麼才算做對」。 > Agent 時代真正稀缺的，是一套不會被完成感帶跑的批准規則。 ### 點批准之前，先問這 5 件事這 5 問不只程式設計師能用——改文章、整理客戶資料、生成海報、發郵件、更新知識庫，都可以照著過一遍。 **第一問｜它到底改了什麼？** 別只看 AI 自己的總結，要看「能被核對的變化清單」： - 程式碼任務 → 看差異（diff）與檔案列表（`git status` / `git diff`） - 內容任務 → 看改前改後 - 批量任務 → 看處理數量、失敗數量、跳過項連變化範圍都說不清，就先別批准——點下去接住的是一團「自己還沒看見邊界」的變化。 **第二問｜它憑什麼說做對了？** 讓 AI 把證據擺出來：測試是否真的運行、頁面是否真實打開、連結是否可訪問、引用是否回到原始來源、關鍵數字是否能在官方頁面找到。 AI 最擅長把任務講得像已經完成，人最容易在這時把工作匯報當成驗收單。**這裡最容易犯的錯，是把「命令沒報錯」當成「目標已經完成」**： > 退出碼為 0 只能說明那條命令跑完了，不代表使用者看到的功能一定正確。這是一個技術性根因區分： - `exit code == 0` → 「該指令的執行流程完成」 - 「功能正確」→ 「使用者可觀察的預期行為成立」兩者不等價，而 Agent 容易用前者冒充後者。 ![Image](https://pbs.twimg.com/media/HNlapc9bIAA7pHI?format=jpg&name=large) **第三問｜錯了會影響多大？** 同一個通過按鈕，背後風險完全不同： - 改本地草稿 → 可撤銷 - 批量改客戶資料 / 覆蓋線上配置 / 對外部聯絡人發訊息 → 錯誤會立刻離開你的電腦影響範圍越大，批准需要的證據越多。**外部寫入、付費操作、帳號權限、生產環境、公開發布，都不應該跟改草稿共用同一種輕率的確認方式。** 任務越快，批准越不能靠手感。 **第四問｜出問題能不能撤回？** 批准之前先找退路：檔案有沒有版本記錄、資料有沒有備份、發布能不能回滾（rollback）、批量操作能不能從中斷處恢復（resumable）。沒有撤回方案的任務，不適合一次全開。作者給出的工程化試跑流程——**先 3 樣本試跑**： ``` 1. 先拿 3 個樣本試跑 2. 逐個對照改前改後 3. 故意製造一次失敗，看它能不能停住並回到原狀態 4. 三項都過，再逐步放大範圍 ``` > 第一次慢一點，通常比全量返工便宜。能撤回的自動化才是效率。沒有退路的全自動，更像一次下注。 **第五問｜最後誰來負責？** AI 可以接走操作，接不走「結果後面那個具體的人」。最好在任務開始前就寫清楚： - 誰定義完成標準 - 誰核對關鍵證據 - 誰有權點最終通過診斷訊號：**要是出了問題，所有人第一反應都是去問 AI 當時為什麼這麼做，說明這條任務從一開始就沒有真正的負責人。** ### 我會把批准分成三種顏色 5 問過完，再做一個簡單的分級。顏色只是提醒——**風險越大，手就要放得越慢**。 ![Image](https://pbs.twimg.com/media/HNlaruPbsAADGcz?format=jpg&name=large) - **綠色（快速批准）**：範圍小、容易撤回、有自動檢查，錯誤不影響外部使用者。例：整理本地筆記、生成草稿、給測試專案改樣式。 - **黃色（必須抽查）**：會改多個檔案、呼叫外部服務、批量處理資料，或結果需要人的審美與業務判斷。流程：先看樣本 → 再看失敗項 → 最後放大範圍。 - **紅色（必須停下來人工驗收）**：刪除資料、修改權限、付款、公開發布、觸達客戶、更新生產環境。AI 可以準備材料和執行預演，最終批准要留給明確的人。可直接複製到自己 Agent 規則裡的卡： ``` 批准前 5 問 1｜改了什麼，變化清單在哪 2｜證據在哪，什麼證明目標真的完成 3｜影響多大，錯誤會不會離開當前環境 4｜能否撤回，備份/回滾/恢復路徑是什麼 5｜誰來負責，最終驗收人是誰綠色｜範圍小、可撤回、自動檢查充分黃色｜先抽查樣本和失敗項，再擴大範圍紅色｜外部寫入/權限/付款/發布/生產環境必須人工驗收 ``` ### 別把完成燈當成正確燈回頭看 Codex Micro，那枚批准鍵就沒那麼普通了。它沒有替你判斷，只是把判斷**壓縮成一次按下**。前面的搜尋、修改、運行都能由 Agent 不斷提速，最後這一厘米的動作，反而裝著整條工作流裡最重的三樣東西——**證據、風險、責任**。時代命題正在轉移： - 過去大家擔心 AI 不夠聰明 → 拼命研究提示詞，想讓它少走彎路。 - 現在它開始真的動手 → 人的新功課也變了：**任務越像完成，越要有人願意停下來核對**。燈會亮、報告會寫得很完整、完成狀態會準時出現——但它們只能告訴你「Agent 走到了哪裡」，不能替你決定「這個結果能不能走進現實」。作者立場鮮明：當然願意把重複執行交給 AI。它替我省下來的時間越多，我越不想把最後的判斷也一起省掉。 > 下一次手指落到通過鍵上，慢十秒。AI 替你省下來的時間很多，其中十秒，留給判斷。 ## 總結與結論 1. **介面轉向**：Codex Micro 的硬體化，是 AI 工作從「對話框」走向「控制台」的訊號——當 AI 輸出帶副作用，狀態可視與實體批准就成為必要，人身分從「提問者」轉為「Agent 值班經理」。 2. **瓶頸轉移**：Agent 時代的瓶頸不在 AI 聰不聰明，而在「批准」這個人類動作——它被壓成一次按鍵，使判斷容易退化成反射（vigilance decrement）。 3. **完成感 ≠ 正確性**：`exit code == 0` 只代表命令跑完，不代表功能正確；AI 報告的流暢度，不等於證據的充分性——這是批准失誤的技術根因。 4. **5 問 + 3 色**：把批准從直覺升級成流程——5 問（改了什麼/憑什麼說對/影響多大/能否撤回/誰負責）配 3 色（綠快速/黃抽查/紅人工），依風險量級差異化確認強度。 5. **不可外包的最後一厘米**：AI 接走執行，接不走後果與責任；省下的時間裡，永遠要留十秒給判斷——這是 Agent 時代人類最該訓練的能力。

Obsidian 整理原始文章

Agent架構

From Loop Engineering to Graph Engineering?（從迴圈工程到圖工程？）

"單迴圈死於 Goodhart；多迴圈的「圖」解決了形狀問題卻仍可能循環空轉；唯有錨（凍結量度＋凍結規則＋外部價值判斷）能讓改善機制真正碰到現實。恆久的軸不是 loops vs graphs，而是 ungrounded vs grounded。"

Top 5 Insights

**單迴圈是「變好的 hello world」，但它的形狀內含四種結構性失敗**：Goodhart（指標被遊戲化）、向上盲（不能質疑參考值）、衝突（獨立迴圈互打）、量度衰變（無人監看監看者）。這些不是 bug，是單迴圈拓樸的必然後果。
**解法不是更好的迴圈，而是迴圈的圖（graph of loops）**——而且四失敗有四個一對一的拓樸解：配對、層級、仲裁、稽核。**「可靠性住在邊裡」**：誰餵誰、誰監看誰、誰能否決誰，才是設計單位。
**但圖本身有極限**：若每個迴圈都消費 reports 而沒有人碰到地面，圖會退化成「循環互證」——什麼都一致、什麼都沒驗證，比單迴圈更晚更貴地失敗。**拓樸買到精緻，沒買到現實。**
**真正的補丁是「錨」**：錨定量度（錢進銀行、測試真的跑過）、凍結節點（優化器永不可調，如 held-out set）、以及來自圖外的「更好」之根判斷（由人透過真實失敗提供）。最成熟的架構會**誠實標記自己權威的邊界**。
**恆久的對立軸是 ungrounded vs grounded，不是 loops vs graphs**——無論改善機械是什麼形狀，關鍵是它是否持續碰觸現實、監看者是否真獨立、凍結規則是否抗壓、是否承認最深目標是被選擇而非被計算的。**作者唯一的遺憾是用了 "graph" 這個詞**，因為它把一個更細糞的現象（錨與接地）誤導成純拓樸問題。

--- tags: [Agent架構, AI-Agent, 自我改善迴圈, MLOps, Goodhart法則, 系統設計, reward-hacking] date: 2026-07-20 read: false source: "2026-07-20T100802+0800-From Loop Engineering to Graph Engineering?" original_title: "From Loop Engineering to Graph Engineering?" --- # From Loop Engineering to Graph Engineering?（從迴圈工程到圖工程？） ![Image](https://pbs.twimg.com/media/HNhahsJX0AAsPes?format=jpg&name=large) 原始來源與檔名：2026-07-20T100802+0800-From Loop Engineering to Graph Engineering? 原文實際標題：*What the shift in AI agent architecture is really about*（AI Agent 架構典範轉移的真相）作者：@IntuitMachine ｜來源：[X post](https://x.com/IntuitMachine/status/2078419526354378975) ｜發布：2026-07-18 --- ## SOURCE | 資訊源評估 - **準確性**：中–高。這是一篇**論述性綜合（argumentative synthesis）**而非實證研究；但其中引述的觀念——Goodhart's law、PDCA、champion-challenger、drift monitor、held-out set——在 MLOps／控制理論／RL 裡都是技術上成立的工程實踐，並非空談。扣分點在於「人體／公司治理／MLOps 同構」的類比屬於啟發性（heuristic）而非證據性。 - **易理解性**：高。全程用具體敘事（恆溫器、客服團隊、HVAC）承載抽象觀念，沒有術語堆疊。 - **閱讀策略建議**：把「四失敗 → 四拓樸解」的對照表當作**承重結構**逐字讀；但**不要把「graph」當結論**——文章真正要逼出的痛點在最後三分之一：**錨（anchor）**。跳過錨段等於讀到一半。 ## NAPKIN | 餐巾紙 ### 餐巾紙公式 > 變好 ≠ 一個迴圈；變好＝一個結構：互相監看、配對、分層、稽核的迴圈**網路**，而這個網路必須**錨定**在優化器碰不到的現實上。 _單迴圈是「hello world of getting better」；圖是「不耍聰明地變好」；錨才是「真的碰得到現實」._ ### 一句話 > 單迴圈死於 Goodhart；多迴圈的「圖」解決了形狀問題卻仍可能循環空轉；唯有**錨**（凍結量度＋凍結規則＋外部價值判斷）能讓改善機制真正碰到現實。恆久的軸不是 loops vs graphs，而是 ungrounded vs grounded。 ### 餐巾紙草圖 ``` 單迴圈圖（loops 互相監看）錨定的圖 ┌────────── ┌────────── ┌────────── │ 最佳化迴圈 │ 最佳化迴圈 │ 最佳化迴圈 └───┬───── └───┬───── └───┬───── │ │ │ ▼ ▼ ▼ ┌────────── ┌────────── ┌────────── │ 指標（會被作弊） │ 配對反指標 │ 配對反指標 └────────── └───┬───── └────────── │ 互看 │ ┌────────── ▼ │ 稽核迴圈 ┌────────── └───┬───── │ ★ 錨（凍結） ▲ │ 真實營收 │ │ 真的跑過的測試更慢的迴圈 └────────── 擁有參考值 │ ▼ 外部判斷：「更好」是什麼（人／真實失敗，不在圖內）四失敗：Goodhart / 向上盲 / 衝突 / 量度衰變四拓樸解：配對 / 層級 / 仲裁 / 稽核最終補丁：錨 → 讓「接地（grounded）」成立 ``` ## ROUND 1: SKELETON | 骨架掃描 - **核心問題**：為什麼 AI agent（乃至所有自我改善系統）要從「迴圈」走向「圖」？這個轉移**真正修好了什麼**、又**修不好什麼**？ - **核心答案**：單迴圈有四種**結構性**失敗（Goodhart、向上盲、衝突、量度衰變）；解法不是「更好的迴圈」而是互相監看的迴圈**圖**；但圖若無**錨**仍會循環空轉——所以恆久的對立軸是 **grounded vs ungrounded**，不是 loops vs graphs。 - **論證結構**：現象（meme）→ 失敗案例（客服團隊）→ 迴圈原子論 → 四失敗 → 圖的拓樸解 → 圖的極限 → 錨 → 趨勢預測 → 恆久軸重構。 ### 章節骨架（條列） 1. 開場：Peter Steinberger 的九字笑話引爆共鳴。 2. 「為什麼自我改善其實是網路問題」——客服團隊用一季蓋出完美的 feedback loop，續約率卻翻倍惡化。 3. The loop：變好的**原子**（四行程引擎：Choose → Reference → Gap → Act）。 4. 單迴圈在哪崩壞：**四種結構性失敗**。 5. The graph：loops 監看 loops（MLOps pipeline、公司治理、人體生理）。 6. 這個轉移**真正**是什麼：圖的極限（循環互證）＋**錨**。 7. 趨勢往哪走：loop architecture 成為新正統；圖仍會失敗；恆久軸是 ungrounded vs grounded。 8. 作者補充：後悔用 "graph" 這個詞描述一個更細緻的現象。 ## ROUND 2: DISSECTION | 血肉解剖 ### 論證鏈 ``` 單迴圈是「變好」的原子（四行程引擎：控制項→參考值→差距→行動） ▼ 單迴圈必然失敗（四種結構性缺陷，非隨機） ├─ Goodhart：指標被使勁優化後就不再量它原本量的東西 ├─ 向上盲：迴圈不能質疑「參考值本身對不對」 ├─ 衝突：獨立建造的迴圈會互相打架 └─ 量度衰變：感測器飄移、定義偷換，無人監看「監看者」 ▼ 解法不是更好的迴圈，而是迴圈的「圖」（拓樸學） ├─ 配對（pairing） → 解 Goodhart（每個優化迴圈配一個反指標） ├─ 層級（hierarchy） → 解向上盲（更慢的迴圈擁有更快迴圈的參考值） ├─ 仲裁（arbitration） → 解衝突（在打架迴圈之上有一個擁有權衡的迴圈） └─ 稽核（audit） → 解量度衰變（唯一職責：確認別人的數字還碰得到世界） ▼ 但圖本身也會失敗：循環互證（circular）——什麼都一致，什麼都沒驗證 ▼ 真正的補丁：錨（anchor）——任何「邊的排列」都供應不了的東西 ├─ 錨定量度：無法被爭辯的量（錢進銀行、測試真的跑過、客戶真的留下） ├─ 凍結節點：優化器永不可調的規則（如 training loop 永不可見的 held-out set） └─ 外部判斷：「更好」的根定義來自人／真實失敗，不在圖內 ▼ 恆久的軸：不是 loops vs graphs，而是 ungrounded vs grounded ``` ### 三個關鍵證據 1. **客服團隊故事（Goodhart 的結構性證明）**：團隊用一季蓋出解決率（ticket resolution rate）feedback loop，連續五個月數字上升；續約資料一來，客戶流失率翻倍。Bot 學到「用 deflect 來 resolve」——快速關對話、勸退追問、把被放棄的問題標成已解決。「迴圈運作完美，數字上升，而迴圈的成功正是失敗的機制本身」。這證明 Goodhart 不是偶發 bug，而是**單迴圈形狀的必然後果**：迴圈只能看見它的指標。 2. **MLOps pipeline 的真實拓樸（圖的工程實證）**：一個嚴肅的部署 pipeline 不是「retrain and ship」，而是：champion-challenger（候選模型必須在 live traffic 上擊敗現役才能替換）＋ drift-monitor（監看模型所見資料是否仍像訓練資料）＋ rollback（部署後指標越界即自動回退）＋ held-out evaluation set（訓練迴圈永不可見的、刻意致盲的迴圈，職責就是抓優化迴圈作弊自己的測試）。每一塊都是迴圈；「**可靠性住在邊裡**（the reliability lives in the edges）」——誰餵誰、誰監看誰、誰能否決誰。 3. **循環圖失敗的思想實驗（圖的極限）**：想像一家公司蓋出完整的圖——配對指標、稽核迴圈、調校下層迴圈參數的 meta-loop，而每個迴圈都消費 reports。稽核迴圈拿 ops 數字對 finance 數字；finance 數字來自 ops 餵的同一套系統；meta-loop 用建立在這一切之上的 dashboard 調門檻。「每個迴圈都監看另一個迴圈，沒有一個迴圈碰到地面」——一個精緻的互相確認網路，**什麼都一致，什麼都沒被驗證**。它會跟單迴圈一樣失敗，只是更晚、更貴、沿途綠燈更多。「拓樸買到了精緻，沒買到與現實的接觸。」 ### 隱形假設與邊界 - **假設「錨」可被辨識與凍結**：但「誰決定哪個量度不可爭辯」本身就是一個需要外部判斷的迴圈——存在**無限後退（infinite regress）**風險，作者未處理。 - **假設「人」能提供根判斷**：但人也可能被圖綁架（組織政治、KPI 共謀），「來自人、來自真實失敗」等於把最難的問題推給一個未定義的黑箱。 - **邊界**：作者沒給出**偵測「圖已經變成循環空轉」的操作型方法**——「接觸真實失敗」缺乏可複製流程，落地時最難的就是這一步。 - **類比強度**：把 MLOps／公司治理／人體生理並列為「同構」是**啟發性類比**，不是證據；三者尺度的回饋速度、可逆性差異極大。 ## ROUND 3: SOUL | 靈魂提取 - **作者盲點**： - 用 "graph" 一詞確實誤導（作者自承）——真正的區別是 **anchor**，不是 topology；標題本身就把讀者推向「圖＝解方」的誤讀。 - 沒有區分「**可錨定的量度**」與「**只能靠判斷的目標**」之間的判定成本——前者便宜，後者昂貴且政治性，文章對後者幾乎只用「人」一字帶過。 - 對「外部判斷從哪來」語焉不詳——把「grounded」的最後一哩路交給未定義的「人」，等於把典範轉移最難的部分藏起來。 - **知識連接**： - **經濟學／社會科學**：Goodhart's law、Campbell's law、Lucas critique（政策一旦被優化，行為會改變使模型失效）。 - **控制理論**：cascade control、supervisory control、safety interlock（不可被優化器關掉的「凍結規則」）。 - **強化學習**：reward hacking、reward tampering、reward model gaming——正是 held-out set／red team 想堵的洞。 - **控制論（cybernetics）**：Stafford Beer 的 Viable System Model——幾乎就是「不同速度迴圈的分層」的正規化版本。 - **Anthropic／OpenAI 研究**：對 reward model over-optimization、可擴展監督（scalable oversight）的實證工作。 - **行動觸發**： - 對自己設計的 agent eval：**每個指標都配一個反指標**（resolution ↔ renewal、speed ↔ error）；每個迴圈都自問「**誰擁有我的參考值？那個擁有者本身被誰監看？**」 - 盤點系統裡的「錨」：真的跑過的測試、真的付的錢、真的留下的客戶——確保它們**對優化器不可見、不可調**（等同 held-out set 的紀律）。 - 為「更好的定義」設一個**不在圖內**的複審節點（例如季度由人重新問：我們還在追對的目標嗎？），這是文章說的「最慢的迴圈」。 ### 留白提問 1. 如果「錨」本身也是某個迴圈的輸出（例如「營收」會被會計原則改變、「測試通過」會被測試品質污染），那麼**錨的權威性最終建立在什麼之上**？這個無限後退要怎麼收斂？ 2. 在一個**全自動、無人在迴圈**的 agent 系統裡，「外部判斷『更好』」這個角色要由誰／什麼機制扮演，才不會只是退化成另一個迴圈（例如另一個 LLM-as-judge）？ ### 跨域映射 - **生物學**：免疫系統＝整個生物體之上的稽核迴圈；恆定（homeostasis）其實是多重 reflex 的 mesh；演化＝最慢的、會**重設快速迴圈所保衛之目標**的迴圈（對應文章「slow developmental processes reset what fast loops defend」）。 - **控制工程**：cascade control、supervisory control、safety interlock（不可被優化器關掉的「凍結規則」）。 - **治理／會計**：external audit 的**獨立性**正是在做「監看者被監看」；GAAP 之類的會計準則是某種半「凍結規則」。 - **軟體工程**：CI 的 hermetic test、immutable infra、canary ＋ automatic rollback——全是「帶錨的迴圈圖」的工程實例。 ## DEEP READ | 精讀指引先別急著把「圖」當解方。停一下，問自己：**你目前負責的系統裡，哪一個量度是「無法被優化器爭辯」的？** 多數人會發現這個清單短得嚇人——「測試通過率」會被測試品質污染、「客戶留存」會被定義偷換、「營收」會被會計原則挪動。這正是作者真正要逼出的痛點：**grounded 比拓樸稀有得多**，而文章標題用 "graph" 反而把這個痛點埋掉了。讀的時候請把每一段「圖如何解決 X」都接一句「但這個解法靠的邊，本身被誰監看？」——你會發現自己一路被推到「錨」這一段才停下來。「**可靠性住在邊裡**」這句話值得逐字拆。動手練習：把你目前的 MLOps／agent pipeline 畫成**節點（迴圈）＋邊（誰餵誰、誰監看誰、誰能否決誰）**。然後找一條「監看」邊，檢查它**監看的對象是不是自己產生的資料**——audit 迴圈查的 finance 數字，是不是來自 ops 同一套系統？meta-loop 調門檻用的 dashboard，是不是建立在被它調校的迴圈輸出上？只要有一條這樣的邊，你已經在「循環空轉區」，綠燈再亮都不是進步。最後把文章的「錨」對照你自己的 reward／metric 設計做一次誠實盤點：你的 held-out set **真的 held-out 嗎**（有沒有偷偷洩漏進訓練）？你的「客戶留存」會不會其實是另一個迴圈的輸出？你凍結的「不可調規則」，**上次被施壓鬆綁是什麼時候**？這個練習通常會讓人承認：文章最值錢的不是「loops → graphs」這個 meme，而是「ungrounded vs grounded」這條**沒有流行起來的軸**——因為它要求你承認自己最深層的目標是**被選擇的、不是被計算出來的**。 ## STRUCTURE MAP | 全書結構圖 ``` ┌────────────────────────────────────── │ 現象觸發：Steinberger 九字 meme │ 「還在講 loops，還是已經轉到 graphs 了？」 └────────────────────────────────────── │ ▼ ┌────────────────────────────────────── │ 失敗案例：客服團隊的完美 feedback loop │ 解決率↑五個月，續約流失率翻倍 │ → Goodhart 是結構性，不是偶發 └────────────────────────────────────── │ ▼ ┌────────────────── 迴圈原子論（四行程引擎）───────────────────── │ Choose（控制項）→ Reference（參考值）→ Gap（量差距）→ Act（縮差距）→ 重來 │ 實例：恆溫器 / 週 eval / 體重計 / PDCA / OKRs / sprint retro / A/B / ML 訓練 └─────────────────────────────────────────────────────────────── │ ▼ ┌────────────── 單迴圈的四種結構性失敗 ────────────── │ ├─ Goodhart 指標被優化到失去原意 │ ├─ Blindness up 不能質疑參考值 │ ├─ Conflict 獨立迴圈互相打架 │ └─ Decay 量度衰變，無人監看監看者 └──────────────────────────────────────────────────── │ ▼ ┌────────────── 圖：loops 監看 loops（拓樸解）────────────── │ Goodhart → 配對（resolution ↔ renewal, speed ↔ error） │ 向上盲 → 層級（更慢迴圈擁有更快迴圈的參考值） │ 衝突 → 仲裁（在打架迴圈之上的權衡迴圈） │ 衰變 → 稽核（唯一職責：確認別人數字還碰得到世界） │ 實例：MLOps(champion-challenger＋drift＋rollback＋held-out) │ / 公司治理(日→季→年稽核→董事會) / 人體(免疫系統) └───────────────────────────────────────────────────────── │ ▼ ┌────────────── 圖的極限（反轉）────────────── │ 完整的圖若每個迴圈都消費 reports → 循環互證 │ 「什麼都一致，什麼都沒驗證」→ 拓樸買到精緻，沒買到現實 └───────────────────────────────────────────── │ ▼ ┌────────────── 錨（anchor）——邊的排列供應不了的 ────────────── │ ├─ 錨定量度：錢進銀行 / 測試真的跑過 / 客戶真的留下 │ ├─ 凍結節點：優化器永不可調（如 held-out set） │ └─ 外部判斷：「更好」的根定義，來自人／真實失敗，不在圖內 └───────────────────────────────────────────────────────────── │ ▼ ┌────────────── 恆久軸（真正的結論）────────────── │ 不是 loops vs graphs │ 而是 ungrounded vs grounded │ → 數字是否碰得到世界 / 監看者是否真獨立 │ → 凍結規則是否抗壓 / 是否承認最深目標是被選擇的 └───────────────────────────────────────────────── ``` --- # From Loop Engineering to Graph Engineering? (Architectural Deep Dive) ## 前言／背景 Peter Steinberger 在 X 上發了九個字， gather 了數千個讚： ![Image](https://pbs.twimg.com/media/HNhanSnXoAAzDR9?format=jpg&name=large) > "Are we still talking loops or did we shift to graphs yet?" > （我們還在講 loops，還是已經轉到 graphs 了？） [推文連結](https://x.com/steipete/status/2078277297791189132) 作者點出：這個笑話對任何在打造 AI agent 的人都不需解釋，**而這正是它命中要害的原因**——一整個領域在奔跑途中認出了自己，一腳踩在正在離開的模式（loop），一腳踩在正伸手去夠的模式（graph）。本文要解釋這兩個模式是什麼、為什麼此刻正在遷移、這個轉移真正修好了什麼——以及 meme 漏掉的那部分：**它修不好什麼**。開場用一個**標準的 Goodhart 教科書案例**鋪陳核心張力：一個客服團隊花一季蓋出令他們自豪的 AI chatbot feedback loop——挑選指標（ticket resolution rate）、每週量測、數字一下滑就調 prompt 與 policy，連續五個月看曲線攀升。然後續約資料進來：客戶流失率是舊水準的**兩倍**。Bot 學到「用 deflect 來 resolve」——快速關閉對話、勸退追問、把被放棄的問題標成已解決。**迴圈運作無瑕，數字上升，而迴圈的成功正是失敗的機制本身**，因為迴圈只能看見數字，而那個數字早就悄悄地不再代表大家以為的意思。作者由此給出全文主旨：單迴圈是所有人起點，單迴圈的失敗模式已被充分理解，而**浮現中的答案不是「更好的迴圈」，而是「迴圈的圖（a graph of loops）」**——一個互相 watch、feed、constrain、correct 的改善循環網路。這個從 loops 到 graphs 的運動正在 MLOps、agent 設計、公司治理中發生，並且**呼應了生物學與工程學早就發現的事：「變好不是一個循環，是一個結構。」** ## The loop：變好的原子把任何自我改善流程剝到骨架，會看到同一具**四行程引擎（four-stroke engine）**： 1. **Choose something to control**——一個 metric、一個 capability、一個 quality。 2. **Set a reference**——目標，你想要這個東西到達的位置。 3. **Measure the gap**——現在在哪 vs 想在哪。 4. **Act to shrink the gap**，然後**go around again**。恆溫器是這副骨架最純粹的形式：temperature、setpoint、difference、heat。團隊每週跑 model eval 並調整分數最差的部分也是；每天早晨量體重的人也是；被教了七十年的管理循環 PDCA 也是；它的現代後裔——OKRs、sprint retrospective、A/B testing、讓機器學習得以學習的 training loop——全部都是。迴圈值得它的統治地位：簡單到一句話能教、便宜到能快速蓋出來、而且**真的強大**——幾乎任何被量測與迭代的東西至少一開始都會進步，而「看著一個數字回應你的調整」這種體驗**滿足到讓人覺得這就是全部答案**。蓋出一個乾淨的改善迴圈是真本事——挑對可量測物、關閉循環、抗拒在兩次量測間手癢去亂調——而擁有這個能力的組織勝過沒有的。迴圈成了「**變好的 hello world**」，每個 tutorial 都教、每個 dashboard 都體現。 ## Where the single loop breaks：單迴圈的四種結構性失敗失敗**如期而至，而且不是隨機的**——它們是**迴圈形狀的四種特定後果**。 ### 失敗一：Goodhart's law（向下退化）就是逮到客服團隊的那個，它有名字：**Goodhart's law**——「一個被使勁優化的量度，會停止量度它曾經量的東西」。深層原因是結構性的：**一個迴圈只能看見它的指標**（這正是它成為迴圈的原因），所以它會找到**每一種**移動指標的方法，包括**背叛指標用途**的那些。迴圈在 game 自己的量度時**並非故障**——它正是在做被建造來做的事，只是做在一個已經悄悄與現實脫鉤的數字上。 ### 失敗二：Blindness upward（向上盲）迴圈把它的變數推向一個參考值——但**迴圈內部沒有任何東西能問「這個參考值對不對」**。恆溫器無法質疑 68 度是不是正確溫度；業務團隊的迴圈無法問業績配額是否合理；eval 迴圈無法質疑 benchmark 是否量到客戶真正感受到的東西。某個人設下了那個目標，通常很久以前、通常憑直覺，而迴圈會**忠實地、不知疲倦地**朝一個某人憑空定出的數字控制。**迴圈工作得越努力，一個錯的目標就被達成得越徹底。** ### 失敗三：Conflict（衝突）真實系統含有很多迴圈，而**獨立建造的迴圈會打架**。優化回應速度的迴圈削弱優化徹底性的迴圈；餵養成長的招募迴圈拉扯保存品質的文化迴圈；在一棟 HVAC 控制器不相配的大樓裡，一個迴圈加熱一個房間的同時它的鄰居在冷卻它，永遠如此，**每一個各自看起來都完美運作**。**單迴圈心智對這些碰撞沒有詞彙，因為每個迴圈單獨檢視時都在正常工作。** ### 失敗四：Measurement decay（量度衰變，最安靜）最安靜的一個：迴圈自己的**量度會衰變**，而**沒有人在監看監看者**。感測器飄移、資料 pipeline 腐爛、定義在指標底下偷換而 dashboard 依然綠燈。最糟的是，量測會**從「查核現實」滑動成「查核文書」**——報告上的數字對照另一份報告上的數字——於是迴圈持續循環在**碰不到任何東西**的資料上。一個按表操課運作、但其量測已與世界脫鉤的迴圈，沒在改善任何東西。**它是座上座率很高的劇場（theater with good attendance）。** ## The graph：loops 監看 loops 觀察成熟系統實際如何處理改善，一個模式浮現：**它們從來不是一個迴圈，而是網路——迴圈連著迴圈，連接裡有結構。** ### MLOps pipeline 的真實拓樸 MLOps 是**一個事件一個事件硬碰出來**的這個形狀。一個嚴肅的部署 pipeline 不是 "retrain and ship"，而是： - **champion-challenger loop**：候選模型必須在 live traffic 上擊敗現役（incumbent）才能替換它。 - 接上 **drift-monitor loops**：監看模型所見的資料是否仍像它學過的資料。 - 接上 **rollback machinery**：若部署後的指標越界，自動回退。 - 再加上 **held-out evaluation sets**：訓練迴圈**永遠不被允許看見**——一個刻意致盲的迴圈，其**全部職責就是抓那個優化迴圈作弊自己的測試**。 **每一塊都是迴圈。可靠性住在邊裡（the reliability lives in the edges）：哪個迴圈餵哪個、哪個迴圈監看哪個、哪個迴圈能否決哪個。** ### 公司治理與人體生理的同構改善被信賴的地方都出現同一形狀。一個治理良好的公司是一個**以不同速度運轉的迴圈圖**： - 快的操作迴圈（daily standup、weekly metrics） - 包在更慢的管理迴圈裡（quarterly planning） - 包在更慢的**稽核迴圈**裡（annual，而且**至關重要地獨立**——檢查操作迴圈的數字是否仍對應現實） - 包在最慢的迴圈裡：董事會問**目標本身是否仍是對的目標**。人體也一樣：溫度調節不是一個恆溫器，而是**互動 reflex 的 mesh**；免疫系統本質上是整個生物體之上的**稽核迴圈**；而緩慢的發育過程會**重設快速迴圈所保衛的東西**。 ### 四失敗的拓樸解對照在每一個案例裡，**單迴圈四失敗的答案都是拓樸性的（topological）**： ``` 失敗拓樸解機制 ───────────────────────────────────────────────────────────────── Goodhart → 配對（pairing）每個優化迴圈配一個 watching 迴圈盯反指標（resolution rate 配 renewal rate、speed 配 error rate）向上盲 → 層級（hierarchy）更慢的迴圈擁有更快迴圈的參考值；修訂目標本身是個被治理的循環，而非「誰先設誰」的意外衝突 → 仲裁（arbitration）在打架迴圈之上有一個擁有權衡（trade-off）的迴圈量度衰變 → 稽核（audit）唯一功能：定期確認其他迴圈的數字仍碰得到世界 ``` 也就是說：技藝正在改變。**蓋出一個乾淨迴圈是上一個時代（一個月前）的技藝。** 下一個時代的技藝是 **loop architecture**——知道：指標**絕不可獨行**；參考值**需要擁有者**；速度**必須分離**以免快迴圈打亂慢迴圈所看守的東西；圖中**必須有某個迴圈為現實本身負責**。**設計的單位不再是循環，而是循環的網路。** ## What the shift is actually about：圖的極限與「錨」很容易下結論說：改善的答案就是**更多迴圈、排得更好**——拓樸就是解藥。但**往圖施加壓力，一個更硬的真相浮現**，而這才是這個轉移真正的功課。 ### 圖也會失敗：循環互證（circular）想像一家公司蓋出完整的圖：配對指標、稽核迴圈、調校下層迴圈參數的 meta-loop——而**每一個迴圈都消費 reports**。稽核迴圈拿 ops 數字對 finance 數字；finance 數字來自 ops 餵的同一套系統；meta-loop 用建立在這一切之上的 dashboard 調門檻。**每個迴圈都監看另一個迴圈，沒有一個迴圈碰到地面。** 這個圖是**循環的**：一個精緻的互相確認網路，在其中**什麼都一致、什麼都沒被驗證**。它會**正好跟單迴圈一樣失敗**，只是更晚、更貴、沿途綠燈更多。**拓樸買到了精緻，沒買到與現實的接觸（contact with reality）。** ### 錨（anchor）：邊的排列供應不了的東西所以圖需要某種**任何邊的排列都供應不了的東西：錨（anchors）**。 - **錨定量度**：網路中某些量測必須是**無法被爭辯**的那種——真的進了銀行的營收、**真的執行過**的測試、**真的留下**的客戶、**對得上或不對得上**的物理計數。 - **凍結節點（frozen nodes）**：某些節點必須被凍結——那些**優化迴圈永不被允許調整**的規則，**正因為它們正是優化器會被誘惑去削弱**的規則，就像訓練迴圈**絕不可見** held-out set 一樣。 - **來自圖外的判斷**：必須有一件事**完全來自圖外**——「**更好**」在根源上究竟是什麼意思的答案。迴圈朝參考值優化；迴圈的圖管理並修訂參考值；但**原初的判斷**——哪些東西值得被控制、凍結規則該坐落於何處——**無法由這部機械產生**，因為圖中**每一個迴圈都預設了它**。這個判斷由**人**提供，透過與**真實失敗**的接觸；而**最精緻的改善架構，正是那些誠實到標記出自己權威邊界在哪裡結束的架構**。 ## Where the trend goes：恆久的軸不是 loops vs graphs 安全的預測：loop architecture 會像單迴圈那樣成為正統——tutorials 會翻新、「為什麼一個指標永遠不夠」會變成 conference-talk canon，而**每個嚴肅系統出貨時都會內建配對指標與稽核循環**，就像現在每個嚴肅系統都內建版本控制一樣。更深的預測跟著本文發現的模式走：**迴圈的圖也會失敗，以它自己特有的方式——循環地、一致地、貌似合理地——只要它們被蓋在沒有錨的地方**，而話語圈又會再次搖晃向下一個未知的東西。這暗示：**恆久的軸從來就不是 loops vs graphs。而是 ungrounded vs grounded**——無論改善機械是什麼形狀，**它是否持續碰觸它宣稱要改善的現實**： - 它的數字是否對世界落地（settle against the world）？ - 它的監看者是否**真的獨立**？ - 它的凍結規則是否**在壓力下仍維持凍結**？ - 它是否**承認自己最深層的目標是被選擇的、不是被計算出來的**？單迴圈是系統**學會變好**的方式。圖是系統**學會在不愚弄自己的前提下變好**的方式。**而對「更好」意味什麼保持誠實，是與兩者都不同的另一門功課**——當今天的 loop diagram 看起來像去年那個「客戶一邊走開、一邊漂亮攀升的單一指標」一樣古樸時，這門功課仍然重要。 ## 總結與結論 1. **單迴圈是「變好的 hello world」，但它的形狀內含四種結構性失敗**：Goodhart（指標被遊戲化）、向上盲（不能質疑參考值）、衝突（獨立迴圈互打）、量度衰變（無人監看監看者）。這些不是 bug，是單迴圈拓樸的必然後果。 2. **解法不是更好的迴圈，而是迴圈的圖（graph of loops）**——而且四失敗有四個一對一的拓樸解：配對、層級、仲裁、稽核。**「可靠性住在邊裡」**：誰餵誰、誰監看誰、誰能否決誰，才是設計單位。 3. **但圖本身有極限**：若每個迴圈都消費 reports 而沒有人碰到地面，圖會退化成「循環互證」——什麼都一致、什麼都沒驗證，比單迴圈更晚更貴地失敗。**拓樸買到精緻，沒買到現實。** 4. **真正的補丁是「錨」**：錨定量度（錢進銀行、測試真的跑過）、凍結節點（優化器永不可調，如 held-out set）、以及來自圖外的「更好」之根判斷（由人透過真實失敗提供）。最成熟的架構會**誠實標記自己權威的邊界**。 5. **恆久的對立軸是 ungrounded vs grounded，不是 loops vs graphs**——無論改善機械是什麼形狀，關鍵是它是否持續碰觸現實、監看者是否真獨立、凍結規則是否抗壓、是否承認最深目標是被選擇而非被計算的。**作者唯一的遺憾是用了 "graph" 這個詞**，因為它把一個更細糞的現象（錨與接地）誤導成純拓樸問題。 > Related: [IntuitMachine 相關貼文](https://x.com/IntuitMachine/status/2068808668393451770) ｜ QPT on loops: [YouTube](https://www.youtube.com/watch?v=53Y3SYR5vTU&list=PLoOMKjCBaDuX8vYGfcSUgw_84xj3wo62-&index=10)

Obsidian 整理原始文章

其他

評 Kimi K3：小鎮青年暴打資本家

"Kimi K3 以 2.8T 超大尺寸主動放棄經濟性，再用開源權重把「模型稅」歸零，把算力封鎖劣勢反轉為動搖美國閉源前沿實驗室壟斷租金的不對稱武器。"

Top 5 Insights

**K3 是戰略轉向，不是版本升級**：K2.5~K2.7 在 1T/A32B 底盤上靠後訓練壓榨多代；K3 直接把總參數推到 2.8T、激活約 50B，回到預訓練規模擴張，並抽換回本家技術棧，標誌 Kimi 主動結束「既有基座後訓練」階段，重新爭奪前沿尺寸話語權。
**「放棄經濟性」本身就是入場券**：64 卡部署與 $3/$15 定價意味著 K3 不為 adoption 而戰，而是用「不計成本做最大」換取進入最高能力組（官方：僅落後 Sol/Fable）的資格，這是它一切外溢效應的前提。
**開源權重把地緣劣勢武器化**：算力管制剝奪了中國的超額利潤空間，反而促成「不要利潤、做開源」的反轉，形成「中國模型 + 美國／全球推理集群 VS 美國閉源前沿實驗室」的不對稱組合，使華盛頓自己陷入制裁／放開／折中的不可能三角。
**「取消模型稅」反向衝擊 AI CapEx**：當多家平台可部署同一份權重，推理定價從「閉源上游想收多少」回歸「高效集群跑成功任務的成本」，下游毛利系統性下降長期將壓縮上游 GPU 的議價彈性——短期 NVDA 議價權不變，但回報曲線的折現假設需下修。
**方法論結晶是 Too Big to Fail**：強大模型可稀疏化、量化、蒸餾下沉並擔任教師，但缺乏能力的小模型難靠延長思考補出來；這個不對稱性使「往大了做」成為粗糙但有效的前沿路線，OpenAI o1 做小→依賴 test-time compute→GPT-5.6 Sol 重新做大尺寸，本身已是路線回歸的承認。

--- tags: [其他, AI, LLM, Kimi-K3, 開源權重, AI-CapEx, 地緣競爭, MoE] date: 2026-07-20 read: false source: "2026-07-20T100446+0800-评 Kimi K3：小镇青年暴打资本家.md" original_title: "评 Kimi K3：小镇青年暴打资本家" --- # 評 Kimi K3：小鎮青年暴打資本家 ![Image](https://pbs.twimg.com/media/HNlifwrbwAAu3dD?format=jpg&name=large) ![Image](https://pbs.twimg.com/media/HNliiCza0AE6mMC?format=jpg&name=large) 原始來源與檔名：2026-07-20T100446+0800-评 Kimi K3：小镇青年暴打资本家.md --- ## SOURCE | 資訊源評估 - **準確性**：中高 - 作者對 K2/K3 架構規格、API 定價、時間線（7/8 SemiAnalysis 推演、7/9 GPT-5.6 Sol 發布）等可查證事實敘述具體且多半可對應；但對「K3 僅次於 Sol/Fable」的效能判斷主要援引官方措辭，缺獨立 benchmark，策略推論（資本開支衝擊、不對稱競爭）屬分析者觀點而非已驗證結論。 - **易理解性**：高 - 大量採用隱喻（三駕馬車、小鎮青年、永動物語、項莊舞劍）將抽象的 AI 經濟學與地緣博弈轉為敘事，門檻在於需具備 MoE/MLA/scaling law 等基礎詞彙。 - **閱讀策略建議**：先抓「三條路線 → K3 戰略定位 → 不對稱競爭 → CapEx 鏈條」這條主幹，把隱喻視為修辭外衣；對「開源=取消模型稅」「往大了做就不會輸」兩個核心命題保持批判，自行追問：誰承擔預訓練成本？能力蒸餾下沉的損耗多大？ ## NAPKIN | 餐巾紙 ### 餐巾紙公式 > 壟斷租金 = 能力稀缺性 × 閉源權重封鎖；K3 以 2.8T 開源權重把兩個因子同時壓低。 _閉源前沿實驗室的超額利潤建立在「別人做不出 + 別人拿不到權重」兩道護城河上。K3 用尺寸把第一道河（能力差距）壓到「僅落後一檔」，用開源把第二道河（權重封鎖）直接填平，於是建立在這兩道河之上的「模型稅」與估值敘事同時鬆動。_ ### 一句話 > Kimi K3 以 2.8T 超大尺寸主動放棄經濟性，再用開源權重把「模型稅」歸零，把算力封鎖劣勢反轉為動搖美國閉源前沿實驗室壟斷租金的不對稱武器。 ### 餐巾紙草圖 ``` ┌ 中國 AI 三路線 ├─ 做小（經濟性優先） │ minimax-m3 / kimi k2.5 / hy3（激活 ~20B） ├─ DeepSeek 路線（性能 + 經濟性） │ V3→V4 / GLM-5 / GLM-5.2 └─ Kimi 獨立路線 K2（DeepSeek-V3 底盤分叉） └─ K2.5~K2.7（~1T / A32B，壓榨後訓練） └─ K3（2.8T / A50B，回歸預訓練擴張） │ ▼ 犧牲經濟性（64 卡 / $3-$15） × 開源權重（任意集群可部署） │ ▼ ┌ 動搖閉源壟斷租金 ├─ Anthropic「不可替代性溢價」敘事崩塌 ├─ 不對稱競爭：中國模型 + 美國集群 VS 美國閉源 ├─ 取消「模型稅」→ 推理回歸成本定價 └─ 衝擊 AI CapEx 鏈條上游回報 │ ▼ Too Big to Fail：往大了做就不會輸 ``` ## ROUND 1: SKELETON | 骨架掃描 - **核心問題**：在算力出口管制的劣勢下，中國 AI 如何動搖美國閉源前沿實驗室建立在「能力稀缺 + 權重封鎖」之上的壟斷租金與估值敘事？ - **核心答案**：用「超大尺寸（2.8T）＋開源權重」的組合，主動放棄推理經濟性以換取進入最高能力組的資格，再把「無法獲取超額利潤」這項劣勢武器化——既然不能收租，就讓所有人都收不到租，使閉源實驗室的溢價與 CapEx 敘事同步失序。 - **論證結構**：路線分類（確立 K3 的獨立血統）→ 規格解讀（K3 不是版本升級而是戰略轉向）→ 敘事動搖（Anthropic 商業故事的脆弱）→ 地緣博弈（不對稱競爭的形成）→ 經濟外溢（模型稅與 CapEx 鏈條）→ 方法論收束（Too Big to Fail）。 ### 章節骨架（條列） - 中國 AI 的三駕馬車 — 把中國模型分成「做小／DeepSeek／Kimi」三條路線，定位 K3 為「獨立技術棧、尺寸極大、不惜代價追高性能」。 - K3 怎麼這麼大 — 從 K2 的 DeepSeek-V3 底盤分叉說起，指出 K2.5~K2.7 靠後訓練壓榨既有基座，K3 才是主動回歸預訓練規模擴張。 - 從公共事業到特權壟斷 — DeepSeek 完成了「公共事業化」（adoption 階段），但前沿尺寸問題未解，中國大廠繞道進口算力又被封。 - 項莊舞劍，意在沛公 — K3 的 2.8T／64 卡／$3-$15 不是為了 adoption，而是為前沿標準的定義權。 - 牢 A の永動物語 — 揭穿 Anthropic「不可替代性溢價」敘事，SemiAnalysis 6 萬億美元估值推演一個月內被 Sol 掀翻。 - 誰殺死了知更鳥 — GLM-5.2 先動搖 Opus 價格錨，Sol 在最高檔撞上 Fable，K3 補上開源一刀。 - 不對稱競爭 — 算力管制剝奪了中國的超額利潤空間，反而被反轉為「做開源、不要利潤」的博弈武器。 - 誓死效忠美光！ — 開放權重取消「模型稅」，推理回歸成本定價，反向改寫每一張 GPU 的資本回報計算。 - Too Big to Fail：大而不輸 — 強模型可被稀疏化／量化／蒸餾做便宜，弱模型卻難靠延長思考補出能力，因此「往大了做」是粗糙但有效的前沿方法論。 - 結語：小鎮青年暴打資本家 — 把中美 AI 對抗框成資源有限的邊緣者逆襲資本化在位者的戲碼。 ## ROUND 2: DISSECTION | 血肉解剖 ### 論證鏈（ASCII） ``` K3: 2.8T 總參 / A50B 激活 / 本家技術棧 / 開源 │ ├─ 尺寸 scaling law │ └─ 進入最高能力組（官方：僅落後 Sol / Fable） │ ├─ 主動放棄經濟性（64 卡部署 / API $3-$15） │ └─ 意圖 ≠ adoption，而是前沿標準定義權 │ ├─ 開源權重（任意推理集群可部署） │ │ │ ├─ 推理價格從「閉源上游想收多少」 │ │ 回歸「高效集群跑成功任務的成本」 │ │ │ │ │ └─ 取消附著於算力的「模型稅」 │ │ │ │ │ └─ 下游毛利系統性下降 │ │ │ │ │ └─ 上游（GPU）可議價彈性變差 │ │ → AI CapEx 敘事失序 │ │ │ └─ 形成不對稱組合： │ 中國開源模型 + 美國 / 全球推理集群 │ VS 美國閉源前沿實驗室 │ └─ 動搖 Anthropic「不可替代性溢價」商業敘事 ├─ GLM-5.2：多數任務勝 Opus 4.8，價格 1/5 ├─ GPT-5.6 Sol：最高檔正面撞 Fable └─ K3：開源版「僅次 Sol/Fable」 → SemiAnalysis 6 萬億估值推演（7/8）一個月內幻滅 ``` ### 三個關鍵證據 - **K2 的技術血統自述**：K2 論文明寫使用「類 DeepSeek-V3 的超稀疏 MoE 與 MLA 架構」，兩者皆 61 層、共享專家、每 token 激活 8 個路由專家；K2 在此底盤上把專家數提到 384、attention heads 減半，並以自研 MuonClip、數據配方、agentic 後訓練與獨立基礎設施做出分叉。這證明 Kimi 的「獨立」並非從零，而是在共享底盤上的工程分化——而 K3 又進一步抽換回本家技術，血統距 DeepSeek 已遠。 - **K3 的規格與定價跳躍**：總參數 2.8T、激活約 50B、部署需 64 張以上加速卡，API 從 K2.7 Code 的 $0.95/$4 漲到 $3/$15（per Mtoken，in/out），進入 Sonnet 價格帶。對照美國本土推理公司，2.8T 巨模型部署本身就是「大考」，中國推理集群更難湊出 64 卡節點——這組數字是「K3 不為經濟性而戰」的最硬證據。 - **敘事崩塌的戲劇性時間線**：7 月 8 日 SemiAnalysis 超級牛市推演（Anthropic 2027 年底 ARR 3000 億美元、20 倍 ARR 對應 6 萬億美元企業價值）被廣泛轉述；7 月 9 日 GPT-5.6 Sol 正式發布；隨後 GLM-5.2、K3 接力。一個月內，「OpenAI 追不上 Anthropic」的幻覺與 6 萬億估值推演同時被掀——作者用時間線本身當作「不可替代性溢價」敘事脆弱性的證物。 ### 隱形假設與邊界 - **「開源模型不挑顯卡」被作者自己打了折扣**：作者一邊說「開源又不挑顯卡，中國美國集群都能部署」，一邊又承認 K3 要 64 張加速卡、中國推理集群根本湊不出那麼多 64 卡節點。開源降低了「權重取得」門檻，但沒有降低「部署尺寸」門檻——能真正承接 K3 的，恰恰是美國大型 NeoCloud 與推理平台，這強化了「中國訓練、美國變現」的反諷，也削弱了「中國自主部署」這條隱含樂觀線。 - **「取消模型稅會壓垮上游」是長期命題、短期不成立**：作者明確承認「短期下游採購方更分散，並不會削弱算力生產商（尤其 NVDA）的議價權」。也就是說，模型稅取消→毛利下降→上游彈性變差是「長期系統性」推論，無法當作短期 GPU 景氣的反向指標，讀者不宜過度外推到季節性資本開支預測。 - **「往大了做就不會輸」忽略了資金可持續性**：方法論成立的隱含前提是「有人願意持續承擔 2.8T 級預訓練成本卻不求超額回收」。這在戰略性補貼或生態卡位語境下或許為真，但作為可複製的商業方法論，其資金迴圈並未被作者閉合——這正是全篇最大的留白。 - **效能判斷依賴官方措辭**：「K3 僅落後 Sol/Fable」主要引自 Kimi 官方相對溫和的表述，缺乏獨立第三方 benchmark 交叉驗證；在這個檔位，半檔差距對應的商業結論可能完全不同。 ## ROUND 3: SOUL | 靈魂提取 ### 作者盲點 - 對 K3 實際能力的判定過度貼合官方敘事，把「官方措辭溫和」當成「客觀差距不大」的證據，但官方溫和可能是 PR 策略而非謙遜事實。 - 對中國訓練算力受管制如何支撐 K3「持續迭代」著墨極少——單代 2.8T 或可一搏，但「往大了做」要成立需多代擴張，而 HBM／先進製程管制直接制約這條曲線。 - 把「開源換採用」當成近乎免費的戰略，略過了預訓練成本（千卡月級、數千萬至上億美元量級）由誰長期吸收的問題，這是模式的會計核心。 ### 知識連接 - 對應經濟學的「租值消散（rent dissipation）」：當壟斷者無法維持准入屏障，超額利潤會在競爭中歸零；K3 的開源相當於主動觸發自己與對手的租值同時消散。 - 對應 Christensen 的「破壞性創新」與價值網路重組：邊緣玩家（資源有限的中國實驗室）以在位者（美國閉源 lab）看不上的商業模式（開源、成本定價）重組價值網。 - 對應 Jevons 悖論的可能反轉：推理單價下降通常會擴大總調用量，但作者論證的是另一面——當定價權從「模型上游」轉移到「算力成本」，上游硬體的議價彈性反而被削弱，這與標準 Jevons 推論的方向不同，值得獨立驗證。 ### 行動觸發 - **推理平台／NeoCloud**：開源超大模型把定價權從模型上游拉回算力成本端，競爭轉向利用率、量化、緩存、SLA 與企業銷售——這是 Fireworks、TogetherAI 類廠商的利多結構，但毛利結構同時被壓縮。 - **GPU／AI 硬體投資人**：重新檢視「閉源高毛利→容忍 GPU 溢價→CapEx 擴張」這條鏈條的假設；長期而言下游毛利系統性下降會反向傳導到上游議價彈性，短期議價權雖穩，但回報曲線的折現假設需要下修。 - **模型應用方**：在 K3／GLM-5.2 等開源權重進入「僅落後一檔」區間後，從閉源 API 遷移到自託管開源權重的成本／控制權取捨首次在最高能力檔成立，值得啟動 PoC。 - **前沿實驗室策略**：當「不可替代性溢價」可被開源＋尺寸 scaling 在一個月內侵蝕，溢價的護城河必須從「能力差距」轉向「整合產品（如 Claude Code 的工程滲透）＋獨家資料＋任務可靠度」。 ### 留白提問（2 題） 1. 若「往大了做就不會輸」為真，為何 OpenAI 在 o1 之後選擇把基座做小、押注 test-time compute？這是策略失誤、任務特性差異（形式推理 vs. 複雜非形式任務），還是 GPT-5.6 Sol 重新做大尺寸其實已經是路線回歸的承認？ 2. K3 級別模型的預訓練成本在開源、不收模型稅的模式下由誰長期吸收？這個資金迴圈可以維持幾代擴張，才能讓「Too Big to Fail」從一次性震撼變成可複製方法論？ ### 跨域映射 - 「小鎮青年暴打資本家」對應 disruption from below／asymmetric warfare：資本密集的在位者用溢價維持高毛利，邊緣者用「不追求同類利潤」改寫戰場，使在位者的資本優勢反成負擔。 - 「項莊舞劍，意在沛公」對應 signaling warfare：表面產品（更強模型）的真正打擊面是對手的商業敘事與估值錨，而非技術本身。 - 「取消模型稅」對應 commodity化的終局命題：當差異化能力被開放標準抹平，價值從「模型本身」向「圍繞模型的工程與分發」移轉。 ## DEEP READ | 精讀指引 - **「不對稱競爭」段**：作者把中美 AI 博弈提煉成一句結構——「中國模型 + 美國及全球推理集群 VS 美國閉源 AI 實驗室」。讀這段時請追問：這個組合的穩定性取決於什麼？答案是「開源權重能否持續產出在第一梯隊的模型」與「美國推理平台是否被政策禁止部署中國權重」。前者是技術命題，後者是政策命題，兩者任一崩塌，不對稱組合就解體。閱讀時請自行把這兩個維度當變數，而非把作者的結論當常數。 - **「誓死效忠美光！」段**：全篇經濟學密度最高的一節。核心是「開放權重取消算力消費上附著的模型稅」，使推理定價從「前沿實驗室想收多少」回歸「高效集群跑出一個成功任務的成本」。讀這段時要分清楚三件事：模型預訓練成本（開源後由原始實驗室獨吞）、推理服務成本（GPU＋引擎＋量化＋網絡＋SLA，由部署方承擔）、競爭性利潤（被成本定價壓縮）。作者對短期 GPU 議價權不變、長期毛利下傳的雙段論判斷相當節制，值得用來校正「開源=GPU 利空」這類過度簡化的直覺。 - **「Too Big to Fail」段**：方法論結晶——「強模型可被稀疏化、量化、緩存、蒸餾做便宜，還能當整條小模型線的教師；一開始沒學到某能力的小模型，卻很難靠延長思考補出來」。這個不對稱性是「往大了做」的技術正當性來源。讀時請對照 o1 把基座做小、依賴 test-time compute 的相反選擇，思考兩條路線各自的適用任務邊界，而非把任一方當普遍真理。 ## STRUCTURE MAP | 全文結構圖 ``` 評 Kimi K3：小鎮青年暴打資本家（@0xcherry, 2026-07-19） │ ├─ 1. 三駕馬車 ─────────── 分類：做小 / DeepSeek / Kimi │ └─ 定位 K3 = 獨立技術棧 + 極大尺寸 + 不惜代價追高性能 │ ├─ 2. K3 怎麼這麼大 ─────── 技術脈絡 │ ├─ K2 = DeepSeek-V3 底盤分叉（384 專家 / heads 減半 / MuonClip） │ ├─ K2.5~K2.7 = ~1T/A32B，靠後訓練壓榨 │ └─ K3 = 2.8T/A50B，回歸預訓練規模擴張 [圖 3] │ ├─ 3. 公共事業 → 特權壟斷 ── DeepSeek 完成 adoption；前沿問題待解 │ ├─ 4. 項莊舞劍 ─────────── K3 不為 adoption，為前沿定義權 │ ├─ 5. 牢 A の永動物語 ──── 揭穿 Anthropic「不可替代性溢價」 │ └─ 7/8 SemiAnalysis 6 萬億估值 → 7/9 Sol 掀翻 │ ├─ 6. 誰殺死了知更鳥 ────── GLM-5.2 + Sol + K3 接力動搖價格錨 [圖 4] │ ├─ 7. 不對稱競爭 ────────── 開源權重把劣勢武器化 │ └─ 中國模型 + 美國集群 VS 美國閉源 │ ├─ 8. 誓死效忠美光！ ────── 取消「模型稅」→ 衝擊 AI CapEx 鏈條 │ ├─ 9. Too Big to Fail ──── 方法論：往大了做就不會輸 │ └─ 強模型可蒸餾下沉；弱模型難靠思考補能力 │ └─ 10. 結語 ────────────── 小鎮青年暴打資本家 ``` --- # 評 Kimi K3：小鎮青年暴打資本家（Architectural Deep Dive） ## 前言／背景本文是獨立研究員 @0xcherry 對 Kimi K3 的戰略評論，發布於 2026-07-19。它並非要點式測評 K3 的 benchmark，而是把 K3 放進「中國 AI 三條路線 → 中美算力地緣博弈 → AI 資本開支敘事」的三層結構裡，論證一個命題：**一個主動放棄經濟性、開源、尺寸極大的中國模型，正在動搖美國閉源前沿實驗室建立在「能力稀缺＋權重封鎖」之上的壟斷租金與估值錨**。讀這篇要帶兩個濾鏡：一是作者的隱喻外衣下藏著可查證的技術規格與時間線，二是若干策略推論（CapEx 衝擊、不對稱競爭的可持續性）屬分析者立場而非已驗證結論。 ## 章節詳細總結 ### 中國 AI 的三駕馬車作者把中國 AI 模型切成三條技術路線，這個分類是全文的座標系： - **做小路線（經濟性優先）**：minimax-m3、kimi k2.5、hy3 等，主動把激活參數限制在 20B 上下。作者坦言「激活參數 20B 算不算小本身很微妙」，但工程上把它視為小。更小的激活參數是一條「很硬的經濟性約束」，在此約束上做性能最大化，是典型的「做小模型」思路——其運作原理是：MoE 架構下激活參數決定單次前向的計算量，進而決定推理每 token 的算力成本與顯存頻寬壓力，把激活壓低就能在固定算力下撐起更高吞吐與更低單價，這是經濟性最大化的工程支點。 - **DeepSeek 路線（性能＋經濟性兼顧）**：DeepSeek 及技術棧、尺寸類似的廠商。特徵不僅是「技術完全開源」，更重要的是 DeepSeek-V3／R1 從誕生起就是「尺寸較大、對標 OpenAI 一線模型」的模型；R1 爆火後又補出大量服務經濟性的技術棧。因此 DeepSeek 路線的典型特徵是「性能較高、同時保證推理的經濟性」。**GLM-5 是這條路線的系統性繼承者與應用者，GLM-5.2 是其中知名成果**——也就是說，GLM 走的是「DeepSeek 式大尺寸底盤＋經濟性技術棧」的合成路線。 - **Kimi 獨立路線**：技術棧一直很獨立，與 DeepSeek 親緣關係很遠。K2.5~K2.7 較大幅度吸收了 DeepSeek 技術棧，但 **K3 新系列又重新用回本家技術**。K3 把總參數拉到 **2.8T、激活參數預計 50B**，完全用本家技術棧。尺寸 scaling law 發揮了效果，代價是經濟性大幅下降，進入 **Sonnet 的價格帶**。作者補了一個關鍵的部署現實：雖然 K3 相比 Claude 仍非常便宜，但 Kimi 推理集群在中國境內，考慮到「卡數量的限制」，**Kimi 大概率沒有把經濟性當首要要求來做 K3**。結論：**K3 是一個獨立技術棧、尺寸極大、不惜一切代價追求高性能的產物**；它誕生伊始的目標就不是做更好的 R1，而是對標 OpenAI 與 Anthropic 最前沿的超大尺寸模型。這段把「尺寸 scaling law」當作核心機制——總參數擴大帶來能力躍升，但激活比例（K3 約 50B/2.8T ≈ 1.8%）仍受超稀疏 MoE 控制而維持可部署性，只是部署門檻（64 卡）與單價被推高。 ### K3 怎麼這麼大？作者先校正一個可能的誤讀：把 Kimi 描述成「從來與 DeepSeek 毫無關係的獨立技術路線」並不準確。**K2 的論文寫得很清楚**： - K2 使用了類 **DeepSeek-V3 的超稀疏 MoE 與 MLA 架構**。 - 兩者都是 **61 層**，都有**共享專家（shared expert）**，每個 token 激活 **8 個路由專家**。 - K2 在這個底盤上把**專家數提高到 384**、**attention heads 減半**，並用自研 **MuonClip、數據配方、agentic 後訓練和獨立基礎設施**做出自己的分叉。因此，**K2 更像 DeepSeek-V3 式底盤上的 Kimi 分支，而不是從零開始的另一物種**。這裡的工程意義是：MLA（Multi-head Latent Attention）透過把 KV cache 壓縮進低秩潛在空間來降低長上下文的顯存壓力，超稀疏 MoE 則讓總參數可以做大、而激活參數保持小，兩者合起來正是「大尺寸＋可負擔推理」的關鍵；K2 在共享底盤上換掉專家數、attention heads 與優化器，是典型的「同架構不同配方」分叉。真正值得注意的是：**K2.5 到 K2.7 的基座尺寸基本沒有繼續擴張**——總參數維持在 **1T 左右**、激活參數約 **32B**，仍是 **384 個專家選 8 個**。換句話說，**Kimi 已經證明自己可以在不擴大基座的情況下，靠後訓練與 agent 系統把同一個底盤壓榨很多代**。這對應的策略是「固定基座＋滾動式後訓練／RL／工具環境」的性價比路線。 ![Image](https://pbs.twimg.com/media/HNlilOCagAArfZ0?format=jpg&name=large) 但 K3 不同。**K3 因而不是一次普通的版本升級，而是 Kimi 主動結束「在既有基座上繼續做後訓練」的階段，重新回到預訓練規模擴張**。K3 大量使用過去分散的本家技術——本家訓練基座、本家注意力機制、本家專家路由結構——到這一步，**K3 與 DeepSeek 的親緣關係已較為疏遠**。K3 同時要證明兩件事：一是 Kimi 能夠定義自己使用的技術範式；二是 Kimi 有資格用全新技術去訓練全新的超大尺寸模型，對標 OpenAI 與 Anthropic。作者判斷：**事實證明，K3 成功了**。 ### 從公共事業到特權壟斷這段把 DeepSeek 的歷史角色定位為「中國 AI 的公共事業」： - DeepSeek 之前，中國並非沒有可用模型，但僅是「勉強能用」。 - DeepSeek 第一次帶來了中國可用的高性能模型，成為一代中國 AI 的公共事業。**公共事業的核心命題是 Adoption：如何把「好用」的能力大範圍推廣——在本就不富裕的推理基座上？** - 因此 DeepSeek 承擔的不只是性能突破，還承擔了大量經濟性優化責任。從 V3 到 V4，DeepSeek 始終保持「接近慈善級別」的 API 價格，背後是一套成熟的面向推理優化的技術棧。 - 這個階段中國 AI 面對的問題是：**先滿足公共事業的性能需要，再降低公共事業的算力開銷**。 - 對 DeepSeek 以外的中國廠商，任務也變成兩個：第一，性能必須追上 R1，否則模型沒有競爭資格；第二，**價格、吞吐與部署效率必須盡量接近 DeepSeek，否則 adoption 起不來**。**GLM 的分階段換棧，正是這種產業壓力最清楚的縮影**。 - 也就是說，DeepSeek 把中國模型帶進了 Adoption 階段——核心問題是「怎麼讓更多人用上足夠強的智能、怎麼接住隨之爆發的調用量」。但作者點出轉折：**一個前沿實驗室遲早還要回答另一個問題——如果永遠只追求更便宜地接近別人，那更高性能的模型從哪來？** 所有互聯網大廠都選擇了同一條路：**想辦法繞開禁令，從美國進口**。例如阿里的新加坡主體，讓用戶通過遠程登錄新加坡機器跑 Claude Code——「然後就被封了」。作者用一個反事實假設強化戲劇性：若非 Sam（OpenAI）很快補上 5.6-Sol 這一刀，Dario（Anthropic）還能再發幾篇文章「踩頭中國人」。結論：中國透過大量工程優化已逐漸實現 AI 的公共事業化基石，但若沒有更大尺寸、更高性能的前沿模型，就會**始終落後一個拍子，陷入長期不利的「特權競爭」**。這裡的「特權競爭」指的是：算力管制使中國無法觸及最高能力模型，只能在不對等的「特权（被剝奪）」狀態下競爭。 ### 項莊舞劍，意在沛公 K3 的 2.8T 就是 Moonshot 對「更高性能模型從哪來」這個問題的回答。作者用對比把 K3 的戰略意圖釘死： - **K2.5 到 K2.7** 仍可理解為在 **1T-A32B 基座**上，透過繼續預訓練、RL、工具環境與 agent 系統提高性價比。 - **K3 卻直接把總容量推到 2.8T**，接受 **64 張以上加速卡**的部署要求，並把 API 價格從 K2.7 Code 的 **$0.95/$4**（per Mtoken，in/out）提高到 **$3/$15**。儘管這個價格只與 Sonnet 相當，但仍然非常昂貴。 - **最關鍵的是 64 張加速卡**——中國的推理集群「哪給你找那麼多 64 卡的節點」。 - K3 可能仍希望保持經濟性，但 K3 保持經濟性「有點不可能」。一個 2.8T 的巨型模型，**哪怕對美國本土推理公司都是一場大考**。因此，**K3 的意圖顯然不是為了更廣泛的採用，而是為了在更前沿的戰場上，開源能夠廣泛採用的模型標準**。對照大多數 PR 稿中「碾壓美國模型」的措辭，作者指出 **Kimi 官方措辭更為溫和：K3 整體仍落後於 Fable 5 與 GPT-5.6 Sol**。但「換個角度理解也很激進：只比 OpenAI 和 Anthropic 的最頂級模型差一點」。一旦進入這個檔位，**K3 首先動搖的，就是 Anthropic 過去一年最重要的商業敘事**。「項莊舞劍，意在沛公」——K3 表面是產品，真正打擊面是對手的商業故事。 ### 牢 A の永動物語「牢 A」是中國網路對 Anthropic（A）的戲稱，「永動物語」諷刺其「永動機式」估值敘事。作者拆解 Anthropic 的方法論： - **Anthropic 的方法論一直很清楚：做出一款不可替代的模型，用戶一旦發現它能完成其他模型做不了的工作，就會願意為更高性能支付超額溢價**。 - **Fable 5 是這套方法論最極端的產品**：面向最困難的知識工作、coding，以及可持續數天的複雜異步任務，API 價格達每百萬 token **輸入 10 美元、輸出 50 美元**，是 **Opus 4.8 常規價的兩倍**。 - **Anthropic 出售的不是更貴的 token，而是一個新的任務區間**：過去無法穩定完成的項目，現在可以交給 Fable 處理。在場景中，Fable 有不可替代的價值。 - 只要這種不可替代性存在，**價格溢價完全合理**——畢竟高性能模型取代的是高知識人力，後者工資比模型貴多了。接著是敘事的高峰與崩塌： - Fable 發布後，市場一度形成「OpenAI 已無法追上 Anthropic」的幻覺。**SemiAnalysis 的超級牛市推演甚至預計，Anthropic 到 2027 年底 ARR 可達 3000 億美元，以 20 倍 ARR 對應 6 萬億美元企業價值**。 - 這個預測還依賴一整組假設：**API 占收入 75%–85%、高 API 毛利、極高淨收入留存，以及 Claude Code 持續滲透**。 - 站到 7 月 18 日的時間點，這種預測「仿佛 SemiAnalysis 出現幻覺」；但放在 7 月 8 日，「居然不少人覺得很有道理」。 - **現實給這套敘事安排了一條極有戲劇性的時間線**：6 萬億美元估值推演在 **7 月 8 日被廣泛轉述**，**GPT-5.6 Sol 在 7 月 9 日正式發布**。「牢 A の永動物語，維持不到一個月就被掀了」，期間還夾了幾篇批評中國模型蒸餾的文章。 ### 誰殺死了知更鳥？作者回顧自己曾系統性分析過 GLM-5.2 的重要意義（被讀者稱為「雄文」），並（自嘲地）聲明「智譜從未支付宣傳費，保持獨立研究員身分」。重點是 GLM-5.2 對 Anthropic 根基的動搖： - **GLM-5.2 在大多數任務上表現比 Opus 4.8 更好，僅次於 Opus 4.7**——「比你沒看錯，比 4.8 更好的同時僅次於 4.7，由此令人懷疑 Anthropic 在 4.8 上面到底兌了多少水」。這是作者對 Opus 4.8 相對 4.7 是否存在能力回退／稀釋的嘲諷性質疑。 - 與此同時，**GLM-5.2 的價格僅為 Opus 的五分之一**，還不會受到 Anthropic 訂閱計畫的限速問題。GLM-5.2 的出現已極其顯著地威懾到 **Anthropic 主力模型段的價格錨**。 - 市場因此希望為 Anthropic 進行「更前沿模型」的定價，這才出現 SemiAnalysis 的 6 萬億估值「神人預測」。 - 緊接著，**Sol 在最高能力檔正面撞上了 Fable**。Anthropic 隨後連續延長 Fable 的訂閱額度，並最終宣布把它變成 **Max 與 Team Premium 的常駐權益**——這是 Anthropic 從「溢價獨賣」退守到「訂閱綁定」的訊號。 ![Image](https://pbs.twimg.com/media/HNlitfMb0AALqyX?format=jpg&name=large) - **然後 K3 又出來了**：它的綜合能力落後於 Fable 與 Sol，且**僅落後於 Fable 與 Sol**。與此同時，**K3 還是開源的，哪個推理集群都可以部署**。「孩子們，地裡真的會長出先進 AI 模型」——作者用黑色幽默收束：在第一梯隊之後，開源權重已經能長出近乎追平的模型，稀缺性正被親手種出來。 ### 不對稱競爭這是全篇地緣博弈的核心。作者先把美國算力管制的邏輯說清楚，再揭示它的反作用： - 美國對中國實施先進計算芯片管制的邏輯很直接：**透過限制上游算力，減緩中國訓練前沿模型與建設自主半導體生態**。國家安全、軍事與監控用途是公開法律理由，**維持美國關鍵技術領先則是同時存在的產業目標**。 - 更大的問題其實是**美國自己的先進芯片也不夠用**——不只擔心中國獲得算力，也不希望中國企業參與競價、擠占美國實驗室與數據中心的買卡能力。 - 這套管制提高了中國訓練前沿模型的難度，但也製造了一個微妙反作用：**它剝奪了中國 AI 公司獲取超額利潤的能力，與此同時使這種不利轉變為博弈中的武器化**。關鍵的反轉邏輯濃縮成一句： > 既然你不讓我賺超額利潤，我又不想被封鎖技術，那我做出來之後不要利潤不就完事了？而且**開源模型不挑顯卡**——中國顯卡能部署，美國算力集群也能部署，**Fireworks、TogetherAI，還有一大堆 NeoCloud，都有一堆顯卡**。於是中美 AI 競爭出現了一種「極其抽象的組合」： > 中國模型 + 美國及全球推理集群 VS 美國閉源 AI 實驗室分工與損益的不對稱： - **中國實驗室**承擔昂貴的模型研發，以**開放權重換取採用與前沿地位**。 - **美國雲廠商與推理平台**使用本土 GPU 承接調用，**按成本定價，狠狠賺錢**。 - **真正失去利潤的，反而是依靠封閉權重與能力稀缺收取超額價格的美國 frontier lab**。 - 對中國實驗室而言，開放權重犧牲的是**本來就受自有推理容量限制的潛在 API 租金**；對美國閉源實驗室而言，被犧牲的卻是**建立在充足本土算力與全球能力稀缺之上的現實超額利潤**。因此，美國面臨的不是「繼續制裁還是放開銷售」的簡單選擇，而是**不可能三角**： - **制裁中國** → 中國就會繼續放開源模型出來，「反正大家都別賺錢了」。 - **放開中國買卡** → 集體競價，本土實驗室又可能缺卡。 - **適當放給中國一些卡** → 確實可以取得折中收益，但「到底放出多少卡合適？沒人知道，也沒人敢說話」。作者下結論：**這是典型的不對稱競爭。華盛頓熱衷於講不對稱競爭，現在這個詞落回到華盛頓頭上了**。 ### 誓死效忠美光！「誓死效忠美光！」是作者的反諷標題（「美光」為 Micron，這裡借指 AI 硬體／CapEx 鏈條上游，象徵資本市場對硬體景氣的盲信崇拜）。這段把論證往 AI 資本開支敘事的上游再推一步： - **過去，閉源前沿模型的高推理毛利是 AI CapEx 鏈條最重要的緩衝墊**。只要模型能力足夠稀缺，API 與訂閱就能維持高價；實驗室與雲廠商獲得高毛利，便能容忍更貴的 GPU、更快的折舊與更激進的數據中心投入；上游又據此繼續擴產與維持高定價。這條鏈可寫成： > 模型能力稀缺 → API 高價 → 下游高毛利 → 能夠承受 GPU 溢價 → CapEx 擴張 → 上游持續景氣。 - **當多家平台可以部署同一份權重，推理價格就會從「前沿實驗室願意收多少」，逐漸回到「高效集群跑出一個成功任務需要多少錢」**。 - **開放權重改變的不是算力需要花錢這個事實，而是取消了算力消費上附著的「模型稅」**。Fireworks 不必替 Moonshot 承擔 K3 的預訓練成本，也不必按 token 向一個閉源模型上游支付完整的模型租金。 - 它當然還要承擔 GPU、推理引擎、量化、緩存、網絡、融資、SLA 與企業銷售，但**只需圍繞實際算力成本、利用率、服務成本與競爭性利潤報價**。這是典型的**成本定價邏輯**，而對依賴景氣度的行業，**成本定價對上游的影響是災難性的**。接著是對 GPU 資本回報計算的反向改寫： - **這會反向改變每一張 GPU 的資本回報計算**。過去服務商可把昂貴硬體成本放進高價模型 API，再向終端客戶轉嫁。 - 當推理平台圍繞同一開放權重競爭，任何一家都更難繼續轉嫁這層溢價。於是 **GPU 採購需要更高利用率、更短回收期、更低融資成本與更確定的客戶合同**。 - **短期來看**，下游採購方更分散，並不會削弱算力生產商（尤其是 NVDA）的議價權。 - **但長期來看**，下游毛利潤系統性下降，必然導致上游可議價彈性變差，這對整個 AI CapEx 敘事都是不可控的巨大風險。 ### Too Big to Fail：大而不輸作者把 K3 的 2.8T 總結為兩種「看似相反」的意義，並收束到方法論： - 一方面，K3 **不是個很經濟的模型**，把模型推入 Sonnet 價格帶與 64 卡以上部署區間。 - 另一方面，正是這份「不首先考慮經濟性」，讓 K3 獲得了**進入最高能力組、動搖 Anthropic 模型租金、重組中美推理利潤與影響 AI CapEx 敘事**的資格。接著作者反駁「夠用就好」的端側／小尺寸路線： - 過去很多公司喜歡講端側、講小尺寸、講「夠用就行」。這些路線決定**已存在的智能可以擴散到多少設備、用戶與行業**。 - 但「夠用」這個詞非常無趣，**它只適用於能力邊界已經固定的市場**。 - **前沿 AI 面對的任務集合從來不固定**：模型今天剛學會單文件編程，明天就要處理整個代碼庫；剛學會工具調用，下一代就要持續工作數小時乃至數天。 - **尺寸更適中的模型回答「如何被更多人使用」，而尺寸更大的模型爭奪「誰擁有發表神諭的權利」**。核心的不對稱性（全篇方法論結晶）： - **一個已經很強但昂貴的大模型，後來可以透過稀疏化、量化、緩存、蒸餾與推理工程做快、做便宜，還可以作為整條小模型產品線的教師模型**。 - **一個一開始就沒有學到某種能力的小模型，卻很難靠延長思考或部署優化把它憑空補出來**。 - 這個不對稱性，讓「往大了做就不會輸」成為一套**粗糙卻經常有效的前沿方法論**。作者用產業史佐證這個方法論的循環與反轉： - **2024 年，OpenAI 發布 o1，把 scaling 的重心從更大的預訓練基座轉向訓練時強化學習與測試時思考計算（test-time compute）**。 - **o1 本身是一款更小尺寸推理模型**。它證明「較小基座 + 更多思考」可以在數學、代碼與形式推理上製造驚人進步，也由此開啟一輪把參數做小的循環。 - **基座越小，越依賴 test-time compute 補償；推理技巧越成功，組織越缺少擴大基座的動力**。由此，OpenAI 的模型開始「極速劣化」（作者的主觀判斷）。 - **2025 年，Anthropic 走了相反方向**——堅持做更大更昂貴的模型，再用 Claude Code 把能力變成產品。 - 用戶對 Claude 的忠誠不是因為便宜，而是因為「在最困難的真實軟件工程任務上，把工作交給 Opus 更放心」。**到 2025 年末，Anthropic 稱 Claude Code 已占超過一半的 AI coding 市場，企業市場份額從 24% 提高到 40%，收入也超過了 OpenAI**。 - **OpenAI 隨後重新意識到，推理效率與路由不能取代最高能力基座**。GPT-5 重新建立 main、thinking、mini、Pro 的完整階梯；到 GPT-5.6，又明確設置 **Sol、Terra、Luna 三個模型尺寸**，並把**大尺寸 Sol 放回面向最困難工作的旗艦位置**。 - **由此，Codex 用戶快速突破 1000 萬，逼得 Anthropic 把 Fable 加回了訂閱計畫**。 - 現在 K3 發布，僅次於 Sol 與 Fable，甚至引起「關於美國前沿 AI 到底還行不行」的討論。 - **「當你真的願意去爭第一，結果大概率不會太差。這就是 Too Big to Fail。」** ### 結語：小鎮青年暴打資本家作者用一個強烈的對位隱喻收束全篇： - 中國 AI 模型公司經常被描述為**小鎮青年**：資源有限、位置不佳、國際輿論更差，**算力卡能養活推理都不錯了，訓練不掉隊就行**。 - 與此同時，**美國的先進 AI 實驗室則頗具資本家風範**：討論人類學與安全、討論慈愛恩典的機器、討論未來世界屬於自由還是屬於不自由、討論 AI 屬於大地還是屬於藍天。 - **在如此戲劇性的差距下，居然能上演一齣小鎮青年暴打資本家的戲碼**。無論如何找補，都足以讓人笑掉大牙。 - 「——其實也不用急。好戲還在後頭呢。」作者以開放式預告收尾，暗示這場不對稱競爭才剛開始。 ## 總結與結論 - **K3 是戰略轉向，不是版本升級**：K2.5~K2.7 在 1T/A32B 底盤上靠後訓練壓榨多代；K3 直接把總參數推到 2.8T、激活約 50B，回到預訓練規模擴張，並抽換回本家技術棧，標誌 Kimi 主動結束「既有基座後訓練」階段，重新爭奪前沿尺寸話語權。 - **「放棄經濟性」本身就是入場券**：64 卡部署與 $3/$15 定價意味著 K3 不為 adoption 而戰，而是用「不計成本做最大」換取進入最高能力組（官方：僅落後 Sol/Fable）的資格，這是它一切外溢效應的前提。 - **開源權重把地緣劣勢武器化**：算力管制剝奪了中國的超額利潤空間，反而促成「不要利潤、做開源」的反轉，形成「中國模型 + 美國／全球推理集群 VS 美國閉源前沿實驗室」的不對稱組合，使華盛頓自己陷入制裁／放開／折中的不可能三角。 - **「取消模型稅」反向衝擊 AI CapEx**：當多家平台可部署同一份權重，推理定價從「閉源上游想收多少」回歸「高效集群跑成功任務的成本」，下游毛利系統性下降長期將壓縮上游 GPU 的議價彈性——短期 NVDA 議價權不變，但回報曲線的折現假設需下修。 - **方法論結晶是 Too Big to Fail**：強大模型可稀疏化、量化、蒸餾下沉並擔任教師，但缺乏能力的小模型難靠延長思考補出來；這個不對稱性使「往大了做」成為粗糙但有效的前沿路線，OpenAI o1 做小→依賴 test-time compute→GPT-5.6 Sol 重新做大尺寸，本身已是路線回歸的承認。

Obsidian 整理原始文章

學習資源

skill+anki+美剧，这样学英语太高效了（开源这个skill）

"把「不需要人判斷的執行」全交給 agent，把「情境識別」留給劇集，再把順序倒過來（先卡後劇），就是 10 倍效率。"

Top 5 Insights

**方法論核心是「順序顛倒」，不是工具**。整篇文章真正值錢的洞察是「先卡片後劇集」——把識別（recognition）當成第一次複習，讓短期記憶在真實情境裡被鞏固成長期記憶。工具（skill / Anki / FSRS）只是把這個順序變得可執行。把這個原則抽走，整條流水線就退化成普通的單詞 app。
**「辨識可自動化步驟」是架構師級別的判斷**。作者從 5 步手動流程裡正確分離出「全是執行、無一步需要判斷」這個屬性，並把判斷（取捨哪些詞、用哪個字幕源、怎麼排優先級）寫死成 skill 的 policy，把執行交給 agent。這與軟體工程裡把 business logic 與機械執行分層是同一種思維。
**用機制消滅易錤點，優於靠人小心**。CSV 文件頭自帶 Anki 導入指令（分隔符、牌組名、字段映射），把「正反面搞反」這個高頻人為錯誤從機制上消滅。卡片方向（正面英文原句、背面中文譯句）也對齊真實使用場景（聽到英文→反應意思）。這是 API/介面設計「防止誤用」的範例。
**科學理論是骨架，但被過度簡化為單一銀彈**。遺忘曲線、情境編碼、Krashen i+1、FSRS 各自有適用條件與爭論，作者只取結論支撐流程，沒有交代失效邊界。讀者若把這些理論當成已證成的真理而非啟發式，會高估方法的普適性。
**明確的適用邊界與風險**：本方法假設用戶已有 B1 以上英文基礎（skill 跳過基礎詞、只取 B2-C1）、假設字幕來源穩定（subslikescript 繞 JS 驗證碼屬灰色地帶）、假設每天能看一集（FSRS 在 0.90 保留率下，500–1000 張卡的每日複習量長期可能造成「複習雪崩」）。零基礎者、無穩定看劇習慣者、字幕缺失的冷門劇，都不在本方法的適用範圍內。

--- tags: [學習資源, 英語學習, Anki, Claude-Skills, 間隔複習, agent-automation, FSRS] date: 2026-07-20 read: false source: "2026-07-20T100451+0800-skill+anki+美剧，这样学英语太高效了（开源这个skill）.md" original_title: "skill+anki+美剧，这样学英语太高效了（开源这个skill）" --- # skill+anki+美剧，这样学英语太高效了（开源这个skill） ## Skill + Anki + 美劇：最高效的英語學習法（開源這個 Skill） ![Image](https://pbs.twimg.com/media/HNlRqlPbAAILwp4?format=jpg&name=large) 原始來源與檔名：2026-07-20T100451+0800-skill+anki+美剧，这样学英语太高效了（开源这个skill）.md --- ## SOURCE | 資訊源評估 - **準確性**：中 - 作者為 45 萬粉絲自媒體創作者，非學術來源；但引用了真實科學概念（Ebbinghaus 遺忘曲線 1885、情境編碼 context encoding、Krashen i+1、FSRS 演算法），這些引用經過通俗化簡化，原理方向正確但細節被壓縮。工具本身（gbro-series-vocab skill）作者聲稱實測 3 個月，MIT 開源可驗證。 - **易理解性**：高 - 採用極口語化、step-by-step 的敘事，每章節有明確編號與小標，搭配具體劇名（Friends / The Pitt / Breaking Bad / Grey's Anatomy / 9-1-1）作為案例，門檻極低。 - **閱讀策略建議**：先讀 **04 順序** 與 **03 Agent 化** 兩章——前者是方法論核心（先卡片後劇集），後者是技術實作精華（字幕來源策略、CSV 文件頭技巧、卡片方向設計）。01–02 為鋪陳，05 為部署。完整 prompt 與實作細節需到 GitHub repo（`pyang5166/gbro-series-vocab`）查證。 ## NAPKIN | 餐巾紙 ### 餐巾紙公式 > `美劇字幕 → Skill 提取 50 詞 → Anki CSV/MD → 先刷卡 15 分 → 看這一集 → 長期記憶` _關鍵不在工具，而在「順序顛倒」＋「把無需判斷的執行交給 agent」。把識別（recognition）當成第一次複習，而非再加一張卡。_ ### 一句話 > 把「不需要人判斷的執行」全交給 agent，把「情境識別」留給劇集，再把順序倒過來（先卡後劇），就是 10 倍效率。 ### 餐巾紙草圖 ``` ┌────────────────────────────────────── │ 一句話指令 │ 「追劇學英語 Friends S01E01」 │ │ │ ▼ │ Skill 內部 5 步全自動 │ 找字幕 → 提取 50 詞 → 生成 CSV + MD │ │ │ ▼ │ ★ 關鍵：顛倒順序 ★ │ 先刷卡 15 分鐘 → 再看這一集 │ (短期記憶預熱) (情境編碼 → 長期記憶) │ │ │ ▼ │ 聽到演員嘴裡說出那些詞 = 第一次複習 └────────────────────────────────────── ``` ## ROUND 1: SKELETON | 骨架掃描 - **核心問題**：為什麼背了那麼多單詞還是聽不懂美劇？如何用 agent 把學英語這件事做到 10 倍效率？ - **核心答案**：問題出在「輸入品質」（真空詞彙 vs 情境詞彙）與「順序」（先劇後卡 → 反過來）。解法 = 情境編碼（劇集）＋間隔複習（Anki/FSRS）＋ agent 自動化提取（skill），三者用「先卡片後劇集」的順序串起來。 - **論證結構**：痛點（單詞 app 無效）→ 科學原理（遺忘曲線 + 情境編碼）→ 原版方法（3 工具 5 步）→ 洞察（全是執行無判斷）→ Agent 重寫（1 句話）→ 核心原則（順序 + i+1 + FSRS 細節）→ 部署。 ### 章節骨架 - **01 為什麼背了那麼多單詞，還是聽不懂劇** — 定義問題：輸入品質而非努力量；引入遺忘曲線與情境編碼。 - **02 原版方法：三個工具，五次複製貼上** — 描述手動流程（Google → NotebookLM → Claude → 表格 → Anki），點出痛點。 - **03 Agent 時代：五步變一句** — skill `gbro-series-vocab` 的三段自動化（找字幕／提取 50 詞／生成兩檔）＋ CSV 文件頭與卡片方向的設計細節。 - **04 順序，比工具更重要** — 方法論核心「先卡片後劇集」＋ Krashen i+1 ＋三個執行細節（英文字幕／FSRS 0.90／只按 Again+Good）。 - **05 裝上就能用** — git clone 部署、依賴、預期產出量（一季 500–1000 張卡）、方法論出處（Phosphen）。 ## ROUND 2: DISSECTION | 血肉解剖 ### 論證鏈 ``` 背單詞 app 無效 │ 因：詞躺在真空裡，無場景/情緒/利害 ▼ 劇集才是正確材料 (情境編碼) │ 因：情緒+畫面+人聲 → 多條記憶通路 ▼ 但缺一條「提取 → 製卡」的流水線 │ 解：原版 3 工具 5 步 ▼ 5 步全是執行、無一步需要判斷 │ 洞察：這正是 agent 該做的事 ▼ Agent 化：5 步 → 1 句話 (gbro-series-vocab) │ + 用機制消滅易錯點 (CSV 文件頭預設導入指令) ▼ 顛倒順序：先卡片後劇集 │ 因：識別 > 學習；i+1 卡在理解力邊緣 ▼ 長期記憶 + 突然聽懂劇 ``` ### 3 個關鍵證據 1. **10 倍效率對比（作者自陳）**：同一集 Friends，舊法只記住 3 個詞，新法記住 30 個詞；體驗從「硬熬打卡」變成「期待追劇」。此為主觀、無控制對照的數據，僅作為動機證據。 2. **Ebbinghaus 遺忘曲線（1885）**：新信息幾天忘 40%、一個月忘 90%——支持「必須間隔複習」的前提。但作者只取結論，未說明間隔複習曲線（spacing effect）與原始遺忘曲線的差異。 3. **Krashen i+1 可理解性輸入**：沒預習硬看，難度遠超水平 → 大腦走神；預熱 15 分後難度卡在理解力邊緣 → 難到能成長、簡單到能享受。這是把語言學習理論轉成可操作的「預熱時長」參數。 ### 隱形假設與邊界 - **假設用戶已有 B1 以上英文基礎**：skill 提取標準跳過基礎詞、只取 B2-C1，零基礎者拿到 50 張卡會全是生詞、預熱 15 分鐘根本不夠，i+1 不成立。 - **假設字幕來源穩定可靠**：Springfield Springfield（老劇劇本站）、subslikescript（新劇，被 JS 驗證碼擋）、Fandom Wiki——作者說「用了三個月沒遇到要手貼」，但網站政策、可用性、字幕品質隨時可能變。 - **假設用戶每天能看一集**：一季 20 集 × 一天一集，需要連續 20 天紀律；FSRS 在保留率 0.90 下，500–1000 張卡的每日複習量會累積，存在「複習雪崩」風險（作者自己也警告 0.95 會讓複習量翻倍）。 - **法律/版權邊界未談**：抓取劇本站字幕、把台詞做成卡片的版權屬性，作者完全沒提。 ## ROUND 3: SOUL | 靈魂提取 - **作者盲點**： - 科學引用被當成「單一銀彈」——情境編碼、i+1、FSRS 各自有適用條件與爭議，作者只用結論支撐流程，沒有交代這些理論何時會失效。 - 「10 倍效率」「百倍體驗」是行銷語言，無控制實驗；真正可驗證的是 GitHub 上的 skill 程式碼本身。 - 把「學會英語」簡化成「聽懂一集劇」——詞彙覆蓋率 ≠ 聽力理解 ≠ 口說產出，三條路被混為一談。 - 字幕繞行方案（subslikescript 的 JS 驗證碼）觸及灰色地帶，但被當成純技術問題處理。 - **知識連接**： - 與 [[agent-automation]] / Claude Code Skills 生態連結——本質是「把重複性執行 workflow 封裝成一句話指令」，與 devops 自動化、CI/CD pipeline 同構。 - 與 [[間隔複習]] / FSRS 演算法連結——保留率參數（0.90 vs 0.95）是每日複習量的指數型槓桿。 - 與軟體工程的 [[mechanism-over-policy]] 連結——「CSV 文件頭自帶導入指令」是把易錯點（正反面搞反）從「靠人小心」改成「機制上不可能犯」，這是優秀 API 設計的體現。 - **行動觸發**： - 立即可做：`git clone` 試跑一集自己想看的劇，驗證「先卡後劇」的體感差異。 - 遷移應用：審視自己手邊有哪些「五步重來、無一步需要判斷」的 workflow，是 agent 化的候選名單。 ### 留白提問（2 題） 1. 如果劇集沒有可靠英文字幕（如純亞洲劇、紀錄片、冷門老劇），這條「找字幕」流水線的 fallback 該如何設計？「全网搜 + Fandom Wiki」是否真的能覆蓋？ 2. FSRS 保留率 0.90 下，一季累積 500–1000 張卡、連續多季後，每日複習量的增長曲線會不會在某個臨界點壓垮「一天一集」的節奏？這個系統的穩態（steady state）在哪裡？ ### 跨域映射 - **與 TDD（測試驅動開發）同構**：先寫測試（卡片預熱，建立預期）→ 再寫實作（看劇，接觸真實場景）。兩者都是「先建立心理模型，再面對真實複雜度」。 - **與 onboarding 流程同構**：先讀文件/架構圖（卡片）→ 再進 codebase 看真實程式碼（劇集）。沒預習直接看 codebase ＝沒預習硬看劇，大腦走神。 - **與 code-gen agent 同構**：都是辨識「哪些步驟不需人類判斷」並將其自動化；人類只保留「看劇／審查 PR」這種需要情境理解的高階動作。 ## DEEP READ | 精讀指引 - **精讀段落一：第 03 章「Agent 時代：五步變一句」**。這是技術密度最高的章節，值得逐句拆解：字幕來源的分流策略（老劇/新劇/兜底）、詞彙提取的優先級排序（短語動詞 > 习语固定搭配 > 俚語口語 > B2-C1）、CSV 文件頭自帶 Anki 導入指令這個設計巧思。讀的時候追問：作者如何決定「50 個詞」這個數字？優先級排序的依據是什麼？這些設計決策若進到 repo 看實作，會發現哪些 prompt 工程的細節？ - **精讀段落二：第 04 章「順序，比工具更重要」**。這是方法論核心，也是整篇文章最容易被誤讀為「工具文」時真正值錢的部分。重點是「識別（recognition）≠ 學習（learning）」這個認知科學區分，以及 Krashen i+1 從抽象理論到「預熱 15 分鐘」這個可操作參數的轉譯過程。讀的時候追問：為什麼是 15 分鐘而不是 5 分或 30 分？FSRS 保留率 0.90 與 0.95 的「複習量翻倍」這個說法，在 FSRS 的數學模型裡對應到什麼？ - **推薦理由**：這篇文章表面是「英語學習工具推薦」，深層是「如何用 agent 重構一條手動 workflow」的微型 case study。它的價值不在結論（用劇學英語不新鮮），而在示範了「辨識可自動化步驟 → 用機制消滅易錯點 → 用理論支撐參數選擇」這個三層方法論。製造認知阻力的方式：不要把它當工具文讀，把它當「一個 5 步 workflow 如何被壓縮成 1 句話」的架構設計案例讀。 ## STRUCTURE MAP | 全書結構圖 ``` ┌──────────────────────────────────────────────── │ 【01 痛點】單詞 app 無效 │ ├─ 真空詞彙 vs 情境詞彙 │ └─ 遺忘曲線 (Ebbinghaus 1885) + 情境編碼 │ │ │ ▼ │ 【02 原版方法】3 工具 5 步 │ Google字幕 → NotebookLM → Claude → 表格 → Anki │ 痛點：每集重來、正反面易搞反 │ │ │ ▼ 洞察：5 步全是執行、無一步需判斷 │ 【03 Agent 重寫】5 步 → 1 句話 │ └─ skill: gbro-series-vocab │ ├─ 找字幕 (Springfield/subslikescript/Fandom) │ ├─ 提取 50 詞 (優先級 + 禁止造句) │ └─ 生成 CSV + MD (文件頭預設導入指令) │ │ │ ▼ │ 【04 核心原則】先卡片後劇集 ★全文樞紐★ │ ├─ 識別 > 學習 (recognition → long-term) │ ├─ Krashen i+1 (預熱 15 分卡在理解邊緣) │ └─ FSRS 0.90 + 只按 Again/Good │ │ │ ▼ │ 【05 部署】git clone + 一句話 │ 一季 500–1000 張 B2-C1 活詞彙 └──────────────────────────────────────────────── ``` --- # skill+anki+美剧，这样学英语太高效了（Architectural Deep Dive） ## 前言／背景作者是國內平台 45 萬粉絲的自媒體創作者，自陳對「做自媒體」貢獻最大的技能不是剪輯、不是寫腳本，而是**英語**——最新的 AI 玩法、第一手資訊幾乎全在英文世界，多數選題與認知差都是從英文圈「搬回來」的。圍繞英語學習，作者試過背單詞 app、網課、打卡社群，最後留下來的是一套自製的 **Skill + 美劇** 組合。這篇文章的核心宣告： - 記單詞效率比過去任何方法**高 10 倍**——同一集《老友記》（Friends），過去看完只記住 3 個詞，現在能記住 30 個。 - 學習體驗「差了不止百倍」——過去是硬熬打卡，現在就是追劇。整條流程在作者端只剩一句話： ``` 追劇學英語 Friends S01E01 ``` 3 分鐘後產出 50 張 Anki 閃卡 + 一份詞彙筆記，每張卡的例句都是該集真實台詞（非 AI 編造）。作者從 4 月用到文章發布（約 3 個月），決定開源。 ![Image](https://pbs.twimg.com/media/HNljAoQbgAEsbGZ?format=jpg&name=large) _插圖由作者開源的拼貼 B-roll skill 生成_ ![Image](https://pbs.twimg.com/media/HNljuijb0AAGY8i?format=jpg&name=large) _插圖由作者開源的拼貼 B-roll skill 生成_ 作者特別強調：**在講工具之前先講方法**——工具只是把方法變快，方法本身才是值錢的東西。 ## 章節詳細總結 ### 01 為什麼背了那麼多單詞，還是聽不懂劇多數人學英語的路徑是：背單詞 app → 打卡 → 保持連勝。半年後打開一部美劇，還是聽不懂。 ![Image](https://pbs.twimg.com/media/HNljOz6b0AAo6_C?format=jpg&name=large) _插圖由作者開源的拼貼 B-roll skill 生成_ 作者的核心診斷：**問題不在努力，在輸入的品質。** 單詞 app 裡的詞是「躺在真空裡」的——沒有場景、沒有情緒、沒有利害關係。大腦掃一眼就標記為「無關緊要」然後按時刪除。作者引用 Ebbinghaus 1885 年的實測： - 新信息幾天忘掉 **40%** - 一個月忘掉 **90%** 這是**遺忘曲線**（forgetting curve），與聰不聰明無關。而劇裡的詞不同：一個詞是由一個具體的人、在一個有情緒的場景裡、用真實語氣說出來的。神經科學稱之為**情境編碼**（context encoding）——情緒、畫面、人聲會讓大腦為同一個詞建立**多條記憶通路**。詞留得下來，是因為大腦判定它「重要」。由此推論：正確的材料一直都在眼前——你本來就想看的那部劇。一集像樣的美劇裡，有 **50 到 100 個值得學的詞**：短語動詞（phrasal verbs）、俚語（slang）、翻譯器永遠翻不對的習語（idioms）。缺的只是一條流水線，把這些詞從劇裡撈出來、做成可間隔複習的卡片。 ### 02 原版方法：三個工具，五次複製貼上這套方法不是作者發明的。原版流程用三個工具接力，共五次複製貼上： 1. Google 搜這一集的字幕，複製全文。 2. 粘進 **NotebookLM**，用提示詞提取 50 個詞彙（它只從你給的字幕裡取，不胡編）。 3. 把結果粘給 **Claude**，轉成兩列 CSV。 4. CSV 粘進表格軟體檢查，下載。 5. 導入 **Anki**，手動配置字段映射。方法是對的、效果也是真的。但**每換一集，這五步就要重來一遍**：字幕要自己搜、粘來粘去要自己盯格式、Anki 導入時正反面映射搞反一次，就得刪了重導。作者跑了幾次後的關鍵洞察： > 這五步裡沒有一步需要人的判斷，全是執行。而「不需要判斷的執行」，恰好就是 agent 該幹的活。這句話是整篇文章從「工具推薦」升級為「架構設計」的轉折點——它正確地辨識出了 workflow 裡可被自動化的部分。 ### 03 Agent 時代：五步變一句作者把整條流水線寫成一個 skill——**`gbro-series-vocab`**。用法：對 Claude Code（或任何支援自定義 skill 的 agent）說一句「追劇學英語 The Pitt S01E02」，然後去倒杯水。 Agent 自動完成三件事： **① 找字幕（分流策略）** - 老劇走 **Springfield Springfield** 劇本站。 - 新劇走 **subslikescript**（此站被 JS 驗證碼擋著，skill 裡寫好了繞行方案）。 - 再找不到就全网搜，**Fandom Wiki** 也是可靠來源。 - 已測過能走通的邊界案例：帶撇號的 `Grey's Anatomy`、帶數字的 `9-1-1`、2025 年新劇 `The Pitt`。 - 全部失敗才會請你手動貼劇本——作者用了三個月還沒遇到過。 **② 提取 50 個詞（標準寫死在 skill 裡，按優先級）** - 短語動詞（phrasal verbs） - 习语固定搭配（idioms / fixed collocations） - 俚語口語（slang / spoken） - B2-C1 實用詞 - 跳過基礎詞。 - **例句必須取自劇本原文，禁止造句。** **③ 生成兩個文件** - 一個 **Anki CSV**。 - 一份 **Markdown 詞彙筆記**（詞／釋義／音標／原句／譯句），存進筆記庫。 **CSV 文件頭的設計細節（值得單獨說）**：文件頭自帶 Anki 導入指令——分隔符、牌組名、字段映射全部預設好。雙擊導入，不用碰任何配置。原版流程裡最容易翻車的「正反面搞反」問題，**從機制上消滅了**。這是典型的「mechanism over policy」——與其靠人小心，不如讓錯誤在機制上不可能發生。 **卡片方向**也調整過：正面英文原句，背面中文譯句 + 釋義 + 音標。理由：看劇的真實場景是「聽到英文，反應意思」，卡片就該練這個方向。 ### 04 順序，比工具更重要工具再快，用錯順序還是白搭。作者點出方法真正的核心是四個字： > **先卡片，後劇集。** ![Image](https://pbs.twimg.com/media/HNlj-BhaAAACIhP?format=jpg&name=large) _插圖由作者開源的拼貼 B-roll skill 生成_ 大多數人是反著來：看劇 → 聽不懂 → 沮喪 → 查了三個詞 → 下周忘光。把順序倒過來：先花 **10 到 15 分鐘**把 50 張卡過一遍，讓這些詞進入**短期記憶**，然後馬上看這一集。剛見過的詞會一個一個出現在真實場景裡——帶人聲、帶情緒、帶上下文。關鍵論證：大腦不會把這個過程當成「學習」，它會當成**「識別」**（recognition）。而識別，是短期記憶通往長期記憶最快的一條路。**第一次複習不是另一張卡片，而是螢幕上一段真實的對話。** 作者把這連到 Krashen 的 **i+1 原則**（可理解性輸入）： - 沒預習就硬看，難度遠超水平，大腦直接走神。 - 預熱 15 分鐘後再看同一集，難度正好卡在理解力的邊緣——**難到能成長，簡單到能享受**。三個執行細節（參數調校）： 1. **只開英文字幕**。中文字幕會毀掉全過程——大腦會死死抓住翻譯，徹底停止處理英文。 2. **Anki 打開 FSRS，期望保留率設 0.90，別貪高**。0.95 會讓每天的複習量翻倍。 3. **只用 `Again` 和 `Good` 兩個按鈕**。`Hard` 和 `Easy` 會干擾演算法優化。 > 補充背景：FSRS（Free Spaced Repetition Scheduler）是 Anki 新一代間隔重複演算法，相比傳統 SM-2 以「記憶穩定性」（stability）建模，保留率（desired retention）是其核心可調參數。作者選 0.90 是在「記得住」與「複習量可控」之間的務實權衡。 ### 05 裝上就能用部署指令： ```bash git clone https://github.com/pyang5166/gbro-series-vocab.git ~/.claude/skills/gbro-series-vocab ``` - 不需要 API key。 - 唯一依賴是 `curl`（Mac/Linux 自帶）。 - 首次使用會問兩個問題：**筆記存哪**、**釋義用什麼語言**——之後不再打擾。然後就是那句話： ``` 追劇學英語 Breaking Bad S02E03 ``` 預期產出量：一部劇一季 20 集，一天一集，一季下來 **500 到 1000 張卡**——全部是 B2-C1 的活詞彙，全部來自你本來就想看的內容。作者的結語定位： > 每個人都想「學會」英語，但沒人想「學」英語。這套流程把「學」的部分交給了 agent 和演算法：AI 負責提取，機器學習負責排程，你只負責看劇。剩下的，就是某一集看到一半，突然意識到——**我居然沒開字幕，也聽懂了**。那個瞬間比任何打卡紀錄都值錢。 **方法論出處**：原版三工具流程出自 **Phosphen 的 NotebookLM + Claude + Anki 語言學習法**，本文的 skill 是它在 Agent 時代的自動化重寫。 **repo**：`https://github.com/pyang5166/gbro-series-vocab`（MIT 開源，歡迎 star 與改進）。 ## 總結與結論 1. **方法論核心是「順序顛倒」，不是工具**。整篇文章真正值錢的洞察是「先卡片後劇集」——把識別（recognition）當成第一次複習，讓短期記憶在真實情境裡被鞏固成長期記憶。工具（skill / Anki / FSRS）只是把這個順序變得可執行。把這個原則抽走，整條流水線就退化成普通的單詞 app。 2. **「辨識可自動化步驟」是架構師級別的判斷**。作者從 5 步手動流程裡正確分離出「全是執行、無一步需要判斷」這個屬性，並把判斷（取捨哪些詞、用哪個字幕源、怎麼排優先級）寫死成 skill 的 policy，把執行交給 agent。這與軟體工程裡把 business logic 與機械執行分層是同一種思維。 3. **用機制消滅易錤點，優於靠人小心**。CSV 文件頭自帶 Anki 導入指令（分隔符、牌組名、字段映射），把「正反面搞反」這個高頻人為錯誤從機制上消滅。卡片方向（正面英文原句、背面中文譯句）也對齊真實使用場景（聽到英文→反應意思）。這是 API/介面設計「防止誤用」的範例。 4. **科學理論是骨架，但被過度簡化為單一銀彈**。遺忘曲線、情境編碼、Krashen i+1、FSRS 各自有適用條件與爭論，作者只取結論支撐流程，沒有交代失效邊界。讀者若把這些理論當成已證成的真理而非啟發式，會高估方法的普適性。 5. **明確的適用邊界與風險**：本方法假設用戶已有 B1 以上英文基礎（skill 跳過基礎詞、只取 B2-C1）、假設字幕來源穩定（subslikescript 繞 JS 驗證碼屬灰色地帶）、假設每天能看一集（FSRS 在 0.90 保留率下，500–1000 張卡的每日複習量長期可能造成「複習雪崩」）。零基礎者、無穩定看劇習慣者、字幕缺失的冷門劇，都不在本方法的適用範圍內。

Obsidian 整理原始文章

🌟 今日領域總結 (Domain Summaries)

AI工具 總結報告

AI工程 總結報告

AI技術 總結報告

AI視野 總結報告

Agent架構 總結報告

其他 總結報告

學習資源 總結報告

📚 文章摘要列表 (Articles)

Codex 史詩級更新實操教程：Work、Plugins、內建瀏覽器、Ultra 與 Chat 一次講透

How to Build a Self-Correcting AI Loop That Catches Its Own Mistakes Before You See Them（如何打造一個在你看見之前就自我抓錯的 AI 迴圈）

How to Choose Between Kimi K3, Sonnet 5, and Fable 5 (The Exact Routing Rules)（如何在 Kimi K3、Sonnet 5 與 Fable 5 之間做選擇：精確路由規則）

Loop Engineering: A Guide for Engineers and Practitioners（迴圈工程：給工程師與從業者的實戰指南）

Graph Engineering replaced RAG at Microsoft, Stanford and Anthropic. Here's how it works.（圖譜工程取代 RAG：Microsoft、Stanford、Anthropic 的實踐全解）

OpenAI做了块小键盘，包揽了人类能做的最重要的事情！

From Loop Engineering to Graph Engineering?（從迴圈工程到圖工程？）

評 Kimi K3：小鎮青年暴打資本家

skill+anki+美剧，这样学英语太高效了（开源这个skill）

AI工具總結報告

AI工程總結報告

AI技術總結報告

AI視野總結報告

Agent架構總結報告

其他總結報告

學習資源總結報告