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 控制在这几类信息最新目标最新约束已完成事实已验证证据剩余动作明确禁止事项。这比搬运全文更干净。切换前的检查清单在发起新会话前我一般会做一次小检查当前目标有没有一句话版本用户最新要求有没有覆盖进去禁止动作有没有单独列出来文件改动是否已经按路径列清楚命令验证结果是否有真实结论未完成事项是否能直接执行是否说明了哪些信息不能外传是否提醒新会话不要回滚无关改动是否提醒新会话先读git status是否说明最后要输出哪些验收证据。这些检查不是形式主义。新会话能不能顺利接上主要就看这里。自动续跑不是放任自动化这里的“自动”不是让 AI 不受控地开很多会话。更合理的理解是当长会话接近失控点时自动进入标准化交接流程。也就是说自动化的是“交接动作”和“交接格式”不是让新会话绕过确认、跳过验证、随意修改。尤其是工程任务里新会话仍然要遵守这些边界不碰生产环境不提交敏感数据不删除用户未授权文件不覆盖无关改动不把失败命令包装成通过不在没有验证时声称完成。长会话续跑的价值是让任务延续而不是降低工程纪律。我会把它做成一个小工具包这套方法最适合沉淀成一个轻量工具包而不是复杂脚本。工具包可以包含长会话风险自查提示词新会话接力 handoff 模板切换前后检查清单脱敏示例可复制到个人 Codex Skill 的规则草案。如果你想直接拿模板落地也可以下载这篇文章的配套资料包Codex 长会话自动续跑提示词工具包资料包里包含上面这些提示词、检查清单、脱敏示例和 Skill 草案适合按自己的 Codex 使用习惯再做二次调整。这样团队成员不需要理解所有底层机制也能按模板把长任务稳定交给新会话。如果以后要进一步自动化再考虑接入线程工具例如get_goal - 判断 token 或上下文风险 - 生成 handoff - fork_thread / create_thread - send_message_to_thread但第一版我更建议先把“交接质量”做好。最后总结长会话不是不能用但不能无限堆。我的经验可以压缩成四句话长任务要有接力点不要等会话撑爆新会话需要的是工程化 handoff不是旧会话全文handoff 要写清目标、约束、状态、证据、文件和下一步自动续跑的本质是上下文治理不是放弃验证和边界。如果你经常用 Codex 做持续数小时的工程任务这个小机制非常值得沉淀。它解决的不是某一次回答质量而是 AI 协作能不能持续稳定地跑下去。可复用模板下面这段可以直接复制使用你正在接手一个 Codex 长会话任务。请不要从头重做请先按以下信息恢复上下文。 【目标】 ... 【当前目录】 ... 【用户最新要求】 ... 【已完成】 ... 【已修改文件】 ... 【已验证】 ... 【未完成】 ... 【禁止事项】 ... 【接手后的第一步】 先运行 git status --short并读取上述关键文件确认状态确认后继续未完成事项。