榨干Codex周额度：Goal指令与长时Agent配置完全指南

引言：为什么要「榨干」Codex 周额度

很多 Codex 重度用户都遇到过这样的困境：五小时的滚动额度很快见底，而按周计费的额度却迟迟无法充分利用。B站UP主在最新分享中给出了一套完整的解决方案——通过 Goal 指令（go 指令） 让 Agent 持续自动运行，从而在五小时额度耗尽后自动切换消耗周额度。

OpenAI Codex 是基于 GPT 系列模型针对代码生成与理解场景专项优化的模型族，其 Agent 模式本质上是「工具增强型 LLM」的工程实现：模型不仅生成文本，还能调用代码执行器、文件系统读写、Shell 命令等外部工具，形成「感知-决策-行动」的闭环。OpenAI Codex 的计费体系采用分层额度设计：短期滚动额度（通常以五小时为窗口）用于日常高频调用，周额度则作为更大的资源池供重度用户使用。这种双层结构类似于移动数据套餐中「日限流量」与「月总流量」的关系——前者耗尽后系统并不完全停止服务，而是自动切换到更大的储备池。Ultra 模式是 Codex 的最高性能档位，其核心特点是采用多 Agent 并行架构：主 Agent 扮演 Orchestrator 角色，接收任务后将其拆解为有向无环图（DAG）形式的子任务流，分发给并行运行的子 Agent 同时处理，从而大幅提升复杂工程任务的执行速度。代价是每个子 Agent 均需独立的上下文注入，协调层的通信本身也占用额外 token，导致整体 token 消耗量呈指数级增长。

据UP主实测，采用最新的 Ultra 模式配合 Goal 指令后，仅一天就消耗了约 10 亿 token。这个量级远超五小时额度的上限，恰恰说明周额度被真正调动了起来。但要用好这套玩法，前提是必须为长时间 Agent 运行做好充分的项目设置，否则跑得越久、幻觉越多，反而得不偿失。

本文将系统梳理这套方法论：Goal 指令的运行机制、长时 Agent 的五条标准项目设置，以及几个关键的 Codex Skill 用法。

Goal 指令：让 Agent 持续运行的核心机制

运行逻辑

Goal 指令的原理并不复杂。当你用 go 指令启动一个复杂任务（比如项目迁移）后，只要不再进行人为引导干预——也就是不再向它发送新的指令去打断它——Agent 就会单纯按照 Goal 指令设定的方式一路运行下去。

Goal 指令在设计思想上与 AI Agent 领域广泛采用的 ReAct（Reasoning + Acting）框架高度契合。ReAct 框架要求 Agent 在每一步行动前先显式输出推理链（Thought），再执行具体操作（Action），最后观察结果（Observation），形成循环。Goal 指令通过将最终目标持久化并在上下文压缩时重新注入，本质上是为 ReAct 循环提供了一个稳定的「目标锚点」（Goal Anchor），防止 Agent 在多轮推理后发生目标漂移（Goal Drift）。

关键点在于：当五小时额度用完时，Agent 不会主动停下，而是自动开始消耗周额度继续工作。这正是「榨干周额度」的核心逻辑。UP主指出，Ultra 模式尤其「费 token」，因为它会发布大量子 Agent 并行完成任务。

Goal 指令的独特优势

Goal 指令还有一个值得关注的特性：在上下文压缩时，它会把 Goal 指令的完整内容再次发给 Agent，让 Agent 重新明确「我的目标是什么、我做到了哪一步」。这有效缓解了长时间运行后 Agent「忘记初衷」的问题。

大语言模型的上下文窗口（Context Window）是指模型在单次推理中能够「看到」的最大文本长度。当对话或任务日志超出这一上限时，系统必须对历史内容进行压缩或截断，这一过程被称为上下文压缩（Context Compression）。压缩的本质是用更短的摘要替代原始细节，不可避免地会丢失部分信息。对于长时间运行的 Agent 而言，这意味着它对任务初始目标的「记忆」会随着运行时间延长而逐渐模糊——Goal 指令通过在每次压缩时将完整目标重新注入上下文，相当于给 Agent 一个持续刷新的「备忘录」，弥补压缩带来的信息损耗。这与强化学习中的奖励函数设计有异曲同工之处：明确、持续可见的目标信号是保证 Agent 行为收敛的关键。

长时 Agent 的五条标准项目设置

UP主强调，在让 Codex 长期用 Goal 指令运行之前，必须先对项目做好一套标准设置。他将其整理为五条，并开源在自己的 GitHub 仓库中。

1. agents.md：书写偏好与规则

agents.md 是一种偏好文件，用于定义仓库规则、Codex 如何编写代码等。在功能上，它等同于 LLM 应用开发中的 System Prompt（系统提示词），但以文件形式持久化在代码仓库中，实现了「提示词版本管理」。System Prompt 工程是当前 LLM 应用落地的核心工程实践之一：它定义模型的角色、行为约束、输出格式和工具使用规范。例如可以规定：写代码是一个 Agent，写完之后再开一个子 Agent 审核代码细节与准确度。

需要注意的是，这个文件不能写太多，它只承载书写规则和偏好，绝不能把上下文塞进去。这背后有 Token Budget（token 预算）的硬约束——System Prompt 每次推理都会占用固定 token，过长的规则文件会显著压缩任务执行可用的上下文空间，并可能触发模型的「中间遗忘效应」（Lost in the Middle），即模型对超长输入的中间部分关注度显著低于开头和结尾。

2. context.md：稳定的项目上下文

上下文应单独放在 context.md 中，记录当下任务需要主要关注的点，即项目的核心上下文。它同样不宜过长——建议不超过 200 行，否则极难维护。这一限制背后有其技术逻辑：文件越长，每次重新注入的 token 成本越高，同时也越容易被模型在压缩时「选择性遗忘」，反而适得其反。

context.md 与 active-context 的双层记忆设计，在架构思想上借鉴了检索增强生成（Retrieval-Augmented Generation，RAG）与认知科学中长短期记忆的分离原则。context.md 扮演的角色类似于 RAG 中的「精选知识库」——经过人工筛选的高密度项目知识，保证每次注入的信息都是最相关的核心内容；而 active-context 则类似于工作记忆（Working Memory），存储当前任务的即时状态，随任务推进动态更新。两者配合，既保证了长期项目知识的稳定传递，又避免了无关历史信息对当前任务的干扰。

UP主特别解释了背后的原因：Codex 的记忆并非靠聊天窗口维持，因为上下文窗口很快会满并被反复压缩，几轮之后它就记不清最初的对话。此时它可能去翻代码来「猜」目标，但当代码仓库足够大时，它不会遍历整个仓库，只会看 README 或开头几句话，极易产生幻觉。

AI 幻觉是指大语言模型生成与事实不符、逻辑矛盾或凭空捏造内容的现象。其技术根源在于模型的生成机制：LLM 本质上是在预测「下一个最可能的 token」，而非进行真正的逻辑推理或事实检索。当输入信息不足、上下文模糊或任务超出训练分布时，模型倾向于用统计上「听起来合理」的内容填补空白。在长时 Agent 场景中，幻觉风险会随运行时间累积：Agent 对大型代码仓库的覆盖不完整时，它会基于局部文件「推断」全局结构；当上下文被多次压缩后，它可能将错误的摘要当作事实继续推进。因此，稳定的项目主方向必须由人为固定下来，作为长期记忆。

3. active-context：短期记忆

在稳定主方向之外，UP主还额外设计了一个 active 文件，记录当下正在推进的小方向。这相当于给 Codex 配了一个「短期记忆」：主方向是长期大脑，小方向是持续更新、不保留旧内容的短期记忆。当主方向发生变化时，他建议开 worktree 来保证上下文的稳定性。

Git Worktree 是 Git 的一项功能，允许在同一个 Git 仓库中同时检出多个分支到不同的工作目录，而无需克隆多份仓库。对于 AI Agent 的长时运行场景，Worktree 的价值在于上下文隔离：当主方向发生切换时，新建一个 Worktree 意味着 Agent 在一个干净的目录环境中启动，避免了旧任务的文件状态、未提交修改或中间产物对新任务产生干扰。不同 Worktree 对应不同分支，可以通过 Git 历史精确还原 Agent 在某一阶段的工作状态，与状态点 md 的「人类可读快照」形成互补。

4. 状态点 md：给人看的项目快照

长时间运行的 Goal 项目会产生极大的代码量，UP主坦言「睡一觉起来就看不懂它在做什么了」。虽然可以用 set task 查询当下进度，但那只能看到当前状态，无法回溯前面十几二十小时的主要思路和任务节点。

因此他要求 Agent 每完成一个小方向就写一次状态点，形成「给人看的改动记录和状态快照」。这样一来，人类就能随时掌握改动内容和推进速度，提前发现 Agent 悄悄改了什么东西，而不是等问题暴露再去补救。状态点 md 与 Git Worktree 的分支历史形成互补：前者提供人类可读的决策脉络，后者提供机器可追溯的代码快照，共同构成长时 Agent 任务的完整审计链。

5. 局部 Skill（agents skill）

第五条针对局部工作流。Skill 既可以装在全局，也可以针对专属项目安装。对于当前项目会频繁使用的能力，或需要反复纠正的模型缺陷，都可以固化成局部 Skill 供 Agent 查询。

UP主还提供了一个 codex project setting 类的 Skill，能根据现有代码仓库自动构建出上述几个文件，省去手写的麻烦。

构建前必用的关键 Skill

GrowMe：让计划在执行前被充分追问

UP主强调，在真正启动 Goal 指令构建之前，一定要先用 GrowMe。它的价值在于：有些计划表面合理，但隐藏的分析决策没有被问清楚。GrowMe 通过追问的方式，帮你把决策分析捋清楚。

这里有一个关键操作：GrowMe 跑完得出计划后，要明确用文字告诉 Agent「把这样的计划用 go 指令去运行」，这样才能让完整计划真正以 Goal 指令方式运转起来。UP主认为，GrowMe 的追问式规划比 ChatGPT 的 Planning Mode 更实用。

Engineering Decision Review：强制遍历仓库

这是UP主目前所有工程都会安装的 Skill。它解决了 Goal 指令长时间运行的一个常见问题：Agent 经常只读几个文件就开始提出架构或重构建议，仓库覆盖明显不足。这一问题的根源正是幻觉机制——Agent 基于局部信息「推断」全局结构，而非真正理解整个代码库的设计意图。

该 Skill 会明确仓库使用范围，强迫以子 Agent 模式或遍历整个仓库的方式，要求在做架构或重构改变之前先读完仓库，通过扩大信息覆盖面来降低「以偏概全」式幻觉的发生概率，从而做出更合理的方案取舍。这本质上是一种「强制 RAG」策略——在 Agent 被允许输出架构决策之前，先通过工具调用完成对仓库的系统性扫描，用真实的全局信息替代统计推断。

Decision Advisor：多角度理性决策

针对容易停留在模糊阶段的决策，Decision Advisor 会先确定决策背景、目标、选项、地区约束与权重，再通过经济、战略等方法给出可行视角。UP主认为它能从约 6 个角度提供理性分析，帮助做出更可靠的判断。

AI 写作的正确姿势

UP主还分享了一个写作类 Skill，并给出了对 AI 写作的深刻观察。

他明确反对让 AI 一次性生成一万字甚至十万字的长文，因为幻觉会非常严重。AI 写作的通病是「达到局部最优却看不到全局」——单看某一段合理，但从更大层面来看却前后矛盾，甚至在整体写得不错的文章里犯低级错误。

这一现象有其信息论层面的根源：Transformer 架构的注意力机制（Self-Attention）理论上具备全局感知能力，但在实践中，受位置编码方案、训练数据分布和注意力稀疏化优化等因素影响，模型对超长文本中远距离 token 对之间的依赖关系捕捉能力显著下降。近年来的研究（如「Lost in the Middle」论文）实验证明，当关键信息被置于超长上下文的中间位置时，模型的利用率远低于将其置于开头或结尾。这意味着模型在撰写第 80 段时，对第 3 段的「记忆」已经极为稀薄，难以保证前后一致性。模型可能在局部段落内保持逻辑自洽，但在宏观结构层面出现论点漂移、重复或矛盾。

他推荐的做法是：一段一段地写。人先写好思路，再让 AI 补写具体段落，配合能「保留原意、节奏、语气、风格」的 Skill 去修改必要内容。这种分段写作策略本质上是将全局控制权交还给人类，AI 只负责局部润色，从而规避了模型在全局一致性上的先天弱点——每次生成的窗口都被控制在模型注意力有效覆盖范围内。这样生成的内容才具备生产级别的可读性。

总结

这套方法的完整逻辑可以概括为：

• 目标：用 Goal 指令让 Agent 持续运行，在五小时额度耗尽后自动消耗周额度；
• 前提：通过 agents.md、context.md、active-context、状态点、局部 Skill 五条设置，为 Codex 构建稳定的项目记忆；
• 流程：先用 GrowMe 追问理清计划，再明确交给 Goal 指令执行，并用 Engineering Decision Review 避免 Agent 只读几个文件就下结论。

这套设置本质上是在对抗长时 Agent 的两大天敌——上下文遗忘和幻觉。上下文遗忘源于压缩机制对信息的损耗，幻觉源于模型以局部信息推断全局的固有缺陷；而 context.md 的精简设计、Goal 指令的目标重注入（Goal Anchor）、Worktree 的环境隔离以及 Engineering Decision Review 的强制遍历，分别从不同角度针对性地加以应对。这四种机制的组合，恰好覆盖了 ReAct 循环中推理层（目标锚点）、记忆层（精简上下文）、执行层（环境隔离）和感知层（全局信息覆盖）四个维度。对新手而言，它提供了一个可复用的标准起点；对重度用户而言，它是真正把周额度价值最大化的实操路径。UP主表示会长期维护这个开源仓库，并将其扩展到工程之外的「人生决策」场景。

核心要点

核心要点