Responses协议深度解析：从“聊天”到“干活”的架构革命

当我为了省 Token、保账号用剪贴板操控 DeepSeek 网页版时才真正理解了为什么 OpenAI 要彻底抛弃 Chat 协议也要强推这套有状态的 Responses。1. 引言一个“魔怔”开发者的自白故事的起点很荒诞。几个月前我跟朋友吹牛说一个月消耗多少 Token 才算“大手子”。朋友晒出的账单是月烧 3 亿 Token我嘴上说“这不就是随便的事吗”心里却在盘算怎么才能让自己的 Token 统计数字也暴涨于是我开始折腾一个奇怪的项目用 DeepSeek 网页版当大脑让 Claude Code 当手自己在中间搭一个反代把 Claude Code 发出的 Anthropic Messages 协议请求翻译成对 DeepSeek 网页版的模拟操作。这项目听起来很完美DeepSeek 网页版靠 conversation_id 自动维护上下文我每次只需要把最新一句话发过去Token 消耗小、行为特征低调、还能绕过 API 费用。我甚至专门研究了怎么模拟人类打字延迟、怎么随机间隔、怎么避免并发请求——一切为了保号。但很快我发现了一个致命问题OpenAI 官方的 Codex底层用的是 Responses 协议不是 Chat Completions。而 DeepSeek 根本不支持 Responses。所有民间接入方案全部失效。为了弄懂为什么我开始深挖 Chat 和 Responses 的区别。这一挖不要紧我彻底理解了什么叫“协议即架构”——也明白了为什么我必须自己造轮子。2. 我的反代方案是怎么运作的在聊协议之前先交代清楚我的架构。核心思路大脑DeepSeek 网页版负责所有推理和理解通过 conversation_id 自动维护上下文。手Claude Code Tauri 工具负责执行工具调用——读文件、写文件、跑命令。翻译官我的本地代理把 Claude Code 发来的 Anthropic 格式请求转换成对 DeepSeek 网页版的简单消息再把 DeepSeek 的回复翻译回 Anthropic 格式。保号措施不开流式一次请求一次回复干净利落没有长连接特征。维持单一长会话整个工作过程只用一个 conversation_id绝不并行开新会话。剪贴板法用朋友项目的剪贴板交互模块操作 DeepSeek 网页版行为模式完全像一个手动复制粘贴的正常用户。关键代码逻辑defget_last_user_message(messages):formsginreversed(messages):ifmsg[role]user:returnmsg[content]return每次收到 Claude Code 的全量历史我只取最后一条用户消息发给 DeepSeek。其余全部丢弃。3. Chat Completions 协议“无状态”的原罪在折腾反代的过程中我每天都在和两种协议打交道。Anthropic Messages API 和 OpenAI Chat Completions API本质上是一类东西无状态的对话协议。什么叫无状态就是每次 API 请求你都必须把整个对话历史全量发送过去。模型不存储任何上下文全靠你喂。这带来三个问题第一Token 浪费恐怖。Claude Code 每次调用工具后都会把完整历史重新组装成 messages 数组发给我。虽然我只取最后一条发给 DeepSeek但 Claude Code 和代理之间的本地传输也是实打实的几万 Token。我心想这要是在公网上跑早就触发风控了。第二上下文管理全靠自己。多步骤任务需要几十轮交互每轮都全量发送历史很快就会触及模型上下文上限。开发者必须自己实现历史的裁剪、总结、管理——这些都是额外的工作量。第三工具调用是“瘸腿”的。Chat Completions 的 function calling 只是一个“信号”模型说“我想调工具了”然后开发者自己在外层写死循环手动处理“调用→获取结果→再次推理”的循环。这就像你让一个将军指挥战斗但将军的命令只能传达到通信兵通信兵得自己跑去找炮兵、自己看地图然后回来再问将军下一步怎么办。4. 沙箱谜题云端还是本地在研究 Codex 的时候我一度被“沙箱”这个概念搞懵了。我问自己Codex 要配置的沙箱到底是什么是本地 Docker 容器还是 OpenAI 服务器上的虚拟机答案很明确服务器端的跑在 OpenAI 的云端不在你本地。运作方式就像给你分配了一台临时的“云电脑”临时且独立每次提交任务云端新建独立沙箱自动装好 JDK、Python 等环境。任务结束或超时立刻销毁。代码是“拷贝”上去的不是直接改你本地文件而是把你 GitHub 仓库的代码拷到沙箱里改完测完再推回 GitHub。默认断网绝对隔离沙箱环境默认互联网断开除非明确授权。但更让我震惊的是这个云端沙箱不是 OpenAI 自己的数据中心而是第三方托管的。E2B、Cloudflare、Daytona 这些沙箱提供商负责执行环境OpenAI 只负责调度模型。两者物理分离责任也分离——代码在沙箱里跑出问题是沙箱厂商的锅不是 OpenAI 的锅。我瞬间理解了这和我用剪贴板方案操作 DeepSeek 网页版的思路一模一样。都是在用“隔离”换“安全”。只不过 OpenAI 用云端沙箱我用剪贴板隔断。5. Responses 协议“有状态”的革命搞清楚了沙箱再来理解为什么 Codex 必须换协议就豁然开朗了。Responses 协议的核心突破是引入服务端状态管理。旧协议Chat的痛苦模式请求1: [用户指令] 响应1: [我要调工具] → 你手动执行工具 请求2: [用户指令, 旧响应1, 工具结果] ← 重复历史 响应2: [继续] → 你手动执行工具 请求3: [用户指令, 旧响应1, 工具结果, 旧响应2, 新工具结果] ← 更长了新协议Responses的优雅模式请求1: [用户指令] 响应1: [response_id: resp_001, 我要调工具] → 沙箱自动执行工具 请求2: [previous_response_id: resp_001, 然后呢] 响应2: [自动拼接历史继续]关键变化就两个input 不叫 messagesChat 协议用 messages 数组Responses 用 input。命名差异反映了定位差异——一个是“对话历史”一个是“任务输入”。previous_response_id这个东西让服务端自动拼接历史你不需要再发全量历史了。这彻底解决了无状态协议的三大痛点。更重要的是Responses 内置了工具调用循环——模型请求调工具沙箱自动执行结果自动返回模型继续推理。整个“思考-行动-观察”循环在服务端完成不用你管。6. 为什么 DeepSeek 不支持 Responses理解了 Responses 的优势下一个问题就是为什么 DeepSeek 不跟进答案很直接Responses 协议强依赖服务端沙箱能力。DeepSeek 的 API 只是一个文本推理接口没有内置沙箱。要实现 Responses意味着要从零搭建一整套云端执行环境——这不仅是技术投入的问题更是商业模式的根本差异。OpenAI 选择把“手”也做成官方服务云端沙箱让你用 Responses 协议一体调用。DeepSeek 选择只做“大脑”把“手”留给开发者自己实现。这恰好解释了为什么我必须继续搞自己的反代项目。当官方平台不提供“有状态执行”能力时通过协议翻译和外部工具链来补全这套“手”的能力就是唯一的出路。7. 结语协议即架构架构即选择回头看我的“反代保号”之路最初只是想省点 Token、让统计数字好看点。但深入了解 Chat 和 Responses 的差异后我意识到协议不是简单的接口格式而是架构哲学的外化。Chat Completions 代表的是“无状态、纯推理”的传统 AI 交互——模型只负责想做不做、怎么做都是你的事。Responses 代表的是“有状态、带执行”的新范式——模型既能想又能做你要做的就是给任务、看结果。OpenAI 用 Responses 协议把“手”锁在云端沙箱里既保障了安全也绑定了生态。DeepSeek 坚持 Chat 协议把“手”的自由度还给了开发者但也把保号、安全、调度这些脏活累活全留给了你。而我这个“魔怔”开发者选择用剪贴板模拟和协议翻译在两者之间走出一条自己的路用有状态网页版的便利结合无状态协议的灵活搭一套既安全又能干活的私人 Agent 框架。这或许就是独立开发者的浪漫不满足于官方给的沙箱玩具非要自己用“反代”和“剪贴板”这种土法子造一个真正能碰本地文件、跑命令行、还不会封号的 AI 工作流。本文作者正试图用一个 DeepSeek 网页版、一个 Tauri 剪贴板工具、和一个不到 200 行的 Python 代理取代昂贵的 API 订阅。目前还在保号的路上继续努力。