不只是并行，是编排流水线
别把并行理解为“把几个活儿同时扔出去”。实际使用中，真正有价值的是有节奏的编排：
# 架构审核 /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 内置）是通用编排引擎：
/ultracode 排查 peri 对 Claude Code 插件的兼容性：
阶段1（并行）：explorer 搜 agent 初始化流程，explorer 搜 MCP 插件加载逻辑
阶段2（串行）：coder 基于阶段1 的结果，修改 prompt 注入位置
阶段3（串行）：verification 跑兼容性测试，输出报告三种依赖模式：
| 模式 | 场景 | 示例 |
|---|---|---|
| 并行 | 任务操作不同文件、无前后依赖 | 同时探索 auth/、db/、api/ 三个模块 |
| 串行 | 下游依赖上游的文件修改 | 先迁移接口定义 → 再改调用方 |
| 汇总后串行 | 先并行探索，汇总后才改 | 先搜所有调用方 → 再统一迁移 |
代理选择指南
选错代理类型是最常见的浪费。每个代理都有明确的定位：
# ❌ 错误：用 coder 做搜索
派 coder 子代理搜索所有 unsafe 代码块
# coder 是读写代理，做搜索浪费——它倾向于改东西而不是报告
# ✅ 正确：explorer 专门做搜索和代码库探索
派 explorer 子代理搜索 src/ 下所有 unsafe 代码块，按模块分类输出| 代理 | 类型 | 适用场景 | 别用它做 |
|---|---|---|---|
| explorer | 只读 | 搜索代码、分析调用链、找 pattern | 改代码、写报告 |
| coder | 读写 | 写代码、重构、迁移 | 纯搜索、架构设计 |
| verification | 只读 | 运行测试、验证改动、报告结果 | 编码 |
| plan | 只读 | 设计实现方案、识别关键文件 | 写代码 |
| general-purpose | 读写 | 综合研究、多步任务 | 有专门代理时优先用专门的 |
| web-researcher | 读写 | 查文档、找资料、生成报告 | 代码库搜索 |
什么时候别并行
并行不是魔法。三个判断标准：
# ❌ 任务之间有文件依赖
任务1：把 User 结构体里的 age 改成 u32
任务2：在所有调用 age 的地方加验证
# 两个 coder 会同时改同一个文件 → 冲突
# ✅ 串行写法
先派 coder 改 User 结构体，
完成后派 coder 搜索所有 age 引用并加验证另外两个陷阱：
- 太多代理不省钱。 3-5 个代理足够大部分场景。太多代理不但烧 token，还容易出现文件写入冲突。
- 微任务别拆分。 “审查 src/api/ 下 5 个文件”是一个任务，派一个 verification 就行。拆成 5 个代理是瞎折腾。
简单流水线示例
/ultracode 请派发一个简单的 workflow：
阶段1（并行）：explorer 搜索所有 deprecated API 调用，explorer 查看新 API 文档
阶段2（串行）：coder 基于探索结果，把 api.ts 里的 deprecated 调用迁移到新 API
阶段3（串行）：verification 运行类型检查和单元测试，验证迁移正确性三个阶段分别用到 explorer（探索）、coder（执行）、verification（验证）——这就是 Peri 工作流的经典三段式。