[下篇] 把 AI 助理搬進自己機房的時代來臨：UbiGPT × UbiCode × UbiWork On-Premise 企業 AI 協作解決方案

撰文：AI 創新與資安研發總監 吳英豪 (Isaac Wu)、編輯：行銷副理 呂宜家（Helen Lyu）

前言：從「為什麼自架」走向「如何落地」

在上篇文章中，我們談到，當開放權重模型的能力逐漸跨過「可交付」門檻，企業導入 AI 的核心問題，已經不再只是模型夠不夠強，而是資料是否能留在自己的邊界內、推論成本是否可預測，以及 AI 是否能真正進入日常工作流程。

對企業而言，On-Premise AI 的價值不只是「把模型放進自己的機房」，而是讓合約、銷售數據、專案原始碼、內部文件與基礎架構資訊，都能在不離開公司網段的前提下，被 AI 安全地讀取、分析與執行。當資料主權、成本曲線與使用信任重新回到企業手上，AI 才有機會從單次問答工具，進一步成為可被治理、可被擴充、也能持續優化的內部基礎設施。

但真正的挑戰是：企業要如何把這件事落地？

一套可用於正式環境的 On-Premise AI 系統，不能只是把一個模型服務起來，也不能只是發一把共用 API Key 給團隊使用。它需要同時處理模型推論、身分認證、金鑰治理、Agent 執行環境、跨部門協作介面、使用紀錄、成本歸屬與資安稽核。

因此，下篇將從解決方案架構切入，拆解 Ubitus 如何透過 UbiGPT、UbiCode 與 UbiWork 三層平台，將 On-Premise AI 從概念轉化為企業可實際部署的協作系統。

四、解決方案架構：三層拆解

三層之間只以標準協定溝通：UbiCode 與 UbiWork 一律透過 OpenAI 相容 API 存取 UbiGPT。這個設計帶來兩個效益：底層模型可以隨時抽換（今天跑 A 模型，下一季換成能力更強的 B 模型，前端使用者完全無感），以及同一個端點後面可以同時掛多個分級的模型，讓上層依任務性質挑選最適合的那一個——這正是下一節角色化 Agent 得以成立的基礎。

五、推論層：UbiGPT

多數團隊在自架 LLM 時，第一版都是「把模型服務起來，發一把共用 API Key 給大家」。這在 PoC 階段可行，但一進入正式環境就會立刻遇到三個問題：分不清誰在用、擋不住離職者的殘留金鑰、算不出各團隊的成本歸屬。

UbiGPT 把「模型服務」與「企業身分治理」合併成同一層，這正是它與單純起一個推論容器的差別。

5.1 模型服務

• OpenAI 相容端點——上層工具零改動即可接入，既有生態系（SDK、CI script、第三方外掛）全部可用。
• 多模型路由——同一個 endpoint 後面可掛多個分級的模型（輕量高速 / 標準 / 高階推理 / 多模態），依團隊、專案、或 Agent 角色路由。高機密專案強制走內網模型，特定非機密專案可放行至外部供應商，策略集中管理。這是第六章「角色配適合模型」能夠落地的前提。
• 長上下文支援——Agentic coding 對上下文長度的需求遠高於一般問答，128K 是實務起跳點。
• 前綴快取（prefix caching）——Agent 每一輪都會帶上幾乎相同的 system prompt 與專案上下文，快取命中率極高。這是自架環境中 CP 值最高的一項優化，對吞吐量的影響可達數倍。

5.2 企業認證：開箱即用，接得上你現有的目錄

UbiGPT 的認證層以主流 IdP 標準為基礎設計，不要求企業為了導入 AI 而改動既有的身分架構：

實務上最關鍵的是AD 同步：使用者的部門、群組、在職狀態直接來自公司既有的 AD，離職帳號停用的當下，其所有 API Key 同步失效。這解決了自架 AI 服務最常見的資安破口——散落在各人 .env 裡、永不過期的共用金鑰。

5.3 API Key 發放與用量治理

• 金鑰生命週期管理——依使用者或服務帳號發放，可設定有效期限、綁定專案、隨時撤銷。
• 用量統計與成本歸屬——記錄每一次呼叫的使用者、模型、token 數與時間戳，可依部門、專案、個人出報表。即使是自架的固定成本，內部分攤與 ROI 佐證仍然需要這份數據。
• 配額與速率限制——避免單一失控的自動化任務吃光整個叢集的吞吐量。
• 稽核日誌——集中式的呼叫紀錄，同時滿足資安稽核與成本分析兩種需求。

5.4 對話紀錄保存：把使用歷程變成企業資產

UbiGPT 提供可選擇性開啟的對話紀錄保存。這個功能表面上是稽核用途，但它真正的價值在別的地方。

人類給 AI 的糾正與回饋，是微調模型最好的資料——沒有之一。

公開語料能教會模型通用知識，卻教不會「我們公司是怎麼做事的」。而每一次工程師打斷 AI 說「不對，這裡要用我們內部的元件，不是開源那套」、每一次法務同仁把 AI 的條款建議改掉並寫下理由、每一次資深架構師否決一個看似合理的設計——這些都是由領域專家在真實工作情境下產生的高品質標註資料。

它的特殊性在於：

• 它是成對的——每一次糾正天然形成「不夠好的答案 → 更好的答案」這組對照，這正是偏好微調最需要的資料結構。
• 它帶有理由——人類糾正時通常會說明為什麼，這比單純的對錯標籤有價值得多。
• 它買不到——你可以買到通用的程式資料集，但沒有任何地方買得到「貴公司內部框架的正確用法」或「貴公司對某類合約條款的標準立場」。
• 它會自己產生——不需要額外編列標註預算，它是團隊日常工作的副產品。

保存下來的紀錄有三種用法：

1. 微調領域特化模型——訓練出真正理解公司內部框架、程式風格、業務術語與決策慣例的專屬模型。這對「內部自研工具鏈」特別有價值：外部模型再強，也沒讀過你們的內部系統。
2. 建立內部評測集——把過去被糾正過的案例整理成回歸測試題庫。下次要換模型時，先跑這一套，用真實踩過的坑來驗證，遠比公開榜單可靠。
3. 萃取為規則與提示資產——不是所有改善都需要重新訓練。高頻出現的糾正可以直接寫進專案規則檔或角色提示，成本低、見效快。

在程式領域，這份資料還有第二個來源：git 歷史本身。UbiCode 會在 commit metadata 中標記產出來源（見 6.6 節），因此「AI 生成後又被人類改掉」的那些變更可以被自動撈出來——這是不需要任何額外標註工作的現成訓練訊號。

這形成一個飛輪：用得越多 → 累積的糾正越多 → 模型越懂這家公司 → 越好用 → 用得更多。 而競爭對手就算用同一個開源模型起步，也複製不了你們累積下來的這一份資料。

這件事只有自架環境做得到。 用第三方 API，你既拿不回完整的互動紀錄，更不可能把資料拿去訓練一個屬於自己的模型——資料流的方向是反的，你的回饋是在幫別人的模型變強。在自架環境中，紀錄本來就存在你的資料庫裡，訓練也跑在你自己的 GPU 上，整條資料鏈從產生、儲存到訓練，全程沒有離開過公司。

當然，這個功能必須配套治理措施：預設為關閉、以團隊或專案為單位選擇性啟用、明確告知使用者、自動過濾憑證等敏感內容、設定保存期限，並在納入訓練前完成去識別化。詳見第九章。

六、Agent 層：UbiCode

6.1 從「一個全能助理」到「一支分工的 AI 團隊」

早期的 coding agent 大多只做一件事：一個模型、一個角色、從頭做到尾。進階一點的會區分「規劃」與「執行」兩種模式。但真實的開發工作不是二分法——「在三千個檔案裡找出所有呼叫這個 API 的地方」和「判斷這個架構該不該拆」是完全不同性質的任務，卻被丟給同一個模型處理。

這造成兩邊都不划算：用高階推理模型去做大範圍檔案掃描，是拿最貴的算力做最機械的事；用輕量模型去做架構決策，則會得到看似合理但經不起推敲的答案。

UbiCode 採用角色化的 Agent 團隊：每個角色有明確職責、專屬的系統提示、可用的工具範圍，以及各自適配的模型分級。由總調度角色拆解任務、指派給合適的專家並行處理，最後彙整結果。

6.2 角色編制

這張表最重要的一欄是「用量特性」。探勘者的 token 消耗通常佔整體的大宗，但它的任務其實只需要輕量模型；架構顧問單次成本最高，但一天可能只被呼叫幾次。 把每個角色配到剛好夠用的模型分級，比起「全部都用最強模型」，總體成本可以差上數倍，而產出品質幾乎不受影響——在某些情境甚至更好，因為專用提示比通用提示更精準。

這正是 UbiGPT 多模型路由存在的意義：同一個內網端點後面掛著不同分級的模型，UbiCode 依角色自動選擇。輕量模型可部署在成本較低的推論資源池、高階模型集中在少數高規節點，整體 GPU 使用效率大幅提升。

6.3 調度與協作方式

• 背景平行執行——調度者採「先排程」的工作模式，把多個專家角色派成背景任務同時進行，追蹤各自進度，收斂後再繼續下一階段。這讓「探勘 + 查文件 + 讀既有測試」這類本來就無相依性的工作真正平行化。
• 手動指派——使用者可直接呼叫特定角色（例如 @oracle 這段鎖的設計有沒有 race condition），跳過調度流程，把最強的推理能力用在刀口上。
• 多模型會審——關鍵決策點可觸發會審模式，讓數個模型各自回答同一個問題，再由系統綜合出共識與分歧點。在自架環境下這特別划算：邊際成本低，就敢於在重要決策上多花幾次推論。
• 結構化長流程——針對大型變更提供多階段的作業流程（盤點 → 規劃 → 驗證路徑設計 → 實作 → 收斂），而不是讓 Agent 一路寫到底。
• 可切換的模型組合（Preset）——同一套角色編制可綁定不同的模型組合，執行時一鍵切換。日常開發用經濟組合，關鍵版本用高規組合；模型升級時只需更新 preset，使用者端零改動。

6.4 能力與權限：以角色為單位控管

角色化的另一個效益是權限可以切得更細。UbiCode 的技能（Skill）與 MCP 工具都是以角色為單位授權的：

• 技能與 MCP 存取採白名單制，可用萬用授權（*）或明確否決（!skill-name）逐項調整。
• 探勘者與知識檢索角色天生就沒有寫入檔案的能力——這不是靠提示詞約束，而是工具層面就沒開放。
• 只有實作者與調度者能觸發變更；破壞性指令一律走人工核可。
• 資料庫查詢類的 MCP 可以只開給架構顧問，不開給高頻執行的角色。

比起「一個全能 Agent 加上一串禁止事項」，用角色天然的職責邊界來限制能力，是更可靠的安全模型。

6.5 執行環境：輕量 VM 沙箱，讓「放手」成為可行選項

角色權限解決了「Agent 能用哪些工具」，但還有另一個層次的問題：Agent 執行的指令，是跑在誰的機器上、能碰到哪些檔案？

UbiCode 的客戶端以 Docker image 形式交付，預設環境在 Windows、macOS 與 Linux 上完全一致；Agent 的實際執行則發生在一個輕量 VM 中，而不是直接跑在使用者的主機上。

只開放必要的檔案與權限：

• 僅掛載當前任務所需的專案目錄，其餘檔案系統對 Agent 不存在——它看不到你的家目錄、SSH 金鑰、瀏覽器設定或其他專案。
• 網路存取採白名單制，預設封鎖對外連線，僅開放內部套件 mirror 與 UbiGPT 端點。
• 系統層級的操作被限制在 VM 內部，宿主機不受影響。

這帶來四個實質效益：

1. 爆炸半徑被限縮——不論是模型判斷失誤、指令參數寫錯，或是讀到惡意內容而觸發的 prompt injection，能造成的最大損害就是弄壞一個隨時可以丟掉重建的 VM。
2. 環境完全一致——「在我機器上可以跑」這個經典問題消失了。工程師本機、同事的機器、CI runner 全部使用同一個 image，Agent 產出的結果具備可重現性。
3. 新人一天上手——不需要照著文件裝三小時的開發環境，拉一個 image 就有完整可用的工作環境。
4. 真正敢放手——這一點最關鍵。

第 4 點值得展開。Agent 的效率來自於連續執行：讀檔、改檔、跑測試、看結果、再修正，一氣呵成。但如果每一個 shell 指令都要人工按一次「同意」，這個流程就退化成一個很慢的問答機器人——工程師花在核可上的注意力，可能比自己動手做還多。

於是團隊會陷入兩難：全面開放怕出事，全面管制又失去意義。

沙箱化把這題解開了。當執行環境本身就是隔離且可拋棄的，「讓 Agent 自動連續執行」就從一個需要勇氣的決定，變成一個合理的預設值。使用者可以放手交辦任務，去做別的事，回來看結果——無後顧之憂。

這與 6.4 節的角色權限構成兩層防護，各管一件事：

單獨任一層都不夠：只有角色權限，一個被誘導的實作者角色仍可能傷及宿主機；只有沙箱，Agent 在專案目錄裡照樣能做出不該做的事。兩層疊加，才撐得起「放手讓它跑」這件事。

6.6 來源可追溯：用 git metadata 標記人類與 AI 的產出

當 AI 開始大量產出程式碼，一個新問題浮現：半年後回頭看，你分得出哪幾行是人寫的、哪幾行是 AI 寫的嗎？

多數團隊的答案是分不出來。而這件事會在三個時間點變成麻煩：稽核時、出事時、以及要評估「AI 到底做得好不好」時。

UbiCode 把來源資訊寫進 git metadata—利用 commit trailer 與 git notes 記錄每一次變更的產生來源，並附上必要的脈絡：

• 由誰產生—人工撰寫、AI 生成，或是 AI 生成後經人工修改（第三種其實最常見）。
• 哪個角色與模型——是實作者還是架構顧問的產出、使用哪個模型與版本。
• 經過哪些審查——是否通過自動 review、由誰核可合併。

關鍵在於這些資訊寫在 metadata 層，不污染 commit message、不改變 diff 內容、不影響既有的 git blame 與 code review 工作流。既有的工具鏈完全不需要調整，資訊就這樣安靜地累積下來。

為什麼值得做

1. 合規與交付聲明——越來越多客戶合約與標案開始要求揭露 AI 生成內容的範圍，甚至明文限制 AI 產出不得進入特定交付物。有了逐 commit 的來源標記，這件事是一句 git log 查詢；沒有的話，就是一場考古。
2. 事故調查有跡可循——線上出問題時，能立刻回答「這段程式是哪個模型、哪個版本、在什麼情境下產生的，當時有沒有經過人工審查」。這決定了你要修的是一行程式，還是一個會持續複製同樣錯誤的流程。
3. 用數據決定信任邊界——可以統計 AI 產出的 revert 率、被 review 要求修改的比例、對應模組後續的缺陷密度，再依據數據決定哪些類型的任務可以放手、哪些仍需嚴格把關。這比靠團隊直覺爭論「AI 到底可不可信」有建設性得多。
4. 智慧財產風險界定——萬一發生授權爭議，能明確界定受影響的範圍，而不是整個 repo 都陷入不確定。
5. 回頭餵養模型——這一點與 5.4 節相互呼應：「AI 生成後又被人工修改」的那些 commit，其 diff 本身就是一組現成的訓練訊號——左邊是模型的產出，右邊是專家認為正確的版本，中間還有 commit message 說明理由。不需要額外標註，git 歷史自己就是資料集。

第 5 點值得特別留意。前面談過人類的糾正是最好的微調資料，而 git metadata 讓這些糾正可以被自動辨識出來——系統知道哪些 diff 是「人類在修正 AI」，哪些只是一般的迭代開發。沒有來源標記，這批最有價值的資料就混在數十萬筆 commit 裡，撈不出來。

6.7 共通能力

無論透過哪種介面，UbiCode 的基礎能力一致：

• LSP 深度整合——透過 Language Server 取得真實的型別資訊與符號定義，而不是只做文字比對。在大型專案中，這對修改正確率的影響非常顯著。
• MCP 擴充——把內部系統（issue tracker、GitLab、內部 API 文件、資料庫唯讀查詢）以標準協定掛上，讓 Agent 在不離開內網的前提下取得企業上下文。
• 專案規則檔——把團隊的架構慣例、命名規則、禁用套件、測試指令寫進 repo 內的規則檔並納入版控，等同於「團隊工程規範的可執行版本」，讓每位工程師的 Agent 行為一致。
• Git worktree 隔離——長時間或高風險的任務可在獨立的工作樹中進行，不干擾當前分支。
• Headless 模式與 SDK——可在無互動介面的環境下執行，直接嵌入 CI pipeline：PR 開啟時自動 review、nightly 自動補測試、CI 失敗時自動嘗試修正。

6.8 TUI：工程師的本機戰場

終端機介面，跑在工程師自己的機器上，與既有的 shell、git、編輯器工作流無縫銜接。

• 角色以 @角色名 直接呼叫，或交由調度者自動分派；背景任務的進度在同一畫面追蹤。
• 一鍵切換模型組合，即時調整成本與品質的權衡。
• 與 shell 及 git 零距離，可腳本化、可進 CI runner。
• 適合分鐘級的互動式迭代：寫功能、debug、跑測試、pre-commit 檢查。

6.9 WebUI 與原生 App：團隊的協作與審查場

瀏覽器介面與桌面／行動原生 App，處理的是 TUI 天生做不好的事——跨裝置延續、長時間任務、以及團隊層級的審查。

• 持續性任務目標（Session Goals）——設定目標後 Agent 持續推進，關掉視窗、換一台裝置都不中斷。適合大型遷移、框架升版、跨模組重構這類需要數小時到數天的任務。
• 多方案平行探索——與會審機制不同，這裡是讓數個模型針對同一需求各自完成一整套實作，在獨立的 session 或 git worktree 中同時進行，最後把各版本最好的部分融合成新的 session。在自架環境下這個玩法特別划算：邊際成本低，就可以放膽地「多跑幾個方案再挑最好的」——這在 token 計價模式下是不敢做的事。
• 角色產出的視覺化追蹤——各角色的背景任務狀態、彼此的相依關係與階段產出在同一畫面呈現，Tech Lead 不需要進到終端機就能掌握整支 AI 團隊在做什麼。
• 變更導覽（Changes Walkthrough）——把大型 diff 轉成 AI 導覽，依邏輯分組並解釋各處修改之間的相互關係。這正面解決了 AI 輔助開發最大的瓶頸：產出速度遠快於人類審查速度。
• 即時預覽——在對話旁直接顯示執行中的應用程式，可對照畫面元素檢視對應的程式碼修改。
• 版控平台整合——從 issue 或 PR 帶著完整上下文直接開啟工作階段；把失敗的 CI 檢查與 review comment 送回給 Agent；在介面上直接更新或合併 PR。
• 跨裝置存取——桌面（Windows / macOS / Linux）、瀏覽器 / PWA、IDE 擴充、iOS 與 Android，工作階段在裝置間延續。
• 多種連線方式，由資安政策決定——這是 on-premise 部署最需要留意的一個設定點：

最後一項提供了最大的便利性——不需要開防火牆連接埠、不需要固定 IP，掃個 QR code 就能從手機接上內網的工作階段。但它同時意味著流量會經過第三方的邊緣節點。雖然連線本身是加密的，但這條路徑是否符合貴司的資安政策，必須由資安團隊實際評估後決定，不應由開發團隊自行開啟。

務實建議：預設關閉隧道功能，以 LAN / VPN 為標準連線方式；若確有跨網存取需求，再依專案機密等級逐案核准，並將啟用狀態納入定期稽核項目。這個功能的存在不是問題，「誰在什麼情況下可以開啟」沒有明確規範才是。

• 排程工作——以 cron 或每日／每週間隔安排重複性任務。
• 工作追蹤與成本可視化——session 依資料夾組織，附帶筆記、待辦與可重複使用的專案動作；核可請求、token 用量與成本一目了然。

6.10 兩種介面怎麼選

實務建議：兩者同時部署，共用同一組帳號與 session。工程師在自己機器上用 TUI 做日常開發，Tech Lead 在 WebUI 上檢視全團隊的 Agent 產出與成本，出差時用手機 App 確認長時間任務的進度。

七、協作層：UbiWork——給不寫程式的人的 AI 同事

談 AI 導入時，話題幾乎總是繞著工程師轉。但把視線移開研發部門會發現一件事：公司裡最多的重複性文書工作，其實不在研發。

法務每週要看幾份格式相近的合約、業務每月要把同樣的報表重整成不同視角、財務要在多份試算表之間對數字、HR 要處理成疊的履歷與制式公告、PM 要把會議逐字稿變成規格與週報。這些工作有三個共同點：高度重複、有明確格式、而且極度耗時。

它們也是最沒有被工具照顧到的一群。工程師有 IDE、有 CLI、有各種 agent；而這些同仁手上只有 Office 和一個聊天視窗——能貼進去的東西有限，貼進去也不能貼機密的。

UbiWork 面向的就是這群人。它的設計前提是：使用者不需要有工程背景、不需要學 prompt 技巧、不需要知道背後跑的是哪個模型。

7.1 設計上的三個關鍵決定

一、產出是檔案，不是聊天訊息。

這是 UbiWork 與一般 AI 助理最大的差別，也是決定「會不會真的被用起來」的關鍵。AI 在對話框裡列出十條建議，看起來很有用，但使用者接下來要做的事是：打開 Word、逐條把建議搬進去、調整格式、加上批註——這段搬運工作往往比思考本身更花時間。

UbiWork 直接產出可交付的檔案：帶追蹤修訂與批註的 Word、格式與圖表完整的 Excel、含轉場動畫的簡報。確認完就能寄出，中間沒有搬運。

二、把檔案丟進去，用中文交辦。

不需要先建 pipeline、不需要匯進 BI 系統、不需要寫公式。拖進一份合約、一疊報表、一份逐字稿，然後用日常語言說明要什麼。對非技術使用者而言，「能不能上手」通常不是意願問題，而是第一步的門檻高不高。

三、內建角色，而不是要求使用者自己寫提示。

系統內建多種專業角色範本（合約審閱、簡報製作、報表分析、文件撰寫等），使用者選一個角色就能開始，不必研究怎麼把需求寫成有效的提示詞。

7.2 能力

• 多 Agent 協同（Team Mode）——多個 AI 角色分工協作、平行執行，而非單一助理循序處理。例如一份提案：一個角色整理數據、一個角色寫文案、一個角色排版成簡報。
• Office 文件產出——簡報（含轉場動畫）、Word 文件、Excel 試算表（含自動格式化與圖表），並內建多種專業角色範本。
• 檔案與資料處理——批次改名、自動歸檔、智慧分類、檔案合併，以及 Excel 資料分析與報表生成。
• 24/7 排程自動化——每週報表、每月對帳彙整、定期資料健檢，設定一次後持續執行，主管一早就收到最新摘要。
• 多格式預覽與多分頁——PDF、Word、Excel、簡報、Markdown、圖片、HTML、Diff 皆可在同一介面預覽，多分頁同時開啟比對。這對「一邊看舊版合約一邊看新版」這類工作特別實用。
• 遠端存取——WebUI 可部署於內網伺服器供全公司共用；若企業已有內部通訊平台，可評估接入以支援行動端指派任務。採嚴格 on-premise 政策時，任何對外的通訊通道都應納入資安評估後再決定是否開啟。
• 資料本地留存——所有工作階段與檔案存放於本地端，不上傳至外部伺服器。

7.3 導入非研發部門的三個提醒

比起研發團隊，非技術部門的導入更容易在「人」的環節卡住。我們自己的經驗是：

1. 從有標準格式的重複性工作開始——合約初審、月報彙整、報表分析這類任務，對錯有明確標準，使用者很快就能判斷 AI 做得好不好，信任建立得快。反過來，如果第一個場景是創意發想或對外文案，評價主觀、爭議多，容易在初期就失去支持。
2. 人工確認關卡不能省——AI 是初審，不是決策者。合約條款、財務數字、對外文件，一律要有具名的人簽核。這一條在研發以外的部門更重要，因為這些產出往往直接對外，而且對外之後改不回來。
3. 產出格式決定採用率——這一點值得重複：能直接寄出的檔案才會被持續使用，一份需要人工再搬一次的建議清單不會。導入時請先問「產出能不能直接用」，而不是「AI 講得對不對」。

第三章的合約初審與銷售數據分析，就是 UbiWork 在我們內部的實際用法——使用者是法務與業務同仁，兩個場景都沒有工程師參與。這正是這一層存在的意義：AI 的效益不該只留在研發部門。

八、落地對照：從部門日常到 SDLC

8.1 非研發部門的日常工作

這張表的共同點是：每一項的產出都是一份檔案，而不是一段對話。這也是為什麼第七章把「產出可交付的檔案」列為設計上的第一個關鍵決定。

8.2 研發：SDLC 各階段

其中「測試」與「Code Review」兩列，就是第三章提到的 Ubitus 內部實作——commit 觸發、自動補測試、自動初步審查，全部跑在 CI 上，工程師不需要多按任何一個按鈕。導入時最重要的一件事：不要一次全上。兩張表都從同一類場景起步最穩——唯讀的分析，以及有標準格式的文件產出。這兩類風險低、成效看得見，等團隊建立信任之後，再逐步放開寫入與自動執行的權限。

九、治理：自架不等於自動安全

把模型搬進機房解決了「資料外流」，但沒有解決「內部濫用」與「產出失控」。而且隨著使用者從研發擴散到法務、業務、財務，治理的重點也會跟著移動——工程師處理的是自家的程式碼，法務與業務處理的卻是客戶的資料，適用的是對方合約裡的條款。

以下機制必須同步建立：

• 資料分級與可用範圍——先定義清楚哪些類別的資料可以交給 AI、哪些必須先去識別化、哪些完全禁止。這件事要在導入前做，而不是出事後補。特別注意含個資與客戶識別資訊的檔案：即使全程在內網，仍受個資法與客戶合約的約束，「沒有外流」不等於「可以任意使用」。
• 權限最小化，並以角色為單位——用 UbiCode 的角色權限政策，讓探勘、檢索類角色在工具層面就沒有寫入能力，只有實作與調度角色能觸發變更。破壞性指令、production 憑證、對外網路請求一律預設封鎖，高風險操作走人工核可。用職責邊界限制能力，比用提示詞叮嚀可靠得多。
• 身分與金鑰集中管理——所有推論流量都必須帶著可追溯到「人」的憑證，由 UbiGPT 統一發放與撤銷。禁止任何形式的共用長期金鑰。
• Secrets 隔離——Agent 的工作目錄不應包含真實憑證；用 secret manager 注入，並確保敏感檔案在忽略清單中。
• 執行環境沙箱化——Agent 一律在輕量 VM 中執行，只掛載當前任務所需的目錄。這讓「授權失誤」的後果從資安事故降級為重建一個容器（見 6.5 節）。
• Egress 預設封鎖——Agent 執行環境的對外網路預設關閉，需要的外部資源（套件庫、文件）走內部 mirror 或白名單 proxy。這一條同時擋掉了 prompt injection 導致的資料外傳路徑。
• 遠端存取通道明文規範——UbiCode 的隧道連線、UbiWork 的外部通訊接入這類「方便但會走出內網」的功能，必須有明確的開啟條件與核准流程，並納入定期稽核。預設值一律為關閉。
• 對話紀錄的知情與淨化——若啟用第 5.4 節的紀錄保存，必須做到：明確告知使用者哪些專案在保存、保存多久；自動偵測並剔除憑證、個資與客戶識別資訊；納入訓練語料前完成去識別化與人工抽樣檢查。能拿自己的資料訓練模型是一項優勢，但前提是這份資料本身是乾淨的。
• 稽核日誌集中——「誰、什麼時候、用哪個模型、跑了什麼任務、消耗多少 token」全部落地留存，同時服務資安稽核與成本分析。
• 產出來源全程留痕——程式碼在 git metadata 中標記人類或 AI 產出（見 6.6 節）；文件類產出則在檔案屬性或內部版本紀錄中留下同樣的標記。這是「AI 大量產出內容」與「這些內容仍然可被治理」之間的那條線。
• 對外產出必須經人工簽核——AI 生成的合約修訂、客戶提案、對外公告、財務數字，在送出前一律要有具名的人確認。研發的 merge 還能 revert，寄出去的檔案收不回來，這一關的價值比程式碼那一關更高。
• 人類仍是最後一關——不論是 merge、寄出，還是對外發布。Agent 可以開 PR、可以生成文件，但拍板的必須是人。變更導覽、風險標記這類工具是幫助人審得更快，不是取代審查。

十、導入路線圖

第 1 階段：PoC（2–4 週）

單一 GPU 節點部署 UbiGPT，接上公司 AD 完成 SSO，3–5 位資深工程師拉取 UbiCode 的 Docker image 後即可接入——客戶端不需要為了 PoC 而改動任何人的本機環境，這也讓「試完不滿意就整包移除」變得毫無成本。目標不是驗證「AI 有沒有用」，而是量測模型在你自己的 codebase 上的實際表現與吞吐上限。同步建立 baseline：現行方案的實際月支出與 token 用量。

第 2 階段：試點（1–2 個月）

擴充到單一團隊（10–20 人）。部署 UbiCode WebUI 做 session 管理與 code review，撰寫第一版專案規則檔，啟用 UbiGPT 的部門用量統計。此階段的重點工作是調校角色與模型的配對：依實際用量數據，找出哪些角色可以降級到更輕量的模型、哪些值得升級，把模型組合固化成適合貴司的預設值。此階段也開始能看出真實的損益兩平點。

第 3 階段：擴散

依壓測結果擴充推論節點，導入 UbiWork 服務非工程角色，把排程任務（每日 log 分析、週報、CI 失敗自動修正）常態化。此時 SLA、監控、模型升級流程都需要正式化。

硬體概念性參考：以目前主流的開源權重程式模型（含 MoE 架構）而言，一台 8 GPU 節點在啟用前綴快取的前提下，通常足以支撐數十名工程師的日常 agentic 流量。但併發吞吐高度依賴模型大小、上下文長度與任務型態，務必以自身工作負載實測為準，不要直接套用他人數字。

十一、常見疑慮

Q：自架模型的能力跟得上嗎？

這是最常見的一題，也是變化最快的一題。在「大範圍架構重構」這類最困難的任務上，頂尖商用模型目前仍有優勢——但差距正在縮小，而且縮小的方向是單向的。至於絕大多數的日常工作：讀懂既有程式、補測試、跨檔案改名、依 CI 錯誤修正、通讀合約、分析報表——現在的開放權重模型已經穩定勝任。

角色化架構讓這題有更精細的解法：能力落差集中在「架構顧問」這一個角色上，其餘角色用內網模型完全足夠。務實作法是混合部署——預設全走內網，僅將高階推理角色在指定的非機密專案上放行至外部供應商，由 UbiGPT 的路由策略集中控管，而不是讓每位工程師自己決定。

順帶一提，這一題也是最值得每半年重問一次的。以開放權重模型近兩年的推進速度，今天需要放行外部供應商的那一小塊，明年很可能就不需要了——而屆時你會慶幸架構早就準備好，只需要改一行路由設定。

Q：維運成本會不會吃掉節省的錢？

會佔掉一部分，所以試算時必須把 MLOps 人力、機房、電力都算進去（上表已納入）。這也是為什麼小團隊不該硬上 on-premise。損益兩平點大致落在「用量穩定且持續成長」的規模。

Q：模型更新怎麼辦？

這正是「上層只認標準協定」的價值。新模型出來，在 staging 節點跑過你的回歸測試集，通過後更新對應角色的模型組合設定即可，使用者端零改動。而且角色化讓升級可以逐一驗證——先只換探勘者的模型觀察一週，再決定要不要換實作者，風險遠低於整包切換。建議維護一套內部的程式任務評測集，這比任何公開榜單都更能反映你的實際需求。

Q：一定要三層都導入嗎？

不一定，但建議至少從 UbiGPT 開始。認證、金鑰與用量治理是所有後續應用的共同基礎；先把這層做對，之後不論加掛什麼 AI 應用，都能沿用同一套身分與稽核機制，而不是每上一個工具就多一組失控的 API Key。

結語

回到開頭那條線：當開放權重模型的能力從實習生一路走到碩博士級的全職員工，「自架等於將就」這個前提就不成立了。而一旦不必在能力上妥協，剩下的問題就只剩「這位全職員工該坐在誰的辦公室裡」。

On-Premise LLM 不是為了省錢而做的技術倒退，而是把 AI 助理從「一個外部服務」變成「一項內部基礎設施」。當推論、身分、Agent 執行與協作介面全部落在自己的邊界內，你得到的是四件事：資料主權不需依賴他人條款、成本曲線可預測且不懲罰高頻使用、模型與工具鏈的長期選擇權握在自己手上，以及——團隊每天累積的專業判斷，可以真正沉澱成公司自己的模型能力，而不是流進別人的訓練資料裡。

UbiGPT 負責把模型與身分治理穩穩地放在內網，UbiCode 把 AI 助理從「一個全能但昂貴的萬事通」變成一支分工明確、各配適合模型的 AI 團隊，並讓工程師與 Tech Lead 各自拿到最合手的介面，UbiWork 則把 AI 協作延伸到整個產品團隊。三層都在你的機房裡，剩下的，是決定什麼時候開始。

 

---

關於優必達

優必達（Ubitus）是首家獲得 NVIDIA 投資的台灣科技公司，在 GPU 虛擬化技術與 雲端串流技術領域具備全球領先地位，並持續為各產業提供世界級的雲端與 AI 解決方案。

優必達與 國立臺灣大學（National Taiwan University）、東京大學（The University of Tokyo） 等頂尖學術機構合作，致力於開發符合在地語言與文化脈絡的 繁體中文與日文大型語言模型（LLM）。

同時，優必達亦提供多元的 AIGC（AI 生成內容）服務，包括：

• UbiArt：AI 圖像生成服務
• UbiONE：AI 虛擬角色解決方案
• UbiAnchor：AI 虛擬新聞主播
• Ubi-chan（AI VTuber）：官方品牌大使，展現優必達在生成式 AI 領域的創新成果

作為雲端遊戲領域的全球領導者，優必達提供完整的一站式解決方案，協助遊戲開發商快速將遊戲導入雲端，並支援電信業者建置自有的雲端遊戲平台。此外，優必達的技術亦廣泛應用於全球互動式媒體與虛擬實境（VR）內容的即時串流服務。

 

聯繫我們

TEL : +81-3-6435-3295 (Tokyo)

+886-2-2717-6123 (Taipei)

Media contact: pr@ubitus.ai

Business inquiry: contact@ubitus.ai

Website: www.ubitus.ai