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

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

但「方法論」這個詞被用得太浮濫了，幾乎跟「框架」一樣，什麼東西加上「方法論」三個字就感覺很厲害，結果打開一看只是一份 SOP。

但這幾篇文章要談的不是怎麼寫 SOP，而是一條完整的成長鏈：從理論到方法論、從方法論到 Playbook、從 Playbook 到執行計畫，每一層往下都是從「通用」變成「專用」、從「可能」變成「確定」的過程，越往下彈性越低，但可執行性越高。

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

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

理論跟方法論到底差在哪？

在說案例之前，先把幾個常被搞混的概念釐清。

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

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

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

所以層級關係是：

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

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

為什麼要特別區分這三層？因為大部分人給 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，讓他分析並提出改善方案時，他做了一件很正常的事，經過一陣”思考”，給我一個四步驟的研究計畫：先盤點所有已知問題（Ground Truth），然後跑一次完整的驗證，接著分類偵測缺口，最後定義改善目標。

這個計畫在方法層級上沒有問題，步驟清楚、可以執行，但我看了之後發現一個根本的問題：

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

這就是天花板問題（Ceiling Problem），你的改善框架被它自己的目標限制住了。不管你把覆蓋率從 22% 提到 80% 甚至 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