长程 Agent 任务不跑偏，靠的不是多开几个会话

长程 Agent 稳定交付靠的是前置对齐、外置状态、调度拓扑、验证闭环和漂移复盘。

让 Agent 跑久并不难。难的是跑了一夜以后，主线还在，结果能用，交付物和最初目标仍然对得上。

长程任务最常见的失败，不是 Agent 完全停住，而是它看起来一直很忙：任务列表越来越长，sub-agent 不停工作，reviewer 不断提出意见，测试也跑了很多轮。最后一看，真正能证明完成的产出很少，主线任务早就被边角料拖走了。

这类问题不能靠一句 /goal 做个 xxx 解决。长程 Agent 更像一个小型工程系统：需求要先对齐，状态要外置，执行要有调度拓扑，验证要自动化，复盘要能发现漂移。少任何一环，跑得越久，偏得越远。

长程任务的第一道风险，是一开始就没聊对

很多人把 Spec、Plan Mode、SDD 当成开工按钮。Agent 先生成一份大而全的文档，用户再认真 review。问题是，这些文档往往是给 Agent 消费的，不是给人高效阅读的。用户必须反复看、反复改，几轮下来注意力被文档耗光，真正该放在目标和验收上的精力反而没了。

更稳的方式，是把讨论前置。先用 brainstorming、grill、wayfinder 这类方式把需求聊清楚：到底要解决什么问题，哪些事情不是目标，哪些约束不能破，哪些问题还不确定。等共识已经形成，再让 Agent 把它沉淀成 context、spec 或 issue。此时人只需要扫方向有没有偏，不必逐字审文档。

这一步不是形式主义。长程任务跑偏，常常不是 Agent 执行歪了，而是人和 Agent 一开始就在错误问题上达成了共识。你不知道自己不知道什么，Agent 也不知道；如果没有前置讨论，两边会在错误方向上越跑越自信。

图：长程 Agent 需要主控、任务图和验证闭环一起工作。

Spec 不是越细越好

强模型加上清楚的问题定义，有时一句话就够。模型弱，或者问题本身还含糊，才需要更厚的 Spec 兜底。但 Spec 再长，也救不了一开始的认知盲区。

可以用这个标准判断需要写到多细：

情况	更适合的做法
目标清楚、边界清楚、模型能力足够	写任务契约，保留调整空间
业务约束复杂、风险高	写清硬边界和确认点
流程本身就是规格	保留步骤，例如审计、迁移、发布
需求仍在迷雾里	先 grill / brainstorm / wayfinder，不急着开工
人自己也没想清楚	让 Agent 反问、原型验证、拆出待确认项

前置对齐的产物，后面要交给 Agent 看；人的主要精力要留给验收、纠偏和最终判断。

状态必须从上下文窗口里搬出去

对齐只是第一步。共识如果只留在聊天上下文里，压缩、换会话、开新 Agent 时都会丢。长程任务要让状态外置，让下一个 session、另一个 Agent 能接上。

外置状态可以很轻，也可以很重。小任务用本地 Markdown context 文件就够；multi-session 的大任务，最好拆成有依赖关系的 issue，放进 Kanban 或类似系统里持续跟踪。关键不是工具，而是把“已经对齐的状态”写成 Agent 能消费、能更新、能交接的形态。

图：长程任务需要把目标拆成可追踪的依赖图

这张图表达的是 Graph Engineering 的基本思路：需求不再是一段文字，而是一组带依赖、状态和阻塞关系的节点。串行节点必须等阻塞解除再继续；并行节点可以交给多个 Agent 同时推进。

主控 session 不该亲自下场写代码

状态外置成 issue graph 以后，还需要一个调度层。传统做法是开一个 /goal session 让它从头跑到尾，这能用，但大任务会逐渐把主会话拖进细节里。

更稳的拓扑是主控 session 加 sub-session。主控 session 管整个 graph，只负责拆派、调度、监控和验收。每个 issue 开一个独立 sub-session 去执行，sub-session 内部再编排 worker sub-agent 和 reviewer sub-agent。

图：主控会话负责调度，子会话负责具体执行

这套拓扑比单 session 里的 sub-agent 更容易控制：

差异点	sub-agent 方案	sub-session 方案
生命周期	子任务短，启动后不容易中途干预	每个 issue 是独立会话，可以点进去看和纠偏
上下文	主 Agent 容易下场，被细节污染	主控会话只看进度、证据和交付物
调度位置	通常绑定当前机器和当前会话	可以跨机器、跨 devbox 分派
监控方式	主要等子任务返回结果	主控可以定期检查 rollout、产物和阻塞状态

主控 session 最重要的能力不是会写代码，而是能发现 sub-session 有没有在动、进度和产出是否匹配、是否偷停、是否谎报、是否钻进无关问题。发现停滞或漂移，直接重启、重派或纠偏，不要再叠一个监工 Agent 把系统变得更乱。

验证闭环决定长程任务能不能放手

Agent 写完代码，只完成了需求的一部分。真正耗时的是验证、修 bug、回归和确认交付物。编码效率如果提升 5 到 10 倍，而验证还停在人工时代，长程任务只会更快地产生垃圾。

项目要尽量 AI Friendly：Lint、单测、E2E、调试工具、日志定位、可复现脚本、自动化验收，都应该成为 Agent 能自己调用的 Harness。没有这些反馈回路，就不应该放心让 Agent 长时间无人值守。

一个可放手的任务节点，至少要有四类反馈：

反馈类型	作用
静态检查	快速拦住格式、类型、明显坏味道
单元测试	让局部逻辑有可重复证明
集成 / E2E	验证跨模块行为和真实路径
交付证据	说明完成了什么、跑了什么、还剩什么风险

如果是新功能，尽量按 TDD 或分片开发走。每一片都要能验证，再进入下一片。长程任务不是一口气憋到最后验收，而是每个节点都要留下证据。

不跑偏的核心，是持续对抗目标漂移

长程任务执行多轮后，计划里会混入大量临时决策。历史惯性很容易被当成原始目标。每次继续之前，都应该重新确认这一轮要达到的可交付状态是什么。

对抗 review 要分两类看：

架构和 ROI：有没有过度设计、重复造轮子、无意义地死磕边角料。
目标偏离：做出来的东西是不是原始需求，功能是否完整，证据是否支撑进度。

reviewer 要带着具体问题审，不要泛泛挑刺。让 reviewer 找问题时，它总能找出点东西。真正要处理的是 P0、P1 和高价值 P2；边界提醒和低价值 P3 直接忽略，否则系统会陷入 review-fix loop。

查问题的 Agent 和改问题的 Agent 不能是同一个。fixer 天然会为自己的改动辩护，reviewer 才应该保持对抗性。

怎样才算完成

一个 issue 完成，不能只看 Agent 说跑完了。至少要同时满足两个条件：

该跑的 worker、reviewer 和验证都完成了，结果也被真正采纳。
交付物足以支撑完成声明，包括代码、测试、文档、验证记录或风险说明。

Agent 跑完但结果没被用上，不算完成。交付物撑不住目标，也不算完成。持续烧 token、轮询、重试，却没有新证据和新进展，就是空转。此时应该停下来重排任务，而不是硬耗。

主控 session 最终可以做一次整体验收：把所有 issue 的交付物、rollout、测试证据和剩余风险串起来看。发现缺口，再派新的 sub-session 补，不要在原来的混乱上下文里继续糊。

让另一个 Agent 做复盘教练

复盘不一定等任务结束。单 session 任务可以开一个临时 side session 分析当前 rollout，问它四个问题：

当前进展是否符合原始目标？
有没有偏离主线或沉迷边角问题？
跑偏原因是什么？
接下来怎么补救，下次怎么预防？

multi-session 任务则让主控 session 直接分析 sub-session。它可以读取每个子会话的进度、交付物和 rollout，再给跑偏的会话发纠偏消息。

这种复盘的价值，不是让 Agent 自我表扬，而是把轨迹当成证据。长程任务要控制的是行为序列，不是某一次回答。

最后还是要靠手感

这些流程可以写进 AGENTS.md，也可以做成 Skill 复用。现成实践可以参考：https://github.com/patrick-fu/awesome-skills#-long-task-control

但工具只能降低入门成本，不能替代使用经验。不同模型的长程任务手感不一样：有的模型执行稳，有的模型发散强，有的模型容易自信但不验，有的模型适合做 reviewer。只有持续使用、观察 rollout、复盘失败，才会知道该把任务切多细、何时介入、何时放手、何时停止。

长程 Agent 任务真正需要的，不是更多并行会话，而是一套控制系统：先把需求聊对，把状态外置成可调度图，用主控 session 管生命周期，让每一步都有验证，再用对抗 review 和复盘抓住目标漂移。能做到这些，Agent 才不是跑了一夜，而是真的推进了一夜。

AI小老六