這篇文章回顧的原始事件發表於 2026 年 10 月 18 日。掘金作者「小番茄程序猿」貼出了一系列文章的第五篇，用 Java 17、Spring Boot 3.4 與 Spring AI，在單機筆電加 Docker 的環境裡，分六個階段實測 AI Agent 落地時的工具呼叫、RAG、MCP、評測與可觀測機制，每個數字都標明了出處。

先把這則消息講清楚。這篇實測的核心結論是：把大模型當成一個延遲高、會產生幻覺、按 token 計費的下遊服務，後端工程師熟悉的超時、重試、限流、快取、熔斷這些老手藝可以直接搬過來用。作者量到一次模型問答平均要 4.7 秒，加上工具層的本快取與自製熔斷器之後，編排層的 p95 延遲從 836 毫秒降到 12.34 毫秒，快取命中率 97.7%。這些是作者自建環境的實測數字，屬於個人實驗紀錄的證據層次，還原條件和你手上的環境不同，數字就會不同，引用時值得留一分保留。

看懂「先懷疑量具，再懷疑系統」這句話

整篇實測裡最值得一般人記住的，是作者談評測時的態度：三路評測互相比對，先懷疑量測工具，再懷疑裁判，最後才懷疑系統本身。作者也誠實揭露了一個「指標假象」：召回率看起來 83%，其實 hit@1 與 MRR 都是滿分，precision@4 的 0.55 是量測口徑造成的。

這種態度用在健康資訊上也成立。看到一個驚人的統計數字時，先問它是怎麼量出來的、量的是誰、口徑是什麼，再決定要不要相信結論。我們先前聊過類似的判讀方法，例如那篇把用臉部照片預測生存機率的 AI 新聞拆開來看的方法，同樣是先問研究說了什麼、沒說什麼。

跑實驗的你，身體也在跑

這類「全部數字可重現」的實測文，讀起來有種想馬上動手照做的魔力。但照做的過程，往往是一次 Docker 環境沒起來、重跑一次、看 log、改參數、再跑。作者自己也是這樣走過六個階段的，文章裡那些 42.8 秒的複合問題實測背後，是反覆的等待與盯著終端機看輸出。

盯著壓測數字跑的時候，有幾件事可以順手照顧自己。終端機的字體調大一些，深色背景配高對比前景，比小字白底省眼力。等待 k6 或模型回應的空檔，剛好是站起來倒杯水、讓眼睛看遠處的節奏點，不用等實驗結束才休息。這和我們在一直盯著螢幕翻截圖的你，眼睛還好嗎那篇聊過的原則一樣：把休息綁在系統的等待時間上，比靠意志力記得休息容易得多。

數字很迷人，但別讓它喫掉你的睡眠

「p95 從 836 毫秒降到 12.34 毫秒」這種數字有種讓人想再調一輪參數的引力。特別是晚上，改一個參數、重跑一次壓測只要幾十秒，很容易就「再跑一次就好」到半夜。

一個實際的做法：動手前先幫這輪實驗設一個截止時間，時間到就存檔收工，把沒跑完的留給隔天。實驗不會跑掉，數據隔天看往往還更清楚。如果你已經連續幾天為了追一個技術問題晚睡，白天開始覺得疲倦、注意力飄、情緒容易煩，這是身體在跟你回報，不是效率問題。若睡眠失調持續超過兩週，或出現胸悶、心悸等持續的身體不適，值得找家醫科或睡眠門診談談，先跟醫師說清楚你的作息型態，比自己硬撐好。

收在這裡

這篇實測文的價值在於誠實：作者把指標假象、量具問題都寫出來，沒有只給漂亮的結論。讀這種文章的你，不妨把同樣的誠實也用在自己身上。實驗數據可以慢慢調，你的眼睛和作息是這輪實驗裡唯一不能重現的環境。