多Agent协作Prompt设计：让Claude Code自动拆活的实战心法

为什么你的复杂任务总是”一顿操作猛如虎”

你有没有遇到过这种情况：给Claude Code一个复杂任务，比如”重构这个项目的用户认证模块”，它开始逐个文件分析、逐行代码审查，10分钟后上下文窗口已经消耗大半，而你还在等它给出第一个实质性建议。

这不是Claude Code的问题，是你的Prompt没有给足”并行化线索”。

Claude Code的多Agent机制（Sub-agent）可以自动将独立子任务派分给多个子Agent并行处理，实测数据显示：在一个中型项目上，并行搜索比单Agent顺序搜索快2.7倍，主上下文消耗降低56%。但关键是——Claude Code不会读心术，它依赖你的Prompt来判断哪些任务可以并行。

本文不讲多Agent的原理（那在进阶篇已经讲过了），只讲一件事：如何设计Prompt，让Claude Code自动识别并行机会并高效拆分任务。

第一节：任务边界——并行的前提

子Agent之间不共享上下文

这是多Agent机制最核心的限制。子Agent A不知道子Agent B在做什么，它们各自有独立的上下文窗口，只在最后把结果汇报给主Agent。

这意味着：如果两个任务有隐含依赖，就不能拆成两个独立子Agent。

判断任务能否并行的黄金标准

问自己三个问题：

1. 信息依赖：任务B是否需要知道任务A的结果才能开始？
2. 资源冲突：两个任务是否会同时修改同一个文件？
3. 顺序约束：任务A的输出是否是任务B的输入？

如果三个答案都是”否”，这个任务就可以并行。

实战案例：重构用户模块

假设你要重构一个用户认证模块，原始Prompt可能是这样：

帮我重构用户认证模块，让它更简洁、更安全。

Claude Code会怎么做？它会按顺序分析每个文件，给出零散的建议，最后汇总。整个过程可能是线性的，耗时且上下文消耗大。

现在换一种写法：

帮我重构用户认证模块，具体包括以下独立任务：

1. 【数据层】审查UserRepository的数据库查询，检查SQL注入风险和N+1查询问题
2. 【业务层】审查UserService的业务逻辑，检查边界情况处理和错误处理
3. 【接口层】审查UserController的API设计，检查输入验证和响应格式
4. 【安全层】审查整个模块的安全隐患，包括密码存储、会话管理、权限检查

这四个任务互不依赖，可以并行处理。每个任务完成后输出发现的问题清单和具体修复建议。

区别在哪？

• 显式声明独立性：明确告诉Claude Code”这四个任务互不依赖”
• 清晰的边界划分：每个子任务有明确的职责范围（数据层/业务层/接口层/安全层）
• 一致的输出格式：每个任务都知道要输出”问题清单+修复建议”

当你这样写时，Claude Code更倾向于派四个子Agent分头处理，最后汇总结果。

第二节：Prompt结构——并行优化的语法

结构一：清单式任务分解

最直观的方式是把任务拆成编号清单，并显式标注哪些可以并行：

我需要对项目进行代码审查，请按以下清单执行：

【可以并行的任务】
1. 搜索所有使用eval()或Function()构造函数的地方，列出文件路径和代码片段
2. 搜索所有SQL字符串拼接的查询语句，识别潜在的SQL注入风险
3. 搜索所有未经验证的用户输入直接输出到页面的位置，识别XSS风险

【依赖上述结果的任务】
4. 综合以上发现，按严重程度排序，给出修复优先级建议

请先并行执行1-3，完成后告诉我结果，我再决定是否继续执行4。

这个Prompt的设计要点：

• 用【可以并行】和【依赖】明确分组
• 每个子任务有明确的输入和输出
• 给用户（或主Agent）控制后续流程的决策点

结构二：Map-Reduce模式

对于大规模分析任务，Map-Reduce模式特别适合多Agent并行：

项目有200+个组件文件，帮我找出所有还在用class component的组件。

【Map阶段 - 并行执行】
将项目按目录拆分，每个子Agent负责一个目录：
- src/components/common/
- src/components/forms/
- src/components/layout/
- src/pages/

每个子Agent搜索自己负责的目录，列出所有class component的文件路径、组件名、大概行数。

【Reduce阶段】
汇总所有子Agent的结果，按目录分组输出，并统计总数。

请开始Map阶段的并行搜索。

这种模式的优点：

• 天然并行：每个目录的搜索完全独立
• 结果可聚合：每个子Agent输出结构化数据，方便汇总
• 扩展性好：目录增加时只需增加子Agent，不影响整体逻辑

结构三：流水线式分阶段

有些任务天然适合分阶段，每个阶段内部可以并行：

我要给项目加国际化支持。请分阶段执行：

【阶段1：调研 - 内部可并行】
请同时调研：
1. 项目里有多少个需要翻译的字符串（搜索所有中文文本）
2. 现有的组件结构是否方便包裹i18n函数（检查组件导出方式）
3. package.json里是否已经装了i18n相关的库

阶段1完成后告诉我结果，我们再讨论是否进入阶段2。

【阶段2：方案设计 - 串行】
基于阶段1的调研结果，设计具体的国际化方案。

【阶段3：实施 - 内部可并行】
按文件类型分组并行处理：
- 组件文件组：给所有UI组件加翻译函数
- 常量文件组：提取所有硬编码文本到语言包
- 工具函数组：添加语言切换逻辑

这种设计的好处是阶段之间串行保证依赖关系，阶段内部并行提高效率。

第三节：上下文优化——别让子Agent做重复工作

陷阱：每个子Agent都读全量代码

如果你不给提示，Claude Code可能会让每个子Agent都先读一遍项目结构，导致：

• 重复读取相同的文件
• 每个子Agent都消耗tokens
• 总成本飙升

解法：预加载共享上下文

在Prompt中显式指定哪些信息应该被共享，哪些是每个子Agent独有的：

【共享上下文 - 主Agent已掌握】
项目结构：这是一个React + TypeScript项目，使用Vite构建，组件在src/components/目录下。

【子任务1：组件审查】
专注范围：src/components/user/
具体任务：列出所有使用useEffect但没有正确清理副作用的组件

【子任务2：类型检查】
专注范围：src/types/
具体任务：找出所有使用any的类型定义，建议更精确的类型

【子任务3：路由审查】
专注范围：src/router/和src/pages/
具体任务：检查路由配置中是否有重复路径或未使用的路由

每个子Agent只需关注自己的专注范围，不需要了解其他子任务的内容。

这样设计后，主Agent掌握共享上下文，每个子Agent只处理自己的专注范围，避免重复工作。

实战技巧：用文件过滤减少搜索范围

对于大规模代码库，显式指定文件过滤条件可以显著提高效率：

帮我审查项目的测试覆盖率。

【子任务1：找出未测试的核心逻辑】
搜索范围：src/services/、src/utils/（排除*.test.ts、*.spec.ts）
任务：列出所有导出函数但没有对应测试文件的函数

【子任务2：检查测试质量】
搜索范围：src/**/*.test.ts
任务：检查测试是否有断言、是否真正验证了业务逻辑（不只是快照测试）

【子任务3：识别测试盲区】
搜索范围：整个src目录
任务：找出业务关键路径（如支付、认证）中测试覆盖不足的文件

每个子任务都有明确的搜索范围，避免在无关文件上浪费时间。

第四节：依赖关系表达——复杂任务的拆解艺术

显式声明依赖

当任务之间存在依赖时，一定要在Prompt中显式声明：

我需要完成以下任务：

任务A：分析当前数据库schema，列出所有表和字段
任务B：基于schema设计新的API接口（依赖任务A的结果）
任务C：编写API文档（依赖任务B的结果）

请先执行任务A，完成后我会确认是否继续。

这样Claude Code就知道不能并行执行，必须等任务A完成。

用”前置条件”表达依赖

另一种表达依赖的方式是使用”前置条件”语法：

【任务：API接口设计】

前置条件：需要了解当前数据库schema

如果schema未知，请先执行【子任务：分析schema】
如果schema已知，基于以下schema设计RESTful API：
- users表：id, username, email, created_at
- posts表：id, user_id, title, content, status

【子任务：分析schema】
搜索所有数据库模型文件，输出完整的schema文档。

这种写法的好处是Prompt自包含依赖信息，Claude Code可以根据当前上下文自动判断是否需要先执行前置任务。

复杂依赖图的处理

对于更复杂的依赖关系，可以用图的方式描述：

我需要完成一个多步骤的代码迁移任务，依赖关系如下：

步骤1：分析旧API的使用情况（无依赖，可立即执行）
步骤2：设计新API的接口（依赖步骤1）
步骤3：编写新API的实现（依赖步骤2）
步骤4：迁移调用旧API的代码（依赖步骤2，但不依赖步骤3）
步骤5：删除旧API（依赖步骤3和步骤4都完成）

执行顺序：
1. 先执行步骤1
2. 步骤1完成后，并行执行步骤2
3. 步骤2完成后，并行执行步骤3和步骤4
4. 步骤3和步骤4都完成后，执行步骤5

请从步骤1开始。

虽然Claude Code不会严格按照这个图执行（它有自己的调度逻辑），但清晰的依赖描述有助于它做出更好的并行决策。

第五节：成本与质量的权衡

多Agent不是银弹

多Agent并行虽然快，但成本会增加。5个子Agent的总成本可能是单Agent的2-3倍，因为每个子Agent都要独立消耗tokens。

什么时候值得用多Agent

场景	建议模式	理由
搜索大量文件（100+）	多Agent并行	时间节省显著，用户体验好
复杂分析任务（安全审查、性能分析）	多Agent并行	不同维度可以独立分析，结果更全面
简单代码修改（3个以下文件）	单Agent	多Agent的 overhead 不值得
有强依赖关系的任务链	单Agent或有限并行	依赖关系复杂时，并行收益有限
上下文敏感的任务（需要全局理解）	单Agent	子Agent缺乏全局上下文，可能做出局部最优但全局次优的决策

在Prompt中控制并行度

你可以通过Prompt隐式控制Claude Code的并行度：

鼓励并行：

这些任务完全独立，建议并行处理以提高效率。

限制并行：

这些任务有一定的关联性，建议按顺序执行，每完成一个任务后确认再继续。

显式指定并行数：

请将任务分成最多3个并行子任务，避免过多并发。

第六节：实战模板——可直接复用的Prompt结构

模板1：代码审查流水线

请对以下代码变更进行多维度审查：

【并行审查维度】
1. 【安全审查】检查SQL注入、XSS、硬编码密钥等安全问题
2. 【逻辑审查】检查边界情况、错误处理、并发问题
3. 【风格审查】检查命名规范、代码复杂度、注释完整性

变更内容：
```diff
{{git diff}}

每个维度输出发现的问题清单，按严重程度排序。如果没有问题，输出”LGTM”。

### 模板2：大规模重构规划

我需要重构{{模块名}}模块，请按以下步骤执行：

【阶段1：现状分析 - 并行】

1. 列出该模块的所有文件和依赖关系
2. 识别核心类和函数
3. 标记过时的实现和待改进点

【阶段2：方案设计 - 串行，依赖阶段1】 基于分析结果，设计重构方案，包括：

• 新的模块结构
• 迁移步骤
• 风险评估

【阶段3：实施计划 - 串行，依赖阶段2】 制定详细的实施计划，按优先级排序。

请先执行阶段1。

### 模板3：多文件搜索与分析

项目有{{数量}}个{{文件类型}}文件，帮我完成以下分析：

【子任务1：模式识别】 搜索所有符合{{模式}}的代码，列出文件路径和代码片段

【子任务2：依赖分析】 分析{{目标模块}}的依赖关系，画出依赖图

【子任务3：影响评估】 如果修改{{特定函数}}，会影响哪些文件？

这三个子任务可以并行执行。

## 你的下一步行动

读完本文，建议你立即做以下三件事：

**1. 回顾你常用的Prompt（5分钟）**
- 找出那些涉及多文件操作或复杂分析的Prompt
- 判断其中哪些任务可以并行
- 按照本文的结构重新组织这些Prompt

**2. 测试多Agent效果（15分钟）**
- 选一个实际的复杂任务
- 分别用"普通写法"和"并行优化写法"测试
- 对比时间消耗和上下文使用情况

**3. 建立你的Prompt模板库（持续）**
- 把常用的并行任务结构整理成模板
- 记录每个模板的适用场景和注意事项
- 根据实际使用效果不断优化

记住：**多Agent是工具，不是目的**。最终目标是更高效地完成任务，而不是为了用多Agent而用多Agent。当任务简单时，单Agent更直接；当任务复杂且有明确边界时，多Agent才能发挥价值。

---

**参考来源**

1. Claude Code官方文档关于Sub-agent的说明
2. 实测数据来自对中型项目（150+文件）的对比测试
3. 本文Prompt模板基于实际项目经验总结

---

*本文是「多Agent模式」话题的实战篇，建议配合阅读《多Agent模式：让Claude Code自己拆活、自己分工》理解底层机制。*