答案摘要：多系统 AI 接口失败时，不能把“超时”直接当作“没有执行”，也不能让智能体自行无限重试。聚匠科技在此类项目中会为每次业务动作建立稳定幂等键和执行台账，按可恢复错误、结果未知、业务拒绝、权限失效分流；重试设次数与时间预算，部分成功逐步补偿，无法自动判断时转入带上下文的人工队列。
先把一次业务动作变成可追踪的执行单
模型判断正确，不代表 CRM、OA、ERP 或工单系统已经完成写入。一次跨系统动作需要独立的流程实例号，并把每个工具调用记录为子步骤。这样才能回答：任务停在哪一步、外部系统是否已经落库、谁可以恢复、再次执行会不会重复建单。
| 执行字段 | 用途 | 验收证据 |
|---|---|---|
| 流程实例与节点 | 定位任务和当前检查点 | 状态流转时间、前后节点 |
| 幂等键与参数摘要 | 识别重复请求和参数冲突 | 重复调用返回原业务结果 |
| 外部业务单号 | 回查目标系统是否已写入 | CRM、ERP 或工单中的编号 |
| 错误类别与重试预算 | 决定重试、停止或转人工 | 错误码、尝试次数、下次时间 |
| 责任人与截止时间 | 防止异常无人处理 | 认领、转派、关闭记录 |
在多系统协同 AI中，智能体负责结构化参数和调用计划，工作流负责状态与超时，工具网关负责权限与幂等，业务系统负责字段和状态校验。
重试前先判断结果未知还是明确失败
网络超时属于“结果未知”：目标系统可能已经成功，只是响应没有返回。此时应先用幂等键、业务单号或查询接口回查，再决定是否重试。参数校验失败、状态不允许等属于业务拒绝，修改输入或人工处理前重复请求不会解决问题。权限失效则要先恢复授权，不能让模型换一种说法绕过。
- 可恢复错误：短暂限流、网关抖动等按退避规则重试，并限制次数和总时长。
- 结果未知：暂停写入，先查目标系统；查不到可靠结果时转人工核对。
- 业务拒绝：保留原错误码与字段，退回资料补充或审批，不自动改参数。
- 权限失效：关闭工具入口，通知责任人处理授权，恢复前不继续后续节点。
重试预算至少包含允许次数、截止时间、退避间隔、可重试错误清单和终止去向。每次尝试沿用同一业务幂等键，并生成不同调用序号；同一幂等键出现不同参数摘要时，应拒绝执行并进入核对队列。
补偿不是把数据库状态直接改回去
跨系统流程常出现“前一步成功、后一步失败”。例如 CRM 已创建客户，ERP 建单失败，客服工单已经发出通知。此时不能用一句“整体回滚”掩盖已经发生的动作。每个节点要预先约定补偿方式：撤销、作废、释放预占、生成反向单据、发送更正通知，或交由人工决定保留哪些结果。
- 记录已经成功的子步骤、外部单号和不可逆影响。
- 停止仍未开始的后续步骤，防止错误继续扩散。
- 按业务规则执行补偿，并为补偿动作设置自己的幂等键。
- 补偿失败时转人工队列，不把原任务误标为已恢复。
- 完成后运行对账，确认源系统、目标系统和用户可见状态一致。
断点续跑要从已确认节点继续
工作流智能体恢复任务时，应读取已完成节点、最新业务对象版本、当前权限和待处理参数，而不是从开头重新调用所有接口。检查点可放在人工确认、外部单号落库、不可逆操作前后，以及每个跨系统边界处。
人工队列要携带原始请求、智能体计划、已完成步骤、错误类别、外部单号、建议处理动作和可用按钮。处理人选择“继续、补偿、终止或重新发起”后，系统保存操作者、理由和参数版本。若订单、库存、合同或客户状态已变化，旧确认自动失效，返回审批节点重新核对。
用故障矩阵验收正常、重复与恢复路径
- 让目标接口在写入成功后故意超时，验证回查后不会创建第二条记录。
- 重复投递同一流程事件，验证幂等命中并返回原外部单号。
- 让第二个系统明确拒绝，验证后续节点停止且输入不会被模型擅自改写。
- 模拟部分成功，核对补偿动作、补偿幂等、用户提示和对账结果。
- 撤销工具权限或修改业务对象版本，确认旧任务不能按原参数继续。
- 由人工接管后恢复执行，确认从检查点续跑，责任人和操作证据完整。
- 关闭重试服务再恢复，确认逾期任务进入人工队列，而不是集中重复写入。
如果目标系统没有稳定业务单号、回查接口、明确错误码或撤销路径，先不要开放自动写入。可以从只读查询和草稿生成开始，在原系统由人工提交；积累真实异常码与处理规则后，再逐步开放工具。无论使用云模型 API、混合私有化还是全本地推理与私有化部署，业务幂等、补偿责任和人工复核都不能由部署方式替代。相关能力可纳入AI 智能体交付验收。
