过去使用AI写代码很多任务都比较短。改一个函数。修一个Bug。补几个测试。任务做完以后开发者通常只需要看最后结果代码能不能跑。测试有没有通过。功能是不是正常。这种方式在短任务里没有太大问题。但随着ChatGPT、Codex越来越能自主执行长任务一个新的问题正在出现任务跑得越久“最后显示完成”这件事本身越不足以证明整个过程真的可靠。因为一个长Agent任务中间可能已经发生了很多事情方向调整。假设变化。测试失败。Scope扩大。部分修改被推翻。Context被压缩。甚至某些关键状态已经和任务刚开始时完全不同。所以未来长任务真正值得关注的不只是Final Result最终结果。还包括Intermediate State中间状态。一、为什么短任务可以只看结果长任务却不行假设你让Codex把这个函数里的空值判断修一下。它改了几行代码。测试通过。你看一下Diff。任务结束。这种任务的执行链很短。即使中间有一点问题影响也有限。但如果任务变成排查大型Repository里一个偶发并发Bug修复以后补Regression Test并确认没有影响其他模块。Agent可能跑很久。它需要搜索大量文件。建立多个Hypothesis。运行测试。失败。重新分析。修改代码。再次测试。甚至更换方案。这时候任务不再是Input → Output而更像Input → State 1 → State 2 → State 3 → … → Final Result如果只看最后一步就会丢掉大量真正决定任务质量的信息。二、最危险的情况是最后成功了但中间发生了什么没人知道比如Agent最后告诉你“Bug已修复所有相关测试通过。”听起来很好。但如果你往回看可能会发现最开始它怀疑数据库。后来改成缓存。中间又认为是Retry。最后才定位到并发条件。在这个过程中它可能改过无关文件。尝试过错误方案。修改过测试。删除过临时代码。最终虽然结果看起来正确但整个执行链里可能留下State Residue状态残留。也就是一些已经过时、被推翻、但仍然存在于Context或代码历史里的信息。如果后面任务再次失败人很难快速知道哪些状态还能信。三、长任务真正需要的是Checkpoint所以未来复杂Agent任务里一个越来越重要的概念就是Checkpoint——检查点Checkpoint不是简单记录“做到第50%了。”真正好的Checkpoint应该回答当前Goal是什么有没有发生变化已经确认了什么哪些Evidence是可靠的已经排除了什么哪些Hypothesis不需要再查当前代码状态是什么哪些修改仍然有效下一步准备做什么这样即使任务后面失败你也不需要重新从零理解整个过程。四、为什么“进度百分比”价值其实不高很多Agent界面喜欢展示30%。60%。90%。但对于开发任务来说这种百分比经常很难真正代表Progress。比如Agent已经修改了大量代码。看起来完成80%。但Root Cause其实还没确认。那真正的有效进度可能很低。反过来一个任务可能还没写一行代码但已经明确问题来自某个并发条件。排除了数据库和缓存。这时虽然“代码完成度”很低任务实际上已经取得了很高价值的进展。所以未来更重要的不是Activity Progress活动进度。而是Evidence Progress证据进度。也就是有没有减少不确定性。五、真正好的Checkpoint应该保存“事实”而不是保存“故事”Agent很容易生成一段看起来完整的总结“我们已经检查了数据库、缓存和Retry目前认为问题可能与并发有关。”这种Summary有帮助但还不够。更有价值的Checkpoint应该尽量保存Facts例如数据库写入只发生一次。缓存读取在两个并发请求中返回同一旧版本。单线程无法复现。并发测试可以稳定复现。这样下一个Session或者下一个Agent接手时不需要重新相信一段Narrative。它可以直接基于Evidence。这会让长任务恢复更加稳定。六、为什么长任务特别容易出现“状态失真”因为Agent任务跑得越久中间状态越多。第一阶段认为问题在A。第二阶段排除A。第三阶段发现B。第四阶段B又只是Secondary Effect。最终Root Cause在C。如果这些状态没有及时整理Context里就可能同时存在A可能有问题。A已经排除。B是Root Cause。B不是Root Cause。C才是真正问题。对于长Context来说这些内容都会继续存在。所以真正危险的不是信息太少。而是Stale State过期状态。它仍然在Context里但已经不应该参与当前判断。七、Checkpoint的一个核心作用就是清理过期状态好的Checkpoint不应该只是“把前面发生的事情全部总结一遍”。而应该完成一次State Compression状态压缩。比如原来有100条探索记录。最终Checkpoint只留下当前Goal。确认Evidence。已排除方向。有效修改。剩余风险。下一步。这实际上是在告诉Agent哪些历史还值得继续带着哪些已经可以放下。所以Checkpoint并不是为了保留所有信息。恰恰相反是为了保留真正值得继续使用的信息。八、可以建立一个指标Checkpoint Quality以后判断一个长任务是否容易恢复可以看Checkpoint Quality可以问四个问题。第一当前状态是否清楚第二关键Evidence是否明确第三已经排除的方向有没有被记录第四下一步是否明确如果这四件事都清楚Checkpoint质量很高。即使任务失败、Session结束、Agent切换也能很快继续。如果Checkpoint只有一句“已经做了很多排查继续解决问题。”几乎没有价值。九、为什么最终结果也可能制造“假完成”长任务最后经常会出现代码能跑。测试通过。Agent说Done。但这并不一定说明原始目标真的完成。比如任务最初是解决并发重复订单。Agent最后只让测试通过了。但真实并发条件没有验证。或者任务最初要求保持API兼容。最终实现虽然能跑但返回行为已经变化。这就是False Done假完成。所以长任务最终验收时还需要回到最开始的Original Goal而不是只看最后一轮Agent自己的Done标准。十、可以用“Goal → State → Evidence → Done”来判断长任务未来复杂任务可以采用一个非常简单的结构Goal最初到底要解决什么↓State当前任务处于什么状态↓Evidence有哪些事实证明方向正确↓Done哪些Acceptance Criteria已经满足这样每个阶段都能回答我们为什么还在继续如果这个链条断掉就说明任务可能已经跑偏。停滞。或者只是制造Activity。十一、为什么中间状态会直接影响失败恢复假设一个Agent已经跑了40分钟。最后因为环境异常中断。如果没有Checkpoint重新开始时可能需要重新读取Repository。重新建立Context。重新跑测试。重新排除已经排除过的问题。这就是Recovery Cost恢复成本。但如果中间有高质量Checkpoint当前Root Cause。已验证Evidence。有效修改。剩余任务。全部保存下来。新Session只需要恢复真正必要的状态。所以一个成熟的长任务不应该追求永远不失败。而应该追求即使失败也不会从零开始。十二、什么时候应该主动创建Checkpoint不需要每5分钟就做一次。但以下节点非常适合Root Cause确认以后。准备开始大规模修改以前。完成一个重要阶段以后。准备Compaction以前。任务即将切换Session以前。高风险修改完成以后。也就是说Decision Boundary关键决策边界往往就是最适合形成Checkpoint的地方。因为这里意味着任务状态发生了一次真正有价值的变化。十三、Multi-Agent以后中间状态会变得更重要如果一个Agent做完整个任务中间状态只是方便恢复。但Multi-Agent不同。比如Agent A负责分析。Agent B负责实现。Agent C负责测试。A不能只告诉B“我觉得应该改缓存。”更好的Handoff应该包含Goal。Root Cause。Evidence。已排除方向。修改边界。这样B才能真正继承A的工作。否则所谓Multi-Agent只是多个Agent重复探索同一个问题。所以未来多Agent真正需要传递的不只是任务结果。还需要Transferable State可转移状态。十四、为什么这会改变“长任务完成率”的判断很多人会看这个Agent最终有没有完成任务。但未来更有价值的指标可能是Recoverable Progress可恢复进度。即使一个任务最终没有完成如果它已经确认Root Cause。排除三个错误方向。留下稳定Evidence。形成可恢复Checkpoint。那么这些工作并没有完全浪费。下一个Session可以继续。反过来一个Agent跑了很久但中间没有形成任何可复用状态。最后一旦失败全部重新开始。这种任务真正的有效产出反而很低。十五、Plus用户最容易误判的是任务失败就等于额度浪费一个长任务失败以后很多人第一反应是这次额度白用了。其实不一定。如果任务留下了有效Evidence。Root Cause。Checkpoint。验证结果。那么这次执行仍然产生了Reusable Progress可复用进展。真正浪费的是跑了很久。但没有留下任何能够带到下一轮的状态。所以Plus阶段很值得先优化Checkpoint。Evidence。State Summary。Recovery Point。这些往往比单纯增加运行时间更有价值。十六、什么时候Plus通常已经够如果你的长任务已经能做到阶段目标明确。关键节点形成Checkpoint。过期Hypothesis及时清理。失败以后能够快速Resume。最终Done会重新对照原始Acceptance Criteria。那么Plus通常已经可以承担很多中等复杂度的长Agent任务。因为即使任务不是一次跑到底也可以稳定续跑。这会明显提高同样容量的有效利用率。十七、什么时候Pro才真正开始匹配更接近Pro的情况是你的Checkpoint体系已经成熟。长任务能够稳定恢复。状态不会因为Session切换大量丢失。大部分执行都能形成可复用Progress。但每天仍然存在大量复杂Repository。长时间Agent任务。高价值并行任务。而这些任务本身持续受到容量限制。这时候问题才真正从State Management Problem状态管理问题变成Capacity Problem容量问题。此时更高容量才更容易真正转化成更多连续有效执行。最后AI任务越来越长以后一个很容易产生的误区是只要最后结果是好的中间过程就不重要。但真实工程并不是这样。因为长任务不是一次回答。它是一个不断变化的状态系统。中间会出现新Evidence。旧Hypothesis。方案切换。代码变化。失败。恢复。如果这些状态没有被管理最后即使成功也很难判断为什么成功。如果失败更难知道应该从哪里继续。所以未来真正成熟的Agent工作流不会只关注Final Result。还会关注Intermediate State。Checkpoint。Evidence。Recoverable Progress。因为AI任务跑得越久真正重要的就越不是“最后它说完成了吗”而是“如果现在停下来我们到底知道什么又能从哪里继续”这才是长任务真正可靠的基础。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型整理了稳定的Plus/Pro会员订阅渠道有需要可自取