01 假設
紙上的計畫很乾淨。Brain（我的私人知識系統）說 MCP。所以只要我用一個小小的 decorator 把每一次 MCP tool call 包起來、把 tool_name、args_hash、latency_ms、status 寫進 SQLite store，我就能看到整個系統的脈搏。從這裡延伸：用 z-score detector 抓每小時的異常、用 Gemini judge 過濾誤報、用 Telegram alerter 發出真正的尖峰。
那個沒寫下來的隱含假設是——MCP 是大門。只要有流量，它就會以 MCP tool call 的形式存在。Modeling 層暖機完之後，我預期會看到每天 30 到 60 筆事件。足夠 signal 做正事。
02 建置
五個小模組，每個只做一件事。我把它們部署到 EC2、用一條 15 分鐘 cron 串起來。Pipeline 長這樣：
端對端 latency 大約 33ms / 筆。Health 很容易讀：cron 上次執行時間、列數、judge call 成功率。全綠。
03 部署
異常偵測在冷 pipeline 上統計上沒意義——樣本太少 z-score 會狂飆。所以我把 readiness 切成三個明確的階段，每一階段行為不同：
第 14 天到了。Pipeline 進入 READY。Cron 每 15 分鐘準時跑。Health check 全綠。所以我做了一件第一天就該做、卻沒人——包括過去的我——想到要做的事：問那個顯而易見的問題。
我們實際收到的資料，是不是當初說好要收的那份資料？
04 稽核
我數了監控系統觀察那段時間裡，Brain vault 內檔案異動的次數，再對照監控 DB 實際抓到了什麼。
監控看到的 vs. 實際發生的。
0.22%
Pipeline 在跑。Pipeline 是健康的。Pipeline 幾乎什麼都沒看到。
Brain 99.78% 的真實流量根本不從 MCP 進來。它從 Telegram bot 進來，或從內部 REST handler直接呼叫核心函式進來——bypass 掉我 instrumentation 所在的 decorator 層。MCP 大門只是三道門裡的一道，而且看起來是最少人走的那一道。
05 歸因
落差一旦看見，下一個問題就是漏點到底在哪裡。我目前有三個還活著的假設；root cause 還沒完全收斂。
- H1 Decorator 在執行中的 process 沒生效。 Instrumentation 包的是 MCP 層的 entry point。如果 runtime 先 import 了未包裝的模組——Python import 順序很脆弱——decorator 就會悄悄地沒套上。沒 error，沒 log line。
- H2 GHA deploy 沒重啟長駐 service。 CI 把新 code 推上去，但 EC2 上的 systemd unit 沒被 restart。新的 decorator 在硬碟上，舊的 process 還在記憶體裡。這個問題會一直咬到下一次重開機。
- H3 MCP 流量本來就低。 Brain 的互動大多走 TG bot 跟 REST。MCP 是留給 Claude Code session 用的——比我以為的還少見。如果是這樣，那「監控沒問題，它只是看著最安靜的那道門」。
06 決策
我原本的下一步是用抓到的資料跑一場 BQML TimesFM benchmark——把 zero-shot foundation model 跟我的 z-score baseline 比一比。每天 ~4 筆事件，這場比較統計上沒意義。所以我在同一個小時內做了三個決定：
07 核心反思
我蓋的東西全都正常。Decorator 33ms 跑完。Detector 算得出來。Judge 會回。Alerter 會送。Pipeline 沒有一個環節壞掉。
但它不重要，因為底下的假設錯了，而我所有的 health check永遠不會告訴我。Health 告訴你「機器有開」。Coverage 才告訴你「機器有對著正確的東西」。
自動化系統必須跑 14 天涵蓋率稽核，不只是 health check。『有在跑』 ≠ 『有在做事』。
對一個正在運作的系統來說，最難的不是加東西——而是去問「已經有的東西，是否真的指向現實」。我現在把這件事當作每一套自動化系統的硬性 14 天交付物，跟 build 本身並列：一個數字、一個驗證日期、以及如果數字不吻合就把專案砍掉的意願。
那個動作，才是真正困難的地方。