自建還是採購：企業 Agent 平台的決策樹（Chinese original）

當 AI 應用從「幾個部門各自用工具」走到「公司需要一個統一的平台」，就會撞上這個決策：自建還是採購。兩邊都有響亮的口號——「不掌控平台就不掌控命運」對「不要重複造輪子」——但口號不能代替分析。這篇給你一棵決策樹：六個面向、每個面向的自我提問與兩邊信號，最後匯成一張判斷表與一份總擁有成本的對比框架。它不會替你做決定，但會讓你的決定有結構、有紀錄，日後環境變了也知道該重看哪幾個假設。

三條路線，不只是兩條

「自建 vs 採購」其實是三條路線，先把選項攤開：

路線	具體形式	你需要什麼	典型風險
純採購	使用 SaaS 形式的 AI 平台或企業助手產品	預算、採購與法務流程、內部推廣	資料出網、功能受限於產品路線圖、供應商鎖定
自架開源	把 Dify、n8n 這類開源平台部署在自己的雲或機房，配置與整合自己做	一到兩名能維運的工程師、伺服器資源	開源不等於零成本：升級、安全修補、整合都是你的
完全自研	從模型呼叫層開始，自己寫編排、記憶、工具接入	專職工程團隊、明確且穩定的需求、管理層耐心	工程量與人才依賴遠超預期；平台還沒好，業務已經變了

多數「要不要自建」的爭論，其實是「自架開源」與「純採購」之間的選擇；真正走到「完全自研」的公司應該很少，且要有非常特殊的理由（下面會講是什麼理由）。

還要提醒一件事：這棵決策樹回答的是「平台層從哪來」，不是「該不該用 AI」。如果場景本身值不值得做還沒想清楚，先過選 AI 工具的判斷框架與什麼時候不該用 AI這兩關，再回來談平台——平台決策建立在「已經有值得平台化的場景」這個前提上。

六個決策面向

每個面向給三樣東西：要問自己的問題、偏採購的信號、偏自建的信號，以及一個可以立刻動手的盤點工具。

面向一：需求獨特性

問自己：我們要的能力，市面產品覆蓋了幾成？剩下沒覆蓋的部分，是「差異化競爭力」還是「我們公司特有的歷史包袱」？

偏採購	偏自建
需求是通用的（客服問答、文件檢索、會議整理）	需求深度綁定獨有業務邏輯，且這邏輯是競爭優勢來源
沒覆蓋的部分屬於內部系統的特殊串接	沒覆蓋的部分正是產品要做的事

警惕一個陷阱：「我們的流程很特別」多數時候不是事實，而是沒看過標準產品怎麼做。先拿真實場景去試兩三個產品，再宣稱獨特性。

盤點工具：需求覆蓋度清單。 獨特性不能坐在會議室裡判斷，要跑一次盤點：

列出任務清單：把平台要承載的核心任務逐條寫下來（接知識庫、跑審批流、串內部系統、多模型切換、匯出稽核日誌……），粒度細到每條都能當場驗證。
拿兩三個候選產品逐條實測：不看銷售演示，用你們自己的真實資料與場景測。
每條標記三種狀態：覆蓋（開箱即用）、半覆蓋（能做到但很彆扭）、未覆蓋（完全做不到）。
對每條「未覆蓋」回答一個問題：這條是我們競爭優勢的來源，還是只是內部歷史包袱？

盤點結果	信號解讀
未覆蓋多，且屬於業務核心	偏自建的強信號
未覆蓋多，但屬於歷史包袱	先考慮改流程，而不是改平台
半覆蓋多	小心：整合與繞路的成本最容易被低估
幾乎全覆蓋	偏採購

「半覆蓋」的解讀值得單獨強調：產品「能做但不好用」時，你需要的是整合開發、繞路配置與教育成本。這些在評估時最容易被歸類成「覆蓋了」，上線後才逐條爆發。半覆蓋項要在成本表的「整合開發」一行逐條列出來計價。

面向二：資料敏感度

問自己：平台會接觸到哪個等級的資料？出網是否被政策或監管禁止？

偏採購	偏自建（自架）
資料以公開與一般內部為主	機密與受監管資料是核心輸入
供應商能提供符合要求的合約與稽核報告	政策要求資料與運算全程留在邊界內

資料分級的判斷方法見企業資料安全基本盤。注意中間地帶：「資料不出網」不等於「必須完全自研」——自架開源平台加本地或合規雲模型，往往就滿足了要求。

把分級與路線對照起來，這個面向的答案就出來一半了：

平台會接觸的資料	可行路線
公開資訊與一般內部文件	採購或自架皆可，看其他面向
含個人資料，可去識別化後處理	採購可行，但去識別化流程與資料處理協議要先過法務
含個人資料，無法去識別化	私有部署或自架；純公有 SaaS 要法務逐案評估
營業秘密與受監管資料	自架加本地或合規模型，或該場景暫不入平台

這張表是判斷框架，不是法律意見：具體哪一級資料允許走哪條路線，以你們法務與資安部門的口徑為準。合規面向的完整盤點方法見AI 合規與風險邊界。

面向三：內部工程能量

問自己：我們有沒有「能長期負責這件事」的工程師？是兼職還是有專人？他們離開了誰接手？

偏採購	偏自建
沒有專職平台工程師，IT 以維運現有系統為主	有能投入的團隊，且管理層接受「平台是產品、要持續養」
工程師招聘與留任困難	已有工程文化與文件習慣

這個面向最常被高估。「我們有工程師」和「我們能養一個平台」是兩件事：平台需要的是持續的升級、修補、整合、on-call，而不是一次性的開發衝刺。如果答案是「擠得出來一個人兼著做」，那就是偏採購的信號。

盤點工具：工程能量自查清單。 這幾題請工程主管與業務主管各自回答一遍，再對照雙方答案的落差：

有至少一名工程師的正式職責包含這個平台（不是「順便做」）
這位工程師離職時，有明確的接手人選與交接文件機制
平台出故障時有回應機制，而不是「等下週上班再看」
團隊有文件與變更紀錄的書面習慣
過去一年，團隊完整交付並維運過類似規模的內部系統
管理層理解並接受「平台要持續養，不是一次交付」
招聘缺口時，能把招聘難度與到職空窗如實排進時程，而不是當確定資源

多數勾不上的，就是偏採購的強信號。工程能量是唯一可以「後來補上」的面向，但補的速度要按真實招聘與培養週期算，不能按願望算。

面向四：長期維護成本

問自己：三年後這個系統還在跑，屆時每年的維護投入是多少？誰付、誰做？

偏採購	偏自建
希望成本可預測（訂閱制）、維護外包給供應商	能接受維護成本隨功能成長，並有預算編列
沒有能力吸收安全事件與故障的處置責任	有 SRE 或同等能力，能承擔生產責任

自建的成本曲線是「前低後高」：第一版做出來很興奮，之後的模型更新適配、安全修補、依賴套件升級、人員流動交接，才是大頭。完整的成本估算方法見AI 成本怎麼算，把「維運人力」那一行放到三年的跨度上攤開，就是自建路線要正視的數字。

面向五：供應商鎖定風險

問自己：如果三年後要換供應商，什麼帶得走、什麼帶不走？

鎖定風險低（偏採購可接受）	鎖定風險高（要談清楚或偏自建）
資料可完整匯出（文件、對話紀錄、知識庫）	核心資產沉澱在供應商私有格式裡
使用標準介面（開放 API、通用協定）	深度依賴私有功能與私有外掛機制
合約有資料取回與過渡條款	續約時議價能力全無

鎖定不是「有沒有」而是「多深」。評估方法：向供應商白紙黑字問清楚匯出能力與格式，並把答案寫進合約。開源路線在這一點有天然優勢——但注意開源專案本身也可能停更或改授權條款，「開源鎖定」同樣存在。

盤點工具：簽約前的供應商提問清單。 每一題都要拿到書面回答，並歸檔進決策紀錄與合約附件：

問題	真正在問什麼
知識庫文件、對話紀錄、工作流定義能否完整匯出？格式是什麼？	資料帶不帶得走
匯出格式是通用格式還是私有格式？	匯出之後在別處重建的成本
模型層能不能替換？換模型供應商時要改多少配置？	模型層的鎖定深度
開放 API 覆蓋哪些功能？私有功能佔我們用法的多大比例？	介面標準化的真實程度
續約調價的通知期與機制是什麼？	預算可預測性
產品停售、供應商被收購時，客戶的權益與過渡安排？	極端情況的退場保障
合約是否含資料取回與遷移協助條款？	退場時有沒有人幫忙

開放協定為什麼能降低鎖定、怎麼用它在評估中加分，見MCP 協議指南。

面向六：合規要求

問自己：所處行業的監管對系統有什麼硬性要求（稽核日誌、資料駐留、可解釋性、紀錄保存）？

偏採購	偏自建
供應商已有行業合規實績與現成文件	合規要求特殊，現成產品的文件覆蓋不了
要求可以寫進合約（資料處理協議、稽核報告）	監管要求系統層面的深度定制

金融、醫療等受監管行業要特別注意：合規既可能是採購的理由（大供應商的合規文件比你自己做的全），也可能是自建的理由（監管對系統控制權有要求）。這個面向的盤點方法與該問法務的問題，見AI 合規與風險邊界。

決策樹與判斷表

把六個面向串成一棵樹。從最硬的約束開始問，軟性偏好放後面：

Q1 資料能不能出網／用合規雲？
  ├─ 不能，且必須全程留在邊界內
  │   → 自架開源（有工程能量）或 暫不建平台（無工程能量）
  └─ 能，或可接受合規雲方案
     ↓
Q2 合規要求，現成供應商能否用文件與合約滿足？
  ├─ 不能，需要系統層定制 → 偏自建（自架開源起步）
  └─ 能 ↓
Q3 需求獨特性：產品覆蓋不足的部分是不是核心競爭力？
  ├─ 是，且工程能量到位 → 自研或深度自架
  └─ 否 ↓
Q4 工程能量：有專職團隊能長期養平台嗎？
  ├─ 有 → 自架開源（成本與控制權折衷）
  └─ 沒有 ↓
Q5 供應商鎖定風險可接受嗎（資料可匯出、標準介面）？
  ├─ 可 → 採購 SaaS
  └─ 不可 → 回到 Q4：培養工程能量，或選可自架的開源方案

使用這棵樹的三個紀律：從上往下問，不要跳題——前面的硬約束（資料、合規）會直接砍掉後面某些選項，先談偏好再看約束是常見的順序錯誤；每個答案留下依據——「資料不能出網」是政策寫的還是假設的？依據不同，半年後重看時結論可能不同；允許走到「暫不建平台」這個出口——很多公司真正的現狀是：場景還太少、能量還不夠，此時正確答案不是二選一，而是先用單點工具跑場景、累積需求，平台決策留到有足夠證據時再做。

對應的速查判斷表：

情況	建議路線
通用場景、資料可出網、無專職工程	採購 SaaS
資料不能出網、有一兩名工程師	自架開源平台加本地或合規雲模型
資料不能出網、無工程能量	暫不建平台；先用單點工具解決單點問題，同時培養能量
深度獨特業務邏輯是核心競爭力、有團隊	自研關鍵層，通用部分仍用開源或採購
受監管行業、供應商文件齊全	採購，但把合規義務寫進合約
想控制又不想從零寫	混合模式（下一節）

混合模式：多數公司的實際答案

純採購與純自建是兩個極端，實務上最常見、也最穩健的是混合：

買平台、建場景：平台層（模型接入、權限、日誌）用採購或開源，業務場景層（知識庫、工作流、提示詞資產）自己建。場景資產是自己的，平台換了可以遷。
開源底座、自研外掛：用開源平台當底座，只針對獨特需求寫外掛與整合，不動核心。升級跟著社群走，定制部分自己養。
資料在地、模型在雲：敏感資料的儲存與處理留在邊界內，模型推理呼叫合規雲 API（去識別化後）。這是資料敏感度與能力之間的常見折衷，可行性要先過法務。
階段演化：先採購跑通場景、累積需求與資料，一段時期後再評估哪些部分值得自建。順序很重要——先買後建，你帶著真實需求去建；先建後買，你帶著想像去建。

分層看，「哪一層買、哪一層自己建」有一張常見的分工表：

層	這層做什麼	常見混合做法
模型層	提供推理能力	幾乎沒有人自訓基礎模型；用雲 API 或本地部署開源模型，並保留切換能力
平台／編排層	權限、日誌、工作流引擎、知識庫管理	採購 SaaS 或自架開源；「自建 vs 採購」爭論的主體就在這層
場景層	各業務場景的提示詞、工作流、測試題集	幾乎都自建——這才是差異化所在
資料層	知識庫內容、業務資料與串接	資料本體留在自己手裡，平台裡放的是部署副本

這張表用一句話讀完：**愈靠近資料與業務的層，愈該自己掌握；愈靠近通用基礎設施的層，愈該用現成的。**多數「要不要自建」的糾結，來自把四層混成一層整體思考。

混合模式的管理要點是邊界要畫在文件上：哪一層是買的、哪一層是開源的、哪一層是自研的、各自誰負責。邊界模糊的混合，最後會變成「哪一層都沒人負責」。

還有一個容易被忽略的資產歸屬問題：混合架構下，真正值錢的往往不是平台，而是沉澱在平台上的場景資產——知識庫、提示詞、工作流定義、測試題集。這些資產要用可攜的格式管理（原始文件在自己的儲存裡、平台裡的是部署副本），換平台時重建的是部署，不是資產本身。這一層的建設方法，見組織 AI 能力建設。

總擁有成本：怎麼公平地比

兩條路線的成本結構不同，直接比「報價」沒有意義，要比三年期的總擁有成本（TCO）。本文不會替你填任何金額——所有數字都必須來自你自己的報價、薪資口徑與工時估計。這張框架表列出兩邊各自該填的項目（金額留空，用AI 成本怎麼算的方法填）：

成本項	採購路線	自建路線
授權與訂閱	年訂閱費 × 3 年	開源授權成本（通常為零，但注意授權條款變更風險）
基礎設施	通常含在訂閱內	伺服器、GPU 或雲資源 × 3 年
整合開發	初次整合工時	平台開發工時＋整合工時
維運人力	管理員兼職投入	專職或部分專職工程師 × 3 年
升級與適配	供應商負責，你付測試時間	模型更新適配、安全修補，全部自己
訓練與推廣	兩者相同：使用者訓練、文件、內部推廣	同左
退場成本	資料匯出與遷移的預估工時	平台廢棄時的場景遷移工時

每個輸入項去哪裡要

填表不是財務一個人的事，每個輸入項都有明確的來源與口徑：

輸入項	找誰要	口徑注意
訂閱或用量報價	供應商的書面報價	問清楚計費單位（按席位、按呼叫量還是按用量），並要求列出各檔位
內部人力成本	HR 或財務	用含福利與管理攤提的完整用人成本口徑，不要用薪資面額
基礎設施	IT 或雲服務定價頁	自建路線要估伺服器與模型部署資源；用量估算法見成本估算一文
整合與開發工時	工程負責人	把「半覆蓋」項的繞路與整合工時逐條計入
訓練與推廣工時	實際負責推廣的人	兩條路線都有這項，別漏
退場成本	工程加法務	資料遷移與場景重建的工時估計

算法與翻轉測試

把每條路線的一次性投入（整合、開發、初始配置）與年度經常項（訂閱、維運人力、基礎設施）分開填。
統一到三年口徑加總：一次性投入＋年度經常項 × 3。年期可以換，但兩邊必須同口徑。
做翻轉測試：對表中每一個估計出來的假設（用量、人數、續約調價幅度、工時），逐一問「這個假設在合理範圍內變動，結論會不會翻轉？」容易翻轉的假設，就是這個決策真正的敏感點——把它寫進決策紀錄，並在 PoC 中優先驗證。

不要指望一個通用的「差多少就選便宜那個」門檻——差異容忍度由你自己定：如果兩條路線的三年總額落在你設定的容忍範圍內，成本就不是決定性因素，回到控制權、合規、組織能量這些軟性面向做判斷。

填表時的兩個紀律：維運人力用完整用人成本（含攤提，向財務要口徑），不要用薪資面額；退場成本兩邊都要填，自建不是「沒有退場成本」，只是退場的形式不同。

最後，把「何時重估」也寫進決策文件。事先約定觸發條件，比事後爭論「要不要重審」容易得多。常用的觸發條件包括：核心場景數量或用量翻倍、供應商續約條件重大變化、公司工程師招聘到位或核心工程師離職、監管要求出現新變化、開源生態出現明顯更成熟的選項。觸發時不必推翻全部分析——把六個面向的答案逐格重看，變了的格子自然會把你導向新的結論。

PoC：決策前的最後一關

無論決策樹指向哪條路線，簽約或立項之前先做一個小規模驗證（PoC）。PoC 要驗證的不是「產品能不能演示」——演示場合它當然能跑，那是演示——而是「在我們的環境裡能不能跑」。

PoC 設計檢查表：

用真實業務資料與真實場景測，不用供應商準備的示範資料
通過標準在開始前白紙黑字寫好：哪些任務必須完成、品質到什麼程度算過、誰來判定
時間與範圍固定，到期出結論，不無限延期
覆蓋度盤點裡的「半覆蓋」項全部列入 PoC 實測
自建路線同樣做 PoC：用最小可行版本驗證最難的技術假設，而不是先做漂亮的介面
寫明退出判定：出現什麼情況直接終止（例如資料安全硬約束被觸碰）
PoC 的結論與證據歸檔進決策紀錄

PoC 最常見的失敗是無限拖長：標準沒先寫、供應商不斷加演示、內部不斷「再試試看」，最後決策沒依據，時間倒是花了不少。判定的紀律很簡單——開始前寫下的標準，結束時逐條對答案，過就是過，不過就是不過。

把決策留成一頁紀錄

這個決策的價值會隨時間衰減：今天的結論建立在今天的假設上。把分析過程存成一頁決策紀錄，等觸發條件出現時可以直接重看：

【Agent 平台路線決策紀錄】
日期／決策者／參與者：
業務場景與規模：
六個面向的答案與依據：
  需求獨特性：覆蓋度盤點結果＋未覆蓋項定性
  資料敏感度：資料分級結果＋法務口徑
  工程能量：自查清單結果＋兩份問卷的落差
  維護成本：TCO 表關鍵假設與敏感點
  供應商鎖定：書面提問清單的回答歸檔處
  合規要求：硬性要求清單＋法務確認
TCO 三年對比摘要（含翻轉測試結果）：
PoC 結論與證據位置：
決定：採購／自架／自研／混合／暫不建
重新評估的觸發條件與下次覆審日期：

最後兩行最重要：它們把「什麼時候重審」從爭論變成約定。

常見誤區

誤區一：「我們有工程師，所以應該自建。」 有工程師和能長期養平台是兩件事。用「這個人離職後誰接手」這個問題檢驗，答案含糊就是能量不足。

誤區二：「開源等於免費。」 開源免的是授權費，不免部署、整合、升級、安全修補、維運的人力。自架開源的三年 TCO 超過 SaaS 訂閱的情況並不少見——差別在錢花在自家工程師身上，不容易被看見。

誤區三：「採購之後就無事了。」 採購路線依然需要管理員：權限、用量、場景配置、供應商版本更新的測試。只是這個投入通常比養平台小一個量級。

誤區四：一次決定、終身適用。 這個決策的正確壽命大約是幾個覆審週期以內的事。業務量、工程能量、供應商市場都在變，把決策樹和 TCO 表存檔，定期重跑。重跑的觸發條件事先寫好：例如「核心場景數量翻倍」「供應商續約條件重大變化」「工程師招聘到位」。

誤區五：低估遷移成本，高估遷移意願。 「反正以後可以換」需要「資料可匯出、介面標準化、合約有保障」三個前提都成立才為真。簽約前把這三項談清楚，比簽約後抱怨鎖定有用得多。

誤區六：工程團隊自建、業務無人接責。 自建平台最典型的死法不是技術失敗，而是需求沒人定義、產出沒人驗收、上線沒人推廣——平台變成技術側的自嗨專案。自建的前提，是業務側有人像對產品一樣對平台的成敗負責。

誤區七：把演示當驗證。 供應商的演示環境與你的真實資料、真實併發、真實整合之間，隔著一個 PoC。沒跑過 PoC 的決策，本質上是相信廣告。

下一步

把 TCO 表的每一格算出來：AI 成本怎麼算。
面向二與面向六的完整方法：企業資料安全基本盤與AI 合規與風險邊界。
決定自建之後，工程側的起步參考：Agent 基礎建設總覽與三層 Agent 協同框架。
平台選好了，組織怎麼用起來：組織 AI 能力建設。
先確認場景本身值不值得做：什麼時候不該用 AI。