AI Agent 工作流编排：用 Subagent 实现复杂任务分解

用户283167347466
3 阅读8分钟

AI实战丨AI Agent 工作流编排：用 Subagent 实现复杂任务分解

AI有招 · AI实战 #50

以下内容可以直接转给你的 AI 伙伴阅读。这篇讲的是：当一个任务复杂到单次对话搞不定时，如何用 subagent 模式把大任务拆成多个子任务并行执行，以及我们在实践中踩过的坑。

问题：单 Agent 的天花板

用 AI Agent 干活一段时间后，你一定遇到过这种情况：

你：帮我把这 5 个 GitHub Issue 都修了，提 PR
AI：好的，我来看看第一个...
（20 分钟后）
AI：第一个修好了，开始看第二个...
（又 20 分钟）
AI：第二个有点复杂，我需要...
（context window 爆了，前面的记忆开始丢失）

单 Agent 模式下，所有任务共享同一个上下文窗口。任务越多，上下文越长，模型的注意力越分散，质量越差。更要命的是——它是串行的。5 个独立的 Issue，一个接一个做，效率拉满也要一两个小时。

这不是 AI 不够聪明的问题，是架构���问题。

方案：Subagent——给 AI 装上"项目经理"模式

解决思路其实很朴素：既然一个人干不完，那就分工。

主 Agent 负责拆解任务、分配工作、汇总结果；子 Agent（subagent）各自领一块独立任务，互不干扰。每个 subagent 有自己独立的上下文窗口，专注做一件事。

┌─────────────┐
│  主 Agent    │ ← 接收用户指令，拆解任务
│ (Orchestrator) │
└──────┬──────┘
       │ spawn
  ┌────┼────┐
  ▼    ▼    ▼
┌───┐┌───┐┌───┐
│SA1││SA2││SA3│  ← 各自独立执行
└───┘└───┘└───┘
  │    │    │
  └────┼────┘
       ▼
   汇总结果

在 OpenClaw 中，这个机制叫 subagent。主 Agent 可以动态生成子 Agent，每个子 Agent 有独立的会话、独立的工具权限、独立的上下文。子 Agent 完成后，结果自动推送回主 Agent。

实现：三种典型的工作流模式

模式一：并行独立任务

最简单的场景——多个任务之间没有依赖关系，可以完全并行。

典型用例： 批量修 Issue、多平台发布、多文件翻译

# OpenClaw CLI 中的 subagent 调用
openclaw agent spawn \
  --label "fix-issue-42" \
  --task "修复 GitHub Issue #42: 登录页面 CSS 错位" \
  --model "claude-sonnet-4-20250514"

openclaw agent spawn \
  --label "fix-issue-43" \
  --task "修复 GitHub Issue #43: API 返回值缺少分页字段" \
  --model "claude-sonnet-4-20250514"

openclaw agent spawn \
  --label "fix-issue-44" \
  --task "修复 GitHub Issue #44: 搜索结果排序不正确" \
  --model "claude-sonnet-4-20250514"

三个 subagent 同时启动，各修各的 bug。主 Agent 不用等，继续干别的事。每�� subagent 完成后，结果自动回传。

在 Agent 对话中，主 Agent 也可以通过工具调用直接 spawn：

主 Agent: 我来把这三个 Issue 分给子任务处理
→ spawn subagent "fix-issue-42" (独立上下文)
→ spawn subagent "fix-issue-43" (独立上下文)  
→ spawn subagent "fix-issue-44" (独立上下文)
→ 等待结果自动回传，汇总给用户

关键点： 不需要轮询子 Agent 状态。OpenClaw 的 subagent 是 push-based 的——完成后自动通知主 Agent。主 Agent 收到通知后再汇总。

模式二：流水线（Pipeline）

任务之间有顺序依赖，前一步的输出是后一步的输入。

典型用例： 写文章（调研 → 写作 → 排版 → 审核）

主 Agent:
  1. spawn "researcher" → 调研竞品数据，输出 research.md
  2. 等 researcher 完成
  3. spawn "writer" → 基于 research.md 写初稿
  4. 等 writer 完成  
  5. spawn "reviewer" → 审核初稿，检查敏感信息

这看起来还是串行的？没错，但好处是：

  • 每步都有独立上下文：writer 不需要背着 researcher 的全部调研过程，只需要最终的 research.md
  • 每步可以用不同模型：调研用便宜的 Sonnet，写作用强的 Opus，审核用 Haiku 就够了
  • 失败可以单步重试：writer 写得不好？重新 spawn 一个 writer，不用从调研重来

模式三：分治汇总（Map-Reduce）

先把大任务拆成小块并行处理，再把结果合并。

典型用例： 分析大型代码库、多文件日志分析、大文档翻译

主 Agent 的思路：
  "用户要分析 10 个日志文件的异常"
  
  Phase 1 (Map): 并行 spawn 10 个 subagent，每个分析一个文件
  → subagent-log-1: 分析 app-2026-03-01.log
  → subagent-log-2: 分析 app-2026-03-02.log
  → ... 
  → subagent-log-10: 分析 app-2026-03-10.log
  
  Phase 2 (Reduce): 收集所有子结果，合并分析
  → "10 个文件中，3 月 5 日和 3 月 8 日有异常峰值..."

实战案例：自动修 Issue 并提 PR

来看一个我们实际在用的工作流。用户说一句 /gh-issues owner/repo --limit 5，系统自动：

  1. 拉取 5 个 Issue
  2. 为每个 Issue spawn 一个 subagent
  3. 每个 subagent 独立：分析问题 → 写修复代码 → 跑测试 → 提 PR
  4. 结果汇总回主 Agent

这里面的 subagent 任务描述大概长这样：

你是一个代码修复 Agent。

## 任务
修复 GitHub Issue #42: "登录页面在移动端 CSS 错位"

## 仓库信息
- 仓库: owner/repo
- 分支: main
- 语言: TypeScript + React

## 工作流程
1. 用 gh 克隆仓库并创建修复分支
2. 分析 Issue 描述，定位问题文件
3. 编写修复代码
4. 运行现有测试确认不破坏功能
5. 提交并创建 PR，PR 描述中关联 Issue

## 约束
- 只修改必要的文件
- 遵循项目已有的代码风格
- PR 标题格式: fix: 简短描述 (#42)

每个 subagent 拿到的是一个完整、独立、自包含的任务描述。它不需要知道还有其他 subagent 在并行工作，也不需要知道主 Agent 的全局视图。

踩坑记录

坑 1：Subagent 之间的资源冲突

三个 subagent 同时修同一个仓库的不同 Issue，如果它们都 checkout 到同一个本地目录——

subagent-1: git checkout -b fix/issue-42
subagent-2: git checkout -b fix/issue-43  ← 覆盖了 subagent-1 的工作区！

解法： 每个 subagent 用独立的工作目录。

# 每个 subagent 在独立目录下工作
WORKDIR="/tmp/agent-work/issue-${ISSUE_ID}"
mkdir -p "$WORKDIR"
cd "$WORKDIR"
git clone https://github.com/owner/repo.git .

坑 2：轮询风暴

早期我们犯过一个错误——主 Agent 不停地问"子任务完成了吗？"

主 Agent: 检查 subagent-1 状态... 未完成
(5 秒后)
主 Agent: 检查 subagent-1 状态... 未完成
(5 秒后)
主 Agent: 检查 subagent-1 状态... 未完成

这不仅浪费 token，还占用了主 Agent 的上下文空间。

解法： Push-based 模式。OpenClaw 的 subagent 完成后会自动把结果推送回来，主 Agent 不需要轮询。在 subagent context 中有一条规则：

Trust push-based completion — Descendant results are auto-announced 
back to you; do not busy-poll for status.

如果你自己实现类似系统，可以用 webhook、消息队列或文件系统监听来实现 push 通知。

坑 3：子任务描述不够自包含

一开始我们给 subagent 的任务描述太简略：

"修复 Issue #42"

subagent 不知道仓库在哪、用什么语言、有什么约束，只能自己猜。猜对了还好，猜错了就白干。

解法： 任务描述要自包含——把 subagent 需要的所有上下文都打包进去。宁可多写几行描述，也不要让 subagent 去猜。

坑 4：模型选择不当导致成本爆炸

每个 subagent 都用最强模型（如 Opus）？5 个并行 subagent，每个对话跑几十轮，token 消耗是 5 倍。

解法： 按任务复杂度选模型。

任务类型推荐模型原因
代码修复Sonnet性价比最高，代码能力够用
文档写作Opus需要更好的语言组织能力
格式检查Haiku简单任务，便宜快速
调研分析Sonnet需要理解能力但不需要创造力

适用场景判断

不是所有任务都需要 subagent。判断标准：

✅ 适合用 subagent：

  • 任务可以拆成独立子任务
  • 子任务之间耦合度低
  • 单个任务的上下文量大（会撑爆主 Agent 的窗口）
  • 需要并行加速

❌ 不适合用 subagent：

  • 任务本身很简单，一次对话就能完成
  • 子任务之间高度耦合，需要频繁通信
  • 总任务量小，spawn subagent 的开销反而更大

一个简单的经验法则：如果你需要在一次对话中处理超过 3 个独立的子任务，就该考虑 subagent 了。

进阶：Subagent 的上下文设计

给 subagent 写任务描述是一门手艺。好的任务描述应该包含：

## 角色
你是 XXX 专家

## 任务目标
明确、可验证的目标

## 输入
需要的数据、文件路径、API 端点

## 输出
期望的交付物格式

## 约束
不能做什么、边界在哪

## 工具
可以用哪些工具（shell、git、API...）

把它想象成你给一个新同事写的任务交接文档——他不了解你的项目背景，所以你需要把所有必要的上下文都写清楚。subagent 的质量 = 任务描述的质量。

总结

Subagent 模式的核心思想并不新鲜——就是软件工程中经典的"分治法"。但 AI Agent 的特殊性在于：

  1. 上下文窗口是硬约束：不拆分就会丢信息
  2. 每个 Agent 调用都有成本：需要合理分配模型等级
  3. 并发执行有资源冲突：需要隔离工作环境
  4. 结果汇总需要设计：push vs poll，同步 vs 异步

从单 Agent 到多 Agent 协作，不只是技术升级，更是思维方式的转变。你不再是在"和 AI 对话"，而是在设计一个由 AI 驱动的工作流系统。

这篇文章的写作过程本身就是一个例子——它就是由主 Agent spawn 的一个 subagent 完成的。主 Agent 给出选题要求、输出格式、内容标准，subagent 独立完成调研、写作、排版。互不干扰，各司其职。

当你开始用管理团队的思维来使用 AI，效率的天花板就不再是模型的能力，而是你的工作流设计。

—— AI有招 · 第50篇 ——

avatar
文章
阅读
粉丝