Gemini Enterprise Agent Platform 解析：AI Agent 五分鐘做得出，為什麼半年上不了線？

今年你只要會打字，五分鐘就能 vibe coding（用自然語言邊聊邊寫程式）做出一個 AI Agent（AI 代理，會自己查資料、自己跑流程的小機器人）。

真的，五分鐘。

做一個會自動回信、自動查訂單、自動跑客服的小機器人，現在比泡一碗泡麵還快。

但接下來這句才是重點：

做得出 demo，跟「敢放上線天天幫你跑業務」，中間隔著一條深得嚇人的鴻溝。

這條鴻溝，多少團隊掉進去就再也沒爬出來。

Google Cloud 最近有一場對談，主題就叫《From Prototype to Production》（從原型到生產），主持人找來兩位 Google 老將 Dave Elliot 跟 Addie，專門講這條鴻溝怎麼跨。他們端出來的東西，叫做「Gemini Enterprise Agent Platform」（Gemini 企業代理平台）。

名字很拗口對吧？我用生意人的話翻一次：

這是 Google 蓋的一條「AI Agent 生產線」。

為什麼一堆 AI 專案，停在「我們也做了一個 demo」

你知道為什麼這麼多公司的 AI 專案，講完「我們也做了一個 demo」就再也沒下文了嗎？

不是技術不夠強。是 demo 跟正式上線，要操心的事情根本是兩個世界。

想像一下，你早上開完會，興沖沖跟老闆 demo 了一個 AI 客服代理，老闆眼睛一亮：「很好，下週上線。」

然後你回到位子上，冷汗才開始流。

這個 agent 用誰的帳號去存取公司資料庫？出了事，你查得到是哪一隻 agent 動的手腳嗎？它記不記得這個客人上一通電話講過什麼？它會不會哪天腦袋一抽，把不該退的款全退掉？

對談裡 Dave 講得很白。他說客戶最常跟他抱怨的，就是「我做得出東西，但接下來我得操心身分認證、操心治理、操心記憶，最後還得自己把一堆服務東拼西湊串起來」。

說到 AI 落地為什麼老是卡關，我之前拆過矽谷的解法，那篇講前線部署工程師 FDE 怎麼把 AI 從工具變成員工。那篇談的是「人」怎麼補位，今天這篇談的是「agent 本身」怎麼被管好。兩半合起來，才是完整的落地。

這就是 demo 跟 production（生產環境）的差別。

demo 比的是「會不會動」。

production 比的是「敢不敢放心讓它一直動」。

Google 這次做的事，就是把「敢不敢放心」這四個字，拆成四道關卡，一關一關幫你補起來。我帶你走一遍。

第一關 Build：先有一套順手的框架

這一關其實最不用擔心。

蓋 agent 的核心框架叫 ADK（Agent Development Kit，代理開發套件），Google 去年在 Cloud Next 就發表了，現在支援 Python、Go、TypeScript、Java 四種主流程式語言，是你從 0 到 1 把 agent 快速做出來的地基。

這就像你要開餐廳，爐具、鍋子、抽油煙機，市面上早就買得到，裝潢一週搞定。

難的從來不是開張第一天。

難的是天天穩定出餐、不出包、客人吃了不拉肚子。後面三關，講的都是這件事。

別小看這層地基。整個團隊用同一套框架交付 agent，才不會你寫你的、我串我的，最後拼出一坨沒人敢碰的東西。

第二關 Govern：幫每一隻 agent 發一張「員工識別證」

這一關，Dave 自己說是「隱藏的寶石」。

裡面有閘道（Gateway）、代理身分（Agent Identity）、代理註冊表（Agent Registry），還有異常偵測（Anomaly Detection）。

他講了一句我很有感的話：這根支柱根本不是「AI 的事」，它是「企業的事」、是「雲端的事」。Google 有一支做這些做了很多年的工程團隊，現在只是把老本行那套搬到 agent 身上。

我用我自己的老本行翻給你聽。

我以前在百貨公司站過專櫃當櫃哥。那時候每個櫃哥都有自己的員工編號、自己的刷卡權限。你不會讓整層樓的人共用同一張識別證，為什麼？因為出了事，你得查得到是誰。

過去玩 agent 的麻煩就卡在這。很多人圖方便，讓一堆 agent 共用同一組 token（存取權杖）、同一個帳號，糊里糊塗就串上去了。結果某天系統被亂搞，你連是哪一隻 agent 幹的都查不出來。

現在 Google 的做法是，給每一隻 agent 發一張「加密生成的身分證」（cryptographically generated identity）。它要存取哪個系統，就用自己這張經過認證的身分去敲門，全程留下稽核軌跡（audit trail）。

一隻查得到、追得到、出事能定責的 agent，才有資格被放進公司的正式流程裡。

別把這當技術潔癖。這是你敢不敢把它放上線的底線。

關於「管 agent」這件事，我在另一篇給電商老闆的三條 AI 治理原則講得更白，有興趣可以搭著看。

第三關 記憶：agent 到底有沒有「記性」

這一關，如果你問我，是最被低估的。

Addie 講，大概一年前開始，「記憶」突然變成 agent 最大的痛點。不是它跑不動，是它跑得「不到大家期待的水準」。

我在雨傘工廠跑了幾年業務，最值錢的本事是什麼？

是記性。

記得這個老客戶上次嫌貨櫃晚到、記得他偏好深色傘布、記得他老闆娘下個月要嫁女兒。一個記得你的業務，跟一個每天都像第一次見面的業務，成交率天差地遠。

agent 也是一樣的道理。沒有記憶的 agent，就是那個每天都不認識你的菜鳥業務。

Google 在這一關推了兩個東西。

一個是 Memory Bank（記憶庫），現在已經正式開放（GA）。它最貼心的地方是：你不必自己變成記憶體管理專家。它會自動判斷「這段資訊好像值得記下來，存吧」，之後再幫你管理跨會話（cross-session）的長期記憶。

另一個更猛，叫 Long-running Agents（長時間運行代理）。

以前的 agent，跟你聊完一段對話就「失憶」，下次回來什麼都不記得。

現在的 agent，能扛著一個跑好幾天、甚至一整週的專案，中途不掉鏈子、不忘記自己做到哪。Dave 說，這現在是 Gemini Enterprise 裡的「一級公民」（first-class）。

你想想，一隻能連跑兩週、不會半路斷片的 agent，能幫你扛掉多少原本得有人盯著的長流程。

再想深一層：agent 一路記下來的東西，其實就是你公司最值錢的第一方資料（first-party data）。這也是 AI 時代真正的護城河。

第四關 Optimize：試吃員、監視器，跟一個沙盒

這是最新、也最前沿的一關。Google 自己說這整根支柱都是新的。它解決的是 agent 最讓人睡不著的那件事：你根本不確定它下一步會幹嘛。

我把這一關拆成三樣東西講。

第一樣，Agent Eval（代理評估），對付「非確定性」。

LLM（大型語言模型）本來就是非確定性的（non-deterministic），同一個問題問兩次，答案可能不一樣。agent 又是一串 LLM 接起來的，當然更不確定。

Addie 講得很妙：這對大家應該不算意外，LLM 不是確定性的，「居然有人會驚訝喔？」

問題是，你把一個不確定的東西，放進公司的關鍵流程（critical path），風險就來了。尤其現在大家都在把多隻 agent 串成「協作艦隊」，一隻不確定，整條鏈子都跟著抖。

Agent Eval 的價值，就是讓你「在它有點隨機的前提下，還能有某種程度的保證，整條流程確實把該做的事做完了」。它還能跑模擬（simulation），用一個儀表板一次看你整間公司所有 agent 的表現。

這就像餐廳出餐前的試吃員。廚師手藝再好，每道菜送上桌前還是得有人先嚐一口，確認沒走味。

第二樣，可觀測性（Observability）與追蹤（Tracing）。

Dave 說，這要拉回到當年雲端可觀測性的老觀念：把 agent 做過的每一個動作，畫成一張圖。

出事的時候，你能倒帶，看是哪一步邏輯壞掉，然後把它修好。

你管不住一個你看不見的東西。

第三樣，Sandbox（沙盒），限制「爆炸半徑」。

這個詞我超喜歡：blast radius，爆炸半徑。

給 agent 工具跟權限，等於給它能力。但能力越大，搞砸的時候破壞也越大。Sandbox 就是幫它裝上護欄，框死它能碰的工具範圍。

Addie 的形容很到位：我們知道有些 agent 需要比別人更大的權力，但這不代表我們不裝護欄，至少要確定它「不會把我們的銀行帳戶整個清空」。

這道理，我是吃過虧才懂的。

早年我自己貪方便，訂閱一堆工具，權限全開、自動扣款全開。結果有幾次忘了取消，月底帳單來才發現被默默扣了一整年。

一個權限全開、又不會自己喊停的東西，遲早讓你出血。

Dave 的比喻最好笑。他說對寫程式的 coding agent（程式代理）尤其重要：我只想給它一支榔頭、幾根釘子，叫它去蓋個鳥屋就好，我幹嘛把整個工具箱、把所有權限預設全開丟給它？

給 agent 自主權，但別給它能炸掉整間公司的權力。

那你現在該做什麼？

四關走完，回到你身上。如果你正在想「我們公司也該搞個 agent 了」，這五件事先放心上：

► 第一，先分清楚你在「做 demo」還是「上 production」。 只是想驗證點子？五分鐘 vibe coding 就夠了，別在治理上浪費力氣。但只要你打算讓它碰真客戶、真金流、真資料，後面那四關，一關都不能跳。

► 第二，先問「身分」跟「稽核」。 導入任何 agent 之前，先逼自己回答一句：它用誰的身分？出事查得到是它幹的嗎？答不出來，先別上線。

► 第三，把「記憶」當需求，不是加分題。 如果你的 agent 要跨天、跨會話服務同一個客戶，記憶就是基本盤。別等到客戶抱怨「怎麼每次都要重講一遍」才補。

► 第四，上線前先算好它的「爆炸半徑」。 列出這隻 agent 最壞能闖多大的禍，再用沙盒跟權限把那個半徑框起來。只給它完成任務需要的工具，多一樣都不給。

► 第五，裝好「儀表板」再放手。 沒有可觀測性、沒有評估機制就上線，等於蒙著眼睛開車。Agent Eval 跟 tracing 不是上線後再補的東西，是上線前就要備好的東西。

工具一直換，但解決問題的人沒被換掉

這場對談收尾在一個我很有感的問題：AI 時代，工程師還剩什麼價值？

Dave 的答案很乾脆。他說工程師的本質是「解決問題的人」。工具一直在換，從程式語言、IDE、函式庫，換到現在的 AI，但「解決問題」這件事從來沒變。

Addie 補了一句軟體工程界的名言，出自 Grady Booch：「軟體工程的歷史，就是一部抽象層級不斷往上疊的歷史。」（the history of software engineering is a history of a rising set of abstractions）

以前你要一行一行寫程式，現在你指揮一群 agent 幫你寫。

以前一個人能管的事情有限，現在一個人要管一支「agent 艦隊」（fleets of agents）。

但有件事沒變：總得有人為品質負責、為架構負責、為「這群 agent 到底有沒有在做對的事」負責。

他們把這一刻，拿來跟 PC 時代、網際網路、智慧型手機的普及相提並論。這三個詞你應該很熟，因為每一個都把整個產業重新洗了一次牌。

我自己從雨傘傳產一路走到數位行銷，看過太多次「工具大換血」。每一次都有人覺得天要塌了，也每一次，都有人趁亂卡進新的位置。

這一次也一樣。

重點是什麼？

這條 AI Agent 生產線，現在才剛搭好。會用它的人，往往不是技術最強的那個人。是最早搞懂「怎麼讓 agent 安全地幫你賺錢」的那個人。

那個人，也許就是你。

資料來源：Google Cloud 對談影片《From Prototype to Production: Building with Gemini Enterprise Agent Platform》，與談人 Dave Elliot、Addie。文中產品功能、開放狀態與平台政策，請以 Google Cloud 官方最新公告為準。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。