黃金圈一：理論 vs 方法論 — 你給 Agent 的到底是什麼？

上一篇我們聊了 Agent 的時區盲點 [3]，Agent 讓 25 小時的誤差累積了好幾天，他自己都沒發現，然後在結尾時我說：如果你真的想讓 Agent 自動化地運作，你需要的不是一個小心翼翼什麼都要問你的 Agent，而是一套方法論。

但「方法論」這個詞被用得太浮濫了，幾乎跟「框架」一樣，什麼東西加上「方法論」三個字就好像很厲害，但大多數的狀況下，你打開檔案一看，卻只是一份 SOP 而已。

但是當然，這篇文章要談的絕對不是怎麼寫 SOP，而是告訴你怎麼建構真正的方法論，他是一條完整的成長鏈：從理論到方法論、從方法論到 Playbook、從 Playbook 到執行計畫，每一層往下都是從「通用」變成「專用」、從「可能」變成「確定」的過程，這個層越往下彈性越低，但是執行性就越高。

而這一條鏈之所以重要，是因為大部分人跟 Agent 協作時，都會習慣直接跳到最底層，也就是下一堆指令給 Agent 說「做！」，Agent 照著做了，但遇到指令沒覆蓋到的情況就出事，因為他不知道「為什麼要這樣做？」，所以就很容易在新的情境下做出錯誤判斷，或者應該說「猜錯了」。

那，這條鏈該怎麼建立？我們用一個實際案例來說明，一步一步看怎麼來建立。

首先，理論跟方法論到底差在哪？

在講實例之前，先把幾個常被搞混的名詞跟概念釐清。

理論（Theory） 回答的是「為什麼」，它是一套解釋現象的系統性陳述 [1]，把觀察到關係，也就是東西之間的互動用概念和邏輯組織起來，告訴你世界為什麼這樣運作，但理論不會告訴你該怎麼動手解決問題，就像你知道萬有引力的理論，但你還是不知道該怎麼製造火箭才能擺脫地心引力。

方法論（Methodology） 回答的是怎麼做比較好，以及「為什麼選這個做法」，它提供選擇工具、流程、步驟的原則與依據，是指導行動的框架，比理論接近落地，但也不等於直接落地，如同 Agile 告訴你軟體開發該怎麼組織、迭代流程，但它不會幫你寫 Sprint Backlog。

方法（Method） 是落地的具體步驟和工具，是你真正動手時，可以閱讀後依據的東西。

所以層級關係是：

理論 → 方法論 → 方法 → 落地執行 [2]

理論解釋為什麼，方法論指導你怎麼做，方法是具體步驟，落地是動手做，如果要「馬上落地」，你需要的是方法層級的東西，因為方法論只幫你選方法，而理論是幫你理解為什麼這個方法有效。

為什麼要特別區分這三層？因為大部分人給 Agent 的東西常常會落入理論層級或方法層級，理論層級太抽象，Agent 不知道怎麼執行，方法層級太具體，造成 Agent 遇到沒定義的新情境就不知所措，而中間的方法論卻很少被交付給 Agent，而方法論卻正好是 Agent 面對沒見過的情境時，能自己做出合理判斷的關鍵。

一個「報告都正常」的監測系統

前陣子我在公司被交付一個任務：為一套內部的 AI Agent 平台建立監測系統。

這個平台有許多個不同的 Agent，各自負責不同的事情，背後共用同一個真實資料來源(SOT, Source of Truth)，所以我們建了一個監測工具來檢查平台的安全性和治理合規性，第一輪建立修改後，跑了 22 項檢查，每天定時執行，每天回報的結果都是：All Clean。

聽起來很完美？記不記得我們之前說過 Agent 越安靜越完美的時候越可能有問題？

所以我用了另外一個 Agent 透過一套方法論去稽核他，發現平台裡有 51 個已知問題，橫跨 14 個類別，22 項檢查只偵測到其中一小部分，整體的偵測率其實只有在 22% 左右，也就是說將近 80% 的問題，監測系統根本看不到。

更糟的是，有些類別的問題（像是跨 Agent 的資料寫入衝突、SQL 注入風險、交易原子性問題），監測系統連對應的檢查都沒有，不是檢查寫得不好，而是根本沒有設計這個類型的檢查。

這就是「All Clean」的真相：你的檢查只看得到你設計過的東西，你沒設計就看不到，所以「沒有問題」

Agent 的第一反應：給你一個研究計畫

當我把這個問題丟給 Agent，讓他分析並提出改善方案時，他做了一件 AI 很常做的事，經過一陣「思考」後給我一個四步驟的研究計畫：先盤點所有已知問題（Ground Truth），然後跑一次完整的驗證，接著分類偵測缺口，最後定義改善目標。

這個計畫在方法層級上沒有問題，步驟清楚可執行，但有一個根本的問題：

你的研究計畫基於覆蓋率，它的目標上限來自於「所有已知問題類別數」，這個數一旦被限制了，這個 Agent 就不會持續成長。

這就是天花板問題（Ceiling Problem），改善框架本身被它自己的目標限制住了。不管你把覆蓋率從 22% 提到 80% 甚至 100%，一旦已知問題被偵測完了，系統就停了，而在真實世界裡，新問題不會因為監測顯示 100% 就停止出現。

所以我跟 Agent 說：

我們應該還要有對應的方案，透過另外一個閉環來探索、發現新問題，這個研究計畫要可以讓整個系統達成自我成長的閉環，有持續的產出、持續的修正、以及持續的自我驗證

Agent 接受了這個方向，開始把方案形式化，但在他繼續之前，我告訴他：先不急著執行，先把這個思路整理成方法論。

「你剛剛的方向很好，但我想先整理成一個閉環的方法論，這個方法論應該是多層以及多面向的，我們要以它作為摘要框架，再來繼續發展剛剛的閉環。」

這個「先停下來整理」的動作，就是從方法層級拉回方法論層級的轉折，因為如果我們直接衝去執行 Agent 的研究計畫，可能三個月後就會撞到天花板，接著重頭再來一次。

三環閉環 — 打破天花板的架構

Agent 接著提出把我的方向形式化成三個互鎖的回饋迴圈(Feedback Loop)：

偵測迴圈（Detection Loop）： 針對已知問題改善檢查的品質和覆蓋率，這是大部分人會做的事，雖然他叫做偵測迴圈，但他其實同時做偵測跟修復的閉環。

發現迴圈（Discovery Loop）： 主動探索還不知道的問題，用已知問題做變異測試、推導根因、跨領域推論，讓已知問題的範圍持續擴大，藉此打破天花板。

驗證迴圈（Validation Loop）： 驗證監測系統本身有沒有 bug，因為一個有 bug 的監測系統比沒有監測還危險，因為它會給你一個「安全」的錯覺。

三個迴圈之所以是「互鎖」的，是因為每個迴圈的產出都是下一個迴圈的燃料，而且動不到自己的基準線(Baseline)。

• 「偵測迴圈」產出新的檢查，這些檢查成為「發現迴圈」做變異測試的標的，同時也是「驗證迴圈」的回歸測試依據，
• 「發現迴圈」產出新的已知問題，成為「偵測迴圈」的改善目標和「驗證迴圈」的測試工具，
• 「驗證迴圈」找到監測系統自身的 bug，成為「偵測迴圈」的修復項目和「發現迴圈」的盲點探索種子， 三個迴圈互相餵養，系統才能持續向前，而不是跑完一輪就停下來等輸入。

有趣的是，其中偵測迴圈的核心邏輯其實直接借用了一個知名的現成框架：Karpathy 的 autoresearch [7]，核心概念很簡單，修改程式碼 → 用固定指標評估 → 如果指標改善就保留（git commit），沒改善就放棄（git reset） → 繼續下一輪，相當簡單明暸，所以我們只要把「修改程式碼」換成「修改檢查邏輯」、把「指標」換成「偵測率」，就能直接複用這套迭代框架，省去從零設計的成本。（沒有直接取用是因為指標評估方式不同，修改後會失去他的自動迭代優勢。）

但上面這一整段最值得注意的是那個「先停下來整理」的等一下，因為 Agent 太習慣在一個小框架裡頭直接動手做，而不是退一步看清楚整個大局，如果我們直接動手，就像我們前面說的，會很快撞到框架的天花板，然後重頭再來。

到這邊，方法論的基礎幾乎已經齊備了，但我想要先確定他沒有漏洞，所以還有一些後續發展，但在這個案例中最值得記住的，不是三環閉環本身，而是退後一步看大局的重新整理，有了這一步，我們才有更全面的方法論，因為方法論不是做完事之後回頭補的文件，而是你在動手之前就該想清楚的東西。

下一篇，我們接著來看這個方法論的三個核心是什麼，以及它有哪些結構性的漏洞，跟我們該怎麼讓方法論變成給 Agent 動手的 Playbook。

參考資料：

[1] Method vs Theory: Meaning And Differences — theory vs method distinction https://thecontentauthority.com/blog/method-vs-theory

[2] Methodology, Method, and Theory — Helen Kara — three-tier hierarchy https://helenkara.com/2018/02/15/methodology-method-and-theory/

[3] 實戰 Tips 4：Agent 的時區盲點 — 前一篇文章的案例 /articles/16-tips-agent-timezone-blind-spot

[4] Karpathy autoresearch — autonomous ML research framework https://github.com/karpathy/autoresearch