一筆 9 億美元的銀行匯款失誤，教了我們什麼 AI 代理的事——專訪 Two Sigma 的 John Feminella

John Feminella 在對沖基金 Two Sigma 負責 AI 架構與工程，他主張企業應該賦予 AI 代理真正的自主權，並以可組合的管控機制加以框限，而不是把代理鎖死、或指望運氣。他先以花旗銀行（Citibank）2020 年 8 月誤將約 9 億美元轉給 Revlon 放款機構的事件鋪陳論點，接著用整場演講的大部分時間，說明 Two Sigma 用來治理代理的五項管控：代理登錄檔、風險評分、執行期護欄、共用評測，以及以分類器為基礎的人工審查。Revlon 事件只佔開場幾分鐘，節目主體是一套企業治理框架。

Feminella 的視角來自一家受監管的金融機構內部，因此他描述的管控是依稽核、許可權與審查量能等限制形塑而成，而非依模型能力設計。讀者讀完應該能帶走一套可大規模部署代理的具體架構、清楚理解為何一刀切的封鎖與全面人工核准都會失敗，以及催生各項管控的具體失效模式——影子 IT、審查疲勞、上下文壓縮。

花旗的錯誤顯示：所有人都做對了事，管控卻依然失效

2020 年 8 月，花旗擔任 Revlon 2016 年定期貸款的行政代理行，這筆貸款拆分給 300 多家放款機構，包括對沖基金、信貸基金、CLO 及其他銀行。花旗的角色只是管道：Revlon 把錢付給花旗，花旗再付給各放款機構，花旗從未動用自己的資金。2020 年 8 月 11 日的計畫，是把約 800 萬美元的應計利息撥給兩個放款機構群組，本金則以票據交換、而非現金的方式滾入新貸款。本金從頭到尾都不該移動。

銀行內部的處理軟體 FlexCube 要處理這類交易，最簡便的做法是把它記錄成 Revlon 清償整筆貸款，這樣就能觸發正確的利息計算。本金部分原本應該轉入內部的過渡帳戶（wash account）——帳上登入、留下紀錄，但資金不離開銀行的界線。有三個標示為「front」、「fund」、「principal」的欄位，需要填入過渡帳戶號碼，並在每個欄位旁打勾。Feminella 說，基於「種種難以理解的緣故」，這些欄位沒有被勾選。

FlexCube 確實發出警告，表示有資金即將流出銀行。這個警告在技術上是對的，因為利息付款確實要流出。三位核准人看了警告，判斷它描述的正是預期行為，於是把它覆寫掉。FlexCube 於是把全額未償本金匯給 300 多家放款機構——約 9 億美元，而不是 800 萬美元。每家放款機構收到的，都是全額清償下它們應得的金額。

放款機構拒絕退錢。Revlon 當時陷入困境，其貸款並未以面額交易，而一個價值約每美元 60 美分的部位能拿到全額，等於天上掉下來的意外之財。Feminella 轉述它們的論點：你們全額付給了我們，貸款就是這樣運作的，提前付款並不構成退還資金的義務。2020 年 8 月之後，商業貸款協議開始加入專門防止這類情況的合約條款。

Feminella 的重點不是這家銀行缺乏管控，而是流程存在、警告也響了，每個人卻都做了自己認為正確的事。這正是他希望聽眾在代理真正接管 FlexCube 這類系統的自主權時，去思考的失效模式。

代理不具確定性，企業早已信任的人類也一樣

有人會質疑：不具確定性的代理特別危險。Feminella 先發制人地反駁，指出人類同樣是不具確定性、也會犯錯的系統。沒有企業會用把員工關進各自房間、禁止彼此交談的方式來因應；企業給的是界線、可視性，以及讓他們能工作的系統。在他看來，安全與創新並不是權衡的兩端。

他否定了三種常見做法：

他說，真正可行的是混合多項可組合的管控，每項各司其職，合起來就能在適當的安全水準下容許真正的自主。他明確表示不要出現斷層：團隊不該在橋蓋好之前只能枯等，無法做自己的工作。

代理登錄檔讓每個代理從第一天就可被辨識

第一個問題是蔓延。大團隊跑許多代理，小團隊跑幾個，個人則毫無管制地跑各種東西——聊天機器人、被「像科學怪人一樣拼湊在一起」的 MCP 伺服器、筆記本實驗、好用的網頁工具。企業回答不了基本問題：這是誰的、它存取哪些工具、它該做什麼、不該做什麼。沒有這些答案，就沒有治理，也沒有重用，團隊於是把已經存在的方案重造一遍，而企業完全看不到這些東西。

直覺的解法——沒註冊、沒核准、沒走完繁瑣流程就什麼都不準跑——會讓多數人乾脆放棄，或轉往更隱蔽的影子 IT 路徑。Feminella 的替代方案是一份代理登錄檔，記錄關鍵事實：宣告使用的工具、會存取的端點、所屬產品，以及負責人。人類、程式及其他代理都能查詢它，藉此得知有哪些代理存在，並把它當作可信的資訊來源。團隊使用公司核准的代理建置框架時會自動註冊；手動註冊也可行。

風險評分把人工審查導向真正重要的地方

代理一旦可被看見，它們的風險輪廓就顯得差異極大。一個負責摘要 Jira 或 Linear 工單的代理，和一個能碰觸執行中系統的正式部署代理，完全不是同一回事。兩者共用同一個審查佇列，等於每個代理都要等上好幾週，而人們會繞過緩慢的流程——又回到原本的問題。讓每個相關單位都做重度人工審查，結果也一樣：一個微不足道的摘要工具，排在專為碰觸正式環境的代理所設的簽核後面等兩個月；審查者被低風險請求淹沒；高風險請求則和它們搶同一份注意力。

Feminella 區分兩類代理：一類是像 Claude Code 或 Pi 這種開放式代理——它們不知道你會問什麼，也不限定自己的用途；另一類是多數企業代理，為特定且充分理解的工作量身打造。後者可從它們事先宣告的內容辨別出來：工具、端點，以及套用的管控。風險分數就是根據這份宣告計算，分數再決定該代理接受多少人工審查。

執行期護欄只授予代理宣告過的工具

代理很少只以單一身分跟單一物件互動。代理越開放，開的門就越多——內部 API、網頁搜尋——每一扇門的風險各不相同。一個擁有角色帳戶許可權的代理，能造成的損害遠大於一個只讀取公開網頁的代理。問題於是變成：這個代理需要多細緻的許可權才能成功行動，而不是「這個代理能不能做 X」。

把所有安全動作列成允許清單、其餘一律封鎖，既安全又無用；團隊不是放棄這些代理，就是想辦法繞過這道牆。Feminella 引用 John Shedd 的話：「船停在港裡最安全，但船不是為了停在港裡而造的。」他的做法是讓代理宣告自己的用途與所需工具。研究摘要代理可以獲準使用網頁工具；發布部署代理沒有理由使用網頁工具，預設也不會拿到。代理作者從 500 個工具中挑出自己需要的四個。

強制執行發生在初始化階段：受管理環境中的代理會到登錄檔查詢自己的政策，這些政策再轉譯成可強制執行的規則，明定允許哪些端點、主機與資源型別。變更許可權不需要開工單，也不必在團隊之外找 IT 溝通。只要符合風險分數並出現在登錄檔中，代理就受到治理並獲得核准。

flowchart TD
    A["代理宣告用途、工具、端點"] --> B["註冊於代理登錄檔"]
    B --> C["依宣告內容計算風險分數"]
    C --> D["依風險等級分派人工審查"]
    B --> E["初始化時查詢政策"]
    E --> F["可強制執行的端點、主機、資源規則"]
    F --> G["代理僅以宣告的許可權執行"]
    G --> H["執行期分類器評估每一次呼叫"]
    H --> I["例行呼叫自動核准"]
    H --> J["模糊地帶的呼叫送交人工"]
    H --> K["明顯危險的呼叫直接拒絕"]

共用評測是針對不斷變動的執行期相依性所寫的單元測試

各團隊打造的評測堆疊天差地別，有些團隊則什麼都沒做。Feminella 把評測視為單元測試的對等物：模型一變，那就是應用程式的執行期相依性；沒有評測，代理就無從得知自己的輸出品質會受到什麼影響。若採中央統一的評測方法，並以完整測試套件加上委員會簽核作為關卡，那麼每次調整提示、每行一行的修改都會排進同一個佇列，因此他基於與其他管控相同的理由否決這種做法。

公司層級的答案是採行一套共用的評測方法，由公司執行、人人可用，涵蓋每個團隊都相同的部分。A 團隊和 B 團隊都需要這些共通功能；各團隊只需自行撰寫關於自家代理的實情。

人工介入審查在量能與上下文流失下崩潰

逐一核准代理的每個動作，在小規模可行，到了正式環境或代理並行運作時就會崩潰——請求湧入的速度遠快於任何人能審查的速度。審查疲勞隨之而來：是、是、是，直到有人在「某個會啟動核彈的東西」上按下「是」。

Feminella 舉了 2026 年稍早的一個例子：某 AI 研究實驗室的一位主管指示她的 OpenClaw 代理提出要刪除的電子郵件清單，並等她核准。她的收件匣太大，代理壓縮了上下文，遺失「等待核準」的指令，刪掉數百封郵件，而且她從手機叫它停，它也停不下來。

解法不是讓人工核准每一個動作。獨立的保守分類器處理例行呼叫，只有最可能重要的請求才會送到人面前。如果一個人 99.99999% 的時間都說「是」，那這就是代理該遵循的規則，而不是一項許可權請求。模糊或可能危險的呼叫會浮現給人工；明顯危險的則直接拒絕。明確的規則走確定性的快速通道；模糊地帶交給分類器。

管控是煞車，而煞車正是讓你敢開快的原因

Feminella 最後把五項管控重新組合成一套系統：登錄檔讓每個代理從誕生起就可被看見；風險分數讓人工審查落在正確的位置；執行期護欄讓代理只碰觸自己需要的東西；共用評測與指標讓所有人達到同一標準，不必各自重造；執行期治理讓分類在該發生的地方發生，而不是在別處。

「車子為什麼要有煞車？不只是為了讓你停下來，而是為了讓你能開快，並且安全地停下來。」

值得帶走的綜合結論是：每項管控的設計都以壓低團隊成本為目標，因為任何增加摩擦的管控，都會把工作推向毫無可視性的未治理影子路徑。尚未解決的張力在於：這套框架取決於分類器夠保守、風險分數夠準確——而這正是花旗事件中失靈的那一類判斷：一個正確的警告被覆寫，只因為在場的人有個聽起來合理的說法，解釋為何這是預期行為。Feminella 並未說明分類器這一層本身如何驗證，而這正是受監管企業的風險委員會接下來最可能追問的問題。