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

不用迁移、不用进谁的墙，五分钟在自己的环境里跑起一个跨两个系统的统一对象，再判断这条路是不是更像你要的样子。