過去我談的高風險場域，不管是災害應變、醫療照護，還是運動科學，AI 扮演的角色大多是「決策支援」——把破碎的資訊整理好、把重要的訊號突顯出來，最後把方向盤交還給人。

這幾年，AI 的角色開始悄悄挪動：從「幫人決定」，走向「自己去做」。這個轉變一旦發生在高風險場域，意味著什麼？我在讀卡內基梅隆大學與 IBM Research 合作的一篇研究時，找到了一個很具體的案例。

什麼是代理式 AI？

案例的主角是開發者代號 P2，一位打造 IT agent 的研究員。他的 agent 原本是要協助處理系統維運任務，卻在測試階段被公司資安團隊攔了下來——因為它「試圖尋找並刪除 root folder」。沒有駭客，也沒有惡意程式，只是一個被賦予了自由度、卻還沒學會分辨後果的 agent，照著自己的邏輯往前走了一步。

這個意外會發生，其實跟「代理式 AI」的定義本身脫不了關係。跟傳統生成式 AI 不同，代理式 AI 不只是「回答問題」，而是「解決問題並採取行動」：它能在極少人類監督下自主決策，能串接 API、操作外部服務並修改環境狀態，能把模糊目標拆解成多步驟任務，也能針對未知情境動態調整策略——開發者代號 P2 的 agent，正是在「自主決策」與「操作外部服務」這兩項能力交會的地方，踩出了那一步。這些能力，都建立在同一個基礎模型之上，也是《The Perils of Agency: How Developers Perceive, Prioritize, and Address Risks in Agentic AI Products》這篇論文想深入探討的起點。這篇論文訪談了 35 位打造 user-facing agentic AI 產品的開發者，開發者代號 P2 的故事，就出自其中一段訪談紀錄。

我們正在抹殺 AI 的代理性

論文提出的核心矛盾，是這樣的：業界拼命開發具備高度自主性的 agent，卻又因為害怕隨之而來的風險，在部署前強加各種剛性限制，像是硬編碼規則、強制人類介入。為了讓 AI 更安全，我們最終把它「降級」回接近傳統的僵化軟體。這是一場代理能力與風險控制之間的零和拉扯。

要理解這場拉扯是怎麼發生的，研究團隊借用了 SPAF 框架，把開發者面對的困境拆成三層：認知（Awareness）——agentic AI 如何改變開發者對風險的感知；動機（Motivation）——開發者如何決定風險處理的優先順序；能力（Ability）——開發者實際採取了哪些控制手段，成效如何。

認知：清晰的靶心，與看不見的盲區

論文發現，開發者對「影響產品效能」的風險極度敏感，卻因為缺乏組織指引，對「社會性危害」視而不見。自主性讓 agent 可以在有限監督下完成任務，但也代表原本用來約束它的「政策」隨時可能被繞過。開發者代號 P26 說，agentic 的規則「可能被違反……所以那些對 agent 的限制，其實不算真正的限制」。環境越複雜，能出錯的地方也越多，agent 串接進 API、資料庫、工具的同時，也把這些連接點變成新的攻擊面——這正是開發者代號 P2 事件會發生的原因。目標越開放，模型出錯的機率也越高，錯誤還會在多輪自主執行中一路累積：這是整篇論文提到最多次的風險，35 位參與者裡有 19 位都談到模型準確度的問題。開發者代號 P35 因此設下一條紅線：一旦表現掉到 80% 以下，「這個 agent 已經是在傷害你的系統，而不是在幫忙」。適應力則帶來另一種困擾，同樣的情境，agent 這次跟下次可能得出不同的結果，難以歸責。開發者代號 P7 把結構化查詢改成讓 agent 自己組出查詢語言，換來更強的彈性，卻也坦言這是「犧牲了可重現性」換來的代價。

這些貼近產品本身的風險，開發者普遍很敏感；但工作取代效應、終端用戶隱私外洩、人類自主性喪失這類下游社會與長遠風險，反而比較少被主動提起。開發者代號 P30 形容自己是在「零資源」的情況下自己摸索，開發者代號 P7 也提到身邊「沒有多少人在做 AI agent」，更沒有人準備好承擔這個責任。

動機：一套商業過濾器

當研究者請參與者排出風險優先順序，一個清晰的模式浮現出來：風險會先經過一層又一層的商業過濾器——是否嚴重影響 AI 的任務品質與準確度，是否會破壞使用者信任與產品可用性，是否觸犯法規或客戶核心利益。只有當風險威脅到這套隱性的商業成功模型，開發者才會有強烈動機去修復它；抽象的風險，像是濫用信任，則容易被無限期擱置。

開發者代號 P1 說得很直接：風險就是「會妨礙功能運作的那些東西」。開發者代號 P10 的 agent 處理信用卡查詢，他很清楚，幻覺不能被當成「一個小失誤」帶過去，因為「這些涉及法規，可能會讓用戶付出很大的代價」。開發者代號 P15 則提醒，開發者要的不是零風險，「只要夠透明，人們就可以承擔風險、也可以避開風險。透明是必要的」。

但即使動機被建立起來，開發者還要面對一堵組織高牆。緩解風險意味著犧牲 AI 的效能、靈活性與開發速度——開發者代號 P3 點出了這個兩難：「你限制這些工具限制得越多，它的價值就越低」。為 agent 的記憶與工具存取添加安全機制，成本極高，還需要持續維護。系統高度依賴外部 API，跨團隊邊界的風險常常沒有人願意承擔最終責任。開發者代號 P10 把界線畫得很清楚：「我是技術人員，我只能盡量確保它的可重現性，但如果做不到，那就是組織的責任」。

能力：蝴蝶結模型，與去代理化的代價

到了真正動手處理風險的階段，論文用「蝴蝶結分析」（Bow-tie Analysis）整理開發者的做法：先找出風險的潛在肇因，像是模糊提示、工具失效、惡意用戶，用工具白名單、輸入淨化來預防；再看風險發生後可能造成的後果，像是系統崩潰、機密資料外流、失去客戶信任，用操作可逆性、人類在迴路審批來保護。

但這裡有一個難以繞開的悖論：開發者用來降低 agentic 風險的方式，往往就是限制讓產品之所以「agentic」的那些特質。賦予自主性，導致違規與失控風險，控制手段是加入強制的人類迴路審查，代價是失去自動化的速度與規模。開放環境與工具，導致資源攻擊與資料外洩，控制手段是嚴格限制工具白名單與防護牆，代價是失去動態解決問題的靈活性。動態適應性，導致不穩定與難以重現，控制手段是把工作流硬編碼、限制輸出，代價是讓系統退化回傳統的僵化軟體。開發者代號 P31 用近乎自嘲的口吻描述自己團隊的做法——加上一句免責聲明提醒使用者可能出錯——「這是個爛解法，就是放棄治療，加個免責聲明很簡單」。

更麻煩的是，開發者連評估工具都是匱乏的。Agentic AI 的應用場景太過開放、太過領域專一，傳統基準測試無法涵蓋真實環境的噪音與突發狀況，這代表沒有可靠的「地面實況」可以拿來驗證系統是否安全。業界普遍用語言模型裁判來監控 AI 代理，矛盾的是，這些護欄本身也是 AI，繼承了相同的非確定性與幻覺風險。開發者代號 P25 一語道破這個困境：「你只是引入了另一種隨機性，增加了一個新的故障點」。

一個無效的開發循環

把這三層發現串在一起看，會發現業界其實困在一個難以突破的循環裡：先是開發高度自主的 agent 以追求極致效能，接著遭遇無法預測的系統性風險與邊界失控，然後因為缺乏動態評估工具，只能強加靜態的剛性限制，AI 也因此變得死板、失去代理價值，與傳統軟體無異。為了恢復產品競爭力，開發者再次尋求賦能，於是又繞回起點，形成一個無法突破的死胡同。

兩條破局之道

論文認為，要走出這個循環，需要同時重塑認知與動機、並發展下一代的動態控制工具。

在擴展認知與建立動機這一側，可以導入自動化紅隊測試，利用大型語言模型大規模模擬提示詞注入與邊界攻擊，在開發前期就暴露出下游的潛在危害；也可以建立專門針對代理特徵與資料流的風險辨識機制。在建立動機上，親社會與同理心導向的設計，可以把抽象的社會風險轉化為具體的人類後果，也可以建立輕量級的風險緩解模式庫，讓開發者實際看到安全設計帶來的商業價值。

在發展能力這一側，論文主張 agentic AI 需要的是能與其能力一起擴充的動態護欄，而不是扼殺核心齒輪的傳統靜態枷鎖。這意味著要有專屬的影響力評估，明確定義產品依賴的代理特徵、伴隨的風險與妥協的代價；也需要代理級的清單與模型卡，把透明度與問責制，變成開發流程裡的標準配置。

我認為這些控制方式，最後都會落在使用者看得到、摸得到的介面上：permission 是 UX，approval 是 UX，human-in-the-loop 是 UX，可追溯性是 UX，undo 也是 UX。當 agent 真的可以自己去做事，AI safety 就不再只是 model 或 engineering 層次的問題，它會變成使用者怎麼理解 agent 做了什麼、怎麼介入、怎麼在出錯之後把狀態拉回來的問題。

結語：與能力並進的安全

論文最後給出的結論很清楚：真正的代理式 AI，不應該在「智能」與「安全」之間妥協。唯有把風險控制融入系統設計的核心，讓它像 AI 本身一樣具備動態適應力，我們才能真正解鎖 agent 的潛力，而不是讓它退化成披著 AI 外衣的傳統軟體。

這句話，也回應了我從一開始就關心的問題：什麼可以讓 AI 自己決定？什麼需要人介入？人要在什麼時候介入？AI 做錯之後，又要怎麼恢復？這些問題，會持續把我帶回同一個起點——如何設計一個在人命關天或高壓決策情境中，依然值得被信任的系統。