过去用AI写代码时任务通常比较短。问一个问题。改一个函数。修一个Bug。如果结果不对重新开一个对话再来一次成本通常不高。但随着ChatGPT、Codex越来越能自主执行长任务情况开始变化。现在一个Agent任务可能已经连续运行很久中间完成了Repository搜索。Root Cause分析。代码修改。测试。失败重试。方案切换。上下文压缩。甚至已经形成了一整套对项目的理解。这时候如果任务突然失败很多人最直接的处理方式还是重新开一个Session从头再跑。但未来长Agent任务里这种“从头再来”可能会变成一种越来越昂贵的失败。因为你失去的不只是前面花掉的时间。真正丢掉的是Accumulated State——已经积累起来的任务状态所以Agent时代真正需要优化的不只是任务能不能一次跑完。还要考虑如果中途失败能不能从一个有价值的位置继续。一、为什么以前“重新来一次”成本没那么高短任务的最大特点是Context少。状态简单。依赖少。比如你让AI修复这个函数的空指针问题。它尝试一次失败。重新打开Session再把相关代码贴进去。AI很快就能重新建立任务状态。所以Restart Cost非常低。但长任务完全不同。假设Codex已经做了40分钟读了几十个文件。排除了数据库问题。确认缓存存在竞争条件。修改了两个模块。跑了多轮测试。还发现一个边界Case没有处理。这时候如果Session直接丢掉新的Agent不仅要重新“写代码”。它首先要重新理解之前已经知道了什么。这就是Restart Cost重启成本。二、真正昂贵的不是重新执行而是重新建立理解很多人会觉得AI速度这么快重新跑一次也没关系。问题是代码生成确实便宜。但一个复杂任务最贵的部分往往不是生成代码。而是State Reconstruction状态重建。比如新Session进入后需要重新回答当前Primary Goal是什么已经排除了哪些方向Root Cause到底确认到什么程度哪些修改已经验证有效哪些测试失败是已知问题哪些Hypothesis已经证明错误如果这些东西都要重新探索Agent其实是在重复消耗搜索。推理。Context。测试。工具调用。所以“从头再来”的成本本质上不是重新生成。而是重新获得已经拥有过的理解。三、长任务最容易丢失的是“探索价值”比如一个复杂Bug排查。前30分钟没有写任何代码。Agent只是检查日志。读调用链。尝试复现。排除几个错误方向。从表面看它好像“什么都没做”。但实际上这30分钟可能已经产生了很高价值数据库不是Root Cause。网络不是Root Cause。问题只在高并发下出现。某个共享状态最可疑。这些都属于Search Space Reduction搜索空间缩减。如果任务失败后全部从零开始这些已经排除的方向可能被重新搜索一遍。于是最浪费的不是代码。而是已经减少过的不确定性又重新变大。四、所以长任务真正应该保存的是“可恢复状态”可以把它叫Recoverable State可恢复状态。一个好的Recoverable State不需要保存整个Conversation。真正值得保留的通常只有当前Goal。关键Evidence。已排除Hypothesis。当前有效修改。失败的测试。剩余问题。下一步动作。只要这些状态还在新Session就不需要重新经历整个历史。它可以直接从当前最有价值的位置继续。这和软件系统里的Checkpoint非常像。五、Restart和Resume其实是两种完全不同的失败处理以后Agent任务失败后可以先区分Restart从头重新开始。重新读取。重新分析。重新建立Context。和Resume从已有状态继续。继承Evidence。Checkpoint。代码状态。下一步计划。真正成熟的长任务应该尽量从Restart-heavy转向Resume-friendly。因为任务越长Restart的损失越大。六、可以建立一个指标Resume Cost未来判断一个Agent Workflow成熟不成熟可以看Resume Cost——恢复成本比如一个任务中断后新Session需要多久才能重新进入有效工作状态。如果需要重新读大量文件。重新解释背景。重新跑所有测试。重新探索已经排除的路径。Resume Cost就很高。如果只需要读取Checkpoint。确认当前代码状态。继续下一步。Resume Cost就很低。所以长任务优化里一个很重要的目标不是永远不中断。而是中断以后恢复足够便宜。七、Checkpoint真正的价值就是降低Resume Cost一个好的Checkpoint可以写得非常短。比如Goal修复订单并发创建重复记录问题。Confirmed数据库唯一约束正常问题发生在幂等记录写入前。Ruled Out客户端重复提交不是主因。Current Change正在测试事务内幂等检查方案。Failing Test高并发场景仍偶发失败。Next Step检查事务隔离级别。这几行的价值非常高。因为它让新Session不用重新理解几十分钟历史。这就是State Transfer状态转移。八、为什么只保留Conversation历史还不够很多人会觉得对话记录不是都在吗理论上有。但Conversation越长真正有价值的信息越容易被埋在旧假设。失败尝试。重复日志。中间解释。里面。这会导致State Noise状态噪声。所以恢复任务最需要的不是“把历史全部重新喂进去。”而是把已经确认的有效状态提炼出来。这也是Checkpoint和完整Context最大的区别。九、真正好的Checkpoint应该区分“事实”和“猜测”恢复长任务时最危险的是把旧Hypothesis当成Fact。比如“缓存可能有问题。”这只是猜测。但如果Checkpoint里写成“问题来自缓存。”新Session可能直接沿错误方向继续。所以可恢复状态最好区分Confirmed Evidence已确认事实。和Open Hypothesis待验证假设。例如Confirmed单线程无法复现。Hypothesis可能存在并发写竞争。这样新Agent知道什么可以直接继承什么仍然需要验证。十、什么时候最应该保存Recovery Point不是每一步都要保存。真正适合形成Recovery Point的通常是Root Cause确认以后。大范围修改开始以前。一个阶段验证完成以后。准备切换Session以前。Context即将Compaction以前。高风险操作之前。这些位置可以叫Recovery Boundary恢复边界。因为任务一旦越过这里状态价值已经发生明显变化。十一、“从头再来”为什么还会放大返工假设第一个Agent已经排除A。排除B。开始验证C。Session失败。新Session没有Checkpoint。于是它重新怀疑A。调查A。再排除A。接着检查B。这不仅浪费时间。还可能因为不同模型或不同Context产生新的路径导致重复修改。重复测试。重复错误。这叫Re-exploration Cost重复探索成本。Agent越能自主搜索重复探索造成的算力浪费越明显。十二、Multi-Agent以后“从头再来”会更贵如果只有一个Agent丢失状态已经很麻烦。多Agent场景更明显。比如Agent A完成Root Cause分析。Agent B基于A的结果开始实现。Agent C准备测试。如果A的状态没有结构化保存B和C就可能分别重新解释到底问题是什么。甚至得出不同结论。最后Multi-Agent并没有提高效率反而制造State Fragmentation状态碎片化。所以未来多Agent真正需要共享的不只是文件。还包括稳定、可转移的任务状态。十三、可以建立一个指标Recovery Efficiency未来可以用一个简单指标Recovery Efficiency恢复效率。判断一次任务中断后多少已有工作可以直接复用多少必须重做比如80%的Evidence能继续使用。代码状态可恢复。测试结果可继承。只有最后20%需要重新执行。Recovery Efficiency就很高。如果所有东西都要重新跑。那即使Agent单次执行速度很快长期效率也很低。十四、什么时候应该Restart而不是Resume当然不是所有旧状态都值得保留。如果当前Session已经出现大量错误Hypothesis。Scope严重漂移。代码状态和最初相比变化太大。Compaction以后理解明显失真。你已经无法判断哪些结论可信。这时候强行Resume反而会把旧问题带进新任务。更合理的是Clean Restart干净重启。但即使Clean Restart也不应该是完全失忆。应该先保留最终确认Evidence。明确排除项。当前真实代码状态。原始Goal。再重新建立Context。也就是说Restart不等于什么都不带。十五、真正成熟的Agent Workflow应该设计“失败以后怎么继续”过去很多Workflow只设计任务怎么开始。怎么执行。怎么验证。但Agent时代越来越需要再加一个部分Recovery Policy恢复策略。比如轻微失败自动Retry。阶段失败回到最近Checkpoint。Session损坏新Session继承Recovery State。方向严重漂移Clean Restart。这比简单的“失败就再试一次”成熟得多。十六、为什么这件事会影响Plus和Pro判断很多Plus用户觉得长任务失败一次特别亏。前面额度全白用了。但真正应该看的是这次任务有没有留下Evidence。Checkpoint。可复用修改。Recovery Point。如果这些都留下了失败不一定等于浪费。真正浪费的是每次失败都必须重新支付完整的探索成本。所以在升级套餐以前先优化Checkpoint频率。State Transfer。Resume流程。Recovery Policy。往往可以直接减少大量重复消耗。十七、什么时候Plus通常已经够如果你的长任务已经能做到阶段性保存Checkpoint。Evidence和Hypothesis分开。Session中断后能够快速Resume。大任务有清晰Recovery Boundary。失败不会自动退回到零。那么Plus通常已经可以支撑很多中等复杂度Agent任务。因为你不要求每个任务必须一次跑到底。而是允许分阶段完成。失败恢复。持续推进。这会明显提高容量利用率。十八、什么时候Pro才真正开始匹配更接近Pro的情况是你的Recovery Workflow已经比较成熟。Restart Cost很低。Resume Cost可控。大部分长任务中断以后都能稳定续跑。重复探索明显减少。但每天仍然有大量复杂Repository。跨模块任务。长时间执行。多个高价值任务并行。并且这些任务本身持续受到容量限制。这时候问题才真正从Recovery Problem恢复问题变成Capacity Problem容量问题。此时更高容量才更容易转化成更多连续有效执行。最后AI越来越能连续工作以后一个很容易忽略的变化是任务中间积累起来的状态正在变得越来越值钱。过去一个短任务失败重新开始。问题不大。未来一个Agent已经运行40分钟、1小时甚至更久以后再说“没事重新开一个Session再跑一次。”代价就可能完全不同。因为真正被丢掉的不是几段代码。而是已经建立起来的理解。已经排除的方向。已经验证的Evidence。已经形成的任务状态。所以未来真正成熟的Agent系统不会只追求让任务尽量不失败。还会追求即使失败也不要把已经赚到的进度全部清零。这就是为什么长任务越来越重要以后Checkpoint。Recovery Point。Resume Cost。State Transfer。都会变成越来越重要的工程能力。因为Agent时代真正昂贵的失败可能不是任务中断。而是任务中断以后你又不得不从头理解一遍所有已经理解过的事情。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型整理了稳定的Plus/Pro会员订阅渠道有需要可自取