多 Agent 工作流：从概念到落地

文章目录

• [多 Agent 工作流：从概念到落地](#多 Agent 工作流：从概念到落地)
• • [为什么需要多 Agent？](#为什么需要多 Agent？)
  • 四种核心模式
  • • [1. 顺序流水线（Sequential Pipeline）](#1. 顺序流水线（Sequential Pipeline）)
    • [2. 并行 + 汇合（Fork-Join）](#2. 并行 + 汇合（Fork-Join）)
    • [3. 对话协商（Conversational / Debate）](#3. 对话协商（Conversational / Debate）)
    • [4. 层级委派（Hierarchical）](#4. 层级委派（Hierarchical）)
  • 框架对比
  • [深入：Claude Code 的 Subagent 模式](#深入：Claude Code 的 Subagent 模式)
  • • 背景
    • 实际工作流
    • 这个模式的真正优势
    • 这个模式的局限
  • 什么时候用什么模式？
  • 写在最后

多 Agent 工作流：从概念到落地

当一个大模型不够用时，我们开始思考：能不能让多个 Agent 协作？

---

为什么需要多 Agent？

单体 Agent 有一个难以逾越的天花板：上下文窗口。

当你让一个模型同时做三件事------理解 PRD、写后端 API、写前端组件------它的注意力会被稀释。更致命的是，一旦上下文窗口被压缩，它可能忘记 PRD 里某个关键约束，导致后端和前端对不齐。

多 Agent 的核心思路是分治：

一个 Agent 只专注一件事 → 多个 Agent 并行工作 → 编排器汇总结果

这不是什么新概念。操作系统里有进程隔离，微服务里有服务拆分，数据库里有分片。多 Agent 只是把这个思想搬到了 LLM 应用层。

---

四种核心模式

业界所有多 Agent 系统，底层不外乎这四种模式的排列组合：

1. 顺序流水线（Sequential Pipeline）

Agent A ──→ Agent B ──→ Agent C
(分析)     (编码)      (测试)

最经典的模式。每个 Agent 只做一件事，输出是下一个的输入。适用场景：数据加工、文档生成、代码审查流水线。

优点 ：逻辑清晰，易于调试------每个阶段的输入输出都是确定的。

缺点：慢。三个 Agent 各花 10 秒，总耗时就是 30 秒。而且一个步骤挂了，后面全废。

真实案例：视频剪辑的 Stage1→Stage2→Stage3→Stage4 流水线。Stage1 提取视频信息，Stage2 转写音频，Stage3 生成剪辑方案，Stage4 合成视频。每一步的输出是下一步的输入，没法并行。

# LangGraph 风格：每个节点是独立函数，图定义顺序
class State(TypedDict):
    videos: List[VideoInfo]
    transcripts: List[Transcript]
    mix_plan: MixPlan

graph = StateGraph(State)
graph.add_node("extract_info", stage1_extract)
graph.add_node("transcribe", stage2_transcribe)
graph.add_node("analyze", stage3_analyze)
graph.add_node("compose", stage4_compose)

graph.add_edge("extract_info", "transcribe")
graph.add_edge("transcribe", "analyze")
graph.add_edge("analyze", "compose")

2. 并行 + 汇合（Fork-Join）

       ┌─ Agent A (用户模块) ─┐
       ├─ Agent B (订单模块) ─┼──→ 编排器 ──→ 合并
       └─ Agent C (支付模块) ─┘

对独立任务最友好的模式。多个 Agent 同时开工，互不干扰，最后汇总。

优点 ：充分利用并行能力，总耗时 = max(各 Agent 耗时) 而非 sum。

缺点 ：合并阶段是瓶颈。Agent A 和 Agent B 可能都改了 utils/helper.py，合并时冲突。

关键设计问题：「怎么确保并行 Agent 互不干扰？」

业界答案基本都是隔离：

隔离方式	代表方案	特点
Git Worktree	Claude Code subagent	每个 Agent 在独立分支上工作，Git 兜底合并
Docker Sandbox	LangGraph + Docker	每个 Agent 跑在独立容器里
虚拟文件系统	Codex CLI	每个 Agent 有自己的 overlay，合并时冲突检测

# 并行派发的伪代码（CrewAI 风格）
crew = Crew(
    agents=[
        Agent(role="用户模块开发", task="实现用户注册"),
        Agent(role="订单模块开发", task="实现下单流程"),
        Agent(role="支付模块开发", task="实现支付回调"),
    ],
    process=Process.parallel  # 三个 Agent 同时开工
)
result = crew.kickoff()

3. 对话协商（Conversational / Debate）

Agent A ⇄ Agent B
(生成)   (审查)

多轮对话直到达成一致

两个 Agent 互相对话，一个生成、一个审查；或者一个有想法、另一个反驳。典型场景：代码 review、创意 brainstorming、安全审计。

优点 ：天然的质量控制，两个模型的盲区可能不重叠。

缺点：慢，而且两个 Agent 可能陷入无限辩论死循环。

AutoGen 的 GroupChat 是实现典范：

# AutoGen: Agent 在群聊中互发消息
groupchat = autogen.GroupChat(
    agents=[coder, reviewer, product_manager],
    messages=[],
    max_round=10  # 最多 10 轮对话，防止死循环
)
manager = autogen.GroupChatManager(groupchat=groupchat)

# Coder 写代码 → Reviewer 检查 → PM 确认需求 → Coder 修改 → ...
coder.initiate_chat(manager, message="实现用户登录功能")

4. 层级委派（Hierarchical）

           ┌──── 编排器 ────┐
           │                │
      ┌────┴────┐      ┌───┴───┐
      │ Team A  │      │ Team B│
      │ Leader  │      │ Leader│
      └────┬────┘      └───┬───┘
      ┌────┴────┐      ┌───┴───┐
      │Worker 1 │      │Worker 3│
      │Worker 2 │      │Worker 4│
      └─────────┘      └───────┘

只有复杂到一定程度的系统才需要。编排器不直接管理 Worker，而是管理多个 Team Leader，Team Leader 再管理自己的 Worker。

优点 ：天然可扩展，单编排器上下文窗口不再是瓶颈。

缺点：延迟高，多了一层转发；而且中间的 Leader 如果理解错了编排器的意图，Worker 白干。

# CrewAI 的层级模式
team_a = Crew(
    agents=[team_lead_a, worker_1, worker_2],
    process=Process.hierarchical,
    task=Task(description="实现前端页面")
)
team_b = Crew(
    agents=[team_lead_b, worker_3, worker_4],
    process=Process.hierarchical,
    task=Task(description="实现后端接口")
)

# 顶层编排
top_crew = Crew(
    agents=[team_a, team_b],
    process=Process.sequential  # Team A 和 B 可以进一步并行
)

---

框架对比

先把话说在前头：没有最好的框架，只有适合你场景的框架。以下不是排名，是按设计哲学分类：

框架	设计哲学	多 Agent 通信	核心优势	核心局限
LangGraph	状态图（DAG）	State 对象在节点间传递	精确的控制流，可检查点恢复	需要写大量 Python 胶水代码
CrewAI	角色扮演	Agent 间委托 + 层级	开箱即用，概念直观	灵活性低，复杂流程难定义
AutoGen	对话驱动	Agent 间直接发消息（GroupChat）	自然的对话式协作，多轮协商	对话轮次难收敛，token 消耗大
OpenAI Agents SDK	工具调用	Handoff（上下文移交）	和 OpenAI 生态深度集成	绑定 OpenAI，且不支持真正并行
Claude Code Subagents	Git-backed 编排	子代理→编排器单向返回	零基础设施，Git 做隔离和合并	依赖 Claude Code 运行时，开放式流程

前三个是"你需要集成到自己的应用里"的开发框架。后两个是"在 CLI 里直接用"的工作模式。

---

深入：Claude Code 的 Subagent 模式

作为最近在实际项目中落地过多 Agent 工作流的团队，我们对 Claude Code 的 subagent 机制感触最深。

背景

Claude Code 的 subagent 本质上是一个独立进程中的 Claude 实例：

主 Claude（编排器）
  │
  ├── Agent("feat-user-auth")     → 独立 worktree，独立上下文
  ├── Agent("feat-order-api")     → 独立 worktree，独立上下文
  └── Agent("feat-payment-flow")  → 独立 worktree，独立上下文

每个 subagent：

• 有自己的独立上下文窗口（不消耗主 Claude 的上下文）
• 工作在Git Worktree 中（物理文件系统隔离）
• 通过 run_in_background: true 可以并行执行
• 完成后返回结构化结果（状态、变更文件、commit hash）

实际工作流

这是我们在视频剪辑项目中落地的完整流程：

阶段零：预检
  ├── 检查 git 状态（必须干净）
  └── 解析 tasks.md 中的任务列表

阶段一：任务审查
  ├── 模糊任务 → brainstorming 澄清需求
  └── 澄清后 → writing-plans 生成实现计划

阶段二：并行派发
  ├── 拓扑排序：无依赖 → 第一批并行
  ├── Agent A (feat-xxx) ─┐
  ├── Agent B (fix-yyy)  ─┼─ 三个 worktree 同时开工
  └── Agent C (feat-zzz) ─┘

阶段三：代码审查（串行，逐任务）
  ├── code-reviewer 对照计划审查
  └── simplify 自动优化

阶段四：合并验收
  ├── 逐任务 merge（冲突 → 子代理消解）
  └── 汇总运行所有子代理的测试

阶段五：输出报告

几个关键设计决策：

1. 为什么用 Git Worktree 做隔离？

因为 Git 已经有了 20 年验证的合并引擎。当三个 Agent 改了同一个文件，git merge 的冲突标记天然就是"多 Agent 冲突解决"------不需要自己实现合并逻辑。Worktree 让每个 Agent 在独立的文件系统副本中工作，是真正的物理隔离，不是"请 Agent A 不要碰 Agent B 的文件"这种 prompt 层面的软约束。

2. 为什么子代理不互相通信？

AutoGen 让 Agent 发消息辩论，CrewAI 让 Agent 委托任务。我们选择只让子代理向编排器汇报。原因很简单：代码生成任务中，两个 Agent 辩论怎么改代码，效率远低于一个 Agent 直接改然后让 code-reviewer 做静态审查。Agent 间的对话在创意性任务（设计评审、需求澄清）中有用，在实现任务中是反模式------多一轮对话就是多一倍延迟。

3. 为什么 merge 不自动解决冲突？

这是项目实际踩过的坑。简单冲突（≤3 个文件、≤30 行）可以派子代理消解后展示 diff 让人类确认；复杂冲突直接中止，让人类决定。Git 冲突标记需要理解双方的语义意图才能正确消解，而当前模型在这方面还不够可靠------它可能合并出一个"语法上没问题但逻辑完全错"的结果。

这个模式的真正优势

不是"功能更丰富"，而是更务实：

• 零基础设施。不需要部署 LangGraph 服务，不需要配置 AutoGen 消息总线。Claude Code + Git 就是全部。
• Git 是唯一的状态层。进度存在 tasks.md 的打勾状态里，代码变更存在 git 分支上。会话断了不丢进度，换一台机器 git pull 接着干。
• 人始终在环路中。每个关键阶段有明确的确认点，用户可以随时说"跳过这个"或"停，这里不对"。

这个模式的局限

要坦诚地写出来：

局限	说明
编排器上下文是瓶颈	5 个阶段 + 所有子代理的返回摘要塞在一个会话，任务数 > 10 时上下文压力很大
合并是串行的	开发可以并行，但 merge 必须一笔一笔来
无自动依赖检测	依赖关系全靠人在 tasks.md 里写，两个 Agent 悄无声息改了同一个文件不会被警告
子代理无状态	子代理不能"之前改过这个文件，这次接着改"------每次都是全新上下文

---

什么时候用什么模式？

一个不精确但实用的选择指南：

你的任务是：
  ├── 有严格顺序依赖（B 必须等 A 的结果）？
  │   └── Sequential Pipeline
  │
  ├── 多个独立子任务，最后要汇总？
  │   └── Fork-Join
  │
  ├── 需要多个视角审校同一份内容（如代码 review、论文审阅）？
  │   └── Conversational / Debate
  │
  ├── 任务极其复杂，单一编排器管不过来？
  │   └── Hierarchical
  │
  └── 只是一个简单的多步骤任务？
      └── 别上 Agent 了，一个模型就够了

大多数实际系统的多 Agent 流程是这四种模式的组合。比如视频剪辑项目：Sequential Pipeline（Stage1→Stage4 主流程）嵌套 Fork-Join（Stage3 内部并行派发），最后以 Conversational（code-reviewer 对照计划审查）收尾。

---

写在最后

多 Agent 不是一个要不要上的问题，而是一个用到什么程度的问题。

目前这个阶段，最好的策略是够用就好：

• 能用单 Agent 解决的别上多 Agent
• 能 Fork-Join 的就别上 Hierarchical
• 能 Git Worktree 隔离的就别上 Docker
• 能让人在环路中的就别全自动

多 Agent 的核心价值从来不是"看起来更酷"，而是每个 Agent 只专注一件事，从而在有限的上下文窗口里做得更好。理解这一点，比追着框架跑更重要。

---

PS：本文基于在实际项目中落地多 Agent 工作流的经验写成，如果觉得写的还不错或者对你有所帮助，记得三连