黃金圈二：建立方法論 — 三個核心與它的漏洞

上一篇我們建立了三環閉環的架構，讓系統可以打破天花板持續成長，但架構只是骨架，借用 Mosky 的說法，進擊的巨人也是先長骨架再長肉，所以這篇開始，我們要往裡面填肉，開始想想方法論的三個核心是什麼？它有哪些漏洞？人類該在什麼時候介入？

方法論的三個核心

Agent 把方案整理成方法論之後，我們開始討論這個方法論的核心到底是什麼？經過幾輪來回，Agent 協助我收斂出三個相互依存的核心：

核心一：多策略發現

因為光靠「偵測已知問題」永遠有天花板，所以發現迴圈需要自己成長，這個”成長”需要有多種策略，避免他的”成長”被限縮，所以我需要每種策略的成長曲線不同：

• 模式傳播（線性）：在一個 Agent 發現的問題，檢查其他 Agent 是否有同樣的問題
• 變異探測（線性）：對已知問題做變形，看系統會不會漏掉變體
• 根因推論（指數級）：從一個問題的根因推導出全新的問題類別，這是打破天花板的關鍵，因為一個根因可能對應多個你從沒想過的問題
• 跨領域遷移（組合級）：把一個領域的問題模式套到另一個領域

核心二：以事實為基礎的信號源

方法論的所有判斷都必須基於事實（Source of Truth），不能基於假設，所以我們把信號分三層：靜態分析（看程式碼）、狀態分析（看運行時資料庫的狀態）、生產信號（看實際運行的行為），只有多層信號交叉驗證才能產生出有信心的結論。

這跟我們在第三篇 Context Engineering [5] 討論的問題直接相關，之前的時區盲點就是一個「基於假設而非事實」的典型 Agent 誤區案例。

核心三：會自我進化的指標

這是最重要的一個，因為沒有指標，你就沒辦法分辨優先度和重要性，但指標本身也會成為限制，當你優化一個指標，你可能不知不覺地在其他維度上退步。

所以指標需要有一個機制可以「被事實挑戰」：當事實跟指標矛盾時，不是事實有錯，而是指標需要調整，同時每個指標都要有一個對應的「反向/正向影子指標」，監控優化主指標時是否在其他地方造成傷害。

比如你在優化「偵測率」的時候，如果「誤報率」同時上升了，影子指標會告訴你，你可能只是在製造更多的噪音，而不是真的在改善偵測。

回頭審視漏洞 — 方法論不是完美的

到這裡聽起來很完整對吧？三個互鎖的迴圈，三個核心，感覺什麼都考慮到了。

但我當時追加多做一件事：回頭請 Agent 再看一次框架，用三個 Subagent 看看這三個迴圈、三個核心的整個框架有什麼漏洞。

結果 Agent 列出了七個結構性弱點，其中幾個特別值得提：

• 自我參照迴圈：所有的發現都從已知問題出發，如果已知問題本身有偏差，整個系統會朝錯誤的方向成長
• 解決驗證缺口：「檢查通過」不等於「問題解決了」，一個被標記為已修復的問題可能只是被繞過了
• 不可觀測的未知：有些問題在任何信號層都沒有痕跡，系統無論多完善都看不到
• 成本盲目：系統會持續新增檢查，但沒有機制評估每個檢查的投資報酬率

這些漏洞本身就是方法論的一部分，因為知道自己的弱點在哪，才能設計對應的防護機制。有些漏洞可以靠系統自動修復（比如解決驗證，可以設定自動回測），有些必須靠人類介入（比如成本決策和策略方向），這就自然引出了人類介入點的設計。

而且方法論不是在真空中建立的，我讓 Agent 去搜尋學術研究，找到了 33 個相關來源，其中有支持這套方法論的概念（像是 MAPE-K 自適應迴圈 [1]、Google SRE 的 error budget 模型 [2]、Netflix 的 Chaos Engineering），也有直接挑戰的反論（像是 Model Collapse 風險，也就是自我參照系統會逐漸退化、Goodhart’s Law [3]，也就是當指標變成目標時指標就會失效），這些反論不是要推翻方法論，而是讓我們知道該在哪裡加裝防護機制，像是自我參照迴圈的漏洞對應的就是 Model Collapse 的風險，影子指標的設計對應的就是 Goodhart’s Law。

人類什麼時候該介入？

但也不是所有的問題都拋給人類處理，不然就變成人類幫 Agent 打工，所以接著我用了一個很常聽到的 80/20 法則(算是挪用，因為他原本不是這個用法)來抓出第一個初步界線，我告訴 Agent，我希望系統應該在 80% 的時間能夠自我運行，但在關鍵的 20% 時間讓人類介入，因為正常來說重要需要人類的可能真的只有 20%。

從這個概念出發再讓 Agent 回頭看一次之前找到的漏洞，他就發現有些問題是可以自行修復的，比如那些需要資訊都存在於系統可觸及信號源裡的問題，像是解決驗證（可以自動回測）、時間盲區（可以加入時間維度的掃描）、檢查交互效應（可以追蹤因果鏈）等等。

他也發現真正需要人類介入的問題是那些需要外部知識或業務判斷的決策，比如嚴重度的判定需要理解業務脈絡、成本取捨需要策略層面的判斷、信號源投資需要評估是否值得花資源去建立新的觀測管道。

經過最終的估算：整個系統成熟之後，人類每月大約只要一到兩小時來處理這些介入點，其餘時間系統可以自行運轉(我覺得太樂觀，大概一週一小時差不多，但這個前提是模型沒有更厲害，如果更厲害可能真的會像他說的)。

但這邊有個要注意的：80/20 不是一開始就該有的目標，他應該是逐漸演進的結果。 初期我想像的應該是從 50/50 開始，系統自己跑一半、人類驗證一半，同時在旁邊平行補充、修正出更可靠的判斷機制（比如用多個不同的模型對關鍵決策做交叉投票，MAGI 的概念），經過一段時間，這些機制的準確率經過八次以上的循環，並驗證達到 90% 以上，才開始逐步減少人類介入，如果你一開始就強迫 Agent 設定 80/20，你等於是在系統還不值得信任的時候就已經放手了。

我在這邊也下了一個重要的設計決策：當系統偵測到異常時，不要直接 escalate 給人類，而是要先自己調查一輪。只有在調查發現自己無法處理（需要的資訊不在系統可觸及的範圍內）時，才 escalate，在這個調查過程也不單純只是調查跟修復，他必須把調查到的資料輸出，並且產生 Finding 的推測，讓人類介入時可以讀取用來判斷，或給另外一個專門的 Agent 來判斷(這個接口就是留給之後多 Agent 自主化的後路)，但這個系統我也設計了例外，這其中唯一的例外就是「系統持續被人類推翻」，因為當這個情況發生時，就代表系統現在的判斷能力(判斷基準、判斷機制)本身有問題，必須直接停下來，因為一個無法正確判斷的系統也無法正確判斷自己是否需要停下來，所以我在這邊設定了強制中止的條件讓人類介入，而非把判斷留給系統。

一路走到這裡，你應該發現：方法論不是一次性的產出，而是一個持續被挑戰和精煉的框架，有了原本的架構加上三個核心、漏洞防護、和人類介入點，我們終於有了一套可以指導 Agent 決策的原則，但具體要做什麼、用什麼工具、先做哪一個，這些是下一層 Playbook 的事。

下一篇，我們來看怎麼把方法論「操作化」成 Playbook，因為方法論再好，如果不能變成 Agent 可以照著執行的東西，它就只是一份好看的文件。

參考資料：

[1] MAPE-K — self-adaptive feedback loops in software engineering https://en.wikipedia.org/wiki/MAPE-K

[2] Google SRE: How Google Runs Production Systems — error budget model https://sre.google/sre-book/table-of-contents/

[3] Goodhart’s Law — when a measure becomes a target, it ceases to be a good measure https://en.wikipedia.org/wiki/Goodhart%27s_law

[4] 實戰 Tips 4：Agent 的時區盲點 — 隱性假設案例 /articles/16-tips-agent-timezone-blind-spot

[5] 第三篇：Context Engineering — 基於事實的信號源 /articles/3-context-engineering