agent 退步，先查 workflow 再查模型
我現在越來越不信那種只貼 TPS 的 benchmark。
對 agent workflow 來說，真正花時間的通常不是模型吐字快 20%，是它一歪掉之後，你要不要自己進去救火。最近看到有人拿同一張 backend ticket、同一台推理機、同一套 Coder→Auditor 流程，去比 OpenClaw 2026.4.24、2026.5.7、2026.7.1，我覺得這種測法比一堆 leaderboard 有用多了。
數字先放前面。
2026.4.24，5/5 技術通過，中位 active time 大約 10 分鐘。
2026.5.7，5/5 通過，但中間更脆。
2026.7.1，只有 3/6 通過，中位 active time 大約 87.5 分鐘，而且每一輪都需要 human recovery。
看到這組數字，我的第一個反應不是「這版模型變笨了」。我比較像是在看一個系統把自己的 boundary 漏出來。
以前做過支付和風控系統，這種 pattern 很熟。單點能力看起來還行，demo 也能跑，但一進長流程就開始露餡。context 一長，handoff 一多，重試一進來，真正拖垮你的不是某一步做不到，是整條鏈開始失去可預測性。你不知道它下一次會卡在哪，也不知道 reset 之後還剩多少正確上下文。
這就是為什麼我一直覺得，agent 的 benchmark 要優先看 end to end，不要先看局部分數。
我自己會先看四件事。
- 人要不要頻繁救火。
- reset 後能不能回到正確狀態。
- review 節點有沒有把錯誤攔下來。
- 同一張 ticket 重跑三次，結果是不是還長得差不多。
這四件事只要有兩件不穩，TPS 再漂亮都只是安慰劑。
很多團隊現在的坑，是把 agent 當成一個很強的函式在接。實際上它比較像一個會漂移的 worker。你如果沒有把 queue boundary、context compaction、審核節點、error taxonomy 先切乾淨，版本一升、prompt 一改、工具順序一換，整條流程就會開始出現那種很煩的半死不活狀態。它不是直接炸給你看，它是讓你多花 70 分鐘去追一個本來 10 分鐘能結束的任務。
那 77.5 分鐘差在哪。
差在你要不要人工 reset。
差在 reviewer 要不要回頭補判斷。
差在 session 汙染之後，接下來每一步都變貴。
這種成本，傳統 benchmark 幾乎不會寫。
所以如果你最近在評估 agent 版本，建議先別急著比誰比較聰明。先拿一條真的會進 production 的 workflow 去壓。用真 ticket、真 reviewer、真恢復流程去測。最後記錄的不是模型答對幾題，是從開始到 technical approval 花多久，有幾次需要人進場收拾。
production 會不會痛，這個數字最誠實。
作者：鍵盤工人