AI Engineer onepage/ Agent data mining
Vivek Trivedy, LangChain · 20:01
這支影片在講：改善 Agent，是資料探勘問題
Agent 的行為不在程式碼裡，而在它每次執行留下的 trace 裡。要持續變好，先讓系統從真實 trace 找出失敗、產生密集回饋，再決定該改 harness 或微調模型。
Published: 2026-08-12Video ID: CvRngaQZQ3Y
01 / 問題
程式碼看不出 agent 為何失敗
自主性換來非決定性。使用者何時挫折、工具何時沒被呼叫，必須回到 production trace 才看得到。
02 / 反轉
觀測與持續學習是同一件事
Trace 不只是除錯紀錄；它是 eval、判斷器、資料蒸餾與下一輪改善共同依賴的事實層。
03 / 解法
先快迭代，再投資訓練
先把兩分鐘可驗證的 harness engineering 做到極限；只有它已無法改善時，才把高成本微調當作突破手段。
Signal cards
影片裡最能改變決策的四個訊號
Feedback cycle
~2 分鐘
harness engineering 的回饋快，應先耗盡這個低成本迴路。
Cost result
10–100×
在法律 benchmark 中，經 trace 指引的工程讓 open model 能以低一到兩個數量級的成本做 trace judging。
Agent evidence
Trace
真實環境裡採取過什麼動作、看到什麼結果，才是可供改善的行為記錄。
Eval output
Dense
只有 pass / fail 沒有可行動方向；細粒度回饋才讓 agent 能爬坡改善。
Core loop
從 trace 到持續改善的三段迴路
01
先 ship，收集真實行為
不要從想像中的 bug list 開始。把每一步的工具呼叫、環境結果與使用者訊號保留成 trace，才能回答「哪裡變笨了」、「誰受影響」或「不同模型會怎麼做」。
02
讓 agent 讀別的 agent trace
在 trace 上提出具體問題：失敗模式是什麼、使用者在哪一步受挫、如果改用另一模型是否更好。重點不是人工通讀，而是讓分析能在大量案例上擴張。
03
把回饋接回 harness 與模型
先用評估與 prompt／工具／流程調整快速修正；若衡量顯示已到瓶頸，再微調特定垂直任務。好的 trace 也能蒸餾成自家訓練資料。
Design choices
不要把 eval 當成排行榜；它是在定義 agent 的行為
每個 issue 要有兩個欄位問題何時開始，以及它影響多少使用者。前者幫你找變因，後者決定優先級。
Trace judge 不必永遠用 frontier model先以高能力模型建立參考，再量測 open model 是否能在目標任務上達到足夠一致的判斷品質。
微調不是第一反應當可快速驗證的 harness 改動仍能帶來提升，就先留在工程迴路；微調用來跨越明確的效能天花板。
記憶不應只會 append長任務的狀態要能依 feedback 更新；把記憶、模型與任務適配視為三條可調的改善軸。
Use this checklist
如果你正在營運 Agent，先做這五件事
為每個 production run 留下可查詢 trace至少能連回任務、工具結果、失敗點與使用者後續行為；沒有共同事實層，後面無法做可靠診斷。
把 pass / fail 改成可行動的密集回饋評估輸出要能告訴改善者「哪一步錯、為何錯、下一步可試什麼」。
把 issue 發生時間與受影響範圍放進 dashboard這兩個欄位讓 incident triage 從直覺排序改成可驗證的產品決策。
建立 harness → finetune → harness 的切換門檻明訂何時工程改動已無增益，再投入訓練成本；訓練後也要回到同一套 eval 驗證。
用自己的好 trace 蒸餾專用能力高品質成功案例與判斷結果，是把通用模型變成垂直 agent 的可持續資料資產。
Source video
原影片與章節
0:00–8:24｜為何 trace 是唯一可靠行為紀錄從 agent 的非決定性、production trace 到讓 agent 分析其他 agent 的行為。
8:24–12:48｜成本、判斷器與 evalopen model trace judging、harness engineering 的天花板，以及 eval 作為行為描述。
13:28–19:17｜適配、密集回饋與狀態model／harness／task fit、dense feedback、三條 agent state 更新軸與非 append-only 的記憶。