面试里被问到 MCP 传输方式答成 WebSocket 是大厂面经里被反复标注的扣分点。这篇用排障视角来处理它先用 TaoToken官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole 申请一个 Key把 TaoToken 当成 Codex 后面的统一模型通道Base URL 填 https://taotoken.net/api 然后把原文面经里的传输方式表格整段贴给 Codex让它逐行核对WebSocketSSE 旧模式Streamable HTTP这几个说法哪里错、错在哪个层次。需要先说清楚边界TaoToken 只出现在 Key 与通道配置这一步它不接管 MCP 传输也不代理任何 MCP Serverstdio 和 Streamable HTTP 的验证仍然要在本地做。真正的痛点是自测时容易漏掉 v2025-03 的推荐项或者把服务端能推送直接等同于要用 WebSocket下面按配置、验证、排查三段走。原问题与场景MCP 传输方式答成 WebSocket 错在哪原文 Q3 和 Q29 反复强调同一件事MCP 的传输方式不是 WebSocket而且这不是一个冷门知识点是面试官用来判断你有没有真正读过协议规范的筛子。错误答案的典型逻辑链是这样的MCP 需要双向通信服务端要主动推结果给客户端WebSocket 是全双工长连接所以 MCP 用 WebSocket。这条链条每一步看着都合理但结论是错的因为前提就搞混了层次。正确的分类要按调用位置拆传输方式适用场景是否走网络底层消息格式stdio本地工具、子进程调用否JSON-RPC 2.0Streamable HTTP远程工具v2025-03 推荐是JSON-RPC 2.0HTTP SSE旧模式旧版远程实现已不推荐是JSON-RPC 2.0memory进程内仅测试否JSON-RPC 2.0gRPC后续演进方向是非 JSON-RPC 主线这里有两个必须答出来的点。第一消息格式与传输方式彻底解耦。不管底层是进程管道还是 HTTPMCP 的消息体始终是 JSON-RPC 2.0请求带 jsonrpc、id、method、params响应带 result 或 error。所以WebSocket 更实时这种理由不成立因为它根本没动到消息格式这一层。第二服务端推送不需要 WebSocket。Streamable HTTP 的单个端点通过 POST 发请求响应可以是普通 JSON也可以是 SSE 流服务端在流里继续下发消息。旧模式的 HTTPSSE 用了 GET 长连接加 POST 两个端点实现更重、更容易在网关和负载均衡上出问题所以新版把它收敛成 Streamable HTTP。面试官常追的下一句是那本地为什么不走 HTTP答案在于本地 MCP Server 是客户端拉起的子进程父子进程之间用标准输入输出传 JSON-RPC 报文即可走的是进程管道而不是网络栈延迟在微秒级也没有端口占用和鉴权问题。这一层如果答不清楚很容易被判断成只背了结论。自己背题的问题在于表格能记住三行但追问一绕就散。所以下面用 Codex 把这份表格变成逐题核对流程而 Codex 需要一个稳定的模型通道这就是 TaoToken 出现的位置。TaoToken 前置模型通道与 MCP 传输是两件事把这两件事分开放后面的配置才不容易错。TaoToken 在这里提供的是模型通道一个 Key、一个 Base URL让 Codex 这类客户端能把请求发到统一入口。它不参与 MCP 的传输选型不改变 stdio 或 Streamable HTTP 的行为也不替代任何 MCP Server 的运行。你在本地用 npx 起一个 filesystem server走的就是 stdio你在本地起一个带 /mcp 端点的服务走的就是 Streamable HTTP。这两条链路上都没有 TaoToken 的参与。准备动作只有三步打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole 完成注册并进入控制台。在 API Keys 页面创建一个 Key形如 YOUR_API_KEY创建后立刻复制保存页面通常不会再次完整展示。确认模型通道地址是 https://taotoken.net/api 后面 config.toml 里的 base_url 就填这个注意不要漏掉 /api 这一段。如果这一步遇到控制台入口找不到、Key 创建后不知道怎么用可以直接看接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc 里面有各客户端的字段说明。Key 不要写进代码仓库也不要贴到聊天记录里。推荐用环境变量注入后面配置里只引用变量名。Codex config.toml 可复制配置把 TaoToken 接成统一模型通道Codex 侧的配置文件是 ~/.codex/config.tomlWindows 下在用户目录的 .codex 文件夹里。没有这个文件就新建一个。# ~/.codex/config.toml model MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat # 按接入文档选择 chat 或 responses字段随版本演进MODEL_ID 以控制台里实际可用的模型名为准不要照抄示例。wire_api 这一项在不同 Codex 版本里取值不同如果启动后报 404 或参数不识别先回到接入文档核对当前版本应该填哪个值再改配置。环境变量在 shell 里设置export TAOTOKEN_API_KEYYOUR_API_KEY想让它长期生效就把这一行写进 ~/.zshrc 或 ~/.bashrc然后 source 一次。Windows PowerShell 用 $env:TAOTOKEN_API_KEYYOUR_API_KEY需要持久化就写进系统环境变量。配好之后进入项目目录直接启动 Codex。此时模型请求走 TaoToken而 MCP 相关的一切仍然由你在本地控制你在 Codex 里挂载的 MCP Server 用什么传输跟这份 config.toml 没有关系。这一点在排查时特别重要很多配了 TaoToken 但 MCP 还是连不上的问题其实两边根本不是同一条链路。验证请求与成功结果让 Codex 对照面经表格逐题纠错先验证模型通道本身通不通再谈纠错否则会把通道问题和知识问题混在一起。第一步确认 Key 与 Base URL 能正常返回curl -sS https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY | head -c 400能返回模型列表就说明通道没问题。如果这里返回 401是 Key 无效或没被正确注入返回 404多半是 base_url 少了 /api 或路径拼错。第二步在 Codex 里开一个会话把面经表格和你的答案一起贴进去用下面这段提示词下面是一份 MCP 传输方式相关的面试题材料。我的回答是MCP 使用 WebSocket 实现双向通信因为服务端需要主动推送结果。 请按以下顺序处理 1. 指出我的回答在哪一层出错说明为什么不能答 WebSocket 2. 区分本地 stdio 与远程 Streamable HTTP 的适用场景说明 HTTPSSE 旧模式为什么不推荐 3. 解释消息格式为什么固定是 JSON-RPC 2.0它与传输方式是如何解耦的 4. 给出三个面试官可能继续追问的方向并各写一段 100 字以内的作答要点。 表格如下 在此粘贴传输方式表格第三步看返回结果是否覆盖了这些判定WebSocket 属于传输层选项MCP 没有采用本地用 stdio走进程管道不走网络远程推荐 Streamable HTTP单端点 POST 加可选 SSE 流HTTPSSE 是旧模式已不推荐所有传输方式下消息体统一是 JSON-RPC 2.0。缺哪一条就继续追问哪一条直到三类场景都能用一句话说清。第四步回到本地做小验证把口头答案变成手上动作。stdio 方向可以起一个本地 servernpx -y modelcontextprotocol/server-filesystem .这个进程由客户端拉起通过标准输入输出收发 JSON-RPC 报文全程没有网络连接也没有端口。远程方向可以起一个带 Streamable HTTP 端点的服务然后用带 Accept 头的请求打它curl -sS -X POST http://127.0.0.1:3000/mcp \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -d {jsonrpc:2.0,id:1,method:initialize,params:{省略}}Accept 头同时声明 JSON 和 event-stream是 Streamable HTTP 的典型特征。跑通这两条面试里再被问到你怎么确认的就有具体依据可讲。本篇常见错排查WebSocket、SSE、stdio 三类报错怎么定位按出错位置分类比逐条背结论效率高得多。第一类是概念答错不涉及任何配置。表现是回答里出现WebSocket 全双工所以 MCP 用它。定位方法很简单问一句消息格式是什么。如果答案是 JSON-RPC 2.0那传输层就不可能被 WebSocket 绑死因为格式与传输是解耦的。修正说法是把本地和远程分开讲本地 stdio 不涉及网络远程推荐 Streamable HTTP。第二类是把 SSE 旧模式当成推荐项。旧模式需要 GET 长连接加 POST 两个端点长连接在网关、鉴权、审计链路上都更麻烦。现在远程场景应优先答 Streamable HTTPSSE 只在讲历史演进或兼容旧实现时提。这类错误在面试里表现为答对了有大方向但推荐项说反了属于细节扣分。第三类是配置层混线。常见表现有这几种把 MCP Server 的访问地址写成 https://taotoken.net/api 这是把模型通道和 MCP 端点搞混了config.toml 里 base_url 写成 https://taotoken.net 少了 /api请求直接 404Key 没有注入到环境变量Codex 启动时报鉴权失败或 401本地 stdio 场景却在配置里填了 HTTP 端点导致客户端拉不起子进程表现为连接被拒绝或进程立即退出。第四类是版本相关。wire_api 取值不对、模型名不存在、协议版本不匹配都会在启动阶段报错。处理顺序是先看错误码再回接入文档对照字段不要凭印象改配置。改完只改一处重新启动验证避免多个变量同时变动导致定位困难。第五类是判断依据缺失。答案说得对但被追问你怎么验证的时答不上来这一类不算报错但会失分。解决办法就是上一节的本地小验证stdio 起一个进程、远程打一次带 Accept 头的 POST两条链路都留下记录。需要继续接入与验证时的路径按问题类型分流比同一个入口反复试要快。如果卡在 Key 创建、config.toml 字段、接入报错这类排障问题上先看 API Keys 页面确认 Key 状态https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys 再对照接入文档核对每个字段https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc 。如果只是想快速验证某个模型在当前通道下能不能正常回答从而确认通道没问题用模型对话页面直接试一句https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat 。如果你打算把这条通道长期挂在 Codex 或 Agent 工作流里反复做逐题纠错、对照规范、写本地验证脚本这类事可以看 Coding Plan 的额度与说明https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan 把日常的模型调用集中到一个稳定入口上。最后再回到这道题本身。面试里被问到 MCP 传输方式时先用一句话定住边界本地用 stdio不走网络远程推荐 Streamable HTTP消息格式统一是 JSON-RPC 2.0与传输方式解耦。剩下的追问无论是 SSE 旧模式还是无状态化升级都可以沿着这条主线展开。想动手确认就按前面的 config.toml 配好通道让 Codex 逐题核对一遍再去本地把 stdio 和 Streamable HTTP 各跑一次。 
长河君 · 2026/9/19 21:03:15 · 阅读 1.2k MCP 传输方式答成 WebSocket 会被扣分？TaoToken 供 Key，让 Codex 对照面经查
面试里被问到 MCP 传输方式答成 WebSocket 是大厂面经里被反复标注的扣分点。这篇用排障视角来处理它先用 TaoToken官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole 申请一个 Key把 TaoToken 当成 Codex 后面的统一模型通道Base URL 填 https://taotoken.net/api 然后把原文面经里的传输方式表格整段贴给 Codex让它逐行核对WebSocketSSE 旧模式Streamable HTTP这几个说法哪里错、错在哪个层次。需要先说清楚边界TaoToken 只出现在 Key 与通道配置这一步它不接管 MCP 传输也不代理任何 MCP Serverstdio 和 Streamable HTTP 的验证仍然要在本地做。真正的痛点是自测时容易漏掉 v2025-03 的推荐项或者把服务端能推送直接等同于要用 WebSocket下面按配置、验证、排查三段走。原问题与场景MCP 传输方式答成 WebSocket 错在哪原文 Q3 和 Q29 反复强调同一件事MCP 的传输方式不是 WebSocket而且这不是一个冷门知识点是面试官用来判断你有没有真正读过协议规范的筛子。错误答案的典型逻辑链是这样的MCP 需要双向通信服务端要主动推结果给客户端WebSocket 是全双工长连接所以 MCP 用 WebSocket。这条链条每一步看着都合理但结论是错的因为前提就搞混了层次。正确的分类要按调用位置拆传输方式适用场景是否走网络底层消息格式stdio本地工具、子进程调用否JSON-RPC 2.0Streamable HTTP远程工具v2025-03 推荐是JSON-RPC 2.0HTTP SSE旧模式旧版远程实现已不推荐是JSON-RPC 2.0memory进程内仅测试否JSON-RPC 2.0gRPC后续演进方向是非 JSON-RPC 主线这里有两个必须答出来的点。第一消息格式与传输方式彻底解耦。不管底层是进程管道还是 HTTPMCP 的消息体始终是 JSON-RPC 2.0请求带 jsonrpc、id、method、params响应带 result 或 error。所以WebSocket 更实时这种理由不成立因为它根本没动到消息格式这一层。第二服务端推送不需要 WebSocket。Streamable HTTP 的单个端点通过 POST 发请求响应可以是普通 JSON也可以是 SSE 流服务端在流里继续下发消息。旧模式的 HTTPSSE 用了 GET 长连接加 POST 两个端点实现更重、更容易在网关和负载均衡上出问题所以新版把它收敛成 Streamable HTTP。面试官常追的下一句是那本地为什么不走 HTTP答案在于本地 MCP Server 是客户端拉起的子进程父子进程之间用标准输入输出传 JSON-RPC 报文即可走的是进程管道而不是网络栈延迟在微秒级也没有端口占用和鉴权问题。这一层如果答不清楚很容易被判断成只背了结论。自己背题的问题在于表格能记住三行但追问一绕就散。所以下面用 Codex 把这份表格变成逐题核对流程而 Codex 需要一个稳定的模型通道这就是 TaoToken 出现的位置。TaoToken 前置模型通道与 MCP 传输是两件事把这两件事分开放后面的配置才不容易错。TaoToken 在这里提供的是模型通道一个 Key、一个 Base URL让 Codex 这类客户端能把请求发到统一入口。它不参与 MCP 的传输选型不改变 stdio 或 Streamable HTTP 的行为也不替代任何 MCP Server 的运行。你在本地用 npx 起一个 filesystem server走的就是 stdio你在本地起一个带 /mcp 端点的服务走的就是 Streamable HTTP。这两条链路上都没有 TaoToken 的参与。准备动作只有三步打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole 完成注册并进入控制台。在 API Keys 页面创建一个 Key形如 YOUR_API_KEY创建后立刻复制保存页面通常不会再次完整展示。确认模型通道地址是 https://taotoken.net/api 后面 config.toml 里的 base_url 就填这个注意不要漏掉 /api 这一段。如果这一步遇到控制台入口找不到、Key 创建后不知道怎么用可以直接看接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc 里面有各客户端的字段说明。Key 不要写进代码仓库也不要贴到聊天记录里。推荐用环境变量注入后面配置里只引用变量名。Codex config.toml 可复制配置把 TaoToken 接成统一模型通道Codex 侧的配置文件是 ~/.codex/config.tomlWindows 下在用户目录的 .codex 文件夹里。没有这个文件就新建一个。# ~/.codex/config.toml model MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat # 按接入文档选择 chat 或 responses字段随版本演进MODEL_ID 以控制台里实际可用的模型名为准不要照抄示例。wire_api 这一项在不同 Codex 版本里取值不同如果启动后报 404 或参数不识别先回到接入文档核对当前版本应该填哪个值再改配置。环境变量在 shell 里设置export TAOTOKEN_API_KEYYOUR_API_KEY想让它长期生效就把这一行写进 ~/.zshrc 或 ~/.bashrc然后 source 一次。Windows PowerShell 用 $env:TAOTOKEN_API_KEYYOUR_API_KEY需要持久化就写进系统环境变量。配好之后进入项目目录直接启动 Codex。此时模型请求走 TaoToken而 MCP 相关的一切仍然由你在本地控制你在 Codex 里挂载的 MCP Server 用什么传输跟这份 config.toml 没有关系。这一点在排查时特别重要很多配了 TaoToken 但 MCP 还是连不上的问题其实两边根本不是同一条链路。验证请求与成功结果让 Codex 对照面经表格逐题纠错先验证模型通道本身通不通再谈纠错否则会把通道问题和知识问题混在一起。第一步确认 Key 与 Base URL 能正常返回curl -sS https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY | head -c 400能返回模型列表就说明通道没问题。如果这里返回 401是 Key 无效或没被正确注入返回 404多半是 base_url 少了 /api 或路径拼错。第二步在 Codex 里开一个会话把面经表格和你的答案一起贴进去用下面这段提示词下面是一份 MCP 传输方式相关的面试题材料。我的回答是MCP 使用 WebSocket 实现双向通信因为服务端需要主动推送结果。 请按以下顺序处理 1. 指出我的回答在哪一层出错说明为什么不能答 WebSocket 2. 区分本地 stdio 与远程 Streamable HTTP 的适用场景说明 HTTPSSE 旧模式为什么不推荐 3. 解释消息格式为什么固定是 JSON-RPC 2.0它与传输方式是如何解耦的 4. 给出三个面试官可能继续追问的方向并各写一段 100 字以内的作答要点。 表格如下 在此粘贴传输方式表格第三步看返回结果是否覆盖了这些判定WebSocket 属于传输层选项MCP 没有采用本地用 stdio走进程管道不走网络远程推荐 Streamable HTTP单端点 POST 加可选 SSE 流HTTPSSE 是旧模式已不推荐所有传输方式下消息体统一是 JSON-RPC 2.0。缺哪一条就继续追问哪一条直到三类场景都能用一句话说清。第四步回到本地做小验证把口头答案变成手上动作。stdio 方向可以起一个本地 servernpx -y modelcontextprotocol/server-filesystem .这个进程由客户端拉起通过标准输入输出收发 JSON-RPC 报文全程没有网络连接也没有端口。远程方向可以起一个带 Streamable HTTP 端点的服务然后用带 Accept 头的请求打它curl -sS -X POST http://127.0.0.1:3000/mcp \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -d {jsonrpc:2.0,id:1,method:initialize,params:{省略}}Accept 头同时声明 JSON 和 event-stream是 Streamable HTTP 的典型特征。跑通这两条面试里再被问到你怎么确认的就有具体依据可讲。本篇常见错排查WebSocket、SSE、stdio 三类报错怎么定位按出错位置分类比逐条背结论效率高得多。第一类是概念答错不涉及任何配置。表现是回答里出现WebSocket 全双工所以 MCP 用它。定位方法很简单问一句消息格式是什么。如果答案是 JSON-RPC 2.0那传输层就不可能被 WebSocket 绑死因为格式与传输是解耦的。修正说法是把本地和远程分开讲本地 stdio 不涉及网络远程推荐 Streamable HTTP。第二类是把 SSE 旧模式当成推荐项。旧模式需要 GET 长连接加 POST 两个端点长连接在网关、鉴权、审计链路上都更麻烦。现在远程场景应优先答 Streamable HTTPSSE 只在讲历史演进或兼容旧实现时提。这类错误在面试里表现为答对了有大方向但推荐项说反了属于细节扣分。第三类是配置层混线。常见表现有这几种把 MCP Server 的访问地址写成 https://taotoken.net/api 这是把模型通道和 MCP 端点搞混了config.toml 里 base_url 写成 https://taotoken.net 少了 /api请求直接 404Key 没有注入到环境变量Codex 启动时报鉴权失败或 401本地 stdio 场景却在配置里填了 HTTP 端点导致客户端拉不起子进程表现为连接被拒绝或进程立即退出。第四类是版本相关。wire_api 取值不对、模型名不存在、协议版本不匹配都会在启动阶段报错。处理顺序是先看错误码再回接入文档对照字段不要凭印象改配置。改完只改一处重新启动验证避免多个变量同时变动导致定位困难。第五类是判断依据缺失。答案说得对但被追问你怎么验证的时答不上来这一类不算报错但会失分。解决办法就是上一节的本地小验证stdio 起一个进程、远程打一次带 Accept 头的 POST两条链路都留下记录。需要继续接入与验证时的路径按问题类型分流比同一个入口反复试要快。如果卡在 Key 创建、config.toml 字段、接入报错这类排障问题上先看 API Keys 页面确认 Key 状态https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys 再对照接入文档核对每个字段https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc 。如果只是想快速验证某个模型在当前通道下能不能正常回答从而确认通道没问题用模型对话页面直接试一句https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat 。如果你打算把这条通道长期挂在 Codex 或 Agent 工作流里反复做逐题纠错、对照规范、写本地验证脚本这类事可以看 Coding Plan 的额度与说明https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan 把日常的模型调用集中到一个稳定入口上。最后再回到这道题本身。面试里被问到 MCP 传输方式时先用一句话定住边界本地用 stdio不走网络远程推荐 Streamable HTTP消息格式统一是 JSON-RPC 2.0与传输方式解耦。剩下的追问无论是 SSE 旧模式还是无状态化升级都可以沿着这条主线展开。想动手确认就按前面的 config.toml 配好通道让 Codex 逐题核对一遍再去本地把 stdio 和 Streamable HTTP 各跑一次。