Any请求疑难杂症解决方案（第二期）- 如何针对Any设计体验提升10倍的本地网关

前言：因笔者只使用Any的GPT模型，下文仅涉及Codex。当然，Claude的原理是一样的。
本文亦不涉及指导如何挤上Any，焚香沐浴祈福即可。

本地网关：指在Codex和Any之间部署一个转发器程序。```
发请求：Codex ──> 本地网关 ──> Any
收消息：Any ──> 本地网关 ──> Codex
```引入本地网关，可以解决很多Any的疑难杂症，增强对话的持续性：

1. 获取更详细的错误信息

Codex客户端有时会吞掉上游具体的错误或只返回简略信息。网关可以直接截获原始响应，打印详情方便定位。

2. 捕捉请求内容与思维强度

Any会映射思维强度，当前的规则大致是：```
low -> low
mid/high -> high
xhigh/max -> max
```比如国庆期间经常会出现概率性路由到low（也就是降智）。本地网关可以直接从消息流中解析实际思维强度并打在日志里。

3. 动态更换上游绑定账号

之前的帖子提到过，Any根据会话ID来绑定上游具体账号。当遇到以下问题时，可在网关给请求随机替换一个新的会话ID来强制切号（注：该次请求会是0缓存）：

- 持续性429：Any号池内部分账号被风控标记导致频繁429，换会话ID可能切到正常号缓解；

- 502找不到绑定的资源：原账号绑定的上游Azure资源被删了，换会话ID重新分配新账号。

4. 400报错

因为Any的各个上游渠道、或者你自己的OpenAI订阅之间，会话加密块可能互不兼容。比如你把之前Plus账号聊的会话直接发给Any，上游解不开就会报无法解密的加密块400。

此时网关可以用来剥离这些不兼容的加密块。我的做法是：

网关遇到400且请求类型是 compaction 时，自动重试一次：剔除加密块再做压缩。

判断compaction是因为在本地压缩丢掉脏块，之后的新请求才不会再带上它，避免每次请求都触发剥离而造成持续性0缓存。

5. 图片质量压缩

Any对单次请求体积偏大的请求不太友好。网关可以在上游转发前，对请求中的高清图片进行微损压缩，降低请求大小（当然这也可以靠本地hook实现，思路是一样的）。

6. 掐断并重试僵尸请求

有些请求可能过了4-5分钟都没有首字。让网关来检测，如果一些请求2分钟都没首字就掐断重试。

暂时只想到这些，有兴趣的佬可让AI参考sub2api的一些处理，写一个自己的网关程序，蹬Any的体验会好很多。