一、让 Flow 准备好被 Agent 使用（Make Your Flows Agent-Ready）
Agentforce 的很大一部分力量来自 Flow。虽然 agent 能访问 Salesforce 数据，但只有通过 agent 操作才能影响数据；而 Flow 是唯一能以低代码方式更改 org 数据的方法。本单元讲清 agent-ready Flow 的原则——正确的 Flow 类型、描述性命名、输入输出变量、权限范围、模块化设计，以及四个常见坑。
完成本单元后，你将能够：
- 创建可分配给 agent 操作的 Flow；
- 为 agent 操作 Flow 中的资源编写有用的名称和描述；
- 在 agent 操作 Flow 中创建合适的变量；
- 限制 agent 及其相关 Flow 可访问的数据。
为什么要在 Agent 中使用 Flow
核心原因在于：agent 能读取 Salesforce 数据，但没有 agent 操作就无法影响数据。agent 操作可以调用 Apex 类、发起 API 调用、运行 Flow 或引用 prompt 模板——但 Flow 是唯一能以低代码方式更改 org 数据的方法。
Flow 还能带来额外的一层准确性：因为 agent 能读取它被授予权限的任何数据、并随意使用它认为相关的数据，所以你可以创建一个 Flow 来检索精确、特定的数据喂给 agent，然后指示 agent 只用 Flow 提供的数据。Flow 同时给了你「行动的能力」和「准确行动」的能力。
创建自动启动 Flow（无触发器）
一条硬性要求：agent 操作只支持 Autolaunched Flow (No Trigger) 这一种 Flow 类型。其他自动启动类型（如记录触发 Flow）虽然在技术上也算「autolaunched」，但被分配的 Flow 必须明确是 No Trigger 类型。
如果你想把现有 Flow 用于 agent 操作，而它不是这个类型，就必须用 Autolaunched Flow (No Trigger) 类型重新创建它。构建之前务必记住这一点。
务必描述详尽（Be Very Descriptive）
AI 技术极度依赖文字，对任何要作为 agent 操作运行的 Flow 同样如此。agent 会用 Flow 的变量名以及 Flow 正在处理的数据来理解 Flow 的作用，所以准确、描述性的名称至关重要。
- 避免「foo」这类变量名，改用「Account_ID」这类描述性名称。
- 给每个变量写清用途描述。
- Flow 的描述会自动成为 agent 的指令——所以把它写成指令式的。例如「更新用户的电话号码，关联其联系人记录；若无匹配联系人则新建一条」比「更新电话号码」有效得多。
始终使用输入与输出变量
基于 Flow 的 agent 操作始终要求至少一个输入变量和至少一个输出变量。即便不做强制要求，这也仍是最佳实践——上下文越多，Flow 越精确。
有一个输出变量你应始终考虑发送：错误消息。agent 期望 Flow 返回某种结果，但 Flow 可能失败。没有数据时，agent 很可能会道歉并给出笼统的「出了点问题」消息，或为了让用户看到点东西而展示无关数据。为避免这一点，创建一个输出变量用于展示更详细、更有帮助的错误消息，用故障路径（fault path）和赋值元素在输出变量中设置错误消息，并告诉 agent 如何、何时使用它。
别怕使用记录变量（Record Variables）
记录变量不只用于 Flow 内部——agent 也能接收它们！如果你需要向 agent 发送一条记录（甚至多条记录）的多个字段，不要创建多个变量，而是为该数据创建一个记录变量或记录集合变量，并设为可输出。
例如，agent 请求客户未结案例的四个字段，与其用四个独立变量，不如用一个记录变量返回这四个字段；若要返回多个案例，则用一个记录集合变量。agent 收到全部数据后，会在呈现给客户时先把数据整理成易读的格式。
别让 Flow 过度喂数据给 Agent
当 agent 从 Flow 收到数据时，它倾向于认为这些数据应该被用于某种用途——可能用它做决策、不必要地展示给客户，甚至可能把客户不该看到的数据展示出来。因此，永远不要给 agent 任何你不想让它使用的数据。
可惜这条规则与 Flow 的默认 Get Records 配置相悖——默认的「How to Store Record Data」是「自动存储所有字段」，但 agent 通常不需要所有字段。
改成选择 「Choose fields and assign variables」，用一个独立的记录变量，只选 agent 需要的字段。
给 Agent 正确的权限
面向员工的 agent 使用与之交互的用户的权限，而面向外部的 agent 使用单个专用用户的权限。因为 agent 只要有正确权限就能访问你所有的 Salesforce 数据，给它过多访问权限是有风险的，所以务必确保每个 agent 的专用用户只拥有它需要的权限。
要控制 agent 的权限，先在 Agentforce Builder 的 Agent Details 页面上找到分配给它的 Agent User。
找到 Agent User 后，给它运行 Flow、服务客户所需的 permission set、profile 和 role。
构建多个小 Flow，而非一个大 Flow
agent 受益于模块化设计：许多各自完成一项任务的小操作，可以多种方式组合、跨多个 agent 复用。
边界通常由操作本身定义：改变商机阶段是一项操作、由一个 Flow 完成；不改变阶段而单独改变关闭日期是另一项操作、由另一个 Flow 完成。但你不必为 Stage 字段的每个可能值都建独立操作/Flow，因为 Flow 可以用 Update Records 元素把字段设成任何被请求的值。
交互点也是设置 Flow 边界的绝佳方式——agent 不能在 Flow 执行中途向客户提问，所以任何需要展示信息或询问下一步的地方，通常都是好的边界。
考虑（上）：别向变量发送过长的文本
文本变量最多只能容纳 255 个字符，超出部分会被截断。把未知长度的文本赋给文本数据类型的输入变量时要格外小心。
如果需要向 Flow 发送超过 255 字符的文本，应找开发人员创建一个 Apex 定义的变量来代替。
考虑（下）：让文本尽可能清晰
尽你所能帮助 agent 理解上下文和指令：使用语法、拼写、标点正确的完整句子。
如果输入文本的位置不能用空格（如变量的 API Name），就在单词之间加下划线以增加清晰度。例如用 Account_ING_Number 而不是 AccountINGNumber。
避免不兼容的输出数据类型
这些复杂数据类型无法通过输出变量传回给 agent：
- Currency（货币）
- Picklist（下拉列表）
- Multi-Select Picklist（多选下拉）
- Apex-Defined（Apex 定义）
如果 Flow 被配置为把这些类型之一传给 agent，agent 将无法再处理任何输出变量——这是一种静默的完全失败。所以设计输出变量时，坚持用 Text、Number、Boolean、Date 或记录变量等简单类型。
改变变量后要重建 Agent 操作
一个微妙之处：当你从 Flow 创建 agent 操作时，该操作会对 Flow 的输入输出变量做一次性快照。这个快照是静态的——之后你改了 Flow 的变量，它也不会更新。
如果 agent 用过时的变量运行 Flow，就会出问题。修复方法简单但不直观：删除该 agent 操作，新建一个，再重新把 Flow 分配给该操作。每次编辑一个已接入 agent 的 Flow 时都要记住这一点。
二、创建 Agent-Ready Flow（Create an Agent-Ready Flow）
本单元动手实践。你将为 Coral Cloud Resorts 创建一个 agent-ready Flow，用来检索客人即将到来的预订活动。先规划交互流程，然后创建 Flow 及其输入输出变量，配置 Get Records 元素精确抓取正确的预订，最后加上故障路径的错误处理。
完成本单元后，你将能够：
- 为 agent-ready Flow 选择正确的 Flow 类型；
- 创建 agent-ready Flow 所需的变量；
- 配置 Get Records 元素向 agent 发送正确数据；
- 配置 Flow 只在需要时向 agent 发送错误消息。
注册 Agentforce 的 Developer Edition Org
本模块需要一个已启用 Agentforce 的特殊 Developer Edition org（专为本 badge 设计）。
- 注册免费的 带 Agentforce 的 Developer Edition org：填有效邮箱、唯一用户名，点击 Sign me up。
- 收到激活邮件后打开并点击 Verify Account。
- 设置密码和密保问题完成注册并登录。
然后把新 org 连接到 Trailhead：在 Challenge 区域点击 playground 名称，点击 Connect Org，输入凭据，点击 Allow，再点击 Yes! Save it。
规划 Agent 的需求
构建自动化之前，先规划。通用套路是：决定 agent 要做什么 → 创建 agent 将运行的 Flow → 创建一个子 agent 处理一组相关任务 → 在该子 agent 上创建引用这些 Flow 的 agent 操作。
本场景：为 Coral Cloud Resorts 构建一个 agent，帮客户管理他们预订的活动（存在 Bookings 对象里）。幸运的是，org 里已有 Get Customer Details Flow——它接收客户的邮箱和会员号、返回联系人 ID，而这个联系人 ID 就是新 Flow 的输入。
交互流程：客户请求查看预订 → agent 询问姓名和会员号验证 → 运行 Get Customer Details 拿到联系人 ID → 运行新的 Get Contact's Upcoming Bookings Flow（传入联系人 ID）→ 返回即将到来且未取消的预订 → 展示给客户。通过串联小型独立任务，agent 就能拿到所需全部数据。
创建 Flow 及其变量
先创建自动启动 Flow（务必选 Autolaunched Flow (No Trigger) 类型），然后添加三个资源：
- Contact_ID（Text，输入）：要为其查找预订的联系人 ID。
- Contact_Bookings（Record 集合，Booking 对象，输出）：即将到来的预订。
- Error_Message_Output（Text，输出）：Flow 失败时展示的错误消息。
给每个变量写清描述——agent 正是靠读这些描述来理解每个变量的用途。
获取客户的预订（Get the Customer's Bookings）
创建一个 Get Records 元素来检索客户的预订：
- Object 选 Booking；
- 三个条件（AND）：Contact 等于 Contact_ID、Date 大于今天（CurrentDate）、Is Canceled 等于 False；
- 按 Date 升序排序；
- 「How to Store Record Data」选 Choose fields and assign variables (advanced)，赋给 Contact_Bookings，只选 Experience_Name__c、Date__c、Start_Time__c、End_Time__c 四个字段。
这正是「别过度喂数据给 agent」原则的实践。
给 Flow 加错误处理
故障路径（fault path）只在它挂接的元素失败时运行。给 Get Records 元素加一条故障路径：
- 在 Get Contact's Upcoming Bookings 元素上选择 Add Fault Path。
- 在该故障路径上放一个 Assignment 元素，把 Error_Message_Output 设为对客户友好的消息，例如「很抱歉，我找不到您的预订活动，您希望联系我们的支持团队吗？」。
最后给 Flow 写 Label 和描述并激活——Flow 必须处于激活状态才能被分配为 agent 操作。
三、把 Flow 添加为 Agent 操作（Add a Flow as an Agent Action）
本单元把 Flow 接入 agent。你要确认 Agentforce 已启用，创建一个管理预订活动的子 agent，把两个 Flow 添加为 agent 操作，在脚本中修正记录集合输出，给子 agent 写清晰的推理指令，最后在 Preview 标签页中测试。最终，Coral Cloud Booking Agent 能从一句提示中检索客人的即将到来的活动。
完成本单元后，你将能够：
- 用基于 Flow 的 agent 操作，让子 agent 发挥最大效用；
- 创建引用 Flow 的 agent 操作；
- 配置子 agent，让一个 agent 操作向另一个提供数据。
设置 Agentforce
接入 Flow 之前，先确认 Agentforce 已启用：
- 在 Setup Quick Find 中搜索并选择 Einstein Setup，确认 Einstein 已开启（若已开启，先关再开以重置）。
- 刷新浏览器。
- 搜索并选择 Agentforce Agents，确认 Agentforce 为 On。
两个都启用后，就可以添加子 agent 及其 Flow 操作了。
添加子 Agent（Add a Subagent）
在 Agentforce Studio 中打开 Coral Cloud Booking Agent，新建一个名为 Booked Activity Management 的子 agent。三条接地准则很重要：
- 描述相关 Salesforce 对象（Bookings、Contacts）及其用途，让 agent 理解数据。
- 告诉它不要使用任何不是由操作输出提供的数据——否则 agent 会看到权限允许的一切。
- 告诉它不要向客户展示任何 ID 值——记录集合总包含记录 ID，而这些 ID 对客户无意义、只会造成困惑。
添加 Get Customer Details 操作
把第一个 Flow 添加为 agent 操作：
- 在 Actions Available for Reasoning 下，创建自定义操作 Get Customer Details，Reference Action Type 选 Flow，选 Get Customer Details Flow。
- 对两个输入（email、memberNumber）勾选 Require input to execute action，确保 Flow 没有所需数据时不运行。
- 对输出（contact）勾选 Show in conversation，允许 agent 把该变量内容发给客户。
然后在画布上确认 email 和 memberNumber 变量设为 Agent Populated——若不是，删除操作重新创建。
添加 Get Contact's Upcoming Bookings 操作
现在把预订 Flow 添加为操作。创建自定义操作 Get Contact's Upcoming Bookings，引用同名 Flow：
- 输入 Contact_ID：勾选 Require input to execute action。
- 输出 Contact_Bookings：勾选 Show in conversation。
- 输出 Error_Message_Output：勾选 Show in conversation。
注意一个规律：操作的默认描述与你写在 Flow 变量上的描述一致——这正是「Flow 里写清描述」如此重要的原因。最后保存，并把 Agent's User Record 选为 EinsteinServiceAgent User。
更新 Contact_Bookings 输出
有一个微妙的修正：记录集合变量需要在子 agent 的脚本里做特殊配置。
- 切换到 Script 标签页；
- 找到 Contact_Bookings 行，把类型从
object改成list[object]； - 再往下几行，把
complex_data_type_name: "lightning__listType"改成"lightning__recordInfoType"； - 保存，切回 Canvas。
给子 Agent 写指令
现在写子 agent 的推理指令——这是 agent 学习如何行事的地方：
- 先讲职责：只帮 Coral Cloud Resort 客人预订、查看、取消活动；不使用任何非操作输出提供的 Salesforce 数据；不向客户展示 ID 值。
- 如果客户询问当前预订的活动，运行 Get_Contact_s_Upcoming_Bookings 操作并展示输出。
- 展示活动列表后，询问还能帮什么。
- 如果客户身份未知，必须先索取邮箱和会员号，运行 Get_Customer_Details 操作后再运行其他操作。
输入 @ 可引用具体操作，让 Agentforce Builder 直接把操作接进指令。
测试 Agent
在 Agentforce Builder 的 Preview 标签页测试：
- 点击 Preview 标签页。
- 输入
Can you show me my booked activities?并回车。 - agent 要求验证后，输入
I am sofiarodriguez@example.com and my membership number is 10008155并回车。
agent 会按顺序运行两个 Flow，返回 Sofia 当前预订活动的列表。恭喜——你创建了一个让 agent 更准确、更强大的 Flow，并给了它持续运行该 Flow 所需的指令。