在当今互联互通的世界中，Agentforce 的多语言支持已不仅仅是一个锦上添花的功能，而是一个解锁全球机遇的战略要务。 作为 Salesforce 的 AI 代理平台，Agentforce 致力于构建一个能够理解并用用户母语进行交流的智能代理。 然而，实现真正意义上的 AI 代理多语言化 并非易事，它需要对代理理解意图、调用动作、检索知识和生成响应的整个流程进行彻底的重新思考。 本文将深入探讨 Agentforce 如何构建并测试其多语言能力，揭示其背后的技术挑战、解决方案和实践经验。

挑战：超越简单的机器翻译

最初，有人提出简单的解决方案，比如使用 “Google 翻译” 或 “ChatGPT” 直接翻译代理的输出。 然而，Agentforce 的团队很快意识到，仅仅依靠机器翻译是远远不够的，甚至可能导致令人啼笑皆非的错误。

例如，当用户用西班牙语提问关于 Salesforce 报告的问题，但所有相关的知识都以英语存储时，简单的翻译方法可能会将用户的西班牙语问题翻译成英语，然后检索英文答案，再将英文答案翻译回西班牙语。 这种方法看似可行，但实际上会面临诸多问题：

• 语境和细微差别的丢失：关键的领域术语在翻译过程中往往会丢失其精确的含义。例如，英文的 “account record” 在法语中被翻译成 “compte rendu”（字面意思是 “帐户报告”），这不仅不准确，而且完全改变了原本的含义。
• 检索失败：Agentforce 采用检索增强生成（Retrieval-Augmented Generation）技术，利用知识库和文件检索相关信息。 如果搜索查询被翻译成与知识文章不同的语言，检索结果可能会为空或无关。 反之，如果只在用户的语言中搜索，可能会错过包含答案的英文文章。 简单地自动翻译查询或文章，而不进行更深层次的逻辑处理，往往会导致无法找到答案。
• 推理不匹配：AI 的推理过程（即内部的 “思维链”）在以单一语言进行时效果最佳（目前是英语）。 强迫 AI 在一种语言中思考，但在另一种语言中回应，可能会降低其连贯性。 让模型以用户的语言进行规划和推理，可能会产生比在最后一步进行翻译更流畅、更符合语境的答案。

这些问题表明，语言不仅仅是一个表面层，它从根本上塑造着理解。 因此，Agentforce 团队得出结论：必须将多语言支持嵌入到整个技术栈中，从用户消息进入系统的那一刻起，直到意图识别、操作调用、槽填充、知识检索和最终响应，代理都需要意识到并流利地使用正确的语言。

解决方案：以用户语言为中心的设计

Agentforce 的多语言化始于 “Hello”。当用户开始对话时，系统需要知道用户所说的语言，并且需要将此信息贯穿整个对话过程。 Agentforce 引入了 “最终用户语言” 上下文变量，该变量由客户端应用程序（例如，聊天窗口或应用程序）在会话开始时定义。

在 Web 聊天场景中，用户的浏览器区域设置或预聊天下拉列表可以设置此变量； 在内部员工代理中，使用用户的个人资料语言。 此上下文变量像双语护照一样与用户的会话一起传递。

至关重要的是，Agentforce 的推理引擎（即编排大脑）使用 “最终用户语言” 来决定代理的工作语言。 这里有一些巧妙的逻辑：”有效” 语言是基于几个因素来确定的。 首先，用户的语言偏好（上下文变量）通常占主导地位——如果用户喜欢日语，代理也应该使用日语。 但也要考虑代理配置的语言：每个 Agentforce 代理都有一个主要（默认）语言和可选的辅助语言。 如果用户使用的语言代理未设置，系统将优雅地回退到代理的默认语言。 例如，如果代理仅支持英语和法语，而用户用瑞典语发送消息，则代理将默认为英语，而不是尝试瑞典语。

推理器（或计划器）还会注意正在使用的操作和目标数据源，因为这些可能会影响语言行为。 所有这些输入组合起来形成一个本地化上下文——本质上是 “我们现在说法语” ——并传播到整个管道中。

更重要的是，这个过程不是一劳永逸的。用户可以在对话中途切换语言，Agentforce 必须跟上。 假设客户开始用加泰罗尼亚语聊天，然后输入 “¿Puedes ayudar con otra cosa？”（西班牙语，意思是 “你能帮我做其他事情吗？”）。 Agentforce 的系统会动态检测到语言切换（通过计划器中的语言检测步骤），并更新后续对话的本地化上下文。 从那时起，代理将无缝地以西班牙语回复。 这种动态切换至关重要——Agentforce 团队在早期发现许多双语用户会进行代码切换，或者代理可能会在不同语言的用户之间转移。 现在，这些更改会被跟踪并被代理实时获取。

技术实现：行动和槽位的多语言支持

了解用户的语言是第一步，在所有地方都使用它才是第二步。 Agentforce 代理由操作驱动——一些预定义的 “系统” 操作（如创建记录、查询数据库或使用知识回答问题）和一些自定义操作。 Agentforce 必须确保每个操作都具有本地化意识。

值得庆幸的是，许多操作都可以自动使用推理器（或计划器）的本地化上下文。 例如，Agentforce 的提示模板操作（用于格式化大型语言模型的提示）会自动在后台附加一个指令，例如 “以用户的语言回复”。 这意味着如果用户是意大利语，LLM 收到的提示将包含类似 “（用户的语言是意大利语，用意大利语回答。）” 的内容——因此模型自然会用意大利语回复。 诸如系统消息（例如，代理的问候语或诸如 “正在搜索记录……” 之类的进度更新）之类的标准输出也会根据该上下文生成或翻译。 Agentforce 团队教会代理用德语说 “Looking up that information…” 作为 “Ich suche diese Information…” 等，适用于所有受支持的语言。

但是，对于某些操作，Agentforce 团队必须亲力亲为。 如果某个操作绕过了计划器的正常提示流程——比如调用内部 API 或外部服务——那么操作所有者（即开发者）必须手动传递语言上下文。 一个很好的例子是 “查询记录” 操作（允许代理运行数据库查询）：它最初根本没有考虑语言，因为数据库内容与语言无关。 但是输出——如字段名称或成功消息——需要本地化。 Agentforce 团队更新了此类操作以显式获取本地化上下文并在撰写结果时使用它。 同样，任何连接到外部服务（可能是第三方 API 或自定义系统）的操作都必须转发 “locale”，以便该服务以正确的语言返回文本/内容。

Agentforce 团队为操作开发人员创建了清单：

• 您的操作是否直接调用 LLM？
• 您的操作是否使用外部服务？
• 您的操作是否生成任何面向用户的文本？

如果对任何一个问题的回答是 “是”，请确保本地化上下文已贯穿每个函数调用。 这是一个艰苦的审查过程，但很有必要——错过任何上下文传递都可能导致在其他情况下以西班牙语进行的对话中弹出英语句子。

甚至槽填充——代理收集操作参数的方式——也需要语言方面的支持。 例如，一个操作可能会问 “您对哪个帐户感兴趣？”，在法语中应该是 “Quel compte vous intéresse ?”。 Agentforce 利用 Salesforce 的翻译机制来实现此类提示。 每个操作的输入和输出都有一个标题和描述元数据（出现在 UI 中或有助于形成提示的标签）。 Agentforce 团队将这些移至使用 Salesforce 的标准本地化框架：操作开发人员用标签引用替换硬编码的英语文本。 在运行时，这些标签会自动以用户的语言呈现。 Agentforce 团队还将技术描述（用于 LLM 提示构建）与面向用户的描述分开。 技术部分保留为 AI 服务的自然语言，而面向用户的标签可以完全翻译。 这样，当代理（用德语）说 “Ich habe 3 Kontakte gefunden”（“我找到了 3 个联系人”）时，“联系人” 一词来自德语中的翻译标签，而不是来自英语架构。 诸如此类的细节可以保持流畅性和专业性——避免出现难看的语言混合或不一致的术语。

知识检索：跨语言的桥梁

Agentforce 多语言之旅中最棘手的挑战（也是最酷的创新之一）是知识检索。 Agentforce 通常使用知识库（文档、文章，甚至上传的文件）来回答用户的问题。 但是，当用户说一种语言而知识内容是另一种语言时会发生什么？ 这是 Agentforce 团队必须发挥创造力的地方。

最初，Agentforce 的知识搜索遵循语言过滤模式：它只会检索与用户的语言上下文匹配的文章。 在实践中，这意味着如果您的代理正在用西班牙语进行对话，它将查找西班牙语知识文章并忽略其他文章。 这种模式对于许多客户来说非常合理——例如，像富士通这样的公司可能有一个与英语知识库分开的日语知识库，他们希望代理只为日语用户提取日语内容。 系统对此效果很好：Agentforce 团队将本地化上下文传递给搜索索引，检索器组件按该语言环境过滤结果。 如果没有日语文章回答该问题，代理可能会礼貌地说 “我找不到答案”，而不是给出英语答案。 在内部测试中，Agentforce 团队看到这种情况发生：一个中文员工代理没有中文知识文章，所以当用中文提问时，它什么也没返回——它过滤掉了所有的英文文章，因为语言不匹配。 这样做的好处是一致性（没有混合语言的答案）； 缺点是即使另一种语言中存在答案，问题也得不到解答。

Agentforce 为其知识操作（AQWK，“使用知识回答问题”）引入了新的翻译模式。 这是对像辉瑞这样的客户的直接回应，他们维护一个中央英语知识库，但有代理为法语、德语等用户提供服务。在翻译模式下，代理可以桥接语言：有效地将用户的查询翻译成知识库语言，找到答案，然后将答案翻译回用户的语言。 这听起来很简单，但实施起来却是一项壮举。 Agentforce 团队必须决定何时使用翻译与直接检索，如何可靠地进行翻译，以及如何避免任何导致 AI 偏离轨道的错误翻译。

在实践中，Agentforce 团队构建了两种翻译模式并对它们进行了实验。 在一种方法中，计划器获取用户的问题（比如，用德语），并在后台要求 LLM 将其翻译成基本语言（比如，英语）。 知识搜索以英语运行，找到（例如）一篇英语文章摘要作为答案，然后再次提示 LLM 以德语向用户呈现该答案。 用户会看到一个来自英语来源的流利德语答案。 代理甚至可以引用该来源（如果已配置），显示英语文章标题——是的，Agentforce 团队就是否也翻译标题进行了辩论！ （目前，文章标题/描述可以通过 Salesforce 标签进行本地化，否则它们可能会以其原始语言显示——这是一个小的折衷方案）。

Agentforce 团队测试的另一种方法是翻译知识内容本身而不是查询。 这意味着，如果一个法语用户问了一些问题，但只有一篇英语文章，我们会将英语文本提供给 LLM，并指示它以法语总结或回答。 这种方法在很大程度上依赖于 LLM 的翻译能力，并且存在在事实中引入错误的风险，因此 Agentforce 团队对此更加谨慎。 这是一个 Agentforce 团队正在不断完善的领域——这两种方法的混合可能会产生最佳结果。 令人兴奋的是，Agentforce 团队正在为客户提供灵活性：那些每个语言都有严格分离库的客户可以坚持使用语言过滤模式（以获得严格的语言环境保真度），而那些拥有单语言库的客户可以选择加入翻译模式以最大化答案覆盖率。

在幕后，要实现这一点还需要更新 Agentforce 的检索基础设施。 Agentforce 团队与混合搜索团队密切合作，以确保其搜索索引和向量嵌入支持所有这些语言。 幸运的是，现代嵌入模型是多语言的，Agentforce 团队集成了开源多语言嵌入来覆盖从阿拉伯语到越南语的所有语言。 Agentforce 团队为新语言的搜索相关性设置了评估，检查了诸如召回率和 MRR（平均倒数排名）之类的指标，以确认德语查询可以找到德语内容，日语查询可以找到日语内容，等等。

对话流畅性与推理

多语言支持不仅仅是理解用户或检索事实——它还包括代理在说话时听起来是否流畅自然。 用户语言的对话生成和推理需要仔细的提示设计和大量的母语人士测试。

Agentforce 团队指示 LLM 尽可能多地用目标语言思考和回答。 团队注意到，如果系统提示是用英语写的，模型有时可能会滑入英语短语，或者在另一种语言中可能会出现不自然的语调。 这里的解决方案是本地化甚至设置样式或上下文的提示部分。 例如，Agentforce 系统提示可能包含一行，例如：“您是一位乐于助人的客户服务代理。” 在德语模式下，团队会发送：“Du bist ein hilfsbereiter Kundenservice-Agent。” 这里的细微差别在于——该模型可能 “知道” 如何说德语，但是在德语中提供整个上下文可以减少任何疑问。

Agentforce 团队还相信会根据语言调整语调和形式。 在英语中，随意的语调效果很好，但在日语中，用户期望更礼貌的形式。 Agentforce 的提示将融入这些文化规范——例如，在日语中使用 “〜ます/〜です” 形式，或在法语中适当使用正式的 “vous”。 一个来之不易的教训是，直接翻译会在这里出卖你。 团队有一个代理在意大利用 “Sto eseguendo Query Records…” 说，“我正在执行查询记录”，其中 “Query Records” 是一个团队尚未翻译的功能名称。 Agentforce 的意大利语评估员给它打了 2/5 分，说它听起来像 “Italglish”。 现在，团队会翻译或解释功能名称，并避免在句子中间混合语言。

在推理方面，确保代理可以用任何语言处理复杂的查询意味着扩展 Agentforce 的培训和测试。 Agentforce 团队收集了每种语言的示例问题——从简单的常见问题解答到棘手的多部分请求——以了解 LLM 如何解析它们。 令人惊讶的是，由于模型的多语言训练，底层的推理链通常可以在语言之间很好地转移。 如果它可以用英语解决逐步数学问题，它也可能用意大利语解决。 区别全在于表达。 Agentforce 团队发现，一些训练数据较少的语言（比如，爱沙尼亚语或泰语）需要额外的支持——在这些情况下，团队会给模型更多示例，甚至调整温度设置以使其在事实上保持正轨。 经验表明，该模型偶尔会在它不太自信的语言中产生更多的幻觉。 Agentforce 团队的缓解措施：在这些语言中使用更短、更结构化的提示，有时会进行回译检查（让它在内部将其答案翻译成英语以仔细检查含义，然后丢弃翻译）。

测试、调整和 LEHF：人为反馈循环

构建它只是战斗的一半——Agentforce 团队必须无情地测试 Agentforce 的多语言能力。 这就是同理心和规模发挥作用的地方。 Agentforce 团队使用他们所谓的 LEHF（语言评估人为反馈）设置了一个专门的 QA 流程——用通俗的话来说，就是让母语人士用他们的语言对代理的响应进行评分，并将该信息反馈到改进中。 团队再怎么强调这个人工循环阶段的价值都不为过。

首先，Agentforce 团队为每种目标语言招募了流利的说话者（通常是 Salesforce 员工或合作伙伴）。 团队为他们提供了一个 Agentforce 测试环境设置的速成课程（有些人在一周内成为了事实上的 QA 工程师！）。 每位测试人员都用他们的语言创建了一个小型知识库（例如，波兰语中的 100 个常见问题解答）并加载了大约 20 个示例文件，以便代理拥有相关内容。 然后，他们在他们的语言中生成了 120 个问题，以彻底练习代理。 这包括知识文章可以回答的 “域内” 问题，以及旨在挑衅代理并测试其回退行为的 “域外” 问题。 例如，一位法国测试人员可能会问一些可回答的问题，例如 “Comment réinitialiser mon mot de passe Salesforce ?”（由知识文章回答），以及一些无法回答的问题，例如 “Quelle est la météo sur Mars aujourd’hui？”（看看代理是否产生幻觉或优雅地处理它）。

对于代理给出的每个答案，测试人员都会在 0-5 的质量等级上对其进行评分。 Agentforce 团队的标准很严格。 “5” 表示答案非常好——正确、完整且用目标语言书写良好。 “4” 表示良好，只是缺少一些小细节。“3” 是勉强可以接受的——也许代理抓住了要点，但错过了一些重要的东西。 低于此值的任何内容基本上都是失败：“2” 表示错误或不相关的答案，“1” 表示用错误的语言回复或出现严重错误，“0” 表示没有给出任何有用的答案。 值得注意的是，如果代理脱离了用户的语言并用意大利语回复（对于多语言代理来说是不可饶恕的），则立即给 1/5。 团队设定了一个很高的标准：要通过公开 Beta 测试，95% 的答案需要得 4 或 5 分。 换句话说，在让真正的客户大规模使用一种新语言之前，几乎所有答案都必须在清晰度和准确性方面接近完美。 少于 5% 的可以 “还可以”。 这个阈值不容易达到——但团队做到了，通常在经过多次修复和测试周期后。

说实话，测试过程非常紧张。 每次语言评估都会生成一个包含问题、答案、分数和注释的详细电子表格。 Agentforce 的本地化团队和数据科学家仔细研究了结果。 团队寻找模式：代理是否一直误解某个短语？ 所有低分是否都来自某个特定的操作或知识来源？ 例如，在一波测试中，西班牙语和意大利语都难以回答带有日期的问题——团队发现知识文章中的日期格式（“2023-07-15”）没有被代理在这些语言中正确表达。 修复涉及调整提示以指示模型如何呈现日期（例如，“以 DD/MM/YYYY 格式说出意大利语的日期”）。 在另一种情况下，Agentforce 的德国测试人员一直看到代理在答案末尾说 “Kein Problem！”（“没问题！”），这感觉太随意了。 该反馈促使团队调整德国语调，使其更专业。 每一轮 LEHF 都让 Agentforce 在每种语言中都变得更好。 团队本质上是与母语人士共同创造质量，这既令人谦卑又令人敬畏。

所有这些 QA 工作的成果是什么？ 当 Agentforce 团队最终看到分数恢复到 95% 的阈值以上时，那就是香槟时间（实际上，团队在 Meet 上举杯庆祝 🎉）。 只有这样，团队才会将一种语言标记为公开 Beta——这意味着客户可以启用该语言，但团队仍然会建议谨慎并邀请更多反馈。 经过进一步的强化，包括额外的评估，甚至是一些混合自动化测试（例如，使用 LLM 作为辅助意见来判断质量），团队会将该语言提升为 GA（全面可用）。 GA 是 Salesforce 对质量的承诺，因此团队非常重视这一点：对于团队的核心代理类型，Agentforce Authoring 团队亲自认证了每种受支持语言在 GA 之前的性能。 对于由各个团队构建的其他专门代理，团队提供了剧本和支持，但是这些团队必须自己本地化和测试他们的代理才能达到 GA。 这种分散的努力是扩展的关键——每个代理所有者都成为了多语言质量的利益相关者。 它培养了对最终用户的同理心文化； 开发人员突然用荷兰语或韩语阅读他们的代理的输出，并从客户的角度看待它。

全球推广：经验与教训

有了坚实的基础和经过验证的质量，Agentforce 团队开始分批推出语言。 团队根据客户需求和语言多样性的组合来确定语言的优先级。 第一波（亲切地称为 “Wave 1”）解决了 FIGS+JP：法语、意大利语、德语、西班牙语、葡萄牙语和日语——需求量大的主要语言。 团队很快就将这些语言投入公开测试，然后将其用于团队的主要代理类型。 第一次看到 Agentforce 用 “Hola, ¿en qué puedo ayudarte？” 向用户问候时，这让团队感到非常兴奋。

Wave 2 添加了更多欧洲和亚洲语言，例如荷兰语、瑞典语、韩语、简体中文和繁体中文等。 此时，由于 Wave 1 中构建的框架和测试制度，团队的流程更加顺畅——团队知道如何在大约一个月的时间内将一种新语言从准备阶段转移到 Beta 阶段。 Wave 3（在撰写本文时正在进行中）正在引入来自世界各地的语言：阿拉伯语（带有从右到左的 UI 考虑因素）、印地语、泰语、土耳其语、波兰语等。 看到受支持语言的列表增长到几十种，真是令人难以置信。

每一波都教会了团队新的经验。 例如，添加阿拉伯语迫使团队在 UI 中实现 RTL（从右到左）支持——这纯粹是一个视觉挑战，但对于良好的体验至关重要。 添加中文教会了团队，团队的分段算法（团队如何将文本分成块以供模型使用）需要更好地处理基于字符的脚本。 团队真正不得不接受持续改进。

Agentforce 团队还学会了对客户透明化语言支持。 在 Agentforce Builder 界面中，语言最初带有 “Beta” 标签——一个温和的警告，表明质量可能会有所不同，并且客户也应该进行自己的测试。 一旦团队和团队的社区彻底审查了一种语言，团队就会删除 GA 的 Beta 标签。 团队解释说，Beta 意味着 “您可以尝试它，但是质量保证由您负责”，而 GA 意味着 Salesforce 已经验证了 Agentforce 和底层 AI 模型中的质量。 设定正确的期望是另一个教训：一些客户认为 “说日语” 的 AI 也会神奇地了解所有关于日本当地商业法规的信息（它不会——它只知道它被给予或训练过的内容）。 团队确保澄清多语言能力意味着代理可以用这些语言流利地对话，但是客户需要提供任何特定于地区的内容，或者确保荷兰语中的知识库具有荷兰语用户的问题的答案。

最后，从这个旅程中获得的一些来之不易的教训：

• 多语言是一种心态，而不是一项功能。 团队最初认为它是一项功能（“添加新语言 = 切换开关”）。 团队发现它确实是一种触及每个组件的行为。 它需要跨职能部门的支持——从工程师在代码中添加语言环境支持，到数据科学家与模型作斗争，再到 UX 设计师适应界面。 这是一种持续的 “这在其他语言中如何工作？” 的心态，团队现在将其应用于每个新功能。 全球准备就绪不是一次性项目； 这是一种构建软件的方式。
• 永不假设，始终测试（用每种语言）。 您可能会假设，如果代理可以用英语处理某个查询，它也可以用意大利语处理。 团队学会了测试甚至 “显而易见” 的事情。 微小的差异——这里有一个较长的单词，那里缺少一个礼貌的粒子——可能会破坏事情。 一个有趣的错误：意大利语中 “编辑” 一词是 “modifica”，代理一直将其解释为 “修改汽车”。 修复涉及调整团队的 NLP 解析以适应该单词，如果没有在实地测试，团队永远不会发现这一点。 这教会了团队谦逊：始终使用母语输入进行测试，并在可能的情况下让母语人士参与其中。 自动化和指标有助于标记问题，但是人类直觉和文化背景解决了问题。

通过所有这些，Agentforce 团队的驱动力是同理心——站在巴黎、东京、里约或孟买用户的角度，并确保他们的体验是一流的。 这是一条漫长的道路，但是听到诸如 “这就像代理真的会说我们的语言！” 之类的反馈，一切都是值得的。

总结：拥抱全球化的 AI 代理

Agentforce 的多语言支持不仅仅是一个技术里程碑； 它是一个技术可以具有包容性和全球可访问性的承诺。 Agentforce 团队正在继续扩展语言支持（如果您的语言尚未上线，请相信我，它已经在路线图上！）。 与此同时，您可以看到 Salesforce 对本地化的承诺。 亲自查看 Salesforce 的多个语言站点！

建立能够流利地对话和在数十种语言中进行推理的代理一直是一个最具挑战性和回报的项目。 它强化了多语言准备就绪不是一个可以切换的开关，而是一个设计、测试和迭代的过程。 从意图分类到操作执行，从检索到生成，每一层都经过精心设计，以尊重用户的语言。 Agentforce 团队的辛勤工作是真实的，规模是全球性的，同理心至关重要。 下次您用您的母语与 AI 代理聊天，并且它真正理解您时，请记住：在那神奇的时刻背后付出了大量的工作。 Agentforce 团队才刚刚开始——Agentforce 正在学习用一种语言一次向整个世界问好。