自建還是導入 AI Agent?大中華區企業的 Build vs Buy 決策框架

一句話先講結論:AI Agent 自建 vs 導入,不是技術題,是「這件事的知識護城河在不在你手上」的商業題。護城河在,就自建;不在,就導入,把省下的時間拿去打你真正該打的仗。

我們去年幫一家華南的製造集團做這個決策。他們原本鐵了心要自建一整套排程 Agent,理由是「資料太敏感,不能外流」。結果盤下來,真正碰不得的只有兩張表,其餘八成流程市面上的方案早就做得比他們好。最後的答案不是二選一,是混的:核心引擎導入,敏感那一層自建包起來。上線第六週,採用率 61%。

這才是重點——大部分人把 Build vs Buy 問成了「哪個比較強」,但真正該問的是「哪個能在我這家公司、我這個合規環境裡,真的被人用起來」。

先分清楚:你在決策的到底是哪一層

AI Agent 從來不是一個整體。它至少拆成四層:底層模型、編排框架 (orchestration)、與內部系統的整合層、以及最上面貼著你業務邏輯的那層。

多數企業在「自建 vs 導入」上吵翻天,是因為把四層綁成一包在討論。實務上你幾乎不會全自建,也很少全導入。真正的決策是逐層問:這一層的知識是我的差異化來源嗎?外面有沒有夠成熟的東西?自己養這層,我養得起維運嗎?

模型層,自建基本不用考慮,除非你是要做基礎研究。整合層與業務邏輯層,往往才是你該親手掌握、也最該投入 FDE 工程資源的地方——因為那裡藏著你比對手強的原因。

把六個維度攤開,分數自然會浮出來:

一條實用的判準:六格裡若有四格以上落在同一側,方向就定了。落在中間地帶,答案通常是混合架構——導入成熟骨架,自建敏感與差異化的那幾塊。

同樣一張矩陣,在台灣、香港、大陸算出來的結果不一樣。原因在三件本地事。

第一是資安與資料落地。大陸的《數據安全法》《個人信息保護法》對跨境傳輸卡得很緊,金融與醫療資料幾乎不可能走境外 API。這一格幾乎自動把你推向「敏感層自建、私有化部署」。台灣金融業則受金管會雲端委外規範約束,得先過內部資安審查。

第二是合規審計的可解釋性。導入的黑箱 Agent 一旦出事,你很難向監理單位交代它為什麼這樣決策。自建或半自建至少能留下可稽核的決策軌跡。這在受監管產業不是加分項,是門檻。

第三,也是我們看過最多人栽的一項——採用率。地端團隊的語言習慣、既有系統的老舊程度、現場人員對 AI 的信任度,國外方案的預設值幾乎都不合。一套為「一般客戶」設計的 Agent,搬到一家哪裡都不一般的本地公司,Demo 再漂亮,實際使用率照樣掉到個位數。

所以我們的建議常常是反直覺的:先不要問自建還導入,先去現場看那套東西「會不會有人用」。答案往往決定了架構,而不是反過來。

如果只能記一件事:按層拆、按在地變數加權、再讓混合架構成為預設選項,而不是把自建與導入當成非黑即白。差異化與敏感層親手握住,通用骨架大方外購。

Tenten 做這類決策時,不從架構圖開始,是從客戶現場的採用率反推架構——工程師先進場,把敏感邊界、合規紅線、現場使用習慣摸清楚,再決定哪一層自建、哪一層導入。畢竟 Demo 很美不算數,上線而且真的有人在用,才算數。