最近 Codex 在群里和社区里又被频繁吐槽无非是“又卡又慢”“半天不出活”。作为一个重度使用者我其实一开始也觉得是网络锅直到自己动手把请求链路拆了一遍才发现问题往往不是单点而是上下文、并发、配置和渲染凑在一起堆出来的。这篇东西就是把我最近的排查和调优过程整理出来给同样被 Codex 卡到头疼的人一个可照做的排查方向。Codex 可以理解为一套基于 Codex CLI 的社区增强封装它保留了原版 CLI 的核心交互同时补了模型路由、并发控制、会话管理、提示词模板等一堆“省事”的功能。但也正因为多了一层封装和一梭子默认参数很多人装上之后直接开用反而把底层的性能短板放大了。这篇文章不打算教你重装一遍而是从“慢在哪”开始逐步拆到配置、习惯和实操最后给你一份能直接抄的调速清单。1. 卡顿之前先定位Codex 的慢到底是慢在哪一步1.1 从按下回车到首字输出拆出三个耗时阶段我习惯把一次 Codex 请求拆成三段本地准备、请求传输、模型生成。很多人一说慢就怪模型其实模型生成往往不是瓶颈前面两段才最容易出鬼。本地准备包括读取历史会话、加载当前目录的文件索引、拼装系统提示词、把用户输入和上下文一起序列化成请求体。这段如果做得重按下回车后你会看到光标先转两三秒才进入“请求中”状态。请求传输是 Codex 把请求体发到模型服务端并等待首字返回的过程。这里涉及 DNS 解析、TLS 握手、数据上行和下行任何一个环节抖动整条链路都会跟着慢。很多“转圈半天才开始出字”的情况都发生在这个阶段。模型生成则是服务端真正开始推理和流式返回文字的过程。如果前面两个阶段都很快但输出本身像挤牙膏一样一字一顿那才轮到怀疑 API 限流、模型负载或者上下文过长导致的推理效率下降。1.2 用时间戳和日志快速区分本地慢还是远端慢Codex 通常会输出详细的日志但默认等级下很多耗时信息被过滤掉了。我推荐先打开调试日志把日志级别调到 debug 或 verbose然后跑一次最简单的提问“你好请回复 OK”再做一次带上下文的真实任务对比两者的日志差异。如果简单提问也慢问题大概率在网络或配置如果简单提问很快但一进项目就慢问题大概率在上下文摄取和文件索引。我一般会同时打开两个终端一个跑 Codex 的交互另一个用tail -f盯日志文件这样每个阶段耗时都能肉眼看到。你还可以在系统里用time命令包裹启动过程或者在 Codex 配置里开启请求耗时统计。起码要能回答“是本地多花了2秒还是远端多花了5秒”不然所有调优都是在猜。我见过有人折腾了大半天配置最后发现是 DNS 解析慢纯属白忙活。2. 导致 Codex 卡顿的五个高频原因2.1 上下文被塞爆模型每轮都要重新读一遍历史Codex 默认会把当前会话的历史消息、系统提示、工具定义和用户输入一起打包发给模型。这个机制保证了对话连续性但代价是每一轮都要重复处理之前所有的 token上下文越长开销越大。我见过最夸张的情况是一个会话里堆了十几个大文件的全文还不时把报错日志整段粘进去最后上下文窗口接近上限。这时候每发一句话Codex 光把请求体序列化就要半天模型端还要把历史全部重新过一遍不慢才怪。更隐蔽的是工具调用记录。Codex 在自动执行代码、读取文件、跑测试时会把中间结果都写进上下文。一次任务可能产生几十条工具消息这些消息都是 token而且往往是没用的大段输出。它们不会显示在对话里但每一轮都被重复计费、重复处理。所以我现在的习惯是一个会话只聊一个具体任务做完就开新会话大段代码优先给路径让 Codex 自己读而不是手动贴进去日志文件如果太长先过滤出关键错误行再提供。这些做法能直接把上下文体积砍掉一半还多。2.2 请求体过大多文件索引、贴大段代码带来的隐性成本很多人喜欢让 Codex “读一下整个项目”它确实会做但代价是项目里的非必要文件也会被塞进请求体。尤其是node_modules、dist、build、.git这类目录如果不做忽略配置Codex 可能花大量时间去扫描、读取和序列化它们。扩容后的请求体不仅让本地序列化变慢还会让网络传输时间成倍增加。本来一个 20ms 能传完的请求变成 200ms大量请求叠加感受就是“敲一下卡一下”。Codex 一般有类似 ignore 文件的机制但很多人根本没配。我建议在一开始就把ignore规则写好把构建产物、依赖目录、缓存目录全部排除掉。同时只把需要关注的文件交给它比如“请阅读src/utils/format.ts然后修改src/pages/index.tsx里的 bug”而不是“你看看这个项目怎么优化”。还要注意终端粘贴的隐藏格式。从网页、PDF 里复制代码时经常会带一堆不可见字符或多余的空白这些内容进入上下文后会占 token还会让序列化后的体积变大。我通常会在粘贴前用编辑器洗一遍格式去掉行号和多余空行。2.3 并发任务互相抢资源本地CPU、内存和 API 限流三重打架Codex 支持同时跑多个会话或并行执行工具任务这本来是好事但开太多会话时CPU 和内存会被多个进程抢占。我曾在同一台 16G 内存的笔记本上同时开四个 Codex 窗口加上编辑器、浏览器和 Docker机器直接进入 swap 状态所有请求都慢成幻灯片。更麻烦的是 API 限流。OpenAI 的接口通常按 RPM每分钟请求数和 TPM每分钟 token 数双重限制。多个 Codex 会话并发时非常容易触发限流而限流往往表现为“请求排队”或“连接被重置”你从界面上看就是转圈更久。所以并发不是越多越好。我一般控制在两个会话以内并且错开大任务的时间。如果要并行跑多个独立任务不如用 Codex 的任务队列功能让系统按顺序调度而不是一股脑全部并发。这样反而整体更快因为避免了限流重试带来的额外延迟。另外本地资源占用可以用系统监控工具看一眼。如果某个 Codex 进程的 CPU 或内存飙高说明它可能在索引文件、加载模型缓存或者跑本地工具这时候再开新会话只会加重负担。先等它跑完再说。2.4 终端渲染和日志输出拖后腿往往被忽略的元凶Codex 支持流式输出模型每生成一个 token 就往终端里打印。这个机制本身没问题但如果终端模拟器性能差或者主题、插件、字体渲染过于复杂大量快速刷新的字符会把终端 UI 线程卡住表现就是“打字慢、滚动卡、输入都跟不上”。我自己踩过这个坑用了某个带背景图、半透明、毛玻璃效果的终端主题Codex 输出稍微一多整个窗口就开始掉帧。换回简洁的主题后流畅度立竿见影。日志也是重灾区。调试模式下日志会非常啰嗦每轮请求打印几百行如果日志还要写同步落盘或滚动切割也会拖慢整体。我建议日常使用把日志级别保持在 info 或 warn只有排查问题时才临时开 debug。还有一个隐藏点是输出内容本身。如果模型连续输出大段代码终端要处理的字符量是很大的。配合自动换行、行号、语法高亮都会增加渲染压力。现在很多终端支持“性能模式”或“关闭硬件加速”的选项可以按需调整。2.5 版本老化与配置冲突缓存、插件、模型路由互相踩脚Codex 迭代很快社区里经常有“升级后突然变卡”的反馈。这种卡往往不是性能退化而是新版本改了默认配置或缓存格式旧缓存没有自动迁移导致每次请求都在重建索引或重复下载模型文件。配置冲突更隐蔽。Codex 支持通过配置文件覆盖模型列表、路由规则、并发数、缓存策略等。但这些配置项之间会相互影响比如你手动设置了很大的并发数却忽略了 API 的限流上限或者你设置了自定义模型别名但别名对应的模型本身更慢结果所有请求都堵在模型端。我一般会做“最小化验证”把 Codex 的配置恢复到默认跑一次任务确认速度和预期相符再逐步开启自定义项。这样能迅速定位是哪一项配置导致的慢。另外Codex 的缓存目录如果长时间不清理会积累大量会话记录、向量索引和临时文件。磁盘 I/O 一高整体响应也会变慢。我建议每隔一两周清理一次无用的会话缓存尤其是那种几十 MB 的历史会话文件。3. 从配置到习惯一套可直接照做的提速方案3.1 给 Codex 瘦身精简上下文和系统提示词第一步是给 Codex 的“系统提示词”做减法。很多人会往系统提示里塞一长串项目规范、角色设定、代码风格要求这些内容每轮都要参与计算越长越慢。我建议只保留最关键的限制比如“不要解释直接输出修改后的代码”“优先使用 TypeScript”这种一句话规则。第二步是控制单个会话的上下文长度。Codex 通常有上下文压缩或截断机制但打开它需要配置。如果没开你就会发现会话越聊越慢。现在很多版本支持自动压缩历史消息把早期的内容摘要化只保留最近几轮完整消息。务必确认这个开关是开启的。第三步是谨慎选择交给 Codex 的文件。不要一次性让它在整个仓库里搜索修改而是先用grep或rg自己定位到相关代码再把它读进来。你花 30 秒做的定位能让 Codex 省掉几十秒的索引和上下文开销。还要注意对话里的“废话”。像“好的”“明白了”“继续”这类确认性消息也会进入上下文。尽量一次把话说完减少来回对话轮数如果需要给代码反馈直接贴修改点不用重发整个文件。3.2 调整并发与缓存参数让请求更轻更稳Codex 的配置文件里通常有并发数、队列长度、缓存大小、超时时间等参数。我推荐的起点是并发数设为 1 或 2超时时间保持默认或稍长一些缓存大小不要调太大以 512MB 为上限。并发数这个指标很反直觉。很多人以为调大并发就能让 Codex 同时干更多活但实际因为 API 限流并发一高单个请求的等待时间反而变长。你需要根据自己账号的限流额度来反推如果每分钟 token 上限是 60k平均每个请求 2k token那并发最多撑到每分钟 30 个请求但这是理论峰值实际最好留一半余量。缓存参数方面Codex 会缓存一些重复的代码块、搜索结果和模型响应。缓存命中能显著减少请求次数但缓存过大也会增加检索和磁盘读取的耗时。我通常把缓存目录放在本地 NVMe 磁盘上而不是机械硬盘如果放在网络盘上那基本等于没有缓存。超时时间也需要权衡。设置太短网络轻微波动就中断重试设置太长一次卡住要等半天。我建议请求超时设为 120 秒流式响应的空闲超时设为 60 秒这样既不会频繁中断也不会无限等下去。3.3 优化终端和日志减少无感等待终端的选择对 Codex 的实际体感影响很大。我比较过几个主流终端在快速滚动输出场景下现代终端比老牌终端更跟手。如果你发现 Codex 输出一大段代码时终端明显卡顿可以试试切换终端的渲染后端从 GPU 模式切到 CPU 模式或者关掉某些炫酷特效。日志方面建议把 Codex 的日志输出指向固定文件并且打开日志轮转避免日志文件无限增长。同时把日志级别在日常使用时调到 warn只记录警告和错误。这样既能保留排查线索又不会让日志写入拖慢主流程。还有一个容易忽略的操作关闭自动检查更新。Codex 如果每次启动或定期去拉取最新版本信息在部分网络环境下会卡几秒甚至更久。我通常把更新检查关了一个月手动检查一次就好。这个选项在配置里叫auto_update或者类似的名字找到就设成 false。Windows 用户还要注意 Windows Defender 或杀毒软件会扫描 Codex 的缓存目录和可执行文件拖慢启动和文件操作。如果信任这个工具可以把相关目录加入排除名单。macOS 用户则需要留意 Spotlight 是否在索引 Codex 的缓存文件夹可以在系统设置里把缓存目录加入隐私排除。3.4 模型路由与 prompt 策略少跑冤枉路Codex 支持配置多个模型并自定义路由规则。我用的策略是“轻活走快模型重活走强模型”简单的文本改写、代码格式化、解释代码走延迟更低的模型复杂重构、多文件改动、架构设计才调用更强的模型。这样可以让简单任务瞬间返回复杂任务慢一点也能接受。默认情况下Codex 可能所有请求都走同一个模型这就等于用跑车拉货既慢又贵。我在配置里给不同任务类型设置了不同的模型别名并配合工具调用做一些自动分流。比如当检测到是纯问答时走更快的小模型当检测到需要跑测试或改文件时走更强的模型。Prompt 策略上我唯一的心得就是“一次说清”。你把需求写得越具体Codex 需要的交互轮次就越少整体耗时也就越少。比如“修一下登录页的 bug”就不如“登录页在输入错误密码时没有提示请找到LoginForm.tsx里的提交逻辑添加错误提示并保证不跳转”来得快。因为后者大幅缩小了检索范围模型不用猜。另外对于常规操作可以做成模板。Codex 通常支持自定义 slash 命令把“代码审查”“生成测试用例”“解释当前文件”这类常用指令固化成模板能减少提示词输入也能让输出更稳定。模板里的指令写得精炼一点不要堆砌形容词。4. 实操记录一次完整排查和调优的过程4.1 第一步抓取耗时分布我拿自己手头的一个中小型前端项目做实战排查。项目大概有 80 个 TypeScript 文件Codex 版本是最新版配置基本都是默认只有模型改成了某个更快的版本。我先开启 debug 级日志清空旧日志文件然后启动 Codex输入“请说明src/api/client.ts的请求拦截器做了什么。”——这是一个纯读文件的简单任务。从日志里我看到了三段耗时构建上下文用了 3.2 秒请求发送到首字节用了 4.1 秒完整流式输出用了 1.5 秒。也就是说用户体感上的 8.8 秒里真正“生成”的时间不到两成本地准备和网络等待占了八成。我又试了一个复杂任务“把services/order.ts里的订单状态判断逻辑重构为状态机。”这次构建上下文耗了 6.8 秒请求发送到首字节用了 6.5 秒输出用了 18 秒。可以明显看到随着上下文变大和输出变长时间几乎线性增长。4.2 第二步清理上下文与缓存我先删掉了 Codex 的缓存目录里两个月以前的历史会话文件释放了大概 1.2GB 空间。然后又检查了项目的 ignore 规则发现里面完全没有排除node_modules和.next导致 Codex 在扫描文件时会读进一堆编译产物。我给 Codex 的配置文件补上了排除列表把node_modules、dist、build、.next、coverage全部加入并删掉了项目根目录下那两个变了形的超大 JSON 数据文件本来是一些仿真数据并不需要让 AI 看。这步做完同一个简单任务从 3.2 秒的上下文构建降到了 0.8 秒。然后我把会话里之前粘贴过的几段大日志剪掉重新开启了一个新会话。这时候简单任务的完整耗时从 8.8 秒降到了 4.5 秒左右其中上下文构建 0.8 秒请求到首字节 3.0 秒输出 0.7 秒。注意请求传输那 3 秒还没动这就说明网络链路是另外一个独立问题。4.3 第三步session 拆分与 checkpoint 使用为了降低长会话的毒性我开始尝试把大任务拆成多个小 session。过去我喜欢一个会话从早用到晚结果到下午随便一个问题都要等十几秒。现在我的做法是每个功能模块开一个会话跨模块的问题重新开新会话并保留关键结论作为文本笔记。Codex 支持会话的保存和恢复但保存的会话文件如果太大恢复时同样会很慢。我给自己定了个规则一个会话里的有效对话轮次超过 40 次或者上下文长度超过窗口的一半就手动开新会话必要时让 Codex 先输出一个总结摘要我再把摘要复制到新会话里当起点。这个习惯一开始很反人性因为总想着“继续聊就行”。但实际使用下来新会话的响应速度几乎和第一次提问一样快那种“越用越慢”的恶心感彻底消失了。它才是这次调优里收益最大的一个改动。4.4 调优后的数据对比我把调优前后的数据整理了一下。同一台机器、同一个项目、同一个模型简单任务的完整耗时从 8.8 秒降到了 4.5 秒左右复杂任务的完整耗时从 31 秒降到了 21 秒左右。其中约一半收益来自上下文瘦身和 ignore 规则另一半来自拆分会话和清理缓存。需要说明的是我并没有调高并发也没有改模型。纯粹的“少拿没用的东西去打扰模型”就能带来肉眼可见的提速。如果你的网络链路本身更差这个对比倍数可能会更夸张。我也不建议一上来就花大把时间搞配置。先把上下文和 ignore 规则做好往往就能解决 80% 的“慢”。剩下的再根据日志里的阶段耗时逐项排查才不会变成玄学调优。5. 常见问题与排查技巧速查表5.1 常见报错/现象与处理方式现象可能原因处理建议按回车后光标转 3 秒以上才出现“请求中”上下文太大或本地文件索引过重精简上下文、配置 ignore 规则、清理缓存发送请求后长时间停在“等待响应”网络链路质量差或请求体过大检查网络耗时、缩小请求体、增加超时重试输出一个字一个字蹦出来模型限流、上下文过长、终端渲染压力大检查 API 余量、拆分会话、换简洁终端主题升级版本后明显变慢缓存未迁移、配置冲突清空缓存、恢复默认配置逐步调开多个会话后机器卡死内存不足、CPU 被占满关掉多余会话、重启 Codex 进程日志文件巨大导致磁盘占满日志轮转未开启设置日志轮转、限制日志文件大小请求包含大量代码时报错请求体超过模型输入上限拆小任务、删除无关文件、用路径代替粘贴5.2 独家避坑清单第一不要把重要任务放在一个长期不关的会话里做。会话就像背包背的东西越多走起来越慢而且中间掺杂的模型回复、工具调用记录占的空间远超你想象。真正省心的做法是“小步快跑”任务做完就开新会话需要用之前的结论就复制摘要而不是把整个历史都拖着走。第二不要在 stdout 里打印无用的调试信息。如果你在代码里临时加了很多console.log或者让 Codex 执行了会产生大量输出的命令这些输出都会成为下一轮请求的上下文。跑完测试或者脚本之后主动让 Codex 忘掉那些输出或者干脆开新会话再继续。第三不要盲目追求“自动读项目”。有时候让 Codex 自动探索项目结构看上去很智能但它会把大量与任务无关的文件读进来既费时又费 token。更高效的方式是你自己用编辑器先看几眼把范围缩小到几个明确的文件路径。这个过程看起来“不自动”但整体时间最少。第四不要在终端里开超长历史记录。终端模拟器的回滚缓冲如果设得太大加上流式输出滚动内存占用会一直涨。Codex 输出内容那么长建议把终端回滚行数限制在 5000 行以内必要时用日志文件保存完整信息而不是靠终端回滚。第五注意网络请求的“首字节时间”。如果你开启 debug 日志后发现大量时间消耗在 TLS 握手或等待首字节那么这属于传输链路问题跟上下文配置无关。这时候调整任何上下文参数都是徒劳应该从链路质量的维度去处理比如检查本机 DNS 配置是否合理、是否触发了限速策略、请求体是否过大。但这些测试最好在低峰时段做不然容易误判。最后再分享一个我个人的小技巧每次改完配置后不要立刻用复杂任务做验证而是先跑一个极小的 sanity check比如“请计算 123*456只输出结果”。如果这个小请求都慢说明是链路或基础配置问题只有小请求很快、大请求慢才说明是上下文和任务复杂度的问题。这个区分方法能帮你省掉无数瞎折腾的时间。我自己从“被 Codex 卡到想卸载”到“正常运行流畅够用”其实没做太多高级操作核心就是上面这些给上下文减负、配置 ignore、拆好会话、该换终端换终端。工具还是那个工具但使用习惯变了体感完全不一样。如果你现在正被卡到崩溃先别急着换工具按这个思路排查一轮大概率会有惊喜。