1. 项目概述当AI代理需要“剧本”如果你在Salesforce平台上构建过Agentforce智能代理那么下面这个场景你一定不陌生你精心设计了对话流程反复测试了各种指令满怀信心地将代理部署上线。结果在与真实客户的第一次互动中它就“自由发挥”了——可能跳过了你认为至关重要的合规检查步骤或者以一种你完全没预料到的方式曲解了客户的意图。大型语言模型LLM驱动的推理能力赋予了代理惊人的灵活性但这份灵活性有时恰恰是问题的根源。当业务流程存在严格的顺序要求、必须遵守的法规或者不容出错的确定性步骤时仅靠自然语言指令的“软约束”就显得力不从心了。这正是Salesforce在Spring ‘26版本中推出Agentforce Script的根本原因。在我看来这不仅仅是功能列表上的一个新增项它代表了Salesforce在AI代理可控性问题上的一次范式转变。简单来说Agentforce Script是一种专为定义AI代理在Salesforce内部行为而设计的高级脚本语言。你可以把它想象成给AI代理编写的一部“剧本”在需要精确执行、分毫不差的关键场景中你通过脚本写下确定的台词和动作而在需要临场发挥、灵活应对的对话部分则交给LLM这位“演员”去自然演绎。Salesforce将这种方法称为“混合推理”——在需要精确性的地方使用确定性逻辑在需要适应性的地方保留灵活的AI推理。对于广大的Salesforce管理员和架构师而言这无疑是一个福音。过去要将一个复杂的业务流程例如处理退款、进行合规的身份验证、执行多步骤的案例升级转化为代理的行为往往意味着撰写冗长且充满各种假设的自然语言指令并祈祷LLM能“理解”你的意图。现在你可以用结构化的脚本语言像绘制流程图一样明确地定义每一步该做什么、在什么条件下执行、以及下一步该去哪里。这极大地提升了代理行为的可预测性和可靠性让我们能够放心地将更关键的业务流程交给AI代理来处理。2. 核心设计思路在确定性与灵活性之间架桥在深入代码细节之前理解Agentforce Script背后的设计哲学至关重要。它的核心目标并非取代LLM而是与LLM协同工作在“完全放任的AI”和“僵化死板的代码”之间找到一个完美的平衡点。2.1 传统指令的局限性在Script出现之前我们控制Agentforce代理主要依赖三大构件主题、指令和动作。主题定义了代理可以处理哪些类型的对话或任务。指令用自然语言描述代理应该如何行事、遵循什么规则。动作允许代理调用外部的Apex类、Flow或API来执行具体操作。这套体系对于简单的、线性的任务处理得很好。例如一个“查询天气”的代理指令清晰动作单一。然而一旦业务流程变得复杂涉及多个步骤、条件分支和严格的执行顺序自然语言指令的模糊性就成了阿喀琉斯之踵。LLM可能会因为对指令的细微理解差异或者上下文中的一点干扰就做出不符合预期的决策。我曾亲历一个典型案例一位客户构建了一个处理退款请求的服务代理。标准流程是1验证订单号2检查退货时间窗是否有效3计算退款金额4处理退款。在大多数测试中代理表现正常。但大约每20次对话中会有一次代理在验证订单后直接跳过了时间窗检查试图进行退款计算。对于企业来说这种偶发的流程违规是不可接受的尤其是在涉及财务和合规的环节。2.2 混合推理两全其美的架构Agentforce Script的引入正是为了解决上述确定性缺失的问题。其设计思路可以概括为“该硬则硬该软则软”。“硬”的部分脚本控制对于业务流程中那些必须按特定顺序、无条件或以特定逻辑执行的步骤使用脚本进行“硬编码”。这包括关键数据操作如从Salesforce中查找记录、更新字段、创建新记录。合规与审批步骤如身份验证、合规检查、发送强制性披露信息。核心业务逻辑如计算金额、应用业务规则、判断资格。步骤顺序保障确保A步骤必须在B步骤之前完成。“软”的部分LLM驱动对于需要自然语言理解、生成、以及处理开放式对话的环节则交给LLM自由发挥。这包括理解用户意图解析客户模糊、不完整或多变的表述。生成人性化回复用自然、有同理心的语言与客户沟通。处理意外问题应对脚本未覆盖的边缘情况或用户突然的话题转换。信息收集与澄清以对话的方式引导用户提供脚本所需的信息。这种架构确保了业务流程的脊梁是坚固且可靠的而代理与用户交互的血肉则是灵活且自然的。脚本像铁路轨道保证了列车业务流程不会脱轨LLM则像车厢内的服务可以根据乘客用户的需求提供个性化的体验。2.3 脚本语言定位管理员友好的“准代码”Salesforce将Agentforce Script设计得尽可能易于上手其定位介于自然语言指令和完整的Apex编程之间。相比于自然语言它提供了结构、顺序和确定性。相比于Apex它更声明式、高级且深度集成在低代码的Agentforce Builder环境中。如果你熟悉Salesforce Flow的构建体验那么学习Script会感到非常亲切。它不需要你打开VS Code或理解复杂的面向对象编程概念。脚本编辑器内置了自动完成、语法高亮和错误提示使得管理员和业务专家能够直接将他们的流程知识转化为可执行的代理逻辑。这极大地降低了AI代理开发的技术门槛让更多“流程专家”而不仅仅是“代码专家”能够参与构建强大的AI助手。3. Agentforce Script语法与核心元素解析现在让我们深入到具体的技术层面看看Agentforce Script长什么样以及它的核心构成部件。脚本本质上定义了一个步骤序列每个步骤都有明确的类型和目的。3.1 基本脚本结构一个典型的Agentforce Script在Agentforce Builder的“脚本视图”中呈现。它由一系列按顺序编写的语句块组成。每个块以关键字开头定义了该步骤的类型。一个脚本通常会从收集必要信息开始经过一系列逻辑判断和操作最终达成某个目标或结束对话。注意以下示例代码是基于公开概念和类似逻辑语言的推测性演示用于说明Script的可能形态。实际语法请以Salesforce官方文档为准。// 示例一个简化的客户服务请求处理脚本框架 SCRIPT “处理客户服务请求”: // 步骤1: 使用LLM进行开场白并收集初始信息 PROMPT “友好问候客户并询问他们今天需要什么帮助。识别他们的问题是否属于‘账户查询’、‘订单问题’或‘技术支持’。” // 步骤2: 根据LLM识别的主题进行路由 CONDITION (USER_INTENT “账户查询”): CALL “账户信息处理子脚本” CONDITION (USER_INTENT “订单问题”): CALL “订单问题处理子脚本” CONDITION (USER_INTENT “技术支持”): CALL “技术支持路由子脚本” OTHERWISE: PROMPT “抱歉我暂时无法处理这个问题。让我为您转接人工客服。” // 步骤3: 在子脚本执行后进行满意度调查 ACTION “Log_Interaction_To_Case” // 调用一个Apex方法或Flow记录本次交互 PROMPT “请问我刚才的解答是否解决了您的问题如果还有其他需要请随时告诉我。”3.2 核心步骤类型详解Agentforce Script提供了几种关键的步骤类型让你可以构建复杂的逻辑流。1. PROMPT提示这是将控制权交给LLM的步骤。你在这里定义发送给LLM的“系统提示词”指导它如何与用户进行接下来的对话。作用生成自然语言回复、向用户提问、澄清模糊信息、处理开放式对话。关键属性text: 给LLM的指令。这是最重要的部分需要精心设计。variable_to_store_response: 可选将用户的回复存储到一个变量中供后续步骤使用。实操心得Prompt步骤中的指令应清晰、具体并设定好边界。例如与其说“询问订单详情”不如说“请向用户索要订单号并确认是否是最近30天内的订单”。后者给LLM的指导更明确能产生更可控的对话。2. ACTION动作这是执行确定性操作的步骤。它可以调用外部资源如Salesforce Flow、Apex类或API。作用执行数据操作增删改查、调用外部系统、运行业务逻辑。关键属性type: 动作类型如FlowApexAPI。target: 要调用的Flow名称、Apex类名或API端点。input_parameters: 传递给目标的输入参数通常来自之前步骤设置的变量。output_variable: 可选将动作执行的结果存储到一个变量中。注意事项确保被调用的Flow或Apex方法经过了充分测试且具有健壮的错误处理。脚本的可靠性很大程度上依赖于这些底层动作的可靠性。3. CONDITION条件这是实现分支逻辑的步骤。基于变量的值或表达式的计算结果决定脚本接下来执行哪条路径。作用实现if/else逻辑根据不同的业务情况路由流程。关键属性expression: 布尔表达式例如$order.Status ‘Shipped’或$customerTier ‘Gold’。true_branch: 表达式为真时执行的步骤块。false_branch: 可选表达式为假时执行的步骤块。技巧复杂的条件判断可以拆分成多个简单的CONDITION步骤或者先在ACTION步骤中通过Apex计算出一个结果变量再进行判断这样逻辑更清晰易于调试。4. LOOP循环用于重复执行一系列步骤直到满足某个条件。作用处理列表数据如订单中的多个商品、重复尝试某个操作如验证密码、或者进行多轮信息收集。关键属性collection: 要遍历的集合变量如一个商品列表。item_variable: 在每次循环中代表当前项的变量名。exit_condition: 可选提前退出循环的条件。警告务必避免创建无限循环。确保循环条件最终会变为假或者设置一个最大迭代次数作为安全阀。5. CALL调用用于调用另一个脚本实现模块化和代码复用。作用将常用的功能如“身份验证”、“发送确认邮件”封装成子脚本供多个主脚本调用。这符合优秀的软件工程实践。关键属性script_name: 要调用的子脚本名称。arguments: 可选传递给子脚本的参数。3.3 变量与数据流脚本的强大之处在于能够在步骤间传递数据。变量是存储和操作这些数据的核心。变量赋值通常在ACTION的输出或PROMPT捕获用户输入时创建。变量作用域一般在当前脚本及其调用的子脚本内有效。数据类型应支持字符串、数字、布尔值、日期、以及Salesforce记录SObject等。最佳实践为变量使用清晰、一致的命名规范如$customerOrder$isEligibleForRefund并在脚本开头通过注释说明主要变量的用途。4. 实战构建一个端到端的退款处理代理脚本让我们通过一个完整的、贴近实际的例子将上述概念串联起来。我们将构建一个处理在线退款请求的Agentforce代理脚本。这个流程包含严格的业务规则是展示Script价值的绝佳场景。4.1 业务需求与流程设计假设我们的电商业务有以下退款规则仅处理“已发货”状态的订单。退款申请必须在发货后30天内提出。退款金额为商品支付金额但需扣除不可退款的运费如果适用。必须明确获得用户对退款金额的确认。所有退款操作必须记录审计日志。基于此我们设计脚本流程信息收集阶段由LLM主导自然地与用户开启对话获取订单号。验证与计算阶段由脚本主导确定性执行。 a. 验证订单存在且状态为“已发货”。 b. 计算订单是否在30天退款期内。 c. 计算应退金额。确认与执行阶段混合执行。 a. 由LLM将计算出的金额以友好的方式告知用户并请求确认。 b. 用户确认后脚本执行退款创建和日志记录动作。 c. 由LLM生成最终的成功通知。4.2 分步脚本实现与注释以下是该退款处理脚本的详细实现。我们将使用一个假设的、更贴近实际编码风格的语法来演示。SCRIPT “Process_Refund_Request”: // 变量声明区概念性 // $orderNumber: 从用户处获取的订单号 // $orderRecord: 从数据库查询到的订单对象 // $daysSinceShipped: 自发货起的天数 // $refundAmount: 计算出的应退金额 // $userConfirmation: 用户的是/否确认 // --- 阶段 1: 信息收集 (LLM主导) --- STEP 1: PROMPT TEXT: “您好我是您的退款助手。为了快速帮您处理请提供您的订单号。” STORE_RESPONSE_IN: $orderNumber MAX_ATTEMPTS: 2 // 设置最多询问两次 ON_FAILURE: JUMP TO STEP “提示联系客服” // --- 阶段 2: 验证与计算 (脚本主导) --- STEP 2: ACTION “Retrieve_Order” TYPE: Apex CLASS_NAME: OrderService METHOD_NAME: getOrderByNumber INPUT_PARAMETERS: {“orderNumber”: $orderNumber} OUTPUT_VARIABLE: $orderRecord ERROR_HANDLING: IF ERROR THEN PROMPT “系统查询订单时遇到问题。” THEN JUMP TO STEP “提示联系客服” STEP 3: CONDITION EXPRESSION: $orderRecord ! null AND $orderRecord.Status ‘Shipped’ TRUE_BRANCH: CONTINUE FALSE_BRANCH: IF $orderRecord null THEN PROMPT “抱歉未找到订单号为 {$orderNumber} 的订单。请核对后重试。” ELSE IF $orderRecord.Status ! ‘Shipped’ THEN PROMPT “您的订单当前状态为‘{$orderRecord.Status}’仅‘已发货’的订单可申请退款。” END IF END SCRIPT // 结束当前会话 STEP 4: ACTION “Calculate_Days_Since_Shipped” TYPE: Apex CLASS_NAME: DateUtility METHOD_NAME: daysBetween INPUT_PARAMETERS: {“startDate”: $orderRecord.ShipDate, “endDate”: TODAY()} OUTPUT_VARIABLE: $daysSinceShipped STEP 5: CONDITION EXPRESSION: $daysSinceShipped 30 TRUE_BRANCH: CONTINUE FALSE_BRANCH: PROMPT “非常抱歉您的订单发货日期是 {$orderRecord.ShipDate}已超过30天的退款期限无法为您办理退款。” END SCRIPT STEP 6: ACTION “Calculate_Refund_Amount” TYPE: Flow FLOW_NAME: Calculate_Refund_Amount_Flow INPUT_PARAMETERS: {“orderId”: $orderRecord.Id} OUTPUT_VARIABLE: $refundAmount // 假设这个Flow内部逻辑会处理商品金额、运费规则等 // --- 阶段 3: 确认与执行 (混合) --- STEP 7: PROMPT TEXT: “根据您的订单可退金额为 **{$refundAmount}** 元。请问是否确认按此金额为您办理退款(请回复‘确认’或‘取消’)” STORE_RESPONSE_IN: $userConfirmation STEP 8: CONDITION EXPRESSION: $userConfirmation CONTAINS ‘确认’ TRUE_BRANCH: STEP 8a: ACTION “Create_Refund_Record” TYPE: Apex CLASS_NAME: RefundService METHOD_NAME: createRefund INPUT_PARAMETERS: {“orderId”: $orderRecord.Id, “amount”: $refundAmount, “agent”: “Agentforce”} OUTPUT_VARIABLE: $refundId STEP 8b: ACTION “Log_Audit_Trail” TYPE: API ENDPOINT: “/services/apexrest/AuditLog” METHOD: POST BODY: {“action”: “RefundCreated”, “recordId”: $refundId, “details”: “Processed via Agentforce Script”} STEP 8c: PROMPT “好的退款申请已提交成功退款编号是 {$refundId}预计1-3个工作日到账。感谢您的耐心等待还有其他可以帮您的吗” FALSE_BRANCH: PROMPT “好的已取消本次退款申请。如果您有其他问题随时可以告诉我。” // --- 异常处理模块 --- STEP “提示联系客服”: PROMPT “当前问题需要人工客服协助正在为您转接...或提供客服联系方式” ACTION “Create_Support_Case” // 创建一个待处理的服务案例 END SCRIPT4.3 脚本设计要点与避坑指南通过上面的示例我们可以总结出几个关键的脚本设计原则和常见陷阱设计原则清晰的阶段划分将脚本逻辑性地划分为“信息收集”、“业务处理”、“用户确认”等阶段使结构一目了然。早失败快退出一旦发现不满足条件如订单不存在、已超期立即给出明确反馈并优雅地结束流程避免让用户和系统做无用功。善用子脚本将“创建退款”、“记录日志”等通用操作封装成子脚本便于复用和维护。例如Create_Refund_Record动作背后可能就是一个封装好的子脚本。混合的智慧在需要人性化交互的地方开头、确认、结尾使用PROMPT在需要精确执行、操作数据的地方使用ACTION和CONDITION。常见陷阱与规避方法陷阱1过度脚本化试图用脚本处理对话的每一个细微之处导致脚本冗长脆弱失去了AI的灵活性。规避遵循“80/20法则”。用脚本控制20%的关键流程节点验证、计算、核心操作让LLM处理80%的对话填充和变体应对。陷阱2错误处理缺失只设计了“成功路径”当API调用失败、数据为空时脚本会崩溃或给出令人困惑的响应。规避为每一个ACTION步骤设计ERROR_HANDLING。使用条件分支CONDITION检查关键变量是否为null。设置一个全局的异常处理步骤如我们的“提示联系客服”。陷阱3变量管理混乱变量名随意不清楚某个步骤后变量是什么状态导致后续逻辑错误。规避建立命名规范如使用前缀input_output_temp_。在复杂脚本中可以添加注释来说明关键步骤后变量的状态。陷阱4忽略对话上下文脚本中的PROMPT指令过于孤立没有考虑之前对话的历史导致LLM回复生硬或不连贯。规避在PROMPT指令中可以简要引用之前的上下文例如“根据您提供的订单号{$orderNumber}我们发现...”。Salesforce的Atlas推理引擎通常会维护对话上下文但明确的提示能使输出更精准。5. 测试、调试与最佳实践构建脚本只是第一步彻底的测试和调试是确保其在生产环境中稳定运行的关键。Spring ‘26版本中与Script配套增强的Agent Preview功能是完成这项工作的利器。5.1 利用Agent Preview进行分层测试新的Preview功能允许你使用模拟数据在隔离环境中测试脚本而不会影响生产数据。单元测试单步测试从第一个PROMPT或ACTION开始使用Preview工具模拟用户输入观察每一步的执行结果。检查变量是否正确赋值条件判断是否按预期分支。集成测试流程测试测试完整的“快乐路径”——即一切顺利的理想场景。确保从开始到结束的整个流程畅通无阻。异常路径测试这是最重要的测试环节。故意提供错误订单号、超期的订单、在确认步骤说“不”等观察脚本是否能按设计优雅地处理这些异常跳转到正确的错误提示或结束分支。压力与边界测试测试输入边界值如刚好第30天、模拟动作失败如API超时、检查在循环中是否会出问题。实操心得在Preview面板中密切关注脚本执行轨迹。它会高亮显示当前执行到的步骤并展示每一步的输入输出。这是理解脚本逻辑流和定位问题的最直观方式。我习惯在构建复杂脚本时每完成一个小模块就进行一次Preview测试而不是全部写完再测这样能及早发现逻辑错误。5.2 脚本版本控制与部署策略虽然Agentforce Builder可能内置了基础的版本历史但对于团队协作和重要变更仍需谨慎。开发-测试-生产充分利用Sandbox环境。在开发沙盒中构建和初步测试脚本在测试沙盒中进行完整UAT用户验收测试最后再部署到生产环境。变更日志在脚本的顶部注释区域记录每次重大修改的日期、作者和修改摘要。这对于后续维护至关重要。渐进式发布对于关键业务代理考虑使用Salesforce的A/B测试功能或逐步向部分用户开放新脚本监控错误率和用户满意度再全面推广。5.3 性能与可维护性考量避免深度嵌套过多的CONDITION和LOOP嵌套会使脚本难以阅读和调试。尽量将复杂逻辑拆分成多个子脚本CALL。优化LLM调用每个PROMPT步骤都会消耗Tokens并带来延迟。在设计时思考能否一次Prompt收集多个信息而不是分成多次简单的问答。文档化除了代码注释维护一个简单的设计文档说明脚本的入口点、主要流程、涉及的系统和关键决策点。这对于 onboarding 新团队成员或未来回顾非常有帮助。6. 进阶应用多代理协作与复杂业务流程Agentforce Script的真正威力在构建复杂、跨职能的自动化业务流程时更能体现。Spring ‘26版本也引入了对多代理互操作性的增强支持而脚本是协调多个代理的“粘合剂”。6.1 设计多代理工作流想象一个复杂的客户 onboarding 流程“销售顾问”代理初步接洽收集客户基本需求和信息。完成后它需要将合格的线索和需求摘要传递给下一个代理。“方案配置”代理根据需求调用CPQ配置、定价、报价系统生成初步方案。它可能需要与“产品专家”代理进行内部协商。“合规审查”代理检查方案是否符合行业法规和公司政策。“合同生成”代理生成定制化的合同草案。每个代理都可以用自己专用的Script来确保其负责环节的确定性和合规性。而代理之间的“握手”和数据传递则可以通过在脚本中调用特定的交接动作来完成例如将一个代理的最终输出作为变量通过一个安全的内部通道传递给下一个代理的启动脚本。6.2 脚本作为业务流程的编排器在这种模式下你可以创建一个**“主控”脚本**或利用Salesflow的流程自动化工具来编排整个多代理工作流主控脚本按顺序或根据条件触发各个专用代理。它负责在代理间传递上下文和数据确保信息不丢失。它监控整个流程的状态处理某个代理失败或需要人工干预的情况。这实际上是将Agentforce Script从控制单个代理对话的“微剧本”升级为指挥整个AI团队协同完成复杂任务的“总导演剧本”。这种模式非常适合端到端的客户旅程自动化如从营销到销售从下单到售后支持。7. 总结与未来展望Agentforce Script的推出标志着Salesforce平台上的AI代理开发从“艺术”高度依赖对LLM的提示工程向“工程”可预测、可测试、可维护迈出了坚实的一步。它并没有削弱AI的创造力而是为这份创造力套上了缰绳使其能在业务规则和合规要求的轨道上奔跑。对于管理员和开发者来说现在拥有了更强大的工具来构建既智能又可靠的数字员工。关键在于掌握“混合推理”的思维模式清晰地划分出哪些部分必须像瑞士钟表一样精确哪些部分可以像人类对话一样自由。然后用Script来铸造钟表的齿轮用LLM来赋予其对话的灵魂。从我目前的实践来看那些率先采用并精通这一模式的组织正在构建的不仅仅是聊天机器人而是真正能够承担关键业务流程、提升效率并保障合规的AI驱动型应用。这不仅仅是技术的迭代更是工作方式和自动化边界的一次重要拓展。
