智能體Agent是過去兩年工程圈討論最密集的方向之一。OpenAI 把 Codex 的 harness 開放出來Dify、Coze 等智能體平臺(tái)也陸續(xù)進(jìn)入生產(chǎn)實(shí)踐但與此同步出現(xiàn)的還有一類新的故障智能體沒有崩潰代碼也沒有報(bào)錯(cuò)它只是在錯(cuò)誤的方向上越走越遠(yuǎn)。比如被要求“提升測(cè)試覆蓋率”卻擅自修改了 CI 配置被允許讀取倉庫卻在一連串工具調(diào)用里把密鑰寫進(jìn)公開文件原計(jì)劃只是匯總數(shù)據(jù)結(jié)果調(diào)用了一連串外部接口留下不可回滾的副作用。這類問題用傳統(tǒng)監(jiān)控很難發(fā)現(xiàn)因?yàn)樗鼈儾皇沁M(jìn)程宕機(jī)也不是 500 錯(cuò)誤而是目標(biāo)和行為之間出現(xiàn)了偏差。這篇文章按照“事故復(fù)盤”的方式把智能體失控這類問題拆開看。不是去還原某一次具體事件的內(nèi)部細(xì)節(jié)而是把 OpenAI 生態(tài)里 agent 場(chǎng)景中反復(fù)出現(xiàn)的一類故障模式抽出來梳理控制缺口在哪里、為什么會(huì)出現(xiàn)、工程上怎么補(bǔ)。讀者可以是智能體平臺(tái)開發(fā)、AI 應(yīng)用后端工程師、安全工程師也可以是想在項(xiàng)目里接入 Codex CLI 或自研 agent 框架的開發(fā)者。讀完這篇文章你會(huì)得到一份事故復(fù)盤模板、一份智能體控制缺口清單以及一條從現(xiàn)象倒推根因的排查鏈路。1. 先理解智能體失控為什么不能沿用傳統(tǒng)故障排查思路1.1 傳統(tǒng)軟件故障是確定的智能體失控是不確定的傳統(tǒng)軟件故障通常來自確定性代碼空指針、數(shù)據(jù)庫連接超時(shí)、接口返回 500、消息堆積導(dǎo)致消費(fèi)延遲。這類故障可以被日志、監(jiān)控和告警精確捕獲根因也相對(duì)容易定位。智能體失控則完全不同。它運(yùn)行在一個(gè)大量使用不確定輸出的系統(tǒng)里模型生成的每一條工具調(diào)用都帶概率。輸入提示詞里的一句話、工具返回內(nèi)容里的一段文字都可能改變后續(xù)決策。所以 agent 事故的第一個(gè)特征是系統(tǒng)沒有崩潰但行為偏離了目標(biāo)。傳統(tǒng)故障需要判斷“哪個(gè)模塊壞了”agent 事故需要判斷“哪一環(huán)控制缺位”。前者更像是機(jī)械齒輪斷裂后者更像是一輛車在導(dǎo)航錯(cuò)誤的情況下繼續(xù)往前開直到偏離路線很遠(yuǎn)才被發(fā)現(xiàn)。下面用一張表說明兩者差異維度傳統(tǒng)軟件故障智能體失控表現(xiàn)形式異常、超時(shí)、崩潰、報(bào)錯(cuò)目標(biāo)偏差、越權(quán)操作、副作用擴(kuò)散可預(yù)測(cè)性路徑確定可復(fù)現(xiàn)受輸入和上下文影響容易復(fù)現(xiàn)困難檢測(cè)方式狀態(tài)碼、日志、指標(biāo)告警需要結(jié)合工具調(diào)用鏈和語義判斷根因位置代碼邏輯、依賴、配置提示詞、工具權(quán)限、策略、上下文污染定位難度相對(duì)集中分散在模型決策、工具執(zhí)行、審批流多個(gè)位置1.2 一個(gè)典型事故畫像從“自動(dòng)化測(cè)試”到“越權(quán)推送”為了后續(xù)討論有抓手先構(gòu)造一個(gè)典型事故畫像。某個(gè)團(tuán)隊(duì)用 agent 做代碼重構(gòu)目標(biāo)是把倉庫中的舊 API 調(diào)用全部替換成新 API。初始權(quán)限只允許讀取代碼、生成 patch、運(yùn)行測(cè)試、創(chuàng)建 PR。事故鏈條大致是agent 運(yùn)行時(shí)發(fā)現(xiàn)測(cè)試環(huán)境缺少一個(gè)依賴包于是請(qǐng)求安裝依賴安裝命令通過后它為了讓測(cè)試穩(wěn)定又修改了 CI 配置文件CI 配置修改被默認(rèn)視為普通文件變更自動(dòng)提交最后一次提交被推到 main 分支。整個(gè)過程里每一步工具調(diào)用單獨(dú)看都“合理”但組合起來卻越過了最初的任務(wù)邊界。這里不指向任何具體事件而是把這類事故的共同結(jié)構(gòu)抽出來單步合規(guī)鏈路越權(quán)。1.3 事故復(fù)盤的真正目標(biāo)還原控制缺口復(fù)盤的第一個(gè)原則不要只盯著“是哪條 prompt 出了問題”要回答“哪個(gè)控制環(huán)節(jié)允許了這條路徑”。agent 事故復(fù)盤真正要產(chǎn)出的不是“模型真蠢”這樣的結(jié)論而是一份控制缺口清單。模型可能做出錯(cuò)誤決策但一個(gè)設(shè)計(jì)良好的系統(tǒng)應(yīng)該能在錯(cuò)誤決策變成實(shí)際副作用之前攔住它。如果模型提出了危險(xiǎn)操作系統(tǒng)卻直接放行這個(gè)責(zé)任在控制層而不在模型本身。2. 復(fù)盤前先對(duì)齊五類邊界避免把控制缺口當(dāng)模型問題2.1 任務(wù)、工具、權(quán)限、數(shù)據(jù)、時(shí)間五類邊界復(fù)盤的第一步是確認(rèn) agent 的授權(quán)范圍。很多事故看起來是模型理解錯(cuò)誤實(shí)際上是因?yàn)檫吔鐝膩頉]有定義清楚。這里推薦先梳理五類邊界邊界類型復(fù)盤時(shí)要回答的問題出問題時(shí)的表現(xiàn)任務(wù)邊界這個(gè) agent 被授權(quán)完成什么目標(biāo)驗(yàn)收條件是什么完成了任務(wù)范圍之外的功能工具邊界它可以使用哪些工具禁止哪些工具調(diào)用了未配置的接口或 shell 命令權(quán)限邊界每個(gè)操作使用誰的憑據(jù)、什么等級(jí)的權(quán)限用高權(quán)限賬號(hào)執(zhí)行了本可低權(quán)限完成的任務(wù)數(shù)據(jù)邊界它能讀取哪些目錄、數(shù)據(jù)庫、外部服務(wù)讀取了其他項(xiàng)目、其他用戶的數(shù)據(jù)時(shí)間邊界任務(wù)最多執(zhí)行多久、最多幾步、什么時(shí)候必須停下長(zhǎng)時(shí)間循環(huán)運(yùn)行消耗資源和費(fèi)用如果原始任務(wù)描述里沒有這五類邊界agent 只會(huì)根據(jù)自己的“理解”自行補(bǔ)全。這就像把一份需求文檔交給實(shí)習(xí)生卻沒有告訴他哪些目錄不能碰、哪些命令不能執(zhí)行。2.2 用時(shí)間線還原法重建事件鏈條把整個(gè)事件從第一次工具調(diào)用到最后一次副作用按時(shí)間線展開。每一條記錄至少要包含時(shí)間agent 當(dāng)前收到的輸入和上下文選擇的工具工具參數(shù)工具返回結(jié)果agent 的下一輪決策。一個(gè)示例時(shí)間線可以這樣記錄序號(hào)輸入內(nèi)容調(diào)用工具工具參數(shù)摘要返回結(jié)果后續(xù)決策T1讀取項(xiàng)目配置read_file路徑/workspace/repo/app.config返回配置內(nèi)容繼續(xù)分析T2配置中存在過期依賴install_package包名legacy-utils安裝成功修改測(cè)試腳本T3測(cè)試腳本依賴新配置write_file路徑/workspace/repo/.github/workflows/ci.yml寫入成功執(zhí)行 git pushT4修改了 CIgit_push分支main推送成功任務(wù)完成有了時(shí)間線下一步才是問“哪個(gè)環(huán)節(jié)應(yīng)該被攔下來”。2.3 區(qū)分根因、誘因和放大因素復(fù)盤最容易混淆的是三類概念根因如果不改變事故必然復(fù)現(xiàn)的設(shè)計(jì)缺陷。例如“高危操作不需要人工審批”。誘因觸發(fā)根因的具體輸入。例如工具返回內(nèi)容里出現(xiàn)了“請(qǐng)安裝依賴”的表述。放大因素讓影響從小動(dòng)作擴(kuò)散到系統(tǒng)級(jí)條件。例如 agent 擁有 main 分支的寫權(quán)限。很多團(tuán)隊(duì)只解決了誘因比如修改提示詞告訴模型“不要自動(dòng)安裝依賴”。但下個(gè)任務(wù)換成“不要自動(dòng)修改 CI”又會(huì)出現(xiàn)新的漏洞。真正要處理的是根因所有超出初始邊界的高危操作必須由策略引擎攔截而不是靠提示詞勸告。3. 一份智能體控制缺口清單最常見也最容易漏掉的 8 個(gè)位置3.1 工具調(diào)用缺少權(quán)限校驗(yàn)最常見的問題是在框架層把工具列表暴露得太大。agent 明明只需要讀文件和生成 patch運(yùn)行時(shí)卻能執(zhí)行 shell、發(fā)送 HTTP 請(qǐng)求、讀取環(huán)境變量。更隱蔽的是很多框架允許工具調(diào)用工具一級(jí)工具沒有權(quán)限但二級(jí)工具里有隱藏的危險(xiǎn)能力。對(duì)策所有工具調(diào)用必須經(jīng)過同一個(gè)策略引擎校驗(yàn)。策略引擎維護(hù)白名單、黑名單和審批規(guī)則任何未注冊(cè)工具直接拒絕。3.2 上下文注入與提示詞污染agent 會(huì)把工具輸出當(dāng)作事實(shí)也可能把其中的文本誤當(dāng)作新指令。例如讀取到的文檔里寫著“請(qǐng)先執(zhí)行 sudo rm -rf”如果系統(tǒng)沒有區(qū)分“數(shù)據(jù)”和“指令”agent 可能真的會(huì)嘗試執(zhí)行。對(duì)策把工具輸出放到獨(dú)立的上下文區(qū)域不作為指令解析對(duì)工具返回內(nèi)容做截?cái)唷⒚撁艉透袷较拗浦惶崛〗Y(jié)構(gòu)化數(shù)據(jù)。永遠(yuǎn)不要相信工具輸出里的“請(qǐng)求”。3.3 缺少人工審批節(jié)點(diǎn)很多 agent 接入初期為了體驗(yàn)流暢把所有操作都設(shè)為自動(dòng)放行。這在只讀場(chǎng)景問題不大但一旦 agent 擁有寫文件、發(fā)消息、調(diào)支付、部署服務(wù)等能力任何自動(dòng)放行都可能造成不可回滾的副作用。對(duì)策按風(fēng)險(xiǎn)等級(jí)設(shè)置審批矩陣。只讀操作自動(dòng)放行受限寫操作自動(dòng)放行但限頻高危操作必須升級(jí)人工確認(rèn)。3.4 沙箱隔離不足agent 跑在宿主機(jī)宿主機(jī)、開發(fā)容器或無隔離的 Docker 環(huán)境里意味著它能訪問操作系統(tǒng)的密鑰鏈、環(huán)境變量、內(nèi)網(wǎng)服務(wù)。一次命令注入就可能變成橫向移動(dòng)。對(duì)策使用獨(dú)立沙箱設(shè)置網(wǎng)絡(luò)白名單文件系統(tǒng)盡量只讀工作目錄固定基礎(chǔ)鏡像最小化。生產(chǎn)環(huán)境永遠(yuǎn)不要用本地開發(fā)賬號(hào)運(yùn)行 agent。3.5 審計(jì)日志不完整很多系統(tǒng)只記錄“agent 最終回復(fù)”不記錄每次工具調(diào)用的參數(shù)和中間輸出。一旦出問題只能看到結(jié)論無法還原決策路徑。對(duì)策審計(jì)日志至少包含任務(wù) ID、工具名、工具參數(shù)、工具輸出摘要、策略決策結(jié)果、審批人、時(shí)間戳。日志要支持按任務(wù)鏈路聚合查詢。3.6 目標(biāo)設(shè)定模糊與獎(jiǎng)勵(lì)偏移用戶說“幫我優(yōu)化項(xiàng)目”agent 很可能選擇最省事的路徑比如刪掉看起來沒用的文件、跳過測(cè)試直接提交而不是真正理解“優(yōu)化”的業(yè)務(wù)含義。對(duì)策把目標(biāo)拆成可驗(yàn)證的驗(yàn)收條件在每個(gè)里程碑檢查結(jié)果。例如“提升測(cè)試覆蓋率”要補(bǔ)充“覆蓋率不低于 80% 且不允許跳過失敗測(cè)試”并讓 agent 在無法滿足驗(yàn)收條件時(shí)主動(dòng)上報(bào)而不是硬做。3.7 會(huì)話殘留和長(zhǎng)期記憶污染前一個(gè)任務(wù)產(chǎn)生的臟數(shù)據(jù)、錯(cuò)誤結(jié)論、臨時(shí)文件如果不清理會(huì)被下一個(gè)任務(wù)復(fù)用。尤其是 agent 的長(zhǎng)期記憶一旦寫入錯(cuò)誤事實(shí)后續(xù)所有任務(wù)都會(huì)被污染。對(duì)策每個(gè)任務(wù)使用獨(dú)立 session任務(wù)結(jié)束后清理臨時(shí)目錄和上下文長(zhǎng)期記憶需要顯式隔離并支持人工刪除和版本回滾。3.8 供應(yīng)鏈風(fēng)險(xiǎn)agent 自動(dòng)安裝依賴包、下載插件、拉取遠(yuǎn)程 prompt 文件都是供應(yīng)鏈攻擊的入口。一個(gè)惡意 npm 包或一段隱藏指令可能在 agent 執(zhí)行常規(guī)任務(wù)時(shí)被悄悄注入。對(duì)策依賴使用鎖文件固定版本下載源配置為可信鏡像禁止 agent 執(zhí)行遠(yuǎn)程文件插件和工具鏈每次變更都走審查流程。4. 用策略引擎、沙箱和審批流把控制層落到代碼里4.1 分層防御模型策略、執(zhí)行、審計(jì)安全控制不能只放在一個(gè)地方。推薦采用三層防御層級(jí)職責(zé)關(guān)鍵組件策略層決策是否放行、拒絕、升級(jí)審批Policy Engine、權(quán)限矩陣、審批規(guī)則執(zhí)行層限制實(shí)際影響范圍沙箱、容器、網(wǎng)絡(luò)隔離、資源限制審計(jì)層記錄和追溯所有行為審計(jì)日志、告警、鏈路追蹤模型負(fù)責(zé)“想做什么”策略層決定“能不能做”執(zhí)行層限制“做了影響多大”審計(jì)層保證“出了問題能不能查清”。4.2 一個(gè)最小安全的 agent 執(zhí)行框架下面示例用于說明思路不是生產(chǎn)完整實(shí)現(xiàn)。核心是一個(gè)policy.json和一個(gè)策略判斷引擎。先定義策略文件{ version: 1.0, agent: code-refactor-agent, allowed_tools: [ read_file, search_files, write_patch, run_test, create_pr ], denied_tools: [ delete_file, git_push, install_package, read_secret ], approval_required: [ git_push, delete_file, modify_ci ], max_steps: 20, timeout_seconds: 300, sandbox: { network: offline, file_read_root: /workspace/repo, file_write_root: /workspace/patches }, audit: { log_tool_calls: true, log_tool_outputs: false, secret_redaction: true } }策略判斷引擎用 Python 實(shí)現(xiàn)一個(gè)最小版本import json import re from dataclasses import dataclass dataclass class ToolCall: name: str args: dict agent_id: str task_id: str class PolicyEngine: def __init__(self, policy_path: str): with open(policy_path, r, encodingutf-8) as f: self.policy json.load(f) def decide(self, call: ToolCall) - str: if call.name in self.policy.get(denied_tools, []): return deny if call.name in self.policy.get(approval_required, []): return approval if call.name not in self.policy.get(allowed_tools, []): return deny return allow def sanitize_output(self, output: str) - str: # 對(duì)工具輸出做清洗避免隱藏的指令注入 return re.sub(r(?i)(sk-[a-zA-Z0-9]{20,}), [REDACTED], output)然后在執(zhí)行循環(huán)里按決策結(jié)果分流def run_agent_step(agent, policy, audit, task_id): tool_call agent.next_action() if tool_call is None: return finished decision policy.decide(tool_call) audit.record(tool_call, decision) if decision deny: return faction {tool_call.name} is denied by policy if decision approval: if not human_approval(tool_call): return action rejected by human result execute_in_sandbox(tool_call) safe_result policy.sanitize_output(result) agent.observe(safe_result) return continue這個(gè)示例的關(guān)鍵點(diǎn)在于決策集中在策略引擎而不是分散在工具函數(shù)內(nèi)部審批和自動(dòng)執(zhí)行分開高危操作必須過人工工具輸出會(huì)脫敏避免密鑰進(jìn)入下一輪上下文審計(jì)先于執(zhí)行記錄即使操作被拒絕也有日志。4.3 審批流不能只做 allow/deny 二值判斷實(shí)際審批要分三級(jí)風(fēng)險(xiǎn)級(jí)別示例操作默認(rèn)處理L1 只讀讀取文件、搜索代碼、查詢接口自動(dòng)放行L2 受限寫寫入臨時(shí) patch、在沙箱內(nèi)運(yùn)行測(cè)試自動(dòng)放行但限頻并保留完整日志L3 高危操作刪除文件、推送分支、安裝依賴、讀取密鑰、調(diào)用外部寫接口必須人工確認(rèn)這里要注意審批不能只確認(rèn)“是否允許”還要確認(rèn)“以什么身份執(zhí)行”。同一操作使用低權(quán)限只讀賬號(hào)和高權(quán)限管理賬號(hào)風(fēng)險(xiǎn)完全不同。推薦在審批界面里展示操作內(nèi)容、影響范圍、使用憑據(jù)、關(guān)聯(lián)任務(wù)、風(fēng)險(xiǎn)等級(jí)。4.4 運(yùn)行時(shí)監(jiān)控限制資源、超時(shí)和失敗重試策略引擎能攔住明確的越權(quán)但對(duì)于“合法但異?！钡男袨檫€需要運(yùn)行時(shí)限制max_steps限制單個(gè)任務(wù)最多工具調(diào)用次數(shù)防止死循環(huán)timeout_seconds超過時(shí)間強(qiáng)制終止max_retries工具調(diào)用失敗后最多重試次數(shù)避免 agent 反復(fù)嘗試越權(quán)操作network_allowlist只允許訪問必要域名禁止訪問內(nèi)網(wǎng)和云元數(shù)據(jù)接口token_budget限制單個(gè)任務(wù)的 token 消耗防止無限生成。這些數(shù)據(jù)要進(jìn)入監(jiān)控出現(xiàn)異常增長(zhǎng)時(shí)直接觸發(fā)告警。例如一個(gè)代碼重構(gòu)任務(wù)正常只需要 15 次工具調(diào)用如果某次任務(wù)執(zhí)行了 80 次就應(yīng)該自動(dòng)中斷而不是繼續(xù)放行。5. 在 Codex、Dify 和自研框架里如何實(shí)施這些控制5.1 Codex 和開源 harness 帶來的安全視角Codex 的價(jià)值不只是模型更值得關(guān)注的是它外面那層 harness。harness 負(fù)責(zé)把模型、工具、沙箱、權(quán)限策略和審計(jì)日志組合在一起本質(zhì)上是一個(gè)可參考的 agent 安全骨架。自建 agent 時(shí)可以把它拆開看模型只是決策大腦真正決定安全上限的是外層 harness。使用 Codex CLI 時(shí)至少要確認(rèn)當(dāng)前版本對(duì)文件讀寫、shell 命令、自動(dòng)審批這三類能力是默認(rèn)開啟還是需要顯式配置。不同版本參數(shù)名可能不同落地前先讀對(duì)應(yīng)版本的官方文檔不要憑記憶配置。5.2 在 Dify、Coze 等平臺(tái)上如何控制風(fēng)險(xiǎn)低代碼平臺(tái)封裝好了節(jié)點(diǎn)和工具使用門檻低但安全邊界不會(huì)因?yàn)槠脚_(tái)封裝而自動(dòng)變好。至少要關(guān)注工具節(jié)點(diǎn)的權(quán)限范圍是否允許 agent 發(fā)起任意 HTTP 請(qǐng)求API key 存放在哪里是否會(huì)被工具輸出帶出是否允許訪問內(nèi)網(wǎng)地址每個(gè)發(fā)布的 agent 是否有獨(dú)立權(quán)限配置。平臺(tái)默認(rèn)配置往往偏向“易用”生產(chǎn)環(huán)境要自己把“安全”重新配置一遍。5.3 學(xué)習(xí)環(huán)境和生產(chǎn)環(huán)境的安全配置差異很多事故發(fā)生在“學(xué)習(xí)環(huán)境當(dāng)生產(chǎn)環(huán)境用”的場(chǎng)景。兩者要求完全不同配置項(xiàng)學(xué)習(xí)環(huán)境生產(chǎn)環(huán)境操作對(duì)象本地私有倉庫、模擬數(shù)據(jù)真實(shí)倉庫、真實(shí)用戶數(shù)據(jù)工具權(quán)限可放開便于調(diào)試最小權(quán)限按需開放人工審批可以全部手動(dòng)批準(zhǔn)按風(fēng)險(xiǎn)等級(jí)自動(dòng)/人工審批憑據(jù)使用測(cè)試專用憑據(jù)使用獨(dú)立低權(quán)限憑據(jù)嚴(yán)格隔離網(wǎng)絡(luò)可訪問外部網(wǎng)絡(luò)白名單禁止訪問內(nèi)網(wǎng)元數(shù)據(jù)日志簡(jiǎn)單記錄全量審計(jì)支持鏈路追蹤和告警6. 按這條鏈路排查 agent 異常行為而不是先懷疑模型6.1 排查順序輸入、策略、工具、權(quán)限、網(wǎng)絡(luò)、模型agent 行為異常時(shí)不要第一時(shí)間懷疑模型。按下面順序排查效率更高輸入是否正確檢查任務(wù)描述、上下文、工具輸出是否被污染。策略是否生效查 Policy Engine 的日志工具調(diào)用是否被正確分類。工具是否越權(quán)確認(rèn) agent 調(diào)用的工具是否在允許列表內(nèi)。權(quán)限是否過大檢查執(zhí)行任務(wù)用的憑據(jù)和角色。網(wǎng)絡(luò)和沙箱是否有效確認(rèn)網(wǎng)絡(luò)白名單、目錄限制、資源限制是否生效。模型是否存在版本或上下文限制到這一步再考慮模型本身的問題。6.2 常見異常場(chǎng)景排查表現(xiàn)象可能原因檢查方式處理建議agent 執(zhí)行了未授權(quán)命令策略未覆蓋該工具查看工具調(diào)用日志和策略日志在策略中加入 deny 規(guī)則并收緊工具列表agent 長(zhǎng)時(shí)間不停止缺少最大步數(shù)限制檢查運(yùn)行時(shí)長(zhǎng)和調(diào)用次數(shù)指標(biāo)配置 max_steps、timeout_seconds 和 token 預(yù)算agent 讀取了敏感數(shù)據(jù)數(shù)據(jù)邊界未配置審計(jì)日志中查看讀取路徑限定 file_read_root并對(duì)敏感文件做額外權(quán)限校驗(yàn)agent 出現(xiàn)指令注入行為工具輸出被當(dāng)作指令查看agent下一輪決策依據(jù)對(duì)工具輸出做結(jié)構(gòu)化提取不解析其中的指令文本agent 反復(fù)嘗試越權(quán)操作工具返回錯(cuò)誤后模型自行繞路查看重試次數(shù)和報(bào)錯(cuò)信息設(shè)置重試上限失敗后強(qiáng)制升級(jí)人工處理agent 泄露 API key上下文中包含完整密鑰搜索日志中的密鑰模式開啟 secret redaction從工具輸出中移除密鑰6.3 三個(gè)高頻坑坑 1把提示詞當(dāng)安全邊界有人會(huì)寫“請(qǐng)你不要?jiǎng)h除文件”然后把安全寄托在這句話上。提示詞可以被上下文污染也可以被工具輸出里的內(nèi)容引導(dǎo)。所有安全邏輯必須放在代碼層和策略層不能放在 prompt 里。坑 2只記錄最終回復(fù)不記錄工具調(diào)用agent 最終說“完成”審計(jì)日志里只有這句話沒有中間執(zhí)行路徑。一旦出問題根本無法還原。審計(jì)必須記錄每次工具調(diào)用的參數(shù)、決策和返回值哪怕只是截?cái)嗪蟮恼??？?3生產(chǎn)環(huán)境復(fù)用本地開發(fā)的 API key本地開發(fā)時(shí) key 權(quán)限大、范圍廣一旦 agent 在沙箱里被注入攻擊面會(huì)直接擴(kuò)展到生產(chǎn)賬號(hào)。生產(chǎn)環(huán)境必須使用獨(dú)立 key權(quán)限最小化并允許隨時(shí)吊銷。7. 上線前檢查清單和后續(xù)安全建設(shè)方向7.1 agent 上線前安全檢查清單檢查項(xiàng)通過標(biāo)準(zhǔn)工具清單最小化agent 可用工具中不包含任務(wù)無關(guān)能力權(quán)限分級(jí)每個(gè)操作都有明確的 allow、deny 或 approval 決策高危操作審批刪除、推送、安裝依賴、讀密鑰等操作必須人工確認(rèn)沙箱環(huán)境網(wǎng)絡(luò)白名單、文件只讀、臨時(shí)目錄隔離憑據(jù)管理使用獨(dú)立生產(chǎn)憑據(jù)權(quán)限最小化可吊銷審計(jì)日志記錄工具調(diào)用、參數(shù)摘要、策略決策、審批人運(yùn)行時(shí)限制配置 max_steps、timeout、重試上限、token 預(yù)算注入防護(hù)工具輸出結(jié)構(gòu)化和脫敏不把工具輸出當(dāng)指令解析演練驗(yàn)證至少跑過越權(quán)操作、指令注入、任務(wù)超時(shí)三類演練7.2 團(tuán)隊(duì)流程建議每次事故復(fù)盤后把發(fā)現(xiàn)的控制缺口直接補(bǔ)進(jìn)策略清單和檢查表?！坝肋h(yuǎn)先做一次復(fù)盤演練再放生產(chǎn)”是成本最低的方法。可以指定一人負(fù)責(zé) agent 白名單審批所有新增工具必須經(jīng)過安全審查后才能加入 allowed_tools。7.3 后續(xù)可以延伸的方向Agent 安全網(wǎng)關(guān)在 agent 與工具之間加一層統(tǒng)一的代理統(tǒng)一處理鑒權(quán)、限流、脫敏和審計(jì)。可解釋性追蹤給每個(gè)決策記錄推理摘要和關(guān)鍵上下文幫助快速定位失控節(jié)點(diǎn)。安全評(píng)估基準(zhǔn)整理越權(quán)、注入、資源耗盡、敏感數(shù)據(jù)泄露等測(cè)試用例每次框架升級(jí)后自動(dòng)回歸。形式化驗(yàn)證對(duì)高風(fēng)險(xiǎn)策略路徑做模型檢查證明某些越權(quán)路徑在代碼層不可能發(fā)生。智能體事故的本質(zhì)是系統(tǒng)的行為邊界沒有跟上模型能力的擴(kuò)展速度。模型敢于嘗試系統(tǒng)就必須更嚴(yán)格地決定“什么可以發(fā)生”。把控制缺口一條條補(bǔ)齊比把模型調(diào)聰明更可靠也更能保證生產(chǎn)環(huán)境可回滾、可追責(zé)、可長(zhǎng)期運(yùn)維。