Codex切推理档会掉缓存命中：多Agent反而更省事

Codex切推理档会掉缓存命中：多Agent反而更省事

今天凌晨，有人问 Tibo：同一个模型只是改了 reasoning level，怎么会把 cache 弄没？Tibo 的回答只有一句：因为这个设置会作为一条指令，放在 context window 的开头。

这种卡顿很容易误判。长线程中途从 high 切到 medium，对话记录还在，旧的 prompt cache 却可能不再命中。后面那一大段历史内容需要重新处理，首次响应时间和输入消耗也可能随之上升。

切一档，为什么前缀就变了

Prompt Caching 看的是 exact prefix，也就是请求开头的 token 序列要一致。稳定的指令、工具定义、schema 和共享上下文放在前面，后续请求才能复用相同的缓存前缀。只要在缓存分界点之前改了一项，这次请求就无法沿用之前的那一段命中。

Codex 当前把 reasoning effort 写进窗口开头的指令。切档后，第一段序列已经不同，后面即使还是同一份项目规则文件、同一次对话和同一批工具，也不能让旧前缀继续算作 exact match。

把两次请求展开，差异会很直观：

[reasoning=high] [系统指令] [工具] [项目规则] [历史对话] [新任务][reasoning=medium] [系统指令] [工具] [项目规则] [历史对话] [新任务]

差别就在开头。人眼会认为后面几项都一样，缓存匹配从第一项就已经分叉。线程越长，项目规则、工具说明、已读文件和对话累积得越多，这次重新处理的输入就越大。为了让下一问快一点而临时切档，有时会先付出一次前缀重算的代价。

短对话里，这次重算可能并不明显。这里的方法主要针对已经积累了大量工具说明、项目规则和历史结果的长线程，不必为了几轮简单问答提前拆任务。

“掉缓存”不等于“丢上下文”。文件、对话和已有结论没有被删掉；变化的是这次输入能不能按缓存价格和缓存路径处理。在能读到 API usage 的工作流里，cached_tokens 突然下降是最直接的信号；Codex 客户端没有展示这个数字时，只能结合切档时点、首次响应和用量变化来判断。

真要测，别把“这次慢了”直接当成证据。工具调用、网络和模型排队都会影响耗时。更稳的对照是保持模型、任务长度和工具集合不变，只在相邻两次请求之间改 reasoning effort，然后看 cached tokens 是否同步下降。没有 usage 明细时，把它当成现象线索，不要给自己算一个看似精确的节省比例。

多代理 v2 给了另一个出口

今天另一条更新刚好能接上这个问题。Multi-agents v2 现在可以把任务交给当前支持的其他模型，包括 Sol、Terra、Luna 和 GPT-5.5。需要快速读日志时，主线程不用从高推理档切出去，可以单独叫一个 Luna 子代理处理；需要更复杂的仓库判断，再给另一个子代理选更合适的模型。

这种分工省的是主线程反复换档、重读大段历史的麻烦，不保证总 token 更少。每个子代理都会独立调用模型和工具，也有自己的输入与输出消耗。并发会花钱。同时启动五个子代理去遍历同一个仓库，很可能比单 Agent 更费。

子代理也不会自动继承主线程的缓存收益。它要建立自己的上下文，主线程传过去多少历史，它就需要读多少。适合拆出去的工作要范围很小，输出也能独立验证。比如查一段失败日志，读两个相关文件，复核一个官方文档页，或者跑一组不改数据的测试。

一项任务如果离不开整段对话、需要反复修改同一批文件，或者关键判断必须连续掌握前面所有取舍，留在主线程往往更合适。强行拆开会让两边都重读材料，还多了一次结果合并。

版本仍有门槛。v2 和可选模型要以当前客户端、账号及已支持列表为准。看不到某个模型时，不要把社交平台的演示当成本账号已经开通。

把工作流改成“稳定主线+小范围分工”

主线程开始时就定好模型和 reasoning effort，长任务中途尽量保持不变。遇到需要另一档速度或判断力的支线，把模型、范围、停止位置和回传格式一起写给子代理。主线程只收结论、证据位置和失败信号，不要把整份日志再倒回来。

主线程该用哪一档，可以按这个任务里最难回退的一步来选。只读查文档、找文件和格式转换很容易重跑；涉及多文件取舍、数据迁移或发布边界时，前面的判断会一直影响后面。从后者出发设定主线档位，把容易重跑的小任务分出去，就不必随着每一问来回改设置。

一条可直接复制的指令可以这样写：

保持主线程当前模型和推理档不变。启动一个 Luna 子代理，只读检查最近一次 Buildkite/GitHub CI：1. 找出第一个真实失败；2. 给出日志位置和复现命令；3. 不改代码；4. 只回传结论、证据和下一步。

这段指令里没有要求子代理“理解整个项目”，它只要找到第一个真实失败。“不改代码”把风险停在诊断阶段，回传字段又把主线程需要重读的内容压到最小。要换成 Terra 或 Sol，也应先保留这个范围，别因为模型更强就把任务重新扩大。

这个 CI 用法也是今天公开出来的实例。Luna 子代理异步标记 Buildkite 和 GitHub CI 的问题，主任务无需停下等它。

跑一次后看三个失败信号。这三类很常见。主线程中途切过推理档，后面第一次请求明显变慢，说明稳定前缀可能已经断了。子代理一上来就重扫整个仓库，说明范围给得太宽。回传内容还有几千行日志，说明它没有完成“只带证据回来”这一步。

长线程先稳住模型和 reasoning effort。需要换档时，把差异放进独立子代理；想压住总消耗，就继续缩小任务范围和回传内容。

打开重置雷达，看 Codex 最新信号