為何容易被忽略
建置失敗,但代理已開始撰寫摘要。它是否已恢復,還是一個重要的失敗在兩個步驟之間消失了?下一個動作往往才是有效審查的起點。
在繁忙的工作階段中,錯誤可能在另一個工具呼叫前一刻就被略過。代理可能有有效的恢復策略,也可能在未處理失敗的情況下繼續執行。無論如何,都需要查看前後的操作序列才能判斷。
ClawMetry 偵測的內容
ClawMetry 標記工具回傳失敗後、未經辨識的重試或確認即繼續活動的情況,並建立資訊性的動作差異發現。較低的嚴重性很重要,這是提示你檢查轉換過程,而非對代理意圖的裁決。
改變發現結果的關鍵差異
觸發範例
失敗,改用其他工具
資訊發現
靜默對比
失敗,使用相同工具重試
此偵測器無發現。
受檢範例的 shell 建置失敗後呼叫了不同的工具,觸發資訊性發現。失敗後再次呼叫同一工具視為重試,此偵測器對此保持靜默。
檢查偵測器結果
{
"kind": "action_discrepancy",
"severity": "info",
"evidence": {
"failed_tool": "Bash",
"continued_as": "tool_call"
}
}下載輸入及完整結果 (JSON)範例的檢查方式
這些範例使用已撰寫的事件資料或一次性設定檔來評估已發布的偵測器。影片說明這些行為,並非即時代理或產品介面的錄製內容。範例中沒有任何指令被實際執行。
結果確立了這些輸入的行為,並不確立執行時期擷取、預防或實際入侵。 檢查已固定的原始碼合約.
接下來要檢查什麼
比對失敗步驟與後續動作。新的動作是否為恢復路徑?錯誤是否在其他地方得到確認?在依賴完成報告之前,請先驗證失敗操作原本應產生的底層結果。
- 檢查失敗結果
- 確認復原路徑
- 確認聲稱的結果
此訊號確立的範圍
此偵測器不驗證最終完成聲明。透過其他工具進行的合理恢復也可能符合觸發條件。