Raindrop 加 PR 模擬，Braintrust 加 Patterns，Agent Eval 兩派開始互補

團隊在會議上說「我們該替 agent 做 eval 了」（eval，用一組資料和評分標準檢查 agent 做得對不對）。你打開兩家廠商的文件（文中的 trace 指 agent 一次執行留下的逐步紀錄，含每次工具呼叫），一邊要你先去讀正式環境的 log，一邊要你先依 agent 的架構建資料集與評分器。下表把這兩條路和第三個常被拿來接手的工具 Langfuse 放在一起，「兩派」是本篇為了比較取的簡稱，業界沒有公認的陣營。

快速回答 Raindrop 共同創辦人 Ben Hylak 主張從讀真實 log 開始，先用 5 到 10 個黃金案例守住關鍵路徑；Braintrust 主張依 agent 架構（單次呼叫、固定流程、工具迴圈到完整 harness）決定資料集與評分器。2026 年 9 月起，Raindrop 推出會重播正式流量的 PR 模擬（早期試用），Braintrust 推出自動找重複問題的 Patterns（公開預覽），兩邊開始補對方的起點。流量小、架構單純、沒有人逐筆審查輸出、也沒有難以回復的工具動作的團隊，先讀 log；改動變頻繁或有不可逆的工具動作時，再補資料集與 CI 關卡。

卡上每條結論後面附一個原作的數字或日期，各節會交代它們從哪裡來。

Raindrop 這一派為什麼從讀 log 開始？

Raindrop 共同創辦人兼技術長 Ben Hylak 主張從真實流量裡的失敗開始，因為預先寫好的測試只認得已知的問題。

2025 年 9 月 5 日，他在 Raindrop 部落格〈Thoughts on Evals〉寫道，eval 擅長防止退步，但團隊的 eval 最後會變成「a collection of issues you already know about」。他的替代方案是監控：agent 複雜到測不完，卻監控得了。LLM 評審（LLM judge，用另一個模型替輸出打分）在他筆下只是窄用途的輔助，理由是校準、成本，以及 Goodhart 定律的風險（指標一旦變成目標就會失真）。產品依使用者個人化時，他建議只留剛好夠做冒煙測試（smoke test，上線前快速確認沒有大壞）的 eval，再讓一小部分使用者先用，看線上訊號。

這是一家賣正式環境監控的公司技術長寫的主張，讀的時候要帶著這個位置。

2026 年 5 月，他在 howtoeval.com 發表〈How to Eval AI Agents: The 2026 Guide〉（頁面只標月份）。這份指南把前面的立場寫成一套順序：

• 範圍。 只談 agent，不含 classifier（分類器）、RAG pipeline 等系統。
• 路線。 他把目標分成兩種：「Benchmark maxxing is for augmenting experts. Floor raising is for agents used in-place of humans.」前者追求高分，後者拉高最差情況的下限。判斷方式是問自己，通過率 90% 和 99% 只能選一個時，第一個反應是不是「掛掉的是哪 1%」；是的話，你在做 floor raising。
• eval 集的大小。 他認為大型 eval 集常是干擾，也認為自信的錯誤答案比誠實的「我不知道」更糟。
• 出貨前。 挑 5 到 10 個代表關鍵路徑的黃金案例（golden cases），寫下來。測試要跑整個 agent，因為行為來自程式、工具與 prompt 一起運作，他稱為 code-aware evals。他不建議用託管的 eval 儀表板跑 agent eval，改用本機的簡易 HTML 頁面看通過與失敗。
• 上線後。 依每天的執行量分四級：

他對 Raindrop 自己的 Agent Self Diagnostics（讓 agent 自己回報問題的隱藏工具）評價偏低，說它比預期不好用，建議當成 Stumbles 那種「什麼都有的水龍頭」，偶爾挑到有意思的。他建議把 10% 到 20% 的 agent 開發時間花在評估與監控，並預測 harness（包在模型外面的程式與工具）會被模型吞進去，中間步驟更難檢視，端到端評估與正式環境監控會變成主要手段。

工程上的意思。 第一級只需要把完整的執行紀錄存下來並且有人讀；到了 Signals 才需要分類器和儀表板。測試放在 repo 裡、啟動真實的 agent 與工具，這比逐條 prompt 測試多一層環境準備。

Braintrust 這一派怎麼依架構決定怎麼評？

Braintrust 的答案是讓評估方法跟著 agent 架構走，因為每多一種能力，就多出一種舊評估看不到的失敗。

2026 年 5 月 21 日，Braintrust 部落格文章〈The six generations of AI agents and how to eval them〉由 Ameya Bhatawdekar 與 Tony Xu 署名。文章先定義 eval 有三個部分：資料（Data）、任務（Task，被測的系統）、評分（Scores）。文中說「evals are the TDD of AI development」，TDD 是先寫測試再寫程式的開發方式。貫穿全文的例子是一個處理告警與事故的 agent，作者逐代回答它多了什麼失敗、該怎麼量：

幾個具體設定值得記下。第 3 代的範例案例把工具呼叫上限設成 8 次。第 5 代用同一題跑多次（範例是 8 次），pass@k 看 k 次裡至少成功一次，衡量能力，pass^k 看 k 次全部成功，衡量一致性；達標條件寫成預算內成功，例如 SEV1 事故要在 10 次工具呼叫與 30 秒內解決，較輕的 SEV3 是 5 次與 0.10 美元。第 6 代把評估拆成冒煙測試、完整 trace 上的離線評估、注入失敗的模擬、對正式流量的重播與影子執行、線上評分五層；文章對這一代沒有給數字門檻。

文章收尾明說，每個團隊不必走到同一個架構：「The lesson is not that every team should end up with the same architecture.」適合的設計取決於任務、風險、模型與產品成熟度。不變的是一個飛輪：把正式環境的 trace 依失敗模式分群，轉成 eval 案例，當作上線關卡。這是賣 eval 平台的公司寫的文章，第 6 代的五層用到的功能，正好是它的產品要賣的。

工程上的意思。 從第 3 代起，評分器讀的是 trace 裡的每一步（工具選擇、參數、次數、延遲），不只是最後答案；預算變成測試裡的欄位，超過就算失敗。第 4 代起，要為每個分支準備案例，並在每次 PR 跑被改到的節點。

Langfuse 的文件怎麼同時接住兩邊？

Langfuse 的文件把離線與線上評估都列為平台功能，沒有指定哪個先做。

文件對兩者的定義很簡短：線上評估（online）對進來的即時 trace 打分，量正式資料的品質與趨勢；離線評估（offline）在發布前拿預先準備的資料集跑應用程式，確認改動可以上線。評估方式有 LLM 評審、程式碼評估、人工標註（標註佇列、介面打分或使用者回饋）等。實驗（experiments）可以並排比較 prompt、模型或程式的改動，在 CI/CD 裡分數退步時擋下部署。官方描述的循環是追蹤、監看、建資料集、實驗、評估五步，正式環境的分數餵資料集，資料集餵實驗。

資料集怎麼養，Langfuse 的指南有幾條具體建議：每個 PR 的關卡只留幾十到一兩百筆，檢查才跑得快；「100 diverse items beat 1000 near-duplicates」；把資料集當成跟著正式流量增加的紀錄，每筆標記加入日期，才看得出有多舊；測的行為不存在或預期輸出有誤時才退役，退役的案例改成封存，保留在版本紀錄裡，歷史結果才讀得懂。Langfuse Academy 的〈Choosing what to evaluate〉進一步建議把指標分成三類：

每個指標都要問「它動了以後，我會改什麼」，答不出來就是雜訊；長期維持 100% 的分數資訊量低，可以退役，護欄例外；調 prompt 去迎合指標會過擬合，所以要定期用新的人工標註重新驗證，並持續手動看一批 trace 樣本。

2026 年 7 月，Langfuse 部落格作者 Annabell Schäfer 公開了他們自己文件聊天機器人的設定。線上這一側用 LLM 評審標出使用者不同意、超出範圍或抱怨的對話，另有偵測全大寫的程式檢查，標出的對話進人工標註佇列；離線這一側的資料集混合正式環境的例子、合成例子與標註過的對話，同一份資料集也當 CI 回歸測試。文中沒有給資料集大小或告警門檻。

工程上的意思。 被標出的線上對話經標註佇列變成資料集項目，再進實驗與 CI，這一條管線讓「讀 log」和「跑資料集」共用同一份資料。

兩派在 2026 年 9 月之後各補了什麼？

先看 Raindrop。2026 年 9 月 17 日，Raindrop 宣布 A 輪融資，由 CRV 領投，總融資額 5,000 萬美元，同時推出 Raindrop Simulations。公告說它在每個 PR 上重播正式流量與既有的測試案例，對提議的 agent harness 改動做異常偵測，標出非預期的行為改變；早期試用擴大中，預計下個月正式開放。2026 年 10 月 22 日，Hylak 署名發表 Change Reports：連上 GitHub repo 後，改動合併後不久與 24 小時後各送一份 Slack 報告，比較改動前後的 agent 行為，目前提供給 Pro 與 Enterprise 方案。公告的範例是一個修復「執行結束卻沒有回應」問題的改動，報告發現仍有兩次正式環境的執行沒有輸出文字。

再看 Braintrust。它的更新日誌在 2026 年 9 月列了 Patterns（公開預覽）：依排程執行 Braintrust 內建的 AI 助手 Loop，找出目前還沒有評分器量到的重複問題與趨勢，每個發現附上相關 trace，有的話附上建議的修法。10 月日誌補上嚴重度與分類，可以修正並附理由，也能讓團隊自訂嚴重度與分類的標準。日誌只標月份，沒有標日。

把這幾筆放在一起，本篇的歸納是：Hylak 在 2025 年主張的起點是正式流量，現在 Raindrop 多了發布前的關卡；Braintrust 在 2026 年 5 月的起點是架構與資料集，現在多了從正式流量自動撈問題的功能。兩邊的預設方向沒變，延伸的範圍重疊了。這個收斂還有另一種解釋（我的推論）：Simulations 與 A 輪融資同一天公布，兩家可能各自把產品線往評估流程的另一端擴張，方法論未必有共識。這不推翻下一節的建議，因為建議看的是團隊的架構與改動頻率。兩邊對未來的看法則有出入：Hylak 預測 harness 會被模型吞進去，Braintrust 六代文的結論是「The loop is still the loop. The real product is everything around it.」，主張迴圈外圍的工程才是產品。限制也要講清楚：Simulations 在公告時是早期試用，Patterns 是公開預覽，這兩個功能在實際團隊裡的效果，我沒有查到公開的第三方資料。

流量小的團隊先讀 log，改動變頻繁再補資料集關卡

我的建議是先照 Hylak 的順序走，因為資料集需要有人先知道「什麼算失敗」，而這個答案要從真實的 log 裡讀出來。前提是 agent 架構單純，每天只有幾十到幾百次執行，輸出沒有人逐筆審查，也沒有難以回復的工具動作。這時 5 到 10 個黃金案例加一週的 log 閱讀，比一套評分平台便宜。代價是讀 log 只告訴你發生了什麼，說不出昨天改的 prompt 有沒有弄壞別的地方。當不只一個人改 prompt 與工具、每週都有改動上線，或 agent 能做刪除、退款這類回不去的動作，就補 Braintrust 與 Langfuse 都主張的那一層：資料集進 CI，改動沒過關就不合併。無論走哪一條，每修掉一個失敗就留下一條測試。

常見問題

Agent eval 要準備多少案例才夠？

沒有單一數字，看用途。Hylak 的指南建議出貨前先寫 5 到 10 個代表關鍵路徑的黃金案例；Langfuse 的指南建議每個 PR 的關卡只留幾十到一兩百筆，並指出 100 筆多樣的案例勝過 1,000 筆近似重複的；Braintrust 以單次提示呼叫的架構為例，用 50 到 500 筆。三者針對的架構與用途不同；流量小、風險低時從最少的開始，失敗一個補一個，流量或風險上來再加量。

離線評估和線上評估差在哪裡？

Langfuse 文件的定義是：離線評估在發布前拿預先準備的資料集跑應用程式，確認改動可以上線；線上評估對進來的即時 trace 打分，量正式資料的品質與趨勢。前者回答「這次改動可以上線嗎」，後者回答「現在線上的品質如何」。

做 eval 要花多少開發時間？

Hylak 的 2026 年指南建議把 10% 到 20% 的 agent 開發時間用在評估與監控，包含寫 eval、讀 trace、調 Signals、查問題。這是 Hylak 的建議值，文中沒有附實驗數據；Braintrust 與 Langfuse 的文章沒有給對應的比例。

為什麼 agent 的 eval 要看 trace，不只看最後答案？

Braintrust 從第 3 代起把評估單位換成 trace（agent 一次執行的逐步紀錄）：agent 自己決定呼叫哪些工具，失敗會出在選錯工具、參數不對、迴圈停不下來或成本暴增，單看最後答案較難發現。所以評分器要讀每一步，並把工具次數、時間與費用設成預算。

延伸閱讀

• LLM Judge 的 Yes/No 清單在成對比較最有證據，直接打分未必
• Loop Engineering 是什麼？怎麼讓 AI 自己把事情做完再叫你？（2026 實戰教學）

參考資料

• Ben Hylak, How to Eval AI Agents: The 2026 Guide（2026 年 5 月，頁面只標月份；2026-10-23 查閱） https://howtoeval.com
• Ben Hylak, Raindrop, Thoughts on Evals（2025-09-05） https://www.raindrop.ai/blog/thoughts-on-evals
• Zubin Koticha, Ben Hylak, Alexis Gauba, Raindrop, Announcing our Series A and $50M in total funding to protect the world from AI agent failures（2026-09-17） https://www.raindrop.ai/blog/series-a
• Ben Hylak, Raindrop, Introducing Change Reports（2026-10-22） https://www.raindrop.ai/blog/introducing-change-reports
• Ameya Bhatawdekar, Tony Xu, Braintrust, The six generations of AI agents and how to eval them（2026-05-21） https://www.braintrust.dev/blog/six-generations-ai-agents
• Braintrust, Changelog（Patterns、Debugger、Loop 條目，2026 年 9–10 月，日誌只標月份） https://www.braintrust.dev/changelog
• Langfuse, Evaluation overview（官方文件，頁面無日期；2026-10-23 查閱） https://langfuse.com/docs/evaluation/overview
• Langfuse, Golden dataset evaluation: build and maintain LLM test sets（頁面無日期，文中提到 2026 年 6、7 月） https://langfuse.com/resources/engineering/golden-dataset-evaluation
• Langfuse Academy, Choosing what to evaluate（頁面無作者與日期） https://langfuse.com/academy/evaluate/choosing-what-to-evaluate
• Annabell Schäfer, Langfuse, Yes, you can copy our eval setup（2026 年 7 月） https://langfuse.com/blog/2026-07-16-steal-our-eval-setup