今年Salesforce大会现场演示环节，一名销售人员没有打开CRM，而是直接问Claude：这笔交易有什么风险？

Claude调取Salesforce及经过授权的邮件、日历和Slack信息，很快发现客户需要的200个VIP席位中有50个尚未落实。销售人员确认方案后，Claude随即更新业务方案、起草客户邮件，还生成了新的工作界面。

整个过程中，Salesforce几乎没有出现在屏幕上，却参与了完整的任务。

这指向一个重要变化：用户可能越来越少进入企业软件界面，却更频繁地调用界面背后的数据、规则和执行能力。

那么，当Agent开始掌握用户入口，SaaS接下来要守住什么？

图1：Claudeforce用户登录界面

爱分析判断，SaaS的界面、通用功能和浅层领域知识的价值将持续下降，核心壁垒将转向企业Know-how，以及定义、执行、治理和持续积累这类Know-how的能力。

一、Agent正在把入口与业务系统分开

过去，AI功能通常被嵌入软件界面，用户仍要打开原系统，而软件的产品入口没有改变。

Salesforce此次发布的AIforce，是一套让企业数据、对象关系、业务规则、权限和可执行动作能够被外部Agent调用的平台能力。以Claude为代表的外部AI入口，通过MCP、API和Skill连接Salesforce：模型负责理解需求、推理和交互，Salesforce负责提供企业上下文、权限、流程和可执行动作。

用户看到的是Claude界面，但Claude并不知道企业的客户是谁、商机处于什么阶段、什么人有权修改合同。模型只有接入企业长期积淀的业务上下文和执行能力，才能从回答问题走向完成工作。

除了Claude，Salesforce正在把这套能力开放给更多外部Agent和工作入口。对于Salesforce而言，入口虽然转移，但产品价值仍保留在每个任务背后，成为Agent读取企业事实和执行关键动作所依赖的业务系统。

此次主动向外部Agent开放能力，Salesforce争夺的已经不是用户停留在哪个界面，而是谁承载企业业务的核心逻辑。

Salesforce in Claude目前仍处于Beta阶段，但战略方向已经清楚：入口可以交给外部Agent，关键业务能力必须继续由Salesforce承载。

二、SaaS要守住的，是被软件化的企业Know-how

如果Agent可以生成界面、调用API，也掌握大量行业知识，企业软件的护城河还剩什么？常见答案是数据或语义层，但这两个答案都不完整。

数据记录企业发生了什么；语义告诉人和Agent，客户、合同和订单分别意味着什么，它们之间是什么关系，收入采用什么口径。没有这些定义，模型即使连接数据库，也很难正确理解企业。

图2：企业Know-how的三层构成

但理解数据和语义，不等于完成工作。Agent还需要三类Know-how：第一，企业认可的业务对象、指标口径和上下文；第二，流程状态、规则、权限、业务例外和异常处理；第三，历史决策、执行结果和人工纠正记录。前两类决定任务能否正确执行，第三类决定系统能否越用越懂企业。

例如，Agent知道退款金额的定义，但不代表它知道什么情况下可以退款、超过多少金额需要谁批准，以及退款失败后如何恢复订单状态。语义是Know-how面向Agent的重要接口，但不是Know-how的全部。

不同类型Know-how受到AI冲击的程度也不同。

通用知识和标准流程更容易被基础模型吸收，长期来看更容易被商品化；企业专有的对象关系、指标口径、流程例外和权限体系需要长期治理，更难复制；如果实时数据和执行结果还能持续影响下一次判断，就会形成进一步的积累效应。

不过，Know-how不会因为被装进企业软件就自动成为壁垒。如果规则仍在员工头脑中，流程依靠口头协调，异常处理散落在项目文档里，软件拥有的只是记录而已。过去可以由员工和软件实施顾问补齐的断点，在Agent独立执行任务时必须被明确表达、调用和治理。

所以，Agent时代真正受到冲击的，是依靠界面、通用功能和浅层知识形成的价值。企业软件能否继续成为业务底座，取决于它是否真正编码了企业运行方式，而不是是否拥有一个名为语义层的产品。

三、Salesforce开放Know-how的使用，但保留控制

AIforce并不是把数据库和业务逻辑完整交给Claude，而是提供一条受身份、权限、Skill和任务范围约束的调用路径。外部Agent可以获得完成任务所需的最小业务上下文，并调用经过授权的工具和动作；Salesforce则负责权限校验、流程执行、关键动作记录和结果回写。

从作用上看，Salesforce为外部Agent提供的是三层能力。

第一层是定义业务上下文：Data 360、Customer 360和元数据体系，把客户、合同、订单、业务关系和指标口径组织起来，让Agent理解企业正在处理什么。

第二层是执行业务动作：MCP和API提供连接与调用入口，Flow、Apex和Action负责读取信息、更新记录、发起审批和推进交易，让Agent不只回答问题，还能完成经过授权的业务操作。

第三层是控制并积累结果：身份、权限、日志、审计、异常处理和人工纠正，决定Agent能做什么、记录做了什么，并将执行结果和修正持续沉淀回平台。

这些能力共同服务于一个目的：让Salesforce积累的企业Know-how可以被外部Agent使用，同时由Salesforce继续负责企业事实的定义、关键动作的执行、过程控制和结果积累。

图3：开放调用回流结果形成的Know-how壁垒

爱分析认为，AIforce的核心是一种“开放使用、保留控制”的平台策略。Salesforce让出部分界面控制权，是为了让自身能力进入更多入口，同时避免平台退化为普通数据库。

不过，开放并不等于壁垒已经形成。随着MCP、Skill等接口逐渐标准化，单纯能被Agent调用很快会成为标配。支持多个模型，也不代表不同模型下的体验、成本和效果完全一致。

更关键的是，公开演示和客户案例目前主要证明Agent能够进入业务流程，尚未完整回答任务成功率、人工纠正率、事故成本和长期ROI。如果Agent执行后仍要依靠大量人工收尾，或者产生的结果没有沉淀回业务系统，开放接口本身就无法带来持续优势。

Know-how要在开放调用后形成护城河，有一个明确前提：每次调用不仅完成任务，还要留下可治理的业务记录，并持续改进数据、规则和下一次决策。只有形成这样的闭环，这类Know-how才会越用越深。

四、中国SaaS要把项目Know-how变成Agent资产

对中国企业软件厂商来说，Salesforce的启示不是照着再做一套AIforce，而是重新审视自己已经积累的Know-how。

国内ERP、CRM和协同办公等软件厂商，长期服务复杂行业和大型企业，并不缺流程、规则和实施经验，但这些Know-how往往散落在产品配置、项目方案、顾问经验、客户制度和员工协作中。

过去，实施顾问可以在不同系统和流程之间补齐断点，但是Agent要独立完成工作，这些隐性经验必须先变成机器能够发现、理解和执行的资产。

国内部分厂商已经开始提供企业本体、Skill、流程Agent、权限控制和审计能力，第三方AI入口也可以通过连接器调用这些服务。但这还不能说明Know-how已经形成可迁移的Agent资产，真正需要验证的是：这些Know-how能否跨出自有界面，被第三方Agent稳定调用，并由核心业务系统持续控制和积累。

沿着这条主线，国内软件厂商需要完成三个转变。

第一，把项目经验变成结构化资产。从顾问头脑和项目文档中抽取业务对象、指标口径、流程、规则和异常处理，区分可以跨客户复用的行业Know-how与必须由客户专属治理的企业Know-how。

第二，把软件功能变成可治理的调用能力。API只说明系统能够做什么；Skill和Action还要说明何时调用、需要什么权限、什么情况下必须人工确认，以及失败后如何恢复。只有这样，Know-how才能被Agent正确使用，而不是被简单暴露。

第三，让执行结果持续积累并形成新的商业模式。每次Agent执行都应留下结果、人工纠正和异常记录，反哺下一次判断。厂商衡量的重点指标也要从上线多少Agent，转向安全完成多少业务流程、减少多少人工纠正、产生多少可核验价值，再据此探索调用、任务或结果计费。

爱分析判断，中国SaaS下一阶段的竞争重点不是再增加一个AI对话框入口，而是把过去沉淀在产品和项目中的企业Know-how，转化为第三方Agent可调用、企业可控制、使用后可积累、厂商可计价的生产级资产。

从Salesforce的平台演进来看，它让出的只是部分交互入口，真正想守住的，是企业Know-how的定义、执行、治理和积累。对所有SaaS厂商来说，这比守住一个界面更重要。