有效使用子代理

子代理大放异彩的场景

当探索工作与执行工作相互独立时，子代理的效果最好。如果任务中的每一步都依赖于上一步的发现，那么这部分工作应该留在您的主线程中。但如果您只需要一个答案，而不关心得出答案的过程，那就把它委托出去。

子代理在以下任务中表现出色：

• 您需要的是结果，而不是寻找结果的逐步过程
• 探索性工作会使主线程的上下文变得杂乱
• 该任务能从全新视角或自定义系统提示中受益

研究类任务

研究是子代理的经典使用场景。设想一下，您要调查一个陌生代码库中的身份验证是如何工作的。您的主线程需要知道 JWT 是在哪里被验证的，但它不需要看到沿途搜索过的每一个文件。

研究型子代理可以读取数十个文件，追踪函数调用，并探索不同的代码路径。所有这些探索都留在子代理的上下文中。您的主线程收到的是一份简洁的摘要，例如：

JWT validation happens in middleware/auth.js line 42,
called from the Express router in route/api.js

繁重的工作由子代理完成。您的主线程恰好得到了继续推进所需的内容。

代码审查

当代码被呈现为由他人编写时，Claude 的代码审查会更有效。如果您在主线程中经过多轮对话构建了一个功能，再让同一个线程去审查它，往往会得到较弱的反馈。因为 Claude 参与了该功能的创建，所以很难以全新的眼光去看待它。

审查型子代理会在一个独立的上下文中查看这些改动。它会运行 git diff，读取被修改的文件，并应用其专门的审查标准，而不受代码编写历史的影响。这种隔离还能让您将项目特定的审查标准编码到子代理的系统提示中，从而确保团队内审查标准的一致性。

自定义系统提示

Claude Code 的默认系统提示强调简洁、以代码为中心的回复。这对编码来说效果很好，但并不适用于所有场景。

以下是两种自定义系统提示能让子代理真正优于主线程的情况：

• 文案撰写子代理——为它提供关于语气、受众和风格的指示。Claude Code 的默认提示倾向于简洁的技术写作，而这恰恰不是您在撰写落地页或邮件营销活动时想要的。文案撰写子代理可以拥有关于语调和结构的完全不同的指示。
• 样式设计子代理——在其系统提示中告诉它先阅读您的设计系统文件，这样它在开始编写任何 CSS 之前，就已经了解您的颜色变量、间距约定和组件模式。

子代理何时会帮倒忙

启动子代理的开销——将其工作对主线程隐藏，并将其发现压缩成一份摘要——只有在子代理能做到主线程做不到的事情时才有意义。有三种常见的反模式需要警惕。

专家式声明

声称自己是专家的子代理很少真正有帮助。像"你是一名 Python 专家"或"你是一名 Kubernetes 专家"这样的提示没有任何附加价值，因为 Claude 本来就具备这些知识。所谓的专家子代理能做的事情，您的主线程完全可以直接做到。

顺序流水线

顺序式子代理流水线会带来问题。设想一个三代理流程：一个用来复现 bug，一个用来调试它，一个用来修复它。当任务真正相互独立时，流水线才能正常工作。而当每一步都依赖于上一步的发现时，流水线就会失败——而修复 bug 几乎总是如此。信息会在代理之间的交接过程中丢失。

测试运行器

测试运行器子代理往往会隐藏您需要的信息。当测试失败时，您需要完整的输出来诊断问题。一个只返回"测试失败"的子代理，会迫使您创建额外的调试脚本，才能获取本应在直接输出中就能看到的细节。测试结果表明，在所有配置中，测试运行器这种模式的表现最差。

决策规则

在决定是否使用子代理时，问自己一个问题：中间过程重要吗？

如果答案是否定的——您只需要最终结果——那就把它委托给子代理。如果答案是肯定的——您需要看到并对过程中发生的事情做出反应——那就把它留在主线程中。

在以下情况使用子代理：

• 研究与探索
• 代码审查
• 需要自定义系统提示的任务

在以下情况避免使用子代理：

• 不能带来真正能力提升的"专家"人设
• 每一步都依赖上一步的多步骤流水线
• 需要完整输出以便调试的测试运行