---
title: "并行执行多任务"
description: "把多个独立任务分给不同子代理同时跑——不用写脚本，描述任务就行"
---

> Documentation Index
> Fetch the complete documentation index at: https://konghayao.github.io/peri-cool/llms.txt
> Use this file to discover all available pages before exploring further.

# 并行执行多任务

## 不只是并行，是编排流水线

别把并行理解为"把几个活儿同时扔出去"。实际使用中，真正有价值的是**有节奏的编排**：

```text
# 架构审核 /ultra-batch
/ultra-batch 评估 peri 项目架构的成熟度：
- explorer 分派到 src/agent/、src/tui/、src/skill/ 三个模块并行探索
- 汇总探索结果后，verification 基于三个模块的报告做整体评估
- 输出：每个模块的耦合度、重复代码、设计 pattern 一致性
```

> 安装：`npx skills add https://github.com/konghayao/peri --skill ultra-batch`

`/ultra-batch` 适合**探索→汇总→评估**这种有节奏的批量任务。而 **`/ultracode`**（Peri 内置）是通用编排引擎：

```text
/ultracode 排查 peri 对 Claude Code 插件的兼容性：
阶段1（并行）：explorer 搜 agent 初始化流程，explorer 搜 MCP 插件加载逻辑
阶段2（串行）：coder 基于阶段1 的结果，修改 prompt 注入位置
阶段3（串行）：verification 跑兼容性测试，输出报告
```

三种依赖模式：

| 模式 | 场景 | 示例 |
|------|------|------|
| **并行** | 任务操作不同文件、无前后依赖 | 同时探索 auth/、db/、api/ 三个模块 |
| **串行** | 下游依赖上游的文件修改 | 先迁移接口定义 → 再改调用方 |
| **汇总后串行** | 先并行探索，汇总后才改 | 先搜所有调用方 → 再统一迁移 |

## 代理选择指南

选错代理类型是最常见的浪费。每个代理都有明确的定位：

```text
# ❌ 错误：用 coder 做搜索
派 coder 子代理搜索所有 unsafe 代码块
# coder 是读写代理，做搜索浪费——它倾向于改东西而不是报告

# ✅ 正确：explorer 专门做搜索和代码库探索
派 explorer 子代理搜索 src/ 下所有 unsafe 代码块，按模块分类输出
```

| 代理 | 类型 | 适用场景 | 别用它做 |
|------|------|----------|----------|
| **explorer** | 只读 | 搜索代码、分析调用链、找 pattern | 改代码、写报告 |
| **coder** | 读写 | 写代码、重构、迁移 | 纯搜索、架构设计 |
| **verification** | 只读 | 运行测试、验证改动、报告结果 | 编码 |
| **plan** | 只读 | 设计实现方案、识别关键文件 | 写代码 |
| **general-purpose** | 读写 | 综合研究、多步任务 | 有专门代理时优先用专门的 |
| **web-researcher** | 读写 | 查文档、找资料、生成报告 | 代码库搜索 |

## 什么时候别并行

并行不是魔法。三个判断标准：

```text
# ❌ 任务之间有文件依赖
任务1：把 User 结构体里的 age 改成 u32
任务2：在所有调用 age 的地方加验证
# 两个 coder 会同时改同一个文件 → 冲突

# ✅ 串行写法
先派 coder 改 User 结构体，
完成后派 coder 搜索所有 age 引用并加验证
```

另外两个陷阱：

- **太多代理不省钱。** 3-5 个代理足够大部分场景。太多代理不但烧 token，还容易出现文件写入冲突。
- **微任务别拆分。** "审查 src/api/ 下 5 个文件"是一个任务，派一个 verification 就行。拆成 5 个代理是瞎折腾。

## 简单流水线示例

```text
/ultracode 请派发一个简单的 workflow：
阶段1（并行）：explorer 搜索所有 deprecated API 调用，explorer 查看新 API 文档
阶段2（串行）：coder 基于探索结果，把 api.ts 里的 deprecated 调用迁移到新 API
阶段3（串行）：verification 运行类型检查和单元测试，验证迁移正确性
```

三个阶段分别用到 explorer（探索）、coder（执行）、verification（验证）——这就是 Peri 工作流的经典三段式。

Source: https://konghayao.github.io/peri-cool/docs/features/parallel-work/index.mdx