Salesforce Agentforce 是 Salesforce 于 2024 年推出的企业级 AI Agent 平台,基于其 Einstein Trust Layer 和 Data Cloud 构建,允许企业通过自然语言描述创建可自主执行任务的数字劳动力。Agentforce 的核心价值在于将 AI Agent 从「聊天机器人」升级为「主动执行者」——它能跨 Salesforce CRM 数据、外部系统和业务流程自动完成客户服务、销售跟进、营销触达等工作,并在关键节点移交人工处理。与 LangChain 等开发者框架不同,Agentforce 面向业务人员和 IT 团队,主打低代码配置、开箱即用的预置 Agent 模板,以及深度的 CRM 数据集成。本篇将覆盖 Agentforce 的速览、初始配置、Agent 搭建全流程、核心能力(Agent Builder、Atlas Reasoning Engine、MuleSoft 集成、Prompt Builder)、生产部署与监控,并附选型对比与面试题,让读者从零开始掌握这一企业级 Agent 平台。

岗位关联

掌握 Agentforce 意味着你同时拥有 CRM 数据资产与 AI Agent 编排能力——这是当前企业级 AI 落地中需求最旺盛、薪资溢价最明显的技能组合之一。

目录
  1. 为什么需要 Salesforce Agentforce:AI 从「聊天建议」到「自主执行」
  2. 安装与环境配置:开通许可 + 启用平台功能
  3. 快速上手:30 分钟用模板跑通第一个客服 Agent
  4. 核心能力详解:Agentforce 的 5 大支柱
  5. 生产部署与监控:从激活上线到持续优化
  6. 版本迭代
  7. AI 应用场景
  8. 常见误区
  9. 面试题
  10. 参考来源
工具类型
企业级 AI Agent 平台(SaaS,低代码)
开发商
Salesforce(美国·旧金山)
开源协议
闭源(商业 SaaS,按对话/按 Agent 用量计费)
GitHub Stars
无
主要语言
可视化配置为主;支持 Apex、Flow、MuleSoft 集成
当前版本
Winter '25 正式版(含 Agentforce 2.0 更新)
安装方式
直接开通:启用 Agentforce 许可 → 在 Setup 中配置
上手难度
★★★☆☆(中等:需了解 Salesforce 数据模型与权限体系)
适合人群
CRM 管理员、业务分析师、企业架构师、AI 落地团队
同类工具
Microsoft Copilot Studio、ServiceNow AI Agents、LangChain/LlamaIndex
托管服务
无

速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。

为什么需要 Salesforce Agentforce:AI 从「聊天建议」到「自主执行」

传统 CRM 中的 AI(如 Einstein 预测、Service 推荐)只提供建议,最终动作仍需人工点击完成——客服要抄写推荐话术、销售要手动更新机会阶段、营销要人工触发后续流程。这种「AI 建议、人执行」的模式在工单量爆发时依然受制于人力吞吐。同时,企业内部大量客户数据散落在 Salesforce 核心 CRM、Data Cloud 和外部系统中,通用大模型无法直接触达这些结构化数据,难以产生可靠业务动作。

Agentforce 的解法是「数据驱动的自主执行」:Agent 通过 Atlas Reasoning Engine(推理引擎)理解用户请求 → 调用 Data Cloud 中的统一客户画像 → 通过预置或自定义的「动作(Actions)」执行 CRM 更新、工单创建、会话转接等真实业务操作。每个 Agent 都配有主题(Topics)限定的能力边界和护栏(Guardrails),确保 Agent 只在授权范围内行动。与 LangChain 等纯代码框架相比,Agentforce 的核心差异是「业务人员可配」——Agent 的指令、知识、动作全部通过可视化界面配置,由 Salesforce 平台托管推理与执行基础设施。

对 AI 从业者而言,Agentforce 代表了一条与开源框架互补的落地路径:前者用自然语言配置减少开发成本、深度绑定 CRM 数据,后者提供模型和工具调用的最大自由度。理解 Agentforce 的「配置式 Agent」范式,有助于在企业场景中更务实地评估技术选型。

安装与环境配置:开通许可 + 启用平台功能

Agentforce 是 Salesforce 原生 SaaS 功能,无需安装任何服务器组件。你可以通过以下三种方式获得环境:注册 Developer Edition 免费开发环境(功能受限)、购买生产环境的 Agentforce 附加许可、或申请 30 天试用。在现有组织(Org)中启用需要系统管理员权限。

步骤一:获取环境。 访问 Salesforce 官网注册 Developer Edition(免费、功能受限的沙箱环境),或向客户成功经理申请 Agentforce Lightning 试用。注册完成后你会获得一个 yourname-developer-edition.my.salesforce.com 的登录地址。

步骤二:启用 Agentforce 许可。 登录后进入「设置(Setup)」。在快速查找框中输入「Agentforce」,进入许可管理页面,确认你的组织已添加 Agentforce 许可。Developer Edition 通常预置了有限数量的 Agentforce 对话配额(按消息数计费,超出后停止服务)。

步骤三:配置 Einstein Trust Layer 与数据连接。 Agentforce 依赖 Einstein Trust Layer(信任层)处理 LLM 调用的数据脱敏与审计,以及 Data Cloud 统一客户数据。进入「设置 → Einstein Trust Layer」页面勾选启用「数据脱敏」「提示词存储」「零数据保留」三项核心开关;随后在「设置 → Data Cloud」中确认 Data Cloud 已启用并具备至少一个数据源空间(Data Space)。若组织尚未使用 Data Cloud,系统会引导你初始化。

步骤四:验证环境。 从 App Launcher 打开「Agent Builder」应用,若能正常加载并看到「新建 Agent」按钮,说明环境就绪。此时你可以先运行一个 Salesforce 预置的「客服 Agent(Service Agent)」模板,无需任何配置即可在测试门户中对话。

bash6 行
# Agentforce 无 CLI 安装流程,以下为环境准备清单(勾选式验证):# 1. 注册 Developer Edition: https://developer.salesforce.com/signup# 2. 设置 → 许可 → 确认 Agentforce 已添加# 3. 设置 → Einstein Trust Layer → 启用数据脱敏与零保留# 4. 设置 → Data Cloud → 初始化 Data Space# 5. App Launcher → Agent Builder → 确认可新建 Agent

快速上手:30 分钟用模板跑通第一个客服 Agent

Agentforce 的最短可行路径是克隆预置的「客服 Agent(Service Agent)」模板,几分钟内即可得到一个可对话的 AI 客服。以下操作均需系统管理员权限。

1. 从 App Launcher 打开 Agent Builder。Agent Builder 是 Agentforce 的中央配置台,所有 Agent 的搭建与调试都在此完成。

2. 点击 「新建 Agent」,在模板库中找到 「Service Agent(客服 Agent)」,选择「克隆」并输入名称(如「电子商城客服」)。

3. Agent 创建后进入配置界面,左侧为 Agent 的指令(Instructions) 输入框——在这里用自然语言描述 Agent 的角色定位与行为边界,例如:「你是电子商城的客服助手,使用中文回答,仅处理订单查询与退换货问题,超出范围时礼貌转人工」。

4. 在 「知识(Knowledge)」 区域点击「添加」,选择你的 Salesforce Knowledge 知识库或引入 Data Cloud 数据作为 Agent 的回答依据;若无现成知识库,可在后续的「测试」标签页中体验纯动作式应答。

5. 在 「主题(Topics)」 区域确认「订单查询」「退货/换货」两个预置主题已启用。每个主题包含一组触发条件(Triggers) 与对话示例(Conversation Samples)——Agent 通过它们判断用户意图是否属于该主题。

6. 在每个主题下的 「动作(Actions)」 中,勾选可用的标准动作(如「查询订单状态」「创建退货申请」)。这些动作由系统自动映射到 Salesforce 后台的数据模型,无需写代码。

7. 点击右上角 「激活(Activate)」,然后进入 「测试(Test)」 标签页。在弹出的测试面板中直接输入:「订单 00001234 现在是什么状态?」——Agent 会调用订单查询动作并返回结果;再输入:「我不喜欢这个颜色,想退货」——验证意图分类与转人工逻辑是否符合预期。

激活后的 Agent 已可在支持 Agentforce 的渠道(如 Service 的 Chat 组件)中投入使用。进阶技巧:在「测试」面板左上角可查看 Agent 的完整推理步骤(包括命中哪个主题、调用了哪些动作、每个动作的输入输出),这是排查 Agent 行为不符预期的最重要工具——出现误判时,优先调整对应主题的触发条件或示例对话,而非直接修改全局指令。

核心能力详解:Agentforce 的 5 大支柱

支柱一:Agent Builder(无代码 Agent 搭建台)。 Agent Builder 是配置 Agent 的可视化界面入口,允许业务人员用自然语言编写 Agent 指令、配置主题与动作。其核心设计是「主题(Topic)→ 触发器(Trigger)→ 动作(Action)」三层结构:主题定义 Agent 的能力范围(如「退换货」),触发器定义用户哪类表述会命中该主题(支持关键词、正则与 AI 语义匹配),动作定义实际执行的业务操作。相比 LangChain 的代码式 Agent 定义,Agent Builder 把「什么场景处理什么问题」的语义边界显式化,天然具备可审计性。

支柱二:Atlas Reasoning Engine(推理与规划引擎)。 Atlas 是 Agentforce 的底层推理引擎,负责在 Agent 收到请求后做意图理解、任务拆解、工具选择与结果校验。官方描述其运行流程为:理解用户请求 → 检索相关知识(RAG 到 Data Cloud)→ 生成行动计划 → 执行动作 → 生成回复,并在每一步写入审计日志。Atlas 使 Agent 能处理多轮、多步骤任务(如一次会话内完成「查订单 → 判断是否超出售后期 → 创建退货单 → 通知仓库」),且不依赖硬编码的对话树。

支柱三:预置动作库与 MuleSoft 集成(动作即一切)。 Agentforce 的价值不在对话,而在「动作」。平台预置了覆盖 Sales、Service、Marketing 的 100+ 标准动作(更新客户、创建工单、发送邮件等),且通过 MuleSoft 可编排外部系统 API 成为 Agent 可调用的自定义动作。自定义动作的开发路径是:在 MuleSoft 中写好 API 编排(如查 ERP 库存)→ 发布为 OAuth 保护的 API → 在 Agent Builder 中「动作 → 添加 → 流/APEX/外部 API」完成绑定。每个动作需声明输入、输出与描述——描述决定了大模型能否在推理时正确选用该动作,值得用业务场景写详细。

支柱四:Einstein Trust Layer(安全与合规底座)。 Einstein Trust Layer 是 Agent 调用的 LLM 安全网关,提供四项核心能力:数据脱敏(将客户姓名、身份证号等敏感字段在发送给模型前替换为标记)、提示词注入防御(检测并拦截提示词攻击)、审计追踪(记录每次 LLM 调用的完整输入输出)、零数据保留(模型供应商不存储企业数据)。客户数据训练和动态地面实况(grounding,将模型回答与 Salesforce 客户数据绑定,减少幻觉)也在此完成。

支柱五:Prompt Builder 与统一知识检索。 Prompt Builder 允许在 Salesforce 中创建可复用的提示词模板,并可关联 CRM 字段做个性化填充;这些模板能被 Agent 引用为「生成动作」。知识检索层面,Agentforce 支持同时从 Knowledge 文章、Data Cloud 数据湖和外部 RAG 服务(通过 MuleSoft)抓取上下文,在 Atlas 中做重排序后注入提示词。这一能力使 Agent 的回答有据可依,而非仅依赖模型参数。

生产部署与监控:从激活上线到持续优化

部署方式一:标准渠道嵌入。 Agentforce 官方支持的部署渠道包括 Salesforce 内置的 Web 聊天(Chat)、服务控制台(Service Console)嵌入、以及通过 API 将 Agent 接入企业外部门户或移动应用。在小规模验证阶段用 Chat 组件发布到内部测试页面即可。生产部署的关键前置条件是权限控制:在「设置 → Profile 与权限集」中,为 Agent 使用的每个动作分配对应权限(如「更新订单」需对象的 CRUD 权限),Agent 执行动作时遵循该用户的权限边界——权限不足时动作失败并在日志中标记原因。

部署方式二:走向多渠道与高可用。 上线到客户服务场景时,需要在 Agentforce 管理后台配置「会话接力(Handoff)」:定义当 Agent 置信度低、用户要求转人工、或会话超时转接三种条件。会话接力目标可以是客服队列(使用 Omni-Channel 分配)或外部客服系统。生产组织建议为生产 Org 配置 24/7 监控与告警,Salesforce 提供信任仪表盘(Trust Status)和 Health Check 用于监控平台侧的健康度,但这仅覆盖平台基础设施,你自己的 Agent 业务表现要通过下面的观测性功能跟踪。

可观测性:Debug 日志与 Einstein 洞察是我们观测 Agent 性能的两个核心手段。 开发阶段,在 Debug 模式下可以查看 Agent 的完整决策链——命中主题、评分、选用动作及参数。生产阶段,设置 → Agentforce 洞察页面提供三个关键指标看板:会话量(Conversation Count)、动作成功率(Action Success Rate)、转人工率(Escalation Rate)。建议按周追踪这些指标,持续更新主题的示例对话以提升命中率,不断丰富动作描述以提升动作调用的准确率。

<p class=“para-label“>避坑清单:</p><ul class=”dash-list”><li>坑 1:权限配置遗漏导致动作静默失败。Agent 动作失败不会弹窗报错,只会记录在 Debug 日志中——上线前务必在 Debug 模式下逐动作验证,对所有 Agent 引用对象和字段做权限检查。</li><li>坑 2:指令(Instructions)与主题(Topics)职责混淆。指令负责角色与全局边界,主题负责具体业务场景及动作绑定。将业务细节写进指令会让 Agent 行为难以收敛,正确做法是把业务细节放在主题的指令与示例中。</li><li>坑 3:动作描述写得过简导致模型调用错动作。动作描述是 LLM 选择工具的依据,描述应写明「何时用」「输入含义」「输出含义」,如「create_case:当用户提出投诉或报障时创建一条服务工单,输入为工单类型与问题描述」。</li><li>坑 4:用生产环境直接调 Prompt 与指令,忽略影子模式。Agentforce 支持将 Agent 配置为「模拟模式(Simulation)」先行验证——先以影子流量评估回答质量,再正式切换真实执行,不要跳过这一验证阶段。</li><li>坑 5:忽略数据脱敏与零保留的例外配置。Einstein Trust Layer 的脱敏规则默认覆盖标准字段,但对自定义字段需手动添加脱敏策略;若你的场景含跨地域数据合规需求,务必在配置脱敏前咨询法务。</li></ul>

维度Salesforce AgentforceMicrosoft Copilot StudioServiceNow AI AgentsLangChain / LlamaIndex
定位企业级 AI Agent 平台(CRM 原生)企业级 AI Agent 构建平台(低代码)IT 服务管理 + AI Agent 编排开源 LLM 应用开发框架
编排范式Atlas 推理引擎,自动规划多步骤执行对话流 + 知识 + 指令式编排流程定义 + NLU 驱动的会话工作流代码式 Chain/Agent/RAG 管道编排
类型约束低代码配置,业务人员可搭建低代码,画布式设计器低代码 + 脚本语言(Flow Designer)全代码,需 Python 工程能力
学习曲线★★★☆☆(需懂 Salesforce 数据模型与权限)★★★☆☆(需懂 Power Platform 生态)★★★★☆(需理解 ITIL 流程与 CMDB)★★★★★(需掌握 LLM 概念与 Python)
生态集成深度集成 Salesforce CRM + Data Cloud + MuleSoft集成 Microsoft 365、Dynamics 365、Power Automate深度集成 ServiceNow ITSM + 企业 CMDB通用:可对接任意 API/数据库/向量库
生产部署SaaS 托管,多渠道发布,企业级 SLASaaS 托管,多渠道,企业级 SLASaaS 托管,ITSM 流程深度绑定自托管为主,部署与运维成本高
License闭源,按对话/按 Agent 用量计费闭源,按 Copilot 消息量计费(随 M365 套件)闭源,按时长与流程数计费开源(MIT 等),模型与算力费用自理
适合谁CRM 重度用户、客服与销售团队Microsoft 生态企业、IT/业务双角色团队IT 服务台、ITIL 流程团队开发者、需要自定义模型与自由编排的团队

选型建议:若你的业务数据以 Salesforce CRM 为核心且希望 AI Agent 直接驱动客户服务与销售流程,Agentforce 是深度集成成本最低的选择;若企业已深度使用 Microsoft 365 生态,Copilot Studio 的学习与集成成本更低;IT 服务类场景(工单、事件、变更管理)应以 ServiceNow AI Agents 为首选;需要完全自定义模型、自由控制推理链路或对数据主权有严格要求的场景,选择 LangChain/LlamaIndex 自研架构。Agentforce 的边界在于它绑定 Salesforce 生态,即使通过 MuleSoft 打通外部系统,核心数据模型与权限仍然架构在 Salesforce 之上。

版本迭代

Agentforce 于 2024 年 9 月随 Salesforce 年度大会正式发布,从最初只能处理客服问答的 1.0,到 2024 年 12 月发布 2.0 引入 Atlas Reasoning Engine 与多步骤自主执行,再到 2025 年春季扩展开发能力,产品主线是「从客服单场景 → 跨业务多 Agent 协作 → 深度自定义」。数据均为官方发布会与 Changelog 确认的版本记录。

版本时间变化提升
Agentforce 1.0(GA)2024-09客服 Agent 模板、Einstein Trust Layer 集成首个正式版,提供预置客服 Agent、知识检索与人工交接能力
Agentforce 2.02024-12引入 Atlas Reasoning Engine、Agent Builder 2.0支持多步骤自主规划与执行,不再依赖硬编码对话流
Winter '25 更新2025-01Agentforce 洞察看板、Debug 模式增强生产可观测性补齐,动作成功率与转人工率可视化
Spring '25 更新2025-03Agent 开发框架(Agent Development Framework)、MuleSoft 深度集成支持开发者用代码扩展动作与自定义推理逻辑,外部系统调用更顺畅
结论

截至 2025 年 3 月,Agentforce 已从最初「客服单场景」进化为「多步骤自主执行 + 开发者可扩展」的企业级平台。这一演进方向明确:Salesforce 正在将 Agentforce 从开箱即用模板推向可编程深度定制,以覆盖更广泛的业务场景。选型时若只需简单客服问答,1.0 时代的模板能力已足够;若需多轮跨系统操作(如订单+物流+ERP),务必使用 2.0 及以上的 Atlas 推理引擎版本。官方尚未公布 MMLU 等通用评测分数,选型应以业务场景适配度和集成成本为核心参考。

AI 应用场景

场景一:智能客户服务与工单处理

阶段:Agent 编排(意图识别 → 知识检索 → 动作执行 → 人工交接)

解决的问题:传统客服依赖人工逐条处理大量重复咨询,Agentforce 通过知识库检索与 CRM 数据联动自动完成订单查询、退换货、账单答疑等高频场景,仅在复杂或高情绪化对话中转人工,显著降低客服工时消耗。

具体案例:某消费电子产品企业部署客服 Agent,接通 Salesforce Knowledge 与订单数据库后,常见问询解决率提升约 30%(官方演示数据),服务回复时间从分钟级缩短到秒级;转人工会话由 Agent 附带完整上下文,客服无需重新询问用户信息。

场景二:销售线索挖掘与跟进(Sales Development)

阶段:Agent 编排(客户画像生成 → 个性化触达 → 销售机会创建)

解决的问题:销售团队人力有限,大量潜在客户未得到及时跟进。Agentforce 在线索评分、个性化邮件起草、会议安排、机会阶段更新等环节实现自主运作,销售代表仅需处理 Agent 筛选出的高意向线索。

具体案例:利用 Agentforce 销售 Agent,在用户提交表单后立即自动发送个性化跟进邮件并创建销售任务,使线索响应时间从小时级缩短至分钟级(官方演示场景);Agent 还可根据 Data Cloud 中的历史购买记录推荐交叉销售产品。

场景三:营销活动触达与客户旅程联动

阶段:Agent 编排(客户洞察 → 内容生成 → 旅程触发 → 效果回流)

解决的问题:传统营销自动化依赖预先设定的固定旅程,对用户实时行为响应滞后。Agentforce 结合 Data Cloud 实时数据与 Prompt Builder 生成个性化内容,在客户旅程的每个触点上自主决策下一步动作,并将互动结果实时回写至 CRM。

具体案例:某零售企业使用 Agentforce 在用户放弃购物车后,基于其浏览记录生成个性化挽回文案并触发折扣发放(需配合促销活动配置),营销邮件打开率提升 25%(官方演示数据),且用户从触达到购买的响应周期明显缩短。

常见误区

误区「Agentforce 不是接入了大模型吗,那它应该像 ChatGPT 一样什么都能回答吧?我直接让它给我写代码、写文章试试。」

正解Agentforce 不是通用聊天机器人,而是「有边界的企业执行器」。它的回答受限于:① 你在指令(Instructions)中定义的角色与边界;② 已配置的主题(Topics)覆盖范围;③ 可调用的动作(Actions)与知识源。超出这些范围时,Agent 必须按配置转人工或拒绝,而不是自由发挥。这是企业场景的安全设计——AI 不能随意访问和操作未经授权的数据。

为何常见:Agentforce 的测试面板看起来像普通聊天框,且底层确实用大模型理解语义,用户容易将其与通用对话模型混为一谈。关键区别在于:Agentforce 的回答必须「落地到动作和数据」,而非生成文本。

误区「我这个 Agent 上线一周了,平时表现挺好的,不用再改了吧?下次回归测试也不用做了,流程没变。」

正解Agentforce 的行为会随多种因素漂移:新业务数据进入知识库、动作描述更新、外界语言模式变化,甚至模型供应商后台升级调整都会影响决策表现。正确做法是按周查看 Agentforce 洞察看板(会话量、动作成功率、转人工率),定期运行测试用例集做回归;每次更新指令、主题或动作后,必须重新在测试面板中跑一轮验证。

为何常见:低代码配置让「搭建 Agent」看起来像设置一套规则,但底层仍是概率模型,行为天然有不确定性。这正是生产环境中 Debug 模式与洞察看板存在的原因。

误区「我已经部署了 Agentforce,可以裁员了——它应该能处理投诉、复杂技术问题,甚至能给客户打感情牌?」

正解Agentforce 适合处理结构化、高频、规则清晰的场景(查订单、改地址、退换货、预约等)。但对于高情绪化投诉、索赔纠纷、复杂多系统排障等场景,官方建议配置平滑的「会话接力」转人工;Agent 应在交接时传递完整会话上下文,让客服人员无缝接手。Agentforce 的产品哲学是「人机协同」而非「完全取代」。

为何常见:厂商宣传中强调「自主执行」与「数字劳动力」,容易让人忽略产品文档中大量关于「Human Handoff」的设计——后者恰恰说明 Agent 的能力边界是经深思熟虑的。

误区「我们的客服流程很简单,把流程文档交给 Agentforce 的模板,上线后应该立即能处理 90% 的工单吧?」

正解真实落地通常需要「先影子、后小流量、再放量」三阶段:先在模拟模式(Simulation)下验证回答质量 → 在内部测试渠道小范围运行 → 再逐步放量到生产渠道。且前期需要大量素材积累——包括知识库的完善程度、主题示例对话的覆盖度、动作的粒度设计。很多团队忽略的隐性工作是:动作背后依赖的数据质量(如订单状态字段是否准确)往往比 Agent 本身更决定成败。官方建议在正式上线前完成至少 2-3 轮迭代测试。

为何常见:模板库给用户「开箱即用」的错觉,但模板只是骨架——每个企业有独特的产品、话术、流程与数据,Agent 的调优是持续投入,而非一次性配置。

误区「Agentforce 要对接我们自己的业务系统,是不是得找工程师写 Apex 才能实现?」

正解Agentforce 提供多条自定义动作路径,从低到高依次为:① 使用预置动作(覆盖常用 CRM 场景);② 在 Flow Builder 中可视化编排逻辑并将其作为动作(适合分支较多、步骤明确的业务流程);③ 通过 MuleSoft 将外部 API 编排为动作(适合跨系统数据打通);④ 使用 Apex 编写自定义调用(适合复杂逻辑)。官方推荐优先使用 Flow 和 MuleSoft,Apex 仅用于预置与 Flow 都无法满足的场景,以降低维护成本。

为何常见:Salesforce 技术栈中的 Apex 是广为人知的扩展方式,但 Agentforce 的产品设计刻意降低了编码门槛——它以 Flow 与 MuleSoft 为「一等公民」动作来源,这是多数从传统 Salesforce 开发转过来的工程师容易忽视的。

面试题

Q1. Agentforce 中「主题(Topic)」的主要作用是?

单选题 · easy

  • A.定义 Agent 的视觉风格
  • B.限定 Agent 的业务能力范围← 正确答案
  • C.管理知识库的访问权限
  • D.配置 Agent 的模型参数

答案:B。主题(Topic)是 Agentforce 的核心概念,它将 Agent 的能力划分为业务场景(如「退换货」「订单查询」),每个主题包含触发条件与绑定的动作——这正是 Agent 行为边界的来源。视觉风格、知识库权限与模型参数均不由主题管理,分别属于 Agent 个性化设置、知识区与 Trust Layer 配置。

Q2. Einstein Trust Layer 的核心能力不包括下列哪一项?

单选题 · easy

  • A.数据脱敏
  • B.提示词注入防御
  • C.零数据保留
  • D.自动生成 Apex 代码← 正确答案

答案:D。Einstein Trust Layer 提供数据脱敏、提示词注入防御、审计追踪、零数据保留四项能力,前两者保证数据不出安全边界,后者确保模型供应商不留存企业数据。Apex 自动生成不在 Trust Layer 范围内。

Q3. 在 Agentforce 中,大语言模型选择执行哪个动作时,主要依据是什么?

单选题 · mid

  • A.动作的代码逻辑
  • B.动作的名称与描述← 正确答案
  • C.动作的调用次数
  • D.动作的权限配置

答案:B。Atlas 推理引擎通过动作的描述文本(以及名称)来理解该动作的用途、输入输出含义,进而决定在何种情况下调用。动作描述写得越贴近业务场景,模型选错动作的概率越低。代码逻辑与调用次数不参与模型决策,权限配置只决定「能不能执行」。

Q4. Agentforce 2.0 相比 1.0 最关键的架构升级是什么?

单选题 · mid

  • A.引入了 Atlas Reasoning Engine← 正确答案
  • B.增加了客服模板
  • C.全面支持 CRM Analytics
  • D.移除了 Einstein Trust Layer

答案:A。Agentforce 2.0(2024 年 12 月随 Winter '25 发布)的核心是引入 Atlas Reasoning Engine,让 Agent 具备多步骤自主推理与规划能力,从「脚本式对话流」升级为「自主执行体」。客服模板在 1.0 就已存在,CRM Analytics 与 Agentforce 是并行产品而非其升级内容,Trust Layer 始终保留。

Q5. 下列关于 Agentforce「会话接力(Handoff)」的说法,正确的是?

单选题 · mid

  • A.会话接力只能由用户手动触发
  • B.会话接力发生时,Agent 无法将上下文传递给人工客服
  • C.会话接力是 Agentforce 设计中的一等公民能力,支持知识库数据与上下文同步传递← 正确答案
  • D.一旦启用会话接力,系统将不再尝试自动化处理任何问题

答案:C。会话接力是 Agentforce 的核心设计之一,配置了「低置信度转人工」「用户要求转人工」「超时转接」等触发条件,且转人工时能携带完整上下文(如会话摘要、用户画像)供人工客服使用。它不是「兜底开关」,也不仅限用户手动触发。

Q6. 在 Agentforce 中,Agent 执行动作失败后,最合适的排查入口是?

单选题 · hard

  • A.查看浏览器控制台日志
  • B.在测试面板的 Debug 模式中查看推理步骤← 正确答案
  • C.重新激活 Agent
  • D.检查 Chatter 动态

答案:B。Debug 模式会展示推理引擎命中的主题、选用的动作、每个动作的输入输出与报错信息——这是 Agentforce 官方推荐的排查手段。浏览器控制台只显示前端页面错误,重现激活无法定位「动作逻辑为何失败」,Chatter 是内部协作流而非系统日志。

Q7. 下列哪些属于 Agentforce 自定义动作的合法开发路径?

多选题 · mid

  • A.使用 Flow Builder 可视化编排后发布为动作← 正确答案
  • B.通过 MuleSoft 将外部 API 编排为动作← 正确答案
  • C.使用 Apex 编写自定义调用← 正确答案
  • D.直接修改预置 Agent 的 Python 源码

答案:ABC。Agentforce 官方支持的三条自定义动作路径为:Flow(低代码可视化)、MuleSoft(跨系统 API 编排)与 Apex(代码级自定义),三者复杂度递增。Agentforce 是闭源 SaaS 产品,不存在「修改 Python 源码」这种操作,预置 Agent 只能通过配置界面定制。

Q8. Agentforce 中 Agent Builder 的三层核心结层级结构是?(选择最准确的描述)

多选题 · mid

  • A.主题(Topic)→ 触发器(Trigger)→ 动作(Action)← 正确答案
  • B.指令(Instructions)→ 主题(Topics)→ 动作(Actions)
  • C.步骤(Steps)→ 分支(Branches)→ 动作(Actions)
  • D.技能(Skills)→ 意图(Intents)→ 动作(Actions)

答案:A。Agent Builder 的核心模型是「主题 → 触发器 → 动作」:主题定义业务场景,触发器定义命中条件,动作执行业务操作。指令(Instructions)是全局的 Agent 角色定义,在层级之外;Steps/Branches 与 Skills/Intents 是其他平台(如 Copilot Studio、ServiceNow)的概念。注意审查题干为「三层核心结构」。

Q9. 关于 Agentforce 生产环境部署的注意事项,下列说法正确的是?

多选题 · hard

  • A.代理执行动作时遵循用户的权限边界,需为动作配套设置 Profile 权限← 正确答案
  • B.生产环境可直接用「模拟模式」验证 Agent 的推理质量,无需影子流量
  • C.建议按周监控动作成功率与转人工率并持续调优主题← 正确答案
  • D.可以使用 Debug 模式在生产环境全量记录所有生产会话的完整推理步骤

答案:AC。A 对——Agent 受权限边界约束,需在 Profile/权限集中配置动作对应的对象与字段权限;C 对——可观测性是 Agentforce 官方推荐的持续优化流程。B 错——模拟模式是验证「回答质量」的手段,正式执行前仍应通过影子流量验证「执行效果」;D 错——Debug 模式捕获完整推理与输入的细粒度日志,通常用于开发与阶段测试,生产环境应仅启用必要审计日志,避免过度的数据记录。多选。

Q10. Agentforce 的 Einstein Trust Layer 数据脱敏策略,以下描述正确的有?

多选题 · hard

  • A.脱敏规则默认覆盖所有自定义字段
  • B.脱敏规则需要管理员为自定义字段手动配置← 正确答案
  • C.脱敏是「发送给 LLM 前替换敏感值」的过程← 正确答案
  • D.脱敏功能仅在 Service 场景中生效

答案:BC。Einstein Trust Layer 的脱敏规则覆盖 Salesforce 标准字段,自定义字段需管理员在 Trust Layer 设置中手动添加脱敏策略——这是常见的一个坑。脱敏的机制确实是在提示词发送给 LLM 前将识别出的敏感值替换为标记。Data Cloud 和各业务模块(含 Sales 与 Service)均为脱敏的适用场景,并非只限 Service。

参考来源