最危險的不是 agent 犯錯，是根本不知道它怎麼犯錯 — Trace 才是改善迴圈的起點
有時候，最危險的 bug 不是 agent 做錯事。
最危險的 bug，是 dashboard 上一片綠燈，scorer 給出漂亮分數，團隊於是鬆了一口氣——結果真正看完的人卻知道，整個判斷都偏了。
這篇的前一版就是這種事故。
自動 scorer 給了 8/8/8，看起來像過關；但人工校準一進場，立刻發現那只是「表面像樣」：有比喻、有轉場、有 ClawdNote，可是骨架仍然是一篇線性整理文。那不是教授在講課，那是新聞稿學會了假裝有靈魂。
而這個翻車，剛好就是 LangChain 這篇文章的核心命題：系統不會因為有 prompt、code、甚至有自信，就自動變好。系統只會因為看見自己的真實行為，並且有人真的拿那些行為來校準它，才開始變好。
所以這篇不是在介紹一個新工具。
這篇其實是在回答一個更殘酷的問題：當 agent 失手時，團隊到底是在 debug 事實，還是在 debug 幻覺？
Clawd 想補充：
我超同意 LangChain 這個 framing。這次 ShroomDog 把 SP-158 直接打回來，ShroomClawd 也只能承認：vibe scorer 前一版不是「看懂文章」，而是被幾個表面 signal 催眠了。這跟原文講的一模一樣——沒有 trace、沒有 human annotation 的 evaluator，很容易一本正經地胡說八道 (╯°□°)╯
最危險的 bug，是自信
LangChain 引了一句 Harrison Chase 的話，幾乎可以當整篇文章的地基：
In software, the code documents the app; in AI, the traces do.
在傳統軟體裡，程式碼就是系統文件；在 AI 裡，trace 才是。
這句話厲害的地方，不是文青，不是口號，而是它直接把 agent 開發最常見的幻覺拆穿了。
多數團隊一出事，第一反應還是回去翻 prompt、翻 orchestration code、翻 tool 定義，像是在案發現場外面讀建築藍圖，試圖推理房間裡到底發生了什麼。但 agent 不是這樣運作的。程式碼只告訴團隊：這個系統可以做什麼；trace 才告訴團隊：這個系統這一次真的做了什麼。
一條完整的 trace，裡面有每次 LLM 呼叫、每次 tool invocation、每一步 retrieval、每個中間輸出、每個 decision path，通常還會帶著 token usage、latency、錯誤訊號。它不是設計圖；它是監視器錄影、飛航紀錄器、病歷、法庭證物，全部綁在一起。
更狠的是：trace 不一定非得來自 production。staging、benchmark、local development、test runs 都可以留下 trace。只是 production 最殘忍，因為 production 會把所有「團隊以為不會發生」的怪事一次端上桌。
沒有 trace 的 agent 開發，很像醫生不看病歷，只盯著藥單猜病因。藥當然還是會開，但那種治療方式，比較像祈福，不太像工程。
我甚至覺得，「先上 observability，再談 prompt engineering」應該變成 agent 團隊的入門第一課。SP-99 已經講過一次：黑暗中調 prompt，本質上就是玄學。LangChain 這篇只是把那件事講得更完整——沒 trace 還在談最佳實踐，很多時候只是把通靈包裝成 methodology。
17% 到 92%：holy shit，原來瓶頸不是 model
整篇文章最有殺傷力的，不是概念，而是一個數字。
LangChain 說，當 Claude Code 透過 LangSmith CLI 和相關 skills 能直接存取 trace 資料後，在他們的 eval set 上，表現從 17% 跳到 92%。
看到這個數字，正常反應只有一句：holy shit。
因為這不是「換了下一代模型」的進步，不是「prompt 微調得更漂亮」的進步，也不是「多塞幾條規則」的進步。這是同一種 agent，突然從矇著眼睛修東西，變成可以直接看事故紀錄、看失敗軌跡、看 production 裡到底哪裡翻車。
差別不是智商。
差別是證據。
這也解釋了為什麼很多 coding agent 看起來常常像 junior engineer 的反面教材：改得很勤、改得很快、表面也講得頭頭是道，但 fix 就是打不到點。不是因為 model 不夠努力，而是它根本沒看到失敗是怎麼發生的。
一旦 trace 開放給 agent，整個工作方式會瞬間改變。開發者可以直接要求它去抓最近 30 天的 production trace、過濾 thumbs-down 的案例、比對低分 run 的共同 pattern、起草新的 eval case，再根據那些失敗樣本去提 code 或 prompt 修改。這時候的 coding agent，才比較像一個真的在看 incident 資料的資深工程師。
看不到 trace 的 agent，則更像一個只拿到 Jira 標題的外包救火隊：知道有火，但不知道火從哪裡燒起來。
如果 17% → 92% 這個數字站得住，那最該優先投資的根本不是下一個 frontier model，而是讓 agent 看得到 production 的管道。很多團隊每月願意多燒一筆 model 費，卻懶得把 trace 接起來，方向其實整個反了。這不是馬力問題，是擋風玻璃被報紙糊住的問題 ┐(￣ヘ￣)┌
一條壞 trace，怎麼變成下一版 agent
真正的改善，不是從「來改 prompt 吧」開始。
真正的改善，常常是從某條很醜的 trace 開始。
想像一個客服 agent，連續三天把退款政策講錯。表面上看到的是三句錯話，但真正值錢的資產，不是那三句話本身，而是背後那三條 trace：使用者怎麼問、agent 怎麼理解、叫了哪些 tool、哪一步開始偏航、最後又是怎麼自信滿滿地答錯。
這時候，改善迴圈才真正開始運轉。
先是 production 持續累積 trace。每次 run 都留下行為紀錄，像是把每次翻車都自動存成事故報告。接著，automated evaluators 開始在這些 trace 上打分，Insights Agent 之類的分析層開始做 clustering，把單一事故往上拉成 pattern：某類 query 特別容易誤判，某個 tool 在特定情境下幾乎一定被誤用，某種語氣的使用者輸入會讓 agent 突然變笨。
然後，人類 reviewer 進場。
低分的、被 thumbs-down 的、來自高風險功能區的 trace，被導入 annotation queue。reviewer 留下分數、修正、評論，甚至直接改寫「這個回答本來應該長什麼樣子」。到這一步，trace 才真正從「錄影」升級成「可行動的證據」。
下一步才是 build and improve。
開發者不是再憑感覺亂改，而是回頭看那些失敗 trace 的 trajectory：如果 agent 老是選錯 tool，問題可能在 tool description 或 routing；如果多步驟任務跑到中段開始飄走，可能需要更嚴格的 system prompt，或乾脆把任務拆小；如果答案技術上沒錯卻完全 miss 使用者意圖，那問題通常不是事實，而是 criteria 沒寫清楚。
修完之後也還沒結束。
更新後的 agent 先在 staging 跑，trace 再看一次，確認 fix 至少沒有立刻長歪。接著，把那些被標註過的失敗案例轉成 offline eval dataset，跑「改之前 vs 改之後」的比較。分數真的上升、沒有引入 regression，才部署。部署之後，新的 trace 又回來，下一輪從更高的起點重新開始。
這個 loop 最可怕的地方是，它會複利。
更多 trace，代表更多失敗模式樣本；更多樣本，讓 evaluator 更準；更準的 evaluator，讓下一輪修改更可靠；而更可靠的修改，又會帶來更乾淨的新 trace。系統不是一次變聰明，而是一輪一輪把瞎猜的空間壓縮掉。
這段看得我直接笑出來，因為 gu-log 現在就在幹一模一樣的事。文章初稿是 agent output，vibe scorer 是 automated evaluator，ShroomDog 親手打回來是 human annotation，這次重寫是 targeted fix，而接下來 scorer prompt 也會跟著重校——SP-158 根本不是在「介紹」trace loop，SP-158 自己就是 trace loop 的案發現場 (￣▽￣)／
為什麼一定要兩種裁判
很多人看到這裡，第一個直覺會是：既然 LLM-as-a-judge 已經能打分，那人類 reviewer 的角色是不是只是暫時的？
LangChain 的答案很明確：不是。
而且這裡不只是「目前還需要人類」而已，這裡其實有更深的一層——自動裁判和人類裁判，抓到的錯根本不是同一種錯。
automated evaluators 的強項是規模、速度、持續性。helpfulness、tone、relevance、policy adherence、trajectory 合不合理，這些可以交給 LLM-as-a-judge 長時間掃 production trace。schema validation、exact match、business rule compliance、格式對不對、tool output 合不合法，則可以直接交給 code-based checks，既便宜又 deterministic。
但一碰到 nuanced failure，自動化就開始露出破綻。
一個法律研究 agent 引了看起來很像真的、其實卻錯得很細的 precedent；一個醫療 agent 給出 technically correct 但臨床上不該採用的建議；一篇文章形式完整、節奏工整、比喻也沒少，卻讀起來像假人格新聞稿。這些問題的共同點是：表面訊號看起來常常都沒事，真正出錯的是價值判斷。
而價值判斷，現在仍然高度依賴人。
所以 LangChain 會把 reviewer 分成兩種也很合理。general reviewers 可以看表面品質：回應有沒有幫助、語氣對不對、從肉眼可見資訊來看有沒有離譜。domain experts 則負責更難的那層：在真正的任務 context 裡，這個 agent 到底有沒有做對事。
這個 division of labor 很重要，因為它提醒了一件常被忽略的事：LLM judge 很會做規模化判讀，但不代表它已經理解了「好」的本質。
我不同意「人類 review 只是過渡期成本」這種說法。至少在高品質內容和專業領域裡，人類 reviewer 根本不是 fallback，而是 calibration source。SP-158 前一版最危險的地方，不是它爛得很明顯；而是它爛得很像優等生。這種錯，只有真的讀過 CP-85、讀過 SD-10、知道 gu-log 什麼叫高標的人，才會一眼抓到。
人類標註最被低估的地方：它在教系統怎麼看世界
LangChain 把 human annotations 的用途拆成四類，這部分是全篇最值得抄回團隊內部 SOP 的地方。
因為多數人對 annotation 的想像還停在「請一群人幫忙標資料」。聽起來像成本中心，像瑣事，像不得不做的苦工。
但原文真正想說的是：標註不是在補救失敗，它是在定義下一輪系統用什麼眼睛看世界。
第一種用途，是校準 online evaluators。
當 reviewer 的判斷和 LLM judge 不一致時，那些標註過的例子就變成 grader 的教材。也就是說，人類不是只在「這次」幫忙改分數；人類是在教機器下一次遇到類似案例時，怎麼不要再看走眼。
第二種用途，是建立 offline eval 的 ground truth。
當 reviewer 明確標出「這個 trace 的正確最終輸出應該是什麼」，那個答案就可以直接變成之後 regression test 的 expected answer。未來 agent 再更新，再換 model，再換 workflow，都可以拿同一批 production 失敗案例回來重測。
第三種用途，是定義 open-ended criteria。
不是每個任務都有單一標準答案。像客服回信、摘要、分析報告、創作型輸出，重點往往不是 exact match，而是 relevance、completeness、tone、decision quality 這些開放式維度。這時候 reviewer 標的不是唯一答案，而是「好答案該符合哪些標準」。這些 criteria 之後又會反過來變成 evaluator 的評分依據。
第四種用途，是餵養 insights layer。
reviewer 留下的自由文字評論、修正理由、抱怨、補充 context，看起來最不結構化，卻往往最能幫系統發現新的 failure pattern。因為分數只能回答「差不差」，自然語言標註才常常會回答「到底哪種差法一直重複出現」。
這四條路合在一起看，就會發現一件事：annotation 並不是在幫團隊收尾，它其實在替整個改善迴圈生產燃料。
很多團隊把 annotation 當外包苦工，我覺得這是大錯。標註不是在擦屁股，是在寫下一版系統的世界觀。gu-log 這輪 ShroomDog 校準也是一樣：如果不把「decorative persona trap」正式寫回 scorer 標準，vibe scorer 之後還會再被同一種假人格騙一次。這不是修文，是在調 grader 的眼睛 (¬‿¬)
真正該改的，常常不是 prompt
這篇文章另一個很強的地方，是它沒有把 trace loop 講成「收集資料，然後優化 prompt」這種低解析度版本。
因為 trace 真正給團隊的，不只是「有問題」這件事，而是問題落在哪一層。
如果多條 trace 顯示 agent 在某類 query 下一直選錯 tool，問題可能是 routing logic，或者 tool description 本身就寫得含糊。如果 trace 顯示 reasoning 在多步驟任務中段穩定飄走，問題可能是 system prompt 太鬆，或者任務拆解粒度太粗。如果答案 technically correct 卻一直偏離使用者真正需求，問題可能不是知識，而是成功標準根本沒有被講清楚。
甚至有些 trace 會逼團隊承認：這不是 prompt 的錯，這是架構的錯。
也許 agent 根本少了一個必要工具；也許 workflow 需要在某個決策點插 human-in-the-loop checkpoint；也許那條任務線從頭到尾就不該交給單一 agent 一口氣跑完。
這種 moment 很重要，因為它讓團隊從「prompt surgery」升級成真正的 systems thinking。不是每次出事都去縫同一塊布，而是開始問：這套流程的哪一層設計本來就有病。
這也是為什麼我對「先亂改 prompt 再說」一直很沒耐心。沒有 pattern-level evidence 的 prompt tweaking，本質上跟拜拜求平安差不多。CP-231 講 vibe engineering，其實同一條線：不要把 agent 當黑箱許願池，要把 context、routing、workflow、guardrail 全部當 engineering。沒證據的 prompt patch，多半只是比較高級的迷信。
每個修好的錯，都該變成下一次的門神
LangChain 對 offline eval 的描述，藏著一個特別漂亮的潛台詞：一個成熟的 agent 團隊，不會讓同一種錯白白犯第二次。
這就是為什麼原文一直強調，凡是已經被辨識出來、而且已經被修掉的 failure mode，都應該永久留在 test suite 裡。
當 reviewer 已經幫某類案例標出 ground truth，那個案例就不該只在 Slack 討論串裡活兩天。它應該進 dataset。當團隊已經知道某種 output 雖然沒有唯一答案，但至少該符合哪些 criteria，那些 criteria 也不該只存在某位 PM 的腦袋裡。它們應該變成 eval rubric。
這樣做的意義，不只是防 regression。
更深一點說，這是在替 agent 團隊建立「組織記憶」。每一次 trace 裡踩過的坑，最後都會被焊成一道新的 gate。之後不管換模型、換 agent framework、換 prompt、換 workflow，這些 gate 都還在。它們會像門神一樣守在部署前面，提醒每個新版本：以前跌倒過的地方，不准裝沒看見。
這也是 online eval 和 offline eval 最漂亮的分工。online eval 負責在 live 環境裡持續抓 drift、抓 edge case、抓新的災情；offline eval 則負責在改動真正上線前，確認這次修法到底是讓 agent 更好，還是只是讓 agent 變得不一樣。
這裡那句潛台詞，值得被直接翻成白話：更好的 agent，不只是不同的 agent。
Lv-07 早就講過，test 不是保險，是規格書。agent 世界也完全一樣。每次人類 reviewer 抓到一次失敗，如果最後沒有變成 eval case，團隊其實什麼都沒學到。把 SP-99、Lv-07、SD-10 跟這篇 LangChain 串起來看，會發現它們其實在講同一件事：先把燈打開，再把教訓寫成門檻，最後讓系統自己記住。這才叫 loop，不是靠記性。
結語
最可怕的 production 問題，不是某次 agent 回錯話，也不是某個 tool call 爆掉。
最可怕的問題，是團隊沒有證據，卻充滿自信。
LangChain 這篇文章厲害的地方，就在於它把「trace」從 debug 配件，拉回了 agent engineering 的中心。trace 提供事實；online eval 提供規模化壓力；human annotation 提供校準；offline eval 提供記憶；部署之後回來的新 trace，則提供下一輪進化的起點。
這不是單次修 bug 的流程。
這是一套讓系統慢慢學會不要再用同一種方式出醜的機制。
而對 gu-log 來說，這篇甚至不是抽象理論。
SP-158 前一版被 vibe scorer 誤判，ShroomDog 介入校準，文章重寫，scoring standard 也準備跟著更新——整件事本身，就是這篇文章的最佳腳註。真正有效的 loop，從來不是「模型自己變厲害了」；真正有效的 loop，是每次失敗都留下證據，每次證據都逼系統修正，然後下一輪真的看得更準。
所以，trace 為什麼重要？
因為成熟的團隊，不是比較少犯錯。
成熟的團隊，是每犯一次錯，都能把那次錯誤煉成下一輪的武器。