如何验收 AI Sales Agent：12 项业务门禁清单
销售 Agent 不能只测回答好不好。用客户身份、来源、权限、商业事实、写前确认、读回与撤销等 12 项门禁验收真实工作流。
流畅回答只是第一关
OpenAI 的 Agent 工作流评估指南建议检查工具调用、交接和 guardrails 的真实轨迹；评估最佳实践强调工具参数、边界输入和重复性。Anthropic 在安全实践说明中也展示了运行环境和配置边界如何影响 Agent 行为。
这些资料说明：评价一个 Agent，不能只看它最后一段话。以下 12 项是 KnowSales 为销售场景整理的业务验收清单，不是任何厂商的官方标准。它覆盖从读取到写回的完整路径，尤其适合连接 CRM、产品知识和客户沟通的 Agent。
读取与判断：六项
| # | 门禁 | 可观察的通过证据 |
|---|---|---|
| 1 | 客户身份 | 公司名与至少一个独立硬标识匹配；重名时停在候选状态 |
| 2 | 权限范围 | 只能读取当前用户和工具授权范围内的客户、知识和附件 |
| 3 | 来源可开 | 关键结论能返回对应邮件、文档、记录或网页，而非只显示一个抽象“可信度” |
| 4 | 时间有效 | 旧报价、旧交期、旧负责人被识别为历史快照 |
| 5 | 事实状态 | 客户提出、我方确认、第三方说法和待澄清不混成同一结论 |
| 6 | 跨客户隔离 | 客户 A 的价格、历史和联系人不会出现在客户 B 的答案里 |
前六项最好用故意相似的合成客户测试。正常样例都能答对，不足以证明系统不会串档。尤其要加入同名公司、同一国家的代理商和同一产品的两个买家。
行动与恢复：六项
| # | 门禁 | 可观察的通过证据 |
|---|---|---|
| 7 | 写入计划 | 写前展示目标对象、原值、拟写值、来源和影响范围 |
| 8 | 人工确认 | 客户事实、价格承诺和对外内容在需要时获得授权人批准 |
| 9 | 正确分层 | 稳定公司事实进 profile；单次沟通进 activity；通用产品知识不夹带客户私事 |
| 10 | 幂等与去重 | 重试、超时或页面刷新不会新增相同记录 |
| 11 | 写后读回 | 按实际记录 ID 核对客户、正文、业务时间与权限状态 |
| 12 | 撤销与诊断 | 错误写入有可恢复路径；失败保留对象 ID 和错误证据，避免盲目重试 |
对第五项“事实状态”与第九项“正确分层”的详细做法，可读AI 写 CRM 前的 write plan和销售 Agent 治理清单。
一套最小验收样本
先建立四个合成场景：
- 两个名字相近、产品相同的客户，测试身份与隔离；
- 一条已经过期的报价和一条新活动，测试时间有效性；
- 客户说“如果测试通过可能采购”，测试条件句与状态；
- 写入请求在成功后故意超时，测试幂等、读回与重复创建防护。
每个场景至少保存输入、预期对象、允许的动作、实际工具轨迹和读回结果。对高风险动作，单次通过只说明这一样本通过；要在权限角色、语言和客户端变化时复测。
如何把清单变成采购或上线标准
让供应商或内部团队演示上述场景，而不是只展示一段漂亮回答。先决定不可妥协项：跨客户隔离、权限拒绝和重复写入通常应列为零容忍。再决定可人工补救项：摘要表达、排序或建议措辞可以在早期由销售审核。将失败按影响分级，修复后回到原场景复测。
KnowSales 已在客户、知识、MCP、权限、来源与看板等环节建立了多个可验证的产品面；具体工具是否对某账号开放，仍要以当下权限与实际调用为准。像持久任务这类仍处有限灰度的能力，应独立验收，不能被一张总清单自动覆盖。
常见问题
回答准确率高，为什么还要测工具轨迹？
因为错误读取或越权调用有时会碰巧生成正确句子。只有轨迹能说明它怎样得出答案。
12 项必须一次全部自动化吗？
不用。先用四个合成场景人工验收高风险项，再把稳定的检查做成回归测试。
Agent 偶尔失败可以上线吗？
取决于失败类型。表达问题可人工审核；串客户、越权与重复写入不能用“偶尔”轻描淡写。
为什么写后读回比“工具返回成功”更重要？
工具回执不能证明内容落在正确客户、正确层级和正确时间。读回才验证实际持久化结果。
用这份清单试跑一个只读客户摘要，再查看 KnowSales 的连接方式，逐步扩大到受控写入。