AgentSpace：打造代理驅動型企業

我們坐在螢幕前處理工作時，最大的瓶頸往往不是缺乏資料，而是日積月累建立起來的那個龐大的數位官僚系統。為了推進一個專案，我們得在 Jira 裡撈進度，再翻幾千封郵件找某個客戶三個月前的確認信，接著登入 Workday 核對資源。每天光是來回切換這些系統、手動搬運資訊，就把時間耗盡了。

本文探討 Google 的 AgentSpace 如何將 AI 整合進日常工作流程，幫助組織轉型為所謂的代理驅動的企業（Agent-Driven Enterprise）。目的是讓 AI 在背景自行開會，打破數位碎片化，讓系統自己去溝通。

統一的企業搜尋：AgentSpace 的核心

AgentSpace 的核心能力是統一的搜尋功能：在組織的整個數位足跡——文件、電子郵件、資料庫——提供一致化的存取管道。這不是單純的關鍵字檢索，而是以 Gemini 的多模態理解，跨越文字、圖片、網頁、音訊與影片去綜合資訊。企業知識圖譜、多代理協作與無程式碼建置，全都建立在這個統一座之上。

AgentSpace 的層次架構
─────────────────────────────────────
┌───────────────────────────────────┐
│ 無程式碼建置（Agent Designer）       │
├───────────────────────────────────┤
│ 代理編排（多代理 + A2A）            │
├───────────────────────────────────┤
│ 上下文理解（企業知識圖譜）          │
├───────────────────────────────────┤
│ 統一的企業搜尋（文件/郵件/資料庫）   │ ← 核心基礎
└───────────────────────────────────┘

用開場的例子來說：過去我們得分別在 Jira、郵件、Workday 之間切換才能拼湊出一個專案的樣貌；統一的企業搜尋讓代理能以單一管道存取所有系統，把碎片化的資訊彙整在一起，這正是打破數位官僚系統的第一步。

代理驅動的企業：不是外掛的聊天機器人

第一次聽到「代理驅動的企業」這個詞，我們腦中浮現的畫面，可能只是公司為每個員工買進階版 AI 聊天機器人帳號，有問題就去問——這其實是很常見的誤解。

把聊天機器人當作外掛工具，需要時下指令，這依然是被動的；而代理驅動的企業，在架構上是將具備自主能力的 AI 代理直接編織進企業底層營運結構。這些代理以 Google Gemini 這類先進大型語言模型作為大腦，但不是被動等待我們發問——它們具備自主推理、規劃，甚至跨系統執行多步驟行動的能力。

以指派代理研究某個新的市場趨勢為例，它的運作邏輯不是單純把帶有關鍵字的檔案調出來，而是自主規劃並執行整個分析流程：

① 檢索外部市場資料
        │
        ▼
② 查詢內部過去兩年的專案檢討報告
        │
        ▼
③ 綜合資訊，撰寫帶有精確內部引文的報告
        │
        ▼
④ 通勤中，將報告即時轉化為音訊摘要

它執行的是一整套分析流程，而不只是資料提取。這正是「代理驅動」與「AI 外掛」在本質上的差異——前者把自動化分析直接嵌入工作流程，而不是等著人類發號施令。

企業知識圖譜：讓 AI 看懂組織脈絡

這裡出現一個關鍵盲點：如果一家企業有數以 TB 計的資料庫，裡面充滿五年前過時的行銷文案或廢棄的專案草稿，AI 在做自主推理時，怎麼知道哪些資訊對我們才是真正重要的？

AgentSpace 的答案是引入企業知識圖譜（Enterprise Knowledge Graph）。傳統的向量搜尋只看字面上的相似度，而知識圖譜在底層繪製了實體之間的立體關係——人員、檔案、專案、資料表之間是如何連結的。

傳統向量搜尋：圖書館檢索終端機
────────────────────────────────
輸入關鍵字 ──► 死板地回報「這本書在第 3 排書架上」

企業知識圖譜：超級圖書館員
────────────────────────────────
讀過館內所有書 + 知道我們同事上週借了哪幾本書
+ 我們團隊這幾天在 Slack 上討論什麼專案
──► 根據隱形脈絡，直接把最相關的段落整理出來

因為有這層圖譜結構，AI 在檢索資訊時，演算法權重會大幅偏向當前的業務脈絡。它知道我們跟某個同事在同一個工作群組，或昨天共同編輯過某份 Google 檔案。有了這層關係的記憶，它給出的分析才是高度個人化且精準的，而不是放諸四海皆準的泛泛之談——這能省下幾個小時拼湊資訊的時間。關於知識圖譜與 RAG 的關聯，可參考這裡-RAG：讓 AI 從只能聊天到引用資料。

值得一提的是，AgentSpace 不只整合企業內部的私有知識圖譜，也支援與 Google Knowledge Graph 整合。後者涵蓋全球公開的實體知識（人物、組織、地點之間的關係），補上私有資料庫之外的世界知識——讓代理在回答「我們的競爭對手今年發布了什麼」這類問題時，能同時查閱外部公開資訊與內部專案脈絡。

多代理協作：A2A 協定下的專業分工

企業裡幾乎沒有什麼複雜任務是單一部門可以獨立完成的。以員工入職為例，這牽涉到人資的合約、IT 的裝置派發、總務的權限設定——單一個 AI 再強大，也很難同時精通法律用語和 IT 基礎設施的 API。當任務跨越過多專業領域，讓一個萬能模型處理所有事，不僅運算成本極高，也容易產生幻覺或給出不專業的決策。

AgentSpace 因此走向多代理系統：多個專門的 AI 代理，透過開放的 Agent2Agent（A2A）協定彼此通訊與協作。負責審查法律條文的代理，其內部的系統提示詞與安全護欄，跟負責寫對外行銷文案的代理完全不同——它們各自有各自的專業。A2A 的完整架構可參考這裡-A2A 協定：打破 AI 溝通的高牆。

承接開頭員工入職的例子，專業分工的協作序列是這樣的：

人資代理                     IT 代理               總務代理
   │                          │                        │
   │── 建立合約 ──────────────►│                        │
   │                          │── 確認配備需求 ────────►│
   │                          │◄─ 回傳裝置型號 ────────│
   │◄─ 回報已派發裝置 ─────────│                        │
   │── 傳送員工資料 ──────────►│                        │
   │◄─ 回報帳號與權限已開通 ───│                        │

人資代理不懂 IT 的裝置型號，IT 代理不了解合約的法律用語——但透過 A2A 協定，它們可以在不同部門的系統之間來回交涉，把「入職」這個跨專業流程拆成一次次明確的委派，而不是靠人類在工具之間搬運。

但多代理協作最令人擔憂的是黑箱作業：代理在看不見的後台互相交涉，我們怎麼知道它們在做什麼決定？AgentSpace 在架構上提供嚴格的日誌記錄與審計追蹤——每一次代理間的交涉（誰委派給誰、帶了什麼任務、結果如何）都會被記錄下來，人類管理者隨時可以介入，檢視這個決策鏈是如何形成的。這不是數位官僚主義，而是像一支精心編排的交響樂：每個專門的代理負責自己的樂器，A2A 協定就是確保彼此音調和諧的樂譜。

無程式碼革命：Agent Designer

這套架構聽起來極度複雜——又是知識圖譜、又是 A2A 通訊、又是各種 API 串接，一般人會直覺認為需要一支五十人的資深工程師團隊，花半年才能架設起來。AgentSpace 在此引入無程式碼革命：透過名為 Agent Designer 的圖形化介面，把底層複雜性全部對一般使用者隱藏起來。

使用者登入 Google Cloud Console，從「AI 應用程式（AI Applications）」進入 AgentSpace，不需要懂怎麼寫 OAuth 的授權程式碼，也不需要懂怎麼解析 Workday 的 JSON 資料。抽象化機制在底層動態處理 API 呼叫、身份驗證與非同步資料處理，表層使用者只需要點選與拖曳，就能把 Google 日曆、Gmail、Workday、Jira、Outlook、ServiceNow 等服務連接起來。行為設定上，可以從 Google 提供的預製提示庫挑選指令，或用白話文寫下自訂需求。

以一位專案經理為例，他不需要排隊等 IT 部門幫他寫自動化指令碼，而是直接用這些積木拼出一個數位員工：每天早上自動把 Jira 高優先權的票證、信箱裡客戶的來信、今天的會議行程，統整成一份摘要。這等於把自動化的權利直接交到最懂業務痛點的人手上——技術平民化賦予第一線人員極大的賦權。當普通業務人員或行銷人員不需要寫程式碼，也能建立具備自主規劃能力的代理時，組織內部解決問題的速度將成指數級成長。

Agent Designer 介面示意（無程式碼建置）
──────────────────────────────────────
[ 資料來源 ]  [ 行為設定 ]
  ☑ Google 日曆   提示：預製提示庫 / 自訂白話文
  ☑ Gmail
  ☑ Jira         [ 整合企業知識圖譜 ]
  ☑ ServiceNow
                 [ 部署 │ 測試 │ 分析 ]

除了資料來源與提示詞，Agent Designer 還有幾項進階能力，讓代理從「單一聊天助理」進化成可營運的系統。這就像是樂高積木的擴充包——基礎顆粒負責拼出代理的骨架，這些進階積木則決定代理能延伸到多遠：

以分析功能為例，這讓管理者能回答「哪個代理被最常使用」「哪個步驟最耗費資源」這類問題，讓無程式碼建置的代理也能被量化管理，而不只是曇花一現的實驗。

建置完成後，代理會出現在 AgentSpace 的聊天介面中——這是使用者實際與代理互動的入口。透過這個介面，團隊可以直接向代理下達任務、查看執行結果，把無程式碼建置的成果轉化為日常可用的數位員工。

安全是核心元件：RBAC 與身份繼承

把技術門檻降得這麼低，讓大家都能輕鬆連接系統，而底層知識圖譜又串起公司所有資料——這難道不是一場資安災難？如果隨手建一個代理去查資料，它會不會順便讀取執行長的私人郵件，或把公司還沒公開的裁員名單撈出來，當作早晨摘要？

在這種架構下，安全性絕對不能是事後才補上的，而是核心基礎元件。除了最基本的資料傳輸與靜態加密之外，AgentSpace 的關鍵機制是嚴格落實基於角色的存取控制（RBAC）。它的運作方式不是讓 AI 假裝不知道，也不是事後把敏感數字打上馬賽克，而是：代理在替我們執行檢索時，完全繼承我們的身份與權限去存取知識圖譜。

使用者身份 ──► 代理（帶著名片，而非自由身）
                  │
                  ▼
          存取知識圖譜
                  │
          ┌───────┴────────┐
          │ 有權限的資料    │ 無權限的資料
          │ → 正常檢索     │ → 在檢索路徑中根本不存在
          └────────────────┘

如果我們的職位沒有權限看到那份裁員名單，那麼在代理替我們生成的資料檢索路徑中，那份檔案根本不存在——它無法讀取、無法推理，當然也就無法回答。知識只有在被安全且負責任地應用時才最有價值。這也解釋了為什麼它被稱為「代理驅動的企業」而不是單純「導入 AI 工具」：改變的是營運的根本結構。

對 UI/UX 的影響

代理驅動型企業的介面設計，與傳統聊天機器人有三個關鍵差異。

第一，代理的執行過程必須可見。 當代理自主規劃並執行多步驟任務（檢索外部資料、查詢內部報告、生成摘要）時，UI 需要把這條執行鏈呈現在使用者眼前，否則使用者只會看到一個「正在思考」的轉圈圖示。介面設計參考：

┌─────────────────────────────────────────────────┐
│ 🔍 市場趨勢研究代理                               │
├─────────────────────────────────────────────────┤
│ 使用者請求：研究 2026 年東南亞電商市場趨勢        │
│                                                 │
│ ① 檢索外部市場資料          ✓ 完成               │
│ ② 查詢內部專案檢討報告      ✓ 完成（2 篇引用）    │
│ ③ 生成帶引文的報告          ⏳ 生成中             │
│ ④ 轉為音訊摘要              待執行               │
│                                                 │
│ [查看決策鏈] [調整提示詞] [下載報告]             │
└─────────────────────────────────────────────────┘

第二，權限邊界要誠實呈現。 RBAC 讓代理繼承使用者身份，但使用者需要知道「哪些資料是我們自己的代理可以觸及的」。當檢索結果因為權限而被過濾時，介面應顯示類似「此結果依權限已過濾」的提示，而不是讓使用者誤以為資料不存在——透明反而建立信任。

第三，無程式碼建置流程本身就是 UI。 Agent Designer 的使用者不是開發者，而是專案經理、業務人員。介面必須用積木式的視覺語言呈現資料來源、提示詞與輸出，並提供即時預覽，否則「賦權第一線」就只是口號。

前後端技術怎麼實作

對應上述 UI/UX 影響，前後端有一條清晰的分工線：後端負責把代理的執行軌跡轉成結構化事件，前端負責把事件渲染成使用者看得懂的流程。

後端：以事件流串出代理執行鏈

不管代理底層是怎麼自主推理的，後端都應該把多步驟執行軌跡轉成可串流的結構化事件，透過 SSE（Server-Sent Events）推送給前端。以 TypeScript 為例：

// 後端：把代理的執行軌跡轉成結構化事件
type AgentStep =
  | { type: 'step_start'; stepId: string; label: string }
  | { type: 'step_done'; stepId: string; output: string }
  | { type: 'tool_call'; tool: string; args: unknown }
  | { type: 'a2a_delegate'; to: string; task: string } // 委派給其他代理
  | { type: 'filtered_by_rbac'; reason: string }        // 因權限被過濾的結果
  | { type: 'done'; result: string }

// 前端（React）：把執行鏈渲染成步驟清單
import { useEffect, useState } from 'react'

function AgentRunView({ runId }: { runId: string }) {
  const [steps, setSteps] = useState<AgentStep[]>([])

  useEffect(() => {
    const es = new EventSource(`/api/agent-runs/${runId}/stream`)
    es.addEventListener('step', (e) => {
      setSteps((prev) => [...prev, JSON.parse(e.data)])
    })
    return () => es.close()
  }, [runId])

  return (
    <ol className="agent-steps">
      {steps.map((s, i) => (
        <li key={i}>
          {s.type === 'tool_call' && `🔧 呼叫 ${s.tool}`}
          {s.type === 'a2a_delegate' && `🤝 委派給 ${s.to}`}
          {s.type === 'filtered_by_rbac' && `🔒 已過濾：${s.reason}`}
        </li>
      ))}
    </ol>
  )
}

判斷在後端，呈現在前端。 代理該呼叫哪個工具、該委派給哪個代理、哪些結果因 RBAC 被過濾——這些判斷必須在後端完成，前端只負責把狀態畫出來。讓代理去呼叫的邏輯（A2A 委派、工具選擇）與 UI 分開測試，其他系統（報表、排程）也能重複使用。

動手實作：Google Cloud Skills Boost 實驗室

想親自動手驗證今天討論的機制，可以到 Google Cloud Skills Boost 找實驗室「使用 AgentSpace 建立 Gen AI 代理（Building with AgentSpace）」。這是一個完整的沙盒環境，實際步驟大致如下：

1. 從 Google Cloud Console 建立或選取專案，啟用必要的 API
        │
        ▼
2. 進入 Agent Designer，從「AI 應用程式」進入 AgentSpace
        │
        ▼
3. 連接資料來源：勾選 Google 日曆、Gmail、Jira 等服務
        │
        ▼
4. 設定行為：挑選預製提示庫的指令，或寫下自訂需求
        │
        ▼
5. 整合企業知識圖譜，讓代理帶有組織脈絡
        │
        ▼
6. 部署後，在 AgentSpace 聊天介面實際與代理對話、驗證輸出

這個過程會實際感受到無程式碼介面如何驅動後端的 AI 模型——我們不是在寫 API 呼叫，而是透過積木式的操作把資料來源、提示詞與知識圖譜組裝成一個可用的代理。親自設定一次提示詞與 API 串接，會對技術的邊界有更具體的認知。

總結

AgentSpace 從一個核心基礎往上堆疊，讓組織走向代理驅動的型態：統一的企業搜尋打通所有系統的資料，企業知識圖譜賦予 AI 上下文意識（並可連結 Google Knowledge Graph 補上外部知識），A2A 協定讓多代理專業分工，Agent Designer 以無程式碼介面讓自動化民主化，加上資料儲存、Web 公開介面與分析監控等進階能力，最後以 RBAC 身份繼承確保權限與信任不被打破。這些層次環環相扣、缺一不可——沒有統一的搜尋，資料仍是碎片；沒有知識圖譜，AI 給的是泛泛之談；沒有 A2A，複雜任務只能靠萬能模型硬撐；沒有無程式碼介面，技術門檻把多數人擋在門外；沒有 RBAC，這些能力就成了資安漏洞。

值得注意的是，這套架構是疊加在組織既有的數位基礎設施之上，而不是打掉重練——AgentSpace 連接的是我們早已在用的 Jira、Workday、ServiceNow 等系統，把 AI 代理嵌入既有營運結構，而非要求企業另起爐灶。

站在更長遠的角度，這裡有一個值得深思的問題：既然 AgentSpace 這類技術能讓數位代理自主推理、透過 A2A 協定溝通、直接執行跨系統的複雜任務，那麼幾年之後，我們對工作的定義會變成什麼？當我們每天的主要職責，從親自動手處理資料與流程，變成指派、監督一群數位代理時，人類在這個決策迴圈裡扮演的，究竟是掌握全局的掌控者，還是只是幫這些聰明代理按下確認鍵的橡皮圖章？

我認為答案取決於我們在架構設計上的選擇，而 AgentSpace 給了一個值得參考的方向。它的設計哲學——身份繼承、RBAC、審計追蹤——其實是把「人」刻意留在決策迴圈裡：權限永遠跟著人走，重要決策鏈永遠可以回溯。換句話說，即使代理變得再自主，架構仍舊為人類保留了「最後一層決定權」的位置。只要這個原則被堅守，代理驅動的企業就不會把人排除在外，而是把我們從資訊搬運中解放出來，投入真正的決策與創新——關鍵不在代理多聰明，而在我們如何設計與它們的界線。這正是代理化真正該帶來的價值。

最後補充一點實用性：本文談的是 AgentSpace 這個具體平台，但背後的架構決策——統一的資料存取、知識圖譜提供上下文、多代理專業分工、權限繼承、審計追蹤——並不綁定特定廠商。即使我們不用 AgentSpace，而是用 LangGraph、CrewAI 等開源框架搭建自家多代理系統，這些原則一樣適用。把本文的層次架構當作設計藍圖，再挑選適合的實作工具，概念就能平移回自己的專案。

參考資料

• Agentic Design Patterns - Appendix D: Building an Agent with AgentSpace (online only)
• Create no-code agents with Agent Designer (Google Cloud docs)
• Google Agentspace enables the agent-driven enterprise (Google Cloud Blog)
• Bringing AI Agents to Enterprises with Google Agentspace (Google Cloud Blog)
• Google Cloud Skills Boost