语音摘要 — 点击播放以跟读：正在朗读的行会保持在顶部附近。
你已经掌握了创建和设计优质子代理的方法。现在的问题是：它们何时真正发挥作用，何时反而会成为阻碍？关键在于一点——中间工作过程对你的主线程是否重要。
子代理的优势场景
当探索过程与执行过程可以分离时，子代理表现最佳。如果任务中的每个步骤都依赖于前一步骤的发现结果，你应该将这些工作保留在主线程中。但如果你只需要答案而不关心过程，就将其委托出去。
子代理擅长处理以下任务：
- 你只需要结果，不需要了解发现过程
- 探索性工作会污染主线程的上下文
- 任务需要全新视角或定制化的系统提示
研究型任务
研究是子代理的经典用例。假设你需要调查一个陌生代码库中的认证机制，主线程只需要知道_JWT验证发生在哪里_，而不需要看到搜索过程中检查的每个文件。
研究型子代理可以：
- 阅读数十个文件
- 跟踪函数调用链
- 探索不同的代码路径
所有这些探索都保留在子代理的上下文中。主线程将获得简洁的总结：
子代理完成了繁重的工作，主线程则获得了推进所需的精确信息。
代码审查
当代码以"他人编写"的形式呈现时，Claude的审查效果更好。如果你在主线程中经过多轮对话开发了一个功能，再让同一个线程进行审查，通常会产生薄弱的反馈。因为Claude参与了创建过程，难以用全新视角审视代码。
审查子代理在独立上下文中查看变更：
- 运行git diff
- 读取修改后的文件
- 应用其专门的审查标准（无需了解代码编写历史）
这种分离性还允许你将项目特定的审查标准编码到子代理的系统提示中，确保团队采用统一的审查规范。
定制系统提示
Claude Code的默认系统提示强调简洁、代码优先的响应风格，这对编程很有效，但并不适用于所有场景。
以下是定制系统提示使子代理真正优于主线程的两个案例：
- 文案写作子代理——为其设定关于语气、受众和风格的指令。Claude Code的默认提示倾向于简洁的技术写作，这不适合落地页或邮件营销。文案子代理可以拥有完全不同的语音和结构指令。
- 样式设计子代理——让其指向你的设计系统文件。当子代理运行时，这些文件会自动加载到其上下文中，因此在编写CSS之前，它就已经了解你的颜色变量、间距规范和组件模式。
子代理的弊端
启动子代理的开销（失去对其工作的可见性、将其发现压缩为摘要）只有在子代理能完成主线程无法完成的任务时才值得。需要注意以下三种常见反模式。
专家声明
声称具有专业知识的子代理往往没有帮助。"你是Python专家"或"你是Kubernetes专家"这类提示不会增加价值，因为Claude已经具备这些知识。所谓的专家子代理能做到的，主线程都能直接完成。
顺序流水线
顺序子代理流水线会制造问题。考虑一个三代理流程：一个复现bug，一个调试，一个修复。当任务真正独立时流水线有效，但当每个步骤都依赖前一步的发现时（调试几乎总是如此），信息会在代理交接过程中丢失。
测试运行器
测试运行器子代理往往会隐藏你需要的信息。当测试失败时，你需要完整输出来诊断问题。一个仅返回"测试失败"的子代理会迫使你创建额外的调试脚本来获取本应直接可见的细节。测试表明，测试运行器模式在所有配置中表现最差。
决策法则
决定是否使用子代理时，只需问一个问题：中间工作过程重要吗？
如果答案是否定的——你只需要最终结果——就委托给子代理。如果答案是肯定的——你需要观察并响应过程中的变化——就保留在主线程中。
适用子代理的场景：
- 研究与探索
- 代码审查
- 需要定制系统提示的任务
避免使用子代理的场景：
- 不增加实际能力的"专家"角色
- 每个步骤都依赖前一步的多阶段流水线
- 需要完整输出进行调试的测试运行