本次議程將分享國泰銀行在規劃與建置企業級 Agent 管理平台 GAIA 2.0 過程中的設計思考與架構取捨，聚焦於 AI Agent 從 PoC 走向正式上線時，企業必須面對的 AgentOps 生命週期、權限控管、與平台化管理議題。

隨著 AI Agent 開始被導入企業內部流程，挑戰已不只是如何讓 Agent 回答問題，而是如何讓 Agent 在符合企業安全規範、上線流程、權限控管與維運要求的前提下，被不同開發團隊穩定地開發、部署、使用與持續演進。尤其在金融業場景中，Agent 一旦開始呼叫工具、串接內部系統或存取企業資料，就必須被納入更嚴謹的治理框架。

相較於一般 Web Service，Agent 具備更高的不確定性與運行複雜度。傳統服務多半是明確的 Request / Response 模型，但 Agent 可能涉及多輪推理、工具調用、長時間任務執行與跨系統操作。因此，企業不能只用一般應用程式的方式管理 Agent，而需要重新思考 Agent 的上架、授權、監控、更版與下架流程。

GAIA 2.0 是國泰銀行針對 Agent 應用所規劃的部署與管理平台，目標是讓不同團隊可以在安全、可觀測、可控管的環境中開發、部署與營運 Agent。本議程將以 GAIA 2.0 的建置經驗為例，分享企業在設計 Agent 管理平台時，會遇到的三個核心問題：

 

第一，AgentOps 生命週期如何設計。

企業內部的 Agent 不只是開發完成後部署上線即可，還需要有明確的上架、申請使用、更版、停用與下架流程。尤其在金融業環境中，上線流程通常需要配合既有 CI/CD Pipeline、行政申請、資安審核與維運責任分工。如何在不破壞既有企業流程的前提下，建立一套適合 Agent 的生命週期治理，是 GAIA 2.0 的重要設計課題。

第二，Agent 的權限與安全邊界如何控管。

Agent 可能不只是查詢資料，也可能呼叫工具、串接內部 API，甚至進一步透過其他 Agent 或工具完成任務。這使得企業必須回答幾個關鍵問題：Agent 可以代表誰執行任務？可以呼叫哪些工具？可以看到哪些資料？哪些操作需要審核？如何避免 Agent 因為自主執行而取得不該有的權限？本議程將分享 GAIA 2.0 在權限控管設計上的思考，特別是 Agent 自身權限與使用者委派權限之間的差異。

第三，為什麼需要 Agent Gateway 作為治理中樞。

當企業內部開始出現多個 Agent、多個工具與多個後端系統時，如果每個 Agent 都直接點對點串接工具與服務，後續會產生權限分散、路由混亂、稽核困難與維運成本上升等問題。因此，GAIA 2.0 在架構上導入 Gateway 的設計思維，將 Agent 的工具呼叫、權限驗證、服務路由與執行紀錄集中在平台層治理，降低各開發團隊重複實作安全與控管機制的成本。

 

（本議程無實機示範，將以架構圖、流程圖與設計案例進行說明。）

 

# AgentOps 在做什麼？

GAIA 2.0 是國泰銀行針對 AI Agent 應用所規劃與建置的企業級部署與管理平台。它的目標不是開發單一 Agent 應用，而是提供一套讓內部多個團隊能夠安全開發、部署、申請使用、維運與下架 Agent 的共通平台能力。

在企業環境中，Agent 不只是接上大型語言模型的聊天服務。當 Agent 開始具備任務規劃、工具調用、內部系統串接與跨流程執行能力時，它就會帶來不同於傳統應用的治理挑戰。企業需要知道每個 Agent 是誰開發的、誰可以使用、可以呼叫哪些工具、可以存取哪些資料，以及出現異常時如何追蹤與停用。

因此，GAIA 2.0 將 Agent 視為一種需要被治理的企業級資產，並從 AgentOps 生命週期、權限控管、與 Gateway 架構等面向，思考 Agent 從 PoC 走向 Production 所需的平台能力。

 

# 該場景有什麼價值及效益？

企業在導入 AI Agent 時，常見瓶頸不是 PoC 做不出來，而是 PoC 難以上線、難以審核、難以控權、難以維運，也難以被其他團隊重複使用。

GAIA 2.0 的價值在於將 Agent 的開發、上架、申請、授權、部署、觀測、更版與下架流程平台化，讓不同團隊不需要各自重新解決相同的治理問題。透過一致的平台設計，企業可以降低 Agent 專案從 PoC 進入正式環境時的溝通成本與安全風險。

對金融業而言，這樣的平台化設計尤其重要。因為 Agent 一旦可以自主呼叫工具或內部系統，企業就必須確保它不會看到不該看的資料、不會執行不該做的操作，也必須留下足夠的紀錄以支援後續稽核與追蹤。GAIA 2.0 希望透過平台化治理，讓 Agent 能夠在可控、可審核、可維運的前提下逐步擴大應用。

 

# 專案架構設計

本次議程將聚焦在企業級 Agent 管理平台的設計思維，而不是單一模型或單一 Agent 框架。GAIA 2.0 的架構設計可從三個層次理解：AgentOps 生命週期、權限治理機制，以及支撐這些治理能力的平台架構。

 

AgentOps 生命週期：企業內部的 Agent 不能只用「開發完成後部署上線」的方式管理。從平台治理角度來看，一個 Agent 至少需要經歷上架、申請使用、更版、停用與下架等不同階段。在 GAIA 2.0 的設計中，AgentOps 生命週期關注的不只是技術部署，也包含行政申請、審核流程、權限核發與維運責任。尤其在金融業環境中，所有上線流程都需要符合既有規範，並整合到標準化的 CI/CD Pipeline 與審核流程中。這裡的挑戰在於，平台團隊不一定能直接操作所有 CI/CD 或部署環境，但仍需要提供清楚的流程設計與介面，讓 Agent 的上線、更版與下架可以被追蹤、被審核，也能與既有企業流程銜接。因此，GAIA 2.0 將 AgentOps 視為一個跨技術、流程與治理的生命週期設計，而不只是單純的部署自動化。

 

權限控管與安全治理：Agent 的權限問題，是企業導入 Agent 時最容易被低估、但也最關鍵的議題之一。在一般應用中，權限控管通常可以圍繞使用者或系統帳號設計。但在 Agent 場景中，情況會更複雜。Agent 可能代表系統執行任務，也可能代表某個使用者查詢資料；可能直接呼叫工具，也可能透過其他 Agent 或中介服務間接完成任務。因此，GAIA 2.0 在權限設計上會特別區分兩種思考方式：

• 第一種是 Agent 自身權限。也就是 Agent 作為一個系統角色，可以呼叫哪些工具、可以連接哪些服務、可以執行哪些固定任務。這類權限適合用在較明確、自動化、與個別使用者無關的場景。
• 第二種是 使用者委派權限。也就是 Agent 代表使用者執行任務時，必須根據使用者本身的權限決定可以看到哪些資料、可以執行哪些操作。這類場景必須特別避免因為 Agent 介入而造成權限放大。

這也是為什麼 Agent 權限治理不能只看「這個 Agent 能不能呼叫某個 API」，而是要同時思考 Agent 身份、使用者身份、工具範圍與操作情境。

 

Agent Gateway 架構思維：當企業內部只有少數 Agent 時，點對點串接工具與服務似乎可行。但當 Agent、工具、MCP Server、API 與後端系統數量增加後，點對點整合會快速造成治理困難。GAIA 2.0 因此採用 Agent Gateway 的架構思維，將 Agent 存取工具與後端服務的過程集中到平台層管理。Gateway 的角色不是單純轉發流量，而是提供統一的權限檢查、路由管理、執行紀錄與治理控制點。

透過 Gateway，平台可以更清楚地掌握：

• 哪個 Agent 發起了呼叫
• 是否代表某個使用者執行
• 呼叫了哪個工具或服務
• 是否符合授權範圍
• 是否需要留下稽核紀錄
• 是否需要被限制、阻擋或人工審核

這樣的設計可以降低每個 Agent 團隊自行處理權限、安全與稽核的負擔，也能讓企業在 Agent 數量增加後，仍然保有集中治理能力。

 

Workspace、Marketplace 與 Gateway 的角色：在上述設計思維下，GAIA 2.0 以 Workspace、Marketplace 與 Gateway 作為平台架構上的三個核心概念。Workspace 主要用來承載不同團隊或不同專案的 Agent 開發與運行空間，提供基本的隔離、管理與治理邊界。Marketplace 主要用來管理企業內部可被重用的工具、MCP Server 或 Agent 能力，避免每個團隊都自行重複開發與點對點串接。Gateway 則作為 Agent 呼叫工具與服務時的治理中樞，負責集中處理權限、路由、紀錄與安全控管。這三個設計並不是單純的平台功能，而是對應到企業 Agent 落地時的三個核心問題：多團隊如何治理、工具能力如何重用，以及 Agent 行為如何被控管。

 

# 開發過程的挑戰與解方

• 挑戰一：Agent 上線流程容易分散在不同團隊

當不同團隊各自開發 Agent，如果沒有統一的上架、更版與下架流程，後續會很難追蹤每個 Agent 的狀態、責任歸屬與使用範圍。

GAIA 2.0 的設計方向，是將 Agent 納入標準化生命週期管理，讓 Agent 不只是被部署出去，而是能夠被申請、審核、使用、更新與下架。

 

• 挑戰二：Agent 權限邊界不容易定義

Agent 可能代表系統，也可能代表使用者；可能直接呼叫工具，也可能間接串接到後端系統。若沒有明確的權限模型，很容易產生越權存取或責任不清的問題。

GAIA 2.0 的設計方向，是區分 Agent 自身權限與使用者委派權限，並透過 Gateway 集中處理關鍵的權限判斷與存取紀錄。

 

• 挑戰三：工具與服務整合容易變成點對點災難

當 Agent 數量增加後，如果每個 Agent 都自行串接工具、API 或 MCP Server，會造成權限控管、版本維護與稽核追蹤上的困難。

GAIA 2.0 的設計方向，是透過 Marketplace 管理可重用工具能力，並透過 Gateway 統一治理 Agent 與工具之間的存取關係。

 

# 金融業 AI 專案落地關鍵

在金融業導入 AI Agent，真正的挑戰不是做出一個可以展示的 Agent，而是讓 Agent 可以在真實企業環境中被安全地上線、被正確地授權、被持續地監控，並且在異常或不再使用時能夠被停用與下架。

GAIA 2.0 的建置經驗顯示，企業在推動 Agent 應用時，不能只關注模型能力或單一 Agent 的效果，也必須及早思考 AgentOps 生命週期、權限治理、安全審核與平台責任邊界。尤其當 Agent 開始串接工具、API、資料庫與內部系統時，這些治理能力會直接影響 Agent 是否能真正從 PoC 走向 Production。

因此，本議程希望分享的不是一套已定型的產品功能，而是國泰銀行在設計企業級 Agent 管理平台過程中，如何思考 Agent 上線治理、權限控管與 Gateway 架構，並提供其他企業在導入 AI Agent 時可參考的設計觀點。

聽眾收穫：

在金融業導入 AI Agent，真正的挑戰不是做出一個可以展示的 Agent，而是讓 Agent 可以在真實企業環境中被安全地上線、被正確地授權、被持續地監控，並且在異常或不再使用時能夠被停用與下架。

GAIA 2.0 的建置經驗顯示，企業在推動 Agent 應用時，不能只關注模型能力或單一 Agent 的效果，也必須及早思考 AgentOps 生命週期、權限治理、安全審核與平台責任邊界。尤其當 Agent 開始串接工具、API、資料庫與內部系統時，這些治理能力會直接影響 Agent 是否能真正從 PoC 走向 Production。

因此，本議程希望分享的不是一套已定型的產品功能，而是國泰銀行在設計企業級 Agent 管理平台過程中，如何思考 Agent 上線治理、權限控管與 Gateway 架構，並提供其他企業在導入 AI Agent 時可參考的設計觀點。