客服 AI 编排层是否形成闭环，不能看对话是否结束，也不能只看接口是否调用成功。真正的验收对象是客户诉求对应的业务状态：该执行的操作已经完成，该审批的事项获得明确结果，未完成的任务有责任人接续，最终反馈与业务系统中的实际结果一致。
先定义完成，再设计验收
以售后申请为例，识别诉求、查询订单、判断政策、提交审批和反馈结果，是流程节点，不是各自独立的成功证明。验收前应明确：什么状态代表处理完成，什么情况必须转人工，哪些结果只能表述为“等待处理”。审批被拒也可以构成明确终态，但不能被包装成申请已获批准。
每个关键节点都应留下可核对的证据，包括输入信息、规则判断、执行结果和后续去向。编排记录用于说明系统做了什么，业务系统结果用于确认操作是否生效，两者需要对应。流程记录完整，不等于业务结果正确。
用异常路径检验衔接能力
正常流程演示只能证明流程能够走通，异常测试才能检验闭环是否可靠。测试应覆盖客户修改诉求、信息缺失、审批拒绝、接口超时，以及重试或重复请求，重点检查：
- 重复请求是否导致重复提交或重复执行。
- 中断后能否从正确节点恢复，失败操作是否需要补偿。
- 人工接手时能否看到已完成步骤、未解决事项和接手原因。
- 执行结果暂不明确时，是否停止推进，避免误报成功。
人工接手也不是终点。若任务只是被转出，却无人承接、无法继续追踪，仍然属于流程断点。
验收时，应将每条测试路径的预期终态、实际业务状态、客户反馈和剩余任务放在一起核对。只有结果一致，或未完成事项已进入可追踪、责任明确的后续处理，才能认定形成闭环；无法确认执行结果的任务，应保持待核实，而不是提前关闭。