模型输出了文字或工具请求，就算完成了吗？流式断线如何判断？

连续追问与解答

沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。

1. 第 1 层流式工具参数已经能解析成 JSON，为什么仍不能直接执行？

   主问题把内容与生命周期分开，这里用语法完整却缺少协议边界的反例检验理解。

   参考解答

   不能。可解析只说明当前字符构成某个 JSON 值，并未证明调用项已封闭、身份齐全或后续状态可接受。SDK 的增量解析对象也可能是中间视图。按 response/item/call 的身份累积指定调用的片段，等目标接口给出完整参数与项边界，再校验并进入调度；Responses 的 arguments.done 与 output_item.done 是不同事件。若采用等待响应终止的策略，再核对该轮终态。不要靠括号计数替代生命周期，也不要把工具调用参数和普通文字共用一个缓冲区。

   沿着这个回答继续深入

   1. 第 2 层参数完成且工具项已封闭，但整次响应终止前断线，可以把这一轮记成成功或失败吗？

      父问确定工具项边界，子问加入外层终止证据丢失，说明内层完成不能推出外层完成。

      参考解答

      都不能只凭这条轨迹得出。可以确认这个调用项的参数边界已出现，但整次响应终态仍未知；后续是否还有输出、是否不完整或失败尚无证据。本题保守策略会暂缓调度并核对原响应。若接口支持按 ID 读取且对象可读取，可查原结果；禁用存储等条件下不能假设仍可查询。查不到并不证明远端失败。记录已知项和未知响应，页面说明终态未确认，而不是删掉已收到的完整项。

      沿着这个回答继续深入

      1. 第 3 层若应用已在完整工具项后启动了只读查询，随后断流，应该把查询结果一起作废并重新发起模型请求吗？

         父问尚未调度，子问改变为工具已经启动；此时必须保留并行发生的业务事实，检验分层状态的必要性。

         参考解答

         不必因通道断开就作废查询事实。保持“响应终态未知”和“查询执行状态”两份记录，查询成功则保存其调用关联与结果，未完成则继续按查询自身状态观察。新模型请求有新的响应身份，不会天然补回旧响应；先核对旧输出能否恢复，再由明确策略决定是否开启新轮。这里不讨论写操作重试算法；关键是观察通道、生成状态、工具结果互不冒充证据。验证时在同一轨迹上标注断流点和查询完成点，不能用一个 failed 清空全部状态。

2. 第 1 层收到模型的完成标记，为什么仍可能没有可交付的正常回答？

   在已有终止证据的情况下改变输出类型，解释为何传输和生成完整仍不足以决定交付。

   参考解答

   完成标记先说明生成到了接口定义的终止边界，再检查输出类型和任务契约。Responses 的 completed 输出可包含客户端函数调用或拒绝，output_text 聚合为空也不等于失败。调用意味着把控制权交给工具流程；拒绝应进入相应产品状态；正常文本仍需验收。只有结果确实满足本任务交付条件才说任务完成。模型写“已处理”不能覆盖工具尚无结果，拒绝也不能作为正常结构化数据输入。

3. 第 1 层把 OpenAI Responses 切换为 Claude Messages，只统一成 done 布尔值会丢失什么？

   条件从单接口变成跨接口，要求抽象保持意义而非只统一字段名。

   参考解答

   会丢失停止原因、内容项封闭与执行位置。Responses 用 status 和类型化 output，Claude Messages 用内容块与 stop_reason；Claude 的 content_block_stop 只是一个块结束，message_stop 需要结合原因判断。end_turn、tool_use、max_tokens 和 pause_turn 分别指向不同动作，服务端工具暂停也不能直接交给客户端重跑工具。适配层可统一应用的“预览/待工具/拒绝/不完整/终态未知”等状态，但保留原始字段；遇到未识别事件或原因不得默认为成功，应按兼容策略记录并处理。