确保流支持智能体
学习目标
完成本单元后，您将能够：
- 创建一个可以分配给智能体操作的流。
- 为智能体操作流中的资源编写有意义的名称和描述。
- 在智能体操作流中创建合适的变量。
- 限制智能体及其相关流可以访问的数据。
此徽章要求您熟悉流并有使用 Flow Builder 的经验。请按照使用 Flow Builder 构建流学习路径，培养强大的流自动化技能，成为 Flow Builder 专家。
为什么应该在智能体中使用流
Agentforce 是一款功能强大的工具，能够为您的用户和客户提供卓越的服务，而其强大的功能很大程度上源于流。虽然智能体可以访问 Salesforce 数据，但如果没有智能体操作，则无法直接更改这些数据。如果您希望智能体创建、更新或删除记录，则需要定义一个能够更改数据的智能体操作。智能体操作可以调用 Apex 类、进行 API 调用、运行流或引用提示模板，但只有流才能以低代码的方式更改 Salesforce 组织的数据。
流还能在确保智能体使用特定数据时提高准确性。智能体可以读取您授予其权限的任何 Salesforce 数据，并使用他们认为相关的任何数据。为了限制智能体使用的数据并大幅提高其准确性，创建流，用于检索特定、精确的数据并将其提供给智能体。然后向智能体发出指令，仅使用该流提供的数据。
那么，要创建基于流的智能体操作，需要做什么呢？
创建自动启动流（无触发器）
智能体操作仅支持自动启动流（无触发器）类型的流。虽然其他流类型（例如记录触发流）在技术上也可以被视为自动启动流，但指定的流必须是无触发器类型。如果您想在智能体操作中使用现有流，但该流并非此类型，则必须使用自动启动流（无触发器）类型重新创建流。
详细描述
AI 技术高度依赖文字。要想让 AI 生成文本并获得良好的效果，必须提供详细的指令，并且需要详细准确的源文本。对于任何想要作为智能体操作运行的流，情况也是如此。
智能体会利用流中的变量名称以及流正在处理的数据来理解流的功能。因此，流的输入和输出变量使用准确且描述性的名称至关重要。避免使用像“foo”这样的变量名称。而应使用像“Account_ID”这样具有描述性的变量名称。
虽然为流中的所有内容添加描述已经是最佳实践，但当流由智能体操作运行时，这一点就显得尤为重要。智能体会使用流的描述及其变量的描述。所有这些文本都有助于智能体理解流的功能以及流正在处理的数据。如果没有明确的名称和描述，智能体就无法准确地确定如何处理某个变量及其所包含的数据。
以下是一些清晰和非清晰描述的示例。
文本类型 |
效果欠佳的描述 |
效果良好的描述 |
|---|---|---|
流描述 |
更新电话号码 |
更新用户联系人记录中关联的电话号码。如果不存在匹配的联系人，创建新的联系人记录。 |
流输出变量名称 |
OrderColl |
Sorted_Cupcake_Orders_Collection |
流输出变量描述 |
纸杯蛋糕订单集合 |
一份按客户提供的电子邮件地址匹配、最新排序的顾客的纸杯蛋糕订单合集。 |
注意，流描述比其他描述更具指导性。这是因为当您将流添加到智能体时，流描述会自动成为智能体的指令。将初始流描述编写成智能体指令的形式可以节省时间。
始终使用输入和输出变量
基于流的智能体操作始终需要在流中至少包含一个输入变量和一个输出变量。即使并非必须包含这些变量，最佳实践仍然是使用输入和输出变量。为流提供更多上下文信息，流会更加精确；当流发送正确的数据时，智能体性能也会更佳。
即使您一时想不到要传递给智能体任何数据，也总有一项内容应该考虑通过输出变量来发送：错误提示。智能体期望流返回某种结果，即使该结果仅仅是流的“您的流已结束”消息。但流可能会失败，并导致意外错误。如果没有来自流的任何数据，您的智能体很可能会道歉并提供一条“出错了”的通用消息。或者，它可能会向客户显示其他数据，但没有任何上下文，仅仅因为它想显示某些内容。
为了避免这种情况（同时也为了满足输出变量的要求），创建输出变量，用于显示更详细、更有用的错误提示。在流中使用故障路径和分配元素，将错误提示设置到输出变量中。然后，确保告知智能体如何以及何时使用该输出变量。您将在下一单元了解如何进行配置。
不要担心记录变量
记录变量不仅限于流内部使用。智能体也可以接收记录变量！如果您需要向智能体发送来自一条记录甚至多条记录的多个字段，请不要创建多个变量。相反，只需为这些数据创建一个记录变量或记录集合变量，并将其设置为可输出即可。假设您的智能体需要从客户的未处理个案中获取四个字段。与其使用四个单独的变量，不如将这四个个案字段放在一个记录变量中返回。如果您需要返回多个个案，也可以将它们放在单独的记录集合变量中返回。
您的智能体随后会收到所有数据并加以利用。如果智能体的指令要求将记录数据呈现给客户，智能体会首先将这些数据整理成有用的、便于阅读的格式。
不要让流过大而影响智能体
当智能体从流中接收到数据时，它往往会认为这些数据应该用于某种用途。它可能会利用这些数据做出决策，或者向客户展示不必要的数据。它甚至可能向客户展示他们不应该看到的数据。因此，绝不应该向智能体提供任何您不希望它使用的数据。
遗憾的是，此规则与流的默认 Get Records（获取记录）配置相冲突。How to Store Record Data（如何存储记录数据）设置的默认值为 Automatically store all fields（自动存储所有字段），但智能体可能并不需要这些全部字段。因此，请选择 Choose fields and assign variables（选择字段并分配变量）设置，使用单独的记录变量，并仅选择智能体需要的字段。
为智能体分配适当的权限
面向员工的智能体使用与其交互的用户权限，而面向外部的智能体则使用单独的专用用户的权限。由于智能体如果拥有相应的权限，就可以访问 Salesforce 中的所有数据，而授予智能体过多的数据访问权限存在风险，因此务必确保每个智能体的专用用户仅拥有其所需的权限。不要授予其任何不必要的访问权限。
要控制智能体的权限，首先要找到分配给该智能体的 Agent User（智能体用户）。您可以在 Agentforce 生成器中的 Agent Details（智能体详细信息）页面查看和更改此用户。
确定 Agent User（智能体用户）后，为该用户授予运行其流和满足客户请求所需的权限集、简档和角色。
构建多个较小的流，而不是一个大的流
智能体受益于模块化设计：许多小操作，每个操作完成一项任务。这些操作可以以多种方式组合，并在多个智能体之间重复使用。
那么，如何确定怎样划分不同流之间的界限呢？想想如何将流与智能体关联起来的：您需要为每个流创建一个智能体操作。当智能体被要求执行某个操作时，操作本身通常就定义了流的边界。例如，如果智能体可以被要求更改业务机会的阶段，这就是一个操作，由一个流执行。如果智能体还可以被要求在不更改阶段的情况下更改结束日期，这就是另一个操作，由另一个流执行。另一方面，您不需要为 Stage（阶段）字段的每个潜在值都创建一个单独的操作和流，因为流可以使用 Update Records（更新记录）元素将该字段设置为请求的值。
但是，如果请求的操作意味着同时更新 Stage（阶段）和 Close Date（结束日期），则可以使用一个智能体操作流来完成，因为这是一个请求。
交互点也是设定流边界的好方法。智能体不能在流的中途向客户询问信息，因此，如果智能体需要提供信息或询问下一步该做什么，这通常是一个很好的边界。想象一下，在管理业务机会的子智能体中，智能体可能需要执行多个任务。
- 询问客户应该选择使用哪个业务机会。
- 获取有关该业务机会的数据。
- 掌握了正确的数据后，询问客户智能体能提供哪些帮助。
- 执行客户要求的操作。
在这种情景下，一个流可以处理步骤 1 和 2。智能体处理步骤 3。步骤 4 应该是一个或多个单独的流，具体取决于智能体还可以对客户的业务机会记录执行哪些操作。
其他注意事项
以下是在智能体中使用流时需要注意的其他事项。
请勿将过长的文本字符串发送到变量中
文本变量最多只能包含 255 个字符，超出此限制的字符将被截断。因此，在将长度未知的文本分配给文本数据类型的输入变量时务必谨慎。如果要向流发送超过 255 个字符的文本，请与开发人员合作，创建 Apex 定义的变量。
尽量使文本清晰易懂
尽一切可能帮助智能体理解上下文和指令。请使用完整的句子，并确保语法、拼写和标点符号正确。如果您在无法使用空格的位置输入文本（例如变量的 API 名称），请在单词之间添加下划线以提高清晰度。例如，使用 Account_ING_Number 而不是 AccountINGNumber。
避免输出数据类型不兼容
这些复杂的数据类型无法通过输出变量传回智能体。
- 货币
- 选项列表
- 多项选择列表
- Apex 定义
如果您的流配置为将这些数据类型之一传回智能体，则智能体将无法再处理任何输出变量。
如果更改智能体流的变量，则需要重新创建智能体操作
从流创建智能体操作时，该操作会一次性保存流的输入和输出变量快照。该快照是静态的。即使流的变量发生更改，它也不会更新。为避免智能体使用过时的变量运行流时出现问题，您必须删除该智能体操作，新建智能体操作，并将流分配给该智能体操作。