邮件里有需求，表格里有确认记录，业务系统里需要一张采购订单草稿。跨系统流程自动化要解决的，是让同一项任务在这些位置之间接力，并能回答：材料是哪一版、批准了什么、写入是否成功、失败后由谁处理。
下面以“根据已确认材料准备采购订单草稿”为示意任务。它只讨论草稿准备和复核，不把邮件发送、采购申请获批或字段录入，直接当成正式下单完成。
先确定这一笔任务是谁，才能谈系统接力
同一封邮件可能包含多种物料，一份表格也可能对应多个供应商。若只用邮件主题作为任务名称，重发、转发或附件更新后，很难判断它属于新任务还是旧任务的修订。
先由业务规则确定任务标识和关联对象，例如申请编号、公司主体、供应商、订单草稿编号及版本。如何拆分订单取决于企业采购规则；不能为了自动化方便，把不同主体或不同授权范围的内容强行合并。
每次接力都应沿用这组关联信息，并记录输入文件版本和当前处理状态。这样责任人才能从一张草稿追溯到原始需求，而不是只看到一段 AI 生成的说明。
把一条任务拆成五次可核对的交接
第一步，收集输入并保存来源。邮件、附件和表格都要注明版本与接收时间；内容冲突时保留差异，交给责任人确认采用哪个版本。
第二步，整理字段与缺项。供应商主体、物料、数量、单位、价格口径和交付条件分别核验。AI 可以协助提取和比对，但缺失字段不能靠模型补成“看起来合理”的值。
第三步，绑定本次动作的授权。需求批准、供应商及交易条件确认、订单授权分别核对。只获得草稿准备权限时，任务就止于草稿，不自动扩大到批准或外发。
第四步，通过可用且获授权的接口或界面执行草稿写入。是否存在适合的接入方式、字段校验和访问权限，需要项目现场确认；不能承诺任意系统都能直接接通。
第五步，回查目标记录，再通知复核人。界面提示或接口返回只是证据的一部分，还要核对目标对象编号、关键字段、状态和关联版本。通知内容要准确写明“草稿待复核”。
这五次交接分别对应输入、判断、授权、执行和确认。关于工具怎样分工，可以延伸阅读AI、工作流和 RPA 的三层分工；实际任务需要在此基础上补齐对象、状态与责任。
超时之后，先确认有没有写进去
最容易被忽略的情况，是系统已经创建草稿，但响应在返回途中中断。调用端显示超时，不等于目标系统没有执行。直接再点一次，可能生成重复记录。
因此应区分“尚未发起”“结果已确认”“结果不确定”几种情况。处于不确定状态时，先按企业认可的关联标识查询目标记录，无法确认则交给责任人检查。只有目标能力、重复请求处理和重试条件都得到验证，才讨论受控重试。
微软的重试模式说明专门提醒了重复执行的副作用。这是跨系统设计要核验的风险，不代表灵核已经内置自动重试或自动回滚能力。
用状态账把任务交给下一位责任人
一份状态账至少包含任务标识、输入版本、已完成动作、系统返回、目标对象、待确认事项和接管人。对不同故障应给出不同后续动作：缺字段找业务补充，权限不足找相应管理责任人，写入结果不确定则先回查。
如果目标系统只完成了部分动作，不能把整笔任务标成成功，也不应未经授权删除记录或修改已产生的业务结果。恢复方式要符合目标系统和企业流程，留下由谁决定、如何处理的证据。
先验收一笔能追溯的草稿
试点可先限定一个公司主体、一类订单和一种输入格式，使用受控环境验证正常与异常路径。每笔任务都应能从原件追到系统草稿，再从草稿反查原件；任何版本不一致都应显式暴露。
灵核数智的工具、技能与作业指导书，可作为拆解任务动作、组合能力和规定异常边界的讨论框架。具体系统接入和可执行范围，仍以已确认条件及样本测试为准。采购业务的前段可参考从询价到比价的自动化闭环，不要把不同阶段的批准和完成状态混在一起。
