我個 Agent 連續叫咗 5 次失敗 API——問題唔係出喺代碼

Bug 打到 production 上嚟。我個 agent 係咁重複同一個 API call，連叫五次。習慣使然，我第一反應係打開代碼。Retry 邏輯冇問題。Function 流程一切正常。Log 裡頭連一個 error 都搵唔到。

代碼入面冇答案。直到我打開 trace，問題先浮出水面。

Agent 代碼係個空殼

打開任何 agent 嘅源碼，你會見到：model 配置、工具清單、system prompt。差唔多就係咁多。至於幾時叫哪個工具、推理順序點排——呢啲嘢唔係住喺代碼入面嘅。

做緊 LangGraph-based agent 嘅團隊，全部都講過同一句話：「睇代碼根本判斷唔到 agent 嘅質素。」

• 同一份代碼、同一個 input，每次叫嘅工具順序都唔同
• 唔似 handleSubmit() 呢類 function，分支邏輯根本唔存在於代碼之中
• 同一條 query 問 GPT-5.2 十次，工具呼叫順序一致性大概得 40%
• 出錯時代碼冇任何 bug，根本無從複現

傳統軟件裡，代碼就係行為本身。但喺 agent 世界，代碼只係個架子。真正嘅行為係喺 runtime 跑出嚟嘅，由 model 點樣解讀當下嘅 context 決定。

Trace 係新嘅源碼

Trace 記錄咗 agent 走過嘅每一步腳印。每個步驟點樣推理、叫咗哪個工具、點解叫——全部都有。以前透過代碼做嘅除錯、測試、效能分析，而家都要靠 trace 先做得到。

Agent 見到一條 error message 之後仲係叫同一個 call——呢個唔係代碼 bug，係推理失敗。睇代碼你永遠睇唔出，只有 trace 先照得到。

• 比較 prompt 修改前後嘅 trace，可以即刻見到推理質素有冇改善
• 喺 LangSmith 入面，將某個時間點嘅 trace 載入 playground，效果就好似設定 breakpoint 一樣
• 一條 trace 可以直接指出 agent 推理係邊一刻走歪——呢樣嘢，幾多行 log 都做唔到

換個比喻：傳統除錯係睇食譜搵問題所在。Agent 除錯係倒帶廚房閉路電視，睇大廚係邊度整錯。食譜可能一點問題都冇，係執行時出咗事。

測試方式根本變咗

傳統軟件，部署前測完就算。Agent 係非確定性嘅，你要持續喺 production 裡頭評估。

冇一條收集 trace、建立 eval dataset、偵測質素退化嘅 pipeline，根本冇可能大規模運行 agent。

採用咗 trace-based evaluation 嘅團隊，任務成功率都有可量度嘅提升。規律係一致嘅：trace 揭露出嚟嘅失敗模式，係任何部署前測試都預測唔到嘅。

• 建立自動化 eval pipeline，每週抽樣 production trace
• 光靠部署前測試，保證唔到非確定性系統嘅質素
• 冇 trace 嘅監控，就係得睇吓個 server 跑唔跑緊
• Agent 可以「正常運作」，但係做緊完全錯嘅嘢——只有 trace 先揭得到

協作同產品分析都係喺 trace 上頭做

Code review 喺 GitHub 做。Agent 嘅判斷審查，喺邊做？

Observability platform 正在接過呢個角色。團隊喺 trace 上面留言、分享特定決策時刻、review agent 推理——就好似以前 review pull request 一樣。協作模式本身都變緊。

產品分析都係同一個模式。個 metric 話「30% 用戶唔滿意」，你唔打開 trace，根本搵唔到原因。Agent 可能按自己嘅標準算係完成咗任務，但係完全估錯用戶想要嘅嘢。

• Mixpanel 呢類產品分析工具同除錯工具，正在以 trace 作為共同嘅基礎層而融合
• 分析 agent 工具呼叫模式，可以反向推導出用戶真正需要嘅功能

一句到尾

Agent 時代，代碼係建築藍圖，trace 係閉路電視片段。出咗事，你唔係先攤開藍圖——係先倒帶片段。

搞得掂 agent 質素嘅團隊，係嗰啲將重心由代碼移到 trace 嘅人。唔係話代碼唔重要，而係真正蝕底嘅失敗——蝕用戶、蝕錢嘅那種——係住喺 runtime 行為入面，只有 trace 先捉得到。