如何用 AI 分析 Agent traces? 持續改進 Agent 產品

做 AI agent 產品最不性感、卻最重要的工作之一，就是讀 traces。一條複雜 agent 的 trace 動輒幾十上百輪，裡面藏著工具呼叫、推理步驟、跟 prompt 的來回。過去大家都靠肉眼一條一條掃，掃到眼花，而且根本掃不完。

先搞懂: 一條 agent trace 長什麼樣

如果你還沒實際翻過 agent 的 trace，先建立個畫面。一條 trace 就是 agent 處理「一個使用者請求」的完整紀錄: 從使用者問了什麼，到它最後回了什麼，中間每一步都被記了下來。而 agent 很少是單純的一問一答，它會推理、規劃、呼叫工具、看結果、再決定下一步，一路跑到收工。

這些步驟在 trace 裡是一層層巢狀的 span: 最外層的 root span 是整個 agent run，底下掛著一個個子 span，每次 LLM 呼叫(推理)、每次工具呼叫(搜尋、計算、查資料庫)都是一個 span。每個 span 還記著自己的輸入、輸出、花了多久、用掉多少 token、有沒有報錯。把父子關係攤開，大概長這樣:

重點是: 這東西的資訊量很可觀。一段對話跨個好幾輪，可能就是幾十上百個 span、好幾 MB 的資料。Adam Lucek 講得好: 「trace 資料這年頭簡直貴如黃金，前提是你得知道拿它做什麼。」難就難在後半句，而那正是這篇要談的。

為什麼 agent 這麼難搞? 因為它跟傳統軟體很不一樣: 輸出是非確定性的、對 prompt 的一點點改動都可能很敏感、又得接受沒有邊界的自然語言輸入。講白了，你不會知道 agent 會做出什麼，直到它真的上線、跑給真實使用者。於是除錯的方式也跟著變: 從「讀程式碼、找邏輯錯誤」，變成「分析 trace」，你要抓的不再是某一行程式寫錯，而是推理出錯、工具用得很沒效率、決策品質不好這類問題，這些在程式碼裡根本看不出來。

2026 年一個很明顯的趨勢是: 乾脆讓 agent 來讀 agent 的 trace。LangChain 把這件事叫做「agent 改進 agent」。小編最近把 LangChain、FutureSearch、Raindrop 還有 Shreya Shankar 幾篇放在一起看，發現關鍵的分歧其實是: 這個讀 trace、找問題的「質性分析」，到底要交給誰的 agent、在什麼時間點做。

讀 trace 其實就是 error analysis，也就是「看你自己的資料」，這是做評估的地基。問題不在於要不要做，而在於人工讀根本沒辦法規模化: 一個團隊一天可能就產出幾千上萬條 trace，沒有人讀得完。所以生產環境的 agent 監控，跟傳統軟體監控很不一樣: 你沒辦法每一筆都細看，只能把「最值得看的子集」送進一套結構化的審查流程，讓 LLM 自動跑品質評估，再從中跑線上評估、偵測已知的失敗、探索還沒發現的問題、把好例子加進資料集、或是觸發人工審查。

而且這件事的回報，遠不只是「抓 bug」。LangChain 的 Viv Trivedi 點得很準: 不管你想做 harness 工程、寫評估、換模型還是後訓練，這些改進 agent 的手段，幾乎全都在「先把 trace 蒐集起來、讀懂」的下游。換句話說，「先出一個 v1 → 打開 tracing → 讀懂 trace 和錯誤 → 做實驗 → 再循環」就是 agent 開發的主迴圈。所以真正的問題變成: 這個迴圈裡最累的「讀懂」這一段，能不能交給 agent?

迴圈裡最吃功夫的，就是「讀 trace、判斷哪裡出錯」這個質性分析的環節。目前小編看下來，有三種不同作法:

① 帶你自己的 coding agent 去讀

這條路的精神是: 不另外養一個分析 agent，而是把 trace 接到你本來就在用的 coding agent(通常就是 Claude Code)，讓它幫你讀。

FutureSearch: 一次深讀一條 trace

最省事的版本是 FutureSearch 分享的 這篇。作者說他花很多時間在讀 agent 的 trace，一半是為了知道怎麼改進 agent，一半是為了確認「跑出來的評估到底能不能信」。

他們的 trace 存在 Langfuse，而所謂「接給 Claude Code」其實樸素到不行: 直接把一條 Langfuse 的 trace 連結貼進去，下一個 review this trace: <Langfuse 連結> 指令就開工了。背後是一個自訂的 /review-agent-trace skill，裡面放滿常見失敗模式的範例，外加「怎麼形成假設、怎麼跑快速實驗來驗證」的指引。他們把要找的問題分成四大類，蠻實用的:

1️⃣ 鷹架程式碼(scaffolding)的 bug: 系統 prompt 設定錯、agent 在某些條件下莫名其妙就停了

2️⃣ 工具失效: 搜尋回傳一堆亂碼或無意義的結果

3️⃣ prompt 引發的問題: 框架太狹隘、指令互相衝突

4️⃣ 推理失敗(最難): agent 搞混日期、亂呼叫工具、漏掉任務的一部分

最有意思的，是模型代差帶來的質變。他們早期用 Sonnet 3.7 時，得把分析拆成數十個很狹隘的 prompt，套到每一個 ReAct 步驟上，又貴又脆弱，還是會漏掉一堆;而且 Sonnet 3.7 太容易相信 agent 的自我評估，agent 說「好，我找到答案了」它就信了。換成 Opus 4.6 驅動的 Claude Code 之後，一個 session、一段通用的 prompt，就能把整條 trace 從頭吃到尾，不需要人工切割，而且「真的能動」。更厲害的是這個 skill 不只挑錯，還會自己形成假設、跑實驗來驗證: 抓到可疑的問題後，它會去模擬一個改過的 prompt 跑跑看，確認真的能修好，才把建議交出來。

那這份報告長什麼樣? 文章貼了兩個實際的輸出。一個是 agent 該查 Google 卻沒查，導致它沒注意到美伊局勢升溫;Claude Code 不只指出這點，還追到根因(這是 Opus 4.6 在 effort = low 下的通病)，並給出具體的修法(把 effort 調到 medium 就好)。另一個更能看出它的「實驗精神」:

還有一點很值得提: 維護成本幾乎是零。他們在 skill 裡順手寫清楚「去哪裡拿 trace、agent 的實作在哪幾個 Python 檔、評估任務的標準答案在哪」，省得 Claude Code 每次重新摸索;再配一份 CLAUDE.md，鼓勵它「發現哪條指令過時了就自己更新 skill」，等於這個分析工具會自我維護。

ihower 自己寫的 trace 分析 skill: 生產規模的取樣審查

那如果要上到生產規模、一天好幾千條 trace 呢? 不必換成大平台，自帶 agent 這條路一樣能做，只是得先解決一個問題: 該看哪些? ihower 自己就手刻了一個這樣的 trace 分析 skill，用 Braintrust 的 bt CLI 把 trace 拉出來，小編借來當第二個案例。生產流量一大，就不可能每筆都讀，重點是把「最值得看的子集」送進結構化的審查。它用三種取樣訊號互補:

• 🚩 明確的壞訊號: 被護欄(guardrail)攔下的、使用者倒讚的、出現 error 的、工具呼叫爆量的、對話超過 N 輪的，這些全部撈進來看
• 🤖 judge 篩選: 用便宜的模型挑出可疑的，例如已知失敗模式的 judge、情緒 / 風險的 judge
• 🎲 隨機基準: 再隨機抽一定比例，才看得到那些「沒觸發任何訊號」的隱性問題，不會被訊號本身的偏誤綁住

skill 裡把這寫成一套加權抽樣規則: 全部 error 加全部 guard 都看，高互動輪數的隨機抽 75%、中互動抽 50%、基準流量只抽 15%。背後的邏輯是: 稀有但高風險的全看，高互動代表高資訊量所以多看，剩下的用隨機覆蓋。用比例(而不是固定條數)，抽樣量會隨流量自動縮放，審查量就跟著訊號密度走。取樣完再把樣本分組、切片，一個子 agent 讀一片，最後合成一份報告。

而這份報告刻意用一套固定骨架，讓每次跑出來的報告都能直接比較:

其中有一條規矩很關鍵: 事實與推論要分開標，別把「樣本裡直接看到的」跟「我推測的」糊成同一句。

編按: 這種「依流量決定怎麼看」的思路，Raindrop 共同創辦人 Ben Hylak 在 howtoeval.com 整理成一條階梯: 一天十來條時直接全讀;量一大就得讓系統告訴你哪些值得看，從 Stumbles(在原始紀錄裡撈苗頭)→ Issues(重複出現的就立案)→ Signals(值得長期監控的行為)→ Experiments(改完用真實流量做 A/B 驗證)。ihower 的加權取樣，就是這條階梯高流量那一端的具體做法。

② 執行時: 讓 agent 自己診斷自己

第二種位置更前面，前到 agent 還在跑的當下。Raindrop 的另一個功能 Agent Self Diagnostics 就是這個想法。小編必須說，這是這輪看下來最有創意的一招: 大家都在想怎麼「事後把 trace 讀懂」，Raindrop 反過來問「那不如讓 agent 在當下自己講」。背後的觀察蠻反直覺但很對: 「現在的 agent 比以前聰明太多了，它們往往比我們更清楚自己哪裡壞了。」

所以與其等事後有人(或有 agent)去翻 trace 才發現問題，不如讓 agent 在執行過程中自己回報故障，預設分成四種信號: 缺少上下文、工具重複失敗、能力缺口、任務徹底失敗(也能自訂)。

機制其實很乾淨，而且回答了一個容易誤會的問題: 這不是平台另外派一個 agent 來分析你，而是你自己那個 agent。你用 Raindrop SDK 把模型呼叫包一層(raindrop.wrap(ai, { selfDiagnostics: { enabled: true } }))，SDK 就會偷偷塞一個隱藏工具(預設叫 __raindrop_report)進你 agent 的工具清單，連 system prompt 都不用你動。照 官方文件 的說法: 啟用之後，SDK 會塞進一個隱藏工具，當 agent 撞上無法復原的問題時，它會靜默呼叫這個工具。每個信號類別，本質上就是給這個工具的一段描述(「什麼情況該回報 missing_context」)，你的模型在跑的當下自己判斷卡在哪、靜默呼叫這個工具，SDK 再把信號(類別 + 一段它自己寫的白話說明，綁在同一個 eventId 上)送回 Raindrop。所以這裡的「智能」，就是你的底層模型在讀那幾段工具描述、對自己的處境做第一層分類，不需要另一個分析模型。回到 Raindrop 之後，平台才負責跨多次執行的彙總、分群、追趨勢、告警。

換句話說，Raindrop 在這裡做的是分散式的質性分析: 把「我哪裡卡住了」這種第一層判斷推到 agent 自己身上(誰會比它更清楚?)，平台只負責把這些信號跨多次執行聚合起來。比起 LangSmith 那種「養一個外部大 agent 事後讀原始 trace」，這是把分析拆開、塞到源頭的另一種賭法。

不過也要老實說一句，而且這話是 Ben Hylak 自己講的: 這招創意十足，實戰上卻沒有表面看起來那麼好用。他在最新的 agent 評估指南(這篇非常讚，推薦一讀)裡直言，自診信號比較像「大水漫灌」: 一堆隨機回報裡，偶爾撈到一個有趣的，得花不少功夫去調靈敏度，才能變成穩定可用的訊號;更微妙的是，你給那個隱藏工具的措辭，會直接左右 agent 到底報不報，說穿了它就是一個二元分類問題。所以小編的評語是: 概念很漂亮、值得關注，但別期待它一開下去就一勞永逸。

③ 事後: 另外派一個專門的 agent 批次掃生產 trace

第三種位置在最後面: 等 trace 都進了生產資料庫，另外派一個專門的 agent，主動、批次地把整個迴圈跑完。最完整的代表，是 LangChain 在它的監控平台 LangSmith 上、五月推出的 LangSmith Engine。它本身就是一個 agent，做三件事: 找出重複出現的失敗、把失敗變成「可處理的問題」、再把問題轉成能長期沉澱的東西(評估器、資料集範例、修復 PR)。重點不在指出「這條 trace 壞了」，而是把一個生產失敗，變成團隊未來能拿來測試、防止退步的資產。

LangChain 還另外寫了一篇技術細節文講他們怎麼蓋這個東西，小編覺得比公告本身有料多了，幾個工程巧思特別值得學:

🔹 先壓縮再讀(trajectory): 生產專案的回看窗口裡可能有上萬條 trace，全塞進上下文根本不可行，光 10 條長 agent 的 trace 就能有上百個工具呼叫。解法是先把每條壓成「骨架」: 每一輪只留角色、工具名稱、延遲、內容字數，不放完整內容。agent 先看骨架找出「形狀可疑」的，再回頭把需要的細節撈進來。

🔹 篩選與調查兩階段分離: 第一階段用便宜的 Haiku 當「篩選員」，一次掃約 20 條，只回報「乾淨 / 可能有問題」，不做診斷;第二階段才派「調查員」把可疑 trace 的完整內容和程式碼撈進來深入分析。篩選員追求規模，調查員追求深度，職責切乾淨。

🔹 限制問題分類: Engine 不讓 agent 自由發明問題類別，而是給它一份預先定義好的清單(像 pii_leak、agent_looping、incorrect_tool_args、missing_tool)。理由很實在: 讓 agent 亂取類別，輸出就難以評估、也難以信任。

🔹 評估器先測過再交出來: Engine 為每個問題提一個評估器，但在拿給使用者之前，會先用 test_evaluator 工具拿證據 trace 跑一遍，確認它真的抓得到對應的失敗(回傳 PASS / FAIL / SKIPPED)。因為一個評估器「看起來合理」跟「真的抓得到問題」是兩回事。

🔹 找問題的 agent 跟修問題的 agent 分開: 早期他們讓同一個 agent 又找問題又提修復，結果什麼都做不好。後來拆成: 主 agent 只負責找問題、產出評估器和資料集，需要修的就打一個 needs_fix 標籤，再交給專門的修復 agent 去提修改。

🔹 跨次執行的記憶(Agent Overview): Engine 維護一份類似 AGENTS.md 的活文件，記著「你的 agent 在做什麼、會出現哪些 trace 結構、常見的地雷、團隊的偏好」，跨次更新，甚至會從使用者的動作(關掉某個問題、建立某個評估器)學習。

這套已經實際幫 Cogent、Harmonic、Campfire 等團隊處理過影響數千條 trace 的問題。而且這也不只 LangChain 一家在做，Arize、Braintrust、Databricks 在 2026 年都推了方向類似的東西，「平台幫你自動分析 trace」已經是一整個賽道。

踩個剎車: agent 真的會「分析」嗎?

三種作法講完，得踩一下剎車。Shreya Shankar 有一篇 Exploring Agent-Assisted Qualitative Analysis(用 agent 協助做質性分析)，做了一個很扎實的實驗。她本身就是做這行研究的(剛拿到教職)，這次直接拿 agent 去做學術界的「質性分析」: grounded theory，也就是讀大量雜亂的資料、貼標籤(編碼)、再歸納成高階的主題。她問了一個很本質的問題: 用 agent 做這種分析，到底行不行?

她的素材是 451 條推文(Sholto Douglas 問「什麼時候你會改用別的模型、而不是 Claude?」底下的回覆)，要分析的是「使用者為什麼想跳槽」。她跑了六種條件，差別在兩個軸: agent 有沒有被教 grounded theory 的方法、以及人類介入到什麼程度(完全不介入、逐批審編碼、讀備忘給回饋、甚至兩個 agent 互相對照)。

她先點出為什麼這題對 AI 特別難: 質性分析的「對的答案」高度依賴語料以外的脈絡，需要一種說不太清楚的品味與判斷(不像「程式有沒有編譯過」有標準答案);更麻煩的是，評斷的標準本身會在分析過程中不斷演化，而現在的 agent 偏偏假設目標固定、又急著收斂。實測下來，毛病很一致:

❌ 是轉述，不是分析: agent 產生的編碼數量，跟推文長度高度相關(ρ = 0.81)，但長推文往往只是同一個抱怨講得更長，它卻照著字數狂貼標籤。而且 93.8% 的編碼整份語料只用過一次，明明完整的編碼簿就在上下文裡，它卻不重用、每條都發明新標籤，根本沒在歸納。

❌ 沒把資料編碼完: 雖然被要求讀完整份、甚至多跑幾輪，agent 卻常讀到一半就自己宣布「分析完成」。表現最好的一組只編碼了 68%，最差的只有 5.5%，多數落在 25–35%;還有些推文直接被跳過、給了空標籤。

❌ 工作管理很差: 它傻傻地一條一條順序處理，不會像人類研究者那樣切分資料、有策略地採樣、邊讀邊組裝。最離譜的一組: 兩個 agent 跑到逾時後，主 agent 乾脆改寫成「關鍵字比對的 Python 腳本」(看到 sycoph 就標 overly_agreeable)，這已經完全不是在做分析了。

❌ 回饋迴圈很弱: 她講一次「我在意競品比較」，agent 就過度擬合、把它捧成最大的分類;她說「標籤太多了」，agent 收斂一下、下一批又故態復萌(最後 96.5% 還是一次性標籤)。要嘛過度擬合早期回饋，要嘛轉頭就忘。

更值得 agent 圈警惕的，是她當「人類審核者」的體感。她發現一個陷阱: agent 產出的高階分類，常常含糊到無法反駁，例如「可靠性與信任」這種大到什麼抱怨都塞得進去的類別，你很難說它錯，但這種「不可證偽」恰恰不是好分類。她一句話點破: 含糊的分類讓人容易相信、卻無法據以行動。如果連「幻覺算不算主要問題」這個類別都定義不清，那它接著提出的「修掉幻覺」方案，你也沒有基礎去信任。這正好戳中 LangSmith Engine 那類「自動產問題、提修復」的要害。

她的結論很精準: agent「能很快做完機械性的部分，但缺乏品味」。所以真正有意思的問題，根本不是「如何自動化質性分析」，而是「如何打造一個系統，讓人類的品味跟 agent 的規模真正組合起來」。而她隨手點的一個未來方向，剛好就是這整篇的主題: 把這套拿去做 agent 的 error analysis: 資料本身就是 agent 的 trace，目標是找出重複出現的失敗模式。換句話說，本文講的三種作法，正是這個還沒被解好的題目的早期答案。

Shreya 這個質疑，跟前面三種作法其實不矛盾，反而互補。注意到沒有: LangSmith Engine 那麼多設計(固定分類、評估器先測過、所有問題都進「待審核」狀態等人按)，本質上都是在替 agent 的「缺乏品味」做防護欄;FutureSearch 乾脆讓你自己的 Claude Code 在你眼皮底下開車，Raindrop 則讓 agent 把判斷攤開成可追蹤、人能在儀表板上把關的信號，也是同一回事。沒有人真的在假裝 agent 能取代人，差別只在於把人擺在迴圈的哪個位置。

想自己做好 trace 分析? 幾條小編的收穫

把上面的成功和翻車擺在一起，如果你打算自己搭一套用 agent 分析 trace 的流程，小編覺得有幾條原則特別關鍵:

🔸 別讓 agent 邊讀邊即興生分類: 這是 Shreya 那組實驗最大的教訓。讓 agent 一條一條讀、順手就把錯誤分類(axial code)生出來，它幾乎永遠在「換句話說」而不是「歸納」。比較好的做法，是把開放編碼和歸類拆開，或讓 agent 只負責提議、由你來定分類。

🔸 迴圈的編排交給程式碼，不要交給 agent 判斷: agent 很愛走一走就自己宣布「分析完成」(Shreya 那組最慘只讀了 5.5%)。所以「要讀哪些、分幾批、跑幾輪、什麼時候停」這種流程控制，用程式碼寫死(像 ihower 的取樣腳本、或 LangSmith 用篩選員去派發)，別讓 agent 自己拿主意。

🔸 用一個很簡單的標準，檢驗你抓到的失敗模式: 每抓出一個失敗模式，問自己一句: 它能不能寫成一條清楚的「納入 / 排除」準則，並且轉成一個自動檢查(LLM-as-judge 或程式斷言)? 不能的話，它就太抽象了，只能拿來自我安慰，沒辦法真的把迴圈閉合起來。這正是 Shreya 說的「含糊分類無法行動」的解藥，也是 LangSmith Engine 堅持每個問題都要配一個測過的評估器的理由。

🔸 把分類體系當成版本化的產物: 先把詞講清楚: 一個 axial code 是「一個錯誤類別」，分類體系(taxonomy)則是「整組類別」合起來的結構，改分類體系，通常就是在新增、合併、刪掉裡面那些類別。原則是: 分類體系一改，就回頭重跑，別讓新舊標準混在一起。而且人該介入的點，是在分類體系這一層，不是逐條標註那一層: 讓 agent 提議分類，你來做判斷(合併、刪除、調整、重新加權)，而不是自己一條一條編碼、當人肉標註工。對應的審查介面也該以群集為單位，每個群集直接附幾條範例 trace 連結讓你抽查，並秀出每輪之間的差異(哪些失敗模式是新增的、哪些類別搬了家)。

迴圈在閉合，但方向盤還在人手上

把這幾篇串起來，2026 的圖像蠻清楚的: 那個「讀 trace → 找問題 → 修 → 驗證」的改進迴圈，正在被 agent 一段一段接管。差別只在於那個最關鍵的質性分析，你想放在哪裡: 交給你自己的 coding agent(FutureSearch 用一個 skill 配 Claude Code)、讓 agent 在執行的當下自己診斷(Raindrop Self Diagnostics)、還是另外派一個專門的 agent 事後批次掃生產 trace(LangSmith Engine)。同一件「讀 trace、找問題」的事，被擺到了流程裡三個很不一樣的位置。

但 Shreya 的提醒值得貼在牆上: agent 是規模的放大器，不是品味的替代品。它能把上萬條 trace 篩到剩幾十個值得看的問題，這已經是巨大的價值;可是「哪個問題真的重要、這個失敗模式該怎麼定義、修復的方向對不對」，這些需要品味的判斷，方向盤還是握在人手上。

編按: 想看一個把這套迴圈跑到生產規模、又刻意保留人類品味的完整案例，可以看小編之前整理的 Replit 如何規模化評測和持續改進 Vibe coding，他們用離線的 ViBench 加上線上的 trace 分群 Telescope，雙引擎驅動每天出貨的 coding agent。

說到底，agent 上線之後本來就是一路邊跑邊修: 你不可能事先想好所有失敗，trace 分析就是你持續發現問題、持續改進的命脈。所以把 agent 做好，從來不只是一個模型問題，而是一個得長期經營的營運問題;而這條營運迴圈裡最累的一段，正是讀 trace，也正是這篇從頭談到尾、最值得想辦法交給 agent 分擔的工作。