Codex 长会话太长怎么办？用“自动续跑”机制把任务接到新会话继续干

摘要

长时间使用 Codex 做研发、测试、文档或排障任务时，会话上下文会不断变长，token 消耗随之上升，后续每次交互都可能变慢、变贵，也更容易出现上下文漂移。我的实践不是等到会话撑爆再补救，而是在累计 token 接近阈值时，主动生成 handoff 摘要，分叉或新建一个会话，再把目标、状态、证据、下一步动作交给新会话继续执行。本文总结这套“长会话自动续跑”方法，并附一个可复用的提示词工具包思路。

这篇适合谁看

如果你已经开始把 Codex 当作长期协作的工程助手，而不是只让它回答几个代码问题，这篇会比较有用。

典型场景包括：

• 一个需求要跑好几个小时，中间会读很多文件、跑很多命令、修很多问题；
• 一个会话里已经出现大量工具输出、日志、代码片段和决策记录；
• 你发现自己只是追问一句“继续”，但模型每次都要背着很长的上下文工作；
• 任务还没有结束，但你不想丢掉已经完成的分析、变更和验证证据；
• 你希望新会话能接着干，而不是重新从头解释一遍。

这类问题本质上不是“模型聪不聪明”，而是工程协作里的上下文管理问题。

长会话为什么会越来越重

在一次 Codex 会话里，模型看到的通常不只是你刚输入的那句话。

它可能还要处理：

• 系统规则和项目规则；
• 之前的对话历史；
• 已读取过的文件片段；
• 命令输出；
• 工具调用结果；
• 中间计划；
• 失败尝试；
• 你临时补充的约束；
• 模型自己生成过的解释和总结。

这些内容会让单次请求的 token 量持续增加。

所以会出现一个很常见的现象：你输入很短，例如“继续”“验证一下”“修掉这个问题”，但这次请求实际携带的上下文并不短。

如果会话被系统自动压缩，token 压力会缓解一些，但这不是完整解决方案。压缩摘要可能丢掉细节，也未必能准确保留当前任务的所有工程边界。

我的经验是：长任务应该主动设计“接力点”。

我现在采用的续跑思路

核心思路很简单：

监控当前会话长度
-> 到达阈值前生成 handoff
-> 分叉或新建新会话
-> 把 handoff prompt 发过去
-> 新会话先复核状态
-> 继续执行剩余任务

这里的关键不是“新建会话”这一步，而是新会话拿到的 handoff 是否足够工程化。

一个合格的 handoff 不能只是：

我们刚才做了很多工作，请继续。

它至少要回答六件事：

模块	要说明什么
目标	当前任务最终要完成什么
范围	允许改哪里，不能碰哪里
当前状态	已经完成了什么，卡在哪里
证据	哪些命令跑过，结果是什么
文件	哪些文件改过、哪些文件只读过
下一步	新会话应该从哪个动作开始

只要这六件事写清楚，新会话就不是“重开一局”，而是“接着当前工单干”。

触发阈值怎么定

我一般不建议等到上下文真的撑不住再切。

比较实用的分层阈值是：

阶段	经验判断	建议动作
轻量阶段	刚开始，文件和日志不多	正常继续
预警阶段	已经读了大量代码、日志、截图或报告	开始整理状态摘要
切换阶段	任务还没完，但上下文已经明显变重	生成 handoff，准备新会话
强制阶段	频繁遗忘约束、重复读文件、回答变散	立即切换，不再继续堆上下文

如果能读取当前会话的累计 token，就可以把它作为硬指标；如果读不到，也可以用行为信号判断。

我会重点看这些信号：

• 模型开始重复问已经回答过的问题；
• 模型对“不能改”的范围记得不稳定；
• 同一批文件反复读取；
• 每次响应明显变慢；
• 继续执行时开始偏离上一轮计划；
• 工具输出很长，但没有被压缩成明确结论；
• 已经出现多轮失败尝试，历史噪音开始变多。

这些都说明这个会话适合交接。

Codex Desktop 里的实际机制

在 Codex Desktop 里，这套续跑通常可以用几个线程能力组合出来：

• get_goal：查看当前目标和累计 token 情况；
• fork_thread：从当前会话分叉一个新会话，保留已完成历史；
• create_thread：显式创建一个新项目会话或后台会话；
• send_message_to_thread：把 handoff prompt 发给目标会话，让它继续执行；
• read_thread：必要时读取旧会话状态，核对接力信息。

不同任务可以选择不同模式。

如果任务还在同一个项目目录下继续做，我更倾向于：

fork_thread
-> send_message_to_thread

这样新会话自然继承同一段工作背景，切换成本更低。

如果是要把剩余工作交给一个干净的新线程，或者要放到后台继续跑，则更适合：

create_thread
-> send_message_to_thread

这里要注意：不要把“线程迁移”和“长会话续跑”混成一件事。迁移线程更偏工作区或执行环境切换；长会话续跑的重点是把任务状态整理成可接力的工程上下文。

handoff prompt 应该怎么写

我现在常用这个结构：

你正在接手一个 Codex 长会话任务，请先不要从头重做。

【目标】
说明最终要完成什么。

【当前目录】
说明项目路径。

【用户最新要求】
列出用户最新口径，尤其是禁止动作。

【已完成】
按条目写清楚已经做完的工作。

【已修改文件】
列出文件路径和修改意图。

【已验证】
列出命令、结果、失败原因或剩余风险。

【未完成】
列出下一步任务，按优先级排序。

【接手要求】
1. 先读取关键文件确认状态。
2. 不要回滚旧会话已做的相关改动。
3. 不要碰无关 dirty worktree。
4. 继续执行未完成事项。
5. 完成后给出验证证据。

这个模板看起来朴素，但比一句“继续”可靠得多。

一个脱敏示例

假设旧会话正在做一个前端管理页改造，已经完成页面结构和部分 API 对接，但还没验证移动端。

handoff 可以这样写：

你正在接手一个 Codex 长会话任务，请不要从头重做。

【目标】
完成某管理页 MVP：配置驱动入口列表、本地服务状态展示、服务详情抽屉和移动端响应式布局。

【当前目录】
/path/to/example-project

【用户最新要求】
- 不接入外部系统。
- 不保存任何密码、cookie、token。
- 不覆盖无关 dirty worktree。
- 完成后运行本地验证并报告结果。

【已完成】
- 已确认项目使用 Vite + React。
- 已新增服务列表页面和配置读取逻辑。
- 已实现服务详情抽屉的基本 UI。
- 已补充敏感字段拒绝逻辑。

【已修改文件】
- src/App.tsx：新增主页面结构。
- src/api/config.ts：新增配置读取和保存校验。
- src/styles.css：新增桌面端布局。

【已验证】
- npm run build：通过。
- curl http://127.0.0.1:8790/api/services：返回示例数据。
- 移动端视图尚未验证。

【未完成】
1. 补移动端响应式布局。
2. 验证停止确认弹窗。
3. 跑浏览器截图检查。
4. 更新 README 的本地运行说明。

【接手要求】
先读 git status 和上述文件，再继续第 1 项。不要重写已完成结构。

这个新会话拿到后，通常就能快速进入工作状态。

不建议把所有历史都搬过去

很多人一想到接力，就想把旧会话全文复制给新会话。

这通常不是好办法。

旧会话里会混杂：

• 已失败的尝试；
• 已废弃的方案；
• 中途讨论；
• 很长的日志；
• 大量重复命令输出；
• 已经被新证据推翻的判断。

新会话真正需要的是“当前事实”，不是“全部历史”。

我更推荐把 handoff 控制在这几类信息：

1. 最新目标；
2. 最新约束；
3. 已完成事实；
4. 已验证证据；
5. 剩余动作；
6. 明确禁止事项。

这比搬运全文更干净。

切换前的检查清单

在发起新会话前，我一般会做一次小检查：

• 当前目标有没有一句话版本；
• 用户最新要求有没有覆盖进去；
• 禁止动作有没有单独列出来；
• 文件改动是否已经按路径列清楚；
• 命令验证结果是否有真实结论；
• 未完成事项是否能直接执行；
• 是否说明了哪些信息不能外传；
• 是否提醒新会话不要回滚无关改动；
• 是否提醒新会话先读 git status；
• 是否说明最后要输出哪些验收证据。

这些检查不是形式主义。新会话能不能顺利接上，主要就看这里。

自动续跑不是放任自动化

这里的“自动”不是让 AI 不受控地开很多会话。

更合理的理解是：

当长会话接近失控点时，自动进入标准化交接流程。

也就是说，自动化的是“交接动作”和“交接格式”，不是让新会话绕过确认、跳过验证、随意修改。

尤其是工程任务里，新会话仍然要遵守这些边界：

• 不碰生产环境；
• 不提交敏感数据；
• 不删除用户未授权文件；
• 不覆盖无关改动；
• 不把失败命令包装成通过；
• 不在没有验证时声称完成。

长会话续跑的价值，是让任务延续，而不是降低工程纪律。

我会把它做成一个小工具包

这套方法最适合沉淀成一个轻量工具包，而不是复杂脚本。

工具包可以包含：

• 长会话风险自查提示词；
• 新会话接力 handoff 模板；
• 切换前后检查清单；
• 脱敏示例；
• 可复制到个人 Codex Skill 的规则草案。

如果你想直接拿模板落地，也可以下载这篇文章的配套资料包：

Codex 长会话自动续跑提示词工具包

资料包里包含上面这些提示词、检查清单、脱敏示例和 Skill 草案，适合按自己的 Codex 使用习惯再做二次调整。

这样团队成员不需要理解所有底层机制，也能按模板把长任务稳定交给新会话。

如果以后要进一步自动化，再考虑接入线程工具，例如：

get_goal
-> 判断 token 或上下文风险
-> 生成 handoff
-> fork_thread / create_thread
-> send_message_to_thread

但第一版我更建议先把“交接质量”做好。

最后总结

长会话不是不能用，但不能无限堆。

我的经验可以压缩成四句话：

1. 长任务要有接力点，不要等会话撑爆；
2. 新会话需要的是工程化 handoff，不是旧会话全文；
3. handoff 要写清目标、约束、状态、证据、文件和下一步；
4. 自动续跑的本质是上下文治理，不是放弃验证和边界。

如果你经常用 Codex 做持续数小时的工程任务，这个小机制非常值得沉淀。它解决的不是某一次回答质量，而是 AI 协作能不能持续稳定地跑下去。

可复用模板

下面这段可以直接复制使用：

你正在接手一个 Codex 长会话任务。请不要从头重做，请先按以下信息恢复上下文。

【目标】
...

【当前目录】
...

【用户最新要求】
...

【已完成】
...

【已修改文件】
...

【已验证】
...

【未完成】
...

【禁止事项】
...

【接手后的第一步】
先运行 git status --short，并读取上述关键文件确认状态；确认后继续未完成事项。