子代理与并行任务

子代理解决什么问题

长会话最大的敌人是上下文污染：跑了 50 轮之后，对话里塞满了试错、废弃方案、无关文件，AI 开始抓不住重点。

子代理是开一个干净上下文去干活的机制。它有独立的对话空间，干完只把结果交回来，中间过程不污染主会话。

三种典型用途

1. 大范围探索 “这个项目里有几种鉴权方式？”——让子代理去翻代码，主会话只接收结论。

2. 并行独立任务 五个互不相干的任务同时跑，而不是串行等五个。

3. 专项角色 可以让子代理扮演特定角色（架构师、测试、审查者），用不同视角看同一个问题。

常见子代理类型

类型	擅长	限制
探索型	快速搜索代码库、定位文件	只读，不能改
规划型	设计实现方案、分析架构	只读，出方案不执行
通用型	能读能写能跑命令	权限最全，风险也最高
专项型	表格处理、文档生成等特定领域	只做对应领域

原则：能用只读型就别用通用型。让它探索就别给写权限。

怎么写子代理提示词（关键）

子代理看不到你当前的对话。它没有你前面几轮的讨论、没有你的隐含前提、没有“就是刚才说的那个”这种上下文。

所以提示词必须自包含。

❌ 错误示范：
"按刚才讨论的方案重构 auth 模块"

✅ 正确示范：
"重构 /Users/me/proj/src/auth 模块：
- 现状：目前用 session 存储，代码在 auth/session.ts
- 目标：改成 JWT，token 有效期 7 天
- 约束：不要改动调用方的函数签名
- 验收：现有测试全部通过
先输出方案给我确认，不要直接改文件"

写提示词时想象你在给一个刚走进房间、没听过之前讨论的同事交代任务。

并行任务的三条规则

规则一：任务之间必须真正独立 两个子代理同时改同一个文件 = 互相覆盖。要改同一处就串行。

规则二：别让子代理做你没理解的事 “基于你的发现修复那个 bug”——你都不知道它发现了什么，怎么验收？正确做法是让它先汇报，你理解后再决定下一步。

规则三：长任务放后台 耗时几分钟以上的任务（装依赖、跑构建、大批量处理）放后台跑，你继续干别的，完成会通知你。

一个实战组合

典型的大型改造任务：

1. 派探索型子代理 → 摸清现状，产出报告
2. 你读报告 → 理解现状（这步不能省）
3. 派规划型子代理 → 基于现状出方案
4. 你确认方案 → 可能来回改几轮
5. 派通用型子代理 → 执行改动
6. 你验收 diff → 跑测试

每一步你都在关键决策点上，routine 的活都派出去。

什么时候不用子代理

• 任务很小（一两轮就能搞定）——开子代理的开销大于收益
• 需要紧密来回讨论的创意工作——子代理的隔离反而碍事
• 上下文本来就干净——没必要隔离

下一篇

MCP 服务器配置——接上外部工具和数据。