Agent debugging 為什麼這麼難:LangChain 的新框架在解什麼問題
Agent observability 終於有人認真做了。
LangChain 上週發了一篇文件,整個框架繞著一個前提:對 agent 做傳統 debugging 根本沒用。
原因很直接傳統軟體是 deterministic 的,同樣 input 永遠給你同樣 output,出問題就看 stack trace,找哪行爆。Agent 打破了這個假設。「你不知道這段邏輯跑起來會做什麼,直到你真的跑過 LLM 才知道。」LangChain 自己這樣寫的。
所以問題就變成:為什麼它在 200 個 step 裡的第 23 步選了 edit_file,沒有選 read_file?這不是 function 壞掉,是決策壞掉。你要能還原那個決策點的完整上下文才有辦法查。
他們提出三個 primitive:
- Run:一次 LLM 呼叫的完整快照,input、可用 tool、output 全記
- Trace:把 Runs 串起來,還原整個執行路徑。複雜 workflow 的 trace 可以到幾百 MB,因為要存下 agent 每個決策點的完整 reasoning context
- Thread:多個 Trace 組成跨時間的 session,適用於多輪任務或長時間對話
方向是對的。我最近在評估一個 multi-agent 設計,就卡在「出了問題不知道哪步壞的」。現有工具通常給你的是「agent failed at step 47」然後沒了,要你自己猜。
實際落地還有幾個問題沒解決。這種 trace 的 storage 和 query 成本不低,concurrent agent 一多就是個坑。另外 Deloitte 一月的報告提到 enterprise 需要新的方式來監控 agent 行為,但「需要」跟「有工具可以用」還是兩件事。
先看看社群反應,等有人在 production 跑過再說。
作者:鍵盤工人