AI Agent 要上線:先建知識庫、再談授權與成本

｜AI 落地應用教學

群環科技與 IBM 推出 AgentX,玉山金控則把 GENIE 升級為 Agent 統一入口。兩案都指向同一條路:先把知識整理好,再逐步放手給 AI,並同步管好成本、權限與紀錄。

本文重點

  • 群環建議先建智慧知識庫,再挑高頻、資料完整、效益可量化的流程
  • 玉山把法遵、徵信專家的判斷方式整理成 Skill,工程師與專家一起迭代
  • 第二年起 Token 成本要精算,稽核日誌與人工核准決定能否全面推廣

群環科技與 IBM 台灣在 2026 年 11 月 12 日發表「群環智行（BestCom AgentX）」。玉山金控也公開了自建 AI 平台 GENIE 3.0 的做法。兩個案例的共同點是：企業 AI 的重心，已從「讓員工會用」轉向「讓 AI 能放心交辦」。

重點整理

一、群環智行：先建知識庫，再讓 AI 動手

根據 iThome 刊出的廠商新聞稿，群環智行以 IBM 今年 4 月全球上市的 AI 代理人 IBM Bob 為核心，主軸是「From AI to Action」，也就是 AI 不只回答問題，還要把事情做完。IBM Bob 原本以工程師為主要使用者。群環預先設計好工作模式、使用規則、Skill（技能包）與 MCP（Model Context Protocol，讓 AI 連接外部工具的通用介面）串接，讓業務、行銷、財務人員第一天就能用對話上手。

這份新聞稿提到幾個值得企業參考的做法：

  • 起點是知識庫：群環總經理萬文凱建議，企業先把散落在各系統、Excel、Email 甚至資深員工腦中的產品資料、技術文件、SOP 與客服紀錄整合成智慧知識庫。接著挑「高頻重複、資料相對完整、效益可量化」的流程切入，再逐步擴大。
  • 兩種運作模式：互動對話模式下，AI 要刪檔案、執行系統指令或寄信前，一定先經使用者同意。流程確定後，可切換為自動化腳本模式，並強制留下完整日誌供事後稽核。
  • 地端部署：IBM 在 10 月 1 日推出自主部署方案，IBM Bob 可部署在企業機房、私有雲、主權雲或隔離網路，程式碼與資料留在企業內部。所謂地端部署，就是把模型與資料放在自己的環境中運作。
  • 成本壓力：IBM 台灣總經理李正屹舉例，一家 IC 設計公司第一年導入時老闆說「盡量用」，第二年就得精算每條產品線的 Token（模型計費單位）用量。他認為企業推廣卡住的原因是信任，包括權責不分、運作軌跡不清楚。

新聞稿也提到零售業舊系統重構的案例：沒有原始碼，只靠訪談紀錄等 4 份殘缺資料，由 1 位資深工程師在 IBM Bob 輔助下不到 1 個月完成，原本人工做法約需 7 個月。這些數字出自廠商與合作夥伴說法，企業評估時應自行驗證。

二、玉山 GENIE 3.0：把專家判斷變成 Skill

iThome 在 9 月 23 日的報導（時間稍早，但內容具參考價值）指出，玉山自建的生成式 AI 平台 GENIE 2024 年 1 月上線 1.0 版。2.0 版加入 RAG（檢索增強生成，先查資料再回答）、多模態與模型調度，用來查行內規章、公文與公告。使用數據方面，月均使用人數從 2024 年上半年的 800 多人，成長到 2026 年上半年的 3,600 多人，全行使用率超過三分之一。

3.0 版的目標是成為 Agent 統一入口，也就是玉山所說的 Agentic Banking（代理式銀行）。使用者提出需求後，系統判斷意圖，再透過 REST 或 MCP 分派給行內 Agent、知識庫或其他系統。底層補上權限管理、個資防護、模型監控、Policy Engine、稽核日誌與 FinOps（雲端成本管理）。

玉山認為最難的是隱性知識。專家往往要等 AI 實際執行、被指出錯誤，才會補上規則。因此做法是讓懂 AI 的人與懂業務的人一起反覆測試，再整理成 Skill。報導提到，一名工程師搭配一名法律專家，約一週就做出法遵 Agent 的初步版本，功能尚不完整。徵信報告也是由 AI 先產生初稿，再由專業人員檢查判斷。

三、補充：用指標衡量 Agent

Google Cloud 在今年 2 月的部落格提出，Agent 可從可靠性、採用情形與業務價值三類指標衡量。例如 plan adherence（是否依計畫順序呼叫工具）與 acceptance rate（使用者不大改就接受輸出的比例）。建議先用可靠性指標建立信任，再談 ROI。這篇發布時間較早，僅作為方法參考。

分析

第一，知識整理比模型選擇更早、也更費工。 群環與玉山不約而同從知識出發。RAG 與 Agent 的品質，取決於文件是否完整、版本是否清楚、權限是否分明。台灣企業常見的問題是資料分散在檔案伺服器與個人信箱，這步沒做好，後面只會放大錯誤。

第二，從「個人生產力」進入「流程責任」。 李正屹描述的三階段是：先問有沒有用，再問有沒有效果，最後才發現推不動。當 AI 要接手整段流程，就必須回答誰核准、誰負責、出事時能不能追溯。互動模式與腳本模式分開，是一個務實的設計：流程還沒穩定時要人核准，穩定後才自動化並留下日誌。

第三，成本會從實驗費變成營運費。 IC 設計公司的例子提醒我們，Token 用量遲早要分攤到產品或部門。選擇雲端、地端或混合，不能只看模型能力，也要看用量與資料敏感度。

第四，專家的參與是瓶頸。 玉山強調，要請專家交出多年經驗，得先讓他們相信 AI 是幫忙而不是取代，並給他們新的角色（測試、監督 AI）。對公部門而言，這也適用於業務單位與資訊單位的分工：承辦人要能參與驗收，而不只是提需求。

以上是整理公開報導後的判讀。群環新聞稿屬廠商稿，成效數字需審慎看待。

給企業的建議

  1. 先盤點知識，再選工具。 列出最常被問、文件相對完整的 3 到 5 類問題（如規章、產品手冊、客服 FAQ），先建立 RAG 知識庫，並要求每個答案附上來源。
  2. 找不到答案時要敢說不知道。 上線前準備一組可逐字查核的題目，包含「文件裡沒有答案」的負向題，檢查系統是否會亂編。
  3. 分階段放權。 初期所有寫入、寄信、刪除動作都需人工核准；流程穩定、紀錄完整後，才對低風險任務啟用自動執行。
  4. 一開始就設計稽核日誌與權限。 每位使用者只能查到自己有權限的資料，並能還原一次 Agent 動作用了哪些資料、依據哪條規則。
  5. 編列 Token 預算與指標。 按部門或流程追蹤用量，並同步看接受率、重做率與人工複核時間，避免只看「用了多少次」。
  6. 讓專家與工程師坐在一起。 以一個明確場景組成小團隊，邊用邊修，再把經驗整理成可重用的規則。

源智匯在知識中樞 Phoebe 與 Yuan A.I. 平台的實務中，也常見相同順序：像農業部跨單位知識庫整合、國立臺灣海洋大學圖書館 AI 查詢助理，都是先把資料與使用情境定義清楚，才擴大應用範圍。若貴單位正在評估 RAG 或 Agent 導入，建議先從一個高頻、可量化的場景開始。

名詞解釋

RAG
檢索增強生成。AI 回答前先從企業文件中找出相關內容，再據以作答，通常可附上來源，降低亂編答案的機會。
MCP
Model Context Protocol，一種讓 AI 連接外部工具與系統的通用介面，可讓不同服務以一致方式被 Agent 調用。
Skill
把某項專業工作的做法、規則與步驟整理成 AI 可重複調用的能力，例如「依法規檢查文件」。
Token
大型語言模型處理文字與計費的基本單位，用量越多，費用通常越高。
IBM Bob
IBM 推出的 AI 代理人，可參與軟體開發的規劃、編碼、測試、部署與維運，也可部署在企業自有環境。
地端部署
把 AI 模型與資料放在企業自己的機房或私有環境運作，而非全部交給外部雲端。
Agentic Banking
代理式銀行。指使用者說明要完成的任務，系統理解後交由對應的 AI Agent 執行，人類負責監督與處理例外。
稽核日誌
完整記錄 AI 做了哪些操作、用了哪些資料的紀錄，方便事後追查與稽核。

常見問題

企業導入 AI Agent 應該從哪裡開始?

群環的建議是先建立智慧知識庫，再挑高頻重複、資料相對完整、效益可量化的流程切入，之後逐步擴大。

地端部署一定比雲端好嗎?

不一定。地端可讓資料與程式碼留在企業內部，適合智慧財產權與資安要求高的情境，但仍要評估硬體、維運與成本，混合架構也是選項。

怎麼避免 AI Agent 做出不該做的事?

初期讓高風險動作都經人工核准，並留下完整日誌；流程穩定後才對低風險任務自動執行，同時管控權限範圍。

參考來源