我们的 Codex 不一样，七个实用技巧让长任务执行表现更佳

分类：Ai 标签：Codex、上下文工程、开发实践

今天分享7 个2026年8月使用 Codex提示词最值得做的优化。

目标很简单：让复杂长任务跑得更稳，同时少浪费 Token。

这套方法不只适用于 Codex。到了 2026年8月，你去看 GPT-5.6、ClaudeFable 5、 DeepSeek V4，会发现几家顶尖模型正在做一件非常相似的事情：一边把 Context Window 做到百万级，一边又想尽办法避免把所有东西都塞进上下文。

以前我们担心上下文不够长，现在真正的问题开始变成：上下文已经足够长了，但里面究竟有多少东西值得模型重新看一遍？

如果你的 Codex 长期挂着很多 MCP、AGENTS.md 越写越长、一个 Thread 用好几天、日志动辄几万行，那么这些优化带来的差距可能非常明显。

一个值得注意的数据

甚至在一些工具密集型场景里，官方已经出现了 80% 级别的优化数据。Anthropic 在 Tool Search 文档中给出的案例里，工具定义原本可以占到约 55K Token，通过按需加载后，Tool Definition Context 可以减少 85% 以上。

如果你不想看中间的原理，只想直接照着改，可以直接拉到文章最后第8章，我放了一份「7 条直接照做版」。

01 缓存与常驻信息：让稳定的 Prefix 可以复用

很多人优化 Token 时，第一反应是删 Prompt。

其实还有一种更重要的思路：不要让那些本来可以复用的 Token 被反复重新计算。

Codex 每轮真正发送给模型的内容，比聊天框里刚输入的那句话多得多。除了当前需求，还可能包含项目级指令、AGENTS.md、Tool Schema、之前的对话和各种运行状态。

这里面有大量内容其实长期不变。

比如项目开发规则、固定工具、工程目录、长期 Prompt 和一些稳定约束。这些内容越稳定，就越有机会利用 Prompt Cache。

Prompt Caching 的一个核心规律就是：公共且稳定的 Prefix 尽量保持不变，把经常变化的内容放在后面。

这已经不是 OpenAI 一家的做法。

Claude 支持 Prompt Caching；Gemini 3 支持 Context Caching；DeepSeek V4 也有针对相同前缀的 Context Cache。虽然各家具体实现不同，但思路高度一致。

对 Codex 用户来说，有几个很实际的注意事项：同一个长期任务中，不要毫无必要地频繁切模型、反复改变工具集合、修改 Sandbox 配置、切换工作目录。因为这些东西本身都可能改变模型看到的 Prefix。

所以一个稳定的 Codex 项目环境，应该更接近：

固定模型

  • 固定项目目录

  • 相对稳定的项目规则

  • 稳定的核心工具

  • 不断变化的具体任务

这里省下来的并不一定表现为“输入 Token 数直接消失”，但可以减少重复计算，并提高缓存复用效率。

这也是第一个很重要认知变化：

不仅只想着删上下文，也要想办法让重复上下文变得可复用。

02 AGENTS.md 只留地图

AGENTS.md 现在已经成了很多 Codex 项目的标配，但我越来越不建议把它写得特别长。

最容易出现的情况是：项目介绍写进去，编码规范写进去，数据库结构写进去，接口约定写进去，Git 规则写进去，部署流程写进去，踩坑记录也写进去。

最后一个 AGENTS.md 几百上千行。

问题在于，这些知识的使用频率其实完全不同。

数据库迁移规范可能一个月只用几次，发布流程可能只有上线时才需要，但如果全部写在长期规则文件里，它们就有可能持续成为 Agent 的常驻背景信息。

OpenAI 在自己的 Harness Engineering 实践里提出过一个非常值得借鉴的原则：

Give Codex a map, not a 1,000-page instruction manual.

给 Codex 一张地图，而不是一本 1000 页的说明书。

更合适的做法，是让 AGENTS.md 主要保存三种东西：

# 项目基础信息
技术栈、关键目录和主要运行方式

# 高频规则
每个任务都必须遵守的开发约束

# 文档索引
- 架构：docs/architecture.md
- 数据库：docs/database.md
- 测试：docs/testing.md
- 发布：docs/release.md

真正需要数据库信息的时候，让 Agent 再去读 database.md；准备发布的时候，再加载 release.md。

这套方法同样不局限于 Codex。

Claude Code 的项目规则、Gemini CLI 的上下文文件，甚至我们自己开发 Agent 时的 System Prompt，本质上都应该遵循类似原则：

高频信息常驻，低频知识按需获取。

Context 足够大，并不意味着所有知识都应该常驻。

这是我认为现在最值得重视的一条。

03 工具管理：MCP 按需加载

很多人刚开始折腾 Agent 时，很容易有一种“工具越多，Agent 越强”的感觉。

GitHub、Browser、Figma、Notion、数据库、搜索、文档、监控平台，再加一堆自己写的 MCP Server，几十个工具全部挂上。

但对模型来说，每增加一个工具，都意味着多了一组选项。

它需要知道工具叫什么、有什么能力、参数如何填写、什么时候应该调用，还要在几十个看起来相似的工具里做选择。

工具本身也属于 Context。

Anthropic 官方文档给过一个非常典型的案例：GitHub、Slack、Sentry、Grafana、Splunk 等一组工具全部加载后，单单 Tool Definitions 就可能占掉约 55K Token。

通过 Tool Search 改成按需发现之后，工具定义占用的 Context 可以减少 85% 以上。

Anthropic 还观察到，当模型长期面对超过 30～50 个工具时，Tool Selection Accuracy 也可能开始下降。

OpenAI 在 GPT-5.6 的 Agent Harness 里同样在做 Deferred Discovery：需要某个 Integration、Skill、Plugin 或 MCP 时，再把相应能力暴露出来，而不是一开始让模型背下所有工具。

所以现在更成熟的 Agent 思路已经从：

我有多少工具？

逐渐变成：

当前这一步，到底需要哪些工具？

对于普通 Codex 用户来说，甚至不需要做复杂的自动 Tool Routing。

先把一个简单原则执行好就够了：

这个项目暂时用不到的 MCP，就不要长期打开。

做纯后端任务，没有必要一直挂着 Figma；当前不操作 GitHub Issue，也没必要让相关工具始终参与每一轮上下文。

MCP 不是插件收藏夹。

如果让我选一个今天就能开始做，而且几乎没有副作用的优化，就是这一条。

04 长文本要自己先过滤，再进入 Context

很多 Token 并不是浪费在 Prompt 上，而是浪费在工具输出上。

比如服务器出现问题，直接让 Codex：

帮我看一下 server.log 为什么报错。

然后 Agent 一次读取几万甚至几十万行日志。

模型最后真正需要的信息，可能只有其中几十行。

更合理的处理流程应该是先搜索：

rg "ERROR|Exception|failed" server.log

确定错误时间和关键词以后，再读取附近一小段：

tail -n 200 server.log

CI、测试和代码搜索都是同样的思路。

测试失败以后，优先给 Agent：

  • 失败测试名称；
  • 错误堆栈；
  • 涉及文件；
  • 关键日志。

不要默认把整个 CI 输出重新读一遍。

代码仓库也一样。先 rg 搜关键函数，先看 git diff，先找到调用关系，再读取真正相关的文件。

可以把这一条浓缩成八个字：

先过滤，再进入 Context。

这其实也是顶尖模型厂商现在共同在做的事情。OpenAI 会限制超大的工具输出，Claude 在 Web Search 和 Tool Calling 中也在不断加入过滤和按需加载能力。

模型并不需要看到原始数据的全部。

它真正需要的是高信息密度的数据。

05 长任务管理：使用 Compact 或阶段压缩上下文

这一条需要稍微讲清楚。

如果使用 Codex，长任务运行到一定程度以后，可以利用它自己的 Context Compaction，把大量历史压缩成继续完成当前任务所需要的状态。

这比无限保留所有原始对话更合理。

但“Compaction”并不是所有模型都使用同一个机制。

Claude 有 Context Editing，可以清理已经失去价值的 Tool Results；不同 Gemini 或 DeepSeek Agent Harness 也可能有自己的上下文管理方式。

所以真正通用的原则不是：

所有模型都应该开启 Compaction。

而是：

长任务不要无限携带完整历史。

假设一个 Debug 已经经历：

方案 A → 失败
方案 B → 修改代码 → 又失败
方案 C → 最终通过

任务已经进入方案 C 之后，方案 A 的几十轮日志和探索过程，通常没有必要永久保持最高优先级。

如果当前 Agent 支持原生 Compaction 或 Context Editing，就让系统处理。

如果没有，可以在一个阶段结束时生成一个 checkpoint：

## 当前状态
已经完成什么

## 最终决策
采用了什么方案

## 关键修改
涉及哪些文件

## 未解决问题
还剩哪些事情

## 下一阶段需要的信息
哪些必须继承

然后基于这个状态继续。

长期 Agent 真正应该继承的是任务状态，而不是每一次失败尝试的完整录像。

06 长任务管理：一个 Thread 对应一个连贯目标

这一条也很容易走向两个极端。

一种极端是，一个 Thread 用一个星期，什么东西都往里面聊。

上午修登录，下午优化数据库，晚上开发首页，第二天又讨论推荐系统。

另一个极端则是，改完一个按钮就开新 Thread。

现在 GPT-5.6、Claude 5、Gemini 3 这些模型的长上下文能力都已经很强，完全没有必要为了节约一点上下文把连续任务拆得支离破碎。

更合理的标准是：

一个 Thread 对应一个连贯目标。

例如：

调查登录 Bug → 找到原因 → 修改代码 → 写测试 → 修复测试失败 → 完成登录问题

这是一个完整目标，可以留在同一个 Thread。

但如果登录功能已经彻底完成，下一件事变成：

重新设计推荐系统架构

这时继续背着登录系统几十轮历史，价值就很有限了。

可以把它理解成：

Repository 保存项目长期记忆，Thread 保存当前工作记忆。

长期知识应该落在代码、文档、测试和 Git 里，而不是永远依赖某一个聊天窗口。

07 推理预算：让强度跟任务难度匹配

最后一个容易浪费资源的地方，是推理强度。

2026 年几个顶尖模型其实已经越来越明确地把“推理深度”做成一个可以调节的资源。

GPT-5.6 支持不同 Reasoning Effort；Claude 有 Effort；Gemini 3 有 Thinking Level。DeepSeek V4 的档位设计和前几家不同，但 Thinking 同样属于一个需要控制的成本来源。

这说明一个趋势：

更强的模型，不代表每一个任务都应该使用最强推理。

例如：

  • 改一处 CSS
  • 修改按钮文字
  • 补一个简单测试
  • 修复已经明确定位的问题

通常不需要和：

  • 排查复杂并发 Bug
  • 重新设计数据库
  • 分析大型跨模块故障

使用相同的推理预算。

对于支持多档 Reasoning 的模型，可以大致按照任务复杂程度分配：

简单明确任务- 低／中等推理

普通开发→ 中等推理

复杂 Debug、架构设计→ 高推理

极难问题- 再考虑最高档

需要注意的是，不同模型的档位名称和具体实现并不相同，所以不要把 GPT-5.6 的 low / medium / high 参数直接套到 DeepSeek 或其他模型。

真正通用的原则只有一个：

让推理预算跟任务难度匹配。

08 总结：7 条直接照做版

如果前面全部跳过了，从这里开始看就够了。

  1. 精简 AGENTS.md。项目级 Context 只保留高频规则和文档入口。详细架构、数据库、部署和业务资料放进 docs/，需要的时候再读取。
  2. 保持长期任务环境稳定。长期项目尽量固定模型、工作目录和核心工具，不要在连续任务里反复改变配置，以利于 Prompt Cache 复用。
  3. MCP 按需打开。做后端就先留后端需要的工具，需要 Figma、Browser、GitHub 时再加。
  4. 先过滤工具输出。搜索 → 缩小范围 → 读取局部 → 再分析。不要默认读取几十万行日志、完整 CI 输出或者整个仓库。
  5. 管理长任务历史。使用相应的上下文管理能力；阶段结束后，必要时留下 checkpoint，只继承当前状态、关键决策和未解决问题。
  6. 按目标拆 Thread。同一问题的调查、修改、测试可以继续放在一起；目标改变时再考虑新开 Thread。
  7. 分配推理预算。小修改不用最高推理，复杂的 Debug、架构和研究任务再增加 Thinking / Reasoning Budget。

把这 7 条压缩成一句话，就是：

稳定缓存、精简常驻信息、按需加载工具、过滤工具输出、管理长上下文、按目标拆线程、按难度分配推理。

我觉得这才是 2026 年使用 Coding Agent 一个非常值得关注的变化。

过去大家不断追求 128K、200K、1M Context，模型厂商也一直在宣传自己能够“装下更多东西”。

但到了百万 Token 已经逐渐成为顶级模型标准配置的时候，竞争方向开始悄悄变化。

OpenAI 在做 Prompt Cache、Deferred Discovery 和 Compaction；Anthropic 在做 Prompt Caching、Tool Search 和 Context Editing；Google 和 DeepSeek 也都已经拥有自己的缓存和上下文优化机制。

大家突然开始努力解决同一个问题：

不是怎么让模型看到更多，而是怎么让模型少看一点没用的东西。

所以我觉得 2025 年大家卷的是 Context Window。

到了 2026 年，真正值得学习的已经开始变成：

Context Management。

上下文有 100 万 Token，并不意味着我们应该想办法把 100 万 Token 塞满。

恰恰相反。

真正成熟的 Agent 工作流，是在真正复杂的问题出现时，能够把这 100 万 Token 留给那些真正值得模型看的东西。

原载：微信公众号「荒岛书生codedoctor」 · 首发：2026-08-20。本文按原稿整理为网页阅读版，保留发表时的产品版本、案例与数据口径。