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

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

三條路線，不只是兩條

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

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

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

六個決策面向

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

面向一：需求獨特性

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

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

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

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

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

面向二：資料敏感度

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

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

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

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

面向三：內部工程能量

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

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

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

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

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

面向四：長期維護成本

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

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

面向五：供應商鎖定風險

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

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

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

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

面向六：合規要求

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

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

決策樹與判斷表

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

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

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

對應的速查判斷表：

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

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

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

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

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

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

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

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

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

每個輸入項去哪裡要

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

算法與翻轉測試

1. 把每條路線的一次性投入（整合、開發、初始配置）與年度經常項（訂閱、維運人力、基礎設施）分開填。
2. 統一到三年口徑加總：一次性投入＋年度經常項 × 3。年期可以換，但兩邊必須同口徑。
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。