上下文窗口没有无限的耐心
你正做到一个功能的一半，需要查清认证中间件如何工作；接着又想请人复核数据库结构；然后才意识到，写界面之前还得确认设计系统的 token。每次岔出去，都会把几十个文件塞进同一段会话。等你回到原任务，上下文里已经堆满与当前交付无关的噪声。
这就是单线程陷阱：一个 Agent、一个上下文窗口，所有任务都挤在同一场会话里。小改动尚能应付，一旦探索、审查和实现要在一次工作中同时发生，它很快就会失控。更好的做法是委派：启动彼此隔离的子 Agent 处理支线工作，主线程只接收整理后的结论。
子 Agent 到底是什么
子 Agent 是一个自成一体的 Claude 实例，拥有独立的上下文窗口、工具权限和生命周期。它读取代码库、完成任务，再把结果汇报给主会话。主 Agent 不必看到每一次原始文件读取和中间工具调用，只接收摘要。
这很重要，因为上下文窗口更像内存，而不是硬盘。Agent 读过的每个文件、发起的每次工具调用、评估的每个中间结果，都在争用同一块有限空间。子 Agent 把这些开销移到独立上下文里，让主会话始终聚焦于真正需要你判断的工作。
Claude Code 内置三类子 Agent：处理通用任务的 general-purpose Agent、专为代码库检索优化的 explore Agent，以及负责设计实现方案的 plan Agent。你也可以在项目级或用户级配置中定义自有子 Agent，指定系统提示词、工具范围和模型覆盖项。
五个值得委派的信号
并非每项任务都适合子 Agent。另开上下文会增加 token 成本和协调延迟。只有当支线工作会给主会话带来大量噪声时，这笔开销才值得。下面是几个明确的判断信号。
- 任务需要阅读十个以上文件才能补齐背景。让研究型子 Agent 汇总结论，比把原始内容整段倒进主会话更有效。
- 手上有三个或更多互不依赖的工作项。并行子 Agent 可以同时完成它们；对于探索、分诊和测试核验等偏读取的任务，通常能缩短 40% 到 60% 的等待时间。
- 你需要不受先入为主影响的第二意见。新的子 Agent 没经历过你的实现过程，更容易看见熟悉感掩盖的问题。
- 工作有清晰的顺序阶段和交接点。研究、实现、审查各用一个聚焦的子 Agent，能让每个阶段保持干净，不把前一阶段的噪声一路带下去。
- 你想在提交前做一次确认。限制工具权限的只读审查 Agent 能提供额外把关，又不会误改文件。
实用的委派方式
最有效的方式通常是先研究、后实现。先把代码库探索交给子 Agent：认证流程怎么走、现有工具函数有哪些、相关类型定义在哪里。它返回一份聚焦的摘要，主会话便能从已知信息出发，而不是用前二十条消息做代码考古。
如果修改涉及多个互不依赖的文件，并行子 Agent 可以避免在一个线程里来回切换模块造成的混乱。每个子 Agent 只负责一个文件或模块。唯一要守住的边界是：不要让两个子 Agent 同时编辑同一文件，否则很容易制造合并冲突。
最容易被忽略的方式，是独立审查。功能完成后，启动一个只有只读权限的新子 Agent，让它检查安全问题、边界情况和错误处理。它不知道你实现时为何这样取舍——也正因如此，常能发现你遗漏的地方。
什么时候留在同一个线程里
子 Agent 不是默认答案，而是针对特定情形的工具。如果工作天然串行，每一步都依赖上一步的结果，那么单一会话通常比层层交接更清楚。若只是快速修复、改名或调整配置，协调成本也会超过收益。
实用原则是：先从自然对话开始，出现上述信号时再用自然语言委派。当某种模式反复出现并趋于稳定，再把它写成团队都能调用的自定义子 Agent 或 Skill。目标不是把并行度推到最高，而是保持主上下文干净，把你的注意力留给真正重要的决策。