先理解
刚接触这个知识点
补齐先备概念，读原理与反例，再用自己的话解释为什么。
从核心原理开始 →知识目录选择核心方向与细分内容
理解 → 实现 → 排错 → 取舍
模型响应的生命周期与完成语义
把传输结束、模型终止、输出类型和工具结果分别判断，知道哪些片段可预览、哪些状态可交付。
知识内容核对 2026-10-03 · 原题来源核对 2026-10-03
这个知识点，你想学到哪一步？
按当前基础选择起点，也可以依次深入。遇到不熟悉的概念，先回到核心原理；完成后用知识练习检查理解。
知识单元目录
LEARN · PRACTICE · REFLECT
知识学习与个人记录
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 模型响应的生命周期与完成语义
先理解核心原理
先备概念：请求与响应生命周期、类型化消息与流式事件
生成完成是一条有作用域的协议事实：它说明哪个响应或内容项到了什么边界，不能扩大为正常回答、正确结论或工具业务成功。语法可解析只证明当前字串形态，终止事件与内容类型才帮助确定后续动作；没有终态证据时保留未知，避免把信息缺失伪装成失败或成功。
用四个维度代替一个成功位
一次数据库连接断开，不会倒推出远端事务一定回滚；同样，流断开描述的是观察通道，不是远端生成的事实。可用四栏理解响应：传输是否读到可信终止、生成是完整/不完整/失败还是未知、内容是文本/拒绝/调用等哪些类型、外部动作是待执行/执行中/已有结果。实际接口还有排队或生成中等状态，不要在终止前把它们归为失败。这四栏是应用设计，不是所有供应商共有的枚举。
为什么完整文本仍不是完整任务
客户端函数调用把控制权交给应用：模型负责提出调用，应用负责执行并返回结果，下一次生成才可能给出任务答复。因此同一个终止响应可以具有“本轮生成完整”和“任务等待结果”两个真值。拒绝也可能是正常返回路径中的类型化结果，不是凭 HTTP 状态就能识别的异常；内容过滤、不完整原因和拒绝字段要按目标接口读取，不能相互替代。
封闭边界与交付边界不同
完整工具项允许应用开始校验与调度，完整响应允许应用确认这一轮的输出集合，业务结果允许确认动作效果。为降低等待而提前处理完整项，是在选择观察与调度边界，不会让后面未收到的事件变成已收到；具体延迟收益需另行测量。本文不规定所有接口必须等整次响应结束。工具校验与重复副作用的设计分别见相关知识单元；这里先建立“何时获得了哪种证据”。
一个容易漏掉的反例
假设页面已显示“报告生成完毕”，但之后收到已知不完整的终止状态；这句文字不能覆盖协议状态。保留预览、标记未完整交付，避免把半段报告当正式导出。反过来，得到正常终止也仅使文本具备进入验收的条件；空正文、漏答或事实错误仍由内容与业务契约判断。
用一个问题检查理解
模型输出了文字或工具请求，就算完成了吗？流式断线如何判断？
一次响应要同时看终止状态和类型化输出，不能只看 HTTP 200、文字结尾或 SDK 的 output_text。正常文本、客户端工具请求、拒绝和已知不完整分别处理；缺少可信终止信息的断流保留为未知。流式文字可作为生成中预览，工具参数要按调用身份组装并确认完整，再进入执行流程。模型响应完成只说明本次生成达到相应边界，工具业务完成还要有独立结果证据。
实现与取舍
“完成”需要说明完成了什么
后端收到 HTTP 200，只说明请求进入了成功响应路径；流后面仍可能出现错误。模型发来一句“处理完了”，也只是内容。应用至少分别记录：连接是否完整读到终止信息、模型为何停止、输出有哪些类型、业务动作有什么结果。这里的“完成文本”指生成过程完整且可进入内容验收，不能据此断言答案事实正确。
先读状态，再读所有输出项
以 OpenAI Responses 为例，响应有 status，完成生成的 completed 与 incomplete、failed 等不同；incomplete_details 可说明停止原因。还要遍历 output：正常消息里的 output_text、函数调用项和拒绝内容不是同一种结果。官方 SDK 的 output_text 是文本聚合便利属性，没有文本块时会返回空字符串；空字符串不能单独证明失败，completed 也不能单独证明获得正常文本。状态与输出依据。
若输出是应用执行的函数调用，应接收完整调用、交给工具流程，再按该接口返回结果；本次模型响应结束可以意味着它在等待工具，而整个任务仍未完成。若类型是拒绝，展示相应说明，不拿拒绝内容解析业务 JSON；已知不完整则标明截断及原因，不替模型补完参数。它们都不等同网络故障。
流式增量不是提交边界
文字增量可用于标着“生成中”的预览。工具参数按响应及输出项身份分别累积，不能把并行调用拼成一个字符串；看到右括号或能做 JSON.parse 只是语法现象，不证明模型已结束该调用。Responses 的参数完成事件与输出项完成事件表达各自边界，整次响应还有自己的终止信息。应用可选择等可信响应终止后调度；若为低延迟在完整工具项封闭后调度，需明确采用的接口语义和执行策略，并独立跟踪工具结果。任何策略都不执行未完成参数，也不把参数完成事件当业务成功凭据。
断线未知与已知截断分开
没有读到可信终止信息就断线，只能说明本地不知道最终状态，不能宣布服务端失败或取消。已有响应 ID、端点支持查询且响应可读取时，可读取原响应核对；OpenAI 的存储配置会影响这条路径，不把查询能力推广到所有接口。查询不可用或不能取得终态，就保留未知，向用户说明部分内容尚未确认；重新生成是新响应，不是补回原响应的结果。
Claude Messages 则在内容块之后发送顶层变更及 message_stop，应用还要看 stop_reason：自然结束、工具请求、额度截断或服务端工具暂停有不同后续动作。content_block_stop 不等于整个消息结束，message_stop 也不等于业务成功。Messages 生命周期依据。因此跨接口适配应保留原始终止原因，再归一化为明确的应用状态；不能用一个通用 done 吞掉差异。
工程推演
- 场景
- 教学事件轨迹：模型先输出“已为你整理”，再给出一个客户端函数调用，响应以 completed 终止；此时工具尚未执行。
- 设计决策
- 把文字视为模型内容，响应记录为生成已终止、存在待执行工具请求；页面显示处理中，工具结果独立更新。
- 验证目标
- 验收时应能指出：模型响应已有终止证据，但工具没有结果证据，不能向用户宣称业务完成。本例是事件语义推演，没有运行真实接口或工具。
- 适用边界
- 实际字段与事件取决于接口和版本。若工具由供应商服务端执行，应按其工具结果项和终止原因识别，不能重复当成客户端调用。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层流式工具参数已经能解析成 JSON，为什么仍不能直接执行？
主问题把内容与生命周期分开，这里用语法完整却缺少协议边界的反例检验理解。
参考解答
不能。可解析只说明当前字符构成某个 JSON 值，并未证明调用项已封闭、身份齐全或后续状态可接受。SDK 的增量解析对象也可能是中间视图。按 response/item/call 的身份累积指定调用的片段，等目标接口给出完整参数与项边界，再校验并进入调度；Responses 的 arguments.done 与 output_item.done 是不同事件。若采用等待响应终止的策略，再核对该轮终态。不要靠括号计数替代生命周期，也不要把工具调用参数和普通文字共用一个缓冲区。
沿着这个回答继续深入
第 2 层参数完成且工具项已封闭，但整次响应终止前断线，可以把这一轮记成成功或失败吗？
父问确定工具项边界，子问加入外层终止证据丢失，说明内层完成不能推出外层完成。
参考解答
都不能只凭这条轨迹得出。可以确认这个调用项的参数边界已出现，但整次响应终态仍未知；后续是否还有输出、是否不完整或失败尚无证据。本题保守策略会暂缓调度并核对原响应。若接口支持按 ID 读取且对象可读取，可查原结果；禁用存储等条件下不能假设仍可查询。查不到并不证明远端失败。记录已知项和未知响应，页面说明终态未确认，而不是删掉已收到的完整项。
沿着这个回答继续深入
第 3 层若应用已在完整工具项后启动了只读查询，随后断流，应该把查询结果一起作废并重新发起模型请求吗？
父问尚未调度，子问改变为工具已经启动；此时必须保留并行发生的业务事实，检验分层状态的必要性。
参考解答
不必因通道断开就作废查询事实。保持“响应终态未知”和“查询执行状态”两份记录，查询成功则保存其调用关联与结果，未完成则继续按查询自身状态观察。新模型请求有新的响应身份，不会天然补回旧响应；先核对旧输出能否恢复，再由明确策略决定是否开启新轮。这里不讨论写操作重试算法；关键是观察通道、生成状态、工具结果互不冒充证据。验证时在同一轨迹上标注断流点和查询完成点，不能用一个 failed 清空全部状态。
第 1 层收到模型的完成标记，为什么仍可能没有可交付的正常回答？
在已有终止证据的情况下改变输出类型，解释为何传输和生成完整仍不足以决定交付。
参考解答
完成标记先说明生成到了接口定义的终止边界，再检查输出类型和任务契约。Responses 的 completed 输出可包含客户端函数调用或拒绝，output_text 聚合为空也不等于失败。调用意味着把控制权交给工具流程；拒绝应进入相应产品状态；正常文本仍需验收。只有结果确实满足本任务交付条件才说任务完成。模型写“已处理”不能覆盖工具尚无结果，拒绝也不能作为正常结构化数据输入。
第 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 分别指向不同动作，服务端工具暂停也不能直接交给客户端重跑工具。适配层可统一应用的“预览/待工具/拒绝/不完整/终态未知”等状态，但保留原始字段；遇到未识别事件或原因不得默认为成功，应按兼容策略记录并处理。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
交互预览改为机器导入的结构化产物
改变的条件：用户可阅读生成中草稿，改为另一系统要求完整 JSON 文档后才能导入；失败内容不能当草稿输入下游。
延伸问题：JSON 文本已经闭合，但最后状态 incomplete，或者收到 refusal，能直接交付吗？
推导与参考解答
不能只凭闭合交付。先检查指定接口的终止状态和类型化内容；incomplete 说明未取得本轮完整生成，refusal 走拒绝路径，即使配置了结构化输出也不能假设它符合业务 schema。保留诊断与预览，但阻止自动导入；若重生成，产生新响应并重新验收，不自行补正文。只有已确认完整的目标内容再进行结构和业务校验。部分章节独立可验收是另一份契约，需要明确声明，不能临时把整体失败解释为整体完成。
保持不变的原理：展示权限与消费权限可以不同，交付必须有符合目标产物契约的完成证据，语法合法不能替代它。
客户端函数调用改为供应商服务端工具
改变的条件：应用原先执行自定义函数，改用 Claude Messages 的服务端工具回合；执行位置和停止原因发生变化。
延伸问题：收到 message_stop，stop_reason 为 pause_turn，是否应执行一次同名本地工具后宣布完成？
推导与参考解答
不应。pause_turn 表示服务端工具循环暂停，其文档处理是把收到的 assistant 内容加入会话并请求继续；在预算和次数限制内推进，而不是把服务端工具项翻译为自定义本地函数。服务端可能已经产生工具结果，按类型识别并保留，不能因本地未执行就假设没有动作。message_stop 确认该消息结束，却未证明任务得到最终答复；继续回合后的输出仍按停止原因和任务条件验收。
保持不变的原理：终止边界属于具体接口和执行层；执行位置变化后，仍须把一轮生成结束与任务完成分开。
易错点
- HTTP 200 或流循环退出后直接显示“任务完成”，忽略流内错误和缺失终止事件。
- 只读取 output_text，把函数调用、拒绝或无文本输出误判为失败。
- 参数片段能解析、SDK 给出增量对象，就立即执行工具。
- 把 arguments.done、content_block_stop 和 response.completed 当成同一层完成信号。
- 把缺少终止信息的断线写成模型 failed，或认为重发请求就是恢复原响应。
- 把拒绝当 JSON 格式错误重试，把已知截断靠补括号变成“完整参数”。
- 把客户端函数调用与服务端工具项混为一类，或凭模型文字宣布业务成功。
参考资料
依据 2026-10-03 读取的 OpenAI 与 Claude 官方文档及 OpenAI 官方 SDK 源码编写。事件轨迹为教学假设，未运行真实模型，未新增生产经历、厂商一致性保证或工具执行效果。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 能区分正常文本、工具请求、拒绝、不完整和断线未知，明确模型响应结束不等于工具业务成功。
- 中高级信号
- 按输出项身份组装增量，分别检查参数封闭、响应终止和内容类型；解释 output_text 为空不能单独判错。
- 资深信号
- 跨接口保留原始原因和证据层次，为预览、低延迟工具调度及未知结果设置明确边界；用事件轨迹验证状态判断，不把统一适配变成语义抹平。
动手验证 按需完成 · 建议 20 分钟
不调用真实模型，用纸面或本地表格判读五条教学轨迹：A 文字增量后 response.completed，含正常文本；B 完整 function_call 后 response.completed，客户端工具尚未执行；C response.completed，message 内容为 refusal；D response.incomplete 且原因 max_output_tokens；E 工具 response.function_call_arguments.done、response.output_item.done 后断线，未见整次响应终止。给每条填写传输证据、模型终态是否已知、内容类型、允许的下一步、对用户的状态说明。再把 E 改成“已在完整项后启动只读工具”，重新判断两个状态。
展开验收要求与检查点
- A 可标生成完成并进入内容验收，不把完成标记当事实正确证明；B 标待工具结果，不能标业务完成。
- C 识别拒绝，D 识别已知不完整，均不执行不完整参数，不伪造正常 JSON。
- E 明确工具项已封闭与响应终态未知同时成立，不仅凭断线断言 cancelled/failed。
- E 的变体分别记录模型响应未知和工具自身结果；不因流断了就抹掉已启动工具的状态。
- 说明哪些判断是本题教学策略，哪些来自指定接口；补一条 Claude message_stop 加 pause_turn 的对照，指出仍需继续服务端工具回合。
重点检查
- 能把传输状态、模型终止状态、输出内容类型、工具业务结果分开表达。
- 识别完整文本、工具请求、拒绝、已知不完整与断线未知，不用文字长度或 HTTP 200 代替判断。
- 区分增量、内容块完成和整次响应终止；完整工具参数才可进入执行流程。
- 保留接口原始字段和调用身份，解释 Responses 与 Messages 的差异。
- 知道生成终止不保证事实正确，也不证明工具业务完成。