← 隨筆

邊界而非指令：如何保持對自主 AI 代理的控制

為什麼對 AI 代理的控制不能建立在提示詞中的指令上——以及如何建立在技術邊界上。一次工作階段中的五起事故。

6 分鐘閱讀
Telegram原文
邊界而非指令：如何保持對自主 AI 代理的控制

隨著 AI 代理變得越來越自主，我們越來越常試圖用習慣的方式管理它們——在提示詞中寫規則：「別碰這個」、「只在那裡工作」、「永遠不要做那個」。在 三個並行代理的實驗 中，我在兩天內收集了一批活生生的案例，說明這種方式在哪裡失效——以及另一種方式在哪裡奏效。文章的論點很簡單：指令是代理以某種機率執行的請求；邊界是系統的屬性，不取決於服從。當代理只有一個、且在監督下工作時，差別看起來只是風格問題。當代理變多時，它就成了架構問題。

一次工作階段中的五起事故

以下所有案例都發生在這個部落格的一次工作階段中——它們都有記錄，每一個都說明了以文字進行管理的一種失效方式。

沒有指令——事故發生了。 代理在為自己的任務做準備時，在 git stash 共用目錄中執行了操作，並把我未提交、與其任務無關的檔案收進了 stash。沒有人「違反」任何東西：禁令根本不存在。這是指令的根本特性——它們總是在事故之後才被寫下。要寫出代理不該做的事的完整清單，是不可能的。

指令存在過——卻沒有奏效。 第一次事故之後，我給代理們加了一條明確規則：「嚴格在自己的工作目錄中作業」。其中一個代理還是在主目錄中執行了 git 命令——只是用絕對路徑存取了它。不是出於惡意，也不是出於愚蠢：模型是機率性的，而遵守文字規則同樣是一個機率，乘以上下文長度和執行次數。

技術邊界默默奏效了。 在同一個實驗中，最被預期的事故一次都沒有發生——「某個代理把所有人的分支都切換了」。不是因為代理們很小心，而是因為 git worktree 在物理上不允許把同一個分支檢出到兩份工作副本中。防護內建於工具之中。不需要記住它，不需要遵循它——它就這樣存在。

指令被放在了本該由邊界站的位置。 最令人不快的發現：這個部落格的正式環境是由提示詞中的一行字守護的。Push 到 master 會觸發自動部署，而每個代理與它之間只隔著「不要 git push」這段文字。它守住了——但這是運氣，不是控制：這裡真正的邊界是存取權限、受保護分支、沒有寫入權限的權杖。請求被放在了鎖的位置上。

邊界置於代理本身之上。 一次工作階段中，執行環境兩次攔下的已經不是受試代理，而是我的主要助理：權限分類器封鎖了對正式伺服器的 SSH 連線，以及對未提交修改的大量刪除——這些動作形式上源自任務，但需要明確的人類「同意」。兩次封鎖都是正確的。而兩次都發生在代理的「紀律」之上，那個代理相當真誠地認為自己是在按計畫行事。

原則並不新——新的只是實體

軟體工程早在 LLM 之前就學過這一課。在豐田的生產系統中，這個原則叫做 poka-yoke：防止錯誤的是流程的裝置，而不是執行者的警覺。只能以正確方向插入的零件，比「請正確插入」的標語更可靠。在平台工程中，同樣的東西叫做 guardrails，在安全領域叫做 defense in depth。到處都是同一個想法： 不要依賴執行者讀過、理解過且沒有忘記——要讓錯誤的動作不可能發生，或代價高昂。

「指令是請求。邊界是系統的屬性。建立在請求之上的控制，不是控制，而是帶有累積效應的運氣。」

– 兩天並行代理工作的主要結論

面對 AI 代理，這個古老的原則因三個原因而更加尖銳。代理很多——指令失效的機率會乘以每個代理的每次執行。代理很快——從「開始出錯」到「徹底搞砸」只隔幾秒，人來不及介入。而代理字面遵從，卻不可靠：它們比任何初級工程師都更賣力地執行提示詞文字，卻仍是機率性的——而機率性地遵守規則，在大規模下必然導致違規。

邊界在實踐中是什麼樣子

我在這次工作階段之後建立的分層——從檔案系統到驗證：

  • 檔案系統： 每個代理都有自己的工作副本（git worktree， Anthropic 推薦 用於並行工作階段，在 Claude Code 中已內建），而在作業系統層面則是沙箱： Claude Code 中的沙箱化 用作業系統的標準原語隔離檔案系統和網路——據 Anthropic 稱，這使他們內部的權限請求減少了 84%，而成功的提示注入仍被鎖在其中。
  • 寫入權限： 產品與 master 靠權限保護，而不是靠提示詞——受保護分支、無推送權限的權杖、為代理設定獨立帳號。要求在提示詞中保留也可以，但作為第二層。
  • 執行環境： worktree 不隔離資料庫、連接埠和容器——它們在所有副本之間是共用的。會啟動測試和伺服器的代理需要一次性資源：臨時資料庫、專屬連接埠、每個代理一個容器。
  • 動作權限： 不可逆操作須經確認或分類器——例如 Claude Code 的 auto mode，它評估每個動作，而不是要麼什麼都問、要麼什麼都不問。這是一道只會因人的明確決定而移動的邊界。
  • 依產物驗證： 不要相信代理的自我報告，而要相信磁碟上的痕跡。我那個卡住的代理在介面上看起來還在運作；診斷的依據是它的副本在二十分鐘內沒有出現新檔案。提交到自己的分支也是同樣的道理：結果要能經得起故障和代理的樂觀。

這套方案中的指令並沒有消失——它們成為最後一層，而不是第一層。提示詞裡的「在自己的目錄裡工作」仍然有用：它會降低嘗試的頻率。但在嘗試與事故之間，應該有一道邊界，而不是希望。

誠實的保留意見

邊界並非絕對：沙箱會被繞過，分類器會出錯，而公開的繞過分析也經常顯示這一點。因此邊界是分層建構的——就像安全領域的一切。而且邊界在起步時比指令更貴：設定 worktree、權限和沙箱要花數小時，在提示詞裡寫一行只要幾秒。不對稱在另一面：邊界只需付一次成本，指令則要付出每次執行都可能失敗的機率。我設定隔離的成本，在第一次重跑實驗時就回本了，那次實驗沒有發生任何衝突。

結論

本系列的提問是：如何把 AI 代理嵌入實際工作，同時不失去控制。本文的答案是：控制不是寫給代理的內容，而是圍繞它建構的東西。在往提示詞裡再加一句「永遠不要做 X」之前，值得先問自己：能不能讓 X 在技術上不可能？如果可以——那才是投入努力的正確位置。讓提示詞去請求；禁止應該是系統的職責。

來源與參考

← 所有隨筆