1. 从“降智”说起：这个插件到底在解决什么问题
如果你最近半年一直在用 codex 做日常开发，大概率遇到过一种很微妙的状态：明明模型没换、网络没断、账号也没欠费，但它的回答质量就是肉眼可见地往下掉。以前能一次跑通的复杂重构，现在要来回改三四轮；以前能准确理解上下文里的变量命名习惯，现在开始胡编函数名；以前写测试用例会主动覆盖边界条件，现在只给你一个 happy path 就交差。圈子里管这个叫“降智”，虽然不严谨，但描述得挺传神。
我一开始也以为是自己的错觉，直到连续几天记录同一类任务的输出质量，才发现这不是心理作用。同一段代码、同一个提示词、同一个模型标识，在不同时间段的响应质量确实存在明显波动。后来跟几个同样重度使用 codex 的朋友交流，大家都有类似体感，于是我开始认真研究这件事的成因，也就有了今天要聊的这个“防降智插件”。
先把这个插件的定位说清楚：它不是一个官方功能，也不是什么黑科技外挂，而是一层夹在 codex 客户端和模型服务之间的请求预处理与上下文管理中间件。核心思路是通过规范请求结构、稳定上下文注入、减少无效 token 干扰，让模型在长会话中尽量保持初始的推理水平。实测下来，在连续两小时以上的编码会话里，它的效果最明显——原本到后半程就开始“摆烂”的 codex，能维持住前半小时的响应质量。
这篇文章适合三类人看：一是每天用 codex 写代码超过一小时的重度用户；二是被“codex 正在重新连接”“codex 一直在 reconnecting”这类问题折磨过的人；三是想搞清楚 codex 请求链路到底怎么回事、愿意动手调配置的折腾型选手。如果你只是偶尔问两句代码，那这个插件对你的收益可能没那么大，但了解背后的原理也没坏处。
需要提前说明的是，下面涉及的所有配置和操作，都是基于我自己的实测环境和常见社区实践总结出来的，不同版本、不同接入方式下细节可能有差异，你照着做的时候要结合自己的实际情况调整。另外，文中提到的模型名称、接口路径等，都以你当前使用的版本为准，我不做任何版本绑定承诺。
2. 降智现象的成因拆解与插件设计思路
2.1 为什么 codex 会“越用越笨”
要理解插件为什么有用，得先搞清楚降智是怎么发生的。我把观察到的原因归为四类，按影响程度从高到低排列。
第一类是上下文污染。codex 在长会话里会不断累积历史消息，包括你的提问、它的回答、工具调用结果、报错信息等等。这些内容里有很多是临时性的、一次性的，比如某次编译失败的堆栈、某个已经废弃的变量名、某段被推翻的方案讨论。但模型并不知道哪些该忘、哪些该记，它会把所有历史都当成同等重要的上下文来处理。结果就是，真正关键的约束被淹没在大量噪声里，模型开始抓不住重点。
第二类是请求结构不稳定。codex 的请求体里有很多字段，比如 system prompt、tools 定义、response format、temperature 等。不同客户端版本、不同接入方式下，这些字段的组织方式可能不一样。有些第三方中转或本地代理在转发请求时，会无意中改变字段顺序、丢失部分元数据、或者注入额外的默认值。模型服务端拿到一个结构不稳定的请求，输出质量自然也会波动。
第三类是会话状态漂移。codex 支持多轮对话，但“多轮”的边界在哪里、哪些内容应该被压缩、哪些应该被保留，不同实现差异很大。我遇到过一种情况：会话进行到一定轮数后，客户端会自动做一次上下文压缩，把前面的历史总结成一段简短描述。如果这个总结做得不好，关键信息就丢了，模型相当于被“重置”了一部分记忆，表现自然下降。
第四类是网络与重试干扰。这个跟“codex 网络连接不上”“codex 正在重新连接”是同一类问题。当请求超时或失败时，客户端会重试。如果重试逻辑不严谨，可能会把同一个请求发多次，或者把失败请求的部分内容混入下一次请求。模型收到这种“脏”请求，输出质量也会受影响。
2.2 插件的核心设计：做减法而不是做加法
市面上有些工具的思路是“给模型更多信息”，比如自动检索代码库、注入项目文档、附加历史提交记录。这个方向不能说错，但在降智这个问题上，做减法比做加法更有效。因为降智的本质是信息过载和结构混乱，你再往里塞东西，只会让情况更糟。
这个防降智插件的设计思路就三条：
- 请求规范化：在请求发出前，对请求体做一次标准化处理，确保字段顺序、必填项、默认值都符合模型服务端的预期。这一步解决的是“结构不稳定”问题。
- 上下文瘦身：对历史消息做选择性保留，把工具调用结果、报错堆栈、重复的代码片段等低信息密度内容压缩或移除，只保留对当前任务有约束力的关键信息。这一步解决的是“上下文污染”问题。
- 会话锚点注入：在每次请求的 system 或 developer 消息里，注入一段简短的“会话锚点”，重申当前任务的核心目标、关键约束和已确认的决策。这一步解决的是“会话状态漂移”问题。
这三条加起来，本质上是在帮模型“聚焦”。模型不是变聪明了，而是被干扰得少了，所以能发挥出它本来的水平。
2.3 为什么选择中间件形态而不是改客户端
有人可能会问：为什么不直接改 codex 客户端，而要做一个中间件？原因很实际。
codex 客户端更新频繁，直接改客户端的话，每次更新你都得重新适配，维护成本极高。而且不同平台的客户端（Windows 桌面版、VS Code 插件、CLI）实现不一样，你要改就得改好几套。中间件形态的好处是解耦：它只关心请求和响应，不关心客户端怎么实现。只要你的客户端支持自定义接口地址，就能把中间件挂上去。
另一个原因是可观测性。中间件可以记录每个请求的原始结构、处理后结构、响应耗时、token 消耗等指标。这些数据对于排查“codex 无法加载组织设置”“codex 登录不上”这类问题非常有帮助，因为你能清楚看到请求到底发出去没有、发出去了什么、服务端回了什么。
当然，中间件也有代价：多一层转发，理论上会增加一点延迟。但实测下来，在本地或局域网内部署时，这个延迟通常在几十毫秒级别，对编码体验的影响可以忽略。相比它带来的质量稳定性，这点代价完全值得。
3. 核心细节解析与实操要点
3.1 请求规范化：字段顺序和默认值为什么重要
先讲一个很多人不知道的细节：模型服务端对请求体的解析，并不是完全“顺序无关”的。虽然 JSON 标准里对象字段是无序的，但实际实现中，某些服务端会按字段出现的顺序做流式解析，先遇到的字段先处理。如果model字段出现在messages之后，服务端可能已经用默认模型初始化了推理上下文，再读到model字段时只能做一次“切换”，这个切换过程可能带来微小的状态不一致。
这不是玄学，我在对比测试中确实观察到：把model、temperature、max_tokens这些关键字段前置后，同一提示词的输出稳定性有所提升。提升幅度不大，但在长会话里会累积。
插件的规范化逻辑大致是这样的：
{ "model": "当前使用的模型标识", "temperature": 0.2, "max_tokens": 4096, "stream": true, "messages": [], "tools": [], "tool_choice": "auto" }关键点在于：必填字段一个不少，可选字段按需保留，顺序固定。temperature我建议设低一点，0.1 到 0.3 之间，因为编码任务需要的是确定性，不是创造性。max_tokens不要设太大，4096 到 8192 足够，设太大反而会让模型倾向于“凑字数”。
注意：不同接入方式下，字段名可能有差异。比如有些中转用
max_output_tokens而不是max_tokens，有些用input而不是messages。你要根据自己实际使用的接口文档来调整，不要照搬。
3.2 上下文瘦身：哪些该留，哪些该扔
上下文瘦身是插件里最核心也最需要谨慎处理的部分。扔多了，模型丢失关键信息；扔少了，等于没瘦身。我经过多次调整，总结出一套保留优先级：
| 优先级 | 内容类型 | 处理方式 |
|---|---|---|
| P0 | 当前任务的目标描述 | 完整保留，并在锚点中重申 |
| P0 | 已确认的关键约束（如“必须用 TypeScript”“不能引入新依赖”） | 完整保留 |
| P1 | 最近 3 轮的用户提问和模型回答 | 完整保留 |
| P1 | 当前打开文件的路径和关键代码片段 | 保留摘要，移除完整内容 |
| P2 | 工具调用结果（如文件读取、搜索） | 只保留结论，移除原始输出 |
| P2 | 报错堆栈 | 只保留错误类型和关键行，移除完整堆栈 |
| P3 | 超过 3 轮的历史对话 | 压缩成一句话摘要 |
| P3 | 重复的代码片段 | 只保留最后一次出现的版本 |
这套规则不是死的。比如你在做一个大型重构，历史决策很重要，那 P3 里的历史对话就不能压得太狠。插件里我留了一个配置项，可以按会话类型切换瘦身策略：refactor模式保留更多历史，debug模式保留更多报错信息，feature模式保留更多需求描述。
实操中有一个坑要特别注意：不要移除 system 消息。有些瘦身逻辑会把 system 消息也当成普通历史来处理，这是大忌。system 消息里通常包含工具定义、输出格式要求、安全约束等，移除后模型行为会完全失控。插件里对 system 消息是强制保留的，只允许在锚点注入时追加内容，不允许删除或修改原有内容。
3.3 会话锚点：给模型一个“定心丸”
会话锚点的作用，是在每次请求时给模型一个简短的提醒，告诉它“我们现在在干什么、已经决定了什么、不要跑偏”。锚点内容不宜长，控制在 200 到 400 token 之间，太长了反而占上下文。
一个典型的锚点长这样：
[会话锚点] 当前任务：重构 user-service 模块的鉴权逻辑 关键约束： - 使用现有 JWT 方案，不引入新库 - 保持现有 API 签名不变 - 所有改动必须有对应单元测试 已确认决策： - 鉴权中间件拆分为独立文件 - 错误码沿用现有枚举，不新增 当前进度：已完成 token 解析部分，正在处理刷新逻辑这段内容会在每次请求时注入到 system 消息末尾。模型看到这个，就不容易在长会话中“忘记”之前的决策。我实测下来，加了锚点之后，模型在 20 轮以上的会话里出现“前后矛盾”的概率明显降低。
锚点的生成方式有两种：一种是手动维护，你在开始任务时写一段，后续手动更新；另一种是自动生成，插件从历史消息里提取关键信息，自动拼装。我建议混合使用：任务目标和关键约束手动写，进度和已确认决策自动提取。因为自动提取有时候会漏掉一些你心里清楚但没明确说出来的约束。
3.4 与 Responses API 的兼容处理
现在很多 codex 接入方式走的是 Responses API 而不是传统的 Chat Completions API。这两者在请求结构上有差异：Responses API 用input而不是messages，用instructions而不是system，工具调用的返回格式也不一样。插件需要同时兼容两种格式，否则你换个接入方式就失效了。
兼容逻辑不复杂，核心是做一层格式转换：
def normalize_request(raw): if "input" in raw: # Responses API 格式 messages = convert_input_to_messages(raw["input"]) system = raw.get("instructions", "") else: # Chat Completions 格式 messages = raw.get("messages", []) system = extract_system(messages) # 统一处理后，再按原格式转回去 ...这里有个细节：Responses API 的input可以是字符串，也可以是消息数组。如果是字符串，转换时要包一层成 user 消息。如果是数组，要注意里面可能混有function_call和function_call_output类型的条目，这些不能简单当成普通消息处理。
提示：如果你用的是第三方中转，它可能对 Responses API 的支持不完整。我遇到过中转把
instructions字段直接丢掉的情况，导致 system 消息完全失效。排查方法很简单：在插件里打印处理后的请求体，看看instructions或system还在不在。
4. 完整实操流程：从零把插件跑起来
4.1 环境准备与依赖安装
先说环境要求。插件本身是一个轻量级的本地服务，用 Python 或 Node.js 都能写。我选 Python，因为处理 JSON 和做文本压缩更方便。你需要：
- Python 3.10 或以上
- pip 包管理工具
- 一个能正常访问模型服务的 codex 客户端
依赖不多，核心就几个：
pip install fastapi uvicorn httpx tiktokenfastapi和uvicorn用来起本地服务，httpx用来转发请求，tiktoken用来算 token 数。如果你不想装 tiktoken，也可以用简单的字符数估算，但精度会差一些。
安装完之后，建一个项目目录，结构大概这样：
codex-guard/ ├── main.py # 服务入口 ├── normalizer.py # 请求规范化 ├── compressor.py # 上下文瘦身 ├── anchor.py # 锚点生成 └── config.yaml # 配置文件4.2 配置文件怎么写
配置文件是整个插件的行为中枢。我把自己用的配置贴出来，你可以直接抄，然后按需改：
server: host: "127.0.0.1" port: 8787 upstream: "你的模型服务地址" normalize: enabled: true field_order: ["model", "temperature", "max_tokens", "stream", "messages", "tools"] default_temperature: 0.2 default_max_tokens: 4096 compress: enabled: true keep_recent_rounds: 3 max_history_tokens: 8000 strategy: "auto" # auto / refactor / debug / feature anchor: enabled: true max_tokens: 400 auto_extract: true manual_anchor: "" logging: level: "info" log_requests: true log_dir: "./logs"几个关键参数解释一下。upstream填你实际用的模型服务地址，如果你用的是官方接口就填官方地址，如果用中转就填中转地址。keep_recent_rounds控制保留最近几轮完整对话，我设 3 是因为再多了上下文会膨胀，再少了模型容易丢上下文。max_history_tokens是瘦身后的历史 token 上限，超过这个值就继续压缩。
strategy设为auto时，插件会根据当前任务的关键词自动判断模式。比如检测到“重构”“refactor”就切到 refactor 模式，检测到“报错”“error”就切到 debug 模式。这个判断逻辑不复杂，就是关键词匹配，但实测挺准的。
4.3 启动服务并接入 codex
配置写好后，启动服务：
uvicorn main:app --host 127.0.0.1 --port 8787看到Uvicorn running on http://127.0.0.1:8787就说明起来了。然后去 codex 客户端里改接口地址。不同客户端改法不一样：
- VS Code 插件：在设置里找
codex.baseUrl或类似的配置项，改成http://127.0.0.1:8787 - CLI：在配置文件里找
api_base或base_url，改成同样的地址 - Windows 桌面版：一般在设置的高级选项里，找“自定义接口地址”
改完之后重启客户端，发一条测试消息。如果插件日志里能看到请求进来，说明接入成功。
注意：有些客户端会校验接口地址的协议和域名，
127.0.0.1有时候不被接受，可以试试localhost。如果还是不行，检查客户端是不是强制走了 HTTPS，是的话你需要在插件前面加一层本地 TLS 终止，或者用支持 HTTP 的客户端版本。
4.4 验证插件是否生效
怎么判断插件真的在起作用？我一般看三个指标：
第一，日志里的请求体结构。如果model字段排在messages前面，说明规范化生效了。如果历史消息数量明显少于你实际对话轮数，说明瘦身生效了。
第二，长会话质量。开一个连续对话，做 15 轮以上的编码任务，观察模型在后半程是否还会出现前后矛盾、忘记约束的情况。如果明显改善，说明锚点起作用了。
第三，token 消耗。插件日志里会记录每次请求的 token 数。对比开启前后的数据，如果平均 token 数下降但输出质量没降，说明瘦身策略是有效的。
我自己的实测数据是：在一个 25 轮的 TypeScript 重构会话里，开启插件前平均每轮请求 6200 token，开启后降到 4100 token，降幅约 34%。输出质量方面，开启前第 18 轮开始出现变量名不一致，开启后到第 25 轮仍然保持一致。
5. 常见问题与排查技巧实录
5.1 插件启动报错怎么办
最常见的启动报错是端口被占用。8787这个端口不算常用，但如果你之前跑过其他本地服务，可能会冲突。解决方法很简单，改配置里的port，换成8788或9090都行。
另一个常见问题是httpx转发时超时。默认超时是 5 秒，对于长响应来说不够。在main.py里把超时调大：
client = httpx.AsyncClient(timeout=httpx.Timeout(120.0, connect=10.0))如果报错说tiktoken找不到编码文件，那是因为它需要下载编码表。第一次运行时会自动下载，如果网络不通就手动下载放到缓存目录。这个编码表不大，几百 KB。
5.2 接入后 codex 连不上或一直重连
这个问题跟“codex 网络连接不上”“codex 一直在 reconnecting”是同一类。排查顺序如下：
- 确认插件服务在跑：浏览器访问
http://127.0.0.1:8787/health，看有没有返回 OK。 - 确认客户端地址改对了：有些客户端改完不生效，需要重启。VS Code 插件有时候要重载窗口。
- 确认 upstream 地址可达：在插件日志里看转发请求有没有发出去、有没有收到响应。如果转发失败，问题在 upstream 地址或网络。
- 确认没有协议冲突：客户端要求 HTTPS 但插件是 HTTP，或者反过来。看客户端日志里的具体报错。
我踩过的一个坑是：客户端在请求头里带了Accept-Encoding: gzip，但插件转发时没有正确处理压缩响应，导致客户端收到乱码。解决方法是在转发时把Accept-Encoding去掉，或者加上解压逻辑。
5.3 瘦身过度导致模型丢失上下文
这是最需要小心的问题。如果你发现模型开始问一些“之前已经说过”的问题，或者重复已经否决的方案，说明瘦身太狠了。调整方法：
- 把
keep_recent_rounds从 3 调到 5 - 把
max_history_tokens从 8000 调到 12000 - 检查锚点里有没有漏掉关键约束
我建议每次调整只改一个参数，观察一两轮会话再决定下一步。一次性改太多，你分不清是哪个参数起的作用。
5.4 常见问题速查表
| 现象 | 可能原因 | 排查方法 | 解决方式 |
|---|---|---|---|
| 插件启动失败 | 端口占用 | 看报错信息 | 换端口 |
| 客户端连不上 | 地址没改对 | 看客户端日志 | 重启客户端，确认地址 |
| 转发超时 | 超时设置太短 | 看插件日志 | 调大 httpx 超时 |
| 响应乱码 | 压缩未处理 | 看响应头 | 去掉 Accept-Encoding |
| 模型丢上下文 | 瘦身过度 | 看请求体历史长度 | 调大保留轮数 |
| 模型前后矛盾 | 锚点缺失 | 看 system 消息 | 开启锚点注入 |
| token 没降 | 瘦身未生效 | 看日志 token 数 | 检查 compress.enabled |
| 工具调用失败 | 工具定义被改 | 看 tools 字段 | 确保 tools 原样保留 |
5.5 几个我踩过的坑
第一个坑：不要对 tools 字段做任何修改。我一开始想“优化”工具定义，把描述改短一点省 token，结果模型开始乱调工具，参数格式也不对了。工具定义是模型理解工具用途的唯一依据，改一个字都可能出问题。插件里对 tools 是原样透传的。
第二个坑：锚点不要写得太具体。我一开始把锚点写得像任务清单，列了十几条，结果模型变得很死板，只按清单走，遇到清单外的情况就卡住。后来改成只写目标和约束，给模型留出推理空间，效果好很多。
第三个坑：日志不要记完整请求体。一开始我为了排查方便，把完整请求体都写进日志，结果日志文件一天就涨到几百 MB，里面全是代码和对话内容。后来改成只记结构摘要和 token 数，需要详细排查时再临时开启完整日志。
第四个坑：不要同时开多个中间件。我试过在插件前面再挂一个请求记录工具，结果两个中间件互相干扰，请求结构被改了两次，模型输出完全乱套。中间件这东西，一层就够了，多了反而坏事。
6. 关于效果边界和后续折腾方向
说了这么多，得客观讲一下这个插件的效果边界。它不是万能的，不能把一个小模型变成大模型，也不能解决服务端本身的容量问题。如果你的降智是因为服务端在高峰期做了降级处理，那插件帮不了你，你只能错峰使用或者换时间段。
它真正能解决的，是客户端侧可控因素导致的降智：上下文污染、请求结构混乱、会话状态漂移。这三类问题在实际使用中占比很高，所以插件的收益才明显。我自己的体感是，开启插件后，长会话的“有效工作时间”大概延长了一倍左右。以前连续用 40 分钟就开始明显感觉模型变笨，现在能撑到一个半小时。
后续我还在折腾几个方向。一个是按任务类型自动切换瘦身策略，现在虽然有了 auto 模式，但判断逻辑还比较粗糙，我想引入更细的分类。另一个是锚点的自动更新，现在锚点里的进度部分还是半自动的，我想让它根据工具调用结果自动更新，减少手动维护。还有一个是多会话隔离，现在插件是全局的，如果你同时开多个 codex 会话，上下文可能会串，这个需要做会话 ID 识别和隔离。
如果你也在用类似方案，或者有更好的思路，欢迎交流。这东西没有标准答案，每个人的使用习惯和接入方式都不一样，多试多调才是正道。我最后再分享一个小技巧：每次调整配置后，用同一个测试任务跑一遍，记录输出质量和 token 数，这样你才能客观判断改动是正向还是负向。凭感觉调参，很容易越调越乱。
