在 Agentforce 测试中心测试 AI 代理：需要结果收据

如果您需要 在 Agentforce 测试中心测试 AI 代理 ，请将其子代理、操作和响应评估用作三个独立的证据，而不是作为一个发布判决。合理的默认是：在沙箱中运行正例和负例，对预期的路线和动作要求新鲜的通行证，然后在推广之前独立验证业务效果。 最后一张收据很重要。当预期的记录更改不存在、重复、应用到错误的范围或仍在等待批准时，代理可以选择预期的子代理、调用预期的操作并生成可接受的响应。绿色测试行证明该行的评估结果。它不会自动证明目的地结果。 本指南将一次 Agentforce 测试运行转变为八个州的晋升大门。该设备不存储任何话语、响应、客户记录或秘密；它只保留通过/失败状态、新鲜度、批准状态和结果接收判决。 检测中心的结果是证据，不是释放判决 Salesforce 的当前测试设置单元描述具有话语、预期子代理、预期操作和预期响应的测试用例。它是结果单位然后公开实际的子代理和操作以及单独的子代理、操作和响应评估。这种分离很有用，因为每个故障都指向不同的修复： 子代理失败： 路由选择了错误的责任边界。 操作失败： 路线看似合理，但所需的操作缺失或不同。 响应失败： 路由和调用可能是正确的，但答案不满足预期的语义结果。 不要将这些字段折叠成单个百分比。假设联系更新案例通过了响应评估，因为代理表示地址已更新。如果操作评估失败，则该句子不是写入发生的证据。即使所有三个评估都通过，目的地读回仍然是副作用的有力证据。 同样的谨慎也适用于新鲜度。在指令或权限更改后，代理版本 12、测试套件修订版 4 和昨天的操作元数据的通过运行无法验证版本 13。将每项晋升决定至少约束： 保持收据内容不含任何内容。存储不透明的标识符、版本、时间戳、布尔值和哈希值。请勿将提示、客户数据、凭据或完整模型响应复制到监控记录中。 在任何分数产生影响之前，还有一个安全边界。 Salesforce 的当前测试工具和注意事项单元警告代理测试可以修改 CRM 数据并告诉操作员在沙箱中进行测试。将其视为硬性前提条件，而不是脚注。使用专用装置、可逆记录、最低权限测试身份和清理验证。错误地触及生产的成功测试并不是一个健康的测试。 将一次试运行变成八个州的晋升大门 本文附带的可检查工件按严格的顺序评估八个无内容的案例。该命令可防止下游绿地隐藏较早的故障： 状态 证据 运营商决策 RUN INCOMPLETE 测试工作尚未完成 等待;不要推断失败或成功 STALE RESULT 结果超出了接受的证据年龄 针对预期版本重新运行 SUBAGENT MISMATCH 子代理评估失败 修复路线、范围或测试期望 ACTION MISMATCH 行动评估失败 检查权限、说明和行动计划 RESPONSE MISMATCH 响应评估失败 修复答案标准或响应行为 WAITING 合法批准尚未完成 通知业主；保留简历上下文 OUTCOME UNVERIFIED 测试中心字段通过，但缺少目的地证明 促销前回读效果 HEALTHY 新的路线、行动、反应和结果证据一致 允许有限的晋升决策 使用 Node.js 运行工件： 预期的摘要是： 重要的实验是最后一对案例。两者都有完整的、全新的运行，并通过了子代理、操作和响应评估。 effect unverified 没有目的地收据并决定 OUTCOME UNVERIFIED ; healthy 添加经过验证的回读并解析为 HEALTHY 。一个字段会更改发布判决。 回读应该符合承诺的结果： 对于 CRM 更新，使用隔离的测试身份查询预期记录并仅比较预期字段。 对于电子邮件或通知，请验证沙箱发件箱或提供商收据，并准确断言一种可接受的效果。 对于知识答案，请验证所需的引文或来源标识符，而不是逐字匹配散文。 对于工作流程切换，请验证持久切换记录、所有者、截止日期和恢复令牌。 对于需要授权的请求，记录 WAITING ;不要仅仅因为代理正确暂停而将其标记为卡住。 这不是一个通用评估器。分类器假设您已将 Agentforce 的当前结果字段映射到您自己的稳定收据合同中。它不会判断事实质量、模拟每个用户的措辞或证明沙箱镜像生产权限。它也无法决定您可接受的通过率基准。 Salesforce 的文档指出，生成行为是概率性的，每个组织都必须定义自己的生产准备阈值。 运行演练，然后设置生产边界 从一项高价值任务开始，其结果是可以确定地检查的。不要以一千个生成的提示开始。具有值得信赖的期望的较小套件将比从一次偶然运行中复制预期操作的大型套件揭示更多内容。 1. 冻结测试身份。 记录代理版本、套件修订版、操作元数据修订版、权限集修订版和沙箱标识符。 2. 定义正面和负面案例。 Salesforce 的设置指南推荐两者。包括有效请求、无效请求、不允许的请求、缺少权限的情况和需要批准的情况。 3. 在沙箱中运行。 播种可逆记录并证明清理。如果环境或身份不明确，则中止。 4. 分别检查三个评估。 修复最早失败的边界。响应重写不得隐藏缺失的操作。 5. 读回结果。 使用具有幂等性密钥或稳定测试记录的特定于目标的断言。 6. 重复健康案例。 单次通过不会暴露概率不稳定。保持运行计数和置信区间可见，而不是声明确定性。 7. 仅升级固定的工件。 如果指令、操作、权限、模型配置或测试预期发生变化，则旧收据将过期。 8. 单独监控实时结果。 生产前评估可降低风险；它不会取代启动后的可达性、计划、等待状态、许可、成本或可交付的运行状况。 最终的边界是代理测试和代理运行状况的分歧点。测试询问在升级之前所选场景的行为是否可接受。操作健康状况询问正在运行的代理是否仍然可以访问、取得有用的进展、使用其工具、尊重批准边界并立即产生预期结果。两者都需要，但其中之一无法替代另一个。 Sidewisp 是围绕运营健康层设计的：证据新鲜度、有用进展、工具访问、等待与卡住以及经过验证的结果。 Sidewisp 目前处于私密预览阶段。 公众现场及互动演示已上线；未提供生产 Agentforce 适配器、实时监控引擎和自动恢复执行器。今天的实际步骤是将不含内容的收据保留在 Agentforce 测试运行旁边，并在目的地结果仍未知时拒绝促销。