工具没有查到记录，怎样与工具崩溃、模型调用失败分别返回

工具没有查到订单，和工具运行崩溃是两件事；模型 API 请求失败又在另一层。若都返回 null，后续既无法决定是否重试，也无法向用户解释结果。应用需要自己的工具结果合同，把领域状态与运行状态清楚表达。

四个信封各有含义

本文定义 ok、not_found、invalid_argument 和 execution_error。ok 必须有 data，error 为空；not_found 没有业务对象，也没有运行异常；参数错误与执行异常必须带稳定错误码，不能同时附一份成功 data。以上是演示应用约定，不是 OpenAI 自动添加的官方状态枚举。

模型 API 的网络或协议失败应在调用层记录，不伪装成某个业务查询的 not_found。只有真实运行了查询且其合同确认不存在，才能报告查无记录。模拟样本不会证明数据库里有没有订单，必须明确合成输入与真实领域事实的区别。

空数组也需要合同解释

查询列表时空数组可能是合法成功；查询单一实体时无对象可能对应 not_found。两者不能单凭 JSON 形状决定。工具定义要先说明接口语义，验证器再检查字段组合。本文示例是单实体查询，因此 not_found 与 ok 数据严格分开。

附件本地函数对四类输入返回不同信封，并验证状态与字段不变式。错误样本故意同时含 ok 状态和错误对象，必须拒收。失败反例是捕获所有异常后返回空对象，日志看似没有错误，模型却可能告诉用户“没有记录”。这会把执行失败变成错误业务结论。

给模型的信息应稳定而有限

执行异常可提供安全错误码和可读说明，不直接回传完整堆栈、系统路径或数据库连接文字。详细诊断留在受控日志，通过关联标识定位。参数错误应指出允许用户修正的信息，但不要把内部实现细节写进普通产品流程。

是否重试取决于状态和副作用，不能简单把所有 error 都重跑。not_found 通常需要核对标识与来源，参数错误需要修正输入；运行异常也未必瞬时。本文只生成与验证结果信封，不实现自动重试，不声称某个错误一定能通过重试恢复。

回填给模型时仍需使用对应 call_id，序列化形式遵守实际接口要求。结果信封通过只证明应用能区分这些合成状态，不能证明真实工具的查询正确性或模型解释正确性。验收报告宜同时记录工具执行结局、信封合法性和最终回答是否忠于结果，避免一项通过掩盖另一项失败。

配套文件与依据

本文的合成输入和参考结果可下载独立样本 a030.json，离线检查器 a030.py与样本放在同一目录后运行。检查器不调用模型接口。 使用 Python 3.12 或兼容版本，将上述文件下载到同一目录，执行 python a030.py。

一手资料1；一手资料2。资料核对日期：2026-10-24。