Agent 会调用工具，只能证明它能发出请求。生产环境还要回答两个问题：这次动作究竟有没有生效，超时后再次执行会不会产生第二笔业务结果。ZGI 作为可自托管的 Agent Runtime 工作区，可以承载 Workflow 状态与节点重试，并与接入层、业务系统共同串起一条可查询、可重试、可对账的生产任务链。
一个 Agent 能把 create_order 调通，离替公司创建订单还有一段距离。接口返回成功，说明请求已按接口语义处理；它是否同时代表订单落库、库存锁定和通知送达，还要看接口契约与各步骤状态。只要工具会改写外部系统，调用成功就不能直接写成“任务完成”。
Tool Call 只是请求，不是业务结果
OpenAI Function Calling 的流程很清楚：模型选择工具并生成参数，应用执行代码，再把工具输出送回模型。strict: true 可以让参数可靠遵循 OpenAI 支持的 JSON Schema 结构，却无法判断用户有没有下单权限、价格是否有效、订单是否处于可修改状态。执行前的业务校验与执行后的结果校验，仍由应用和运行层负责。
工具输出也不能直接当成可信事实。MCP Tools 规范要求服务端验证所有工具输入并清理输出；如果工具声明了 outputSchema，服务端必须让结构化结果符合该结构，客户端也应在传给模型前校验。结构合格仍不等于业务完成，程序还要确认“success”代表哪一种成功。
最麻烦的情况，是不知道刚才到底做没做
创建订单请求超时，可能是请求尚未到达服务端，也可能是订单已经落库，只是响应丢在路上。直接重试可能多出一笔订单，不重试又可能留下一个已经发生却无人确认的结果。模型只看超时报错，分不清这两种情况。
为了安全处理重试，可以先为一次业务操作分配稳定编号，并把它传给每次重试。下游支持幂等时，同一操作重复提交不会产生第二笔订单；下游不支持时，还要依靠唯一约束、结果查询或去重记录补上。AWS 的 Agent 可靠性实践也指出，带副作用的重试若没有稳定键，会造成重复执行。
重试还要区分错误：网络波动、限流可以限次退避重试；参数错误和权限失败应停止，业务状态冲突要先刷新状态或处理冲突。超时不能被解释为“没有执行”，自动重试也不能凭空换来“一次且仅执行一次”。
把一次调用做成可对账的任务单
不要只保存一次工具输出。每次创建订单都要关联稳定的业务操作编号，并留下执行身份、目标对象、每次尝试和下游订单号，后续查询与重试都沿用同一个编号。模型负责提出结构化动作，确定性程序负责校验、执行、记录和转换状态。
这张任务单会留下三类回执。请求回执说明 Agent 想做什么，执行回执说明工具返回了什么，任务回执则来自目标系统，说明订单最后处于成功、失败、处理中还是需要人工处理。按照 RFC 9110，HTTP 200 表示请求已经成功，响应内容应说明动作状态或结果；对于异步或多步骤任务，还要核对下游业务状态，才能确认整项任务完成。
用 ZGI 串起运行状态与业务结果
ZGI 把 Agent、Workflow、Skills、Knowledge、Data 与 Model Routes 放在同一套运行环境中。放到订单场景里，可以让 Workflow 的运行状态和节点重试关联同一个业务操作编号，再把下游订单号回写用于查询。
ZGI 保存并推进 Agent 的执行过程，再通过同一个业务操作编号与接入层、业务系统的订单去重、最终状态和补偿规则衔接。这样，Workflow 状态、下游订单号与最终结果可以保持对应，任务也更容易查询、重试和对账。
部分失败后，不能从头再跑
如果订单已创建，库存锁定却失败，整条链不能从头再跑。运行层要保存每个已确认步骤，只重试可以安全重复的部分；无法自动判断的动作转给人工，需要撤销的动作进入预先定义的补偿流程。
任务记录不是为了多存一份日志，而是让支持人员能凭同一个业务编号查到下游状态，并找出长期停在“处理中”的记录。进程重启后，也应从最后一个已确认步骤继续，而不是重新执行整条链。
上线前，先改造一个真实动作
可以先挑一个会改写真实系统的工具，把它变成一张可查询、可安全重试、可对账的任务单。发起后能找到业务编号，超时后能判断结果，部分失败后能从正确步骤继续，异常时能说明由谁接手，工具调用才开始接近生产能力。
