Agent 工作流设计：从单次对话到多步骤自动化 · 第 1 / 6 节

第 1 课：从单次对话到工作流：为什么需要编排

学习目标：

理解单次对话和工作流的本质区别

识别适合工作流的任务特征

了解工作流编排的核心价值

前置要求：使用过 Claude Code 或类似 AI 工具 | 下一课第 2 课 >>

你的 Agent 遇到了瓶颈

你让 Claude Code 重构一个大型代码库:"帮我把这个 5000 行的单体应用拆分成微服务架构。"

Claude 开始分析。它读取文件、识别模块边界、提取依赖关系……然后在第 47 个文件时，上下文窗口满了。它忘记了前面做过什么，重新开始，陷入循环。¹

或者你要求它"审查所有 PR 并生成本周的发布说明"。Claude 一次只能处理一个 PR,你得手动运行 20 次，每次都要重新解释格式要求。

这就是单次对话的极限:一个对话、一个上下文窗口、一条推理链。对于复杂任务，这个模式会崩溃。²

什么是工作流

工作流是一个可执行的脚本，它把复杂任务拆解成多个步骤，每个步骤委托给一个新的代理，由脚本负责协调。³

关键区别:

维度	单次对话	工作流
控制流	Agent 决定下一步做什么	脚本决定下一步做什么
上下文	所有历史都在一个窗口里	每个步骤有独立的上下文
并行	顺序执行	可以并行启动多个代理
可重复性	每次可能不同	脚本固定，执行确定
适用规模	小任务(几个文件)	大任务(数百个文件、多个验证阶段)

举个例子，重构工作流的脚本可能是:

JAVASCRIPT

// 伪代码示例
async function refactorWorkflow(codebase) {
  // 步骤 1: 并行分析所有模块
  const modules = await Promise.all(
    codebase.files.map(file => 
      agent({ task: `分析 ${file} 的职责和依赖` })
    )
  );
  
  // 步骤 2: 生成微服务边界方案
  const plan = await agent({ 
    task: '基于分析结果设计微服务边界',
    context: modules 
  });
  
  // 步骤 3: 并行提取每个服务
  const services = await Promise.all(
    plan.services.map(svc => 
      agent({ task: `提取 ${svc.name} 服务的代码` })
    )
  );
  
  // 步骤 4: 验证所有服务的测试通过
  return await agent({ 
    task: '运行所有服务的测试套件',
    context: services 
  });
}

这个脚本持有循环、分支和中间结果，Claude 的上下文只看到最终答案。编排是确定性的，只有每个步骤内的工作由模型驱动。³

工作流适合什么场景

适合工作流的任务有四个特征:

需要协调的代理数量超过一次对话能管理的:一个对话可以管理 3-5 个子代理，超过这个数量需要工作流
希望编排逻辑固化为可读、可重用的脚本:写一次，随时重跑
任务可以拆解为清晰的阶段:分析 → 规划 → 实施 → 验证
需要并行执行或交叉验证:多个独立子任务、对抗验证、锦标赛模式²

典型场景:

代码库审计:扫描 500 个文件，每个文件一个代理检查安全问题，汇总结果
大规模迁移:将 200 个组件从 Vue 2 升级到 Vue 3,并行处理，最后验证集成
交叉验证研究:同一问题让 5 个代理独立研究，交叉验证事实，生成一致性报告
多角度方案评估:从架构、性能、成本三个角度独立评估设计方案，再合并²

不适合工作流的场景:

简单的单文件编辑或代码审查(直接对话就够了)
创意写作、头脑风暴这种开放式任务
需要很多人工判断、无法形式化为步骤的任务

工作流的演进历史

工作流不是凭空出现的，它是 Claude Code 编排能力的第四个阶段:¹

阶段 1: 单体代理

┌─────────┐│ Claude  │  一个上下文窗口做所有事:└─────────┘  读取、规划、编辑、测试

┌─────────┐│ Claude  │  一个上下文窗口做所有事:└─────────┘  读取、规划、编辑、测试

阶段 2: 子代理扇出(Agent 工具)

┌─────────┐│ Claude  │──→ agent: "搜索代码库"│ (main)  │──→ agent: "读取这 40 个文件"└─────────┘  结果返回给父代理

┌─────────┐│ Claude  │──→ agent: "搜索代码库"│ (main)  │──→ agent: "读取这 40 个文件"└─────────┘  结果返回给父代理

阶段 3: 代理团队

┌─────────┐    ┌─────────┐    ┌─────────┐│ Planner │───→│ Coder   │───→│ Tester  │└─────────┘    └─────────┘    └─────────┘     每个代理保持自己的角色和上下文

┌─────────┐    ┌─────────┐    ┌─────────┐│ Planner │───→│ Coder   │───→│ Tester  │└─────────┘    └─────────┘    └─────────┘     每个代理保持自己的角色和上下文

阶段 4: 工作流编排

    ┌─────────────────┐    │ Workflow Script │  持有循环、分支、状态    └────────┬────────┘         ┌───┴───┬───────┬───────┐         ↓       ↓       ↓       ↓    agent()  agent() agent() agent()    每个调用启动独立的子代理

    ┌─────────────────┐    │ Workflow Script │  持有循环、分支、状态    └────────┬────────┘         ┌───┴───┬───────┬───────┐         ↓       ↓       ↓       ↓    agent()  agent() agent() agent()    每个调用启动独立的子代理

工作流的核心创新是控制流反转:不是让 Agent 决定"接下来做什么",而是让脚本决定"接下来调用哪个 Agent"。³

编排的本质

编排(Orchestration)就是字面意思:一个乐谱，多个音乐家。¹

在工作流中:

乐谱 = 你写的 JavaScript/TypeScript 脚本，包含 for 循环、if 语句、Promise.all
音乐家 = 每个 agent() 调用启动的子代理
指挥 = 脚本的执行引擎，按照乐谱协调代理

一个普通的 Agent 在运行时即兴决定控制流:"先做 A,然后看情况决定做 B 还是 C"。

一个工作流把控制流写死在脚本里:"先并行做 A1-A10,全部完成后做 B,如果 B 返回的 score > 0.8 就做 C,否则做 D"。

确定性编排的好处:

可预测:同样的输入，执行路径相同
可调试:哪个步骤出错一目了然
可重跑:脚本存在 .claude/workflows/,可以按名字调用
可扩展:从 10 个代理扩展到 100 个代理，只需改循环次数³

第一个工作流场景:代码审查管道

让我们看一个真实场景。你的团队有 15 个待审查的 PR,每个 PR 需要检查:

代码风格是否符合规范
是否有明显的 bug
测试覆盖率是否足够
是否更新了相关文档

用单次对话，你得运行 15 次，每次手动切换 PR。

用工作流:

JAVASCRIPT

async function reviewPRsWorkflow(prList) {
  // 阶段 1: 并行审查所有 PR
  const reviews = await Promise.all(
    prList.map(pr => 
      agent({
        task: `审查 PR #${pr.number}`,
        prompt: `检查代码风格、潜在 bug、测试和文档。
                 输出 JSON: { style: score, bugs: [], 
                 coverage: number, docs: boolean }`
      })
    )
  );
  
  // 阶段 2: 汇总报告
  return await agent({
    task: '生成周报',
    prompt: `基于 ${reviews.length} 个 PR 的审查结果,
             生成本周的代码质量报告,
             按严重性排序问题`
  });
}

这个工作流的价值:

15 个 PR 并行审查，比顺序快 15 倍
审查标准一致(都用同一个 prompt)
可以每周自动运行，无需人工干预
脚本可以提交到 Git,团队共享

下一课: 第 2 课:工作流的基本组成 — 学习工作流的构建块:步骤、状态、分支和循环

ClaudeWorld：什么是工作流？多代理编排详解 — https://claude-world.com/articles/what-is-a-workflow-multi-agent-orchestration/ ↩ ↩² ↩³
Claude Code 官方文档：工作流编排 — https://code.claude.com/docs/en/workflows ↩ ↩² ↩³
Alex Op：Claude Code 工作流确定性多代理编排 — https://alexop.dev/posts/claude-code-workflows-deterministic-orchestration/ ↩ ↩² ↩³ ↩⁴

练习

回顾你最近一周的工作，找出一个重复性任务，判断它是否适合工作流:

Level 1: 识别你的第一个工作流场景

判断标准:

需要处理多个相似的输入(多个文件、多个数据源、多个服务)
有清晰的阶段划分(提取 → 转换 → 验证 → 输出)
希望每次执行的流程一致
可以部分或全部并行执行

写下来:

任务描述(一句话)
当前怎么做的
如果用工作流，会分成哪几个阶段
预期节省多少时间

完成标准 · 本地勾选

场景描述清晰、阶段划分合理(3-5 个阶段)、能说明并行执行的机会、时间估算有依据(如"现在顺序处理 10 个文件需 30 分钟，并行预期 5 分钟")

选择这两个场景中的一个，说明为什么一个适合单次对话，另一个适合工作流:

Level 2: 对比单次对话和工作流

场景 A: 修复一个函数的 bug,函数有 50 行代码，逻辑清晰

场景 B: 将一个包含 30 个组件的 UI 库从 Material-UI v4 升级到 v5

写出你的判断和理由(每个场景 2-3 句话)。

完成标准 · 本地勾选

准确识别场景 A 适合单次对话(任务小、上下文可控、无需并行)、场景 B 适合工作流(规模大、可拆解、可并行)能解释"为什么"而不只是重复定义能提到工作流的具体优势(如并行、一致性、可重复)

第 1 课：从单次对话到工作流：为什么需要编排

你的 Agent 遇到了瓶颈

什么是工作流

工作流适合什么场景

工作流的演进历史

编排的本质

第一个工作流场景:代码审查管道

Footnotes

练习

回顾你最近一周的工作，找出一个重复性任务，判断它是否适合工作流:

选择这两个场景中的一个，说明为什么一个适合单次对话，另一个适合工作流: