从 Compaction 到 Token Budget：Codex 如何接住一个越来越长的任务

让 Codex 修改一个小文件，通常不会遇到明显的“记忆”问题。任务如果变成升级一个项目，情况就不同了。它要阅读代码、修改配置、运行测试、排查报错，中途还可能调用子 Agent。几个小时以后，结果取决于一组更实际的问题：它是否还知道目标是什么、改过哪些文件、哪条路已经失败、旧证据去哪里找，以及剩下的资源够不够完成验证和收尾。

Codex 最近公开了一组面向长任务的新能力。可以把 Goal 看成持续有效的任务单，Token Budget 看成资源额度，Notes 是交接单，History 是历史档案，new_context 则负责换一个新的工作台。其中，token-budget context、History Notes 和 new_context 属于同一项仍在实验中的上下文管理能力。本文再把它们与 Goal、Rollout Budget 放在一起观察，用来解释一种可能的长任务工作方式；并非所有会话都会自动照此运行。

一、Compaction 有什么局限？

Compaction 的问题不能只用“压缩后可能丢信息”概括。长任务要保留的内容很多：用户最初的要求、后来增加的限制、已经做出的决定、被否决的方案、工具返回的数字，以及当前工作停在什么地方。这些信息的重要性还会变化。一条当时看起来普通的要求，到了验收阶段可能变成决定结果是否合格的关键条件。

例如，用户在任务开始时说“可以调整登录模块，但不要动支付流程”。前半句会频繁参与后续修改，后半句可能很久都用不上。等到 Agent 为修复测试准备修改支付代码时，这条沉在早期对话里的限制才突然变得关键。

压缩仍然需要取舍。任务主线通常比较醒目，容易被保留；某个文件路径、一次报错中的具体数字、用户说过的“不要修改这一部分”，就更容易在概括中被弱化。如果任务经过多次压缩，后一次面对的又可能是已经整理过的内容。早期被省略的细节不会自动回来，原先不够准确的概括也可能继续传下去。

短任务、按顺序推进的任务，通常只要保住主线就能继续。工具调用很多、分支很多的长任务，对细节的要求更高。用户如果要求 Codex 找出三十轮之前的某次报错，或者重新检查一个早已被否决的方案，模型需要那条具体记录，只知道“之前排查过这个问题”的大意还不够。这里讨论的是任务变复杂后更容易出现的风险，不代表每次 Compaction 都会导致失败。

出错后不容易追查，是另一个限制。以 OpenAI API 的压缩结果为例，它主要供后续模型继续使用，人无法像检查任务清单那样逐项查看。任务后来走偏时，团队很难直接判断是模型理解错了、工具执行错了，还是某个早期条件没有被保留下来。普通背景信息遗漏，可能只会让回答不够完整；授权范围、安全要求或验收标准缺失，就可能带来更严重的结果。

长任务留下的“现场”还包括工具之间的调用关系、用户是否授权、图片、文件标识、子任务状态和安全检查结果。Codex 的更新日志曾经专门修复过压缩前后保留安全证据和图片状态的问题。这至少说明，聊天文字之外，还有一组信息需要单独设计保存和恢复方式。

保存信息的同时，系统还要安排剩余资源：整项任务还剩多少额度，搜索和修改可以花多少，测试与收尾至少要留多少，什么时候应停止查找并开始交付。历史能够变短，不代表这些资源已经安排合理。问题由此从“保存什么”走向了“资源怎样分配”。

二、Token Budget 管理的究竟是什么？

可以把 Context Window 理解为模型眼前的工作台。工作台有多大，决定它此刻能摊开多少消息、代码和工具结果。Token Budget 更像任务的资源额度，它关心这项工作准备投入多少 token、已经用了多少，以及资源减少到什么程度时需要提醒、交接或收尾。前者解决“当前能放多少”，后者解决“整项工作准备花多少”。这里所说的 Budget 与账户额度和 API 账单不是一回事。

公开材料里的 Budget 出现在三个范围：当前工作窗口、一次连续执行和整个长期目标。为了方便理解，可以把它们叫作 Context、Rollout 和 Goal 三种口径。这只是本文的整理方式，不是 OpenAI 正式发布的三层架构名称。

Context 口径关注当前工作窗口什么时候需要交接。实验模式同时提供 Notes、可搜索 History 和 new_context，让 Agent 可以留下交接单、换到新的窗口，再按需查询旧记录。它和“模型一次最多能看到多少内容”不是一回事；公开资料也没有规定达到某个统一数值后，一定会自动写 Notes 或切换窗口。

Rollout 可以理解为 Agent 连续工作的一轮。系统会记录这轮共用了多少 token，还可以让“读入材料”和“生成内容”按不同权重计入额度，并在额度下降时提醒 Agent 调整节奏。提醒不等于硬性停止，不同环境达到上限后的处理方式可能不同。

Goal 口径像整项任务的总账。只要还是同一个未完成目标，多轮执行的用量就会继续累计，子 Agent 花掉的 token 也会记到总 Goal 名下。把工作拆给多个 Agent 可以更快并行推进，却不会增加一份免费的额度。它回答的是“整个任务已经用了多少资源”，不是“眼前工作台还放不放得下”。

放到代码迁移里会更直观。Context 口径关心当前窗口还能否继续放下代码和测试结果；Rollout 口径记录这一轮阅读、修改和生成消耗了多少；Goal 口径则关注整个迁移任务已经投入多少，其中也包括子 Agent 的工作。三种口径观察的是同一项任务在不同范围内的资源使用，不能互相替代。

三种口径分别回答三个问题：当前窗口什么时候需要交接，这一轮执行花了多少，整个目标已经投入多少资源。它们负责资源记账，不能代替任务单和历史档案。Codex 要跨 Context 继续工作，还需要 Goal、Notes、History 和 new_context 接力。

三、Token Budget 的架构是怎么运转的？

把这些元素放进一次任务的执行过程里，关系会更清楚。下面沿着任务从建立、执行到换出新窗口的过程展开。

假设 Goal 是“把项目升级到新版本，并让全部测试通过”。后面的工作可能跨过多个窗口，但这张任务单始终负责说明要做到什么；变化的是模型每一阶段摆在工作台上的材料。

任务开始时，Goal 先保存要完成什么，以及什么状态才算完成。只要 Goal 还没有结束，它的目标状态、预算和已用量就可以继续保留。用户的新消息能够影响当前工作；如果任务目标本身发生变化，更稳妥的做法是明确更新 Goal，避免新要求只停留在某一轮对话里。

Agent 真正工作时，面对的是 Active Context，也就是当前工作台。这里放着它眼前需要处理的消息、文件内容和工具结果。预算系统在旁边记录资源消耗，但不会替工作台保存内容。公开材料还显示，子 Agent 的消耗会进入根 Goal 的预算，因此多人并行式的 Agent 协作仍然受到总资源约束。

当这张工作台不适合继续承载后面的工作时，Agent 可以把需要带走的状态写进 Notes。这份交接单不必抄下所有聊天，更重要的是说明已经做了什么、哪些方案失败了、当前卡在哪里、重要结果放在哪里，以及下一步准备做什么。Notes 越接近一份可直接接手的工作说明，新窗口恢复任务时需要重新猜测的内容就越少。

没有写进 Notes 的细节，也不一定要全部丢掉。History 提供历史记录的搜索入口。新窗口需要核对用户原话、旧报错或某次工具结果时，可以回到档案库中寻找对应内容。这样，Notes 负责快速接续当前进度，History 负责需要时回查细节，Active Context 只保留眼前真正要处理的信息。

交接准备好后，Agent 可以调用 new_context 开启新窗口。当前开源实现显示，这条路径会直接建立新窗口，不再为整段会话生成一份新的历史摘要。进入新窗口后，Agent 可以读取 Notes 接上进度，需要具体证据时再查询 History。

假设 Codex 正在做一次代码迁移。切换窗口前，Notes 可以记录已经改过的文件、仍未通过的测试、已经排除的方案和下一步。进入新窗口后，Agent 先根据这份交接单继续；如果要确认某个旧错误的完整堆栈，再去 History 中查找。新窗口不必一开始就装下全部历史，也能知道任务该从哪里接着做。

四、这套架构解决了旧问题，也引入了哪些新问题？

可以用一次代码迁移继续看这些风险。用户要求 Codex 升级项目依赖，并明确提出“不要修改支付模块”。Agent 已经改完大部分文件，测试仍然失败。它在 Notes 中只写了“依赖升级已完成，下一步修复测试”，却漏掉了支付模块不能修改，也没有记录测试失败的原因。新窗口即使顺利读到这份交接单，也可能从错误的起点继续。

Notes 是最直接的风险点。它写得太少，关键限制和失败原因可能带不过去；写得太多，又可能变成另一份冗长的上下文。更麻烦的是，如果 Agent 已经误解了任务，它也可能把错误理解写入 Notes。判断交接单是否合格，不能只看它有没有生成或写了多少字，而要看接手者能否据此做出正确的下一步。

History 解决的是“旧记录还在不在”，却没有自动解决“需要时能不能找对”。假设真正有用的信息藏在一次测试输出里，新窗口搜索“依赖升级失败”，原记录写的却是“类型检查异常”，这次查询就可能错过关键内容。产品需要测试关键记录能否在正确时间被找到并用于当前判断，不能因为有了搜索入口，就认为历史问题已经解决。

切换窗口的时机也很难只靠一个数值决定。切得太早，Agent 会频繁写交接单、恢复状态和回查历史；切得太晚，当前工作台已经堆满旧内容，可能连一份完整的 Notes 和必要的收尾都写不好。预算提醒只能告诉 Agent 资源正在减少，何时停止探索、进入验证并准备交接，仍然需要产品规则和模型策略共同决定。

不同位置保存的状态还可能互相冲突。用户已经修改 Goal，Notes 却保留着旧要求；History 找回的是早期方案，但这个方案后来已经被否决；文件实际上已经修改，交接单却还停留在修改之前。如果系统不知道该相信哪一份信息，新窗口得到的材料越多，反而越难作出正确判断。

这种冲突在外部操作中更危险。Agent 写完 Notes 后，可能又发送了消息、创建了记录或提交了审批。如果新窗口只看到过期的 Notes，就有可能把已经完成的动作再做一次。因此，交接单不能只写“下一步做什么”，还要区分哪些动作已经完成、哪些尝试失败、哪些结果仍不确定。涉及付款、授权和安全要求的状态，更不能只依赖模型自己概括。

预算也会反过来影响 Agent 的行为。前期搜索花得太多，后面可能没有足够资源运行测试和整理结果；同时启动太多子 Agent，总预算会下降得更快；预算太紧，任务可能过早结束，预算太宽，又可能带来更多无效尝试。Token Budget 让资源变得可见，但怎样把资源分给理解、执行、验证和交付，仍然是一个需要不断校准的产品问题。

五、这次变化对 AI 产品经理意味着什么？

评价一套长任务 Agent，不能只问“模型记忆好不好”。Context 切换以后，它能否继续执行最新目标，是否知道哪些工作已经完成，能否找回需要的证据，又能否在预算内完成验证和交付，这些问题更接近用户最终得到的结果。

产品设计可以先明确每类信息应该放在哪里。Goal 保存当前目标、完成标准和停止条件；Notes 保存已经完成的工作、关键决定、未解决问题、重要产物位置和下一步；History 保留可以回查的过程记录；授权、付款、安全规则和业务状态则进入更可靠的结构化系统。信息的重要性越高、外部影响越大，就越不应该只交给模型自由概括。

交接状态还需要写清版本。Goal 修改以后，Notes 应该能对应到新的目标；文件或数据发生变化时，要留下可以核对的对象和结果；调用外部工具时，要区分成功、失败、结果未知和从未执行。这样，新 Context 才不会把旧计划当成当前任务，也不会重复执行已经完成的操作。

评测也要从“还记不记得开头那句话”转向完整任务。一个有效样本可以故意加入中途改口、相似文件名、被否决方案、精确数字、工具失败、子 Agent 协作和多次 Context 切换。任务结束后，再检查它是否执行了最新要求、是否重复走过失败路线、是否找到了关键证据，以及是否留下足够预算完成测试和交付。

指标不需要一开始就铺得很复杂。先看长任务最终有没有完成、人工接管了多少次、交付是否一次通过、总共消耗了多少资源。结果不好时，再往前查：新窗口是否成功恢复了任务，关键限制有没有保留，历史记录有没有找对，预算又是在什么阶段花完的。这样的指标才能帮助团队定位问题，而不只是得到一个“token 用得很多”的结论。

用户也需要看到必要的任务状态。产品可以展示当前 Goal、任务进行到哪一步、预算大致用了多少、最近一次 Notes 记录了什么。当目标偏移、历史找不到、状态互相冲突或预算即将耗尽时，系统应让用户能够修正目标、补充信息或接管任务。高风险操作更应该在状态不确定时暂停，而不是让 Agent 带着猜测继续。

接管也不应该意味着让用户从头阅读所有聊天。一个可用的接管页面，至少要把当前目标、已经完成的工作、仍未解决的问题、关键证据位置和剩余预算放在一起。用户看完后应该能直接决定继续、修改目标还是终止任务。否则，系统虽然保存了全部历史，真正需要负责的人仍然无法快速接手。

预算配置要跟着任务类型变化。代码迁移需要为测试和回归留资源，资料研究需要为核对来源留资源，涉及客户或业务系统的任务还要为确认与人工接管留资源。团队要观察资源通常消耗在哪个阶段，再决定探索可以花多少、什么时候应该收敛，以及哪些子任务值得并行。

一个可行的起点，是挑选一项经常发生的长任务，为它制定最小交接规则。每次切换前记录有效目标、关键决定、产物位置、已知失败和下一步；切换后要求 Agent 先恢复这些状态，使用旧事实时能够找到对应记录；恢复失败、证据缺失或预算不足时转交人工。再用固定预算重复运行几组包含中途改口、工具失败和多次换窗的任务，比较完成率、恢复时间、人工接管次数和总成本。做到这一步，“长任务记忆”才从一个模糊的模型能力，变成可以设计和验证的产品能力。