昨天留了兩個疑點：P-LLM規劃階段本質上看不到資料，跟任務完成率掉下來，是不是同一件事；還有檢查時機是不是太晚，今天把「代價」這件事攤開來講清楚，探討代價到底是哪些與有多少？

兩個數字，差了20幾個百分點

在CaMeL官方論文中以AgentDojo上測試的數據有77%任務能證明安全並執行，未加防禦系統的能有執行84%，差7個百分點。但另一篇獨立評測，Bhagwatkar等人2025年發表在NeurIPS的論文《Indirect Prompt Injections: Are Firewalls All You Need, or Stronger Benchmarks?》，重新跑過同一個AgentDojo基準後，得到的數字CaMeL的ASR一樣是0%，但benign utility只有53.6%，utility是54.5%。

這兩組數字差了超過20個百分點，我們目前查到的資料裡，沒有看到任何一篇論文對這個落差做出解釋，這可能是評測用的模型不同、AgentDojo的版本或任務子集不同，或是單純是目前此比較資訊較，因此對於CaMel的可證明安全架構需在實作前加以驗證。

代價不只是完成率，還有算力成本

同一篇獨立評測還指出一個官方論文比較少強調的角度：CaMeL的token成本，是所有比較對象裡最高的，輸入token約是無防禦基準的2.82倍，輸出token的2.73倍，部分任務單次跑完要價超過8000秒，代表不只是有些任務做不到，還會造成就算做得到也比較貴、比較慢，但對於能夠提提升防禦的角度來看，值得看使用所帶來的價值是否大於損失。這個角度現在提出來，在後續實測階段如果要跟自己的方案做對照，算力成本也會是其中跟任務完成率一樣需要量測的項目。

官方自己承認的失敗原因：「Data requires action」

CaMeL論文附錄裡有針對失敗案例做了分類，其中一類官方稱為「Data requires action」，此部分為該採取什麼行動，取決於還沒讀到的不受信任資料，這正好是昨天所說因為P-LLM規劃階段的資訊不足，跟完成率的代價，終究會在某一類任務上匯合成同一個問題，當任務的本質就是讀了才知道，再好的規劃也繞不過去，而這正是官方自己承認、架構天生解不了的一類失敗。

發現兩個數字對不上，能學到什麼？

知道了兩種不同的測試結果，讓我去思考了學術中論文評測結果爲何會有此結果，很多時候這類評測牽涉太多可以調整的變數，這也讓我想起過去在執行其他專案時，目標也總是想辦法讓模型本身得到最好的效果，但在測試新的資料時往往會遇到結果不盡理想，因此用哪個模型當底層引擎、資料集抽樣抽到哪個版本、成功與失敗的判定標準怎麼寫，任何一個環節不一樣，數字就可能大幅偏移。因此學會習慣性地多思考在什麼條件下量出來的，以及我們要固定的變因，對於接下來的研究也很必需。

這不是CaMeL的問題

IPIGuard這個防禦機制本身，同樣把「規劃」和「接觸外部資料」徹底切開，只是它用的是工具依賴圖，而不是capability標記。兩者的核心取捨是一樣的，只要選擇在接觸不受信任資料之前就把計畫鎖死，「有些任務讀了才知道該怎麼做」這個代價幾乎是必然的，不是CaMeL這篇論文的實作缺陷，而是整個plan-then-execute流派共有的結構性問題。

這一點對我來說有參考價值：如果之後要處理「在不犧牲安全保證的前提下，拿回一部分彈性」，IPIGuard用圖結構表達依賴關係的做法，是另一個切入的視角，不一定要侷限在capability標記這一種思路裡想事情。

簡單預告接下來幾天要走的路線，讓這幾天的關係更加清楚，CaMeL、IPIGuard、PlanGuard，代表的是plan-then-execute這個大方向底下，三種不同的具體實作，各自用capability標記、工具依賴圖、隔離規劃器加意圖驗證器，去處理同一個「規劃跟接觸外部資料要不要切開」的問題，但這三篇都是規劃一旦定案，執行期就會不能改動。接下來要開始研究ControlValve跟CXI，他們處理控制流本身合不合法，跟這幾天讀的這三篇關注的不太一樣，一個顧「資料流向對不對」，另一個顧「呼叫順序對不對」，讀完這兩組之後，才會看得出兩者其實是互補的關係。

同一個問題，還有第三種切法

CaMeL跟IPIGuard都屬於plan-then-execute方式，但具體做法也不是只有一種，PlanGuard是先用隔離的規劃器，根據使用者原始指令跟工具定義，產生一份乾淨的參考動作集，而規劃器從頭到尾碰不到任何外部檢索回來的內容，真正執行時系統會分成兩階段比對，第一階段是硬比對，看實際呼叫的工具名稱跟參考集合合不合；第二階段加上一個意圖驗證器，容許一些良性的格式差異（例如「上週」寫成「last_week」或是「lastweek」都算可以繼續），但抓得出參數被惡意置換的情況。

這篇在InjecAgent這個基準上，不管是直接傷害還是資料竊取類的攻擊，攻擊成功率都是0%，而且誤判率壓到1.49%，對照純粹只做第一階段硬比對的版本，誤判率會飆到27%到38%。這組數字說明靠硬性比對容易把正常但講法不同的合法請求也一併擋掉，加一層語意寬容度，才能同時壓低攻擊成功率跟誤判率，這對我們設計判讀關卡也是一個提醒，過度死板的規則，代價不只是犧牲功能性，還可能製造大量假警報。

這個對照某種程度上也在回答讀者可能會有的問題：既然已經有CaMeL、IPIGuard、PlanGuard三種做法在處理plan-then-execute的代價，為什麼還需要再多一套機制？答案是這三篇都還停留在「讓靜態計畫的代價變小」，沒有一篇真正處理「讓計畫本身能有限度地動起來」，這條界線接下來幾天會反覆確認，是不是真的沒人做過。

下一步

「控制流完整性」這個詞，到目前為止都只是拿來描述CaMeL在做的事，還沒有真正追過它的出處，這個詞是從傳統軟體資安借來的，原本用來擋的是完全不同的一種攻擊。下一篇要回頭把這條類比拆開，看它在傳統軟體資安裡原本長什麼樣子，跟現在套用在agent身上，究竟有哪些相似之處。

參考資料

• Debenedetti et al., Defeating Prompt Injections by Design, arXiv:2503.18813
• Bhagwatkar et al., Indirect Prompt Injections: Are Firewalls All You Need, or Stronger Benchmarks?, arXiv:2510.05244
• IPIGuard: A Novel Tool Dependency Graph-Based Defense Against Indirect Prompt Injection in LLM Agents, arXiv:2508.15310