agent 在第三輪呼叫了錯的工具時,你手上只有一坨扁平的 messages 陣列,而要回答的問題是——那一輪模型到底看到了什麼。這個工具把陣列重建成迴圈結構:每一輪框出模型收到的輸入、它做的決定、你餵回的結果,tool_call_id 的配對直接顯示而不必自己找。每輪的輸入切片是依標準送出規則從最終陣列反推的重建值,不是線上抓包,工具會在每張切片上標明這一點。全程在瀏覽器本機解析。
agent 在第三輪呼叫了錯的工具時,你手上只有一坨扁平的 messages 陣列,而要回答的問題是——那一輪模型到底看到了什麼。這個工具把陣列重建成迴圈結構:每一輪框出模型收到的輸入、它做的決定、你餵回的結果,tool_call_id 的配對直接顯示而不必自己找。每輪的輸入切片是依標準送出規則從最終陣列反推的重建值,不是線上抓包,工具會在每張切片上標明這一點。全程在瀏覽器本機解析。
關於這個主題的常見疑問與實用解答。
每一則 assistant 訊息開啟一輪。它之前的所有訊息是這一輪的輸入,assistant 訊息本身是決定,它之後到下一則 assistant 之前的工具結果是這一輪的結果。這對應迴圈真正的跑法:送出歷史、模型決定、你執行並餵回、再來一圈。Anthropic 的對話把工具結果包在 user 訊息裡而不是獨立的 tool 訊息,所以切換 API 規則版本會改變哪些訊息算結果。
那些平台是為持續監控而生:接上 SDK、註冊帳號,trace 送往它們的伺服器。這個工具站在相反的一側——完全不碰你的執行環境。當有人在 bug report 裡貼了一坨陣列、當你從 production log 撈出一段對話、當你看的是別人服務的 trace,那裡沒有東西可以埋點。貼進來就看得到迴圈結構,而且什麼都不離開你的瀏覽器。
不是,而且工具在每張切片上都這樣標示。它是依「每次請求帶上到那個時點為止的歷史」這條標準規則從最終陣列重建的。框架常常打破這條規則——裁剪舊訊息、注入系統前綴、改寫工具描述、摘要歷史。所以請把切片當成輸入的形狀,不是逐位元的複本。如果你的框架改寫得很兇,重建結果呈現的是一個樸素 client 會送出的東西——那仍然是判斷「模型的視野從哪裡開始不再變化」的正確基準。
安全。解析、輪次切分與配對全部在你的瀏覽器內執行——不上傳、不儲存、不進 analytics。agent trace 裡常常帶著客戶資料、內部工具參數,system prompt 裡甚至有 API key,這正是這個工具完全沒有伺服器端的原因。貼上時打開瀏覽器的 network 分頁就能自己驗證。