pranav-afk

單一代理的除錯已經大致解決：看提示、看工具呼叫、看輸出。

多代理圖形則不同。讓團隊不斷踩雷的模式如下：

  1. 代理 A 將任務交給代理 B
  2. B 呼叫工具
  3. 結果回到 A
  4. A 根據結果做出決策
  5. 三個步驟之後，最終答案明顯錯誤

問題通常不在步驟 5。錯誤發生在交接（步驟 2）。等到你盯著最終輸出時，只能靠手動從日誌還原整個鏈。

這就是多代理除錯的代價。

為什麼交接會在無聲無息中出錯

在單一鏈中，只有一個元件掌握狀態的來龍去脈。

在多代理執行中，狀態常常是隱式的：

  • A 記錄：「我傳了正確的東西。」
  • B 記錄：「我收到合理的內容。」
  • 兩者在各自看來都「正確」。
  • A 原本的意圖與B 實際操作的內容之間的落差，正是無聲失敗藏身之處。

如果你只記錄每個代理自己的輸出，這個落差就永遠不會被發現。

在完美工具出現前，有三件事可以幫上忙

1. 把交接視為一等事件

不要只記錄「代理 A 結束」／「代理 B 開始」，而要記錄更多：

  • 決定交接的原因
  • 傳輸中的資料
  • 接收方被告知的內容
  • 接收方實際能存取的項目（工具、記憶體範圍、權限）

最後一項很重要。資料可能吻合，但授權卻不同（B 無法讀取 A 以為它能讀取的記憶體）。

2. 優先使用步驟檢查，而非整條重新執行

當工具具有副作用（寄送郵件、更新工單、移動資金）時，重新執行整條圖形來除錯既慢又危險。

你真正需要的是：跳到交接步驟，並在那裡檢查狀態。

3. 及早（低成本）偵測差異

實務上有一個有效模式：在邊界建立快照。

  • 傳送方快照：A 放在傳輸線上的內容
  • 接收方快照：B 在第一次工具／LLM 呼叫之前所綁定的工作狀態
  • 比對兩者

若兩者有差異，你能在步驟 2 就抓到，而非步驟 5。比完整重播更省：只要比對快照，不必重新執行圖形。

從節點分叉（在該狀態下測試不同的工具／政策，而不必重播上游）是復原的一半。偵測才是大多數團隊從未建立的那一半。

這對「代理可觀測性」意味著什麼

泛用的「顯示 LLM 跨度」對單一鏈有幫助。

多代理系統需要邊界感知的操作：

  • 跨代理的巢狀／連結執行
  • 在決策時可見的記憶體
  • 已授權的工具
  • 依邏輯任務彙整的成本與重試次數

這正是我們正在用 Cartha 打造的方向（SDK-first：追蹤、範圍記憶體、預算、多代理巢狀）。我們對完整的「從節點分叉」以及自動交接差異探測仍處於早期階段，並且對此保持坦誠。

如果你只能記住一件事：請記住記錄交接，而不只是代理本身。

給你的問題

如果你正在執行多代理圖形（LangGraph 或其他）：

  1. 你是否把交接視為一等事件來記錄，還是只記錄各代理的 I/O？
  2. 當你「重播」時，是完整重新執行，還是步驟層級的檢查？
  3. 你是否建立過任何檢查，確認傳送方的資料與接收方解讀的狀態完全一致？

很想知道你在正式環境中哪些做法有效（或失敗）。

文件／試用：cartha.in/how-to-use