API 回答被截断怎么办？结束原因、输出上限与补齐验收
API 回答看起来被截断，先保留原始响应与实际发送的参数，读取该接口的结束原因，再决定是否补写。长度上限、主动停止、拒绝和等待工具结果，需要不同处理；把 token 上限一律调大并不能解决所有情况。 本文从已完整收到的响应对象开始，不讲网络分帧；官方资料核对日期为 2026 年 10 月 25 日，案例均为人工构造，没有真实调用。
先拿到哪个字段，才有判断依据？
只看页面最后一句，无法确认模型为什么停。先记录协议、模型、请求标识、输出上限参数、原始结束字段与用量；有多个候选回答时，分别记录对应 choice，不把第一项的结论套给全部。
| 实际接口 | 先读哪里 | 还要看什么 |
|---|---|---|
| OpenAI Chat Completions | 每个 choices[i].finish_reason |
该项的 message、拒绝信息、工具请求 |
| OpenAI Responses | 响应级 status；未完成时读 incomplete_details.reason |
output 条目类型、拒绝内容与工具调用 |
| Claude Messages | stop_reason |
命中的 stop_sequence、内容块与用量 |
Chat 的 length 表示达到请求中的 token 上限；stop 可以是自然停止，也可以命中了设置的停止序列。不能把两个值都记成“完整回答”。Chat 响应定义
Responses 的 incomplete 需要继续看原因，例如 max_output_tokens 或 content_filter；拒绝也可能出现在消息内容块中。OpenAI 未完成与拒绝处理 Claude 则区分 max_tokens、stop_sequence、tool_use、refusal 等；model_context_window_exceeded 要按上下文限制处理，pause_turn 表示服务端工具循环暂时停下，不能当最终答案。Claude 结束原因
这些是各自官方协议的定义，不是所有兼容服务共用的保证。云岚API接入也需按实际渠道记录；缺字段或遇到未知值时标“未确认”，不要猜成 length。若连完整响应或有效终态都没收到，先转到 SSE 接收检查。
确认原因后，选择对应动作
| 观察到的证据 | 下一步 | 暂时不能做什么 |
|---|---|---|
| 明确的长度或上下文限制 | 核对实际上限、输入长度、推理用量，再缩小任务或调整预算 | 将已有半段标为完成 |
| 命中停止序列 | 对照请求配置和命中信息，检查是否提前碰到正文会用的分隔符 | 仅因结尾短就认定 token 不足 |
| 拒绝或内容过滤 | 单独展示、记录并按应用规则处理 | 当成缺字反复要求补完 |
| 有完整工具请求 | 进入相应工具流程并检查结果 | 把没有正文等同于生成故障 |
| 正常停止但缺章节、项目或字段 | 对照任务清单列出缺项，修订要求或有范围地补写 | 用结束状态替代内容验收 |
| 原因缺失、互相矛盾或未识别 | 保存脱敏响应，核对协议与服务说明 | 静默归为成功或自动无限重发 |
遇到工具条目尤其要先看整体状态：出现工具名，不代表参数已经完整。 响应明确未完成时，不应拿半段参数去执行；完整调用仍要校验结构、权限与执行状态，再走工具调用与结果回传。本文不实现工具执行器。
该调哪个上限，为什么正文短也会用完？
OpenAI Chat 当前使用 max_completion_tokens，旧 max_tokens 已弃用，适用模型还有限制；Responses 使用 max_output_tokens；Claude Messages 使用 max_tokens。不能只把同名数字复制到另一种接口。先检查实际发出的请求，确认 SDK 或应用默认配置没有覆盖你打算使用的值。
上限是预算，不是保证生成的字数。OpenAI 的推理模型还可能把输出预算用于推理 token，甚至在产生可见正文前就达到限制，因此“正文很短”和“已耗用输出预算”可以同时成立。查看实际 usage，不用中文字符数估算余量。Chat 参数定义、推理预算说明
只有确认预算不足后，才在模型支持范围和任务成本内调整。上下文空间不足时，单纯增加输出上限未必有用；可减少不必要输入，或将任务拆成有编号的段落。不要照抄一个固定大数，声称它适合所有模型。
补写后，怎样证明任务终于完整？
先保留原结果，写出缺失范围，而不是只发送“继续”。例如原任务要求 A、B、C 三节，实际只有 A 和 B 的开头，就记录每节预期内容、现有结果和缺项；新尝试明确补哪一节。需要传递前文时，按多轮历史规则保留必要上下文。
补写不是原请求的无损续传。拼接前检查边界重复、漏句、编号断裂、前后结论矛盾；还要确认新响应也正常结束。若是结构化数据，继续按 JSON 语法、字段和事实验收处理，不能靠补一个括号恢复丢失信息。
下载输出完成检查包，里面有判读清单、人工响应片段、内容覆盖表和空白 CSV。每次把“原始结束状态”“缺失范围”“改了什么”“本次结论”分别记录；未知用量留空，各次尝试的成本分别核对，不只保留最后一次成功。
只有结束状态已确认、拒绝或工具分支已妥善处理、所需内容逐项验收通过，才把该版本交付或入库。模板不自动判断事实正确，也不证明某个模型或渠道已经兼容。
常见问题
finish_reason 是 stop，就能保证所有内容齐了吗？
不能。它说明该候选为何结束，不保证章节、记录或业务要求齐全；还需检查停止序列配置与任务覆盖清单。
改成流式输出，能绕过 token 上限吗？
不能把它当作增加输出预算的方法。流式改变接收方式，仍需核对同一模型与接口的上限、用量和最终状态；不要把更早看到文字误认为可无限输出。
返回空正文，是不是一定没生成、没计费？
不是。先检查推理用量、拒绝信息和工具条目。缺失 usage 也不能填成零；具体费用以该次请求记录和账单为准，参见任务费用核对。
自动循环发送“继续”，直到不报 length 就可以吗？
不够。每次都要有明确缺项、次数与费用上限，并检查重复或矛盾。若涉及工具副作用，先确认原执行状态；没有长度错误也不等于最终内容通过。