OpenAI 自曝家底：Codex 的 Agent Loop 里，Prompt Caching 和 Context Window 到底怎么配？

1. 一次代码生成请求为什么第二次比第一次慢那么多你让 Codex 类工具改一个 README它先cat README.md再ls再读两个源文件最后写回。整个过程你只发了一条消息但模型被调用了五六次。第一次调用很快后面几次越来越慢Token 账单也涨得离谱。这不是模型变笨了而是 Agent Loop 在每一轮都把「从开天辟地以来的所有内容」重新打包发一遍。OpenAI 技术团队拆 Codex 时把这件事说得很直白LLM 是无状态的Agent 的「记忆」是每一轮重新拼出来的假象。一次对话轮Turn里可能包含多次推理和工具调用迭代每次迭代都要把系统指令、工具定义、历史消息、工具输出全部塞进新的 Prompt。Prompt 长度随迭代次数线性增长而发送的 JSON 体积接近二次方增长。这里有两个热词决定了你的成本和延迟Prompt Caching 和 Context Window。前者决定「重复的前缀能不能复用计算结果」后者决定「你还能塞多少东西进去」。Codex 的工程做法是把静态内容instructions、tools放在 Prompt 最前面动态内容用户输入、工具输出追加在最后让旧 Prompt 成为新 Prompt 的精确前缀从而命中缓存。一旦命中采样成本从二次方级降为线性级。这篇文章不聊 AGI 愿景只做一件事在 TaoToken 统一 Key/API 通道下用可复制的config.toml和settings.json让你亲眼看到缓存命中与上下文窗口边界到底长什么样。适合正在用 Codex CLI、Cursor、Windsurf 或自己写 Agent 的人。2. 用 TaoToken 统一 Key 接入 Codex 类 Agent LoopCodex CLI 的 Responses API 端点是可配置的这意味着你可以把它指向任何实现了 Responses API 的通道。TaoToken 提供统一的 Key 和 API 入口你不需要在多个供应商之间来回切换配置一个 Key 就能观察 Agent Loop 的真实行为。先拿到凭证。打开模型对话页面确认通道可用再去控制台创建 API Key。这两个入口分别是模型对话https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewriteAPI 基地址统一用https://taotoken.net/api不要加 UTM 参数。拿到 Key 后先做一次最小连通性验证确认通道正常再往下配 Agent Loopexport TAOTOKEN_API_KEYsk-你的Key curl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ | head -c 500返回模型列表就说明 Key 和通道没问题。接下来所有配置都围绕这个 Key 展开。如果你更想先看接入文档再动手文档入口在这里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite3. 可复制的 config.toml 骨架把静态前缀钉死Codex CLI 读取~/.codex/config.toml。这份骨架的核心思路只有一条所有静态内容放前面且顺序固定所有动态内容追加在后面。顺序一旦抖动缓存就失效。# ~/.codex/config.toml model gpt-5.2-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api/v1 env_key TAOTOKEN_API_KEY wire_api responses # 静态指令文件内容在会话间保持不变 model_instructions_file ~/.codex/instructions.md # 项目文档查找限制大小避免撑爆 Context Window project_doc_max_bytes 32768 project_doc_fallback_filenames [AGENTS.md, CLAUDE.md] # 自动压缩阈值超过就触发 compact auto_compact_limit 120000 [sandbox] mode workspace-write几个参数值得单独说。wire_api responses告诉 Codex 走 Responses API 协议这是缓存前缀匹配的前提。model_instructions_file指向一个固定文件内容不要每次会话都改否则系统消息一变整个前缀缓存全废。project_doc_max_bytes默认 32 KiB从 Git 根目录向上查找AGENTS.md这个值调太大会让初始 Prompt 就很长调太小又可能漏掉关键上下文。auto_compact_limit是上下文窗口的保险丝。Codex 超过阈值会自动调用/responses/compact端点把历史对话替换成一个更小的项目列表其中包含一个typecompaction的不透明encrypted_content保留模型对原始对话的潜在理解。你不需要手动敲/compact了但阈值要设得比模型真实窗口小一截给输出 Token 留空间。instructions.md里放什么放那些永远不变的东西角色定义、代码风格、禁止事项。不要放「今天要改哪个文件」这种动态信息那属于用户消息。4. settings.json 配置片段控制工具枚举顺序如果你用的是 VS Code 扩展或兼容 Codex 协议的客户端工具定义和沙盒配置往往通过settings.json下发。这里最容易踩的坑是工具枚举顺序不一致。OpenAI 明确提过他们早期 MCP 工具实现有个 Bug工具没有按一致顺序枚举直接导致缓存失效。{ codex.tools: [ { name: shell, enabled: true }, { name: update_plan, enabled: true }, { name: web_search, enabled: false } ], codex.mcpServers: { weather: { command: npx, args: [-y, modelcontextprotocol/server-weather], toolOrder: [get-forecast, get-alerts] } }, codex.sandbox: { mode: workspace-write, writableRoots: [/Users/you/project] }, codex.context: { autoCompactLimit: 120000, preserveReasoning: true } }toolOrder这个字段不是官方标准但思路必须贯彻任何动态注册的工具列表都要保证每次请求的枚举顺序完全一致。MCP 服务器可以通过notifications/tools/list_changed动态改工具列表如果在长对话中间响应这个通知就会造成昂贵的缓存失效。稳妥做法是会话中途不要增删工具需要变更就开新会话。preserveReasoning: true对应 Codex 把typereasoning项目连同encrypted_content一起追加到后续input里。这样即使你开了零数据保留模型仍能从前几轮的推理消息中受益因为相关加密内容可以在服务端解密。沙盒配置和批准模式如果中途变了不要修改早先的消息而是追加一条新的roledeveloper消息格式和原始permissions instructions一致。当前工作目录变了就追加一条新的roleuser消息格式和environment_context一致。这是 Codex 保住缓存命中的关键手法。5. 验证缓存命中与上下文窗口边界配置写完怎么知道缓存到底有没有命中最直接的办法是观察两次请求的延迟和 Token 用量差异。第一次请求必然缓存未命中第二次如果前缀完全一致应该明显更快。用下面这个脚本连续发两次请求第二次把第一次的完整input作为前缀只追加一条新用户消息import os, time, json, requests API https://taotoken.net/api/v1/responses KEY os.environ[TAOTOKEN_API_KEY] HEADERS {Authorization: fBearer {KEY}, Content-Type: application/json} base_input [ {type: message, role: user, content: [{type: input_text, text: 读取 README.md 并总结结构}]} ] def call(payload): t0 time.time() r requests.post(API, headersHEADERS, jsonpayload, timeout120) dt time.time() - t0 data r.json() usage data.get(usage, {}) return dt, usage payload1 {model: gpt-5.2-codex, input: base_input} dt1, u1 call(payload1) print(f第一次: {dt1:.2f}s, usage{u1}) # 第二次复用第一次的 input 作为前缀追加新消息 payload2 { model: gpt-5.2-codex, input: base_input [ {type: message, role: assistant, content: [{type: output_text, text: README 包含安装、用法、API 三节。}]}, {type: message, role: user, content: [{type: input_text, text: 把 API 那节展开}]} ] } dt2, u2 call(payload2) print(f第二次: {dt2:.2f}s, usage{u2})看usage里的cached_tokens字段不同实现字段名可能略有差异。如果第二次的cached_tokens明显大于零说明前缀命中了。如果两次延迟差不多、cached_tokens为零检查三件事tools数组顺序是否一致、model是否变了、instructions内容是否被改动。验证上下文窗口边界用一个大文件反复追加观察什么时候触发压缩# 生成一个约 40KB 的测试文件 python3 -c print(line\n * 8000) big_context.txt # 在 Codex 会话里连续让它读取并追加内容 # 观察 auto_compact_limit 触发时的行为当 Token 数逼近auto_compact_limitCodex 会调用/responses/compact返回一个包含typecompaction项目的新列表。你会在日志里看到input被整体替换而不是继续增长。这时候对话还能继续但早期逐字历史已经被压缩成不透明的加密摘要。6. 本篇常见错排查缓存一直不命中。九成是前缀被破坏了。检查tools数组是不是每次请求顺序不同检查model_instructions_file指向的文件是不是被动态改写检查沙盒配置是不是在会话中途被修改而不是追加新消息。Codex 团队专门强调过引入新功能时必须极其小心不要破坏缓存MCP 工具枚举顺序那个 Bug 就是活教材。上下文窗口爆了但没触发压缩。确认auto_compact_limit设得比模型真实窗口小。窗口同时包含输入和输出 Token你只按输入估算就会超。另外确认客户端版本支持/responses/compact端点老版本可能还在用需要手动/compact的实现。第二次请求反而更慢。可能是previous_response_id被启用了。Codex 为了保持请求完全无状态、支持零数据保留刻意不用这个参数。如果你在自定义客户端里开了它服务端行为可能和预期不一致。保持每个请求无状态靠前缀匹配拿缓存收益。工具调用输出把 Prompt 撑爆。shell工具返回一大段日志时整段输出会作为function_call_output追加进input。在config.toml里给 shell 工具设timeout_ms并在 instructions 里要求模型对长输出做摘要后再继续别让原始日志无限堆积。改了工作目录后缓存失效。这是预期行为因为environment_context变了。正确做法是追加一条新的roleuser消息反映新 cwd而不是回头改旧消息。旧消息一改整个前缀就断了。如果你在排障过程中需要重新生成 Key 或核对接入参数直接去 API Keys 页面和接入文档对照https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 和 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite7. 长期跑 Agent Loop把 Key 和额度管起来单次调试用按量 Key 就够了但如果你要让 Codex 类 Agent 长期在项目里跑循环——每天几十上百轮工具调用——按量计费的波动会很难预测。这时候更适合用 Coding Plan 把额度固定下来配合统一的 TaoToken KeyAgent Loop 的每一轮推理都走同一条通道缓存前缀的稳定性也更容易保证。长期编码和 Agent 场景的入口在这里https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite配置层面还有一个小技巧把instructions.md和settings.json一起纳入 Git 管理但不要把 API Key 写进去。Key 走环境变量TAOTOKEN_API_KEY配置文件只引用变量名。这样团队成员拉下代码后各自用自己的 Key而静态前缀内容完全一致缓存命中率在团队维度上也能保持稳定。最后留一个我实测下来最容易被忽略的点auto_compact_limit不要设成模型窗口的 95%。压缩本身也要消耗一次推理而且压缩后的encrypted_content虽然保留了潜在理解但逐字细节会丢。设成 70% 到 80%给工具输出和模型回复留足空间Agent Loop 跑起来会顺很多。