Salesforce 管理员在 Agentforce 中配置自主智能体（autonomous agents）时，需要在 Agentforce Builder 中建立结构化的业务运营领域、可执行的业务工具以及多层治理控制。与遵循确定性决策树的传统基于规则的聊天机器人不同，Agentforce 依托 Atlas Reasoning Engine 动态理解用户意图、制定行动计划并自主执行任务。为了确保这些自主智能体在企业边界内可靠、安全地运行，管理员必须配置三个基础构建块：用于对工作进行分类和划定范围的主题（topics）、用于执行业务逻辑的操作（actions），以及用于实施行为约束、数据隐私和人工上报路径的护栏（guardrails）。
架构基石：Atlas Reasoning Engine
为了有效配置自主智能体，管理员必须了解 Agentforce 如何处理用户交互。Agentforce 的核心是 Atlas Reasoning Engine，它通过持续的“推理-行动-观察”（reason-act-observe）循环来协调智能体行为：
- 意图分类（Intent Classification）： 当最终用户提交咨询时，Atlas 会对照分配给该智能体的所有活动主题的分类描述来评估该消息。
- 上下文装配（Context Assembly）： 选定主题后，Atlas 会载入该主题的自然语言指令、可用操作、对话历史记录，以及通过 Salesforce CRM 或 Data Cloud 检索到的相关客户数据。
- 计划制定（Plan Formulation）： 推理引擎评估满足用户请求需要哪些操作（如果有），并确定需要从对话中提取的必要参数。
- 操作执行与观察（Action Execution and Observation）： 智能体执行所选操作（例如查询库存记录或更新服务工单状态），并观察返回的输出结果。如果需要后续步骤，引擎将继续推理，直至达成目标或触发上报边界。
由于 Atlas 是进行动态推理而非遵循脚本化的对话树，因此管理员无需构建静态分支路径。相反，管理员需要定义边界、工具和目标，让引擎自主探索解决问题的最佳路径。
步骤 1：在 Agentforce Builder 中配置主题（Topics）
主题是智能体的核心功能领域。它们对相关能力进行分组，提供上下文，并划定智能体获准运行的边界。
访问 Builder 并创建主题
- 在 Salesforce 设置（Setup） 中，使用“快速查找”（Quick Find）框导航至 Agentforce Agents（根据版本配置，可能显示为 Einstein Agents）。
- 从列表中选择所需智能体，然后点击 Open in Builder。
- 在 Agentforce Builder 的左侧导航面板中，选择 Topics 选项卡。
- 点击 New Topic 从头构建自定义主题，或从标准预配置领域模板中进行选择（例如 Order Management、Billing Inquiries 或 Case Escalation）。
定义主题元数据与分类范围
每个主题都需要三个关键配置字段，它们直接影响 Atlas Reasoning Engine 如何路由传入的提示词：
- 主题名称（Topic Name）： 标识业务功能的清晰、描述性标签（例如
Billing_and_Invoices或Appointment_Scheduling）。 - 分类描述（Classification Description）： 详细的语义说明，阐明哪些用户意图、查询和请求属于该主题。Atlas 高度依赖此描述来计算意图相似度。例如，不要只写简单的“账单问题”，而应编写：“处理有关客户发票、账单历史、付款方式、收据请求、费用争议和订阅续订费用的咨询。”
- 范围（Scope）： 简明扼要的摘要，概述智能体在该领域内可以解决和不能解决的问题。这为模型开始推理提供了直接的上下文边界。
编写主题级指令
主题指令提供了智能体在主题激活后必须遵循的具体行为准则和操作步骤。管理员应使用清晰、祈使语气的自然语言起草指令：
- 顺序指引（Sequential Guidance）： 概述标准操作顺序（例如：“1. 询问客户的订单编号（Order ID）。2. 验证订单编号是否与现有记录匹配。3. 检索物流状态并总结交付时间表。”）。
- 条件逻辑（Conditional Logic）： 定义特定场景的处理规则（例如：“如果订单状态为‘已送达’，但客户表示未收到包裹，则启动丢包上报流程。”）。
- 风格与语气指示（Style and Tone Directives）： 明确沟通偏好（例如：“提供简明、专业的回答。在解释发票明细时避免使用技术术语。”）。
管理员应追求聚焦的设计：每个智能体通常配置 10 到 15 个独立主题，确保分类描述之间的语义重叠降至最低，避免引擎产生犹豫或误分类请求。
步骤 2：挂载与配置操作（Actions）
操作是智能体调用的功能工具，用于检索信息、创建或更新记录以及执行外部业务逻辑。没有操作，智能体只能对话；有了操作，智能体才能执行实际工作。
管理员可用的操作类型
管理员可以向主题挂载多种类型的操作：
| 操作类型 | 实现机制 | 典型用例 |
|---|---|---|
| Flows | 在 Flow Builder 中配置的自动启动流（Autolaunched flows） | 更新 Salesforce 记录、创建服务工单、触发审批请求、查询多对象数据。 |
| Apex 类 | 带有 @InvocableMethod 注解的可调用 Apex 方法 | 复杂计算、大批量批处理查询、加密验证、遗留系统对接桥接。 |
| 提示词模板（Prompt Templates） | 在 Prompt Builder 中创建的标准或自定义提示词模板 | 起草个性化电子邮件、总结对话记录、生成定制化产品推荐。 |
| 外部服务与 MuleSoft API | OpenAPI 规范或 MuleSoft Anypoint 端点 | 从第三方物流系统获取实时出货数据、检查支付网关余额、在 ERP 中预留库存。 |
配置操作参数与元数据
在向主题添加操作时，管理员必须通过精确的自然语言描述来配置参数定义：
- 选择操作： 在主题详情视图中，点击 Add Action 并搜索目标 Flow、Apex 方法、提示词模板或外部服务。
- 定义操作描述： 明确说明该操作完成什么任务以及应在何时调用。Atlas 会读取此描述以判断该操作是否符合其当前推理计划的步骤。
- 映射输入参数： 针对每个必需的输入参数（例如
caseId、customerId或billingZipCode），指定智能体应从当前对话上下文中提取该值、直接向用户索取，还是传递静态系统变量。 - 定义输出处理： 配置智能体如何处理操作的返回值。指定是将输出作为综合消息直接返回给用户，还是作为后续操作的上下文传递回推理循环。
- 要求确认（状态变更操作）： 对于敏感或不可逆的操作（例如处理付款、取消合同或删除已安排的服务预约），管理员可以启用确认要求，强制智能体在执行操作前明确要求用户进行确认。
步骤 3：实施多层护栏（Guardrails）
自主智能体需要健全的治理机制，以防止幻觉、数据泄露、策略违规和未经授权的数据修改。管理员可在四个不同层面实施护栏：对话指令、确定性逻辑、访问权限以及平台信任控制。
1. 基于自然语言指令的对话护栏
第一道防线是在主题指令中明确声明负向约束。管理员应将指令视为向员工提供的标准作业程序（SOP）：
- 明确禁止事项： 清晰阐明智能体绝不能执行的操作（例如：“未经主管批准，切勿承诺超过 50 美元的财务额度或退款。”）。
- 隐私保护： 指导智能体处理敏感客户输入（例如：“切勿向客户索要完整的信用卡号、银行账户信息或政府身份证件号。如果客户主动提供此类信息，切勿在对话中重复该信息。”）。
- 平稳上报触发条件： 指定智能体必须停止处理并通过 Omni-Channel 将客户转接给人工客服的精确标准（例如：“如果用户提及采取法律行动、两次要求与主管沟通或使用侮辱性语言，请立即调用 Transfer to Agent 操作。”）。
2. 确定性逻辑护栏
虽然大语言模型擅长理解对话的细微差别，但关键计算和确定性业务规则绝不能交由生成式估算来处理。管理员应通过将关键逻辑迁移至确定性代码中来强化严格边界：
- 使用 Flows 和 Apex 进行计算与验证： 如果折扣必须根据客户生命周期价值遵循严格的阶梯规则，请将计算封装在自动启动流（Autolaunched Flow）或 Apex 方法中。让智能体调用该操作，而不是生成式计算折扣。
- 输出验证： 在将记录提交至数据库之前，使用验证规则和流决策元素来拒绝无效的输入参数。
3. 权限与访问控制护栏
Agentforce 智能体在特定的执行上下文中运行操作。管理员必须在智能体的身份上贯彻最小权限原则：
- 专用智能体用户与配置文件： 每个智能体都在专用的 Salesforce 用户记录下运行。管理员应创建专门针对该智能体运行范围量身定制的 Profile 和 Permission Set。
- 对象级与字段级安全性（FLS）： 确保智能体的权限集仅针对其分配主题所需的特定标准和自定义对象授予
Read或Edit权限。切勿授予Modify All Data或宽泛的管理权限。 - 共享规则（Sharing Rules）： 验证智能体用户是否遵循组织范围默认设置（OWD）以及基于角色的共享规则，确保其无法检索其授权领域或部门之外的客户记录。
4. 平台级护栏：Einstein 信任层（Einstein Trust Layer）
Agentforce 运行在 Salesforce 的 Einstein 信任层之上，提供无需太多管理配置的内置安全功能：
- 数据零保留（Zero-Data Retention）： Einstein 信任层保证第三方基础模型不会保留提示词中发送的企业客户数据，也不会用于模型训练。
- 自动化数据脱敏： 个人身份信息（PII）——例如社会安全号码、电子邮件地址和电话号码——在提示词离开 Salesforce 信任边界前会被自动检测并脱敏。
- 有害内容与提示词注入防御： 传入的用户输入和生成的模型输出均会接受有害语言、仇恨言论以及试图劫持智能体指令的提示词注入攻击扫描。
- 审计跟踪与可观察性： 每次交互（包括检索到的接地数据、发送的提示词、模型中间推理过程以及最终响应）都会记录在 Data Cloud 审计记录中，以备合规与治理审查。
步骤 4：测试、可观察性与优化
在将智能体部署至生产客户或内部渠道之前，管理员必须验证其推理路径并完善其指令。
使用对话预览面板
Agentforce Builder 包含一个交互式 Preview 面板，允许管理员实时模拟对话：
- 测试“典型顺畅路径”（Happy Path）： 输入标准用户查询，以验证智能体是否正确分类意图、选择适当主题并调用相应操作。
- 检查推理追踪（Reasoning Traces）： 点击预览窗口中的推理摘要，审查智能体的内部思考过程。检查选择了哪个主题、哪些指令影响了响应，以及向调用的操作传递了哪些输入参数。
- 测试边缘用例与护栏： 故意提交超出范围的查询、模糊请求和对抗性提示词（例如要求智能体忽略其指令或透露内部系统配置）。确认智能体保持在范围内、适当地引用公司策略，或上报给人工代表。
在生产环境中部署与监控
完成配置与沙盒测试后：
- 渠道激活： 激活智能体并将其分配给部署渠道，例如 Salesforce Service Cloud Messaging、Experience Cloud 站点、移动应用或内部 Slack 工作区。
- Agentforce Command Center： 监控实时绩效指标，包括分流率、主题分布、操作成功率和上报频率。
- 持续提示词微调： 审查智能体过早上报或错误分类意图的会话日志。完善主题分类描述，并添加澄清性的负向指令，以随着时间推移消除歧义。
通过系统地定义细粒度主题、为其配备健全的可调用操作，并辅以多层护栏进行防护，Salesforce 管理员能够将生成式模型转变为可靠、自主的数字协作伙伴，在保障企业标准的同时提升企业运营效率。