Agentforce、Copilot Studio 之外：何時選擇開放自託管執行時

先給結論：套件型 agent 平臺在自家生態裡最強——前提是你的資料、流程、身份和許可權也主要在那個生態裡。當業務散在多系統、資料要自持、模型要可選時，開放自託管執行時，或者套件與自託管執行時混用，才更接近真實企業的結構。

一家公司做 AI agent 選型，入圍名單很自然：Agentforce、Copilot Studio、ServiceNow AI Agents。三家都強，都有人推薦。

他們差點就簽了 Agentforce——CRM 場景演示得最漂亮。臨門一腳前，一位架構師提了個問題：“我們要讓 agent 處理的客戶問題，一半要查 Salesforce 裡的商機，一半要查我們自建系統裡的交付和工單。生態外那一半資料怎麼納入同一個許可權和口徑？”

銷售的回答是”可以做整合”。於是他們花了六週做了個整合 PoC。結論很清楚：能連，但每加一個生態外系統，就要重寫一套同步、對齊一次口徑、維護一條會斷的管道——而他們生態外的系統有七八個。那一刻團隊才意識到：問題不在 Agentforce 不夠好，而在它假設了一個對這家公司不成立的前提。

六週和一個 PoC 的成本，買來一個其實一開始就能想清楚的教訓。

那個沒說出口的前提：你的世界主要在同一個生態裡

這些套件的強，本質是”生態內最優”。Agentforce 最適合 Salesforce 裡的客戶、流程和物件；Copilot Studio 與 Microsoft 365、Power Platform、Teams、SharePoint、Entra 的結合最順；ServiceNow AI Agents 則天然貼近 ServiceNow 上的流程。前提成立時，它們確實省心——資料現成、許可權現成、整合現成，agent 幾乎順手就接上。

可這個前提，對很多企業並不成立。真實的企業長這樣：CRM 一家、ERP 另一家、工單第三家，外加一堆自建系統和電子表格；它們想保留模型選擇權，因為模型一年一個樣；它們受監管約束，資料不能隨便出域。對這樣的企業，“生態內最優”反而成了約束——因為業務本來就跨多個系統。每接一個生態外系統都要重寫一條管道，正是那家公司在 PoC 裡撞到的邊界。

攤開比：不是誰更好，是各自適合誰

維度	封閉套件（Agentforce / Copilot / ServiceNow）	開放自託管執行時（ObjectStack / ObjectOS）
最適合	業務已重度集中在該生態內	資料散在多系統、跨棧、要自持
資料位置	廠商雲	你自己的基礎設施
模型選擇	偏向自家或繫結模型	自由換，模型在外、執行時在內
業務定義歸屬	長在平臺裡	你倉庫裡的開放協議後設資料（Apache 2.0）
計費	按動作 / 按席位	按執行時與基礎設施，與用量解耦
起步姿態	先把業務搬進生態	擴充套件存量系統，不要求先遷移

這張表沒有”全對”的一列。

先潑兩盆冷水：很多時候，你就該選套件

把話說到前頭，免得這篇變成單方面的安利。開放自託管不是更高尚的選擇，它是為特定處境準備的選擇——而很多公司的處境，恰恰適合套件。

第一，如果你的世界真的基本在一家牆裡。 你 90% 的業務就在 Salesforce 裡、也不在意資料出域、不打算換模型——那 Agentforce 多半就是最優解。為了”不被鎖定”這個尚未發生的風險，去承擔眼前實實在在的遷移和運營負擔，是不划算的。

第二，如果你沒有平臺團隊。 這是經典的”自建 vs 購買”。開放、自託管意味著你得自己運營它——打補丁、保證可用性、管好升級。套件那種”開箱即用、出事有人接電話、有 SLA 兜底”的託管體驗，對一個沒有專職平臺團隊的公司，往往比”完全的控制權”更值錢、更省心。控制權是有運營成本的，沒人接得住的控制權是負擔。

但”買套件”省下的活，沒你以為的多

不過”購買”這一側，有一筆賬經常被算漏：整合稅。

套件的報價單上寫的是席位或動作的錢，沒寫的是——你那七八個牆外系統，每一個都要一條整合管道：建的時候要對齊口徑，建完之後要隨兩邊的升級持續維護，哪一頭改了欄位，管道就可能默默斷掉。開頭那家公司的六週 PoC，量出來的就是這筆稅的首付。所以”買套件 + 一堆易碎整合”，表面是 buy，骨子裡你還是在 build——而且 build 的是最沒價值、最易碎的那部分。

把這筆整合稅算進 TCO，“購買更省心”的結論，只在生態外系統很少、或它們本來就不需要被 agent 觸達時才穩。系統越散，這筆稅越重，套件的”省心”優勢就被啃得越多。

其實你可以兩個都用：混合不是騎牆

這就引出一個被選型討論長期忽略的選項：這不一定是單選題。

最務實的架構，往往是混合的：在你確實重度使用的那個生態裡，繼續用它的套件——Salesforce 裡的銷售 agent 就讓 Agentforce 幹它最擅長的；但在跨系統、要統一口徑、要自持資料的那一層，用一個開放、自託管的執行時來做連線組織。後者不取代套件，它做的是套件結構上做不好的那件事：把散在多個牆裡的業務，收成一份你自己持有的、帶許可權和審計的統一定義。

換句話說，開放執行時可以是你多個系統（包括那些套件）之上的連線組織，而不是又一堵要你搬家進去的牆。承認這一點，選型就從”押哪一家”變成了”哪部分用套件、哪部分用開放”——這才是大多數真實企業最後落地的樣子。

開放自託管，到底換來什麼

如果你屬於右列、或要做的正是那個跨系統的連線層，那”開放 + 自託管”換來的不是情懷，是具體的能力。最能說明問題的，是它對待存量系統的姿態——也正是開頭那家公司卡住的地方。

套件希望你的世界搬進它的牆；開放執行時假設你的世界本來就是散的，它的活是讓既有系統原生支援 AI，而不是先遷移。那家公司的客戶資料一半在 Salesforce、一半在自建系統。在 ObjectOS 上，它可以把 Salesforce 和自建庫都接成資料來源、各自建模，再用統一口徑對齊成同一個受治理的”客戶”：

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: '客戶',
  fields: {
    name: Field.text({ label: '客戶名稱', required: true }),
    tax_id: Field.text({ label: '統一社會信用程式碼' }), // 跨系統對齊“同一個客戶”的口徑
  },
});

差別可以具體到一次提問。“這個客戶值不值得投入資源保？”——

• 之前：agent 接 Salesforce，看到商機活躍，答”值得”；它壓根不知道自建系統裡這個客戶的交付一直在延期、工單積壓。
• 之後：agent 面對的是一個統一的客戶，商機、交付、工單一起看，答”商機不錯，但交付風險高，先解決履約再談擴單”。

同一個模型、同一個問題，只因為腳下的”客戶”不再被牆切開，結論就從片面變成了全域性。而這一切不需要為每個牆外系統重寫同步管道——業務定義是你倉庫裡可 diff、可遷移的後設資料；執行時跑在你自己的基礎設施上，強制許可權、記錄審計；模型可以來自外部任何一家。你沒有把”自己業務的定義”交給任何一家保管。

一個誠實的選擇題

所以這不是”誰該被淘汰”，是”哪部分交給誰”。問自己三個問題：

1. 我的業務，是基本都在某一家生態裡，還是散在多個系統中？
2. 我能不能接受資料持續流向廠商雲？合規上籤得了字嗎？
3. 我有沒有團隊去運營一套自託管的執行時？

前兩個答案偏”散的、不能”，第三個偏”有”——那你要找的，本來就不是又一個更強的封閉套件，至少在那個跨系統的層上不是。如果三個答案都偏向另一邊，那就大方用套件，它們確實好用。誠實地對號入座、甚至大方地混著用，比追逐誰家功能更新重要得多——也比花六週做個 PoC 才想明白，便宜得多。

結語

封閉套件贏的是”生態內最優”，這個優勢在它的前提成立時非常真實，不該被否認。開放自託管執行時贏的是”前提不成立時仍然成立”——當你的世界是散的、資料要自持、模型要自由、定義要握在自己手裡，並且你擔得起自己運營它的那份責任。

知道哪部分該用套件、哪部分該用開放、以及為此各付什麼代價——比任何一家的功能列表都重要。開頭那家公司如果早點問那三個問題，能省下六週和一個 PoC。

npm i -g @objectstack/cli && os start

不用遷移、不用進誰的牆，五分鐘在自己的環境裡跑起一個跨兩個系統的統一物件，再判斷這條路是不是更像你要的樣子。