Agent 工作流设计：从单次对话到多步骤自动化 · Lesson 3 of 6

第 3 课：如何拆解复杂任务为工作流

学习目标：

掌握任务分解的三种策略

识别任务间的依赖关系

将分解结果转化为可执行的工作流

前置要求：第 2 课：工作流的基本组成 | 下一课第 4 课 >>

从"不知道怎么开始"到清晰的步骤

你接到任务："将我们的单体 Rails 应用拆分成微服务架构"。这是个复杂任务。你不知道从哪里开始、有多少步骤、每步做什么。

任务分解(Task Decomposition)就是把这种模糊的大任务，拆解成清晰的小步骤。¹

好的分解有三个标准:

每个子任务足够小，可以在一个 Agent 调用或函数中完成
子任务间的依赖关系明确，知道哪些必须顺序执行、哪些可以并行
子任务的输入输出清晰，上一步的输出能直接作为下一步的输入

分解得好，工作流写起来就像拼乐高。分解得不好，你会在执行时发现步骤遗漏、顺序错乱、数据传不下去。²

策略 1：顺序分解(Sequential Decomposition)

适用场景: 任务有明显的先后顺序，每步依赖前一步的结果。

方法: 从终点倒推，问"这一步需要什么输入？那个输入从哪里来？"

示例：生成技术文档

任务: 为一个 API 生成用户文档

倒推分解:

最终输出: Markdown 文档  ↑ 需要什么？步骤 4: 生成 Markdown(需要：结构化的文档内容)  ↑ 从哪里来？步骤 3: 组织内容(需要：端点列表 + 示例代码 + 说明)  ↑ 从哪里来？步骤 2: 为每个端点生成示例(需要：端点列表)  ↑ 从哪里来？步骤 1: 从代码提取端点列表(需要：源代码)  ↑起点: 源代码目录

最终输出: Markdown 文档  ↑ 需要什么？步骤 4: 生成 Markdown(需要：结构化的文档内容)  ↑ 从哪里来？步骤 3: 组织内容(需要：端点列表 + 示例代码 + 说明)  ↑ 从哪里来？步骤 2: 为每个端点生成示例(需要：端点列表)  ↑ 从哪里来？步骤 1: 从代码提取端点列表(需要：源代码)  ↑起点: 源代码目录

转化为工作流:

JAVASCRIPT

async function generateAPIDocsWorkflow(sourceDir) {
  // 步骤 1: 提取端点
  const endpoints = await extractEndpoints(sourceDir);
  
  // 步骤 2: 生成示例(依赖步骤 1)
  const examples = await Promise.all(
    endpoints.map(ep => generateExample(ep))
  );
  
  // 步骤 3: 组织内容(依赖步骤 1 和 2)
  const content = await agent({
    task: '组织文档结构',
    prompt: '将端点和示例组织成用户友好的文档结构',
    context: { endpoints, examples }
  });
  
  // 步骤 4: 生成 Markdown(依赖步骤 3)
  const markdown = await renderMarkdown(content);
  
  return markdown;
}

依赖链:

步骤 2 可以和步骤 1 并行吗？不能，因为步骤 2 需要步骤 1 的 endpoints。

步骤 3 可以和步骤 2 并行吗？不能，因为步骤 3 需要步骤 2 的 examples。

顺序分解的特点: 依赖链长，并行机会少，但逻辑清晰。³

策略 2：并行分解(Parallel Decomposition)

适用场景: 任务可以拆解为多个独立的子任务，它们不互相依赖。

方法: 识别"对每个 X 做 Y"模式，每个 X 都可以并行处理。

示例：代码库安全审计

任务: 审计 100 个文件的安全问题

并行分解:

JAVASCRIPT

async function securityAuditWorkflow(files) {
  // 阶段 1: 并行审计每个文件(无依赖)
  const audits = await Promise.all(
    files.map(file => auditFile(file))
  );
  
  // 阶段 2: 汇总结果(依赖阶段 1)
  const summary = await agent({
    task: '汇总安全审计',
    prompt: `分析 ${audits.length} 个文件的审计结果，
             按严重性排序问题，生成执行摘要`,
    context: audits
  });
  
  return summary;
}

async function auditFile(file) {
  return await agent({
    task: `审计 ${file.path}`,
    prompt: `检查 SQL 注入、XSS、硬编码密钥、不安全的加密。
             返回 JSON: { file, issues: [{ type, line, severity }] }`
  });
}

结构:

          ┌─→ auditFile(1) ─┐          ├─→ auditFile(2) ─┤files ───→├─→ auditFile(3) ─┼─→ summary          ├─→   ...         ─┤          └─→ auditFile(100)─┘

          ┌─→ auditFile(1) ─┐          ├─→ auditFile(2) ─┤files ───→├─→ auditFile(3) ─┼─→ summary          ├─→   ...         ─┤          └─→ auditFile(100)─┘

扇出-汇总(Fan-out-Reduce)模式: 这是并行分解最常见的模式。⁴

扇出: 将任务分散给多个并行的 Agent
汇总: 将所有结果合并成最终输出

并行分解的威力: 100 个文件，每个审计 2 分钟。顺序执行需要 200 分钟，并行执行只需 2 分钟(假设无资源限制)。

策略 3：混合分解(Hybrid Decomposition)

适用场景: 大部分真实任务。有些部分可以并行，有些部分必须顺序。

方法: 先识别高层阶段(必须顺序执行)，然后在每个阶段内识别并行机会。

示例：大规模代码重构

任务: 将 50 个组件从 Vue 2 升级到 Vue 3

混合分解:

转化为工作流:

JAVASCRIPT

async function vue2to3MigrationWorkflow(components) {
  // 阶段 1: 并行分析所有组件
  const analyses = await Promise.all(
    components.map(c => analyzeComponent(c))
  );
  
  // 阶段 2: 顺序生成迁移计划(依赖阶段 1)
  const plan = await agent({
    task: '生成迁移计划',
    prompt: '基于分析结果，确定迁移顺序和潜在冲突',
    context: analyses
  });
  
  // 阶段 3: 按计划并行迁移组件
  const migrated = await Promise.all(
    plan.batches.map(batch => 
      Promise.all(batch.map(c => migrateComponent(c)))
    )
  );
  
  // 阶段 4: 顺序运行集成测试
  let testResult = await runIntegrationTests();
  
  // 阶段 5: 如果测试失败，修复并重测(循环)
  let attempts = 0;
  while (!testResult.passed && attempts < 3) {
    const failures = testResult.failures;
    await Promise.all(
      failures.map(f => fixComponent(f))
    );
    testResult = await runIntegrationTests();
    attempts++;
  }
  
  if (!testResult.passed) {
    throw new Error('迁移失败，3 次修复尝试均未通过测试');
  }
  
  return { plan, migrated, testResult };
}

混合分解的依赖图:

阶段 1 (并行)           阶段 2 (顺序)analyze(1..50) ────→ generatePlan                              ↓阶段 3 (并行)                 ↓migrate(1..50) ←────────────┘       ↓阶段 4 (顺序)runTests ←─────┐   ↓           │   ├─通过→ 结束 │   └─失败→ 阶段 5 (并行 + 循环)          fix(failures) ─┘

阶段 1 (并行)           阶段 2 (顺序)analyze(1..50) ────→ generatePlan                              ↓阶段 3 (并行)                 ↓migrate(1..50) ←────────────┘       ↓阶段 4 (顺序)runTests ←─────┐   ↓           │   ├─通过→ 结束 │   └─失败→ 阶段 5 (并行 + 循环)          fix(failures) ─┘

混合分解的关键: 在保持必要顺序的同时，最大化并行机会。³

使用 LLM 辅助分解

你也可以让 LLM 帮你做任务分解，零样本提示、链式思考提示、示例引导提示三种方式都行:¹

零样本提示(Zero-Shot)

任务: 将一个包含 100 个 API 端点的 REST API 文档从 Swagger 2.0 升级到 OpenAPI 3.0
请将这个任务分解为 5-8 个清晰的步骤，每个步骤说明:1. 做什么2. 需要什么输入3. 输出什么4. 是否可以并行执行

任务: 将一个包含 100 个 API 端点的 REST API 文档从 Swagger 2.0 升级到 OpenAPI 3.0
请将这个任务分解为 5-8 个清晰的步骤，每个步骤说明:1. 做什么2. 需要什么输入3. 输出什么4. 是否可以并行执行

链式思考提示(Chain-of-Thought)

任务: 重构一个 5000 行的 Python 类，将它拆分成多个小类
让我们一步步思考如何分解这个任务:
第一步应该做什么？为什么？第二步依赖第一步的什么输出？哪些步骤可以并行执行？如何验证每一步都正确完成？
请给出详细的分解方案。

任务: 重构一个 5000 行的 Python 类，将它拆分成多个小类
让我们一步步思考如何分解这个任务:
第一步应该做什么？为什么？第二步依赖第一步的什么输出？哪些步骤可以并行执行？如何验证每一步都正确完成？
请给出详细的分解方案。

示例引导提示(Few-Shot)

我会给你一个复杂任务，请参考示例将它分解为工作流步骤。
示例任务: 批量处理 50 张图片(调整大小、添加水印)示例分解:1. 读取图片列表 (输入: 目录路径, 输出: 文件列表)2. 并行处理每张图片:   2a. 调整大小 (输入: 原图, 输出: 调整后的图)   2b. 添加水印 (输入: 调整后的图, 输出: 最终图)3. 保存结果 (输入: 处理后的图片列表, 输出: 保存路径列表)
现在分解这个任务: 为 20 个 Git 仓库生成贡献者统计报告

我会给你一个复杂任务，请参考示例将它分解为工作流步骤。
示例任务: 批量处理 50 张图片(调整大小、添加水印)示例分解:1. 读取图片列表 (输入: 目录路径, 输出: 文件列表)2. 并行处理每张图片:   2a. 调整大小 (输入: 原图, 输出: 调整后的图)   2b. 添加水印 (输入: 调整后的图, 输出: 最终图)3. 保存结果 (输入: 处理后的图片列表, 输出: 保存路径列表)
现在分解这个任务: 为 20 个 Git 仓库生成贡献者统计报告

LLM 分解的优势: 快速生成初始方案，识别你可能遗漏的步骤。

LLM 分解的劣势: 可能过于抽象(如"分析数据"而不是"计算每个文件的圈复杂度")，需要人工细化。¹

识别依赖关系的实用技巧

技巧 1: 问"这一步能不能在第一步之前做？"

如果答案是"可以"，说明它们可以并行。如果答案是"不行，需要等第一步的结果"，说明有依赖。

技巧 2: 画依赖图

用箭头表示依赖: A → B 表示"B 依赖 A 的输出"
步骤 1 → 步骤 2 → 步骤 4         ↓       步骤 3 ↗

用箭头表示依赖: A → B 表示"B 依赖 A 的输出"
步骤 1 → 步骤 2 → 步骤 4         ↓       步骤 3 ↗

步骤 2 和步骤 3 可以并行吗？可以，它们都只依赖步骤 1。

步骤 3 和步骤 4 可以并行吗？不能，步骤 4 依赖步骤 2。

这种「箭头表示依赖、不会绕回起点」的图有个正式名字，叫 DAG(有向无环图)。步骤 1 不依赖任何其他步骤，是图里最先能跑的叶子节点；把所有步骤按依赖关系排出一条不违反箭头方向的顺序，这个排序方法就叫拓扑排序。

技巧 3: 检查数据流

列出每一步的输入和输出:

步骤	输入	输出
1. 读取文件	文件路径	文件内容
2. 解析代码	文件内容	AST
3. 提取函数	AST	函数列表
4. 生成文档	函数列表	Markdown

如果步骤 X 的输入来自步骤 Y 的输出，X 依赖 Y。

常见分解错误

错误 1: 步骤太大

"准备数据"包括什么？读取文件？解析配置？连接数据库？太模糊了。

✓ 好:1. 读取配置文件2. 连接数据库3. 读取源数据表4. 转换数据格式5. 写入目标数据表6. 运行验证查询

✓ 好:1. 读取配置文件2. 连接数据库3. 读取源数据表4. 转换数据格式5. 写入目标数据表6. 运行验证查询

错误 2: 遗漏错误处理步骤

如果步骤 2 失败怎么办？服务 A 已经部署了，但 B 没有，系统处于不一致状态。

✓ 好:1. 备份当前配置2. 部署服务 A3. 健康检查服务 A4. 如果步骤 3 失败 → 回滚服务 A5. 部署服务 B6. 健康检查服务 B7. 如果步骤 6 失败 → 回滚服务 A 和 B8. 更新负载均衡器

✓ 好:1. 备份当前配置2. 部署服务 A3. 健康检查服务 A4. 如果步骤 3 失败 → 回滚服务 A5. 部署服务 B6. 健康检查服务 B7. 如果步骤 6 失败 → 回滚服务 A 和 B8. 更新负载均衡器

错误 3: 忽视并行机会

❌ 不好(顺序执行):for (const service of services) {  await buildService(service);  await testService(service);  await deployService(service);}

❌ 不好(顺序执行):for (const service of services) {  await buildService(service);  await testService(service);  await deployService(service);}

这会顺序处理每个服务，很慢。

✓ 好(混合并行):// 并行构建所有服务await Promise.all(services.map(s => buildService(s)));
// 并行测试所有服务await Promise.all(services.map(s => testService(s)));
// 并行部署所有服务await Promise.all(services.map(s => deployService(s)));

✓ 好(混合并行):// 并行构建所有服务await Promise.all(services.map(s => buildService(s)));
// 并行测试所有服务await Promise.all(services.map(s => testService(s)));
// 并行部署所有服务await Promise.all(services.map(s => deployService(s)));

下一课: 第 4 课:状态管理和上下文传递 — 学习如何在工作流的步骤间正确传递和管理数据

ApX Machine Learning：LLM 代理任务分解策略 — https://apxml.com/courses/agentic-llm-memory-architectures/chapter-4-complex-planning-tool-integration/task-decomposition-strategies ↩ ↩² ↩³
ACONIC 论文：系统化 LLM 任务分解 — https://arxiv.org/html/2510.07772v1 ↩
OneUpTime：如何创建任务分解 — https://oneuptime.com/blog/post/2026-01-30-task-decomposition/view ↩ ↩²
MindStudio：Claude Code 五大工作流模式 — https://www.mindstudio.ai/blog/claude-code-agentic-workflow-patterns ↩

Exercises

选择下面的任务之一，将它分解为 5-8 个步骤:

Level 1: 分解一个真实任务

任务 A: 为一个 Web 应用生成性能报告(加载时间、资源大小、Core Web Vitals)

任务 B: 清理一个 Git 仓库(删除未使用的依赖、移除废弃代码、更新过时注释)

要求:

每个步骤写清楚：做什么、输入、输出
标注哪些步骤可以并行
画出依赖关系图(用文字或箭头)
说明是顺序、并行还是混合分解

Done criteria · checked locally

步骤数量合理(5-8 个，不是 3 个大步骤也不是 15 个碎片步骤)每个步骤的输入输出明确正确识别并行机会(如任务 A 中加载时间、资源大小、Core Web Vitals 可以并行测量)依赖关系图正确分解策略选择合理

下面是一个"批量 API 端点迁移"任务的分解，有 3 个严重问题。找出这些问题并给出修正方案。

Level 2: 修复错误的分解

要求:

找出 3 个问题(提示: 步骤太大、遗漏错误处理、忽视并行机会)
给出修正后的完整分解(5-8 步)

Done criteria · checked locally

正确识别 3 个关键问题(步骤 2 太模糊没说明如何生成、缺少测试和验证步骤、没有回滚机制、没有并行处理多个端点)修正方案包含至少 6 个步骤包含测试/验证步骤包含错误处理或回滚步骤识别并行机会

My note

Jot down thoughts, sticking points, things you didn't get. Written to this course's appendix only — the lesson file is never touched.

Also distill into learning memory (so the agent knows me next time)

第 3 课：如何拆解复杂任务为工作流

从"不知道怎么开始"到清晰的步骤

策略 1：顺序分解(Sequential Decomposition)

示例：生成技术文档

策略 2：并行分解(Parallel Decomposition)

示例：代码库安全审计

策略 3：混合分解(Hybrid Decomposition)

示例：大规模代码重构

使用 LLM 辅助分解

零样本提示(Zero-Shot)

链式思考提示(Chain-of-Thought)

示例引导提示(Few-Shot)

识别依赖关系的实用技巧

常见分解错误

Footnotes

Exercises

选择下面的任务之一，将它分解为 5-8 个步骤:

下面是一个"批量 API 端点迁移"任务的分解，有 3 个严重问题。找出这些问题并给出修正方案。

My note