使用爱因斯坦机器人增强客户互动：我的经验与教训

二月 06, 2026

当团队决定引入 Einstein Bots 来提升客户服务自动化水平时，我对这个工具充满了期待。毕竟，在 Salesforce 生态里，它能如此紧密地与我们的数据和服务流程集成，这本身就是一大优势。然而，就像任何一项新技术一样，从概念到实际落地，总会遇到一些意想不到的挑战。这篇文章，就是我在这段旅程中，遇到的一些问题、我的思考以及最终的解决方案。

初期困惑：意图识别的“黑箱”与我的“心智模型”

问题起源：为什么它总猜错我的意思？

我们遇到的第一个核心问题，就是 Bot 的意图（Intent）识别准确率。在最初的测试阶段，Bot 经常会把用户的问句导向错误的对话流。比如，用户明明想查询订单状态，却被匹配到了“修改个人信息”的对话。这让我很沮丧，感觉 Bot 就像一个“黑箱”，我不知道它是如何做出判断的。

当时我一度怀疑是不是我们提供的训练语句（Utterances）不够多，或者不够多样化。我们尝试着为每个意图添加了大量的训练语句，结果发现，有时候训练语句越多，反而越容易造成意图之间的混淆，因为有些语句在语义上存在模糊地带。

我的判断与取舍：在“量”与“质”之间寻找平衡

避免意图间的过度重叠：我开始意识到，意图识别不是简单的关键词匹配，而是要让每个意图有其独特的“语义指纹”。如果两个意图的训练语句有太多共性，Bot 就会难以区分。我采取的策略是，在定义新意图时，先快速评估其与现有意图的潜在重叠风险。
侧重“高质量”训练语句：我不再盲目追求数量，而是更注重训练语句的质量和多样性。例如，针对“查询订单状态”这个意图，我不仅会提供“我的订单到哪了？”“我想查一下订单状态”，还会加入一些更口语化、甚至带错别字的变体，比如“订单咋样了”“查单”。但重要的是，这些变体要保持意图的唯一性。
利用“增强意图”和“意图集”：随着 Bot 功能的扩展，我发现单纯依靠单一意图已经不够。Salesforce 提供了“增强意图（Enhanced Intents）”和“意图集（Intent Sets）”功能。增强意图允许我们通过数据模型来更好地识别意图中的实体，而意图集则允许我们对特定场景下的意图进行分组，避免全局性的意图混淆。例如，在用户已经进入“订单管理”的对话流后，可以激活一个只包含订单相关意图的意图集，从而缩小 Bot 的“监听范围”，提高准确性。

当时的理解：这不是一个纯粹的编程问题

当时我意识到，Einstein Bots 的意图识别更像是一个“语料调优”的工作，而不是一个纯粹的编程问题。它需要我们站在用户的角度去思考，用户可能怎么问，并且不断地测试和迭代。我经常会用 Bot Builder 里的测试功能，模拟各种用户的提问方式，然后观察 Bot 的响应。这虽然费时，但却是最直接了解 Bot “思维”方式的方法。

对话流的“意大利面条”困境与模块化思考

问题起源：对话流越来越难维护

当 Bot 的功能逐渐增多，对话流的数量也随之暴涨。最初，每个功能我们都设计成一个独立的对话流。但这很快就导致了问题：

重复逻辑：很多对话流都需要做类似的判断，比如“欢迎语”、“询问用户类型”、“处理异常输入”等。这些逻辑在不同的对话流中被重复构建，导致一旦某个通用逻辑需要修改，就得在好几个地方手动调整。
维护困难：一个复杂的对话流，里面的“消息”、“问题”、“操作”节点交织在一起，就像一盘“意大利面条”。要理解其完整路径和状态变化，需要耗费大量精力。
协作瓶颈：如果多个开发者同时处理 Bot，很容易因为修改了同一个对话流的不同部分而产生冲突，或者因为不清楚其他人的逻辑而引入 Bug。

我的判断与取舍：借鉴软件工程的模块化思想

为了解决这个问题，我开始尝试将软件工程中的模块化思想引入到 Bot 的设计中。

创建可重用“对话块”：我开始识别出那些可以在多个对话流中复用的逻辑片段，并将它们抽象成独立的、可被调用的“对话块”（Sub-Dialog）。例如，“用户身份验证”、“获取订单号”、“转接人工服务”等，都被设计成独立的对话流，并在需要时通过“Transfer to Dialog”步骤进行调用。

明确变量的输入输出：为了让这些“对话块”真正有用，我非常重视变量的传递。每个“对话块”都应该有清晰的输入变量（从调用方接收数据）和输出变量（将处理结果返回给调用方）。这类似于函数调用时的参数和返回值。


// 调用一个子对话流，并传递参数
Bot Action: Transfer to Dialog
    Dialog: AuthenticateUser
    Input Variables:
        UserEmail: {!Bot.UserEmail}

// 在子对话流中，处理后设置输出变量
Bot Action: Set Variable
    Variable: Dialog.IsAuthenticated
    Value: True

使用“上下文变量”管理会话状态：Salesforce Einstein Bots 提供了多种变量类型，其中“Bot Variable”和“Context Variable”是管理会话状态的关键。我倾向于将全局性、跨多个对话流共享的状态信息（如用户ID、当前会话的主题等）存储在 Context Variable 中，而将特定于某个对话流的临时数据存储在 Bot Variable 中。这有助于清晰地管理会话状态，避免变量污染。

为什么这么做：提升可维护性与可扩展性

这种模块化的设计极大地提升了 Bot 的可维护性。当“转接人工”的逻辑需要修改时，我只需要改动“转接人工服务”这一个对话流即可，而不用担心影响其他地方。同时，它也提高了可扩展性，新功能可以通过组合现有的“对话块”来快速实现。

连接“大脑”与“四肢”：通过 Flow 集成 Salesforce 后端逻辑

问题起源：Bot 如何“执行”操作？

Bot 最重要的价值之一是能够与 Salesforce 后端数据和业务逻辑进行交互，而不仅仅是聊天。我们需要 Bot 能够查询客户信息、创建 Case、更新记录等。最初，我考虑过直接通过 Apex Class 来实现这些功能，但很快发现了一些限制：

开发效率：每次后端逻辑调整都需要编写和部署 Apex 代码，这对于快速迭代的 Bot 来说，效率不高。
维护成本：Bot 开发者可能不总是专业的 Apex 开发者，维护成本相对较高。
权限管理：Apex Class 的权限管理也需要仔细考虑。

我的判断与取舍：Flow 是连接 Bot 与 Salesforce 业务逻辑的“最佳搭档”

经过一番研究和尝试，我发现 Salesforce Flow（流）是连接 Einstein Bots 与后端业务逻辑的理想选择。

声明式自动化：Flow 提供了强大的声明式自动化能力，我可以不写一行代码就实现复杂的业务逻辑，比如查询记录、更新字段、创建新记录、甚至调用外部服务。这大大加快了开发速度。
输入与输出的无缝对接：Einstein Bots 可以非常方便地调用 Flow，并传递 Bot 中的变量作为 Flow 的输入，同时接收 Flow 的输出并将其存储为 Bot 变量。
```
// Bot Action: Call Flow
// Flow Name: QueryCustomerCase
// Input Mapping:
//   Flow Input Variable   ->   Bot Variable
//   CustomerEmail         ->   {!Bot.CustomerEmail}

// Output Mapping:
//   Flow Output Variable  ->   Bot Variable
//   CaseNumber            ->   {!Bot.LastCaseNumber}
//   CaseStatus            ->   {!Bot.LastCaseStatus}
        
```
当时配置这一块，我特别注意了 Flow 的“可从 Bot 调用”设置，以及其输入输出变量的 API 名称。一旦名称匹配不正确，Bot 就无法正确地与 Flow 通信。
权限管理：确保运行 Bot 的用户（即 Einstein Bot 用户）具有执行相关 Flow 和访问 Salesforce 对象的权限至关重要。我发现很多时候 Bot 无法正常工作，就是因为 Bot 用户缺少了某个对象的读写权限，或者 Flow 的执行权限。这需要我们在配置文件和权限集中仔细配置。

为什么这么做：效率、维护性与低代码

选择 Flow 作为主要集成方式，是因为它在效率、维护性和低代码方面都有显著优势。它让非开发者也能理解和修改后端逻辑，降低了 Bot 的维护门槛，并且能够更好地适应业务的快速变化。当然，对于特别复杂的、需要事务控制或高性能的逻辑，Apex 仍然是不可替代的，但对于 Bot 常见的交互场景，Flow 已经足够强大。

我的当前看法与未解决的挑战

总的来说，Einstein Bots 是一个强大且富有潜力的工具，它极大地拓展了 Salesforce 在客户服务自动化领域的边界。通过解决意图识别、对话流设计和后端集成这些核心问题，我们已经能够构建出相当智能和实用的 Bot。

我目前对它的看法是：

设计思维优先： Bot 的成功不仅仅是技术实现，更在于良好的用户体验设计和对会话逻辑的深入理解。
迭代是关键： 没有任何一个 Bot 可以在第一次设计就完美无缺。持续的用户反馈、数据分析和迭代优化是其成长的必由之路。
Flow是其“神经中枢”： 充分利用 Flow 的能力，能够极大释放 Bot 与 Salesforce 平台集成的潜力。

当然，挑战依然存在。例如，如何更好地处理多语言支持（特别是对意图训练的影响），以及如何更精细地管理 Bot 在不同渠道（Web Chat, SMS, WhatsApp）的用户体验差异，这些都是我们未来需要持续探索和优化的方向。特别是当会话变得非常复杂，涉及多个轮次和大量上下文信息时，如何确保 Bot 始终能理解用户意图并保持连贯性，这仍然是一个值得深入研究的课题。

Salesforce中文网