为什么收到了事件，界面却没有逐字更新

调用 AIGoCode 的 Anthropic Messages 接口时，普通 JSON 响应与流式响应需要两条读取路径。普通响应遍历 content，而设置 stream: true 后，需要按 SSE 事件读取。把普通响应的解析方式直接放进流式回调，很容易只拿到事件对象，却没有把文字交给界面。

本文聚焦流式事件的分工与文本增量判断，不重复介绍安装工具或创建 Key。接口与参数以 Anthropic Messages API 文档为依据；文中的核对步骤是接入建议，不代表一次新的生产调用实测。

先确认请求确实走了 Messages 流式路径

文档给出的请求地址是 POST https://api.aigocode.dev/v1/messages，认证使用 x-api-key。直接调用时，应选择包含目标模型并支持外接调用的分组，再填写该分组中的模型 ID。不能只看模型所属厂商来决定协议，也不能把其他分组的 Key 直接套过来。

在原本可以返回普通响应的请求里，将 stream 设置为布尔值 true。保留 messages 对话列表；系统指令使用请求体顶层的 system。建议先只改这一处流式开关，避免同时更换地址、模型和解析代码，导致无法定位差异。

如果你仍在配置客户端入口，可先从 AIGoCode 官网进入文档，按所用工具核对分组与地址。本文讨论的是直接读取 Messages 事件流，不把工具已经封装的内部事件当成相同接口。

事件先分层，再判断哪些内容可以显示

官方文档列出的流式事件可以按下表整理。它们处于不同层级，不应该收到一个事件就往回答末尾添加一段文本。

事件	文档中的含义	建议的处理职责
`message_start`	消息开始	建立这一轮回复的接收状态
`content_block_start`	内容块开始	记录接下来开始接收内容块
`content_block_delta`	内容增量	继续检查增量类型，再决定交给哪条处理路径
`message_stop`	消息结束	将本轮接收状态转为结束
`error`	流中的错误信息	保存脱敏错误，交给失败处理路径

表中最后一列是应用层组织建议。文档列出的事件名称与含义，并不等于你的前端已经完成了对应状态管理；需要在自己的读取代码里明确连接起来。

content_block_delta 不等于一定有可显示的文本

官方文档进一步说明，文本增量的类型为 text_delta。因此，处理逻辑至少要分成两步：先识别内容增量事件，再核对增量类型是否为文本。不能把所有内容块都转换为字符串追加到聊天气泡。

可以把文字展示入口限定在“已识别 content_block_delta，且确认增量类型为 text_delta”的分支。其他内容保留给对应类型的处理逻辑。这里没有列出未在当前文档中展示的完整事件 JSON 字段，实际取值应对照你收到并已脱敏的事件结构，不要凭普通响应的字段位置猜测。

这也与普通响应的规则呼应：文档要求遍历 content，读取 type 为 text 的文本块；工具调用等其他内容块按各自类型处理。两种模式都需要识别内容类型，但普通响应中的 text 与流式文本增量的 text_delta 不能混写成同一个判断值。

将“已经显示文字”和“本轮已经结束”分开记录

建议给接收代码保留两个状态：目前累计显示的文字，以及本轮接收是否结束。文字出现时只更新前者；收到消息结束事件时再更新后者。这样便于排查界面已经显示部分文字、加载状态却一直没有结束的情况。

遇到 error 事件时，应将错误交给失败路径，而不是将其作为回答内容展示。排错记录只保留必要的事件名称、失败时间和脱敏错误，避免记录真实 API Key 或未经处理的完整业务输入。不要因为屏幕上已有文字，就把错误分支忽略。

本文没有据此推导断线续传、自动重试、固定事件数量或请求一定成功等能力。是否重试，应另行核对失败原因和原请求结果。

用一张检查表定位解析问题

排查时依次确认：请求是否确实携带 stream: true；读取端是否按 SSE 而非一次性 JSON 解析；事件分发是否区分消息与内容块；文字展示是否只接收已确认的文本增量；结束与错误分支是否分别更新应用状态。

如果普通响应可显示、流式响应不显示，优先比较两条解析路径。如果文字已经能追加、界面却一直显示生成中，再检查消息结束分支。如果只在某种内容块上报错，先核对类型判断，避免把非文本内容强制按普通字符串读取。以上都是缩小问题范围的方法，不把某个现象直接认定为服务端故障。