Salesforce 为自家智能体配上了能跑数周的运行时

10 月 5 日，Salesforce 在迪拜和利雅得发布了一系列新的 Agentforce 智能体，而大多数报道都把焦点放在了这份名单上。Casey 通过语音、短信、WhatsApp 和网页聊天处理客户服务。Paige 负责解决 IT 和人力资源方面的请求。Carter 帮助购物者在聊天中比较产品并完成结账。Piper 负责筛选入站线索。Marshall 编排后台流程并留存审计记录。Fin 负责运行复杂的客户体验工作流。Hunter 则承担从调研到触达的外呼销售工作。

这份名单恰恰是最无趣的部分。真正的看点在于其底层：一个全新的长周期运行时，它让智能体能够围绕一个目标持续数天乃至数周，而不是在单次交互结束时戛然而止。

这与企业级 AI 一直以来所售卖的产品，属于完全不同的品类。

回答与完成之间的差别

对话式助手解决一个问题后便结束这一轮对话。而运行在长周期运行时上的智能体则会接收一条指令，将其转化为可衡量的目标，制定计划，然后朝着目标推进，同时判断哪些任务需要完成、需要哪些工具，以及在哪些环节必须停下来等待人工介入。

Salesforce 给出的例子是：销售向 Hunter 下达指令，要求在季度结束前挽回有风险的商机。Hunter 会把这转化为一份计划并开始执行，在预设的节点暂停以等待销售人员批准。

有三项机制使这一切成为可能。记忆（Memory）在跨会话的场景下保留上下文与进展，因此周一接手工作的智能体清楚自己周五做了什么。持久化执行（Durable execution）让计划持续运行，并允许智能体在情况变化时恢复或调整。动态引导（Dynamic steering）则根据单个用户的反馈调整行为。

第三项正是设计中最有意思的地方。一个运行数周的智能体会累积大量决策，其中大多数都会在细微之处出现偏差。如果唯一的反馈渠道是那种会重置计划的纠正，那么这个智能体就谈不上持久。引导意味着智能体在运行途中调整行为，而不是重新开始。

治理问题被推到台前

智能体在无人看管的情况下运行得越久，责任归属问题就越重要。

Salesforce 的答案是双层的。凡是需要批准或判断的地方，人类都保持参与，这是常规的护栏。在其之下，Agent Script——一种用于描述智能体行为的开源语言——让企业能够将 AI 推理与确定性规则结合起来。其目的在于对智能体如何做出决策进行细粒度控制，这样一来，必须遵循政策的部分就可以写成政策，而不必靠学习得来。

一切都运行在客户既有的权限和业务规则之内，每个智能体都带着企业赋予它的名字。其表述是：智能体成为品牌的延伸——这实际上是一套营销话术在承担合规的活儿。

审计记录在这里同样重要。据描述，Marshall 会为每一个动作提供记录。对于一个跨越数周、涉及多个系统的流程而言，审计轨迹是人类主管无需重放整个过程就能复盘发生了什么事的唯一途径。

Salesforce 所指向的证据

该公司报告称，Agentforce 与 Slack 合计产生超过 70 亿个智能体工作单元，其中最近一个季度就有 32 亿个。具体的客户也被逐一点名：Perk，其销售管道中有 60% 现在由外呼智能体生成；Autism Queensland，其 70% 的行政请求由 Paige 解决；Hibbett AI，六周内上线，如今处理 90% 的核心购物旅程。

Hibbett 这个数字值得细品。一个零售部署能在六周内覆盖 90% 的购物旅程，这是在宣称配置速度，而配置速度正是企业级智能体项目历来折戟的地方。它们大多卡在集成环节，而不是能力上。

被点名的客户也经过挑选，以表明某种买家取向。一个销售管道生成指标，是说给销售负责人听的。一个行政请求指标，是说给公共部门或医疗健康行业买家听的。这些案例研究本身就是市场细分。

与记录系统的连接，才是真正的护城河

这些智能体基于 Customer 360 运行，这意味着它们能利用企业在 Salesforce 中已有的客户上下文、数据和业务流程来运作。

这是一种伪装成技术细节的分发优势。竞争对手可以做出一个能进行外呼调研的智能体。但要做出一个已经掌握客户历史、未结商机和支持工单的智能体，则是另一回事，而这对没有底层记录的厂商来说是做不到的。

取舍之处也是老生常谈。靠近记录系统带来的任何收益，都伴随着对它的依赖；而一家把销售智能体跑在 Agentforce 上的企业，其 CRM 选择的更换成本也变得更高。

它与其他常驻型智能体有何不同

Salesforce 并不是唯一一家推出无需提示即可运行的智能体的公司。

OpenAI 的 Dots 围绕用户定义的目标在后台持续运行，连接数千个应用，每个智能体都跑在自己的私有云计算机上。Meta 的 Muse 智能体也采取类似定位。共同的想法是：智能体持有的是一个目标，而不是回答一个问题。

Salesforce 版本的差异在于起点不同。Dots 从一个目标和一组已连接的应用出发。Agentforce 则从一条客户记录、一个案例、一个商机或一笔订单出发，因为它绑定在 Customer 360 上。这收窄了智能体能处理的范围，却加深了它对处理对象的了解。

对企业而言，窄版本往往更有用。一个什么都碰得到的通用智能体，比一个只在企业已经治理的系统内部工作的专用智能体更难获得授权。权限模型是继承来的，而不是新造出来的。

持久化之下的定价问题

一个把计划持续挂着一个月的智能体，其成本产生方式与请求—响应模型截然不同。

计划状态的存储、跨会话的记忆、针对一个理应在需要审批时发出告警的智能体所做的监控，以及模型调用本身，都会计入一个可能产生结果、也可能不产生结果的工作流之中。对话式助手的成本按轮次计量。常驻型智能体的成本则按时间单位和工单量计量。这两个数字对不上，这正是为何点名客户比功能清单更重要。Perk、Autism Queensland 和 Hibbett 描述的都是财务团队早已能够定价的成果：生成的销售管道、解决的行政请求、处理的购物旅程。一个替代已知成本的智能体容易证明其价值；一个创造出全新成本类别的智能体则不然。

值得关注什么

有三件事将决定长周期运行时究竟是一个产品，还是一场演示。

第一是长时间跨度下的失败行为。一份在两个月里逐渐跑偏的计划，比一次会话内就失败的计划更难诊断，而 Salesforce 并未说明当智能体在追逐一个早该在数周前放弃的目标时会发生什么。

第二是 Agent Script 能否在 Salesforce 之外被采用。一种描述智能体行为的开源语言，只对留在该平台上的客户有用。如果它可以移植，就会成为标准；如果不能，它就只是一种配置格式。

第三是持久化的价格。一个把计划挂着一个月的智能体消耗存储、记忆和监控资源，而这些都不会出现在按 token 计费的对比中。常驻型智能体的单位经济模型不是请求—响应模型的单位经济模型，而 Salesforce 并未公布它究竟按哪一种收费。

该公司所采用的说法——这些智能体是凭它们完成的工作、而非回答的问题来评判的——设定了一个高于行业以往所受的标准。它也让衡量变得简单：那些有风险的商机要么关单了，要么没有。