后台与长任务 Agent
系列入口：如何使用 Agent。相关：Git 检查点、上下文压缩与摘要。
一、为什么需要「后台」这种工作方式
前面讲的协作多是交互式的：你发任务、看它做、随时纠偏。但有些任务天然很长——全仓调研、批量改造、跑大量测试与数据处理，可能耗时几十分钟甚至更久。一直盯着屏幕既浪费你的时间，也容易因为会话被打断（网络抖动、终端关闭、电脑休眠）而前功尽弃。
后台/异步执行让你把长任务「发出去就可以去忙别的」，需要时再回来看进度、收结果。 它把「人必须在场」变成「人可以异步介入」，是处理大型任务的重要工作方式。
二、启动前：把长任务切成可恢复的阶段
后台任务最忌讳「一坨指令丢出去、中间无任何落地点」。启动前应先把目标拆成清晰阶段，并想清楚每阶段的成果以什么形式保存——写入文件、提交检查点、还是产出阶段性报告。
这样设计有两个目的：一是你随时能通过这些落地成果判断进度，而不是面对一个黑箱；二是万一中断，能从最近一个完成的阶段续跑，而不必从头再来。对会改动代码的任务，配合 Git 检查点；对调研类任务，让它把中间结论持续写进文档。把「可观察」和「可恢复」在启动前就设计好，是长任务稳妥与否的关键。
任务说明里还应包含明确的完成判据（产出什么、跑哪些检查），让 Agent 在无人盯守时也清楚终点，避免它自由发散、越做越多。
三、异步启动与进度查看
启动后台运行后，你可以去处理其他事，再通过客户端提供的方式回来看：任务是否还在运行、当前走到哪一步、已经产出了什么。理想的进度信号是那些客观的阶段成果——某份报告新增了几节、某批测试已通过、某些文件已提交——而不只是一句「我正在处理」。
查看进度也是一种轻量的异步把关：如果你中途发现方向偏了，可以及时介入纠正，而不必等它跑完几十分钟后才发现整段都走偏。长任务不等于放任不管，而是把「实时盯着」换成「周期性回看」。
四、中断与断点恢复
长任务被打断几乎是必然：网络断了、进程被杀、上下文被压缩、或者某阶段失败。可恢复性决定了你是否要为每次中断付出全部重跑的代价。
恢复的核心是依赖前面落地的阶段成果：确认上一个已完成、可信的检查点，把它的状态和「还剩什么」作为输入，让 Agent 从那里续跑，而不是重开一个什么都不知道的会话。对上下文可能被压缩的情况，让它维护一份滚动的任务状态摘要（已完成、关键决策、待办），保证续跑时不丢线索。这正与上下文压缩与摘要的方法相通。
恢复时还要先核对检查点确实可信、结果未过期，避免在一个已经被污染或过时的基础上继续——长任务跨越时间较长，期间代码或数据可能已被他人改动。
五、长任务特有的三类风险
5.1 上下文漂移
任务越长、经过的压缩和步骤越多，早期的目标与约束越可能被稀释或走样，Agent 可能逐渐偏离初衷。对策是阶段性对照原始目标、用滚动状态摘要锁定关键约束，并在回看时确认仍在正轨。
5.2 成本失控
后台任务无人即时叫停，可能因反复重试、死循环式探索而持续消耗 token 与时间。应为阶段、重试次数、总预算设置上限，并在成本异常时能及时中止；长任务尤其要先想清楚它是否真值得全自动跑完。
5.3 结果过期
一个跑了很久的任务，其依据可能在中途已变化：它分析的代码被合并、查询的数据已更新。收尾时要确认结论仍对应当前现实，而不是盲目采信一份「基于旧状态」的报告。
六、收尾：异步不等于免验收
任务跑完，验收标准和交互任务完全一致：读产出与 diff、跑测试、对照最初需求、抽样核对，参考输出校验的做法。「它在后台跑了很久」不是信任理由，时间长只代表投入多，不代表结果对。把好最后一关，长任务的价值才能真正落袋。
六点五、后台任务最大的错觉：「发出去就等于在推进」
把任务丢到后台，容易让人产生一种安心的错觉：它在跑，我只需要等结果。但「进程还活着」和「任务在正确推进」是两回事。一个后台任务可能早已卡死、在原地反复重试、或悄悄偏离了目标，而你不看就完全不知道，几十分钟后收来一份要么没进展、要么方向全错的结果，时间已经白白流走。
对治的核心是让进度基于客观产物，而非运行状态。在启动时就要求每个阶段把成果落到文件或检查点，你回看时看的是「报告新增了几节、测试通过到哪一步、提交了哪些内容」，这些无法伪造，也能立刻分辨是真推进还是空转。把周期性回看排进自己的日程，而不是等跑完才一次性检查——中途一次及时的纠偏，往往能省下整段返工。
这也意味着异步不等于放任。你省下的是「实时盯守」，而不是「把关责任」。 把后台协作理解成「我可以晚几分钟看，但必须看」，才能既享受异步的自由、又不被「发出去就放心」的错觉反噬。
六点六、断点恢复：续跑最容易踩的两个坑
中断恢复听起来美好，实际操作中有两个高频坑，会让「续跑」变成「带着错误继续」。
第一个坑是从不完整或不可信的检查点恢复。如果所谓检查点只是中途存了一下、并未验证状态可用，基于它续跑等于在一个已经坏掉的基础上盖楼。恢复前应先确认该检查点确实通过了测试、成果完整。第二个坑是忽视时间差导致的过期：长任务跨越较久，期间相关代码可能被合并、数据可能被更新，你让它基于旧上下文继续，产出的可能是一份对不上当前现实的结果。续跑前要快速核对依据是否仍然成立。
除了选对检查点，恢复时输入的信息组织也很关键。不要开一个空白会话指望它「接着上次」，而要把滚动状态摘要（已完成、关键决策、待办、未决风险）连同检查点一起显式提供。把「记忆」落在持续维护的文件里，而不是它的瞬时上下文，续跑才能无缝，而不是重新摸索或丢掉关键线索。
六点七、什么样的任务适合真后台，什么不适合
后台并非对所有任务都更优，选错了反而增加风险，这里给一个判断框架。
适合后台的，是目标明确、完成判据清晰、过程可客观验证、且即使中途无人干预也不会造成不可逆后果的任务——比如一份调研报告、一批可回滚的机械改造、跑一套测试。它们放手后你能通过产物确认质量。不适合全自动后台的，是那些需要连续价值判断、会改动重要系统或数据、或中途有大量分叉需要决策的任务——这类一旦偏航代价高，更适合分阶段推进、在关键节点让人回看确认，而不是一口气跑完。
一个稳妥的折中是把「看起来很大」的任务先拆成阶段：其中可判定、低风险的部分用后台跑，高风险或需要判断的节点回到交互式协作。用风险和可验证性、而不是单纯用耗时长短来决定是否后台，你才能把异步用在它真正省力又安全的地方。
六点八、为长任务记账：让花费看得见、停得下
后台任务脱离了即时视野，最容易在成本上失控，因此需要主动「记账」和设上限，而不是跑完才看到账单。
先明确长任务的主要花费来自哪里：反复试错式探索、失败后的整段重跑、以及在卡点上无意义的重试。知道来源，就能针对性设限——为单个阶段的尝试次数、整体运行时长或总 token 预算设定上限，达到阈值就停下来等人看，而不是无限循环。让 Agent 在阶段性产出里顺带报告已用的步骤和大致花费，你回看时成本也一目了然。
关键态度是把「中止」当作正常选项：当一个后台任务明显在空转或代价超出预期，及时停掉、缩小范围、或换成更聚焦的方案，比让它「自己跑出来」更省。低成本验证阶段（小样本、只读）先跑，确认值得再投入全量，也是把钱花在刀刃上的做法。会算账，长任务才不会从「省力」变成「失控」。
六点九、收尾验收：跑了很久不等于可信
最后再强调一次异步协作最容易放松的环节——验收。时间投入容易被误当成质量保证，但它们毫无因果关系。
一份跑了很久的报告，依然可能基于中途已变化的代码或数据、可能在漫长过程中因上下文压缩而偏离了原始目标、也可能在你没盯守时混入了错误。因此收尾动作和交互任务完全一致：对照最初需求逐条核验、读 diff、跑测试、抽样回到原始材料核对，并专门确认结论对应的是当前现实而非旧状态。
你可以在启动时就把「完成判据」写清楚，收尾时逐条勾，避免被一份厚重、完整、却可能失真的产出说服。「它很努力、跑了很久」是情感，不是证据。 守住最后这道客观验收，长任务的价值才算真正落袋，异步带来的自由才不会以牺牲质量为代价。
六点十、把长任务设计成「可随时交付」的形态
最后给一个统领性的设计思想：好的长任务不是一条只能等到终点才有产出的流水线，而是一串随时都能停下来、且每段都有价值的成果。
这意味着拆阶段时就让每段产出独立有用——调研先沉淀一份可读的结论、改造先让一个模块完整可用、测试先覆盖一条关键路径。于是即使中途要暂停、需求变更、或你判断不再继续，已完成的部分依然能被保留和使用，而不是和未完成部分绑在一起作废。配合检查点和滚动状态，你随时能看清进度、随时能收尾。
这种「增量交付」的心态也降低了长任务的心理负担：你不必赌上一大段时间换一个最终结果，而是持续收获确定的小价值。让每个阶段都自成一个可验收的终点，是后台与长任务从「失控风险」变为「稳扎稳打」的根本设计。
七、常见问题
Q：怎么知道后台任务是真在跑、还是卡住了？ 看客观的阶段成果是否在推进、进程与资源状态是否正常；长时间无新产出要警惕挂起，必要时检查日志或从检查点重启。
Q：任务太大，一个后台会话装不下怎么办？ 拆成多个阶段或多个较小的异步任务，各自落地成果，再串联；不要指望单个无限长会话承载一切。
Q：恢复后 Agent 不记得之前的细节？ 靠持续维护的状态摘要和落地文件，而不是它的瞬时记忆；续跑时把这些作为输入显式提供。
Q：长任务值得全自动跑完吗？ 视风险而定。低风险、可验证的可放手；高风险或会改动重要系统的，更适合分阶段、在关键节点让人回看确认。
Q：怎么避免任务在我不看时悄悄跑偏？ 靠启动时写清完成判据、让每阶段把成果落地、并安排周期性回看；中途一旦发现偏离立即介入，而不是等终点才检查。
Q：长任务中途失败，全部重来最省事吗？ 通常最浪费。先判断失败是局部执行问题还是共同前提错误：前者从最近检查点续跑相关部分，后者才需纠正前提整体重派。
八、检查清单
- 长任务已拆成清晰阶段，每阶段有可观察、可恢复的落地产出。
- 任务说明含明确完成判据，避免发散。
- 可随时查看进度与中间成果，并能在偏航时介入。
- 已预设检查点与滚动状态摘要，中断后可从断点续跑。
- 设置了时长/重试/预算上限，能及时中止异常。
- 收尾时确认结果未过期，并按标准验收、跑测试。
总结
后台长任务把人从「必须在场」解放为「异步介入」：启动前先拆好阶段并设计可落地、可恢复的成果，异步运行中通过客观进度周期性回看，中断后凭检查点和滚动状态摘要续跑，并防范上下文漂移、成本失控和结果过期；无论跑多久，收尾仍按统一标准验收——让 Agent 在你不必盯守的情况下，依然可靠地完成大任务。