核心结论
AI 智能体接入 CRM、ERP、工单系统后，价值不在于“聊得像不像人”，而在于能不能在权限允许的范围内完成查询、生成、流转和回写。验收时要看工具调用成功率、权限校验、异常处理、日志审计和人工确认机制。
先区分查询、建议和执行
业务系统动作可以分成三类：查询类、建议类和执行类。查询类风险较低，例如查客户状态、订单进度、库存数量；建议类需要人工判断，例如生成跟进话术、推荐处理方案；执行类风险最高，例如修改订单、创建退款、发起审批、变更客户等级。
不同动作对应不同权限和验收标准，不能都用一句“AI 自动处理”概括。
接口权限要细到动作级
AI 智能体不应该拥有一个过大的系统账号。更合理的方式是按用户身份、部门、角色和动作范围授权。销售只能看自己负责的客户，客服只能处理授权工单，管理者才能查看汇总数据。
- 谁可以查询客户资料。
- 谁可以写入跟进记录。
- 谁可以创建或关闭工单。
- 哪些动作必须二次确认。
- 哪些字段必须脱敏展示。
工具调用要有可复查日志
智能体每一次调用接口，都应该记录用户、时间、工具名称、输入参数、返回结果、是否成功和失败原因。没有日志，就无法判断问题来自模型、接口、权限还是业务规则。
对执行类动作，还应记录人工确认人和确认内容，避免出现“AI 替谁做了决定”的责任不清。
异常场景比正常演示更重要
很多演示只展示正常路径：用户提问，AI 调接口，系统返回结果。但真实业务里更常见的是接口超时、字段缺失、权限不足、客户不存在、订单状态冲突、第三方系统维护。验收时必须覆盖这些异常场景。
- 接口失败时是否重试或提示人工处理。
- 权限不足时是否拒绝，而不是绕过限制。
- 数据冲突时是否保留原始状态。
- 执行前是否让用户确认关键字段。
结果回写决定业务价值
如果 AI 只是回答一句话，员工仍然要手动复制到 CRM 或工单系统，效率提升有限。更好的设计是把摘要、标签、待办、工单和跟进记录按规则回写，让后续流程可以继续追踪。
聚匠的建议
多系统智能体项目建议先做“只读查询 + 人工确认写入”，稳定后再开放更多自动化动作。验收指标要覆盖任务完成率、工具调用成功率、权限正确率、异常处理和日志完整性。
