让 Coding Agent 开发一套 JWT 用户认证：分析项目、设计库表、写接口、实现 Token 签发与校验、跑测试。执行到一半它突然宣布"任务完成"——中间有一步被它静默跳过了。这不是模型能力问题，而是长任务的通病：上下文不断膨胀，早期指令的权重被稀释，步骤遗漏和重复执行随之而来。人类靠飞行检查单和 TODO List 对抗同类问题，Agent 也一样——它需要一套显式的任务清单机制。
清单的三种状态与三个好处
最简形态下，每个任务只有三个状态：pending 等待、in_progress 执行中、completed 完成。Agent 每做完一步就更新状态，再照着清单决定下一步。收益有三层：防遗漏（完成与否有据可查）、进度可视化（用户随时知道执行到哪）、可编排（依赖顺序和协作关系有了承载物）。
清单不保证 Agent 不犯错，它只是把犯错从"静默丢失"变成"可追踪的偏差"——这已经是质的改善。
从便利贴到任务系统
以 Claude Code 的演进为例能看清两代设计。早期的 TodoWrite 是便利贴式方案：面向单次会话、扁平列表、不支持显式依赖，更新时提交全量清单。修个 Bug 这种四五步、无依赖、单角色的任务，便利贴足够了。
任务一旦要跨会话续作，或涉及多 Agent 并行，便利贴就不够了。后来的 Task 系统给了四个工具：创建任务、查详情、更新状态与依赖、列清单。三个关键升级：任务数据持久化到磁盘，不依赖对话上下文存活；支持依赖关系，前置任务完成前后续任务不可认领；支持多协作者认领与状态流转，为团队协作打了地基。
其他工具的同构实现
这套机制不是 Claude Code 独有，各家编程 Agent 都演化出了同构物：Codex CLI 用 update_plan 维护带状态的步骤计划，Cursor 在计划模式下先产出可确认的任务拆解再执行。互通的一点是"计划先行、确认后动"——复杂任务的清单会先交给用户过目，确认了才开工。选工具时不必纠结名称差异，看两点就够：状态是否落盘（能否跨会话恢复）、依赖是否显式（能否多角色并行）。
清单自身的坑
任务清单用不好，反而会成为新的故障源，三个实操教训值得记住。
其一，粒度失控。拆出二三十个条目的清单，维护成本超过收益，模型在频繁的全量更新里也会注意力稀释。经验值是控制在五到十个条目，每个条目对应一次可验收的交付。
其二，依赖链设深了会自我阻塞。A 挡 B、B 挡 C 的长链条里，任何一环失败整条链停摆。无依赖关系的步骤就该并行放开，依赖只标真正的前置约束。
其三，全量更新撞并发。便利贴式的全量提交在多 Agent 同时改清单时会互相覆盖，共享清单必须走原子化的单项更新——这正是 Task 系统按工具拆分的原因之一。
恢复会话后的核对动作
跨会话续作时，清单状态与磁盘实际可能不一致：会话中断在半步，状态还停在 in_progress，文件却只改了一半。恢复后的标准动作是先核对再继续：拉一遍清单，对每条 in_progress 的任务用 git diff 或文件检查确认实际进度，把状态修正到与现实一致，再决定从哪一步接着跑。跳过这个核对，Agent 会把清单当作事实，在错误的基础上继续执行。
任务清单机制的本质，是给概率性的执行过程加一层确定性的账本。清单本身很简单，真正值钱的是它带来的两个性质：步骤可追踪、状态可恢复——长任务的可靠性，就是从这两点开始建立起来的。
评论0