SAP的Joule，或许是最有潜力的AI Agent
Mona Zhang
2025年7月31日
企业想要leverage GenAI的能力，需要创建customized的workflows and applications，也就是AI Agent（AI代理）. 根据Open AI的 Gen AI 5个阶段成长路径, 随着基础模型和软件架构（如中间件标准化）的逐步展开，企业将能够释放其在生成式AI上的应用能力。
从LLM的兴盛到现在已经过去了大约3年时间，美欧SAAS公司的AI Agent开始进入密集推出期。这次Trunity Partners将会带大家进入几家主流的SAAS公司(ServiceNow, Salesforce and SAP)推出的企业级AI Agents，从他们的低级架构构建，训练数据，训练方法出发，推导他们未来可能的天花板和能力，并且选出最有希望带企业带来真正价值和给自身带来质变的公司。
背景：
从2024年以来, AI Agent 逐步进入大家的视野，在SAAS公司明确推出各家产品之前（包括ServiceNow的NOW AGENT， Salesforce的Agentforce和SAP的Joule），企业在一些AI vendors（如Accenture）的帮助下自身已经开始做了一些细分领域的尝试，大部分还是基于聊天类的Chat-bot，如优化客服效率等。而可行动的代理中比较有名的是Karna，一家做消费者科技金融的公司。2024年初Klarna 把两年前收集的 200 万条客服对话、退款流程与风险标签喂给 OpenAI 完成企业级微调，并在自家 AWS里托管，其可以处理对话，并且调用内部退款、物流、账单 API来执行任务；上线首月，该助手就处理了 230 万次对话，相当于 700 名全职坐席工作量，平均响应时长从 11 分钟降到 2 分钟，预计全年节省 4,000 万美元客服成本。部分企业在思考是不是自己设计所有的垂类Agent，再用Google提供的Agent2Agent等工具把他们协奏（orchestrate）在一起，但是这其实并不可行，主要是因为：（1）企业本身并没有统一的semantic language layer：企业训练模型的数据本身来源于各类SAAS中沉淀，而这些软件本身的数据和数据结构都是不相同的，哪怕都交给大模型来训练，得到的模型的准确率也不高；（2）大部分企业自训Agent只能处理单一任务，无法跨应用交互（如退货与供应链，财务和CRM系统连接），如果需要连接协作，需要手写多个Agent互动的接口和业务逻辑，开发成本高；（3）运维成本高，企业需要自建observability面板，设计各类监控节点等，缺乏规模效应。
2024年下半年由于受到企业自己探索垂直类GEN AI Agent的威胁，几家大的SAAS公司均宣布了自身的企业级AI AGENT战略（当然有的公司2022年就开始做了，如SAP），包括ServiceNow的NOW Agent， Salesforce的Agentforce和SAP的Joule，而Oracle，Hubspot等公司尚未推出Agent类的功能。随着SAAS公司正式大力推广自己的Agent，企业在SAAS公司覆盖的领域（如ERP,HRM,采购,CRM,ITSM等，其实已经覆盖了企业80%场景）因为高成本，低效率和不能多平台协作等原因失去了自己创建Agent的动机，但是在特定情况下，企业自建Agent的动力还是比较大，包括：（1）企业自建所有的软件（如Google, MSFT, ORACLE, SAP等）；（2）数据主权或模型保密要求极高（国防、药物配方、交易算法），不能接受第三方平台托管推理（3）业务流程离主流 SaaS 很远——例如高频交易、半导体设备调度、基因测序分析，或者是Carrier的IoT数据分析等，现成 Agent 市集里找不到可以满足其需求的产品。
目前OpenAI和Palantir等第三方公司仍然在比较积极地帮助企业客户进行AI Agent设计和落地，但是他们缺乏某个细分赛道的多企业数据（如几千家公司在ERP，CRM等垂类的数据）和业务逻辑，对Agent做训练都十分困难，使得其目前每次拓展案例都类似于做定制化业务，需要所有一切从头开始。就某些特定领域来看，这类第三方公司的起点可能比专属SAAS公司落后5年。而SAAS赛道内，也并不是所有的公司都已经完全准备好，能够抓住机会的公司更多是在过去几年把内部各产品线打通，数据层打通上花了很多精力的公司，并且某些SAAS公司的数据本身并不能拿来训练智能体AI Agent。从这个角度看，OpenAI等公司在这些SAAS公司擅长的领域实际上很难替代他们的存在，也就是说这些数据质量好，公司底层tech debt较轻的SAAS公司在GEN AI时代会得到增加，而不是削弱，这也是投资机会所在。
我们最近主要研究了SAP，ServiceNow和Salesforce三家公司
这三家公司都推出了自己的AI Agent，而Oracle, Hubspot等公司目前还是把GEN AI功能融合在具体产品功能中，还未推出正式的Agent。目前看SAP从2020年开始在新的CEO Klein带领下解决了内部产品孤立，数据库孤立，缺乏统一语义层等问题，而且SAP内部所留存的企业业务数据天生闭环+覆盖面最广，天然最适合训练智能AI Agent。而ServiceNow的虽然一直以来以平台强大，Tech debt几乎没有为优势，但是其因为接触企业业务窄，更加“外围”，且其记录的业务数据不能闭环（业务流程大都最终通向无记录的人工服务），其业务数据用于训练的价值低，很难构建一个Controller，为此公司已经收购了Moveworks来填补自身训练不出center controller的空白，预计2025年下半年完成收购。Salesforce的步伐可能是最慢的，公司过去依靠大量收购进行产品线和功能扩展，Founder在位多年，战略方向摆动，善于收购而不专注于解决产品孤岛的问题，Tech debt最重，并且其底层数据库虽然部分打通，采用的是“数据复制”的模式，而不是原数据模式，导致跨产品延时问题难以解决。
下面我们对三家公司的AI Agent战略进行底层拆解：
Salesforce:
Salesforce 的AI Agent产品统称为Agentforce，其中大脑中控是Atlas reasoning engine。根据专家调研，Agentforce 的价值在于它能整合并激活数据资源，它的整体效能完全取决于数据整合的质量，以及像 Snowflake 这样原生连接的数据湖工具，或依赖 Databricks 做数据清洗。目前Salesforce在数据层的整合做的并不好，虽然公司号称2021-2024年公司完成了内部各个收购产品的底层和数据整合，不过目前仍然还有很大提升空间。
整合效果不佳一方面是因为Salesforce的Tech Debt很重，根据我们与公司专家的交流发现，Salesforce从未将大型并购项目完全迁移进自身核心架构，MuleSoft、Slack、Tableau、Demandware全都独立于核心架构之外。目前Salesforce的整合水平大约是4分（满分10分），然而即使有充足资金，也不可能在短时间内完成所有组件的重构。而哪怕最完美可能Salesforce也只能整合到5分的水平，主要原因是组织文化的问题，CEO Marc Benioff非常随性，关注点常变，战略方向每几个季度就可能改变，导致资源重新分配，今年的Agentforce大转向以及连续几年的大规模裁员就直接干扰了工程团队的长期规划。此外，Salesforce内部的“会议文化”也严重拖慢了效率——初创企业一小时能做的决策，Salesforce可能要一个月。总体来说技术问题可解，文化问题才是存在性风险。
另一方面是，Salesforce的Data Cloud本质是数据副本（Data Copy），而不是一个源数据（Source of Truth），它并不直接读取 Sales Cloud、Service Cloud、Marketing Cloud 等系统中的实时数据，而是通过 ETL（提取、转换、加载）或同步机制，把原始数据拉一份进来，存储在Data Cloud自己的数据模型里，作为后续AI训练、客户细分、营销自动化、Agentforce 推理的基础。基于数据ETL和同步的AI Agent推理过程耗时充满不确定性，可能几分钟，甚至几小时，这导致AI Agent在真实环境中可能完全不可用。
如果从Salesforce的产品发展历史来看，Salesforce Agentforce并非一个独立产品，而是多个旧产品的整合包装。它整合了Einstein、Datorama、Einstein Copilot，并加上Atlas Reasoning Engine 提供的 LLM、NLP 和生成式 AI 功能。从 Einstein 到 Agentforce ，并不源自重大技术突破，而是对市场形势的快速反应，尤其是在 2022 年 11 月 ChatGPT 引爆市场、微软迅速将 OpenAI 接入 Copilot 产品之后。Einstein 的前身是 Salesforce 在 2015-2016年AI 并购潮中收购的Datorama，这本质上是一个分析工具，加上了一个可视化的前端，改名为Einstein Analytics，具备了可视化，分析和基于预设规则的预测的功能。Einstein系统依赖于事先设定的分支逻辑来预测用户行为，例如客户点击某个页面可能会跳转到哪个产品页面。2023–2024 年间，Salesforce 把 LLM 技术加到 Einstein Copilot 上，实现了回答问题的功能，之后Salesforce收购了Airkit.ai，带来了自动处理请求、创建低代码/无代码智能代理的能力，有了这一变化，Salesforce 把Einstein Copilot重新命名为Agentforce，然后推广 “创建你自己的 Agent”的理念。由于这一系列的收购，分装，嫁接等操作，叠加2022年左右外部activities要求公司裁员和节约开支（实际上低margin更多是由于tech debts带来的），关键技术和管理人才流失非常大（这些流失的人后来创立了竞争平台 Sierra.ai），导致用户可以感知到Agentforce的使用体验其实并不佳。Salesforce 目前正试图回聘部分离职人员，重新构建技术、销售、销售工程团队，完成重组，以希望可以加快Agent的底层技术的完善。
从公司文化上来看，Salesforce也很难推出一个性能极佳的Agent。公司过去的关键技术/产品均来源于收购，而这种倾向源于“上市压力”，内部团队本身就无法快速开发新产品。一方面是高层产品团队人员流动性大，很多人把 Salesforce 当作职业跳板，人员不稳定使得很多项目难以落地。而面对这种开发难题，在公司销售导向，市值导向的背景下，也推动公司不断收购新产品，让销售每年都有“新故事”可讲。
从实际使用效果来看，在我们4月的一个专家访谈中得到回复“尽管市场宣传热烈，实际应用却极其保守，在公开场合Salesforce 更喜欢展示那些适合对外发布的AI项目案例以制造声势。但现实中，AI 的主要用途还是在企业内部的ITSM 这类简单的活动。虽然如此，Salesforce还是在积极推进产品落地，2024年Q4供公司制定了一个补贴1000家客户企业快速落地AI的计划，已经使用了多个 Salesforce 云产品的客户优先获得入选资格。
从具体使用情况来看，Agentforce的能力不足之处：
1. 数据
（1）数据编排复杂且容易出错：Agentforce本身不具备强整合能力，必须依赖 MuleSoft、Snowflake、Databricks等外部工具进行数据提取、转换和加载。这种拼装式集成架构造成数据流容易中断，出错率高。
(2）数据延迟：Salesforce在2019-2020年重建customer data cloud，即后来的Data Cloud模块，这算少有的公司内部自己产生的产品，但最后构建的架构却是“UI在核心平台，数据在公有云”的分裂架构，这两个系统间存在显著的结构差异，这导致了严重的响应延迟和技术耦合问题。在多系统、跨平台调用下，数据的传输速度与一致性不足，影响 AI 推理的实时性。这是企业级部署的关键痛点之一。
（3）数据质量因为没有统一标准而没有保障：虽然 Salesforce 在数据安全与权限模型上表现较好，但整合外部数据时很难统一标准，导致“数据有了，但不能用”、“权限分离，授权复杂”等问题。
2. 推理能力
（1）大多数模型仍是基于“问答”的交互逻辑：目前的推理系统偏向信息检索型，缺乏具备意图理解、任务规划和自主执行能力的智能代理。
（2）Atlas Reasoning Engine 尚未成熟：虽然这是 Salesforce 的“AI 控制大脑”，但当前还在“拼装早期阶段”。真正具有 agentic 行为的推理系统需要大规模训练、统一语义层与工具调用逻辑，这在 Agentforce 中尚未实现。ServiceNow通过收购Moveworks来提升“大脑中控能力”。
（3）缺乏上下文记忆与长周期对话机制：推理模型无法很好地记住用户上下文，或在多轮交互中做出持续优化，这限制了 Agentforce 实现“全自动客户处理”或“跨系统任务协调”的能力。ServiceNow通过收购Moveworks来提升记忆能力。
虽然如此，Salesforce的CEO Marc Benioff非常重视Agentforce，认为是关乎公司existential risk的产品。上面说到的这些能力是需要提升的地方，Salesforce目前的tech debt比较大，而且产品底层能力比较弱，再加上CRM领域可能有ServiceNow的竞争，这也是市场给其估值水平低的原因。
ServiceNow
ServiceNow一贯特点是大部分新增扩展功能都来自于平台自建而不是收购，其ITMG，HRSM，CSM和Security Operations等产品天然有深度底层整合，而不像 Salesforce 只是表面整合而仍保留各自为政的架构。这种统一平台的做法是 ServiceNow的一贯作风，使得其能维持一个一致的代码库，从而快速推出新产品，例如 GRC（治理、风险、合规）产品，开发周期仅需六到八个月，而安全运营产品也是迅速推出的案例，显示出平台的高扩展性。ServiceNow大约三分之二的代码在不同应用间是共享的，这也极大加快了产品化速度。ServiceNow在2021年之前的研发费用80%用于平台建设，20%用于新产品开发。2022年开始研发费用80%用于新产品开发，20%用于平台建设。由于长期坚持统一平台战略，ServiceNow 几乎没有技术债务，这让 ServiceNow 架构上更高效，虽然在某些细分领域其无法收购导致了创新速度略慢。
ServiceNow在一个真正的AI Agent推出上最大的问题是ServiceNow留存的客户业务数据大部分是单一规则+无闭环，不适合用于训练Center controller。如在一个用户请求“帮我开一台测试用的 Linux 主机，CPU 要 4 核以上，能跑 docker”，在没有GEN AI的情况下，用户在ServiceNow中首先需要填写一个表单，分栏目提交开设Linux主机的需求，而后ServiceNow会在后台进行一系列的自动化操作，包括检查该用户是否有相关权限、确定虚拟机部署在什么资源池、调用第三方脚本创建虚拟机（由第三方完成），系统监听创建状态是否成功，等待外部返回结果，创建成功或失败后更新任务状态，触发通知（如邮件或 ServiceNow 通知）；整个流程高度依赖于管理员提前配置的流程模板。而之后如果任务失败，系统会进入“等待人工审批”或“异常挂起”状态，需要由 IT 工程师查看日志、手动干预、修复或重新提交任务，ServiceNow的workflows的特征是“出错即停”-转人工，而人工如何处理并未记录在系统中。所以，ServiceNow的这类数据对于AI Controller的训练来说并没有很大的价值。与之相比的是SAP，SAP中留存的数据的特征是用户会尝试多个方法来实现某一目标+闭环，如某个采购员 A 发起一个采购申请，金额较大，但预算科目不匹配，结果是系统自动驳回，这时候他会先拆分订单金额、拆单处理，再用合理预算账户绕开限制，或者通过特殊采购类型（如“库存转移”）重新组织流程，这种“尝试-失败-路径调整-成功”的行为轨迹，在系统中是有明确记录的（审批状态变更、字段修改、调用时间差、异常处理记录等），而这些尝试-失败-再尝试-再失败-最后成功的数据的训练价值就非常高，构成了 Controller 可学习的任务分解策略和 fallback 模式。
除了数据在训练上价值较低的问题，ServiceNow还需要解决前端用户交互层面以及工作流的启动流程等能力的缺乏，为此，ServiceNow在2025年收购了Moveworks来增强其前端能力。
那ServiceNow收购Moveworks就能够解决他的数据方面的问题吗？
答案是不可以，Moveworks 的专长在于构建面向用户的对话式 AI 界面，它可以理解自然语言查询，并通过与后台系统的集成来自动执行简单任务，其定位是“Conversational AI for Enterprise IT Support”赛道，也就是说其业务流程很大一部分最终也转向了无数据记录的人工服务。
首先，Moveworks于2016年开始展开对话式AI Assistance业务，强调的是“通过自然语言入口”完成跨系统事务，他本身是在ServiceNow等软件的上一层，如用户对 Moveworks 说：“我没法登录邮箱”，之后的业务链条是Moveworks 识别意图 → 自动在 ServiceNow 生成 IT 工单 → 填好表单 → 回应用户状态。尽管与下层软件角色不同，但随着 Moveworks 智能水平提高，它确实逐渐具备抽象 ServiceNow 并替代其部分价值的能力，未来可能用户不用再登录ServiceNow的界面，所有流程都通过聊天完成，ServiceNow 被“封装成一个 API 后台”，而对中小企业客户来说，Moveworks + 简单的票务系统足以替代一部分 ServiceNow 功能，而当 Moveworks 能整合多个系统（如 Jira、Workday、Okta）时，它有机会成为跨系统的统一控制台。所以可以看到，ServiceNow收购Moveworks的目的第一是自救，获得Moveworks的AI Agent全领域能力（包括前端语言理解+Controller+跨系统上下文记忆，这些都是ServiceNow如果要培养需要花5年以上时间的）；第二是获得在GEN AI时代下打通其他legacy system的能力，在过去ServiceNow虽然已经构建了几乎与所有系统的“管道连接”，但这些连接是用户在表单界面填写内容，之后根据已经编排的逻辑触发连接，再与其他系统进行交互。
SAP
SAP在推出AI Agent上有天然的优势：（1）SAP以ERP为核心，其内部流程的用户数据类型为用户会尝试多个方法来实现某一目标+闭环数据链条，天生适合用于训练AI Agent；（2）SAP除了ERP以外，还扩展到了HRM,会计,CRM,采购,Marketing等领域，几乎所有业务全部覆盖，拥有最宽的企业内部工作流覆盖面，可以训练出更加智能的AGENT；（3）SAP从2020年开始，在新CEO Klein的带领下完成了各个产品线的整合，解决了product silos的问题，并且将各产品线的底层数据库打通，构建了可以存储结构性数据和非结构性数据的Data Sphere database和打通内部所有产品和外部Databricks的统一semantic layer（所有的数据层合并称为Business Data Cloud），从而可以让Agent在所有数据中无缝穿行和做到语义理解/输出/执行的统一。
SAP 于 2024 年 10 月推出了名为 “Joule AI Agents” 的人工智能代理，覆盖财务、客户服务和销售等领域，具备自动化和优化业务流程的能力。这些能力已超越传统的摘要、内容生成和引导式问答，而能够执行如数据提取、报告生成和基础流程触发等任务。进入 2025 年，SAP 持续将 Joule AI Agents 拓展到 ERP、支出管理和人力资源等关键企业领域。目前，Joule 已支持部分可执行操作的 AI Agent、即用型代理、自定义代理构建工具、代理之间的协作能力以及业务流程集成功能。SAP 还计划在 2025 年第三季度和第四季度正式发布统一的 AI Agent 中心（AI Agent Hub）以及自定义技能构建器（custom skill-builder），这标志着其正加速迈向更具自主性、可实际执行任务的智能代理体系。
SAP的AI Agent战略不纠结于底层LLM是哪一家的模型，其核心战略在于训练好Center Controller（Joule Reasoning Engine）。SAP训练Joule的方法如下：
1. 准备好semantic layer（语义层）：不仅要打通各个不同产品的数据库，还需要对其数据格式等进行统一，此外还需要对各个不同的数据之间建立有关的映射（如“某个销售订单”可链接至对应的客户、库存、应收）。具体来看SAP对来自超30,000家客户的授权业务数据，经过脱敏处理，形成统一结构，包括主数据（如客户、供应商、员工、成本中心等），交易数据（如采购订单、发票、审批状态等）和行为轨迹数据（如用户在系统内的点击、调用、修改、审批路径）。
2. 建模workflows（如创建采购申请，审批预算，销售订单变更），每一个workflow包含四个部分，包括触发意图（用户输入的自然语言，转为业务目标），所需上下文（涉及的业务对象，如物料、供应商、科目），过程状态（按时间线记录所有审批、失败、修改、回滚路径），不同决策路径（不同路径尝试之间的依赖、顺序与优先级），SAP把这些workflows，训练出Joule controller如何一步步解决问题的能力。
3. 多路径尝试与异常处理学习，SAP ERP 系统的关键价值在于“失败后的行为也被记录”，例如，某个采购员发起了一个大额订单，系统因预算不匹配拒绝了，他随后将订单拆分、改用其他科目，最终绕开了限制，这一系列操作都被系统记录了审批流、字段变更、失败时间、调用接口等。这些数据为 Joule 提供了真实的 路径调整逻辑。
4. 与LLM协同训练，主要是为了调用LLM来完成具体任务，包括文本生成，问题生成，文案生成，和异常分析，让LLM更加个性化地适用于企业业务场景的需求。
5. 知识图谱融合，这一步是为了让Joule Agent更加智能，让员工在与其交互的时候Agent可以直接调用已经储备的知识图谱（来源于底层数据库），如当员工Q&A某个销售订单的时候，Joule能够自动映射到订单所属于的客户，信用等级，收款账户，负责人员，权限等一系列数据；如审批某个销售合同，Joule会直接联系到相关其他需要进入这个流程的人（一定程度上可以替代ServiceNow）
因为SAP已经拥有了大量的高质量数据，以及CEO Klein做的整合，打通的准备工作，让Joule能够快速推出，并且拥有极好的底层架构和牢固基础。从时间线上来看，Joule的推出花了大约20个月，分为4个阶段：（1）2022年中：SAP 开始准备 AI 的底层平台，包括数据打通、数据库搭建、搭“AI平台”，同时准备可以用于训练的workflows。（2）2023年初：SAP 正式启动 Joule 的训练，把各种workflows（成功的、失败的、绕道处理的）拿来做训练，还开始搭建 Joule 的大脑框架。（3）2023年9月Joule 第一次正式上线，嵌入到了 SAP 的核心产品里，包括ERP, HR, Finance，采购等。（4）2024年初Joule 已经学会处理超过 100种常见的业务场景（比如采购申请、员工转岗、发票审批等），而且如果失败了还能换一种办法继续尝试，不会轻易“卡住”（5）2024年中，Joule 不再只支持采购、HR、财务等常见流程，而是开始支持制造、销售、供应链、IT运维等更多模块。（6）截至2025年Q1，管理层表示“With more than 1,300 skills in 130+ use cases, Joule has the capability to automate 80% of the most common tasks SAP users perform every day”，例如将预算和预测任务的完成速度提升了高达 80%，通过 AI 驱动的洞察将市场竞争分析速度提升 90%，帮助用户快速查找采购数据，将信息查询处理速度提升 95%。
从Joule Agent对SAP整体收入角度来看，Joule 功能目前被打包进 RISE Premium Plus套餐内，不以单独产品售卖。过去5年SAP的主要增长动力来自于更多传统ERP用户转向Cloud，目前整体客户转运已经过半，而随着Joule的推出，只有转云完成，并且购买SAP更多SAAS产品（如CRM,HR,财务，采购）的客户才能够更高效地使用Joule Agent的功能，相信Joule的推出，将会比较大的推动SAP的未来5年的收入增长。
免责声明：本文仅供参考和教育之用，不构成财务、投资、法律或税务建议。文中表达的观点仅代表我个人，并不一定反映Trunity Partners Ltd.或其关联公司的观点。任何对特定资产、历史事件或个人的提及均仅供参考，并不代表对未来表现的认可或预测。读者在做出投资决策前，应自行进行尽职调查或咨询持牌顾问。
