---
title: "AI Agent 模式解析：让多个 AI 同时开工"
author: deletexiumu
pubDatetime: 2026-03-15T00:30:00+08:00
featured: false
draft: false
tags:
  - AI Agent
  - AI 编程
  - Claude Code
description: "Anthropic Building Effective Agents 系列第三篇：Parallelization 并行化模式的两个变体 Sectioning 与 Voting，以 Superset IDE Git Worktree 隔离和 Replit Agent 4 冲突解决为核心案例，含最小并行模板代码。"
---

*Building Effective Agents 模式解析系列（3/6）*

![Parallelization 并行化](/blog/ai-agent-pattern-parallelization/01-cover.png)

---

## 真实场景引入

你用 Claude Code 做一个全栈项目——先写后端 API，等写完再写前端组件，前端好了再写测试。每步都等上一步完成，一个下午过去，只推进了三分之一。

但你可能见过另一种做法：有人组了个 6 人 AI 团队，前端、后端、数据、测试同时开工，30 分钟出 MVP（如果你读过这个系列的第 20 篇 [Agent Teams 实战](/posts/claude-code-agent-teams-practical-guide/)，应该对这种场景不陌生）。

差别不在模型能力，而在**任务是串行还是并行**。

串行是安全的默认选择——简单、可控、不会冲突。但当任务可以拆成独立的部分时，串行就是在浪费时间。今天要讲的 **Parallelization（并行化）** 就是解决这个问题的模式。

---

## 什么是 Parallelization

Anthropic 在 [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) 中将 Parallelization 定义为：让多个 LLM 实例同时处理任务，结果通过程序化方式聚合。

它有两个变体：

### Sectioning（分段）——不同的人干不同的活

将任务拆成独立子任务，并行执行。每个子任务有不同的职责和 prompt。

Anthropic 原文示例：一个模型处理用户查询，另一个同时筛查不当内容。两件事没有依赖关系，没必要串行。

再比如 LLM 评估场景：每个调用评估模型性能的不同方面——准确性、流畅度、安全性——各自独立打分，最后合并。

### Voting（投票）——多个人看同一件事

对同一任务运行多次，获取多样化输出再聚合。

Anthropic 原文示例：多个 prompt 从不同角度审查代码漏洞——安全视角、风格视角、性能视角——任一发现问题就标记。另一个场景：多个 prompt 评估内容是否违规，通过设置不同投票阈值来平衡假阳性和假阴性。

![Sectioning vs Voting](/blog/ai-agent-pattern-parallelization/02-sectioning-vs-voting.png)

**两者的核心区别**：Sectioning 是 fan-out——把一个大任务拆开分给不同人；Voting 是共识——让多个人独立看同一件事，用聚合结果提高置信度。

### 与系列前两篇的关系

- **Chaining**（[第 1 篇](/posts/prompt-chaining-agent-pattern/)）：步骤固定，顺序执行，前步输出喂后步
- **Routing**（[第 2 篇](/posts/ai-agent-routing/)）：先分类，再走不同路径
- **Parallelization**：子任务已知且独立，同时执行

一个重要的区分——Parallelization 的子任务是**预定义的**。你在写代码时就知道要拆成哪几个子任务。如果子任务需要由 LLM 动态决定（不知道要拆几个、拆什么），那是下一篇要讲的 Orchestrator-Workers 模式。

### 核心权衡

Anthropic 原文的表述很精准：

> "Agentic systems often trade latency and cost for better task performance."

Parallelization 把这个权衡具象化了——**用资源换速度**。多个 LLM 调用同时跑，总 token 消耗更高，但端到端延迟大幅降低。同时，Anthropic 指出，复杂任务拆给多个独立 LLM 调用，每个专注一个方面，效果优于单次调用塞入所有考量。

---

## 核心案例：Superset IDE——Git Worktree 并行隔离的工程实践

### 为什么选这个案例

Superset IDE（superset-sh/superset）不是 Parallelization 模式的"教科书实现"——它不是一个 LLM 编排框架。它是该模式在 AI 编程领域的**工程基础设施**，解决的核心问题是：多个 Agent 并行工作时，如何隔离和合并。

项目由 Avi Peltz、Satya Patel、Kiet Ho 创建（YC Spring 2026 批次），2026 年初公开发布并迅速走红，截至 2026-03-15 GitHub 约 7k Stars，Apache 2.0 开源。

### 它解决什么问题

你想同时跑多个 Claude Code / Codex / Gemini CLI 任务，但它们操作同一个仓库——文件冲突、状态混乱、互相覆盖。这不是模型的问题，是并行的基础设施问题。

### 核心创新——Git Worktree 隔离

Superset 用 **Git Worktree** 作为隔离技术。每个 Agent 会话启动一个新的 worktree——一个独立目录，拥有共享的 Git 历史。

```
Agent 1 → worktree-1/ → feature/auth 分支
Agent 2 → worktree-2/ → fix/header 分支
Agent 3 → worktree-3/ → test/payment 分支
```

物理隔离，互不干扰。Agent A 修改文件不影响 Agent B，直到显式合并。

**与多 clone 的区别**：worktree 共享 `.git` 目录，省磁盘、保持历史一致。

**与容器/沙箱的区别**：worktree 是 Git 原生能力，零额外开销。

### 架构拆解

完整流程：

```
用户在 Superset IDE 中启动任务
  → 自动创建 worktree + 分支
  → Agent 在隔离环境中工作
  → 完成后通过 diff viewer 审查
  → 合并回主分支
```

几个关键设计决策：

- **Agent 无关性**：支持 Claude Code、OpenCode、Codex CLI、Gemini CLI 等任何 CLI Agent——"Any CLI agent will work"
- **持久化守护进程**：Agent 会话由守护进程管理，关闭笔记本电盖也不会中断
- **统一仪表盘**：一个视图监控所有运行中的 Agent，Agent 需要输入时即时通知

### 体现 Parallelization（Sectioning）的三个维度

**1. 预定义子任务并行**

用户将项目拆成独立子任务（前端 / 后端 / 测试 / 文档），每个 Agent 并行处理。子任务是人工预定义的，不是 Agent 动态拆分的——这正是 Sectioning 的定义。

**2. 解决了并行的核心难题——隔离与合并**

worktree 提供文件级隔离，内置 diff viewer 提供人工合并审查。没有隔离的并行是灾难——多个 Agent 同时编辑同一个文件会产生不可预测的结果。

**3. 用资源换速度**

多个 Agent 同时消耗 token，但端到端交付速度数倍提升。团队自己说 "more than doubles our productivity"。

### 局限与争议

HN 社区的反馈相当直接（[HN 讨论帖](https://news.ycombinator.com/item?id=46109015)）。

**"typing time 变成 reading time"**——HN 用户 amortka 的核心观点是，并行 Agent 本质上把瓶颈从"编码"转移到了"审查"。他给出了并行 Agent 有效的前提条件：任务范围明确（scoped task）、有不变量测试（invariant tests）、diff 足够小便于快速审查。

**"10+ Agent"是上限，不是日常**——团队成员 saddlepaddle 坦承 "I can't get to 10 regularly"。实际数据：简单任务稳定在 5-7 个并行，复杂任务 2-3 个。支持 10+ 是产品能力，不是工作常态。

**并行度受限于任务独立性**——互相依赖的任务无法真正并行，这是 Parallelization 模式的固有约束。

**平台支持**：以 macOS 为主，Linux 支持已上线但仍在完善，Windows 暂未支持。

---

## 辅助案例：Voting 原文示例 + Replit Agent 4

### 案例一：代码审查投票——Voting 变体的典型应用

Anthropic 原文给出了两个 Voting 场景：

**代码漏洞审查**：多个不同 prompt 分别审查同一段代码，各自关注不同维度（安全漏洞、风格规范、性能问题）。任一发现问题则标记需人工复查。

**内容审核**：多个 prompt 评估内容不同方面，通过配置投票阈值来控制精度：

- **多数投票（majority vote）**：N 个审查者中过半认为有问题则标记
- **阈值投票**：设置不同阈值平衡假阳性和假阴性——阈值低（任一标记即触发）适合高敏感场景，阈值高（全部标记才触发）适合低误报场景
- **加权投票**：不同审查者对不同维度的权重不同

学术研究也支持这个方向。JMIR 2025 年发表的医学问答研究中，基于 boosting 的加权投票在 MedMCQA 数据集上将准确率提升了 3.81%；arXiv 2511.15714 的内容分类实验（10 个 LLM 零样本评估）证实，协调多模型决策显著优于单模型——但也发现了**性能平台效应**：超过一定阈值后，增大模型规模或提升算法复杂度的收益递减。

### 现实世界的混合形态：Claude Code Review

Anthropic 2026-03-09 发布的 Claude Code Review 不是纯 Voting——它是"多 Agent 并行审查 + 验证过滤 + 严重度排序"的混合并行架构。

工作流程：PR 打开后，一组 Agent 并行工作，每个独立审查代码、寻找不同类别的 bug → 验证步骤过滤误报 → 按严重度排序 → 合并为一条总结评论加行内评论。

Anthropic 内部测试数据（来源：Anthropic 官方博客 claude.com/blog/code-review）：

- 超过 1000 行变更的大 PR：84% 会被指出问题，平均 7.5 个发现
- 工程师标记为错误的发现：不到 1%
- 引入前仅 16% 的 PR 收到详细审查评论，引入后 54%

这说明真实系统往往是 Sectioning（不同 Agent 看不同维度）+ Voting（多视角聚合判断）的混合体。纯 Voting 在教科书里很清晰，到了工程实践就会和其他模式自然融合。

### 案例二：Replit Agent 4——并行 Agent 与合并机制

2026 年 3 月 11 日发布，Georgian 领投 $400M Series D，估值 $9B（[Analytics India Mag 报道](https://analyticsindiamag.com/ai-news/replit-raises-400-mn-at-9-bn-valuation-unveils-agent-4-for-vibe-coding)）。

**并行机制**：用户审批的多个独立任务在隔离 fork 中同时执行——auth / database / backend / frontend 各在独立线程中运行，主应用副本保持全局上下文感知。

**冲突解决**：当并行任务产生代码冲突时，专门的 sub-agent 负责合并，完成后自动跑测试。

**Trello 式看板追踪**：Drafts（计划等待审批）→ Active（Agent 正在构建）→ Ready（完成待审查）。PM 通过看板管理 Agent 工作，替代传统的线性聊天线程。

**与 Superset IDE 的对比**：Superset 用 worktree 隔离 + 人工合并（更安全可控）；Replit 用 fork + sub-agent 自动合并（更自动化）。两种策略反映了并行系统在"安全"和"效率"之间的取舍。

**边界说明**：Replit Agent 4 还支持"自动将大任务拆成子任务"——这部分已进入 Orchestrator-Workers 的领域，子任务由 Agent 动态决定而非用户预定义，将在下一篇讨论。

---

## 怎么设计好的并行

### 任务拆分原则

**识别独立性**：任务之间无共享状态、无顺序依赖才能真正并行。如果 B 依赖 A 的输出，它们就不能并行——只能放到不同的执行批次（先跑 A，A 完成后再跑 B）。

**Vertical Slice 优于 Horizontal Layer**：按功能纵切（一个 Agent 负责完整的用户模块：Model + API + UI）优于按层横切（一个 Agent 写所有 Model，另一个写所有 API）。原因很直接——纵切的任务天然操作不同的代码区域，文件冲突少，并行度高。横切造成串行瓶颈：后续层级依赖前置层级完成。

**拆分粒度**：太粗则并行度不够，太细则协调开销吃掉收益。一个可操作的检验标准：每个子任务的产出是否可以独立被审查和合并？如果合并时总是要和其他子任务联合看才能判断对错，说明拆得太细了。

### 隔离策略（从轻到重）

| 策略 | 实现方式 | 适用场景 | 代表案例 |
|------|---------|---------|---------|
| **文件级隔离** | Git worktree | 代码项目，多 Agent 改不同文件 | Superset IDE |
| **上下文隔离** | 每个 Agent 独立上下文窗口 | 研究/分析任务，产出独立 | Claude subagent 模式 |
| **进程级隔离** | 容器/沙箱 | 需要不同运行环境 | Replit fork |

选择原则：**能用轻量方案就不上重量方案**。worktree 是 Git 原生命令，没有额外依赖；上下文隔离是 Agent SDK 内置能力；容器隔离最重，但提供最强的环境隔离。

### 聚合策略

**Sectioning 聚合**：
- 结果拼接：多段文档直接合并
- 结构化合并：代码 PR merge
- 人工审查：Superset IDE 的 diff viewer，人工决定是否接受每个 Agent 的产出

**Voting 聚合**：
- 多数投票：过半同意即通过
- 阈值投票：根据场景敏感度调整阈值
- 加权投票：对特定维度更可靠的审查者赋予更高权重
- LLM 裁判：让另一个 LLM 从多个输出中选最优

### 并发度控制

经验做法：**从 5 个并行任务起步**，再按以下因素调整：

- **任务独立性**：依赖越少，可并行越多
- **机器性能**：经验上本地机器很快会遇到资源瓶颈——CPU、内存、磁盘 I/O 都会成为限制因素
- **API 限额**：并行不等于免费，每个会话的 token 成本不变，配额按并发数比例消耗
- **人工审查能力**：Superset IDE 团队实测，复杂任务 2-3 个更稳定——因为审查成为瓶颈

不要追求某个"最优并发数"。并发度是场景相关的，简单修 bug 可以跑 5-7 个，复杂功能开发 2-3 个就够了。

### 错误处理

与 Chaining 的关键区别：Chain 中一步失败会阻塞后续所有步骤；Parallelization 中，**单个 Agent 失败不应阻塞其他 Agent**。

三条策略：

1. **独立重试**：失败的子任务单独重试，不影响其他正在运行的任务
2. **超时熔断**：设置每个子任务的超时时间，超时即放弃或降级处理
3. **原子提交回滚**：每个子任务产出独立 Git commit，失败可单独 revert——不用回滚整个项目

### 最小并行模板

一个 3-agent 并行的示意模板，展示 Sectioning 模式的核心结构。`call_llm` 是占位实现，需要根据你实际使用的 API 来替换（如 Anthropic SDK、OpenAI SDK 等）。模板展示的是并行编排逻辑，不可直接运行。

**任务表：**

| Agent | 职责 | 输入 | 输出 |
|-------|------|------|------|
| Agent 1: 提取 | 从文档提取关键事实 | 原始文档 | JSON: `{facts: [...]}` |
| Agent 2: 分析 | 从文档分析风险点 | 原始文档 | JSON: `{risks: [...]}` |
| Agent 3: 摘要 | 生成执行摘要 | 原始文档 | JSON: `{summary: str}` |
| 聚合 | 合并三路输出为最终报告 | 三个 Agent 的 JSON | Markdown 报告 |

**Python 代码：**

```python
import asyncio
import json
from typing import Any

# ---------- 工具函数 ----------
async def call_llm(prompt: str, model: str = "YOUR_MODEL_ID") -> str:
    """调用 LLM，返回文本响应（省略具体 API 调用细节）"""
    ...

# ---------- 三个并行 Agent ----------
async def extract_facts(doc: str) -> dict:
    """Agent 1: 提取关键事实"""
    output = await call_llm(
        f"从以下文档中提取所有关键事实，输出 JSON 格式 {{facts: [...]}}。\n\n{doc}"
    )
    return json.loads(output)

async def analyze_risks(doc: str) -> dict:
    """Agent 2: 分析风险点"""
    output = await call_llm(
        f"分析以下文档中的潜在风险，输出 JSON 格式 {{risks: [...]}}。\n\n{doc}"
    )
    return json.loads(output)

async def generate_summary(doc: str) -> dict:
    """Agent 3: 生成摘要"""
    output = await call_llm(
        f"为以下文档生成不超过 200 字的执行摘要，输出 JSON 格式 {{summary: str}}。\n\n{doc}"
    )
    return json.loads(output)

# ---------- 聚合函数 ----------
async def aggregate(facts: dict, risks: dict, summary: dict) -> str:
    """将三路输出合并为最终报告"""
    combined = json.dumps(
        {"facts": facts, "risks": risks, "summary": summary},
        ensure_ascii=False
    )
    report = await call_llm(
        f"基于以下三个分析结果，生成一份完整的 Markdown 格式报告。\n\n{combined}"
    )
    return report

# ---------- 并行执行引擎 ----------
async def run_parallel_analysis(doc: str) -> str:
    """Fan-out: 三个 Agent 并行执行 → Fan-in: 聚合结果"""

    # 并行执行三个 Agent
    results = await asyncio.gather(
        extract_facts(doc),
        analyze_risks(doc),
        generate_summary(doc),
        return_exceptions=True,  # 单个失败不阻塞其他
    )
    # 过滤异常结果
    facts, risks, summary = [
        r if not isinstance(r, Exception) else {"error": str(r)}
        for r in results
    ]

    # 聚合
    report = await aggregate(facts, risks, summary)
    return report

# ---------- 错误处理增强版 ----------
async def run_with_retry(fn, *args, max_retries: int = 2) -> Any:
    """单个 Agent 的独立重试，不阻塞其他 Agent"""
    for attempt in range(max_retries + 1):
        try:
            return await fn(*args)
        except Exception as e:
            if attempt == max_retries:
                return {"error": str(e)}
            print(f"  {fn.__name__} 失败 (第 {attempt+1} 次)，重试...")

async def run_parallel_with_error_handling(doc: str) -> str:
    """带独立重试的并行执行"""
    facts, risks, summary = await asyncio.gather(
        run_with_retry(extract_facts, doc),
        run_with_retry(analyze_risks, doc),
        run_with_retry(generate_summary, doc),
    )
    report = await aggregate(facts, risks, summary)
    return report
```

**几个设计要点：**

- `asyncio.gather` 是 Python 原生的并行原语——三个 Agent 同时启动，全部完成后才进入聚合步骤。Google ADK 的 `ParallelAgent` 和 OpenAI Agents SDK 的 fan-out 模式本质上都是这个结构。
- 每个 Agent 接收相同的原始文档但执行不同的任务——这就是 Sectioning。如果让三个 Agent 对同一文档做相同的风险分析再投票，就变成了 Voting。
- `run_with_retry` 实现了单个 Agent 的独立重试。一个 Agent 失败不影响其他两个——这是 Parallelization 区别于 Chaining 的关键特征。重试耗尽后返回 `{"error": ...}`，聚合步骤需要检查并处理这种降级结果（生产代码应在 aggregate 前过滤错误项）。
- 聚合步骤是另一次 LLM 调用。简单场景下可以用纯代码拼接替代，不一定需要 LLM。

---

## 适用场景与模式组合

### 适合并行的场景

- **任务天然可分片**：多文件、多模块、多语言、多数据源——每个分片操作不同的资源
- **需要多视角复核**：代码审查、内容审核、安全检测——一个视角可能漏掉的，多个视角兜住
- **延迟敏感，愿意用 token 换速度**：MVP 快速原型、紧急修复多个 bug

### 不适合并行的场景

- **任务之间有强依赖**（后步需要前步输出）→ 用 Chaining
- **子任务不可预测**（不知道要拆几个、拆什么）→ 用 Orchestrator-Workers
- **所有子任务操作同一资源且无法隔离**（如编辑同一文件的同一段）→ 串行或合并为一个任务

### 与其他模式的组合

**Chain + Parallelization**：Chain 的某步内部并行。典型例子是 GSD 工作流（[第 1 篇](/posts/prompt-chaining-agent-pattern/)的核心案例）——它的 Execute 阶段将任务按依赖关系分组为 Wave，同一 Wave 内的任务并行执行，跨 Wave 串行。这是 Chaining 骨架中嵌套 Parallelization 的实例。

**Routing + Parallelization**：路由后的多条路径并行处理。Anthropic 原文的 guardrail 示例——护栏检查和核心回答同时进行，不用等护栏通过了再开始生成回答。

**Parallelization + Voting**：先 Sectioning 拆子任务，每个子任务内部用 Voting 提高置信度。Claude Code Review 就是这种混合形态。

### 核心判断标准

**子任务是否已知且独立？**

- 是 → Parallelization
- 子任务未知、需动态拆分 → Orchestrator-Workers（下一篇）

---

## 结尾

这是 Building Effective Agents 模式解析系列的第三篇。Chaining 解决"按什么顺序干"，Routing 解决"谁来干"，Parallelization 解决"怎么同时干"。

核心观点只有一句：**Parallelization 的本质是"同时开工，各干各的"——Sectioning 分工，Voting 复核。** 能并行的前提是任务独立且可隔离，否则并行制造的混乱会比串行浪费的时间更贵。

**下一步**：拿文中的最小模板试一下。找一个你正在做的任务，看它能不能拆成 2-3 个独立的子任务并行处理。如果你在做代码项目，试试用 `git worktree` 开几个隔离的工作目录同时跑不同的 Agent。


---

## 相关阅读

- [AI Agent 模式解析：Prompt Chaining 提示链](/posts/prompt-chaining-agent-pattern/) — 系列第 1 篇，固定步骤的顺序执行模式
- [AI Agent 模式解析：Routing 路由分流](/posts/ai-agent-routing/) — 系列第 2 篇，输入分类导向不同处理路径
- [Claude Code Agent Teams 多代理协作完整实战](/posts/claude-code-agent-teams-practical-guide/) — 并行 Agent 的实战案例，6 人 AI 团队 30 分钟出 MVP

---

*原文参考：[Anthropic - Building Effective Agents](https://www.anthropic.com/research/building-effective-agents)*

*核心案例：[Superset IDE（superset-sh/superset）](https://github.com/superset-sh/superset)*

*案例来源：[Replit Agent 4](https://blog.replit.com/introducing-agent-4-built-for-creativity)*

*数据来源：[Claude Code Review - Anthropic 官方博客](https://claude.com/blog/code-review)*

*数据来源：[RouteLLM Voting 研究 - JMIR e70080](https://www.jmir.org/2025/1/e70080)*

*数据来源：[LLM Ensemble for Content Categorization - arXiv 2511.15714](https://arxiv.org/html/2511.15714v1)*

*行业观点：[The New Stack - Why AI Parallelization Will Be One of the Biggest Challenges of 2026](https://thenewstack.io/why-ai-parallelization-will-be-one-of-the-biggest-challenges-of-2026/)*