1. Codex CLI 里 wire_api 到底在选什么Codex CLI 的wire_api不是「用哪个模型」的开关而是「客户端按哪套协议把请求发出去」的开关。你把它理解成插头形状更贴切插座服务端可能同时有圆孔和扁孔但你的插头Codex CLI只有一种形状插错了不是电压问题是根本插不进去。当前 Codex CLI 需要持续处理推理项、工具调用、命令执行结果、文件变更和多轮上下文。这些内容在 Responses 协议里有对应的结构化字段比如input数组里可以放消息、推理项、工具调用及其结果。而 Chat Completions 的典型结构是messages数组响应文本落在choices里它没有为「工具结果如何续接下一轮」设计完整的上下文组织方式。所以结论先放这里当前 Codex CLI 的自定义提供商应使用wire_api responses对应服务端路径通常是/v1/responses。Chat Completions 仍然是一个存在的 API适合你自己写简单聊天脚本或已有聊天应用但它不是 Codex CLI 的可互换备用开关。这里要分清两件事。「模型服务是否支持 Chat Completions」描述的是服务端能力「Codex CLI 当前使用什么 wire API」描述的是客户端协议要求。服务端同时支持两个入口不代表 Codex CLI 可以任意选。最终要看客户端发送什么结构、等待什么事件、如何恢复后续轮次。我实测过一个典型误区有人看到服务端文档写着「兼容 OpenAI Chat Completions」就把wire_api填成chat然后反复换模型名、查余额、加重试。实际上请求根本没离开客户端配置加载阶段就被拦下了。下面按阶段拆开讲先解决配置再解决通道最后验证请求真的跑通。2. 把 endpoint 改到 TaoToken 统一通道的前置准备在动config.toml之前先把「Key 从哪来、Base URL 填什么、模型 ID 写哪个」这三件事定下来。Codex CLI 的配置里env_key写的是环境变量名称不是把真实 Key 直接写进文件。这一点很多人第一次配会踩坑把sk-xxx直接塞进env_key结果客户端去读一个叫sk-xxx的环境变量当然读不到。TaoToken 在这里的角色是统一 Key/API 通道你用同一个 Key通过它的 API 入口访问模型Codex CLI 侧只需要把base_url指向 TaoToken 的 API 地址wire_api保持responses。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置里填干净的基址就行。具体准备三步第一步拿到 Key。进入控制台的 API Keys 页面创建或复制一个 Key。这个页面地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。创建后先别急着贴进配置文件放到环境变量里。第二步确认模型 ID。不同模型在服务端的标识不一样别凭记忆写。可以在模型对话页面先手动发一条消息确认这个模型 ID 是服务端实际接受的。模型对话入口是 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。这一步很关键因为model字段写错请求会进到服务端但被路由拒绝报错信息往往和协议无关容易误导排查方向。第三步设置环境变量。Linux/macOS 下可以写进 shell 配置Windows 下用系统环境变量或 PowerShell 的$env:。以 Linux/macOS 为例export TAOTOKEN_API_KEY你的Key验证环境变量是否存在只看名字不要输出内容[ -n $TAOTOKEN_API_KEY ] echo env exists || echo env missing这里有个安全习惯排查时只确认环境变量是否存在不要把 Key 打印到终端、截图或共享配置里。Codex CLI 的env_key字段填的是变量名TAOTOKEN_API_KEY不是变量值。如果你用的是 Claude Code 或 Cline 这类工具接入逻辑类似都是 Base URL Key Model ID 三件套。但 Codex CLI 的特殊点在于wire_api必须是responses这是它和其他聊天客户端最大的配置差异。前置准备做完下面进入可复制的配置片段。3. 可复制的 config.toml 配置片段与切换步骤Codex CLI 的配置文件默认在~/.codex/config.tomlWindows 下是%USERPROFILE%\.codex\config.toml。如果你之前配过别的提供商先备份一份cp ~/.codex/config.toml ~/.codex/config.toml.bak然后写入下面这段最小可用配置。注意base_url的拼接规则TaoToken 的 API 基址是https://taotoken.net/apiCodex CLI 会在后面拼/v1/responses所以base_url填到/api/v1这一层具体以你实际路由拼接结果为准配完用后面的验证步骤确认最终路径。model your-model-id model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api/v1 env_key TAOTOKEN_API_KEY wire_api responses重点核对四项。model必须是服务端实际接受的模型标识就是你在模型对话页面验证过的那个。base_url是否包含/v1要和 Codex CLI 的路由拼接规则一致填错会出现 404 而不是 401这个区别后面排障会用到。env_key写环境变量名称不是真实 Key。wire_api使用responses服务端必须真正实现对应协议。如果你需要保留多个提供商可以写成多段用model_provider切换model your-model-id model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api/v1 env_key TAOTOKEN_API_KEY wire_api responses [model_providers.local-test] name Local Test base_url http://127.0.0.1:9999/v1 env_key LOCAL_TEST_KEY wire_api responses切换时只改model_provider的值其他段保持不动。这样排查时可以把「协议配置错误」和「网络不可达」拆成两个阶段本地测试提供商故意指向不可达端口配置层能正常加载说明协议字段没问题换成 TaoToken 后如果连通性失败问题就在网络或 Key不在wire_api。配置写完后先做配置加载检查不要直接发请求。Codex CLI 在严格配置模式下会在加载阶段拦截非法wire_api。如果你把wire_api写成chat会看到类似这样的提示Error loading config.toml: wire_api chat is no longer supported. How to fix: set wire_api responses in your provider config.这个报错发生在请求发出之前此时换模型名、调余额、加重试都没有意义。看到这个提示直接改wire_api就行。配置层通过后再进入下一节的请求验证。4. 验证请求与成功结果从配置加载到工具续接验证要分层做不要一上来就跑复杂任务。我实测下来按下面顺序能最快定位问题在哪一层。第一层确认客户端版本。不同版本的 Codex CLI 对wire_api的支持有差异先记录实际版本codex --version第二层确认配置能加载。用诊断或严格配置模式跑一次观察输出里是否识别到你的提供商和协议。正常应该能看到类似model provider: TaoToken和wire API: responses的字段。如果这一步就报wire_api不支持回到上一节改配置。第三层用最小文本任务验证非流式响应。先发一条最简单的指令比如让它输出一句话确认请求真的到达服务端并返回内容。这一步成功说明 Base URL、Key、模型 ID、协议四者基本对齐。第四层验证流式事件完整结束。Codex CLI 在编码任务里大量使用流式输出如果中转层只改写路径却没完整处理流式事件常见现象是首轮有文字但中途中断或者客户端报「响应格式不完整」。观察流式输出是否能正常收尾而不是卡在半截。第五层验证工具调用可以回传并继续执行。这是 Responses 和 Chat Completions 差异最大的地方。让 Codex CLI 执行一个需要调用工具的任务比如读取一个文件再修改它。成功的结果是工具被调用、结果回传、下一轮继续执行而不是首轮有文字但工具不执行。第五层通过后整条链路才算可用。如果使用 TaoToken 这类统一模型服务也按同样顺序核验配置严格加载、请求进入正确路径、流式事件完整结束、工具调用可以回传并继续执行。只完成其中一层不代表整条链路可用。一个可观察的成功信号是Codex CLI 在诊断结果里识别出wire API: responses并且后续工具任务能连续执行多轮。如果只看到连接成功但工具不执行说明协议层可能被中转层截断了需要回看服务端日志里的实际模型、状态码、耗时和错误阶段。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth排障的核心思路是「先确认请求有没有离开客户端再判断问题属于网络、网关、模型还是事件解析」。下面按真实报错对照。401 Unauthorized。请求已经到达服务端但 Key 无效或没带上。检查env_key填的是不是环境变量名称以及这个环境变量在当前 shell 里是否真的存在。用[ -n $TAOTOKEN_API_KEY ]确认存在性不要打印内容。如果环境变量在别的终端会话里设置当前会话可能读不到重新开一个终端或重新 source 配置。local proxy failed。这类报错通常出现在客户端尝试走本地代理但代理不可达。检查你的网络配置里是否残留了本地代理设置以及base_url是否被错误地指向了本地地址。Codex CLI 的base_url应该指向 TaoToken 的 API 地址不是本地端口。如果你之前配过本地测试提供商确认当前model_provider指向的是正确的段。reading choices 相关报错。这个报错很典型客户端在响应里找choices字段但 Responses 协议的响应结构里没有这个字段。出现它通常意味着协议不匹配——要么wire_api配错了要么中转层把 Responses 请求转发到了 Chat Completions 端点。回到配置确认wire_api responses并确认服务端真的实现了 Responses 协议而不是只改写了路径。OAuth 相关报错。如果你用的是需要 OAuth 的提供商配置报错可能和 Key 认证方式冲突。Codex CLI 的env_key走的是 API Key 认证不要和 OAuth 流程混用。确认你的提供商段用的是env_key而不是 OAuth 相关字段。如果确实需要 OAuth那是另一套配置和本篇的 API Key 通道不冲突但不要在同一段里混写。404 Not Found。请求到达了服务端但路径不对。检查base_url是否包含/v1以及 Codex CLI 拼接后的最终路径是否是/v1/responses。404 和 401 的区别很重要401 是认证问题404 是路径问题两者排查方向完全不同。HTTP 200 但工具不执行。这是最隐蔽的一类。HTTP 200 不能直接证明兼容还要检查响应结构、流式结束事件以及工具结果能否进入下一轮。如果中转层只改写路径没有完整处理工具项、调用标识、流式事件和上下文就会出现首轮有文字但工具不执行、流式输出中断、工具结果无法续接等现象。这类问题要看服务端日志确认工具调用项是否被正确透传。排查顺序建议固定下来运行codex --version记录版本用严格配置确认配置能加载核对wire_api是否为responses核对 Base URL 最终是否指向/v1/responses用最小文本任务验证非流式响应再验证流式事件、工具调用和多轮续接最后回看服务端日志。这个顺序能避免一个常见误区配置层已经拒绝请求却一直在服务端改模型路由。6. 按场景选协议与后续接入路径回到标题的问题Responses 与 Chat Completions 怎么选现在已经不是二选一而是「看客户端要什么」。如果你配置的是当前 Codex CLI自定义提供商应使用responses。如果你只是自己写一个简单聊天脚本Chat Completions 仍然可用。两件事不要混在一起服务端能力不等于客户端协议要求。按场景分Codex CLI 的编码任务、工具调用、多轮上下文续接走 Responses。已有聊天应用、简单单轮生成、你自己写的脚本走 Chat Completions。如果你在同一个项目里两者都有就分别配置不要试图用一个wire_api覆盖所有场景。后续接入路径上如果你要把 Codex CLI 接到 TaoToken 统一通道配置片段就是第 3 节那段验证步骤就是第 4 节那五层。需要长期跑编码任务或 Agent 场景的可以看 Coding Plan 页面了解额度与通道安排https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里面有各协议的路径说明。如果你用的是 Claude Code 或 Anthropic 相关配置对应入口是 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后留一个实用习惯每次改完config.toml先跑配置加载检查再发最小请求最后才跑真实工具任务。把「协议配置错误」和「网络不可达」拆成两个阶段通常比反复更换模型、Base URL 和 Key 更快也能避免把客户端协议错误误判成上游故障。配置层通过、请求进入正确路径、流式事件完整结束、工具调用可以回传这四层都过了才算真正接入完成。 
长河君 · 2026/10/18 18:52:03 · 阅读 1.2k Codex CLI 的 Responses 与 Chat Completions 怎么选？现在已经不是二选一
1. Codex CLI 里 wire_api 到底在选什么Codex CLI 的wire_api不是「用哪个模型」的开关而是「客户端按哪套协议把请求发出去」的开关。你把它理解成插头形状更贴切插座服务端可能同时有圆孔和扁孔但你的插头Codex CLI只有一种形状插错了不是电压问题是根本插不进去。当前 Codex CLI 需要持续处理推理项、工具调用、命令执行结果、文件变更和多轮上下文。这些内容在 Responses 协议里有对应的结构化字段比如input数组里可以放消息、推理项、工具调用及其结果。而 Chat Completions 的典型结构是messages数组响应文本落在choices里它没有为「工具结果如何续接下一轮」设计完整的上下文组织方式。所以结论先放这里当前 Codex CLI 的自定义提供商应使用wire_api responses对应服务端路径通常是/v1/responses。Chat Completions 仍然是一个存在的 API适合你自己写简单聊天脚本或已有聊天应用但它不是 Codex CLI 的可互换备用开关。这里要分清两件事。「模型服务是否支持 Chat Completions」描述的是服务端能力「Codex CLI 当前使用什么 wire API」描述的是客户端协议要求。服务端同时支持两个入口不代表 Codex CLI 可以任意选。最终要看客户端发送什么结构、等待什么事件、如何恢复后续轮次。我实测过一个典型误区有人看到服务端文档写着「兼容 OpenAI Chat Completions」就把wire_api填成chat然后反复换模型名、查余额、加重试。实际上请求根本没离开客户端配置加载阶段就被拦下了。下面按阶段拆开讲先解决配置再解决通道最后验证请求真的跑通。2. 把 endpoint 改到 TaoToken 统一通道的前置准备在动config.toml之前先把「Key 从哪来、Base URL 填什么、模型 ID 写哪个」这三件事定下来。Codex CLI 的配置里env_key写的是环境变量名称不是把真实 Key 直接写进文件。这一点很多人第一次配会踩坑把sk-xxx直接塞进env_key结果客户端去读一个叫sk-xxx的环境变量当然读不到。TaoToken 在这里的角色是统一 Key/API 通道你用同一个 Key通过它的 API 入口访问模型Codex CLI 侧只需要把base_url指向 TaoToken 的 API 地址wire_api保持responses。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置里填干净的基址就行。具体准备三步第一步拿到 Key。进入控制台的 API Keys 页面创建或复制一个 Key。这个页面地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。创建后先别急着贴进配置文件放到环境变量里。第二步确认模型 ID。不同模型在服务端的标识不一样别凭记忆写。可以在模型对话页面先手动发一条消息确认这个模型 ID 是服务端实际接受的。模型对话入口是 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。这一步很关键因为model字段写错请求会进到服务端但被路由拒绝报错信息往往和协议无关容易误导排查方向。第三步设置环境变量。Linux/macOS 下可以写进 shell 配置Windows 下用系统环境变量或 PowerShell 的$env:。以 Linux/macOS 为例export TAOTOKEN_API_KEY你的Key验证环境变量是否存在只看名字不要输出内容[ -n $TAOTOKEN_API_KEY ] echo env exists || echo env missing这里有个安全习惯排查时只确认环境变量是否存在不要把 Key 打印到终端、截图或共享配置里。Codex CLI 的env_key字段填的是变量名TAOTOKEN_API_KEY不是变量值。如果你用的是 Claude Code 或 Cline 这类工具接入逻辑类似都是 Base URL Key Model ID 三件套。但 Codex CLI 的特殊点在于wire_api必须是responses这是它和其他聊天客户端最大的配置差异。前置准备做完下面进入可复制的配置片段。3. 可复制的 config.toml 配置片段与切换步骤Codex CLI 的配置文件默认在~/.codex/config.tomlWindows 下是%USERPROFILE%\.codex\config.toml。如果你之前配过别的提供商先备份一份cp ~/.codex/config.toml ~/.codex/config.toml.bak然后写入下面这段最小可用配置。注意base_url的拼接规则TaoToken 的 API 基址是https://taotoken.net/apiCodex CLI 会在后面拼/v1/responses所以base_url填到/api/v1这一层具体以你实际路由拼接结果为准配完用后面的验证步骤确认最终路径。model your-model-id model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api/v1 env_key TAOTOKEN_API_KEY wire_api responses重点核对四项。model必须是服务端实际接受的模型标识就是你在模型对话页面验证过的那个。base_url是否包含/v1要和 Codex CLI 的路由拼接规则一致填错会出现 404 而不是 401这个区别后面排障会用到。env_key写环境变量名称不是真实 Key。wire_api使用responses服务端必须真正实现对应协议。如果你需要保留多个提供商可以写成多段用model_provider切换model your-model-id model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api/v1 env_key TAOTOKEN_API_KEY wire_api responses [model_providers.local-test] name Local Test base_url http://127.0.0.1:9999/v1 env_key LOCAL_TEST_KEY wire_api responses切换时只改model_provider的值其他段保持不动。这样排查时可以把「协议配置错误」和「网络不可达」拆成两个阶段本地测试提供商故意指向不可达端口配置层能正常加载说明协议字段没问题换成 TaoToken 后如果连通性失败问题就在网络或 Key不在wire_api。配置写完后先做配置加载检查不要直接发请求。Codex CLI 在严格配置模式下会在加载阶段拦截非法wire_api。如果你把wire_api写成chat会看到类似这样的提示Error loading config.toml: wire_api chat is no longer supported. How to fix: set wire_api responses in your provider config.这个报错发生在请求发出之前此时换模型名、调余额、加重试都没有意义。看到这个提示直接改wire_api就行。配置层通过后再进入下一节的请求验证。4. 验证请求与成功结果从配置加载到工具续接验证要分层做不要一上来就跑复杂任务。我实测下来按下面顺序能最快定位问题在哪一层。第一层确认客户端版本。不同版本的 Codex CLI 对wire_api的支持有差异先记录实际版本codex --version第二层确认配置能加载。用诊断或严格配置模式跑一次观察输出里是否识别到你的提供商和协议。正常应该能看到类似model provider: TaoToken和wire API: responses的字段。如果这一步就报wire_api不支持回到上一节改配置。第三层用最小文本任务验证非流式响应。先发一条最简单的指令比如让它输出一句话确认请求真的到达服务端并返回内容。这一步成功说明 Base URL、Key、模型 ID、协议四者基本对齐。第四层验证流式事件完整结束。Codex CLI 在编码任务里大量使用流式输出如果中转层只改写路径却没完整处理流式事件常见现象是首轮有文字但中途中断或者客户端报「响应格式不完整」。观察流式输出是否能正常收尾而不是卡在半截。第五层验证工具调用可以回传并继续执行。这是 Responses 和 Chat Completions 差异最大的地方。让 Codex CLI 执行一个需要调用工具的任务比如读取一个文件再修改它。成功的结果是工具被调用、结果回传、下一轮继续执行而不是首轮有文字但工具不执行。第五层通过后整条链路才算可用。如果使用 TaoToken 这类统一模型服务也按同样顺序核验配置严格加载、请求进入正确路径、流式事件完整结束、工具调用可以回传并继续执行。只完成其中一层不代表整条链路可用。一个可观察的成功信号是Codex CLI 在诊断结果里识别出wire API: responses并且后续工具任务能连续执行多轮。如果只看到连接成功但工具不执行说明协议层可能被中转层截断了需要回看服务端日志里的实际模型、状态码、耗时和错误阶段。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth排障的核心思路是「先确认请求有没有离开客户端再判断问题属于网络、网关、模型还是事件解析」。下面按真实报错对照。401 Unauthorized。请求已经到达服务端但 Key 无效或没带上。检查env_key填的是不是环境变量名称以及这个环境变量在当前 shell 里是否真的存在。用[ -n $TAOTOKEN_API_KEY ]确认存在性不要打印内容。如果环境变量在别的终端会话里设置当前会话可能读不到重新开一个终端或重新 source 配置。local proxy failed。这类报错通常出现在客户端尝试走本地代理但代理不可达。检查你的网络配置里是否残留了本地代理设置以及base_url是否被错误地指向了本地地址。Codex CLI 的base_url应该指向 TaoToken 的 API 地址不是本地端口。如果你之前配过本地测试提供商确认当前model_provider指向的是正确的段。reading choices 相关报错。这个报错很典型客户端在响应里找choices字段但 Responses 协议的响应结构里没有这个字段。出现它通常意味着协议不匹配——要么wire_api配错了要么中转层把 Responses 请求转发到了 Chat Completions 端点。回到配置确认wire_api responses并确认服务端真的实现了 Responses 协议而不是只改写了路径。OAuth 相关报错。如果你用的是需要 OAuth 的提供商配置报错可能和 Key 认证方式冲突。Codex CLI 的env_key走的是 API Key 认证不要和 OAuth 流程混用。确认你的提供商段用的是env_key而不是 OAuth 相关字段。如果确实需要 OAuth那是另一套配置和本篇的 API Key 通道不冲突但不要在同一段里混写。404 Not Found。请求到达了服务端但路径不对。检查base_url是否包含/v1以及 Codex CLI 拼接后的最终路径是否是/v1/responses。404 和 401 的区别很重要401 是认证问题404 是路径问题两者排查方向完全不同。HTTP 200 但工具不执行。这是最隐蔽的一类。HTTP 200 不能直接证明兼容还要检查响应结构、流式结束事件以及工具结果能否进入下一轮。如果中转层只改写路径没有完整处理工具项、调用标识、流式事件和上下文就会出现首轮有文字但工具不执行、流式输出中断、工具结果无法续接等现象。这类问题要看服务端日志确认工具调用项是否被正确透传。排查顺序建议固定下来运行codex --version记录版本用严格配置确认配置能加载核对wire_api是否为responses核对 Base URL 最终是否指向/v1/responses用最小文本任务验证非流式响应再验证流式事件、工具调用和多轮续接最后回看服务端日志。这个顺序能避免一个常见误区配置层已经拒绝请求却一直在服务端改模型路由。6. 按场景选协议与后续接入路径回到标题的问题Responses 与 Chat Completions 怎么选现在已经不是二选一而是「看客户端要什么」。如果你配置的是当前 Codex CLI自定义提供商应使用responses。如果你只是自己写一个简单聊天脚本Chat Completions 仍然可用。两件事不要混在一起服务端能力不等于客户端协议要求。按场景分Codex CLI 的编码任务、工具调用、多轮上下文续接走 Responses。已有聊天应用、简单单轮生成、你自己写的脚本走 Chat Completions。如果你在同一个项目里两者都有就分别配置不要试图用一个wire_api覆盖所有场景。后续接入路径上如果你要把 Codex CLI 接到 TaoToken 统一通道配置片段就是第 3 节那段验证步骤就是第 4 节那五层。需要长期跑编码任务或 Agent 场景的可以看 Coding Plan 页面了解额度与通道安排https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里面有各协议的路径说明。如果你用的是 Claude Code 或 Anthropic 相关配置对应入口是 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后留一个实用习惯每次改完config.toml先跑配置加载检查再发最小请求最后才跑真实工具任务。把「协议配置错误」和「网络不可达」拆成两个阶段通常比反复更换模型、Base URL 和 Key 更快也能避免把客户端协议错误误判成上游故障。配置层通过、请求进入正确路径、流式事件完整结束、工具调用可以回传这四层都过了才算真正接入完成。