主體漂移：企業智能體架構中的身份、權限與問責危機

在過去一年中，我審閲了大約二十多家企業的智能體架構，包括銀行、零售商、醫療系統以及幾家監管機構。這些架構圖無一例外地令人印象深刻：MCP網關、工具註冊表、向量存儲、編排器、策略引擎、可觀測性堆棧等模塊一應俱全，箭頭標識着智能體如何相互發現、共享上下文以及跨網格調用工具。按照2026年的標準，這些圖景是任何嚴肅的智能體部署所必備的。但所有這些圖都沒有顯示：這些智能體是誰？它們代表誰的權威？當它們出錯時，誰負責？

這個缺失有一個值得命名的稱謂：主體漂移——在任何足夠大的智能體系統中，人類權威與實際行動者之間逐漸脱鈎。在你部署第一個智能體時看似合理的身份態勢，隨着智能體的倍增、組合以及壽命超過原始初衷而悄然退化。主體漂移並非三個獨立的故障模式，而是一個級聯：身份首先崩塌；接着是權限侵蝕，因為不再有穩定的主體來綁定策略；最後是問責消失，因為智能體錯誤造成的成本落到了事故覆盤時談判地位最弱的團隊頭上。要阻止這個級聯，必須在第一環就進行干預，但目前幾乎沒有企業智能體平台能做到這一點。

要觀察這個級聯的運行，我們來看一個最普通的退款智能體。一名客服代表在處理聊天時要求智能體為一件損壞商品處理48美元的退款。智能體檢查資格、執行退款併發布更新。審計日誌記錄了動作由類似"refund-agent-prod-03"的實體執行，該實體運行於客服平台團隊擁有的服務主體下。這條記錄是真實的，但毫無用處。智能體並非以"refund-agent-prod-03"的身份行動，而是以客服代表的身份，代表客户，沿着一條無人記錄的委託鏈。在構造良好的系統中，客户、客服代表、智能體身份和服務主體應同時記錄，可作為鏈式查詢，且持久化於會話之外。但當今大多數生產系統並非如此。這是級聯的第一環：身份坍縮為泛化的服務主體，再也沒有可綁定的“誰”。

權限侵蝕隨之而來。退款智能體擁有一個理論上可退款任何訂單的"issue_refund"工具。其權限本應更窄（退款不超過200美元、訂單不滿90天、信譽良好的客户、超過50美元自動升級），但該權限存在於提示詞、YAML文件或團隊最近一次在策略變更後便未更新的Notion頁面中。運行時強制能力，但無人真正強制權限。當中毒輸入或混淆的推理鏈導致智能體向錯誤客户退款1800美元時，事後問題“誰批准了此策略”得不到清晰答案，因為策略從未作為工件存在。在高風險場景下情況更糟：想象一個擁有保護分支合併權限的編碼智能體，被嵌入代碼註釋的提示詞指示“記錄配置值用於調試”，卻靜默地將秘密外泄到外部監控服務。

接着問責消失。構建智能體的團隊聲稱其遵循策略；編寫策略的團隊聲稱未預料到該輸入；運營平台的團隊表示智能體以服務主體運行，其行為不由他們負責。審計日誌可能記錄了動作，但未記錄產生該動作的推理、塑造推理的檢索上下文，以及構建檢索的提示歷史。事後覆盤變成了考古學，成本最終由會議結束時談判地位最弱的團隊承擔。

這一切是新的嗎？我們有IAM、身份治理、策略即代碼、審計追蹤、SIEM以及30年的合規實踐。為何這不只是IAM的適當實施？因為IAM圍繞智能體會違反的假設而構建。IAM和IGA假設主體羣體在人類時間尺度上變化：人員入職、離職，服務賬户每季度輪換。智能體按會話生成並組合成鏈，一個智能體調用另一個，後者再調用第三個，通過委託令牌模擬用户，而傳統IGA根本無法將之表示為鏈。策略引擎在動作發生時刻觸發，作用於API、數據庫和網絡。智能體在到達這些執行點之前就已做出最關鍵的決策——選擇調用哪個工具及參數。成熟的審計日誌假設重放輸入可重現輸出，但對於智能體，重放提示和檢索可能產生不同動作，因為模型本身貢獻了日誌未捕獲的狀態。儀器觸發，儀表盤變綠，但靜默外泄秘密的智能體依然在運行。審計日誌記錄動作由"agent-service-01"執行，這同樣既真實又無用。

這也正是銷售統一堆棧的供應商希望你跳過的地方。微軟的Entra Agent ID（當前處於公開預覽階段）是迄今為止最成熟的方案，將為人類和工作負載使用的條件訪問、身份治理和身份保護擴展至AI智能體這一新身份類型。谷歌和Salesforce也在構建這一層。營銷話術是智能體將獲得與勞動力其他成員相同的身份驅動保護。這在解決級聯第一環上邁出了實際的一步，但它並非治理——它是一個控制平面，卻有着治理平面的營銷。條件訪問能告知你智能體的訪問嘗試是否被允許，但它無法告知你智能體在訪問嘗試之前所做的決策是否在其權限內，為何做出該決策，或者哪個業務單元擁有該決策應遵循的策略。

真正的治理平面必須捕獲決策，而非僅捕獲動作。一個推理級的審計記錄是缺失層的承載基元，它大致如下：

{ "event_id": "refund-2026-05-17-08431", "triggered_by": { "human_principal": "rep:[email protected]", "delegated_via": "support-console-session-9c2a", "customer_principal": "cust:7741289" }, "agent": { "identity": "refund-agent", "version": "v4.7.2", "policy_ref": "refund-policy/v3.1 (signed: r.patel, 2026-04-22)" }, "task": "Process refund for order 88812204", "retrieved_context": [ {"doc": "order:88812204", "fetched": "2026-05-17T08:43:11Z"}, {"doc": "policy:refund-eligibility", "chunk": 4, "fetched": "2026-05-17T08:43:12Z"} ], "reasoning_trace": "...", "tool_calls": [ {"tool": "check_eligibility", "input": "...", "output": "eligible"}, {"tool": "issue_refund", "input": {"amount": 48.00}, "output": "ok"} ], "action": "refund:48.00", "principal_chain_hash": "0x9e7b3f..." }

並非所有智能體都需要此記錄。一個安排會議時間的調度智能體不需要。但移動資金、部署代碼或做出監管者最終會過問的決策的智能體則需要，這正是應設置的門檻，因為其關聯成本高。推理級審計更接近飛行記錄器而非系統日誌饋送。存儲和查詢這些數據成本高昂，且涉及真實隱私問題，因為這些日誌包含智能體所見的一切，包括智能體有權讀取但審計系統本不應保留的數據。可通過按比例保留來承擔成本：高爆炸半徑智能體（面向監管、客户資金、合同重大、修改生產）進行完整推理捕獲；內部輔助工具進行輕量捕獲。

這引出了架構圖中未提出的問題：誰構建並運行這些？安全團隊可強制策略但無法制定策略；瞭解退款智能體應被允許做什麼的人擁有退款業務而非防火牆；IT可配置身份但無法起草“信譽良好”或編寫升級規則。MCP和A2A協議社區在傳輸級身份和委託方面做了實際工作：MCP提供工具調用溯源，是Entra Agent ID及大多數供應商框架構建的標準；A2A正在趨近跨智能體委託原語。兩者都重要，但均不制定策略。連接器由標準而非機構推動。

企業需要一個位於擁有策略的業務單元與運行時的平台團隊之間的新職能：稱之為智能體運營——一個通常4-8人的小組，嵌入而非集中，向CIO或CISO彙報（取決於內部政治），明確負責維護每台生產智能體的註冊表、其命名的人類所有者、版本化的權限規範、推理級審計的保留策略及其生命週期狀態。每個智能體經過簽署策略的上線審核，按實際節奏審查，並在其初始目標結束時真正退役，而非像當前這樣靜默地存活於其發起人之後。設計時需防範故障模式，如審查節奏僵化為形式、策略工件滯後於智能體部署速度、或該職能成為智能體被委員會否決而死亡的地方。該職能必須跟上平台團隊的速度，否則一個季度內就會被繞過。

這項工作艱鉅且早該進行，而監管的時鐘正在滴答作響。歐盟AI法案高風險條款今年將進入執行階段，監管機構會要求可解釋性、可追溯性、生命週期記錄以及命名的人類問責——這正是智能體運營職能產出的工件。Tyler Akidou在其四月的Radar文章中稱此為缺失的HR層；Artur Huk更近期的《從能力到責任》從運行時角度得出了相似結論。標籤不如工作重要。本文涉及組織內部的治理；更困難的是跨組織治理，即智能體在不同信任體制下運作。這嚴格來説更糟，值得另文探討。

在你自己的四牆之內，診斷一下午即可完成：選取一個生產智能體，嘗試用證據回答：它承載誰的權威——從動作回溯到命名的人類？它的權限在哪裏説明，誰簽署了當前版本？明天它做錯事時，誰付出代價，如何決定，以及有什麼推理級記錄支持該決定？大多數誠實進行此練習的架構師都會得到三個空白和內心的不安。這就是主體漂移——被命名並可見的漂移。

你構建的網格是真實且必要的，但不夠充分。其餘的架構是其上的制度：註冊表、簽署的策略、推理級審計、每條鏈條末端的命名人類。在大多數企業中，它尚不存在，並且不會通過購買另一個平台而到來。你必須自己起草它。