任务系统：Agent 的行动蓝图

本章摘要：

计划让复杂任务显式可追踪。复杂任务先进入 Plan Mode 只读思考，让方向在零成本阶段就确认下来——避免动手后才发现错误。任务卡片显式声明"做什么、为什么做、依赖什么"，让进度可追踪。完成 ≠ 达成，最后要回到原始目标验证。

Agent Loop、工具系统、技能系统分别提供循环机制、执行能力和领域知识。计划与任务系统提供长步骤任务的拆解、排序、追踪和验证能力。

普通聊天的上下文是线性的，但现实任务可能是并行的、有依赖的。计划系统在这两者之间架桥。

为什么 Agent 需要计划

复杂任务包含多个有依赖关系的步骤。以一个常见的工程任务为例——把项目的 Python 版本从 2 升级到 3：

任务：把项目从 Python 2 升级到 3

步骤 1：升级构建配置中的 Python 版本
步骤 2：修复 print 语句语法              ← 依赖 1
步骤 3：更新第三方库到兼容版本            ← 依赖 1
步骤 4：替换已废弃的标准库调用            ← 依赖 2、3
步骤 5：全量回归测试                      ← 依赖 4

这个例子不是讲 Python 升级的细节，而是讲"为什么需要计划"——你能看到步骤之间是有依赖的，乱序会导致返工。

没有计划系统时，Agent 靠上下文记忆推进。上下文有限且会被新内容冲掉，步骤之间的依赖关系容易丢失。

计划系统则把进度变成显式清单，解决四个问题：

没有计划	有计划
大目标模糊，易遗漏	拆解：每步都是可执行小任务
依赖隐式，易搞错顺序	排序：依赖显式，顺序清晰
需翻对话历史	追踪：任务看板实时反映进度
完成 ≠ 达成	验证：每步后对照原始目标检查

计划的制定：Plan Mode

面对复杂任务，Agent 先进入计划模式（Plan Mode），核心约束是只读不写——搜索代码、阅读文件、理解架构、设计方案，但不执行修改。

   用户提出复杂任务
          │
          ▼
┌───────────────────┐
│ Plan Mode（只读） │
│                   │
│ 搜索代码          │
│ 理解架构          │
│ 设计方案          │
│ 列出实现步骤      │
│ 标注依赖关系      │
└─────────┬─────────┘
          │
          ▼
     人类审查计划
      ┌───┴───┐
      │       │
     通过    修改
      │       │
      ▼       │
┌──────────────────┐
│     执行阶段     │
│     (读、写)     │
└──────────────────┘

Plan Mode 分离理解和行动，在零成本阶段确认方向，避免动手后才发现方向错误的代价。

计划的产出是一份任务列表——每个任务标注做什么、为什么做、有什么前置条件。

任务的载体：任务卡片

计划不能悬浮在空中。框架在会话中维护一组任务卡片，每张卡片记录三件事：

• 做什么（subject）：简短标题
• 为什么做（description）：背景、要求
• 前置条件（blockedBy）：必须先完成的任务

任务有三种状态：未开始（pending）、执行中（in_progress）、已完成（completed）。任务管理在会话中提供四类工具：

• 创建任务（将计划步骤变为显式条目）
• 追踪状态（记录每步当前进展）
• 管理依赖（声明谁先谁后）
• 提供进度可见性（实时反映整体完成情况）。

任务卡片的另一层价值是工作锚点。在长对话中，模型的"记忆"会变得模糊，但任务列表始终能锚定当前的进度——即使上下文滚动、压缩、丢失，任务列表仍然是"我们在做哪几件事"的可靠参考。

任务的依赖与看板

任务通过依赖关系显式声明顺序。依赖是执行时的硬性约束——未完成时不会执行后续任务。

任务看板对人类是透明的（知道 Agent 在做什么），对 Agent 自己是防遗漏的安全网（不会因为上下文滚动就忘记下一步该做什么）。

从计划到执行：工作循环

计划系统把 Agent 的工作流拆成三步循环：

1. 查看看板：哪些任务还没做、哪些依赖已解决
2. 领取任务：选择当前可做的任务，标记为执行中
3. 执行并标记完成：调用工具完成任务，确认成果后标记为已完成

回到第 1 步继续，直到所有任务完成。

这套循环和"软件开发里的看板方法"几乎一样——只是 Agent 是执行者。

验证：完成不等于达成

所有任务完成后，必须回到原始目标验证——这是计划系统最重要的设计之一。任务列表只保证"每步做完了"，但完成 ≠ 达成：

• 完成是说"代码改完了"
• 达成是说"用户要的东西真做对了"

验证一般分三层：

1. 自动化层：运行测试、类型检查、代码风格检查
2. 功能性层：启动应用，实际操作核心流程
3. 目标层：回到用户原始请求，逐条核对

验证不通过时，相关任务重新打开，修复后再验证。没有"完成"状态可以一锤定音——验证是计划系统的最后一关。

本章要点

• 计划让模糊目标变显式：拆解 + 依赖 + 追踪 + 验证
• Plan Mode 是只读思考阶段：分离"理解"和"行动"
• 任务卡片是工作锚点：在长对话中保持进度可见
• 完成 ≠ 达成：所有任务完成后必须回到原始目标验证
• 计划系统的核心价值不是"列任务清单"，而是让复杂任务在长上下文中仍可推进