如果我的 Agent 核心任務同時黏著三個屬性，完全拆不掉任何一環，該怎麼辦？
這種情況下,通常代表這個 Agent 的設計本身在架構層面就存在結構性風險,值得先退一步問：這個任務真的需要一個 Agent 同時具備這三種能力嗎，還是可以拆成多個各自只具備兩種屬性的子 Agent，透過額外的驗證層互相配合？例如一個「讀信箱、判斷是否需要處理、需要的話自動執行對應動作」的複合型 Agent，可以拆成三個角色：一個只讀信箱、產出結構化摘要的 Agent（有私有資料存取＋不受信任內容暴露，但不能對外通訊）；一個根據結構化摘要決定該做什麼的判斷 Agent（不直接碰原始郵件內容，只處理已經過濾整理的結果）；一個實際執行動作的 Agent（有私有資料存取＋對外通訊，但輸入完全來自前一個 Agent 的結構化決策，不直接暴露於原始的不受信任內容）。
這樣拆解後，沒有任何一個角色同時具備全部三個屬性，即使某個環節被攻破，攻擊鏈也會在角色交接的地方被切斷。這種做法犧牲的是系統整體的複雜度跟延遲，換來的是每個角色都能被獨立稽核、獨立限制權限。
方案二（先出草稿再核准）聽起來最容易實作，是不是應該優先選這個？
實作簡易度確實是方案二的優勢，但這不代表它應該是預設首選——它的實際防護力,高度依賴一個你無法完全控制的變數：使用者會不會真的認真讀草稿內容。IBM Bob 事件已經證明,當核准請求出現的頻率夠高、使用者被問煩了之後,「核准」這個動作很容易從「經過判斷的把關」退化成「反射性的按鈕點擊」,一旦退化到這個程度,方案二在實務上提供的保護,遠低於它在紙面上看起來的樣子。
比較務實的判斷方式，是問自己：這個 Agent 需要核准的頻率有多高？如果一個任務流程需要連續核准五、六次，方案二的實際效力會被核准疲勞大幅削弱，這時候應該優先考慮方案一或三（用架構本身擋掉風險，而不是依賴使用者的持續警覺）；如果核准頻率本來就低，一個任務只需要核准一次,方案二的效力比較能維持,這種情況下確實是相對簡單又有效的選擇。
方案三提到用「權限更低的子流程」先做過濾，這個子流程本身會不會又變成新的攻擊目標？
這是一個很敏銳的問題,答案是「會，但風險等級不同」。子流程確實會成為攻擊者的下一個目標,但它跟主 Agent 的關鍵差異在於權限範圍——子流程被設計成只能做過濾跟初步處理，不具備私有資料存取或對外通訊的能力，就算子流程本身被攻破，攻擊者拿到的頂多是「能操縱過濾結果」的能力,而不是直接動用私有資料或對外送出東西的能力。這代表拆解不受信任內容這一環,並沒有讓風險完全消失,而是把風險從「主 Agent 被攻破，直接造成資料外洩」降級成「子流程被攻破，需要再進一步突破主 Agent 的權限限制才能造成實際傷害」,多了一層攻擊者需要跨越的障礙。
這也呼應了一個更根本的原則：拆解致命三要素中的任何一環，本質上都是把風險轉移到新產生的環節，而不是讓風險消失。子流程本身的過濾邏輯也需要定期稽核,確認它沒有被錯誤設計成「表面上在過濾,實際上把不受信任內容原封不動傳遞給主 Agent」這種形同虛設的狀態,這也是為什麼架構複雜度高的方案三,需要比方案一、二更持續的維護投入。
已經套用了二選一法則的 Agent，日後新增功能時，要怎麼避免不小心又把第三個屬性加回去？
最直接的做法是把「檢查是否違反二選一法則」寫進功能上線前的架構審核清單，變成一個強制檢查點，而不是依賴工程師憑印象記得。具體可以要求每個新功能提案明確標註：這個新功能是否會讓某個既有的 Agent 角色，額外獲得原本沒有的私有資料存取、不受信任內容暴露、或對外通訊能力，如果答案是肯定的，必須明確說明目前這個角色原本拿掉的是哪一環，新功能是不是要把這一環加回來——如果是，代表這個新功能不應該直接疊加在既有角色上，而應該考慮拆成新的、權限更受限的角色。
實務上一個常見的疏漏情境是「漸進式功能擴張」：一個 Agent 原本只能讀取資料（拿掉了對外通訊），後來因為使用者反覆要求「能不能順便幫我發個通知」，工程團隊在既有角色上直接加了一個發送通知的功能，沒有意識到這個小改動已經讓這個角色重新集滿了三要素。這也是為什麼架構審核清單不能只在專案啟動時做一次,而要綁定在每一次新增權限或新增工具的變更請求上,確保二選一法則不會被日常的功能疊加悄悄破壞。
知道致命三要素（存取私有資料、暴露於不受信任內容、能對外通訊）是什麼，跟知道怎麼在自己的 Agent 架構裡實際拆解它，是兩件不同的事。Meta 的 AI 安全團隊在 2025 年 10 月公開發表的「二選一法則」（Rule of Two），提供了一個具體的實作原則：一個 Agent 在單一 session 裡最多只能同時滿足三個屬性中的兩個。這篇文章要處理的是下一步——三個屬性各自拆解一環，實務上分別長什麼樣子，各自的取捨是什麼。
如果 Agent 的核心任務是處理不受信任的內容並對外通訊（例如一個瀏覽網頁、自動回覆郵件的助理），拆解私有資料存取這一環，代表把 Agent 限制在完全隔離、或只能接觸經過脫敏處理的測試資料的環境裡運作，即使被注入指令，攻擊者能拿到的也只是無關緊要的內容。這個方案的優點是實作相對單純——不需要複雜的人工核可流程，Agent 可以持續自主運作；缺點是犧牲了功能完整性，很多實用場景本來就需要 Agent 接觸真實的私有資料才有意義（例如要幫使用者查詢自己的訂單紀錄），如果核心任務本身離不開私有資料，這個拆解方案根本不適用。
如果 Agent 需要同時存取私有資料跟處理不受信任的內容（例如一個讀取信箱、根據郵件內容整理待辦事項的助理），拆解對外通訊這一環，代表把「自動送出」這個動作改成「先產生草稿，使用者確認後才送出」。這個方案的優點是即使 Agent 的判斷被劫持,生成了一段包含惡意內容的草稿,也不會自動造成實際傷害,使用者在確認畫面上有機會發現異常;缺點是使用者體驗會被打斷，如果 Agent 需要連續處理多個步驟，使用者可能被要求核准好幾次，而且這個防線的實際效力,取決於使用者是不是真的會仔細閱讀草稿內容,而不是看到熟悉的介面就反射性按下確認——這正是 IBM Bob 事件裡「人工核可淪為安全劇場」的同一種風險。
如果 Agent 需要同時存取私有資料跟具備對外通訊能力（例如一個能查詢帳戶餘額並執行轉帳的金融助理），拆解不受信任內容這一環，代表嚴格限制 Agent 只處理完全可信、受控的輸入來源——不直接讀取使用者貼上的任意網頁內容或第三方文件，如果真的需要處理這類內容，先透過一個獨立、權限更低的子流程做初步處理跟過濾，再把結果（而不是原始內容）交給有實際操作權限的主 Agent。這個方案的優點是保留了 Agent 的自主性跟功能完整性；缺點是架構複雜度最高，需要額外設計隔離層跟流程，而且「怎麼定義可信輸入」本身也需要持續維護跟更新,並不是設定一次就一勞永逸。
三個方案沒有絕對的優劣，選擇取決於你的 Agent 核心價值主張離不開哪個屬性。如果 Agent 的價值在於「幫我處理我自己的資料」，私有資料存取通常無法拿掉，該考慮方案二或三；如果 Agent 的價值在於「幫我瀏覽外部世界」，暴露於不受信任內容通常無法拿掉，該考慮方案一或二；如果 Agent 的價值在於「幫我自動完成連續動作，不需要我一直盯著」，對外通訊的自主性通常是核心賣點，該考慮方案一或三。實務上，很多 Agent 系統會針對不同功能模組分別套用不同方案——例如同一個助理，處理一般查詢時走方案一（不碰私有資料），處理帳務操作時走方案二（先出草稿再確認），沒有規定整個系統必須用同一套拆解邏輯。
如果你正在設計或稽核一個 Agent 系統的安全架構，二選一法則給了你一個具體的驗收標準：針對每一條實際的操作路徑，逐一確認它拆解的是哪一環,以及這個拆解在實務上是不是真的生效（例如「草稿確認」是否真的會被使用者認真閱讀，而不只是形式上的一道關卡）。這件事直接關係到你的問責基礎——一份記錄清楚「這個功能模組故意拿掉了私有資料存取，因為核心任務不需要」的架構文件，跟完全沒有評估過三要素就上線，是完全不同等級的治理責任;前者能在事後追查時明確指出「這條路徑的風險已被評估並緩解」,後者則需要從零開始重建整個判斷過程,而且很可能是在真實事件發生之後才被迫去做。