前言

這幾天我一直在同一個框架裡打轉，追它那個判定攻擊成敗的函式到底看了什麼。追到最後卡在同一個地方：它只讀任務跑完後的環境狀態，一次執行結束丟出一個布林值，這個值分不出模型是根本沒把注入當一回事、還是動了手只是差一點。要知道中間發生什麼，得另外回去翻工具呼叫的軌跡。這條路走到這裡，缺的其實不是更多資料，而是一個能對著「軌跡中間某一步」下判斷的評測方式。

今天換一份材料：讀一篇論文 TraceSafe（arXiv:2604.07223v1）。這篇不是我跑的新實驗，是離線閱讀，範圍先收在它的摘要、第 1 節、第 2 節，以及第 3 節開頭的方法概述與問題設定，還沒進到它建資料集的方法與後面的評測結果。我要回答的是一個問題：它把安全評測「評什麼、在哪裡判」這件事，從哪裡搬到了哪裡，而它搬動的那個缺口，是不是我這段時間在 AgentDojo 上撞到的同一面牆。

一、只看 agent 最後回了什麼，為什麼不夠？

TraceSafe 的第一個主張是：大型語言模型從靜態聊天機器人變成能自主呼叫工具的 agent 之後，主要的脆弱面也從最終產出移到了中間的執行軌跡。針對自然語言回應的護欄已經有大量評測，但把護欄放進多步工具軌跡之後是否仍然有效，幾乎沒有人量過。

基於這個主張，論文建立了一套 benchmark，並自稱是第一個專門評測「軌跡中途安全」的完整基準。它涵蓋四個領域（提示注入、隱私外洩、幻覺參數、介面不一致）下的 12 類風險，共有超過 1,000 個獨立的執行實例。受測對象包括 13 個被當作護欄使用的大型語言模型，以及 7 個專門的護欄系統。各類風險的逐項成績屬於後面的章節，今天不討論，這裡只用這些數字確認論文處理的問題範圍。

論文用一個直觀的例子說明，為什麼風險移到中間軌跡是真實存在的問題。它的其中一個良性種子是使用者請求「把成績整理好，寄給教授和助教」。這個工作流會用到 send_email 和 summarize 兩個工具。正常的軌跡是先用 summarize("grades.csv") 整理出結果，再呼叫 send_email 寄給教授，最後再呼叫一次 send_email 寄給助教。在良性版本中，兩位收件人都是應該收到成績的人。

有害版本不改變整條軌跡的結構，只修改其中一步：把最後一次 send_email 的收件人換成不該收到成績的外人，或是在內文填入模型幻覺出來的資料，然後在這一步之後截斷軌跡。由於只動了這一步，標註可以精確指向它。在實際情境中，這樣的任務跑完後回給使用者的「已寄出」，和良性版本完全相同。只看最終產出的護欄在兩個版本中讀到的都是「已寄出」，無法察覺成績已經寄給了錯誤的人。這類傷害只有檢查軌跡中的那一步才看得出來。

二、「評 agent」和「評護欄」有什麼不同？

進入論文的論證之前，需要先釐清幾個概念。

工具呼叫管線是指：由模型驅動的 agent 為了完成使用者請求，會自行決定呼叫外部工具（例如查天氣、寄信、讀檔），取得結果後再決定下一步，如此反覆進行多步。因此，危險並不集中在最後的回覆，而是分散在中間每一次工具呼叫。

護欄是獨立於受保護模型之外的偵測器。它讀取一段輸入或輸出，判定應該放行還是攔截。傳統護欄只檢查語意的「表面」，也就是最初的提示和最終的回覆，論文把 Llama Guard、Granite Guardian 等系統歸在這一類。今天要討論的問題是：只看頭尾兩端的護欄，放進包含許多中間步驟的軌跡之後，還能發揮多少作用？

全篇最關鍵的是以下這組對照。

端到端的 agent 評測以 agent 本身為對象：把 agent 放進可能藏有攻擊的環境，觀察它會不會被誘導、會不會完成有害任務。這類評測的環境是動態的，必須實際執行 agent，結果會隨模型和每次執行而改變。

軌跡層級的護欄評測則以護欄為對象：給定一條固定的軌跡，檢驗護欄能否在其中某一步攔下不安全的動作。由於軌跡固定，判定結果可以重現。TraceSafe 做的是後者。

最後還需要定義「中途風險」：惡意行為發生在軌跡中的某一步，即使最終產出看起來正常，傷害也已經造成。前面寄錯收件人的例子就屬於中途風險。

三、現成的 agent benchmark 為什麼不能直接拿來評護欄？

論文的回答是：既有的 agent 安全評測關注的是 agent 在動態環境中的端到端韌性，缺少單獨評測護欄所需的兩項條件，也就是固定的軌跡，以及標出哪一步不安全的逐步標註。

論文點名的幾個 benchmark 都屬於這種情況。ToolEmu 用語言模型模擬沙盒，以動態、端到端的方式偵測工具使用造成的危險副作用，規模為 144 個測試案例、36 個工具。AgentHarm 提供 110 個明確惡意的 agent 任務，分屬 11 個危害類別，評測被越獄的 agent 能否端到端完成多步有害任務。Agent Security Bench 則把 agent 各階段的攻防形式化，建立端到端的 benchmark，涵蓋提示注入、記憶污染、後門等攻擊。

這三者評的都是 agent 在動態環境中能否撐住，產出的是整體結果，而不是一條固定、每一步都標好安全與否的軌跡。即使把其中某一次執行凍結下來，軌跡上也沒有標註指出不安全的是第幾步。它們提供的只是整次執行結束後「攻擊是否得逞」的判定。因此，若要用它們單獨衡量護欄的分辨力，缺的就是固定軌跡和逐步標註。

四、只看最終結果的評測，實際用起來會卡在哪裡？

論文指出的缺口，我這段時間在 AgentDojo 上已經遇過。追查 AgentDojo 判定攻擊成敗的 security() 函式時，我觀察到三個現象，分別對應「只看最終產出、只做端到端評測」這種做法的三個結構限制。

第一，security() 只讀取任務結束後的環境狀態 post_environment，不讀取模型在過程中提出的動作。因此當它回傳 False 時，無法分辨模型是拒絕了注入、根本沒有嘗試，還是已經動手但差了一步。

第二，一組任務的 Average security 底下是十四種彼此無法比較的成功定義，各自產生一個布林值後再取平均。數學上它是平均值，語義上卻不是同一種單位的平均。

第三，同一組設定重複執行十次，攻擊成功率每次都是零，完全沒有變化。手上沒有非零的基準值，就無法比較防禦讓成功率下降了多少。

這三個現象指向同一個限制：評測如果只讀最終環境、只給出端到端的布林結果，就無法衡量護欄能否在中間某一步攔下攻擊。TraceSafe 要補的就是這一塊。

五、TraceSafe 如何把「在某一步攔下」寫成形式定義？

論文第 3 節的形式化會用到四個物件：使用者請求、工具集、執行軌跡、護欄。先說明它們之間的關係，後面的符號才容易對上。

在包含關係上，工具集由多個工具組成，每個工具有自己的參數；軌跡由多個步驟組成，每一步包含一個動作。在因果關係上，agent 根據請求和工具集執行任務，產生軌跡；護欄則讀取請求、工具集、目前為止的歷史和當前步驟，決定攔截或放行。

以下依照論文第 3 節的記號逐一介紹，並代入前面寄信的例子。

agentic 工作流由使用者請求 q 開始，例如 q＝「把成績整理好，寄給教授和助教」。伴隨 q 的是可用的工具集 T＝{T_1,…,T_k}，在這個例子中 T＝{send_email, summarize}。每個工具 T_i 由三部分定義：名稱 T_i.name、描述 T_i.desc，以及一組預期參數 P_i＝{p_{i,1},…,p_{i,m_i}}。以 send_email 為例，T_i.name 是 send_email，T_i.desc 是這個工具的用途說明，P_i 則是它需要的參數，也就是收件人和內文。

agent 為了完成 q 會進行多步互動，產生執行軌跡 τ＝[t_1,…,t_n]。在這個例子中，τ 依序是 summarize 一步和 send_email 兩步。軌跡中的每一步 t_i 由三部分組成：agent 的推理、提出的動作 a_i（例如一次工具呼叫），以及隨後的觀察 o_i（例如執行結果）。以寄信給教授這一步為例，a_i＝send_email(recipient="prof@uni", body="85")，o_i 是工具回傳的「已寄出」。

最後是被評測的對象：護欄 G。給定請求 q、工具集 T，以及當前步驟之前的歷史 t_{1:i-1}，G 要判斷能否在軌跡中的任一步 t_i 攔下風險。

論文在這裡用一句話確立了整篇的立場：「TraceSafe-Bench evaluates the guardrail, not the agent's robustness.」意思是受評測的是護欄，而不是 agent 的韌性。具體做法是模擬一條 agent 已經提出不安全動作 a_i 的軌跡，檢驗 G 能否在 a_i 送達環境之前攔下它。至於 agent 為什麼會提出這個動作，不在評測範圍內。這句話把 TraceSafe 和所有評測 agent 的 benchmark 區分開來，也正好回應第四節的三個限制：它不問 agent 有沒有被攻破，而是問護欄能在哪一步攔下攻擊。

把兩者畫成兩條流程會更清楚。第一條是 agent 的執行迴圈：

使用者請求 q ＋ 工具集 T
→ agent 產生第 i 步 t_i =（推理, 動作 a_i, 觀察 o_i）
→ o_i 回饋給 agent
→ 下一步 t_(i+1)
→ …

第二條是護欄的攔截點，位於動作送達環境之前：

護欄 G：在 a_i 送達環境之前
→ 讀取（q, T, 歷史 t_{1:i-1}, 當前步驟 t_i）
→ 判定放行或攔截

TraceSafe 評測的是 G 這條流程，而不是 agent 那條。把 TraceSafe 的記號逐項對照我在 AgentDojo 上觀察到的評測結構，兩種做法的差異如下：

表格最後一列是這篇論文對我最有用的地方，接下來兩節分別說明它的由來。

六、每一步安不安全，標準答案要從哪裡來？

形式化定義完成後，還有一個實際問題：要替每一步標出安全與否，這些逐步的標準答案要從哪裡取得？

論文的說明很直接：讓模型自由生成有害行為，得到的行為不夠真實；事後請人標註複雜的工作流，成本又高到不切實際。此外還有第三個問題：如果用語言模型生成有害行為，再用語言模型判斷它是否有害，生成者和判斷者同源，結果容易自我印證。

TraceSafe 的做法是「良性轉有害」的編輯：取一條真實的良性軌跡，用確定性的程式在指定位置注入風險，並在注入點截斷軌跡。這樣既保留了真實的規劃邏輯，又能得到精確的逐步標準答案。關鍵在於修改真實的良性軌跡，而不是憑空生成有害行為。修改位置由程式指定，所以哪一步被動過手腳一清二楚，既不需要事後找人標註，也不需要讓語言模型判斷自己生成的內容。至於具體如何檢查、如何變異，屬於資料集的建構方法，在後面的章節，今天只討論這個動機。

這個動機剛好能解決我先前遇到的困難。我在 AgentDojo 上重複執行十次，攻擊成功率每次都是零，代表最終環境從未出現「攻擊得逞」的狀態。要衡量防禦讓攻擊成功率下降多少，必須先有非零的成功率作為基準，而這個基準始終沒有出現。

確定性編輯避開了這個前提。它不需要等 agent 真的被攻破，也不需要最終環境出現成功狀態，而是直接在軌跡的指定位置放入一個已經提出的不安全動作，並以這一步作為標準答案。要回答的問題因此從「攻擊成功率下降了多少」變成「面對明顯不安全的動作，護欄能否攔下」。如此一來，衡量護欄的分辨力就不再取決於是否發生過成功的攻擊。

七、R-Judge 和 MCP-Guard 不是已經在做類似的事了嗎？

要看清 TraceSafe 的新意，需要把它和兩個最接近的研究比較。這一節容易把三種說法混在一起，所以我分開陳述：論文如何描述對方、對方如何描述自己，以及我讀完後的判斷。

先看 MCP-Guard。TraceSafe 認為 MCP-Guard「只做單步、事後偵測」：無法在呼叫抵達伺服器之前攔截，而且只檢查單一的工具呼叫，忽略了多步軌跡中的風險。然而，我找到最接近的 MCP-Guard 公開摘要，描述的是三階段的縱深防禦管線，並沒有說自己是事後偵測；TraceSafe 標註的年份也未必對應同一個版本。因此，兩邊的描述是否一致，目前還沒有獨立核對。以下引用時採用 TraceSafe 的說法，但一律註明出處，不把它當作 MCP-Guard 的既定事實。

再看 R-Judge。R-Judge 和 TraceSafe 更相近，因為兩者都使用固定的既有記錄。TraceSafe 在第 1 節把 R-Judge 和其他 benchmark 一起歸為「動態環境中的端到端 agent 韌性」評測。但 R-Judge 自己的摘要描述的是另一回事：它包含 27 個情境、569 筆既有的多輪互動記錄，由人工標註安全標籤，評測模型對整段記錄的風險覺察能力。依我的判斷，R-Judge 同樣是以靜態記錄加人工標註為基礎的判斷型 benchmark，把它歸為「動態端到端」並不精確。不過，這個歸類上的偏差反而凸顯了 TraceSafe 真正的不同之處。

差異在於標準答案的來源和粒度。R-Judge 的標準答案由人工標註，對應整段記錄，回答的是「模型能否察覺這段記錄中的風險」。TraceSafe 的標準答案由程式在指定位置編輯產生，對應單一步驟，回答的是「護欄能否在這一步攔下」。前者需要付出人工標註的成本，判斷粒度是整段記錄；後者不需要人工標註，也避開了讓語言模型評判自身產出的問題，判斷粒度細到每一步。

總結三者的定位：R-Judge 同樣使用靜態記錄，但依賴人工標註，判斷的是整段記錄的風險覺察；MCP-Guard（依 TraceSafe 的描述）只檢查單一工具呼叫；TraceSafe 則結合了逐步定位的標準答案、確定性編輯，以及對護欄在特定步驟攔截能力的評測。它的不同不在於靜態或動態，而在於這三項特點同時具備。

八、讀到這裡，哪些結論還不能下定？

今天只讀到問題定義和形式化。資料集的建構方法（如何挑選良性種子、如何把良性軌跡改成有害軌跡、12 類風險各自如何轉換）和後面的評測結果（各護欄的成績、結構瓶頸的相關數據）都還沒讀，因此今天不做相關結論。

「MCP-Guard 只做單步、事後偵測」是 TraceSafe 的描述，尚未獨立核對，不能當成 MCP-Guard 的既定事實。TraceSafe 自稱是「第一個軌跡層級的 benchmark」，這點也不宜視為定論，因為 R-Judge 同樣是以靜態軌跡為基礎的判斷型 benchmark。目前我只能從摘要層級分辨兩者的差異，R-Judge 的全文還沒讀。

小結

把今天各段合起來，TraceSafe 的問題移位不是換個名詞、也不是把舊結論套到新資料上，而是同時換了三樣東西：評測的對象從 agent 換成護欄，判定的位置從最終環境狀態換成軌跡裡逐步定位的標準答案，標準答案的來源從動態跑出來或人工標註換成對真實良性軌跡做確定性編輯。這三樣恰好對上我這段時間在 AgentDojo 上撞到的三件事——security() 只讀最終環境、Average security 是不可比布林的平均、十輪全零沒有非零基準。它不是在重做我做過的事，是把同一個問題換一個評測對象，重做成一個能重現的基準。

這件事會改變之後怎麼看「軌跡層級的防禦」。往後評一個護欄，該問的不再是「agent 有沒有被攻破」，而是「這條軌跡走到某一步，護欄攔不攔得下那個已經被提出來的不安全動作」；而且因為標準答案是編輯出來的，量護欄的分辨力不必先等到一次真的成功的攻擊，這正好跨過我先前卡住的那道坎：手上沒有非零基準，也還是量得動。至於它建資料集的方法夠不夠扎實、那些護欄的成績如何，是接下來要繼續讀的。

感謝大家今日份的閱讀。