8 月 3 日阿里发布 Qwen3.8-Max 时，最出圈的不是 2.4 万亿参数，而是一个实验：模型从一个空文件夹出发，无人干预地连续编码 16 天，产出 265 次提交、127 个 PR，交付了一个完整项目。Anthropic 去年底的工程博客也把"长程 Agent 的脚手架（harness）"列为核心议题——行业共识已经很清楚：模型能力不再是瓶颈，会不会驾驭长任务才是普通用户和团队的真实差距。
但大多数人的日常体验是：让 AI 改个大需求，前二十分钟惊艳，半小时后开始重复劳动、改坏之前写好的代码，一小时后彻底跑偏。问题不在模型，在于我们还在用"聊一句话"的方式驱动一个需要"项目管理"的工人。这篇文章把长任务跑偏的根因拆开，给一套今天就能用的打法。
一、为什么会跑偏：三个根因
先诊断，再开药。长任务失败几乎都能归到这三类：
- 上下文漂移（Context Drift）。Agent 的上下文窗口是有限的，跑着跑着早期信息被挤出或压缩，它忘了最初的目标和约束，开始"自由发挥"。这是长任务的第一杀手。
- 目标不可验证。你说"把性能优化一下"，Agent 没有判断"做完没有"的标准，只能无限改下去，或者改了两行就宣布胜利。
- 没有中间产物。两小时的工作全在 Agent 的"脑子"（上下文）里，一旦跑偏或会话中断，一切归零，只能从头再来。
对应的解法也正好是三件事：把状态写到磁盘、把目标变成验收命令、把大任务切成可独立验证的小块。下面逐个说。
二、任务拆解：把"一句话需求"变成任务卡
长任务的第一步不是打开终端，而是花十分钟写一份任务说明。推荐直接在仓库里建一个文件，比如 TASK.md：
# 任务：给订单模块加退款流程
## 目标
用户可在订单页对已支付订单发起退款，状态机覆盖：申请→审核→原路退回。
## 验收标准（全部通过才算完成）
- `npm test -- refund` 全绿
- `npm run build` 无错误
- 手动路径：创建订单→支付→申请退款→状态流转正确
## 约束
- 不改 users 表结构
- 新代码必须带测试
- 提交粒度：每个子任务一个 commit
## 子任务
1. [ ] 设计 refunds 表并写 migration
2. [ ] 退款申请 API + 状态机
3. [ ] 审核接口（管理员侧）
4. [ ] 前端订单页入口与状态展示
三个要点：
- 验收标准必须是命令或可观察的行为，不能是形容词。"测试全绿"可以验证，"代码优雅"不行。
- 约束清单比目标描述更重要。Agent 跑偏时往往不是不会做，而是做了你不让它做的事——顺手重构了无关模块、升级了依赖、改了别处的 API。
- 子任务的粒度是"一次能验证完"。每个子任务都应该小到：做完就能跑一遍验收，确认了再往下走。
三、进度日志：给 Agent 一个"外置大脑"
对抗上下文漂移最有效的手段，是让 Agent 把状态持久化到文件里，而不是依赖它自己的记忆。做法是在任务说明里加一条规则：
每完成一个子任务，把进展追加到
PROGRESS.md：做了什么、改了哪些文件、下一步是什么、有什么坑。
这样即使上下文被压缩、会话重启，甚至你换了一个模型接着干，新的会话读一遍 TASK.md + PROGRESS.md 就能无缝接上。Anthropic 提到的 compaction（上下文压缩）机制本质上也在做同样的事——但你自己维护的日志比自动压缩可靠得多，因为写什么是你定义的，不是模型临场总结的。
进阶一点的做法是在日志里固定四个字段：
- Done：已完成的子任务及对应的 commit hash
- Now：当前正在做的子任务
- Next：按顺序的后续步骤
- Gotchas：踩过的坑（比如"这个测试在 CI 上需要环境变量 X"）
Gotchas 这一段价值最高——Agent 在长任务里反复踩同一个坑是常态，写下来它就只看一次。
四、验收门禁：每一步都要过闸门
长任务最大的浪费是：第三步改坏了第一步的成果，到第六步才被发现，回退成本巨大。解法是每个子任务完成后立即跑验收，不过就修，过了才继续。
实操上就是给 Agent 明确的工作循环：
对每个子任务：
1. 实现
2. 跑 npm test 和 lint，失败则修复（最多重试 3 次）
3. 通过 → git commit → 更新 PROGRESS.md → 划掉子任务
4. 连续 3 次修不好 → 停下来，在 PROGRESS.md 记录问题，等待人工
注意第 4 条：要给 Agent 一个"认输"的出口。没有这条规则，它会陷入"越修越坏"的死循环——这是长任务跑偏最常见的死法。停下来把问题写清楚，人类花两分钟看一眼，比让它硬撑两小时强得多。
另外推荐把 git 用起来当安全网：开始前打一个新分支，每个子任务一个 commit。真跑偏了，git log 一看就知道从哪一步开始坏的，回退到任意检查点重跑。
五、常见误区与注意事项
- 不要一上来就让它跑通宵。先拿"一小时能完成"的任务练流程，确认你的 TASK.md 写法和验收命令都顺了，再逐步拉长。Qwen3.8-Max 那种 16 天的实验背后是一套自研的 Harness 框架，不是裸模型直接跑。
- 长任务的成本会非线性放大。一次长程任务可能是几十万次 token 消耗，跑之前想清楚这个任务值不值，顺手在工具里设好用量提醒。
- 权限收敛。给 Agent 的终端权限按最小化原则：能跑测试和构建即可，数据库写操作、部署命令这类高危动作留在人手里，或者至少要求它执行前停下来确认。
- 别让多个 Agent 无协调地改同一个仓库。如果并行跑多个任务，按目录或模块切分边界，各跑各的分支，合并由人来做。
- 日志文件要记得 gitignore 或定期清理，PROGRESS.md 这类过程产物不一定要进主干历史。
小结
长程 Agent 的时代已经来了——头部模型证明了"连续工作十几天"技术上可行，但这不等于你把一句话丢给它就能得到同样的结果。普通用户能抓住的红利是这套朴素的方法论：任务写清楚、状态落磁盘、每步过验收、允许它认输。四件事都不需要等新模型，今天打开 Claude Code 就能试。先从一个一小时的任务开始，把流程跑顺，你会明显感到 AI 从"聊两句很惊艳"变成了"真的能交付"。