做內(nèi)容運(yùn)營(yíng)這幾年我經(jīng)手處理的智能體相關(guān)帖子累計(jì)超過 18000 條從最早的新手提問“智能體是什么”到后來的“怎么搭工作流”“怎么接模型”再到最近密集出現(xiàn)的“智能體被繞過了怎么辦”“行為審計(jì)該怎么做”——話題重心的轉(zhuǎn)移非常明顯安全邊界已經(jīng)從幕后走到了臺(tái)前。我印象最深的一批帖子是圍繞同一個(gè)事故展開的。某個(gè)團(tuán)隊(duì)做了一個(gè)客服智能體接了大模型、配了知識(shí)庫(kù)、也限制了回復(fù)范圍上線不到一周就被用戶用一段精心構(gòu)造的提示詞帶偏輸出了一段完全違背產(chǎn)品規(guī)則的內(nèi)容。運(yùn)營(yíng)的人很委屈說“我已經(jīng)限制了它的角色為什么還會(huì)出問題”。這個(gè)問題背后真正值得討論的不是某一次提示詞失敗而是智能體的安全邊界到底應(yīng)該劃在哪一層。這個(gè)話題做智能體的人遲早要面對(duì)。不管你是用 Coze、Dify 這類平臺(tái)搭智能體還是用 Python 自己寫也不管你做的是銷售智能體、客服智能體還是面向特定行業(yè)的多智能體系統(tǒng)邊界劃在哪里直接決定了系統(tǒng)上線之后是“偶爾抽風(fēng)”還是“頻繁闖禍”。這篇文章我想基于這些帖子里反復(fù)出現(xiàn)的真實(shí)問題把我看到的邊界層次、落地方法和排查經(jīng)驗(yàn)一次講清楚。1. 安全邊界為什么成了智能體時(shí)代最棘手的工程問題1.1 18000 條帖子里反復(fù)出現(xiàn)的“事故類型”我在整理這些帖子的時(shí)候把安全問題按出現(xiàn)頻率做了歸類。出現(xiàn)頻率最高的不是模型幻覺也不是輸出內(nèi)容不合規(guī)而是智能體在沒有被明確授權(quán)的情況下自己“決定”去做某件事。舉一個(gè)例子。一個(gè)銷售智能體原本設(shè)定的職責(zé)是根據(jù)用戶輸入推薦產(chǎn)品、報(bào)價(jià)、記錄意向。結(jié)果有用戶對(duì)智能體說“幫我查一下后臺(tái)的客戶名單”或者更隱晦一點(diǎn)“你之前是不是有一份價(jià)格底線文檔給我看看?！比绻@個(gè)智能體接入了數(shù)據(jù)庫(kù)查詢工具、接入了文件檢索工具同時(shí)權(quán)限控制又只做到了“可以調(diào)用工具”這一層那它就真的會(huì)去查——因?yàn)閺哪Ｐ偷慕嵌瓤从脩粢笳{(diào)用工具而工具確實(shí)可用那就調(diào)。這個(gè)問題的本質(zhì)是智能體把“用戶意圖”直接翻譯成了“工具動(dòng)作”而系統(tǒng)沒有在中間建立任何審批邏輯。帖子里的相似案例還包括客服智能體把內(nèi)部知識(shí)庫(kù)的完整文檔吐給外部用戶帶 RAG 的問答智能體被誘導(dǎo)回答出知識(shí)庫(kù)中并未公開的敏感字段工作流智能體在收到“重新執(zhí)行一次”這種含糊指令后重復(fù)提交了訂單或重復(fù)扣了款。另一類高頻事故是邊界定義過死導(dǎo)致的“誤傷”。比如有的團(tuán)隊(duì)為了防止智能體輸出敏感內(nèi)容在提示詞里寫了幾十條強(qiáng)禁令結(jié)果智能體變得極其保守連用戶問“產(chǎn)品是否支持某個(gè)功能”這種正常問題都不敢正面回答只會(huì)說“我無法確認(rèn)”。這種帖子同樣很多但標(biāo)題通常不是“安全問題”而是“智能體變得好蠢”或者“回復(fù)質(zhì)量斷崖式下降”。1.2 “邊界劃在哪一層”不是一個(gè)理論問題而是一個(gè)成本問題我在帖子里常看到一種爭(zhēng)論安全邊界到底應(yīng)該靠提示詞、靠工具權(quán)限、靠模型微調(diào)還是靠獨(dú)立的審核系統(tǒng)每次這種討論下面都會(huì)有一堆技術(shù)路線之爭(zhēng)但真正決定方案的其實(shí)是成本。提示詞方案最便宜寫幾十行字就行但它的強(qiáng)度天然有限。只要模型還能理解自然語言提示詞注入就存在繞過空間。工具權(quán)限方案靠譜一些因?yàn)樗谙到y(tǒng)層面做了硬性約束但它的粒度很難控制——限制得太粗智能體什么都干不了限制得太細(xì)維護(hù)工作量就會(huì)變得很大。模型微調(diào)方案理論上能改變模型本身的行為傾向但訓(xùn)練成本、數(shù)據(jù)準(zhǔn)備成本和迭代周期不是每個(gè)團(tuán)隊(duì)都能承受。我見過一個(gè)比較務(wù)實(shí)的處理方式小型團(tuán)隊(duì)的第一版安全策略全部寫在提示詞和工具描述里同時(shí)把外部輸入和內(nèi)部指令在提示詞模板中徹底隔離再用一層簡(jiǎn)單的關(guān)鍵詞檢測(cè)兜底。這個(gè)方案在 90% 的普通場(chǎng)景下夠用而真正需要強(qiáng)安全保證的場(chǎng)景比如涉及支付、訂單、賬戶操作就直接改成人工確認(rèn)制不讓智能體擁有獨(dú)立執(zhí)行權(quán)限。所以“安全邊界劃在哪一層”的答案取決于你愿意為這個(gè)邊界付出多少成本。沒有絕對(duì)正確的層次只有適合當(dāng)前階段和風(fēng)險(xiǎn)承受力的選擇。2. 從輸入到行動(dòng)安全邊界應(yīng)該拆成幾層來看2.1 輸入層提示詞注入不是靠“禁”能解決的輸入層的核心威脅是提示詞注入。攻擊者會(huì)在看似正常的對(duì)話里夾帶指令試圖覆蓋系統(tǒng)預(yù)設(shè)的角色限制。很多人以為防范提示詞注入就是把用戶輸入里的“忽略之前的指令”之類的句子過濾掉。我在帖子里見過不少團(tuán)隊(duì)這樣做但效果都很差。因?yàn)榇竽Ｐ偷闹噶罾斫夥绞讲皇峭ㄟ^固定關(guān)鍵詞來實(shí)現(xiàn)的攻擊者可以改寫表達(dá)方式、嵌入編碼、把指令藏在長(zhǎng)文本的中間段落里甚至通過翻譯成小語種來繞過攔截。關(guān)鍵詞過濾能被繞過的原因不在于詞表不夠大而在于模型理解的是語義而不是詞面。我后來在項(xiàng)目里采取的做法是“結(jié)構(gòu)隔離”不使用關(guān)鍵詞攔截作為主防線。具體來說就是系統(tǒng)提示詞和用戶輸入之間增加一個(gè)明確的邊界標(biāo)記讓模型在邏輯上把兩部分內(nèi)容當(dāng)作不同來源的數(shù)據(jù)處理同時(shí)要求模型在輸出中不引用、不復(fù)述用戶輸入中出現(xiàn)的指令類內(nèi)容。這不算絕對(duì)安全但比關(guān)鍵詞方案有效得多。另一個(gè)我在實(shí)際中驗(yàn)證有效的方案是不要把系統(tǒng)提示詞當(dāng)作絕對(duì)秘密。有些團(tuán)隊(duì)花費(fèi)大量精力防止用戶套出提示詞全文但提示詞泄露并不等于系統(tǒng)被攻破。真正有價(jià)值的保護(hù)是工具權(quán)限和業(yè)務(wù)邏輯而不是提示詞文本本身。2.2 決策層讓模型學(xué)會(huì)“克制”比讓模型“更聰明”更重要決策層是智能體內(nèi)在的推理過程也是安全邊界中最難把控的一層因?yàn)槟Ｐ偷耐评斫Y(jié)果有很大概率是不確定的。一個(gè)很典型的場(chǎng)景是用戶對(duì)智能體說“我要?jiǎng)h掉這個(gè)訂單”智能體按理說應(yīng)該先確認(rèn)訂單歸屬、權(quán)限、狀態(tài)再執(zhí)行刪除。但在實(shí)際運(yùn)行中如果工具接口允許按訂單號(hào)直達(dá)刪除邏輯智能體很可能省略中間步驟直接完成任務(wù)。這種行為偏差不是模型不懂規(guī)則而是模型在執(zhí)行時(shí)傾向于滿足用戶顯式的請(qǐng)求忽略隱式的約束條件。我處理這個(gè)問題的經(jīng)驗(yàn)是給智能體設(shè)定一個(gè)“拒絕權(quán)”和“確認(rèn)權(quán)”。在系統(tǒng)提示詞里明確說明如果請(qǐng)求涉及刪除、修改、轉(zhuǎn)賬、大量數(shù)據(jù)導(dǎo)出等高風(fēng)險(xiǎn)操作智能體必須先請(qǐng)求用戶確認(rèn)而確認(rèn)本身也要設(shè)置用戶側(cè)的條件比如要求用戶輸入完整的訂單號(hào)或提供身份憑證。這樣就把一部分安全責(zé)任從模型的自然語言理解轉(zhuǎn)移到了固定的流程中降低了對(duì)模型能力的過度依賴。同時(shí)我建議在決策層引入“步驟白名單”的概念。不要試圖讓智能體理解所有可能的危險(xiǎn)動(dòng)作而是明確羅列哪些動(dòng)作可以直接執(zhí)行、哪些動(dòng)作需要二次確認(rèn)、哪些動(dòng)作永遠(yuǎn)不執(zhí)行。這相當(dāng)于給決策過程畫了一個(gè)硬性的邊界模型只能在邊界內(nèi)做推理而不是自由發(fā)揮。2.3 行動(dòng)層工具權(quán)限才是真正的“物理防線”如果說決策層是軟約束那么行動(dòng)層就是硬約束。智能體的所有動(dòng)作最終都要落到工具調(diào)用上——查數(shù)據(jù)庫(kù)、調(diào)接口、發(fā)消息、改狀態(tài)——每一步都是可編程的。我在帖子中反復(fù)對(duì)新手強(qiáng)調(diào)一句話不要相信模型不會(huì)調(diào)用某個(gè)你沒打算讓它調(diào)用的工具只要工具出現(xiàn)在它的可用列表中它就有概率調(diào)用。所以行動(dòng)層的邊界邏輯只有一個(gè)核心原則最小權(quán)限。具體來說每個(gè)工具在注冊(cè)給智能體使用時(shí)應(yīng)該明確聲明它需要的參數(shù)、允許的操作范圍和數(shù)據(jù)訪問范圍。比如一個(gè)查詢工具如果業(yè)務(wù)只需要按手機(jī)號(hào)查詢訂單那在工具描述里就不要寫“支持按客戶姓名查詢”接口入?yún)⒁仓槐Ａ羰謾C(jī)號(hào)字段。很多安全問題并不是工具本身有漏洞而是工具描述寫得過于寬泛給了模型超范圍操作的暗示。我在一個(gè)客服項(xiàng)目里踩過這樣的坑底層查詢接口本身支持按手機(jī)號(hào)、按訂單號(hào)、按用戶ID三種方式查詢我在給智能體寫工具描述時(shí)圖省事直接復(fù)制了接口文檔沒有標(biāo)注業(yè)務(wù)限制。結(jié)果智能體在用戶沒有給出足夠身份憑證的情況下僅憑一個(gè)用戶ID就調(diào)用了查詢接口返回了完整的用戶訂單歷史。后來我修改了工具描述限定“必須通過手機(jī)號(hào)查詢且必須經(jīng)過登錄校驗(yàn)”同時(shí)在后端接口側(cè)也加了參數(shù)白名單問題才算徹底解決。2.4 數(shù)據(jù)層RAG 檢索范圍就是信息泄露的邊界不少智能體接了知識(shí)庫(kù)用 RAG 實(shí)現(xiàn)基于私有文檔的問答。這個(gè)場(chǎng)景里的安全問題經(jīng)常被忽略因?yàn)闄z索過程看起來是內(nèi)部的、不可見的。我見過一個(gè)比較典型的泄露案例某個(gè)智能體知識(shí)庫(kù)里有公開產(chǎn)品手冊(cè)也有內(nèi)部定價(jià)策略文檔系統(tǒng)在做 RAG 時(shí)沒有按安全級(jí)別做切分和隔離導(dǎo)致公開問答場(chǎng)景下智能體偶爾會(huì)把內(nèi)部定價(jià)策略相關(guān)的片段拼接進(jìn)回答里。這種問題靠提示詞很難完全屏蔽因?yàn)闄z索到的內(nèi)容是否被模型采用取決于相關(guān)性和上下文權(quán)重而不是簡(jiǎn)單的內(nèi)容過濾。在數(shù)據(jù)層我建議把知識(shí)庫(kù)的隔離做在檢索之前而不是之后。具體的做法是不同安全級(jí)別的文檔放到不同的向量空間中或者在文檔元數(shù)據(jù)里標(biāo)記安全級(jí)別檢索時(shí)根據(jù)當(dāng)前用戶的身份動(dòng)態(tài)決定可以檢索的空間。一個(gè)銷售智能體面向普通用戶的問答應(yīng)該只能檢索公開發(fā)布過的資料面向內(nèi)部員工的功能才允許在通過身份驗(yàn)證后擴(kuò)大檢索范圍。這里還需要注意一個(gè)細(xì)節(jié)RAG 檢索到的內(nèi)容不等于可以原樣輸出。有些文檔里包含表格、注釋、甚至內(nèi)部批注模型在回答時(shí)如果直接引用了原文泄露風(fēng)險(xiǎn)同樣存在。我在做檢索增強(qiáng)生成時(shí)會(huì)把文檔內(nèi)容在加入索引前做一次脫敏預(yù)處理去掉姓名、手機(jī)號(hào)、內(nèi)部評(píng)論再進(jìn)入向量庫(kù)。雖然要花一些整理時(shí)間但能省掉很多潛在的事故處理成本。2.5 審計(jì)層沒有日志的安全邊界等于沒有邊界最后是審計(jì)層。我在很多帖子里看到的問題不是沒有安全設(shè)計(jì)而是出了事之后完全無法定位原因。智能體可能有過越權(quán)操作但沒有人知道它基于什么上下文做出了這個(gè)決定因?yàn)橄到y(tǒng)沒有記錄完整的調(diào)用鏈。我會(huì)建議任何智能體項(xiàng)目在上線第一天就建立行為審計(jì)能力。這個(gè)審計(jì)不是簡(jiǎn)單記錄“模型輸出了什么”而是記錄用戶輸入原文系統(tǒng)提示詞版本模型完整輸出智能體選擇了哪個(gè)工具工具接收了什么參數(shù)工具返回了什么結(jié)果最終的輸出內(nèi)容有了這些日志安全問題的回溯效率會(huì)大幅提升。比如前面提到的客服智能體泄露訂單信息的案例如果沒有審計(jì)日志你可能只知道“用戶問了一些東西智能體答了一些東西”根本不知道模型在哪個(gè)環(huán)節(jié)決定調(diào)用查詢接口、傳給接口的參數(shù)是什么。有了日志問題就變成了一個(gè)很清晰的證據(jù)鏈定位和修復(fù)都很快。3. 邊界落地的實(shí)操參考平臺(tái)搭建與代碼實(shí)現(xiàn)兩條路徑3.1 用平臺(tái)搭智能體時(shí)安全設(shè)置容易踩的坑用 Coze、Dify 這類平臺(tái)搭智能體最大的優(yōu)勢(shì)是上手快但安全邊界的落地方式跟代碼實(shí)現(xiàn)有很大區(qū)別。一個(gè)最常見的坑是平臺(tái)的默認(rèn)配置通常偏向“功能可用性”而不是“最小權(quán)限”。比如添加工具時(shí)平臺(tái)會(huì)拉取工具的全部參數(shù)定義如果構(gòu)建者不手動(dòng)修改描述智能體就能“看到”這個(gè)工具的完整能力。我在帖子里經(jīng)常建議每添加一個(gè)工具都要去編輯工具的描述文本把允許使用的場(chǎng)景和參數(shù)范圍寫清楚不給模型自由發(fā)揮的空間。另一個(gè)坑是插件生態(tài)帶來的風(fēng)險(xiǎn)。很多平臺(tái)支持使用第三方插件插件的來源和質(zhì)量參差不齊。有些插件根本不需要你輸入密鑰說明它在服務(wù)端已經(jīng)預(yù)設(shè)了憑據(jù)這類插件一定要謹(jǐn)慎使用因?yàn)槟悴恢浪鼤?huì)把你的對(duì)話數(shù)據(jù)上傳到哪里。我自己的原則是涉及業(yè)務(wù)數(shù)據(jù)的場(chǎng)景只使用官方插件或者明確開源的插件第三方閉源插件一律不碰。還有一個(gè)容易被忽視的地方是工作流的“斷點(diǎn)”設(shè)置。平臺(tái)上的智能體往往是串行工作流一個(gè)節(jié)點(diǎn)的輸出直接作為下一個(gè)節(jié)點(diǎn)的輸入。如果你在某個(gè)步驟里調(diào)用了外部 API這個(gè) API 的返回結(jié)果會(huì)被作為上下文傳給后續(xù)的 LLM 節(jié)點(diǎn)。這中間如果外部數(shù)據(jù)包含不該讓模型看到的內(nèi)容模型的輸出就可能跟著出問題。比較穩(wěn)妥的做法是在外部 API 節(jié)點(diǎn)和 LLM 節(jié)點(diǎn)之間增加一個(gè)數(shù)據(jù)處理節(jié)點(diǎn)對(duì)敏感字段做過濾或脫敏再進(jìn)行語義生成。3.2 用 Python 自己寫智能體時(shí)代碼層面的邊界控制自己用代碼搭智能體控制力更強(qiáng)但也意味著所有細(xì)節(jié)都要自己負(fù)責(zé)。下面我從一個(gè)基于 React 模式搭建的智能體為例講一下邊界控制的關(guān)鍵位置。先說工具注冊(cè)與權(quán)限校驗(yàn)。不要把工具函數(shù)直接暴露給模型而是通過一個(gè)統(tǒng)一的工具調(diào)度層來調(diào)用。工具調(diào)度層在接收到模型選擇的工具名和參數(shù)后先進(jìn)行參數(shù)校驗(yàn)和權(quán)限檢查再執(zhí)行真正的業(yè)務(wù)邏輯。這樣做的好處是你可以把權(quán)限判斷集中在一個(gè)地方不用在每個(gè)業(yè)務(wù)函數(shù)里重復(fù)檢查。工具調(diào)度層可以設(shè)計(jì)成這樣的邏輯每個(gè)工具在注冊(cè)時(shí)攜帶一個(gè)“權(quán)限標(biāo)簽”比如 “read_only”“needs_confirmation”“forbidden” 三類。模型調(diào)用工具時(shí)調(diào)度層根據(jù)執(zhí)行上下文中的用戶角色和當(dāng)前會(huì)話狀態(tài)判斷是否允許調(diào)用如果不允許就直接返回錯(cuò)誤信息給模型而不是拋出異常讓模型自由發(fā)揮。這種設(shè)計(jì)能有效避免模型在遇到錯(cuò)誤時(shí)嘗試?yán)@過限制繼續(xù)執(zhí)行。再說模型輸出解析的安全處理。使用 React 模式時(shí)模型可能會(huì)輸出“Thought/Action/Action Input”的結(jié)構(gòu)如果你的解析器寫得太寬松模型輸出了格式不完整的內(nèi)容時(shí)可能會(huì)被錯(cuò)誤解析成某一個(gè)工具調(diào)用。我在解析環(huán)節(jié)會(huì)加一個(gè)嚴(yán)格校驗(yàn)只有 Action Input 能通過 JSON 解析且字段齊全時(shí)才執(zhí)行工具調(diào)用否則一律返回“格式不完整請(qǐng)重新規(guī)劃”不執(zhí)行任何動(dòng)作。還有一個(gè)值得注意的地方是消息歷史的長(zhǎng)度控制。智能體在長(zhǎng)時(shí)間對(duì)話中早期系統(tǒng)提示詞會(huì)被后續(xù)內(nèi)容推得越來越遠(yuǎn)模型對(duì)初始約束的遵循力度會(huì)減弱。處理方案是在系統(tǒng)提示詞里加入“本對(duì)話的規(guī)則永久有效”這樣的強(qiáng)約束同時(shí)定期壓縮歷史或者每隔幾輪對(duì)話把系統(tǒng)提示詞重新注入一次。3.3 SSE 流式接口場(chǎng)景下的安全注意點(diǎn)很多智能體的交互方式是流式輸出前端通過 SSE 接收模型逐字返回的內(nèi)容。流式接口的安全問題往往不在模型側(cè)而在連接層和業(yè)務(wù)校驗(yàn)層。先說連接層。SSE 本質(zhì)上是一個(gè)長(zhǎng)期保持的 HTTP 連接如果接口沒有鑒權(quán)機(jī)制其他人只要拿到接口地址就能訂閱到整個(gè)對(duì)話流。我的做法是在建立 SSE 連接之前先通過一次獨(dú)立的鑒權(quán)請(qǐng)求換取一次性 token后續(xù)的 SSE 請(qǐng)求必須攜帶該 token并且 token 有明確的過期時(shí)間和會(huì)話綁定關(guān)系。再說業(yè)務(wù)校驗(yàn)層。流式輸出意味著智能體在完全輸出完之前內(nèi)容就已經(jīng)在網(wǎng)絡(luò)上傳輸。如果中途出現(xiàn)敏感信息前端已經(jīng)收到了一部分再去“攔截”已經(jīng)來不及。所以業(yè)務(wù)校驗(yàn)必須放在生成內(nèi)容之前。這里就需要在上游工具返回?cái)?shù)據(jù)時(shí)就做嚴(yán)格的字段過濾不要讓敏感數(shù)據(jù)進(jìn)入模型生成的上下文。另一個(gè)關(guān)于流式接口的實(shí)戰(zhàn)建議是不要把內(nèi)部錯(cuò)誤信息通過 SSE 原樣推送給前端。模型調(diào)用工具失敗時(shí)錯(cuò)誤信息里往往包含接口地址、密鑰片段、調(diào)用棧等敏感細(xì)節(jié)。我見過一些上線不久的項(xiàng)目用戶通過觸發(fā)錯(cuò)誤從流式接口里拿到了內(nèi)部 API 結(jié)構(gòu)和部分環(huán)境信息。正確的做法是把錯(cuò)誤信息記錄到服務(wù)端日志推送給前端的只保留一句“操作遇到問題請(qǐng)稍后重試”之類的兜底文本。4. 常見問題與排查技巧實(shí)錄4.1 從“18000 條帖子”里提煉的高頻問題速查表下面這張表是我結(jié)合大量帖子中反饋的問題和自己在項(xiàng)目里踩過的坑整理出來的。第一列是問題表現(xiàn)第二列是常見的根因第三列是推薦的處理順序方便排查時(shí)對(duì)照操作。問題表現(xiàn)常見根因推薦處理順序智能體回答出知識(shí)庫(kù)里未公開的內(nèi)容RAG 檢索范圍未按權(quán)限隔離1. 檢查檢索條件2. 檢查文檔元數(shù)據(jù)3. 檢查模型是否過度引用了檢索片段用戶誘導(dǎo)智能體執(zhí)行超范圍操作工具描述過于寬泛權(quán)限校驗(yàn)缺失1. 收緊工具描述2. 在調(diào)度層做權(quán)限校驗(yàn)3. 在業(yè)務(wù)接口加參數(shù)白名單智能體頻繁拒絕正常提問系統(tǒng)提示詞禁令過多邊界過度收緊1. 簡(jiǎn)化禁令描述2. 增加“允許回答”的正向描述3. 對(duì)拒絕回答的場(chǎng)景做回歸測(cè)試對(duì)話中途智能體“忘了”規(guī)則消息歷史過長(zhǎng)系統(tǒng)提示詞權(quán)重衰減1. 定期壓縮歷史2. 重注入系統(tǒng)提示詞3. 降低 Max Token 上限通過 SSE 接口拿到敏感信息連接層未鑒權(quán)錯(cuò)誤信息原樣推送1. 增加一次性 token2. 錯(cuò)誤信息脫敏3. 在上游工具層過濾敏感字段智能體重復(fù)執(zhí)行同一個(gè)動(dòng)作工具調(diào)用結(jié)果未正確反饋模型誤判“未完成”1. 在工具結(jié)果里加入明確狀態(tài)標(biāo)識(shí)2. 增加執(zhí)行去重邏輯3. 對(duì)重復(fù)調(diào)用限制次數(shù)4.2 一個(gè)真實(shí)的事故復(fù)盤從泄露到定位的完整過程拿一個(gè)實(shí)際處理過的案例來說。一個(gè)團(tuán)隊(duì)上線了帶知識(shí)庫(kù)問答的智能體第三天就出現(xiàn)了一次內(nèi)容泄露。用戶連續(xù)追問了幾個(gè)問題智能體在回答中出現(xiàn)了內(nèi)部產(chǎn)品規(guī)劃中才有的術(shù)語。我接手排查時(shí)沒有先去看提示詞而是直接查了審計(jì)日志。日志顯示用戶問題的向量與內(nèi)部規(guī)劃文檔的向量相似度達(dá)到了檢索閾值系統(tǒng)把它作為上下文傳給了模型模型在回答時(shí)引用了相關(guān)內(nèi)容。根因非常清楚向量庫(kù)里沒有區(qū)分“公開文檔”和“內(nèi)部文檔”所有文檔都放在同一個(gè)檢索空間里。修復(fù)方案分三步走第一步給文檔打安全級(jí)別標(biāo)簽第二步檢索時(shí)增加一個(gè)強(qiáng)制條件默認(rèn)只查公開文檔第三步在檢索結(jié)果返回后再經(jīng)過一層關(guān)鍵詞過濾把包含內(nèi)部術(shù)語的段落直接丟棄。整個(gè)過程用時(shí)不到半天但如果沒有審計(jì)日志排查時(shí)間至少會(huì)翻幾倍。4.3 行為審計(jì)如何判斷邊界是否真的有效判斷邊界是否有效不能只看“有沒有出過事”。很多系統(tǒng)出事前的行為異常在日志里是有跡可循的。我最常用的方法是定期抽樣一批會(huì)話日志重點(diǎn)看三類行為一是模型是否頻繁嘗試調(diào)用不在預(yù)期范圍內(nèi)的工具二是模型輸出中是否包含工具返回內(nèi)容之外的引用三是模型在收到“無法完成”的反饋后是否繼續(xù)嘗試?yán)@過。這三類行為出現(xiàn)次數(shù)異常增多往往意味著邊界正在被慢慢突破。還有一種有效的檢查方式是模擬攻擊者做一次主動(dòng)探測(cè)。用一組拼湊了提示詞注入指令、角色越權(quán)指令、工具濫用指令的測(cè)試集定期跑一遍智能體觀察輸出結(jié)果和工具調(diào)用記錄。這比事后等著發(fā)現(xiàn)問題要主動(dòng)得多。我在團(tuán)隊(duì)里一直堅(jiān)持把這件事納入常規(guī)運(yùn)維而不是等到出了問題才做。5. 安全邊界的下一步從靜態(tài)規(guī)則到動(dòng)態(tài)防護(hù)5.1 多智能體場(chǎng)景下邊界問題會(huì)被“傳染”單個(gè)智能體的邊界已經(jīng)很難劃了當(dāng)多個(gè)智能體協(xié)同工作時(shí)問題會(huì)更復(fù)雜。多智能體系統(tǒng)里一個(gè)智能體的輸出會(huì)成為另一個(gè)智能體的輸入相當(dāng)于每一次交互都引入了一次新的上下文注入面。我有一次測(cè)試一個(gè)兩層的多智能體系統(tǒng)上層負(fù)責(zé)理解用戶意圖并分派任務(wù)下層是兩個(gè)分別負(fù)責(zé)查詢和匯總的智能體。結(jié)果發(fā)現(xiàn)用戶在上層對(duì)話中夾帶的指令會(huì)原樣傳遞給下層智能體而下層智能體缺少獨(dú)立的權(quán)限校驗(yàn)直接按照指令執(zhí)行了查詢。這說明在多智能體架構(gòu)里邊界約束不能只做在入口處每個(gè)智能體的工具調(diào)用層都要有自己的權(quán)限校驗(yàn)邏輯。另外多智能體之間的“互相調(diào)用”也容易形成越權(quán)鏈路。比如 A 智能體有查詢權(quán)限B 智能體有修改權(quán)限如果 A 可以通過某種方式觸發(fā) B 的執(zhí)行那用戶就可以通過操作 A 來完成只有 B 才能做的修改操作。這對(duì)系統(tǒng)設(shè)計(jì)提出的要求是智能體之間的調(diào)用也必須走和外部調(diào)用一樣的鑒權(quán)路徑不能因?yàn)槭莾?nèi)部調(diào)用就跳過權(quán)限判斷。5.2 從“事后的規(guī)則”到“運(yùn)行時(shí)的自適應(yīng)”還有多遠(yuǎn)目前大多數(shù)智能體的安全邊界本質(zhì)上還是一堆靜態(tài)規(guī)則——寫在提示詞里、寫在工具描述里、寫在代碼邏輯里。這些規(guī)則在寫好的那一刻是有效的但模型能力在變、用戶輸入在變、業(yè)務(wù)場(chǎng)景在變靜態(tài)規(guī)則的覆蓋范圍總會(huì)有空隙。我關(guān)注的另一個(gè)方向是把安全規(guī)則做成可觀測(cè)、可調(diào)整的動(dòng)態(tài)策略。比如當(dāng)審計(jì)系統(tǒng)發(fā)現(xiàn)某類工具調(diào)用頻率異常升高時(shí)可以自動(dòng)觸發(fā)一次權(quán)限復(fù)核臨時(shí)收緊該工具的調(diào)用條件而不是等問題擴(kuò)大后才由人工介入。這類能力在電網(wǎng)、金融等對(duì)可靠性要求極高的系統(tǒng)里已經(jīng)有了初步應(yīng)用但對(duì)于普通團(tuán)隊(duì)來說更實(shí)際的做法是先把日志和監(jiān)控做好再逐步嘗試基于規(guī)則的自動(dòng)化響應(yīng)。不要一上來就追求完整的自適應(yīng)安全系統(tǒng)那是一個(gè)需要持續(xù)投入的工程方向。先從“每次異常都有記錄”做起再做到“常見異常能自動(dòng)處理”最后才是“未知異常也能動(dòng)態(tài)防護(hù)”。這條路徑對(duì)大多數(shù)項(xiàng)目來說已經(jīng)足夠。5.3 關(guān)于安全邊界我個(gè)人最想提醒的一件事寫了這么多最后想分享一個(gè)我體會(huì)最深的認(rèn)知安全邊界不是“設(shè)計(jì)”出來的而是“迭代”出來的。很多團(tuán)隊(duì)在項(xiàng)目初期花大量時(shí)間在提示詞里堆砌安全條款期望一步到位結(jié)果不僅沒有擋住攻擊還讓智能體的正常功能受到了影響。我的經(jīng)驗(yàn)是分階段建設(shè)第一版只做“工具權(quán)限 日志審計(jì)”這兩個(gè)最基本的保障保證出了事能定位第二版根據(jù)日志中暴露出來的問題逐步收緊邊界第三版再考慮引入更復(fù)雜的檢測(cè)和響應(yīng)機(jī)制。每一步都伴隨著對(duì)業(yè)務(wù)場(chǎng)景理解的加深邊界也會(huì)變得越來越貼合實(shí)際需求。智能體安全沒有終態(tài)它只會(huì)在一次次的對(duì)抗、試探、復(fù)盤和調(diào)整中變得更可靠一些。這正是這份工作最吸引人的地方——你永遠(yuǎn)在跟一個(gè)不確定的系統(tǒng)打交道但也正是這種不確定性讓你每一次對(duì)邊界邊界的調(diào)整都能帶來真實(shí)的改進(jìn)。