在上一篇，我们了解了 Agent 依靠“思考-执行-观察”的死循环来做事。
这看起来很棒，但如果我们把任务难度拉高，对 Agent 说：“去帮我开发一个带有登录注册功能的博客网站。”

如果 Agent 直接带着这个庞大的目标进入循环，它通常会表现得像一个莽撞的实习生：第一步去建数据库表，第二步去写前端，第三步发现前端连不上数据库，第四步又去改后端配置……最后在无尽的报错中彻底迷失，耗尽 Token 额度然后宣告失败。

人类工程师是怎么做的？我们会先画架构图、排期、分阶段（Sprint）。
同样的，要让 Agent 完成复杂任务，它必须具备**“任务分解（Task Decomposition）”**的能力。

1. 核心概念：为什么必须分解任务？

把大象装进冰箱需要三步，Agent 写代码也一样。任务分解的核心目的是解决以下三大痛点：

1. 降低单步试错成本（最小步进）
   • 如果目标太大，Agent 一次性生成 1000 行代码，只要里面有 1 个拼写错误，这 1000 行代码就全废了。
   • 如果拆成 10 个子任务，每次只写 100 行代码并立刻测试。错了也只需修改这 100 行。这就叫最小步进（Minimum Stepping）。
2. 理清依赖关系（Dependency Graph）
   • 没装依赖包，就没法跑测试；没建好数据库表，就没法写 API 接口。
   • 任务分解能帮 Agent 理清先后顺序，形成一张依赖图（DAG），不会出现“先穿鞋再穿袜子”的尴尬。
3. 优先级与上下文控制
   • 大模型的上下文窗口是有限的。如果 Agent 脑子里一直装着“整个博客系统的宏大构想”，它很容易在写具体代码时分心。
   • 拆解后，Agent 每次只需要聚焦当前这一个小任务，做完一个划掉一个。

2. 怎么拆？从模糊目标到“可执行子任务”

让 Agent 学会拆解任务，通常需要在工程上引入一个专门的 “规划者节点（Planner）”。
它的工作不是干活，而是专门负责把人类的一句话，翻译成一份长长的任务清单。

一个优秀的“可执行子任务”，必须具备三个条件（你可以把它当作给 Agent 下的 KPI）：

1. 边界清晰：必须明确知道这个任务只干什么，绝对不干什么。
2. 具有前置依赖：必须知道做这个任务之前，要先完成哪些事。
3. 有明确的验收标准（DoD, Definition of Done）：怎么才算做完了？不能凭感觉，必须能被工具客观验证（比如“测试脚本运行全绿”）。

3. 本篇产出：Agent 任务分解模板（含验收）

为了让你的 Agent 能像资深项目经理一样拆解任务，你需要在提示词（Prompt）中或者内部的数据结构中，强制它输出以下格式的 JSON 或 Markdown 列表。

当你要求 Agent 开始干活前，先让它（Planner 角色）输出并确认这份清单：

{
  "project_goal": "开发一个带登录注册功能的博客网站后台",
  "sub_tasks": [
    {
      "task_id": "T01",
      "task_name": "项目初始化与依赖安装",
      "description": "使用 npm 初始化 Node.js 项目，安装 express, mongoose 等基础依赖。",
      "dependencies": [], // 没有前置依赖，优先执行
      "acceptance_criteria": [
        "执行 npm run start 不报错",
        "package.json 文件存在且包含指定依赖"
      ],
      "status": "pending"
    },
    {
      "task_id": "T02",
      "task_name": "设计与创建数据库 Schema",
      "description": "编写 User 和 Post 两个模型的文件。",
      "dependencies": ["T01"], // 必须等 T01 跑完
      "acceptance_criteria": [
        "models/User.js 文件被成功创建",
        "使用测试脚本能够成功向本地数据库插入一条 Mock 用户数据"
      ],
      "status": "pending"
    },
    {
      "task_id": "T03",
      "task_name": "编写用户登录/注册 API",
      "description": "实现 /api/register 和 /api/login 接口，包含密码加密逻辑。",
      "dependencies": ["T01", "T02"], // 依赖前两步
      "acceptance_criteria": [
        "使用 curl 或自动测试工具调用 /api/register 能返回 200 及 Token",
        "使用错误密码调用 /api/login 必须返回 401"
      ],
      "status": "pending"
    }
  ]
}

为什么这份模板能救命？

1. 强迫 Agent 思考验收标准（acceptance_criteria）：
   • 注意看 T03，验收标准不是“写完代码”，而是“用 curl 调用返回 200”。
   • 当 Agent（执行者）开始做 T03 时，它的“观察（Observation）”阶段就不再是盲目的，它会一直循环修改代码，直到 curl 命令真的返回 200，它才会把状态改成 completed，并进入下一个任务。
2. 断点续跑的基础：
   • 就算跑到一半系统断网了，重启后，Agent 读一下这份清单，发现 T01 和 T02 的状态是 completed，它就能无缝从 T03 继续往下跑。

总结与复盘

• 面对复杂目标，直接让 Agent 开干是灾难性的。必须先让 Planner（规划者） 介入，完成任务分解。
• 任务分解的三要素：最小步进、依赖关系、客观验收标准（DoD）。
• 这份拆解出的任务清单（Task List），就是 Agent 在自动驾驶时的“高德地图导航路线”。

下一步路线提示：
有了路线图，Agent 就不会迷路了。但是，在执行 T03 时，Agent 需要用到 T02 里定义的数据库结构。
如果 T02 是昨天干完的，今天在干 T03 时，Agent 怎么还能“想起来”昨天写的代码长什么样？
为了解决这个问题，我们必须给大模型装上“内存条”。下一篇，我们将进入：《记忆与上下文管理：短期记忆、长期记忆、检索记忆》。