Marginlab 盯上 Claude Code 漂移

Marginlab 做了一個每天跑的追蹤器。Claude Code 搭配 Opus 4.6，每天固定測 50 題。它還會做週報和月報。講白了，就是盯著模型有沒有慢慢歪掉。

這件事很實際。很多 coding agent 在 demo 看起來很猛。真的上線後，表現卻會飄。Marginlab 直接抓 SWE-Bench-Pro 的子集合來跑。它不用花俏包裝。它想看的，就是使用者真正在 CLI 裡碰到的結果。

每天到底在看什麼

這個 tracker 的核心是 pass rate。也就是 50 題裡，Claude Code 解對幾題。這個數字最直觀。你一眼就知道今天有沒有掉。

但 Marginlab 沒有只看分數。它還顯示 input tokens、output tokens、API cost、平均 runtime，還有總 tool calls。這很重要。因為 agent 出問題時，常常不是只掉準確率。

有時候它會一直試。工具呼叫暴增。runtime 也變長。這種情況下，模型可能還能解題，但效率已經變差。對開發者來說，這就是成本開始失控的前兆。

• 每天固定跑 50 題
• 每週與每月做彙總
• 用 Bernoulli trials 看 pass rate
• 顯示 95% 信賴區間
• 直接跑 Claude Code CLI，不加自製 harness

最後一點最關鍵。很多 benchmark 一包再包，最後量到的是 wrapper，不是模型。Marginlab 直接走 Claude Code CLI。這比較接近真實開發流程。說真的，這種做法比較不會自嗨。

它也有一個 degradation status panel。這裡會把樣本數和統計門檻一起放出來。不是每次掉分都算數。樣本太少時，波動本來就很大。這點比很多只會貼分數圖的頁面誠實多了。

為什麼現在要做這個

Marginlab 說，這個 tracker 是回應 Anthropic 在 2025 年 9 月的 degradation postmortem。那份說明很直接。模型上線後，表現還是可能往下掉。不是每次更新都只會變好。

這也是很多團隊最怕的事。你昨天還覺得 agent 很穩。今天突然開始多跑幾輪。或者同一題要花更多 token。這種變化不會立刻炸掉服務，但會慢慢吃掉你的成本和信心。

Marginlab 也強調自己是獨立第三方。它沒有跟 frontier model provider 綁在一起。這點很重要。因為很多 dashboard 很像行銷頁。分數一高就大吹特吹。Marginlab 比較像在做監控，不是在做宣傳。

“We want to offer a resource to detect such degradations in the future.” — Marginlab

這句話很直白。它不是在做排行榜。它是在做預警器。模型如果在 reasoning、tool use，或長任務表現上開始漂移，日更追蹤就有機會先抓到。

我覺得這種工具會越來越重要。因為 agent 的問題，常常不是一次壞掉。是慢慢變鈍。等使用者抱怨時，很多跡象早就出現了。

數字怎麼看，才不會被騙

Marginlab 最有意思的地方，在於它把樣本數和統計門檻講清楚。50 題的日測，本來就很吵。它沒有假裝每天的波動都很有意義。這種誠實很少見。

它的估算是這樣。50 題時，大約要 ±13.8% 的變化，才比較能過 p < 0.05。350 題時，門檻縮到 ±4.8%。1,400 題時，門檻只剩 ±2.3%。樣本越多，越能分辨噪音和真問題。

這對 coding agent 特別重要。因為 agent 的行為很不穩。今天可能多試幾次。明天可能少試幾次。runtime、tool calls、token 數都會晃。只看單日分數，很容易誤判。

• 50 題：約 ±13.8% 才容易有統計意義
• 350 題：約 ±4.8%
• 1,400 題：約 ±2.3%
• 日、週、月都會做聚合
• 同時看 pass rate、runtime、tool calls、token、成本

這組數字告訴我們一件事。小樣本很適合快速掃描。大樣本才適合下結論。很多團隊在內部看板只放一條分數線，結果天天被噪音搞心態。Marginlab 至少把這件事講開了。

如果拿競品來比，差異也很明顯。像 SWE-Bench 本身偏向標準化評測。OpenAI Codex 這類產品展示時，通常更強調能力與體驗。Marginlab 則把焦點放在持續監控。它問的不是「能不能跑贏一次」，而是「能不能一直維持」。

這種監控，為什麼對台灣團隊有用

現在很多軟體團隊都在把 AI agent 放進流程。寫 code、改 bug、補測試、查 issue，通通有人想交給 LLM。問題是，模型不是靜態元件。今天的表現，和下週可能不一樣。

台灣很多團隊資源不算多。你不可能每次模型更新都人工驗證一輪。這時候就需要固定的監控機制。每天跑一小批題目，配上週報和月報，至少能先知道有沒有異常。

這種做法也適合跟自家觀測系統搭配。你可以把 pass rate 當功能指標。把 token 和成本當財務指標。把 runtime 和 tool calls 當效率指標。三個一起看，比只看一個漂亮分數實在多了。

再往前想一步，這也會影響採購決策。當你要選 Claude、GPT，或其他 LLM API 時，除了價格和上下文長度，也該看它在你自己的任務上，會不會隔幾天就漂一次。這不是學術問題。這是產品風險。

我自己的判斷很簡單。未來做 agent 的團隊，會越來越像在管伺服器。不是只裝好就算了。你還要看健康度、延遲、錯誤率，還有版本變更後的差異。模型監控會變成基本功。

接下來該怎麼看這類 tracker

如果你有在用 Claude Code，我會建議先把這個 tracker 收藏起來。不要只看某一天掉分。要看連續幾天的趨勢。再對照 runtime、tool calls 和 token 數。這樣比較不會被單日噪音騙到。

更實際一點，團隊可以自己做一個小版。固定任務集。固定執行路徑。固定記錄成本和延遲。只要你有 30 到 50 題的穩定樣本，就已經能抓到不少異常訊號。

我猜接下來會有更多這種獨立追蹤器。原因很簡單。模型更新太快了。只看官方公告不夠。只看 demo 也不夠。你需要的是每天都在跑的數據。

所以問題不是「模型某次考幾分」。問題是「它下週還能不能維持」。如果你的產品真的靠 coding agent 吃飯，那這種監控最好現在就做起來。