答案摘要：多系统 AI 接口失败不能只靠“再试一次”。聚匠科技通常为每次工具调用设置幂等键、超时、有限重试、补偿动作、人工处理队列和对账状态，确保 CRM、工单、ERP 或 OA 暂时不可用时，不会重复建单、跳过审批或留下无法追踪的数据，并定期做状态对账。
模型判断正确，系统动作仍可能失败
AI 智能体已经识别出用户要报修，也正确提取了设备编号，但工单接口可能超时；CRM 返回成功后，网络中断导致智能体以为失败，再次提交就可能产生两条记录。多系统协同的稳定性，更多取决于接口和状态设计，而不是对话效果。
需求阶段应把“成功、明确失败、未知结果、等待人工”当作不同状态。尤其是超时，不能简单等同于失败，因为目标系统可能已经写入成功。
五个机制分别解决什么问题
- 幂等键：同一业务动作重复请求时，目标系统返回同一结果，不重复创建。
- 有限重试：只对网络抖动等可恢复错误重试，并设置退避和次数上限。
- 补偿动作：后续步骤失败时，撤销预占、恢复状态或生成待处理任务。
- 人工队列：权限、数据冲突和业务判断问题交给明确岗位处理。
- 对账任务：定期比较源系统和目标系统状态，发现漏单、重复和长期处理中记录。
错误码也要按“可重试、不可重试、需人工、结果未知”分类。参数格式错误反复重试没有意义；鉴权过期需要刷新或通知管理员；目标系统限流适合延迟重试；业务规则拒绝则应把原因交给操作人处理。分类规则由接口负责人确认，不交给模型猜测。
日志要串起一次完整业务动作
一次调用应有统一 trace ID，关联用户请求、智能体计划、工具名称、幂等键、参数摘要、接口响应、业务对象 ID 和最终状态。参数中有手机号、合同金额等信息时可脱敏，但不能只保留一句“调用失败”。
对外提示也要区分状态。“系统繁忙，请稍后查看工单列表”适合结果未知；“资料缺少设备编号，请补充”属于可修复问题；“您没有关闭工单权限”属于权限拒绝。不能让模型用自然语言掩盖真实接口状态。
人工队列需要负责人、优先级、处理时限和关闭条件。处理人员修复数据后，是继续原流程、重新发起还是终止任务，必须有明确按钮和状态记录；不能让员工在群里说一句“好了”就结束异常。关闭后仍要进入对账范围。
联调失败测试清单
| 测试场景 | 预期结果 |
|---|---|
| 目标接口超时 | 查询结果后再决定重试，不重复写入 |
| 同一请求连续提交 | 幂等命中，返回同一业务对象 |
| 第二个系统写入失败 | 停止后续步骤并进入补偿或人工队列 |
| 权限被临时收回 | 拒绝执行并记录权限原因 |
| 字段规则发生变化 | 校验失败可见，不写入不完整数据 |
哪些动作先不要交给智能体自动执行
没有幂等接口、无法撤回、涉及资金或会对客户产生直接影响的动作，不适合首期全自动。可先让 多系统协同 AI 生成操作草稿，由人工确认；稳定后再用 工作流智能体 分阶段开放工具权限。对部署、日志和密钥有更高要求时，应同时评估 私有化部署 / 源码交付。
