企业AI采购的第二阶段：谁把模型算成了一笔清楚的账

两年前，企业讨论 AI 的时候，问题通常是能不能做。现在这个问题变了，变成了做完之后省了多少，这笔钱什么时候回来。这个变化听起来只是个说法，其实它改变了整个行业的卖法。

因为一旦客户开始问回报，供应商就不能只展示能力了。它得展示账本。而账本这个东西，是要能被别人翻、被别人对、被别人挑毛病的。

2025 年这一年，微软、Salesforce、ServiceNow 三家做的事，表面上看是发产品、发版本、发定价，实际上都在回应同一件事：把证明价值这个动作做进产品里，让客户能拿着一份东西去开会。

这一期我想把这三家的做法拆开，看它们各自把计量的锚点放在哪里。为什么放在那里，这个位置对供应商和对客户分别意味着什么，以及这些公开材料到底能证明到什么程度。

计量

先立一个坐标，不然后面容易看混。企业判断一个 AI 项目值不值，实际上要做三次判断：这件事有没有发生，发生了多少，发生之后划不划算。三件事的难度完全不同。

有没有发生，看日志就行。发生了多少，需要定义单位。划不划算，需要基线、需要对照组、还需要把成本全算进去。业内的公开材料，大多停在前两步。

第二阶段这个说法，不是一个官方分期，是一种观察角度。它指的不是技术换代，是买方的评估方式换了：从看演示，变成看报表。

这个变化对企业内部的影响，比对外部大。因为看报表这件事，需要有人先定义什么叫好。定义权在谁手上，谁就掌握了这个项目的生死。

先从最容易被忽略、但其实最要命的地方说起：计价单位。

计价单位不是一个财务细节，它决定了供应商的收入跟什么绑定，也决定了客户的风险长什么样。

企业软件的计价单位，这几十年一直在往下沉。最早是按人头，一个员工一个席位，不管你用不用，钱照收。这个模式供应商最喜欢，因为收入可预测。

席位制的毛病，客户很清楚：买了不用也要付钱，用得多也不多付。所以一到云时代，供应商急着推用量计费，客户也接受，因为理论上更公平。但公平的代价是波动。

后来云计算起来，单位变成了用量，按 API 调用次数、按存储、按算力。收入开始跟着使用强度走，客户的风险开始上升，因为你没法在年初把账单算死。

到了 agent 这一代，单位又往下沉了一层。因为 agent 不是被动等你调用，它会自己发起动作。计价的对象从人变成了工作本身。

计费层

Salesforce 是观察这个过程最好的样本，因为它在一年之内换了两次口径。

2024 年 9 月 12 日，Agentforce 发布。这是 Salesforce 的自主 agent 平台，能在服务、销售、营销、电商这些场景里自己执行任务。你可以理解成，它不只是回答问题，它会去改系统里的记录、发邮件、开单、关单。

Agentforce 这个名字里的 force，Salesforce 用得很熟练，它把自己定位成让 agent 去执行，而不是让 agent 去建议。这个定位差别很大：建议错了可以不理，执行错了要修。

当时公告里写的起价，是每次对话 2 美元。

注意这个单位。它的计量对象是一次对话，不管这次对话里处理了几件事，都算一次。这对客户是友好的，因为边界清楚，一次交互一次钱。

按对话收费还有个隐含的好处，对客户来说边界感强。你大概知道一个月会有多少客户来问，账单能估个八九不离十。这种可预测性，在预算会上很值钱。

2025 年 5 月 15 日，第二套方案出来了，叫 Flex Credits，弹性积分。这次的计量单位换成了 action，动作。每个 action 消耗 20 credits，公告标出来的价格是每个 action 0.10 美元。

同时还有一份 Flex Agreement，弹性协议，允许客户在用户许可和数字劳动力投入之间做调配。数字劳动力这个词，指的是 agent 干活折算出来的产能。本质上是把软件当成一种可以按量雇佣的劳动力来定价。

这两次公告不能简单对比。对话和 action 是两个不同的计量单位，光看标价，比不出谁更便宜。而且新方案加进来，也不说明旧的按对话计价已经全面取消。两套东西在客户合同里怎么并存、什么条件可以迁移，公开材料里没有答案。

但方向是清楚的。计量单位从对话下沉到 action，说明供应商想把收入锚在更细的实际工作上。一次对话里如果 agent 做了五个动作，按对话收一次，按 action 收五次。

这个设计对供应商有一个直接好处：收入和使用强度绑得更紧。客户业务量涨，agent 干活变多，账单跟着涨。这比席位制弹性大得多。

对客户则是另一个故事。成本从固定变成浮动。你没法定一个年度预算然后忘掉它，因为 action 的数量取决于业务量，也取决于 agent 的设计有多爱动手。

这里有个细节值得注意。Salesforce 同时给了一个叫 Digital Wallet 的工具，数字钱包，用来管用量和做预测。这个工具的存在本身就是一种承认：这笔开销是会变的，客户需要有人帮他盯着、帮他踩刹车。

所以第一层的判断是这样的。计费单位的细化，是把价值主张落实到可以计数的动作上。这个动作确实比对话更接近工作本身。

但计数的是动作，不是成果。一个 action 可以是一次干净利落的工单关闭，也可以是一次用户试了两下就放弃的失败尝试。在账单上，这两个长得一模一样。

往深一层想，计费单位的细化，其实是在解决供应商自己的一个难题：agent 的价值不好定价。它不像存储按 GB 算，也不像坐席按人算，它干的是判断和操作，价值随场景变化极大。按 action 收是一种折中，把不可测的价值换成可测的次数。

这里有个概念需要说清楚，就是 action 到底怎么算。点一次按钮算一个，调一次外部系统算一个，还是完成一个业务节点算一个？公开材料没有给出统一定义。定义不清，账单就不好预测，跨供应商更没法比。

这就是计量工具的天花板。它能告诉你发生了多少次，告诉不了你值不值。要跨过这条线，得靠流程绩效数据，那是另一套东西。

分析层

再看微软，它走的是完全不同的路。它没有改计价单位，它做的是分析层。

先说清楚一个容易混的地方。微软这块业务其实有两层：一层是给员工用的助手，一层是给企业搭 agent 的工具。Copilot Studio 属于后者，它是搭东西的地方，不是聊天窗口。这个区分很重要，因为 ROI 讨论的对象是后者。

微软在 Copilot Studio 里有一个工具，叫 Savings calculator，节省计算器。文档里的定位是：按 agent 单次运行、或者按工具，来估算相比其他做法节省的时间或者成本。微软把它描述成估算业务影响、跟踪 ROI 的方式。

这个工具长得很朴素。你要填几个数字：这个 agent 一个月跑多少次，每次相比人工省多少分钟，人力成本折算多少钱。填完，出来一个年化节省额。

这类工具在采购流程里有个专门的位置，叫 business case，商业论证。它不是事后算账，是事前说服。一份预算要过会，通常就得有这么一张纸。

问题在于，那几个输入参数是人填的。跑多少次，取决于你怎么估业务量。省多少分钟，取决于你拿它跟什么比。工具本身不校验这些假设，它只负责把假设算成一个漂亮的数字。

一种很典型的用法是把它反过来用：先定一个想要的投资回报率，再倒推每次要省多少分钟。这个做法本身没问题，但它说明这类工具的性质是目标设定，不是结果测量。

但它产出的东西，性质是估算。它是可配置的，是根据你填的参数推出来的，不是经过独立审计的已实现收益。这个区别，在预算会上经常被模糊掉。

微软还有另一半，这一半更扎实。2025 年春天，它公布了 Copilot Studio 和 Viva Insights 的集成，当时是公开预览。Viva Insights 是分析组织工作方式的工具，集成之后可以汇总企业内 agent 的使用趋势和影响分析。

这一半是事后观测。它回答的是：agent 被用了多少，用在哪些场景，趋势在往上还是往下。它基于真实发生的使用数据，比输入框硬。

但使用和收益之间，还隔着一层。用得多的团队业绩好，不等于用工具导致了业绩好。

微软公开过一个内部销售案例：Copilot 的高频使用者，人均收入高 9.4%，赢单数量多 20%。这是公司自己观察到的关联性结果。

这个数字传播得很广，但它的证据强度要打个折。高频使用者可能是本来就更能干、更主动的那批人。他们收入高，可能因为他们本身强，也可能因为工具帮了忙。这两种解释，公开材料分不开。

要分开，需要对照。比如同一批销售，随机分成两组，一组重度用，一组不用，看半年后的差距。这种设计在软件行业很少做，因为成本和周期都太高。所以大部分我们看到的数字，都是相关性，不是因果。

这里可以插一句关于 agent 到底是什么的解释，因为后面还要反复用到。agent 跟以前的聊天机器人最大的区别，是它有手。聊天机器人只能给你一段文字，agent 能调用系统、能提交表单、能改数据。所以它出错的时候，后果也比聊天机器人重。

这解释了一个现象：企业评估 agent，最关心的往往不是它多聪明，是它出错的时候会不会被发现、能不能回滚。这个关注点，跟评估一个员工有点像。

回到微软。它的路径可以概括成一句话：一头是事前的估算器，一头是事后的使用面板，中间缺的那一环，是把使用和成果对上号的因果证据。

这个缺口不是微软一家的问题，是整个行业的现状。因为补上这一环，需要的不是产品，是客户愿意做对照实验，而这个成本通常没人愿意付。

顺带说一句，这也是为什么 AI 项目失败率高这类说法要小心对待。失败的定义不一样，结论就不一样。按有没有上线算，和按有没有达到预期回报算，是两个完全不同的分母。

流程宿主

第三家 ServiceNow，做法又不一样。它几乎不谈新的计价单位，它谈的是平台。

2025 年 3 月 12 日，ServiceNow 公布了 Yokohama 这个平台版本。公告里说新增了跨 CRM、HR、IT 这些领域的 AI agents，重点强调可以在单一平台上构建、上线和管理 agent。

这个措辞值得停一下。构建、上线、管理，这三个词讲的是生命周期，不是能力上限。它卖的不是 agent 有多聪明，是 agent 从做出来到管起来，都在同一个地方，不用来回搬。

平台这个词在企业软件里被用滥了，但它的经济学含义很具体：一次建设，多次复用。agent 建在一个已经有流程、有权限、有数据的地方，边际成本低。建在一个空地上，每一块砖都要自己搬。

这条路线的好处，藏在数据里。ServiceNow 本来就是做 IT 服务管理、人力资源服务、客户服务这些流程系统的。一张工单从开单到关闭，每一步都在系统里留痕。

这意味着基线数据天然存在。你想想，要证明一个 agent 有用，最难的是什么？是知道没有它的时候是什么样。人的记忆不可靠，事后回忆的省了多少时间，基本都是估的。

如果流程本来就在系统里跑，历史数据一拉，基线就有了。去年同期这个月，平均处理时长多少，一次解决率多少，返工率多少。这些数字不需要新建，它们本来就在。这是微软和 Salesforce 要靠集成去补的东西，ServiceNow 本来就有。

但这也带来一个麻烦，叫归因混淆。假设一个工单的处理时间从 8 小时降到 3 小时。这里面有多少是 agent 的功劳，有多少是你顺手把流程也改简单了？两件事一起做，效果混在一起，事后很难拆开。

而且客户上 agent 的时候，通常不会只上 agent。它会顺便梳理流程、清理数据、调整权限。这些都是好事，但它们会一起体现在指标上，全都记在 AI 头上。

这就是平台路线的两面。一面是基线便宜，另一面是归因困难。而这两面其实是同一个原因造成的：agent 和流程长在一起了。

流程系统做归因有个天然的难处，也有个天然的优势，两者是一体两面。优势是数据全，难处是变量多。一条流程上改动五个地方，最后指标变好了，你说清是哪个起的作用？这需要很强的实验设计，而企业的流程不允许随便做实验。

还有一点要说清楚。ServiceNow 公告里那些效率和 ROI 的表述，属于公司主张。公告是产品能力的陈述，它说的是我们能做什么、预期能带来什么，不是客户已经拿到净收益的证据。这两者之间隔着实施周期。

所以三家放在一起，差异的本质不是模型能力的差异，是价值捕获位置的差异。微软在分发和分析这一层，Salesforce 在用量计费这一层，ServiceNow 在流程宿主这一层。

这三个位置，各自对应一种竞争壁垒。微软的壁垒是入口和生态，全公司都在用它的办公套件，agent 长在里面，分发成本几乎为零。Salesforce 的壁垒是客户数据和记录系统，销售和服务的原始数据在它那里。ServiceNow 的壁垒是流程本身，跨部门的协作规则写在它的系统里。

理解这一点很关键。因为这意味着，企业选谁，很大程度上不取决于谁的模型强，取决于你的数据在哪、你的流程跑在哪、你已经在为谁付钱。

还有一个观察，我觉得挺有意思。你去看这三家的公开材料，会发现模型本身的规格几乎不出现。参数多少、跑分多少，这些在消费级 AI 的讨论里天天见，在企业采购的材料里反而退到背景里去了。

这不是偶然。当客户开始问回报，模型就变成了原材料，跟电、跟带宽一样。原材料是同质的，采购不会为它写长篇报告。真正被比较的，是搭在它上面的东西：流程接得通不通，数据拿不拿得到，账算不算得清。

这也解释了一个现象：同一批底层模型，可以被三家包装成三种完全不同的产品，卖出三种不同的价格结构。差异不在模型，在模型外面那层。

采购

把这三家放在一起，还有一个共同的背景，比产品本身更重要：买单的人变了。

第一阶段的 AI 采购，很多是从创新预算或者 IT 预算里出的。这笔钱的性质是试错，考核的是有没有做出东西，做出来就算赢。

第二阶段不一样。金额变大，agent 真的接手了业务动作，这笔钱就开始往运营预算里挪。运营预算的审核逻辑完全不同：要有回报周期，要有单位成本，要能和外包、和人力、和原来的软件横向比。

CFO 一进场，供应商就得交作业。这解释了为什么 2025 年这几家集中推出的是计量工具、计费方案、分析面板，而不是更炫的模型。技术没有突然突破，是采购流程提出了新要求。

从这个角度看，微软的计算器、Salesforce 的积分、ServiceNow 的平台管理，其实在回答同一个问题：我怎么让我这套东西，进入你的预算表，而且待得住。

待得住这一点常被忽略。一个项目进了预算表，第二年要续，就得拿出去年的成绩说话。这时候，第一年那个估算器算出来的漂亮数字就没用了，得看实际发生了什么。这就是为什么事后观测这一层，长期看比事前估算更重要。

这也带来一个副作用。当采购标准变成可计量，那些不容易计量的价值就会被系统性低估。比如员工体验、比如响应速度带来的客户留存。这些事很重要，但它们进不了那张表。

这里还要提一个现实中的坎，叫试点做完了上不去。很多企业做了很成功的试点，一个小团队用得挺好，但推到全公司就卡住了。卡住的原因通常不是技术，是权限、是数据边界、是每个部门的流程不一样。

这个坎跟回报有直接关系。试点的数字往往最好看，因为范围小、盯得紧、参与者积极。规模化之后，这些条件都没了，单位收益会往下走。所以看案例的时候，问一句这是多大的范围，比看节省比例更有用。

验证

那到底什么样的证据，才算把 ROI 验证了？我把它拆成三层，从下往上说。

最下面一层，是供应商能看见的计量。跑了多少次，用了多少 action，花了多少钱。这一层三家都有，而且做得越来越细。它是必要的基础，没有它什么都谈不上。

中间一层，是客户能自己对照的流程绩效。同一个流程，部署前的处理时长、一次解决率、人工接管比例，和部署后比。这一层需要基线，需要同一个口径，还需要排除同期发生的其他变化。

最上面一层，是扣掉所有成本之后的净收益。省下的人工时间，要减掉许可费、用量费、实施费、集成费，还要减掉每天盯着它别出错的那部分人力。这部分经常被忘掉，但它是真实存在的。

最后这部分值得多说一句。agent 上线不等于人就能减。很多团队的做法是，人还在，但工作内容变成了审核 agent 的输出。这个环节，很少出现在供应商的节省估算里。

还有个更隐蔽的成本，是机会成本。同样这批人、这笔钱，如果不用来上 agent，可能用来做别的改进。这个成本永远不会出现在任何一张账单上，但它是真的。

这三层之间有严格的顺序。下层不成立，上层就没意义。但现实里，很多讨论是从最上层开始的：先宣布一个净收益，再倒着找支撑。这个顺序一颠倒，数字就容易变成装饰。

所以要盯的指标，我认为有三个，而且只有三个。

第一，基线和部署后的指标是不是同一口径，中间有没有混进别的改动。这一条不过关，后面全是空谈。第二，准确率和人工接管率。这两个数决定了 agent 到底是省事还是添乱，接管率高的 agent，省下来的时间会被复核吃回去。第三，把许可、用量、实施、维护全部加进去之后的单位成本，和原来那条路比。

反过来说，几个常见指标单独看都没有意义。活跃用户数只说明有人登录。调用量只说明系统在转。action 计数只说明计费单位在累积。供应商算出来的节省值，同样是过程量。

它们能说明系统在被使用，说明不了业务变好了。这两件事之间的距离，就是整个第二阶段要解决的问题。

这里有个容易踩的坑，跟计费方式直接相关。净收益的分母在变。按 action 计费，意味着成本随业务量浮动。业务量涨，账单涨，节省额也跟着涨。

如果只看节省额的绝对值，会误以为回报在改善。实际上单位成本可能一动不动，你只是做得更多了。所以要比的是比率，不是总额。这一点，在按用量计费的合同里尤其重要。

还有一个反常识的点。成本越透明，越容易做出错误决策。因为看得见的成本会被反复审视，看不见的成本被忽略。结果是，企业可能因为一张 action 账单太贵，放弃了一个其实很划算的自动化。

反假设

讲到这里，得给一个相反的解释。因为它是真的有可能成立的，不给它位置，前面的分析就是单边的。

如果大部分公开的 ROI 数字，都依赖供应商设定的参数、客户自选的样本、还有公司自己的内部案例，而且缺少独立的对照评估，那么所谓采购进入第二阶段，可能不是被验证过的回报推着走的。

真正的推手可能是另外几样东西，而且每一样都更硬。

第一是平台捆绑。你已经在用这套 CRM，或者这套 IT 系统，加一个 agent 模块，比换一套系统便宜太多。这个决策不需要算 ROI，只需要算迁移成本。

第二是数据可达性。你的客户数据在哪，你的工单数据在哪，agent 就只能在哪干活。数据搬家的成本，往往比软件本身贵。

第三是治理需求。公司要求 AI 的动作要留痕、要能审计、要能一键关掉。这个需求来自合规和风控，不来自财务。而能提供这套治理的，通常就是原来那个平台。

第四是议价。采购部门拿三家报价互相压，最后成交价可能比标价低不少。这个过程里，ROI 是个谈判工具，不是决策依据。

这四样东西，都不需要 ROI 被证明，就能推动采购。而且它们是结构性的，不会因为某个产品变聪明就消失。

那怎么区分这两种情况？看合同结构，而不是看发布会。

如果一个客户开始要求用量上限、要求按效果付费、要求不达标可以退出，说明他其实不确定回报。他在为不确定性定价，把风险推回给供应商。

如果客户直接签三年、按席位锁量、按年预付，说明他买的不是回报率，是路线绑定。他要的是确定性，不是回报。

这两种合同都会存在。真正有信息量的，是比例，以及比例在往哪个方向移动。

还有一层原因，让独立审计变得稀缺。做一次严格的对照评估，要花时间、要停掉部分优化、要接受可能为负的结果。供应商没动力，客户也没动力，因为项目已经立项了，谁也不想亲手证明它不值。

回到最开始那个问题。企业买 AI，从问能不能做，变成问省了多少。这个转变是真的，三家公司 2025 年的动作都在响应它。

但响应和证明是两件事。计量工具的出现，说明供应商知道客户要看账。它不说明账已经算平了。

对买方来说，这一阶段的功课其实变简单了，也变难了。简单是因为工具都给你了，数字随手就有。难是因为数字多了以后，分清哪个是过程、哪个是结果，比没有数字的时候更费劲。

最后还有一个变量，我觉得会被低估：组织愿不愿意改流程。agent 要真省事，通常需要把原来的审批环节砍掉几个。但砍环节是政治问题，不是技术问题。很多项目卡在这里，不是模型不行，是没人敢签字。

ServiceNow 在 2025 年 3 月 12 日那份 Yokohama 公告里，写的是数千个 AI agent。下一个该被追问的数字，是这数千个里面，有多少条流程能在同一套基线口径下，把完成率和单位成本同时讲清楚。这个数字出来之前，第二阶段还只是个开场。