客戶最擔心的不是答錯，而是做錯
設想一個銷售方案 Agent。員工讓它讀取客戶資料、檢索產品庫、生成方案，并把文件發(fā)到工作群。任務看起來很普通，但鏈路里藏著不少問題：
- 客戶資料中的一段外部文本，誘導 Agent 讀取其他目錄；
- 產品庫里有員工本來無權查看的價格文件；
- 消息工具默認允許發(fā)送，Agent 把未審核方案發(fā)給了客戶；
- 接口超時后自動重試，造成同一條記錄被提交兩次；
- 事故發(fā)生后，日志只顯示“工具調用失敗”，無法還原當時讀過什么。
- 傳統(tǒng)軟件主要限制用戶點擊哪個菜單。Agent 會自行規(guī)劃步驟，風險邊界會隨著上下文、文件、工具和模型判斷動態(tài)變化。因此，企業(yè)要控制一條正在運行的任務鏈，靜態(tài)賬號權限只能覆蓋其中一部分。
Anthropic 做了什么：把安全邊界放進執(zhí)行環(huán)境
Anthropic 在 2026 年 5 月發(fā)布的工程文章中介紹了 Claude 在不同產品中的隔離方式。其核心思路是：不要只依賴模型“記住安全要求”，還要用操作系統(tǒng)沙箱、容器、虛擬機、文件邊界和網(wǎng)絡策略限制實際能力。Anthropic，2026-05-25
文章披露了兩個值得企業(yè)平臺關注的數(shù)據(jù)：
- 早期方案需要用戶批準約 93% 的工具調用，頻繁彈窗很快造成審批疲勞；
- 引入沙箱后，審批提示減少了 84%，系統(tǒng)只在真正越過邊界時打斷用戶。
- 企業(yè)不必讓所有 Agent 使用同一種沙箱。更可行的做法，是把低風險動作放在明確邊界內自動執(zhí)行，把高風險動作留給策略或人工確認。控制越精確，安全與效率越不需要互相犧牲。
把 Agent 放進生產環(huán)境，至少要管住五件事
身份和數(shù)據(jù)范圍要跟著任務走
平臺要知道任務由誰發(fā)起，并把用戶身份傳遞到知識庫、數(shù)據(jù)庫和業(yè)務系統(tǒng)。Agent 不應因為擁有一個系統(tǒng)賬號，就繞過員工原有的數(shù)據(jù)權限。
客戶在 PoC 中可以直接測試：讓不同崗位提問同一個問題，檢查檢索結果、字段和附件是否按原系統(tǒng)權限變化。只在應用入口做一次登錄校驗，不能證明運行過程安全。
工具權限要細到具體動作
同一個工具里的動作風險并不相同。查詢訂單和取消訂單、生成郵件和發(fā)送郵件、創(chuàng)建草稿和正式發(fā)布，不能共用一條權限。
更實用的策略通常有三類：
- 允許：低風險、可逆、限定范圍內的動作自動執(zhí)行；
- 拒絕：超出任務和崗位邊界的動作直接阻斷；
- 需確認：發(fā)送、刪除、付款、發(fā)布等敏感動作進入人工確認。
- 確認界面還要展示即將執(zhí)行的內容、目標對象和主要依據(jù)。只顯示“是否允許調用某工具”，用戶很難作出有效判斷。
代碼、文件和網(wǎng)絡需要隔離
如果 Agent 能運行代碼或處理附件，就要限制它能訪問的目錄、能啟動的進程和能連接的網(wǎng)絡地址。臨時任務應盡量使用隔離環(huán)境，任務結束后清理狀態(tài)。
對外部內容也不能只做文件格式檢查。網(wǎng)頁、郵件、文檔和工具返回值都可能攜帶提示注入。平臺需要區(qū)分“用戶指令”和“外部資料”，并對外部指令保持低信任。
人工介入后，任務還要能繼續(xù)
人工介入不應等同于“遇到問題就全部重做”。長任務需要在關鍵步驟保存狀態(tài)，支持暫停、修改參數(shù)、替換材料和繼續(xù)執(zhí)行。
如果任務已經(jīng)完成了不可逆動作，恢復機制還要知道哪些步驟可以重試，哪些步驟必須先核對外部系統(tǒng)。Checkpoint、冪等鍵和補償流程，是生產 Agent 常被忽略的基本功。
審計要能還原一次任務
審計記錄至少應包含：
- 發(fā)起人、使用的 Agent 和版本；
- 輸入材料、檢索來源和權限上下文；
- 模型、工具、參數(shù)及返回結果；
- 命中的允許、拒絕或確認策略；
- 人工確認人及其決定；
- 失敗、重試、恢復和最終輸出。
- 有了這些信息，平臺團隊才能判斷問題來自模型、數(shù)據(jù)、工具、策略還是流程。否則所謂審計只是保留了一段難以解釋的對話。
這會怎樣改變企業(yè)級智能體平臺選型
過去的平臺演示通常強調模型接入和流程編排。現(xiàn)在客戶需要把“運行時控制”單獨列為一組驗收項。
| 選型對象 | 可以重點檢查的方向 |
|---|---|
| Anthropic | 產品環(huán)境中的沙箱、文件與網(wǎng)絡邊界、工具審批設計 |
| OpenAI | 企業(yè)工作空間、連接器、工具調用和管理員控制 |
| Microsoft Copilot Studio | 與 Entra、Power Platform、連接器和數(shù)據(jù)策略的結合 |
| Google 企業(yè) Agent 平臺 | 云身份、數(shù)據(jù)治理、Agent 運行與企業(yè)搜索的結合 |
| Rich AIBox | 工作空間、工具策略、沙箱、人工介入、任務恢復和審計是否形成統(tǒng)一運行面 廠商能力會持續(xù)更新，正式選型應以當期產品文檔和現(xiàn)場測試為準。比較的關鍵也不是誰的菜單更多，而是誰能證明一次真實任務始終沒有越過企業(yè)邊界。 |
把運行時控制落到企業(yè)平臺：以 Rich AIBox 為例
彩訊股份在 Rich AIBox 中把控制對象從“應用”繼續(xù)拆到任務、工具和動作。放到真實客戶場景里，可以沿著下面六個問題核驗：
- Workspace 邊界：團隊、Agent、知識和工具按工作空間組織，減少跨場景誤用。
- 工具策略：對工具或動作配置允許、拒絕和需確認，敏感動作進入人工確認。
- 隔離運行：對代碼、文件和外部連接設置沙箱與資源邊界。
- HITL：在關鍵步驟暫停，讓業(yè)務人員查看依據(jù)、修改參數(shù)或批準執(zhí)行。
- Checkpoint：長任務保存過程狀態(tài)，支持失敗后的恢復和重試控制。
- 運行審計：記錄調用鏈、策略命中、人工決策和異常過程，供問題定位與復盤。
- 上述功能中，部分仍屬于規(guī)劃或運行面設計方向。對外發(fā)布和客戶選型前，應根據(jù)當前版本逐項確認已上線能力、配置粒度和適用部署方式。
- 把這些能力放進前面的評價框架，客戶真正要看的不是功能名稱，而是它們能否在同一條真實任務中協(xié)同生效：資源有沒有越界、敏感動作是否被攔下、人工確認是否出現(xiàn)在正確節(jié)點、失敗任務能否恢復、審計記錄能否還原過程。
建議在 PoC 里做六次壓力測試
普通演示很難暴露權限問題。可以主動設置以下測試：
- 越權檢索：不同角色訪問同一知識庫，驗證結果和字段是否隔離。
- 提示注入：在附件或網(wǎng)頁中加入誘導指令，觀察 Agent 是否越過原任務。
- 敏感動作：讓 Agent 發(fā)送、刪除或發(fā)布，檢查是否觸發(fā)正確的確認策略。
- 接口超時：在動作完成后制造超時，檢查是否發(fā)生重復提交。
- 中途換人：任務暫停后由另一名員工接手，檢查授權和審計是否更新。
- 事故回放：只依靠平臺記錄，還原一次任務的材料、決策和動作。
- 壓力測試的結果應進入驗收報告，而不是只由廠商口頭解釋。
常見問題
有人工審批，就能避免 Agent 風險嗎？
不能。審批過多會造成疲勞，用戶可能習慣性點擊同意。更合理的方式是讓低風險動作在受控邊界內自動執(zhí)行，只把高風險、越界或不確定動作交給人工。
私有化部署是否等于安全？
不等于。私有化解決了部分部署和數(shù)據(jù)邊界問題，但身份傳遞、工具權限、提示注入、異常恢復和審計仍要單獨設計。
只做知識問答，也需要運行時控制嗎？
需要，但強度不同。知識問答至少要控制文檔權限、來源、外部內容和輸出留痕；一旦能調用工具或更新系統(tǒng)，控制要求會明顯提高。
Rich AIBox 的這些能力都已經(jīng)上線了嗎？
相關能力會隨版本持續(xù)完善。客戶可在 PoC 中核驗策略粒度、隔離方式、恢復能力和審計字段，并按實際部署版本確定驗收范圍。