什么活儿该派给子代理？

导读

子代理是独立隔离、可调用工具的任务执行者，用来解决主线上下文膨胀、任务混杂的问题：把子任务外包出去，只返回结果，不污染主线。判断标准只有一条——这段中间过程值不值得占用主对话的 Token 预算。

本文统一用“子代理”指代隔离式实现

子代理（Subagent）是隔离式并行执行单元，在绝大多数 AI Agent 开发语境下，“子代理”和 Subagent 没有区别，只是中英文的对应翻译关系。

日常使用中不必严格区分。不同herness定义有些不一样，核心区别是：是否默认继承上下文规则。

一个模型的上下文窗口是有限的，而重要决策往往发生在上下文还干净的早期。假设你在陌生项目里随便问一句“这是个啥项目”，AI 可能要读几十个文件。如果全灌进主对话，主对话立刻被噪声淹没。通常可以用子代理来解决这个问题：让一个agent去处理复杂的任务，只返回一个结论给主窗口。

我自己的判断标准是：这段中间过程值不值得占用主对话的 Token 预算。

这段中间过程是什么	放在哪
只需要产出结论，不参与后续决策	隔离到子代理
本身就是后续决策的依据，比如调试报错、逐步推理链、关键接口定义	留在主线

主对话的 Token 预算应该花在决策上，不是花在原始数据和中间产物上。这个判断适用于所有形式的子代理。

子代理不继承主对话的安全护栏和用户偏好

这是一把双刃剑。你在当前聊天窗口里说过的所有话、纠正过的指令、达成的共识、上传的临时文件等，如果你没有给子代理明确指令去阅读这些东西，它就是一个全新的会话，对此一无所知（但仍然受项目根目录那类常驻规则文件的约束）。

关于子代理的使用技巧

子代理通过主代理转述结果，不直接跟你说话。不要让主代理完全自主、未经审核地代写提示词。 可以用固定模板，主代理填槽，人来审核关键字段；至少主代理写完后你要审核一遍。这是最容易翻车的地方，两个代理你一搭我一搭，非常容易陷入“你画我猜”的怪圈。
建议把子代理输出落盘，也就是保存成文件。子代理不会跟你直接沟通，生成的结果藏在“思考中”，有些产品甚至不提供查看。落盘之后，你才能复查结果质量。
和主代理约定好哪些结果注入主对话上下文。如果子代理的目的就是保持主对话干净，那进入主对话的摘要内容应该由你控制。

主代理在上下文里参与了代码生成，让它自己审自己，它会偏袒自己的产出。这是自我一致性偏差，不是故意包庇。所以派一个子代理来审，它没有这段生成记忆，拿到就是陌生代码，没有“这是我写的”这种自我一致性压力，挑毛病完全不讲情面。

你可以利用这种“挑别人毛病质量更高”的特点，派一个子代理来审主对话里的方案或者代码。如果你足够放心的话，你甚至可以使用这段提示词：

text

派一个子代理来审你的方案，你将会跟它对话，直至你们两个达成一致意见，再把结论给我看。

额外需要注意的事情

有些产品需要手动开启：部分 Agent 产品——尤其是国内所谓“work 系列”——默认不开启子代理能力，需要提前在设置中打开。

需要显式触发：直接告诉 AI 你要调用它。

总 Token 消耗通常显著更高: 以 Claude Code 的嵌套子代理为例，每层独立持有自己的上下文窗口和系统提示词，同样的代码库如果被多个子代理重复读取，Token 消耗会成倍增长。

子代理不一定省时间：即便是并行任务，例如派多个子代理去读一本书，也不一定更省时。模型输出速度、上下文长度限制和 API 调用延迟并不会因为并行而消失，任务拆分、结果合并和上下文往返还会增加协调成本，所以整体耗时未必下降，甚至可能更高。

子代理省的是主对话上下文空间，换的是决策质量。如果你的目的是“更快做完”，子代理的表现真谈不上亮眼，只有在大量重复且机械的工作场景下才值得用——即便如此，也不保证比单代理效率更高。