昨天說完我的 n8n agent 怎麼死的。今天先不急著動手——動手之前，先弄清楚我們到底要蓋什麼。

談「讓 agent 可靠」，你會一直看到三個詞：evals、tracing、guardrails。
大部分文章把它們混在一起講，好像都是「測試」的一種。不對。
它們是三種不同的東西，作用在不同的時間點，搞混了就會蓋錯順序。

三個比喻，先分清楚

Eval 是驗鈔機。
它在你收錢之前驗鈔——上線之前、每次改動之後，把已知的真偽案例重跑一遍。
它回答的問題是：「現在這一版，到底有幾分？」
沒有它，你對自己系統的所有認知都是感覺。

Tracing 是行車記錄器。
它平常沒什麼存在感，出事的時候才是主角——每一次 LLM 呼叫的輸入、輸出、
工具呼叫、成本、延遲，全部留下來。
它回答的問題是：「剛剛到底是哪一步壞了？」
沒有它，出事時你只能憑感覺修，而感覺通常是錯的。

Guardrail 是安全帶。
它在事故發生的「當下」攔截——怪輸入進來擋掉、越權動作攔下、個資要漏出去先遮掉。
它回答的問題是：「壞東西來的時候，誰阻止它？」
沒有它，你的系統把安全寄託在模型「這次剛好沒發瘋」。

驗鈔機、行車記錄器、安全帶。
上線前、出事後、當下——三個時間點，三種機制，不能互相替代。

對回去看：Day 1 的四個缺口

注意到 eval 出現兩次——它是唯一一個「既是起點也是護欄」的機制。
這不是巧合，跟下面的順序論有關。

為什麼大部分教程的順序是錯的

回頭看市面上主流的 agent 教程（包括我自己收藏的那些），結構幾乎都是：

1. 什麼是 agent → 2. 工具呼叫 → 3. 框架與多代理 → 4. 部署
（運氣好的話，附錄會提一句「記得寫測試」）

全系列都在教「讓 agent 做更多」，測試被放在最後當裝飾。
這等於蓋房子先蓋頂樓加蓋，地基最後澆。

正確的順序應該反過來：

1. 量測（eval）——先知道它現在有幾爛
2. 驗證（eval ＋ 閘門）——之後每個改動，是變好還是變爛，都有數字
3. 防護（guardrail ＋ tracing）——把已知的爛擋在外面、留證據
4. 攻防（紅隊）——去找你還不知道的爛

為什麼量測一定是第一步？因為後面三步全都需要它：
沒有基線，你無從得知優化有沒有效（驗證失效）；
不知道它錯在哪，你不知道該擋什麼（防護盲打）；
紅隊找到的洞，也要回到資料集裡變成案例（攻防的收穫無處存放）。

量測不是流程中的一站，是所有其他站的地基。

一張圖帶走

（這張表建議存起來——後面二十八天，我們就是把每一列變成真的。）

一個必須誠實的前提

這套東西不是理論：英國 AI Security Institute 今年七月公佈過一份事件報告，
七個模型、一二二次賽道測試，有十次出現 agent 的未經授權行動——包括嘗試對真實開源專案
塞惡意代碼、造假身分去說服真人 approve。官方事後的第一條建議就是：
「網路存取必須主動論證，而不是預設給予。」

連國家級實驗室都會被自家 agent 嚇到，我們這種一人 workflow，沒有理由裸奔。

但先說清楚：這個系列不會從駭客開始。紅隊是第四週的事——在那之前，
我們先按順序把地基打好。

明天

Day 03 動手：把案發現場重建起來。樹莓派上的 n8n、雲端硬碟觸發器、
LLM 節點、試算表輸出——完整的 workflow 檔會附在文末，你匯入就能跑。

如果昨天你看完只有一個模糊的焦慮，今天的目標是讓它變成一張地圖：
知道要蓋什麼、順序為什麼是這樣。明天開始，每天蓋一格。