Google AI Live + Labs Taipei 心得 · 後篇

為什麼最難的不是模型

從 Agent Gateway 看 AI 進企業的最後一哩

上一篇文章談到那組數字。Google 在台上的分享裡，七成的企業推進到生產環境時遇到阻礙，治理這一環只有一成狀態良好，將近兩成直接卡死。

我本來以為那個下午的壓軸，會是一場產品發布。

結果整場三十幾分鐘，講者開頭沒多久就說了一句大實話。

他說，談到最後，AI 代理好像不是在賣 AI，都在講 security 跟 governance。只有這個東西做夠了，AI 才找得到辦法大量使用。

這句話講得很輕，但我覺得它是整場活動最誠實的一句。一個賣 AI 的人，在台上承認自己賣的其實不是 AI。

他接著說，即便到了 2025 年底，還是有很多企業的資訊主管說不清楚 AI 代理到底是什麼、能做什麼、該怎麼管。他現場的說法是引自一份「2025 年底官方評測」，但沒有說明是哪個機構做的，我事後也沒查到原始報告，所以只能先當成一位業界人士引述的判斷。不過我相信。因為我自己的公司裡，工具已經在跑了，定義卻還在改。

01

在代理和系統之間，先插一道門

要理解這一層在做什麼，用海關想最清楚。

今天你要出國，不是買了機票就能直接走到停機坪。中間有一道關卡，護照拿出來、行李過機器、必要時被請到小房間問話。這道關卡的存在並不是懷疑每個人都要偷渡，而是讓「可以出境」這件事有一個統一的確認點。

講者把這層叫做 Agent Gateway，代理的閘道。它的位置在代理和它要存取的東西之間。

為什麼需要它？你可以想像公司裡放了一百個代理，每個代理身上帶著一組權限，各自去呼叫資料庫、寄信系統、財務系統。出了事，你要去一百個地方查是誰做的，而且其中大概有三十個的設定你看不懂，因為那是業務部門自己拉的。

有了這道閘道，所有進出都從同一個地方過。

講者講得很務實。閘道分入口和出口兩邊，出口這一側目前做得比較完整，包含身分驗證、內容安全檢查、其他安全偵測。入口這一側目前只做到內容檢測，把關還沒有出口那麼嚴。他沒有把這件事講成完美方案，反而直接說入口這塊還在補。

我欣賞這種講法。因為在企業裡推這種東西，最怕的就是把它說成萬靈丹，然後第一次出事就沒人相信了。

這裡有個觀念值得停一下。

很多人以為治理就是在事後查帳，看看誰做了什麼。但 Gateway 這個設計的野心更大一點，它想在事前就決定「這個動作能不能發生」。這兩件事的難度差很多，因為事後查帳只要留下紀錄就好，事前攔截你得先想清楚什麼該攔、什麼不該攔。

而這就碰到整個題目最難的地方了。你要攔，就得先知道「誰」在敲門。

02

一個代理，身上有三張身分證

這一段是整場講得最細的地方，我盡量用人話重講一遍。

一個代理在企業裡做事，它身上其實帶著三層身分。

第一層是使用者本人的身分。就是坐在電腦前那個人。他要先登入，公司透過內部的身分系統確認他是誰。這一層的目的是「你有沒有資格用這個代理」。比如說這個代理是給高階主管查財務資料用的，那一般員工就不該進得來。

這一層其實最單純，因為多數公司早就有了。你有員工帳號、有權限分組，這套東西在代理出現之前就跑了幾十年。

第二層是代理自己的身分。這點是很多人會忽略的。代理不是「你」，它是一個獨立的東西，它自己也要有身分證。

講者提到，Google 在部署代理時會自動幫它建立一個專屬身分，不用自己申請。有了這個身分，就能照最小權限原則去開權限，甚至細到按資源來開。

為什麼這一層重要？因為如果代理沒有獨立身分，它就只能借用某個人的權限去動作。那出事的時候你會搞不清楚是這個人做的，還是代理做的。

前兩層講完，多數人會覺得，這樣應該夠了吧。麻煩的事情還沒開始。

第三層最麻煩，是使用者授權給代理的臨時通行證。

設個場景。這個代理要去查一份財務資料庫，它有第二層身分，所以它進得去。但它接下來要讀一份放在某位主管個人雲端硬碟裡的文件，那份文件是那位主管的個人權限才看得到的。

這時候怎麼辦？總不能讓代理拿自己的身分去開，那會變成越權。也不能把主管的帳號密碼給代理，那更荒謬。

解法是發一張臨時通行證給代理，效期很短，用途限定，代理拿著這張證去代替那位主管取資料。

講者說，這三層身分裡，最不想讓它出現在程式碼裡的就是後面兩層。因為一旦寫進程式碼，每一支代理都要自己處理這套權限流轉，寫錯一次就出漏洞，而且非常難維護。

所以他們把這套身分交換做成了平台的內建能力，開發者只要在參數裡打開一個開關，後面兩層的身分轉換就自動處理掉了。程式碼裡完全看不到這些流程。

我聽到這裡覺得，這個設計思路值得記下來。

它的做法是把「正確」變成預設值。

那套權限流程太複雜，工程師寫著寫著就會漏掉一段。與其期待每個人都不出錯，不如讓正確的做法綁在系統的預設值裡，想都不用想。

這件事跟後面幾節講的所有東西，其實是同一個思路的變形。

03

一萬元的退款，這句話要怎麼寫成規則

知道是誰在敲門之後，接著要決定這個人能拿什麼、不能拿什麼。這就是策略。

講者說有兩種寫法，我覺得這兩種寫法的差別，是整場最容易被低估的一段。

第一種是傳統的權限策略。它可以寫得很精細，精細到不只是「這個代理能不能用這個工具」，還能限定它只能用工具裡的某幾個方法，甚至可以限制方法可以動到哪些屬性。

假設公司有一個查訂單的工具，裡面有「查詢」和「修改」兩個動作。傳統策略可以規定這個代理只能查、不能改。再細一點，就算准它改，也可以限定它只能改「運送地址」這個欄位，不能改「金額」。

這種精確度非常夠用，而且判斷是硬的，是或否，沒有模糊空間。

但它有一個罩門。

講者舉了一個例子，我認為這個例子值得記一輩子。

假設公司規定，這個客服代理只能處理一萬元以下的退款申請。

這條規定你要怎麼寫成傳統的權限策略？

理論上可以，但你得把退款金額切成很多段，一萬元以下、一萬五以下、兩萬以下，每一段設一條規則。金額級距一改，全部重寫。而且這種規則寫得出來，只是因為金額剛好是數字。

那如果規定是「不能對情緒激動的客戶直接拒絕」，這要怎麼寫？

寫不出來。

所以有了第二種，語意策略。用自然語言把邊界講清楚，比如直接寫「這個代理只能處理一萬元以下的退款申請」，它會自己去判斷眼前這個請求有沒有超過。

可以寫成 if-else 的，用傳統策略，因為它快、它硬、它不會被騙。寫不成 if-else 的，才交給語意策略。

我特別想強調這個順序。很多企業導入 AI 的時候，習慣把所有規則都丟給模型去「理解」，覺得模型這麼聰明應該聽得懂。但這正好用錯了地方。

模型是機率性的，它聽得懂，但也有聽錯的時候。而規則這種東西，最不能接受的就是「大部分時候對」。

所以正確的順序是，先把所有能寫成硬規則的部分寫死，讓模型只負責處理那些真的需要判斷的模糊地帶。模型的彈性留給該彈性的地方，確定性留給不能出錯的地方。

這個順序很簡單，但我發現很多專案失敗就失敗在這裡。他們把不能出錯的事，交給了只保證「大部分時候對」的東西。

04

四道門，把一百個動作篩到剩下不到一個

這是我認為第二篇最該講清楚的一段。

給代理權限，聽起來像是打開一個開關。但講者說，那其實是四道遞進的門，一道比一道窄。

我把它想成一道漏斗，動作從上面倒進去，逐層篩。

第一道是沙箱。當代理要執行程式碼的時候，先丟進一個隔離的容器裡跑。這個容器只有三十秒，而且完全沒有網路。跑得完、沒出事，才放行。

這一層的用途很明確。比如說你在分析一個來路不明的檔案，需要跑一段腳本去拆它。這段腳本可能有問題，所以先在沙箱裡試。爆了也只爆在裡面。

第二道是規則閘門。這一層處理的是「絕對不能發生的事」。

講者的兩個例子我記得特別清楚，一個是禁止碰觸生產資料庫，一個是禁止一次封鎖掉核心路由。

這種事不需要判斷、不需要衡量情境，就是不行。所以直接寫成程式碼，是就放、否就擋，不經過模型。這是我在上一節講的那個思路的極致版本，把最不能出錯的部分完全從機率性的世界裡拉出來。

第三道是議會。這個名字取得很好，我猜是故意的。

到了這一層，事情開始有點微妙。這個動作不是絕對禁止的，但也不是百分之百確定安全。比如隔離一個網路區段，比如修改一組身分權限。這兩件事在正常運維裡天天在做，但做錯一次會很嚴重。

講者的做法是，讓第二個獨立的模型來複核第一個的判斷。

這個設計的巧妙地方在於它處理的是「盲點」。第一個模型判斷失誤，通常是因為它順著某個思路一路推下去，那個思路本身就錯了。你讓同一個模型再想一遍，它還是會走到同一個結論。但換一個獨立模型，它可能從別的角度看到問題。

這跟人類開會的道理一樣。真正有用的覆核，是找一個跟你想法不一樣的人，不是找一個跟你一樣的人再問一次。

第四道是人工核准。議會如果意見不一致，這個動作就停下來等人簽。

這裡的層級關係要說清楚，不然會誤會成「議會通過就放行」。講者給的分層是這樣，最危險的那一檔，是議會和人工兩道都要過，雙簽把關。也就是說，風險高到某個程度，光靠兩個模型同意的票數是不夠的，還得有人負責。

我特別喜歡講者講這一層時候的語氣。他很明確地說，有了代理不代表不需要人。真的真的很敏感、真的真的很嚴重的操作，還是要有人在迴圈裡做最後判斷。

這句話在一個 AI 大會上講，其實不太討喜。但它誠實。

四道門排下來，你會看到一個很漂亮的設計邏輯。這道漏斗的目的，是讓代理被放心。一百個動作倒進去，九十九個在分流和輕量模型那一層就處理掉了，真正走到議會跟人的不到千分之一。風險被集中到少數真正需要人看的地方，而不是攤平到每一個動作上。

這才是治理設計該有的樣子。它把注意力集中在該花的地方，而不是處處設限讓事情做不成。

05

有權限，不代表有道理

這裡有個很容易被漏掉的層次，我覺得是整場最有洞見的一段。

前面講的三層身分、兩類策略，管的是「你有沒有權限做這件事」。但講者提醒，還有一件事要管，就是「你現在這個動作，在這個情境下合不合理」。

這兩件事不一樣。

舉個例子。一個採購代理，它有下單的權限，這是它的職責，完全合法。但現在是凌晨三點，它突然要下一筆八百萬的單。它有權限，可是這個動作本身很不尋常。

權限檢查會放行，因為它確實有這個權限。但如果你有第二層檢查，它會停下來問一句，這個時間、這個金額，合理嗎？

講者說，所以要有兩條防線。

第一條管身分，判斷你有沒有這個權限。這是靜態的、二元的，有就是有。

第二條管意圖，判斷你現在這個動作在當下的情境裡合不合理。這是動態的、看情境的。

他把這兩條防線的差別，收在一個公式裡，我認為這是整場最值得抄下來的一句。

機率性的模型，加上確定性的防護欄，等於可預測、可擔保的商用級系統。

我看到這個公式的時候，想到的是汽車的安全氣囊。

安全氣囊不是拿來取代駕駛的判斷，它是在駕駛判斷失誤的時候，還有一層不靠人的東西兜底。防護欄的角色也一樣，它讓模型犯錯的時候，結果不至於不可收拾。

講者還有另一句話我很喜歡，前面提過。他說，如果所有環節都可控、可管理，企業才可能大規模使用代理。關鍵是「可管理」，不是「不會犯錯」。

這個區別非常重要。追求「不會犯錯」的系統永遠上不了線，因為它不存在。追求「犯了錯也不會失控」的系統，才是可以上線的東西。

這也是我認為整個 AI 治理最被低估的地方。大家都在問怎麼讓 AI 更準，但企業真正需要的是，怎麼在 AI 不準的時候不受傷。

06

兩個協議，一個管工具，一個管代理

前面講的都是怎麼管住一個代理。但真實的企業不會只有一個。

場景是這樣。公司試點成功之後，各部門開始自己做代理。跟過去系統開發一樣，不同團隊會選不同的語言、不同的框架。這件事你擋不住，也不該擋。

但有一件事會出問題。大家都需要呼叫同一批工具、同一批資料來源。如果每個團隊都自己寫一次串接，那就變成重複造輪子，而且每一套的錯誤長得都不一樣。

所以需要統一的通訊方式。講者提了兩個協議，名字聽起來很像，但管的是兩件不同的事。

MCP 管的是代理跟工具之間。它把工具呼叫的方式標準化，接 API、接資料庫、接各種資源，都走同一套介面。好處是工具只要包裝一次，全公司的代理都能掛上去用。不用每個團隊都重新接一次。

我用一個比喻來理解。這就有點像家電的插頭規格統一了，你不用為每一台電器準備不同的插座。

A2A 管的是代理跟代理之間。這個稍微抽象一點。它讓不同框架做出來的代理可以互相對話、協作，而且重點是，協作的時候不需要把自己內部的記憶、資源、工具都攤開給對方看。

第二個協議我覺得更有意思，因為它處理的是一個很實際的問題。企業裡一定會有這種狀況，A 部門用一個框架做的代理，要跟 B 部門用另一個框架做的代理合作完成一件事。如果沒有共同語言，這件事就只能靠人工在中間傳。

有了這層，架構上就從「一個中央大平台處理所有事」，慢慢變成「很多代理在各處跑，彼此能對話」。講者用的詞是代理網格。

這個演進方向我覺得很值得注意。它的意思是，未來企業不會只有一個 AI 系統，而是有一群互相協作的代理。而治理的角色也跟著變，從「管一個系統」變成「管一個生態」。

管生態比管系統難得多，這就是為什麼前面那些閘道、策略、防護門變得更重要。因為在一個生態裡，你永遠不會知道下一秒會有誰來敲門。

07

一本冊子記「誰」，一本記「能用什麼」

最後這一層，是整個治理架構的底。我覺得它也是最容易被跳過的，因為它做起來最不像在推 AI，更像在整理資產清冊。

場景是這樣的。一家公司推了半年，各部門做了幾百個代理。這時候會出現三種災難。

第一種是安全缺口。有些代理是員工自己拉的，沒有登記，IT 根本不知道它存在。這種叫影子代理，它可能正在呼叫一些不該呼叫的 API。

第二種是重複浪費。三個部門各做了一個功能幾乎一樣的代理，沒有人知道。而且更常見的是，能用輕量模型解決的雜事，大家一律用最貴的模型去跑。

第三種是版本漂移。一堆角落裡的代理還在用舊版模型，那些模型已經不符合最新的個資規範了。它昨天合規，今天不合規，而且沒有人知道。

這三件事的共同點是，你連「有哪些代理在跑」都說不出來。不知道存在，就談不上管理。

講者的解法很乾脆，兩本冊子。

Agent Registry 管「誰」。登記每個代理的身分、擁有者、部署位置、用的是哪個模型版本。它能回答三個問題，現在有哪些代理在跑、誰負責、用的是哪個模型。

Tool Catalog 管「能用什麼」。登記每個工具的功能、用途、資料範圍、哪些代理有權限呼叫。它能回答，哪些工具可用、哪一個被授權碰生產環境的防火牆。

這兩本合起來，就是企業 AI 資產的單一事實來源。

我特別喜歡講者對這件事的一句形容。他說，資訊長最大的噩夢叫「無人管理的影子資產」。你要的是全域控制平面，不是一堆散落的腳本。

這其實就是資產管理。

一家公司有多少台電腦、多少套軟體授權、多少張憑證什麼時候到期，這些東西如果沒有清冊，遲早會出事。IT 部門過去幾十年做的事情，很大一部分就是在維護這份清冊。

現在只是清冊裡多了新的一類東西，叫 AI 代理。它有自己的身分、自己的權限、自己的生命週期，甚至會自己呼叫別的東西。

而它比傳統資產更難管的地方在於，它會動。一台筆電不會自己去改資料庫，一個代理會。

08

沒人想做的那些事

回到開場那句話。

講者在一個賣 AI 的場合上說，談到最後，AI 代理不是在賣 AI，都在講 security 跟 governance。

我把整場聽完，覺得這句話可以有兩種讀法。

第一種讀法是無奈。AI 產業講了兩年的能力，最後卡在使用者的信任上，只好回頭補課。

第二種讀法我更相信。治理不是 AI 的附屬品，治理是 AI 能不能變成生產工具的前提。就像你蓋一棟樓，鋼筋混凝土是主體，但真正決定這棟樓能不能用的，是消防、是結構安全、是逃生通道。這些東西在完工典禮上不會被稱讚，但少了它們，這棟樓根本拿不到使用執照。

講者自己講了一句很坦白的話。他說不會有老闆跑來跟你說，你的 Agent Gateway 做得真酷。

這句話我聽了很有感。在企業裡，做這類事情的人通常拿不到掌聲。你做得好，是因為什麼都沒發生。而「什麼都沒發生」是最難證明的功勞。

但也正是這種工作，決定了 AI 到底只是辦公室的玩具，還是真的能進到生產線。

那組數字說九成的企業卡在治理。我覺得這個數字不必當成警訊，它反而是一個很清楚的路標。它告訴你，如果你想比別人早一點把 AI 用起來，該花力氣的地方不在模型，在那些沒人想做的雜事上。

身分、權限、清冊、稽核。

這幾件事講起來一點都不酷。但就像所有基礎工程一樣，它酷不酷跟你需不需要它，是兩件完全無關的事。

整場活動聽完，我最大的收穫是一個很樸素的判斷方式，產品功能反而一個都沒記住。

以後再有人拿一份 AI 提案來問我該不該做，我大概不會先問它用了哪個模型。

我會問，這東西出事的時候，誰攔得住。

 

---

Google AI Live + Labs Taipei 心得 :

[前篇] 燒了一年的 token 之後，Google 開始談 ROI 了
[後篇] 為什麼最難的不是模型：從 Agent Gateway 看 AI 進企業的最後一哩

---

歡迎訂閱我的文章，第一時間可以收到喔!

常見問題

什麼是Agent Gateway？

Agent Gateway是一道設置在AI代理與它要存取的系統之間的統一關卡，負責身分驗證、內容安全檢查等把關工作。它的作用類似海關，讓所有代理的進出都經過同一個確認點，避免權限設定分散難以追蹤。

AI代理為何需要三層身分驗證？

第一層是使用者本人的身分，確認誰有資格使用這個代理；第二層是代理自己的獨立身分，避免與使用者身分混淆；第三層是臨時授權通行證，讓代理在特定情境下代替使用者存取受限資源。三層分工讓權限歸屬清楚，出事也能追溯責任。

MCP與A2A協議有什麼不同？

MCP管理的是代理與工具之間的溝通，將各種API、資料庫的呼叫方式標準化，讓不同代理都能共用同一套介面。A2A則管理代理與代理之間的協作，讓不同框架開發出來的代理能互相溝通，而不需要攤開各自內部的資源與記憶。

為什麼企業導入AI代理常卡在治理這一關？

因為多數企業一開始只關注模型效能，卻忽略了身分、權限、策略與資產清冊這些基礎工程。當代理數量增加後，若沒有統一的治理架構，就容易出現影子代理、重複浪費與版本漂移等問題，導致專案無法真正進入生產環境大規模使用。