文章
ChatGPT 和 Codex 合并了，协议又动了一刀
ChatGPT 与 Codex 合并后协议再改，工具定义被移入 additional_tools，第三方模型收不到工具会假装调用。作者本地网关 AgentGate 已适配，将工具还原转发上游，合并版桌面端仍可指向本机调用 DeepSeek、
项目地址： https://github.com/dengmengmian/agentgate-ai
ChatGPT 和 Codex 合成一个桌面端之后，很多人第一反应是：界面变了、入口变了。
我关心的是另一层：
协议又动了一刀。
工具定义有时不在顶层的 tools里，而塞进 input 的 additional_tools。
不处理的话，第三方模型收不到工具列表，只能在正文里瞎写假 <tool_call>。
看起来像模型变笨了。
其实是中间被吃了。
我这边本地网关 AgentGate 已经跟上：把这类工具抬回去，再转给上游。 合并后的桌面端，仍然可以指到本机，继续调 DeepSeek、MiMo 等你配好的模型。
这不是另开一条产品线。 还是那句话： 模型接口配在 AgentGate 里，本地客户端从网关调——客户端怎么改版，我尽量让这一层接得住。
⸻
这事为什么值得先说
之前写过：我喜欢用 Codex，想用 DeepSeek，协议接不上，所以做了本地网关。 那是第一道卡：接上。
客户端一合并、一改协议，接上的人最容易再摔一跤。 工具丢了、假调用、排查半天以为是模型不行——这类坑会集中冒出来。
所以这篇先把合并版说清楚。 后面再说：接上之后，我怎么把多家模型收在一个入口里少手切。
⸻
我真正想要的，其实一直没变
越做越清楚，初衷不是「做一个抽象的 AI 网关概念」。
而是：
所有模型接口都配在 AgentGate 里。 本地任务——Codex、合并后的 ChatGPT 桌面端、Claude Code，还是别的——都能从这一个入口任意调用。
起点是 Codex + DeepSeek。 DeepSeek 不支持图片时，带图自动走 KimiCoding。 合并版协议变了，网关跟上。 手切模型太烦，多模型在路由里待命。
一条线，不是东一榔头西一棒子。
⸻
网关接上了，手还是闲不下来
接得上之后，第二个烦很快出现。
写代码用 DeepSeek，额度一紧就想换。 带图自动切人，这个顺。 但还有后台小任务、备用站、偶尔想试别家……
每多一家，就多一次「现在启用谁」的决策。 要么去点切换。 要么改配置。 要么在任务中途停下来想：这次该用哪个？
问题听起来不大。 对我这种每天挂着 Agent 写代码的人来说，它很实际。 我不想因为换模型，就把注意力从代码上拽走。
所以 AgentGate 后来做重的，是路由这一侧： 客户端只连本机一个地址。多模型在网关里待命，按规则接活。
⸻
一次多个，不是贪多
先说清楚：不是一个聊天窗口里同时跟十个模型说话。 是 多套模型能力同时挂在路由里。
这一枪用 A。 下一枪可能 B。 挂了试 C。 不用我再点一次「启用」。
常见做法是「一次启用一套」： 启用 DeepSeek → 写一阵 → 撞额度再点备用 → 要带图再切 vision……
AgentGate 是：
客户端 Apply 一次，指向 127.0.0.1:9090。
后面挂主模型、备用、带图条件、小任务条件。
有图、模型名像 haiku、429 / 5xx，按规则走。
日志里能看见这一枪到底用了谁。
同一家供应商也可以挂多个 Key：轮询着用，某个 Key 撞 429 了自动换下一个。
多模型是多家待命；多 Key 是同一家里多条命——额度分散、限流时少停手。
一句话我自己这么记：
- 配置切换回答「现在启用谁」。
- 网关回答「这一枪该用谁，不行换谁」。
有人会用 CC Switch 这类工具一键换供应商，那也很好用，解决的是配置怎么切得快。 我这边更想解决的是下一截：客户端已经指到本机之后，多模型怎么在路由里待命，少让我手切。
两边不冲突；需要的话也可以叠——切换工具指到 127.0.0.1:9090就行。
图片 图片
这和初衷是同一条线： 接口都收在本地网关。 文本可以优先 DeepSeek。 图片可以走 KimiCoding。 失败可以进 Provider 链。 小任务可以分流。 合并后的桌面端，也还是指到这一处。
不是一开始规划的「多模型平台」。 是用着用着——先接上，再跟上合并版，再少手切——才长出来的。
⸻
智能切换不是为了炫技
AI 编程真正影响效率的，往往不是某次回答快了几秒。 而是：它能不能稳定撑住你持续干活。
中间突然限流。 突然 5xx。 突然这个模型不接图片。 突然你得停下来切配置。 突然合并版工具全丢了。
这些打断，比慢几秒更伤。
所以路由、failover、合并版适配，对我来说都不是功能列表上的勾选项。 是为了少中断。
- 能透明代理，就不硬转。
- 必须转换，才转换。
- 能自动让不支持 vision 的 Provider 让路，就不让用户手判。
原则还是那句：
工具尽量站在前面挡复杂性，而不是制造新的复杂性。
⸻
完整输入输出日志，方便我开发
接第三方模型时，最烦的不是「调不通」三个字。 是调不通的时候，你不知道卡在哪一截。
客户端发出去的是什么？
网关转成什么样交给上游？
上游回了什么？
工具字段丢没丢？模型名映射对没对？
合并版 additional_tools抬上去了没有？
没有完整日志，就只能猜。 猜一轮，改配置一轮，再猜一轮——开发节奏全碎了。
所以 AgentGate 本地会留下请求级日志： 输入、输出，以及转换前后，该脱敏的脱敏。 出问题我先翻日志，对着 raw / converted 看，比在客户端和上游之间空转快得多。
这对我自己写代码、接新 Provider、查合并版协议坑，都是刚需。 不是为了做漂亮的看板，是为了少瞎猜。
⸻
顺带做了个桌宠
网关、日志、路由，看着都偏「控制台」。 用久了有个很实在的问题： 网关在跑、请求在走、今天花了多少——我不一定愿意一直盯面板。
所以后来加了桌宠。
它不是主菜。 也不是想做成第二个产品。 就是本机网关旁边，多一个轻量的存在感： Claude Code 在干活时，它会有反应。 忙的时候跳得勤一点，闲了会安静些。 今天花费偏高，会有点「吃撑」的样子。
也可以聊天；网关通的时候用真实模型回，不通就回落本地文案。 聊过的偏好能记一点，页面里也能改记忆。
这些能力，走的还是同一条本地网关——不是另接一家云。
宠物不替代日志，不替代路由配置。 它只是让「本机一直在跑」这件事，不那么干巴。 我继续写代码，状态从余光里扫一眼就行。
⸻
边界还是要守
边界不是「我不是 Codex」。 Codex、合并后的 ChatGPT 桌面端、Claude Code、OpenCode——它们该干什么还干什么。
我要守的是另一头： 模型接口只配一处——AgentGate。 本地任务从这一处任意调用。 Key、路由、映射、日志，收在本机网关。 客户端换代、合并、改协议，我尽量让网关接住，而不是每个工具里再铺一套供应商。
- 不做新的 IDE。
- 不做云上中转站。
- 宠物也不另接一家云，还是走同一入口。
边界不清楚，就容易越做越重。
所以定位还是克制：
本地入口。接口收口。多模型待命。完整日志看得见。客户端改版，网关尽量跟上。
⸻
我自己怎么用
装好之后大致是：
- 供应商里贴好各家 Key（能调的都配进来；同一家可以塞多个 Key）
- 启网关
- 路由里挂主备和条件
- 本地客户端（含合并版桌面端）Apply 到本机
- 发几条不同场景，去日志看走了谁——尤其看工具还在不在
Windows 若被 SmartScreen 拦一下：更多信息 → 仍要运行。 开源未签名安装包常见这样，不是病毒弹窗。
不适合谁，也直说：
- 只想永远用官方一个模型、从不换——可以不装。
- 要团队计费、多租户——看 LiteLLM / new‑api 一类。
- 只想点一下换中转配置——专用切换工具更轻；真要把多家收成一个本地入口，再来 AgentGate。
⸻
写在最后
AgentGate 对我来说，仍然不是从一个宏大概念开始的。
一开始只是： 我喜欢用 Codex，但我想用 DeepSeek。
后来越来越清楚，真正想要的是：
所有模型接口配在 AgentGate 里，本地任务随便调。
于是一路长出来：
- DeepSeek 不支持图片，图片请求自动走 KimiCoding。
- 手切模型太烦，多模型在路由里待命。
- 同一家多 Key，429 换下一条。
- ChatGPT 和 Codex 合并，协议又动一刀，网关跟上。
- 问题不好查，做完整输入输出日志（含转换前后）。
- 本机一直在跑，做了个桌宠扫一眼状态。
它不一定复杂。 但它解决了我每天真的会遇到的问题。
合并版刚换的人，如果第三方模型「突然不会用工具」——先别急着骂模型。 有可能是协议被吃了。 可以试试把请求先过一遍本机网关。