深入解析 Salesforce 的智能体技术栈

ByteByteGo Newsletter 2026-10-27T09:55:08.816165

只有 30% 的 AI 智能体试点项目真正进入了生产环境。差别在哪？(赞助内容) Datadog 的免费电子书讲清了：能让智能体落地的项目和卡在试点阶段的项目，区别到底在哪里。剧透一下：关键不在模型，而在持久化执行、记忆管理、评测流水线和可观测性。你会学到：识别让智能体项目在上线前就夭折的四种失败模式；构建评测流水线，让你在生产规模下信任并治理智能体；为智能体工作流加上可观测性，以便调试生产环境中的非确定性行为；衡量能向团队和管理层证明智能体投资回报的关键先行指标。下载电子书

Salesforce 的智能体已经完成了 70 亿次“智能体工作单元”（Agentic Work Unit，AWU）——这是该公司用来统计 AI 智能体完成工作量的单位，覆盖 Agentforce 和 Slack。其中 32 亿次来自第二季度。但让智能体稳定遵循指令，确实是个难题。

Agentforce 是 Salesforce 用于构建和运行智能体的平台。它的第一版把所有指令塞进一个很大的提示词里。随着规则越堆越多，模型开始跳过一些重要规则。对用智能体面试候选人、处理患者数据的客户来说，这没法接受。于是 Salesforce 换了新设计：一套多层系统，把确定性代码和推理模型结合起来，最大限度保证可靠性。

为了弄清这套系统怎么运作，我们在 Dreamforce 2026 上见到了两位主导者：Salesforce 总裁兼 CTO Muralidhar Krishnaprasad（MK），以及 AI 应用开发平台产品管理高级副总裁 Khushwant Singh。感谢 MK 和 Khushwant 与我们分享细节。

本文将带你了解以下内容：

• 为什么仅靠提示词（prompting）的简单设计并不可靠
• 如何把确定性代码和概率性推理器结合起来，提升可靠性
• 如何构建一个支持身份解析的数据层，把多个系统里的记录关联成统一的用户档案
• 如何构建高效的上下文引擎（context engine）
• Agent Identity 如何让 agent 拥有自己的权限
• AIforce 和 Headless Toolkit 如何让 Slack、Claude 等工具里的 agent 访问 Salesforce 的数据和操作

简单的设计：一个大提示词

构建 agent 最简单的方法，就是把所有内容写进一个提示词。大多数团队做第一个 agent 时都是这么干的。

假设你在为一家医疗公司做客服 agent。你可以把业务规则写成自然语言说明（比如：只能讨论患者本人的记录），再加上可用工具的描述（比如「获取预约安排」），还可以把患者数据之类的相关信息一并塞进去。然后 agent 把这一切都放进 LLM 的上下文窗口。整个设计就这么多。剩下的，就指望 LLM 自己「做对的事」。

在这种简单设计里，模型要同时处理四件事：1）执行规则；2）在不同系统之间找到用户是谁；3）把模型可能需要的数据放进去；4）确保 agent 只做它被允许做的事。

Agentforce 的第一个版本就是这么做的。据 MK 说，团队不断往里加指令，比如「只做这个」「只做那个」「先获取所有预约」。团队注意到一个有意思的现象：指令不超过八条时，效果还不错；一旦超过八条，模型就会丢掉一些指令。

可模型为什么会丢掉指令？因为在模型看来，指令未必是规则，它只是上下文里的一段文字而已。没有任何机制能保证指令一定被遵守。而且，往上下文里加的指令越多，模型遵循指令的能力也会越差。这不是 Salesforce 独有的问题。

有一项叫 IFScale（指令遵循基准）的测试，给 20 个模型分别输入最多 500 条简单指令，看它们能遵守多少条。结果即使是最好的模型，在满 500 条时也只遵守了 68%。这说明提示词只能"试图"塑造大语言模型（LLM）的行为，并不能强制它照做。那么 Salesforce 在模型之外搭了什么来补这个缺口？下面就看 Agentforce 是怎么设计的。

Agentforce 是怎么搭起来的

Salesforce 的新设计思路是：把原来全塞进提示词里的四件事拆出来，各自交给专门的系统去管。为了看清这些系统分别在哪儿，先梳理一下 Salesforce 现有的平台架构。整个架构自下而上分四层：

• 数据层：把企业各个数据源整合成一个统一视图。Salesforce 称之为 Data 360。
• 应用层：面向销售、服务、营销的业务应用，它们提供智能体可以调用的动作。Salesforce 称之为 Customer 360。
• 智能体层：智能体在这里定义和运行。Salesforce 称之为 Agentforce。
• 交互层：人和智能体对话的入口，比如 Claude 聊天窗口或 Slack。

与其把所有事情写进提示词、指望模型全包，不如让每件事由某一层里的专门系统分别处理。举例来说：在智能体层，一门叫 Agent Script 的脚本语言负责强制执行规则；在数据层，身份解析（identity resolution）负责找出客户的统一档案；Agent Context Engine 是一个独立系统，决定哪些数据能送到模型面前。模型只负责需要推理的那些步骤。

接下来逐一介绍这四个各管一摊的系统。为了讲得具体，我们跟着 MK 分享的那个演示走一遍。演示里的公司是一个模拟的医疗机构，名叫 Cumulus，患者叫 Harper Clark——不过按 MK 的说法，这套东西背后跑的都是生产环境。

1. 用 Agent Script 实现确定性指令

第一件该从提示词里拿出来、单独处理的事，是强制执行规则。每一轮会话都要做很多检查，而这些检查完全可以确定性地执行。指望模型来管这些，既没效率也不可靠。

另一个系统可以直接运行代码，更可靠地强制执行这些规则。这就是 Agent Script 的任务——Salesforce 专为描述智能体行为而打造的语言。据 MK 介绍，团队从去年开始着手开发它，起因是 Agentforce 的第一个版本撞上了指令上限。它是开源的，看起来几乎和 Python 一样 [x]。

它怎么运作？你只需在 Agent Script 文件里写清智能体的行为。这个文件会被编译成一份结构化规范，称为 Agent Graph（智能体图），再由 Atlas Reasoning Engine（Atlas 推理引擎）执行——也就是 Agentforce 背后的运行时 [x]。引擎负责运行代码部分，只在需要推理时才调用模型。

想更好理解，可以拿它和 SQL 触发器对比。触发器是数据库在更新某一行之前或之后自动运行的代码，发起更新的应用无法跳过它。Agent Script 走的是同样的路子。

用一个具体例子来对比朴素设计和 Agent Script。假设 Harper 提问：「我和 Perl 医生的下次预约是什么时候？」在朴素设计里，提示词写着「务必先获取预约记录」，然后我们指望模型照做。而在 Agent Script 里，这次查询就是医疗预约子智能体 before_reasoning 块中的一行代码。正因如此，它每次都能可靠执行。

把各个环节拼起来，Harper 提问后发生的事是这样的：

1. 模型选中医疗预约子智能体。
2. before_reasoning 块运行（预约查询以代码形式执行）。
3. 引擎构建提示词。
4. 模型收到提示词并写出回答。
5. 最后，after_reasoning 块执行。如有需要，它也可以把对话转交给另一个子智能体。

这种把确定性任务和推理部分分开的做法，让系统保持可靠。模型只专注于对代码准备好的上下文进行推理，而不去管获取预约记录或者回复之后该做什么这类事。

确定性指令能提升可靠性，但也不该到处都用。

最佳实践是：需要行为可预测的部分（比如条件判断）用代码写，需要真正推理的部分才交给自然语言。

2. 用 Data 360 打造统一画像

第二套系统负责回答「客户是谁」。Harper 的预约查询看起来只是简单查一下，但预约数据可能根本不在 CRM（客户关系管理）系统里。它可能在 Snowflake 这类云数据仓库里。而且 Harper 这个人可能在多个地方重复出现，如下图所示。

一种做法是把不同的记录列表交给模型，让它判断哪些是同一个人。但这会成为不可靠的来源。更好的办法是用一个数据层，分三步来处理。

第一步：打通数据。 Agent 需要的数据通常不在同一个地方。数据层连接各种数据源，直接从中读取。这样 agent 拿到的始终是最新的记录视图。为了演示，MK 在 Snowflake 里改了 Harper 记录上的保险计划，这个改动立刻得到了反映。

第二步：统一（Harmonize）。 不同数据源对同一条记录的看法可能不一致。比如，一个系统把完整姓名存在单个字段里，另一个系统却把它拆成两列。数据层会把每个数据源映射到同一套共享数据模型上，模型里包含 person（人员）、lead（线索）、account（客户账户）等通用对象。据 MK 说，这个映射是自动的，能覆盖成千上万个数据源。

第三步：识别身份。 这一步处理不同数据源的记录描述的是同一个人的情况。在 Data 360 里，靠管理员配置的匹配规则（match rules）来完成。规则可以是精确匹配（比如邮箱地址完全相同），可以是允许细微差异的模糊匹配，也可以是先清洗字段再比较的规范化匹配。这样一来，两个写法不同的电话号码也能匹配上。注意，源记录本身不会被改动，输出的是一个统一画像（unified profile），它能链接回每一条源记录。

经过这几步，需要 Harper 的预约时，直接从统一画像里取就行，不用再让模型去猜 Harper Clark 到底是谁。

3.

用 Agent Context Engine 获取相关上下文

第三项任务是决定哪些数据该放进提示词。要是把所有东西都塞进去，不仅会增加延迟，还可能把真正相关的事实给淹没。所以必须在数据和提示词之间放一个上下文管理系统，由它判断一个问题到底需要什么。这就是 Agent Context Engine（ACE，Agent 上下文引擎）的活儿，它是 Data 360 的一个新组件。

这个上下文引擎分六步处理请求：

• 解析（Resolve）：确认用户、Agent、目的，以及问题涉及哪些实体。
• 规划（Plan）：决定去哪儿找这些信息（比如关系型查询、用户画像、搜索索引）。
• 调和（Reconcile）：按某种标准给结果排序，比如相关性、权威性、新鲜度。
• 治理（Govern）：套用规则，比如访问权限、脱敏、授权同意。
• 编译（Compile）：生成最终上下文，其中包含工作状态、记忆等内容。
• 学习（Learn）：判断这次交互中哪些该记住或更新。

MK 拿它和一个「朴素版」保险客服 Agent 做了对比。朴素版没有任何上下文管理，用户问一句「给我看看我的保险计划详情」，Agent 就从各种数据源里拼命拉数据，最后堆到 124,000 个 token。用上上下文引擎后，同一个问题只用了 9,000 个 token。接着用户又问了一句要搬到佛罗里达，这时朴素版会话两轮问题就烧掉了约 300,000 个 token；而带上下文引擎的会话，在处理一个投保流程的第三步之后，也才用了 65,000 个。两套设计的差距随着对话推进越拉越大，这也说明上下文管理必不可少。

那上下文引擎到底怎么挑该发什么？实际操作里有不同做法。一种是客户的用户画像以图（graph）的形式常驻内存，图里的节点就是人、保险计划这类东西，然后只挑出跟问题相关的节点。文档也可以用类似方式过滤。比如 Harper 问「什么生活方式最适合我？」，三个索引会从几百份文档里挑出相关段落——这三个索引分别匹配精确词、语义含义、以及关联实体（这套做法叫 GraphRAG）。上下文引擎也能处理记忆。

例如，客户问完佛罗里达的问题后，系统可以记一条备注：这位客户可能要搬到佛罗里达。MK 指出，这只是一条记忆，还不是事实。只有客户真的完成了注册，它才成为事实，而且只有经过批准的事实才会被提升为长期记忆。不管怎样，模型每次看到的，都只是公司掌握的该客户信息中一小块当前切片。

4. 用 Agent Identity 做权限管理

最后一项工作是确保 Agent 只做它被允许做的事。目前大多数 Agent 方案里，Agent 都是以用户身份行事。假设 Alex 是一名销售，他把一个 Agent 接到 Salesforce 上。这个 Agent 拿到 Alex 的凭证，就能做 Alex 能做的所有事。这种设计并不理想：Agent 拿着 Alex 的完整凭证，一旦出错就是真问题。人有很大的权限，但至少受工作速度限制；Agent 没有这个限制，它可能犯一次错，然后反复犯很多次。

用 Khushwant 的话说，客户想要的是：“这个 Agent 代表 Alex 工作，但我不希望它有和 Alex 一样的权限。”

解决办法是给 Agent 一个自己的身份。Salesforce 本来就通过权限集控制用户能做什么。新系统 Agent Identity 让管理员也能给 Agent 附加规则和权限，这样每个 Agent 都有唯一的身份和唯一的权限。有了 Agent Identity，Agent 认证时会有两个令牌：一个属于 Agent，一个属于它代理的用户。执行操作前，Salesforce 会检查用户的权限、Agent 的权限和数据策略，三者都不拒绝，操作才会执行。

Agent 在哪里运行

到这里，我们看的都是可靠的 Agent 平台内部发生了什么。但使用 Agent 的人可能在别的地方工作，比如 Slack 或 Claude。有些公司干脆在别的平台上构建自己的 Agent。客户通常希望 Salesforce 到用户所在的地方去。做到这一点的方法，是把平台和它自己的界面分开。这样构建的软件叫无头（headless）架构。

它不依赖自己的用户界面，而是通过 API 把功能开放出来，供其他界面调用。为此，Salesforce 开发了一个实时接口层，名为 AIforce，把平台的数据、工作流和逻辑带到用户和智能体（Agent）实际工作的地方。外部智能体要使用无头平台（headless platform），需要满足几个条件。第一是 API，即平台开放的功能接口。第二是技能（skills）。API 只告诉智能体可以调用什么，但不会说明完成一项任务需要哪些调用、按什么顺序调用。技能正好补上这个缺口：它列出相关 API、各自的参数以及步骤顺序。第三是 MCP（Model Context Protocol，模型上下文协议），这是一个开放标准，服务器发布工具列表，智能体可以按列表调用。Salesforce 为 AIforce 开发了一整套底层构件，命名为 Headless Toolkit，上述能力都由它提供。Salesforce 的 API 每天已经处理 96 亿次调用，其技能发布在公开的 GitHub 仓库 sf-skills 中。

另一个问题是工具数量。MCP 让向智能体暴露工具变得很容易，但智能体能调用的每个工具通常都会以定义的形式加载进上下文窗口。这些定义可能包含名称、描述和参数结构。每次向模型发送请求时，这些定义都会一并发送，成本很高。当工具有数百个时，它们会占用很大一部分上下文，而智能体很少用到这些定义。常见的解决办法是只建一个小型工具索引，而不是把所有工具都放进去。智能体先搜索自己需要什么，再读取找到的工具详情，最后执行。Salesforce MCP Server 就是这样工作的，只用了四个工具。

假设你在 Claude 中使用 Salesforce 插件，要求它找出过去 100 天里最好的 20 个商机。这个请求会经过三步：Claude 先调用 “discover”，并带上它对请求的理解；服务器在一个包含可用 API 和技能的索引上做语义搜索，返回一个简短的排名列表；然后 Claude 对最匹配的结果调用 “describe”。

服务器返回这项技能的「契约」，列出要调用的 API、参数、依赖关系以及各步骤的顺序。Claude 发起 dispatch 调用，服务器把请求路由到正确的端点，检查用户权限，再把结果返回。这样，agent 的上下文里只需要放四个工具定义，而不必把所有可用工具的定义都塞进去。

下一步

本文讲到的所有东西，都是围绕模型搭起来的一块块脚手架。目前这些部件分散在不同的产品里。按照 MK 和 Khushwant 的说法，下一步是把它们整合成一个系统，也就是 Enterprise AI Harness——一个企业可以灵活使用的统一平台。企业把自己的 agent 和数据接进来，就能一次性获得评测（eval）、链路追踪（tracing）等功能，无论这些 agent 跑在 Agentforce 上还是别处。

Salesforce 改用了一套新设计：多层架构，把确定性代码和推理模型结合起来，尽量把可靠性做到最高。

查看原文