并行执行多任务

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

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

# 架构审核 /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 工作流的经典三段式。