A Deep Dive into Salesforce’s Agent Tech Stack

Salesforce Agent 技术栈深度解析

ByteByteGo

2026年10月26日

仅30%的AI代理试点项目能进入生产环境。成功的关键是什么？（赞助内容）

Datadog的免费电子书揭示了哪些因素真正决定了代理项目能否从试点阶段成功过渡到生产环境。剧透：问题不在于模型。关键在于持久的执行能力、内存管理、评估流水线和可观测性。

你将学到如何：

• 识别在代理程序上线前可能导致失败的四种模式
• 构建可信赖并支持生产规模治理的评估流水线
• 通过必要的可观测性工具对代理工作流进行监控，以调试生产环境中的非确定性行为
• 测量能向团队和管理层证明代理投资回报率的关键指标

下载电子书

Salesforce代理系统在Agentforce和Slack平台上已完成了70亿个智能工作单元（AWUs），这是公司用于衡量AI代理工作量的单位。其中，仅第二季度就完成了32亿个。

但让代理系统持续遵循指令确实是个巨大挑战。Agentforce（Salesforce构建和运行代理的平台）的首个版本将所有指令整合到一个大型提示中。随着规则数量增加，模型开始跳过一些关键指令。对于使用代理进行求职者面试或处理患者数据的客户来说，这种问题无法接受。

Salesforce转向了新的设计架构：一个结合确定性代码和推理模型的多层系统，以实现最大可靠性。为了深入了解这一架构的工作原理，我们在2026年Dreamforce大会上采访了两位核心架构师：Salesforce总裁兼首席技术官Muralidhar Krishnaprasad（MK）以及AI应用开发平台产品管理高级副总裁Khushwant Singh。感谢MK和Khushwant与我们分享这些细节。

在本文中，你将学到：

• 为什么依赖提示的简单设计不可靠
• 如何结合确定性代码与概率推理模型提升可靠性
• 如何构建支持身份解析并将多系统记录整合为统一档案的数据层
• 如何构建高效的情境引擎
• Agent Identity如何为代理赋予独立权限
• AIforce和Headless Toolkit如何让Slack和Claude等工具中的代理访问Salesforce数据和操作

简单设计：单一提示模式

构建代理的最简单方式是将所有内容写入单一提示中。这正是大多数团队构建首个代理时采用的方式。想象你正在为一家医疗公司构建支持代理。你可以将业务规则写成自然语言指令（例如：仅讨论患者本人的记录）。然后添加可用工具的描述（例如："获取预约记录"）。你还会包含其他相关信息，如患者数据。代理系统会将所有这些内容纳入LLM的上下文窗口。这就是整个设计。我们只能希望LLM能做出正确判断。

在这种简单设计中，模型需要同时处理四项任务：1）执行规则，2）跨不同系统识别客户身份，3）包含模型可能需要的数据，4）确保代理仅执行被授权的操作。

Agentforce 的第一个版本以这种方式处理所有事情。根据 MK 的说法，团队不断添加诸如“只做这个”“只做那个”“首先获取所有预约”之类的指令。团队的一个有趣观察是，这种做法在最多八条指令时运行良好。但超过八条后，模型会丢弃指令。

但为什么模型会丢弃指令？对模型来说，指令不一定是规则。它只是上下文中的某些文本。无法保证指令一定会被遵循。此外，随着我们在上下文中添加更多指令，遵循指令的效果也会变差。这不仅限于 Salesforce。一个名为 IFScale 的基准测试对 20 个模型进行了测试，每个模型在一个提示中包含多达 500 条简单指令，以衡量指令遵循能力。即使表现最好的模型，在 500 条指令全部使用时也仅遵循了其中的 68%。

因此，一个提示只能尝试塑造 LLM 的行为，但无法强制执行该行为。让我们看看 Salesforce 围绕模型构建了哪些内容来解决这个问题。

Agentforce 的构建方式

Salesforce 的新设计通过将四项任务从提示中移出，并由专用系统分别处理，来确保可靠性。要了解这些系统的位置，让我们回顾一下当前的 Salesforce 平台架构。从下到上的堆栈中，四个主要层级分别是：

• 数据层：将公司的数据源转换为一致的视图。Salesforce 将其称为 Data 360。

• 应用层：销售、服务和营销的业务应用，这些应用提供了代理可以执行的操作。Salesforce 将其称为 Customer 360。

• 代理层：代理在此处被定义和运行。Salesforce 将其称为 Agentforce。

• 界面层：人们与代理交互的场所，例如 Claude 聊天或 Slack。

不再将所有内容放入提示中并期望模型处理所有任务，而是由这些层级中的某个系统的专用系统分别处理每项任务。例如，在 Agentforce 层中，一种名为 Agent Script 的脚本语言确保强制执行规则。在数据层中，身份解析负责找到客户的统一档案。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（Agentforce的运行时引擎）执行[x]。引擎会运行代码部分，并在需要推理时调用模型。

为了更好地理解，可以将其与SQL触发器进行比较。触发器是数据库在更新一行数据前后自动运行的代码，发起更新的应用程序无法跳过它。Agent Script遵循类似的模式。

让我们通过一个具体例子比较原始设计与Agent Script。假设Harper问：“我与Perl医生的下次预约是什么时候？”在原始设计中，提示语会说“始终先获取预约信息”，并希望模型能遵循。而在Agent Script中，查找操作是医疗预约子代理的before_reasoning代码块中的一行代码。因此，它总能可靠地运行。

当Harper提出问题时，系统会按以下流程处理：

• 模型选择医疗预约子代理。
• 执行before_reasoning代码块（预约查询作为代码运行）。
• 引擎构建提示语。
• 模型接收提示语并生成回答。
• 最后执行after_reasoning代码块。如有需要，它可能将对话转发给其他子代理。

这种将确定性任务与推理部分分离的设计，使系统保持可靠性。模型只需专注于代码准备的上下文进行推理，而无需处理获取预约或回复后操作等事务。

虽然确定性指令能提高可靠性，但不应滥用。最佳实践是：用代码实现需要可预测行为的部分（如条件判断），用自然语言处理实际需要推理的部分。

2. 通过Data 360实现统一客户档案

第二个系统处理“客户是谁”的问题。Harper的预约问题看似简单，但预约数据可能根本不在CRM（客户关系管理）系统中。它可能存储在Snowflake（云数据仓库）中。Harper可能在系统中存在多个记录，如下所示。

一种方法是向模型提供不同的记录列表并要求其判断哪些属于同一个人。但这会成为不可靠的来源。相反，数据层通过三个步骤可以解决这个问题。

步骤1：获取数据。代理需要的数据通常不会集中存储。数据层连接到各种数据源并直接读取数据。这样，代理可以实时查看最新记录。为说明这一点，MK在Snowflake中修改了Harper的保险计划记录，修改立即生效。

步骤2：数据标准化。不同数据源可能对同一记录有不一致的视图。例如，一个系统可能将全名存储在单个字段中，而另一个系统则拆分为两个字段。数据层会将每个数据源映射到共享数据模型，该模型包含person、lead等通用对象。据MK介绍，这种映射是自动完成的，可跨数千个数据源运行。

步骤 3：解析身份。此步骤处理来自不同来源的记录描述同一人的情况。在 Data 360 中，这是通过管理员可配置的匹配规则实现的。规则可以是精确匹配（如相同电子邮件地址）、允许小差异的模糊规则，或在比较前清理字段的规范化规则。这样，不同格式的电话号码也能匹配。请注意源记录永远不会被修改，输出是一个统一的档案，可链接回每个源记录。

通过这些步骤，当需要获取 Harper 的预约信息时，数据会从统一档案中提取，而非模型自行推断 Harper Clark 的身份。

3. 借助代理上下文引擎的关联上下文

第三项任务是决定哪些数据应包含在提示信息中。如果将所有数据放入提示信息，会增加延迟并可能掩盖关键事实。上下文管理系统需要位于数据与提示信息之间，判断问题需要哪些信息。这就是代理上下文引擎（Agent Context Engine，简称 ACE）的作用，它是 Data 360 的新组件。

上下文引擎通过六个步骤处理请求：

• 解析：识别用户、代理、目的以及问题所涉及的实体。
• 规划：选择信息来源（如关系查询、档案、搜索索引等）。
• 协调：根据某些指标（如相关性、权威性、新鲜度）对结果进行排序。
• 治理：应用规则（如访问权限、数据脱敏、用户同意）。
• 编译：创建包含工作状态、记忆等信息的上下文。
• 学习：决定本次交互中需要记住或更新的内容。

MK 将此与保险支持代理的简单设计进行了对比。在简单版本中，没有上下文管理时，“展示我的保险计划详情”这一问题会促使代理从多个来源提取数据，导致使用 124,000 个标记。而使用上下文引擎后，相同问题仅使用 9,000 个标记。在后续关于搬到佛罗里达州的提问中，简单版本的会话在两个问题中消耗了约 300,000 个标记，而使用上下文引擎的会话在第三步处理注册信息后仅使用了 65,000 个标记。随着对话继续，两种设计之间的差距会进一步扩大，这凸显了建立上下文管理的重要性。

那么，上下文引擎如何选择发送哪些信息？

实际应用中有多种实现方式。一种方法是将客户的档案以图结构存储在内存中，节点代表人物或计划等实体。然后仅选择与问题相关的节点。文档也可以通过类似方式过滤。当 Harper 询问“对我而言哪种生活方式最合适？”时，三个匹配精确词汇、含义和关联实体的索引（这种方法称为 GraphRAG）会从数百份文档中筛选出相关段落。

上下文引擎还可处理记忆。例如，在佛罗里达州相关问题之后，它可以记录该客户可能搬迁至佛罗里达州的提示。MK 指出，这属于记忆而非事实。只有当客户实际完成注册时，这一信息才会成为事实，并且只有经过批准的事实才会被纳入长期记忆。无论如何，模型看到的始终是公司对客户了解的当前小片段。

最后的任务是确保代理只执行其被允许的操作。在当今大多数代理配置中，代理以用户身份行事。想象一下，Alex是一名销售代表，他将代理连接到Salesforce。代理获取Alex的凭证后，可以执行Alex能做的一切操作。

这种设置并不理想，因为拥有Alex完整凭证的代理一旦犯错，就会造成实际问题。拥有广泛权限的人类至少受到工作速度的限制，而代理则没有这种限制。它可能犯错并反复重复错误。根据Khushwant的说法，客户真正想要的是：“这个代理代表Alex工作，但我不希望代理拥有与Alex相同的权限。”

解决方案是为代理赋予独立的身份。Salesforce已经通过权限集控制用户能执行的操作。新的系统“Agent Identity”允许管理员为代理附加规则和权限，从而使每个代理最终拥有独立的身份和独特的权限。

通过Agent Identity，当代理进行身份验证时，会生成两个令牌：一个用于代理，另一个用于代理所代表的用户。在执行操作前，Salesforce会检查用户的权限、代理的权限以及数据策略。只有当所有条件均未拒绝时，操作才会执行。

代理的运行环境

到目前为止，我们已经探讨了可靠代理平台内部的运作机制。但使用代理的用户可能在其他地方工作，例如Slack或Claude。一些公司完全在其他平台上构建自己的代理。客户通常希望Salesforce能够深入用户所在环境。

实现这一目标的方法是将平台与其界面分离。采用这种设计的软件被称为“无头”架构。它不依赖于自己的用户界面，而是通过API公开功能，使其能够被其他界面使用。为此，Salesforce开发了一个名为AIforce的实时界面层，将平台的数据、工作流程和逻辑带到用户和代理已经工作的任何地方。

对于外部代理要使用无头平台，需要以下要素：首先是API，即平台公开的功能；其次是技能（skills）。API告诉代理可以调用什么，但不会说明任务需要哪些调用或顺序。技能通过列出API、参数和步骤顺序来弥补这一空白。第三是MCP（Model Context Protocol），这是一个开放标准，服务器通过它发布工具列表，代理可以调用这些工具。

Salesforce开发了AIforce背后的一套构建模块，名为Headless Toolkit，提供了上述所有功能。Salesforce的API每天已经处理96亿次调用，其技能已发布在名为sf-skills的公共GitHub仓库中。

一个独立的挑战是工具数量。MCP虽然让代理调用工具变得容易，但每个代理能调用的工具通常会以定义形式加载到其上下文窗口中。这些定义可能包含名称、描述和参数模式等信息，每次向模型发送请求时都需要传输这些定义，成本较高。当有数百个工具时，这些定义会占用大量上下文空间，而代理很少会使用这些定义。

常见的解决方案是创建一个工具的小索引，而不是全部工具。代理首先搜索所需工具，然后读取找到的工具详细信息，最后执行操作。Salesforce的MCP服务器正是通过这种方式运作的，它仅使用四个工具。

假设你正在使用带有 Salesforce 插件的 Claude，请求获取过去 100 天内排名前 20 的销售机会。该请求会经历以下三个步骤：

• Claude 调用 "discover" 接口并传递对请求的解读。服务器会在可用 API 和技能的索引中执行语义搜索，返回一个简短的排序列表。
• Claude 对最佳匹配项调用 "describe" 接口。服务器返回该技能的合约信息，其中列出了涉及的 API、参数、依赖关系以及步骤顺序。
• Claude 调用 "dispatch" 接口。服务器将请求路由到正确的端点，检查用户权限后返回结果。

通过这种方式，代理的上下文中仅包含四个工具定义，而不是包含所有可用工具的工具定义。

下一步计划

本文中提到的所有内容都是围绕模型构建的支撑框架。目前这些组件分布在不同的产品中。根据 MK 和 Khushwant 的规划，下一步是将它们整合为一个统一系统——即企业级 AI 控制平台（Enterprise AI Harness）。这是一个企业可以灵活使用的统一平台。企业可以将代理和数据接入该平台，同时对所有接入内容统一应用评估、追踪等功能，无论代理是在 Agentforce 上运行还是部署在其他环境。