回答看着正确却执行失败，工具结果需要单独验收模型写出正确回答，只能说明语言输出符合预期。任务是否完成，还要检查工具调用、

模型回答看着正确，业务任务仍可能执行失败。工具接口返回成功，不一定代表目标数据已经写入；生成的说明符合要求，也不能证明消息真的发出。验收需要覆盖调用状态、返回结构、业务规则和外部结果，高风险动作还要保留人工确认。

ZGI 将工具调用放进 Workflow 和 Agent Runtime 的运行链路中，并记录 Workflow 节点的状态、输入输出、错误和时间信息。这些记录可以帮助团队找到执行过程第一次偏离预期的位置。记录提供排查线索，业务是否完成仍需结合工具回执和目标系统状态判断。

为什么成功返回仍会失败

工具调用至少经过四个层次。请求先抵达接口，接口返回一份结构化结果，业务系统按规则处理，外部状态随后发生变化。任何一层都可能出现“技术上成功，业务上没有完成”的情况。

例如，HTTP 状态码为 200，只能说明请求获得响应。返回体可能包含失败码，写入任务也可能进入异步队列。批量操作还可能只完成其中一部分。若 Agent 只读取最外层的 success 字段，最后生成的回复会很完整，真实结果却留下缺口。

把验收拆成几层更容易定位问题：

工具返回后先做结构校验。字段缺失、类型变化或无法解析时，流程应停止在当前节点，保存原始响应和错误原因，避免把异常数据继续传给模型。

结构通过后再检查业务结果。订单是否找到，记录是否全部更新，文件是否真的生成，通知是否进入发送队列，都需要明确的完成条件。条件不能只写进 Prompt，最好由确定性规则或专门节点执行。

涉及写数据库、发送消息、修改权限等动作时，还要读取可核对的结果标识。记录编号、版本号、文件地址或业务回执可以连接“调用已经发生”和“结果可以确认”两件事。外部系统无法立即确认时，流程应进入等待或待核验状态，避免提前告诉用户任务已经完成。

超时最容易触发重复执行。Agent 没有收到响应，并不能证明外部系统没有处理请求。直接重试可能重复发信、重复建单或重复写入。调用前生成稳定的任务标识，外部系统支持时使用幂等键；重试前查询已有结果，可以缩小重复副作用。

批量任务还需要记录每一项的状态。五十条数据处理了四十八条，整体结果不能简单写成失败或成功。已完成项、失败项和待确认项分别保存，后续只补做缺失部分，人工也能看清需要处理的范围。

ZGI 的 Workflow 运行记录包含节点状态、输出和错误信息，Agent Runtime 日志也能保存执行步骤的状态与时间。团队可以用同一个任务标识串起用户请求、工具参数、返回结果和后续节点，排查时先找第一处异常，少在最终回答上反复猜测。

人工审查适合放在责任和业务影响较高的节点。退款、数据删除、对外发送和权限变更等操作，在执行前确认目标、范围和参数；执行后再核对业务回执。低风险的只读查询可以自动验收，减少不必要的等待。

运行记录的字段和保留范围会受到部署配置影响，启用后还要检查敏感参数是否脱敏、谁能查看日志以及保留多久。日志能够还原相关事件，无法替代目标系统的结果确认，也不会自动给出唯一根因。

上线前可以准备四类失败样本：接口超时、返回字段缺失、业务规则拒绝和部分成功。逐条确认流程在哪里停止、记录了什么、是否错误重试，以及用户最终看到的状态。只有这四类情况都能被区分，工具调用才算进入可验收的业务链路。