AIGoCode Responses 流式输出已有文字，为何还不能算完成？终态事件核对指南

把“收到文字”和“收到完成信号”分开

使用 AIGoCode Responses API 时，界面能逐段显示文字，只能说明程序正在消费正文增量。它还不足以说明这一轮响应已经完整结束。接入代码如果在第一段文字出现时就标记成功，后面的未完成状态或错误事件便可能被漏掉。

这篇文章聚焦一个具体任务：在已经能显示流式文字的前提下，补齐完成、失败和未完整结束的分支。接口依据是 Responses API 官方文档，不是对接口做新的压力测试或异常注入。

先确认使用的是 Responses 的事件名称

文档给出的端点为 POST https://api.aigocode.dev/v1/responses。直接调用时选择支持外接调用的分组，并使用 Authorization: Bearer YOUR_API_KEY 鉴权；模型 ID 应来自当前分组。请求使用 input 发送内容，增加 stream: true 后按 SSE 事件读取。

如果你是从其他协议迁移而来，先检查读取代码中保留的事件名称。Responses 的正文增量名为 response.output_text.delta，完成事件为 response.completed。不要仅因两个接口都能流式输出，就复用另一种协议的结束判断。

AIGoCode 文档说明，支持 OpenAI 协议的模型同时支持 Responses 与 Chat Completions。选择哪条入口，要与现有请求体和响应解析配套；这不表示两种事件格式可以直接混用。可从 AIGoCode 官网进入对应协议文档核对。

用事件分发表建立三个处理入口

可以将当前文档列出的事件分到下面三个入口。表中的应用动作是组织代码的建议，事件名称与含义才是文档直接给出的接口事实。

不要把第三行全部重命名成“网络错误”。文档将它们列为失败、未完整结束或错误信息；应用应保留收到的具体名称，再根据实际内容排查。本文不推断它们一定由哪种账户状态、额度或模型行为触发。

先解析完整事件，再向界面追加

官方文档要求程序按完整事件边界解析，收到正文增量后追加显示。接收层应先完成事件解析，再将已识别的正文增量传给界面。不要跳过解析，直接把传输层读到的一段内容当成完整事件。

建议把代码职责拆成接收、事件识别和界面更新三步：接收层保存尚未组成完整事件的内容；识别层在完整事件上判断类型；界面层只处理已确认的正文增量。这里描述的是实现组织方式，没有补写文档未列出的完整事件 JSON 字段。具体取值应以实际接收到并脱敏后的事件结构为准。

若只是用 curl 观察流式输出，文档建议使用 -N。终端能持续出现文本有助于观察，但仍应同时检查终态事件，不能只截图第一段输出就判断整轮成功。

给展示状态和结果状态各留一个位置

一个便于排错的做法，是分别保存当前已显示的文本与本轮结果状态。收到正文增量时更新显示文本；收到完成事件时进入完成分支；收到失败、未完整结束或错误事件时，记录具体分支并提示结果需要核对。

如果连接中断时没有观察到完成信号，建议将本轮标记为“完成状态尚未确认”，保留已经显示的文字供人工核对。不要把这一状态自动解释成请求未被执行，也不要据此无条件重新发起生成。是否重试需要结合原请求结果与错误原因判断，本文不承诺断点续传或安全自动重试能力。

按现象检查对应分支

文字能显示，但一直转圈。 检查 response.completed 的事件分发与界面状态更新，确认完成事件没有被仅处理正文的回调忽略。

显示了部分文字，随后报告问题。 保留实际收到的是 response.failed、response.incomplete 还是 error；不要用已有文字覆盖问题提示，也不要仅凭有输出就将业务任务标记完成。

终端有输出，程序界面没有。 比较终端观察方式与程序的完整事件解析，确认正文增量确实走到了显示入口。先验证解析路径，再判断是否需要改动请求配置。

完成这三处核对后，应用至少能分别表达“正在显示”“确认完成”和“需要检查结果”三种状态。它们是应用自己的状态设计，不是额外宣称平台提供了新的恢复、重试或交付保证。