Sub-agent

Sub-agent 架构解决了单 Agent 的上下文瓶颈和专注度问题：

• 上下文隔离：每个 Sub-agent 在自己的上下文窗口中工作，主 Agent 只看到最终结果，不会被大量中间产物淹没。
• 并行执行：多个 Sub-agent 可以同时处理不同的子任务——比如一个查资料、一个写代码、一个做测试。
• 专业分工：不同的 Sub-agent 可以配置不同的 System Prompt、工具集甚至模型——搜索 Agent 连接搜索引擎，代码 Agent 连接编译器。

Sub-agent 的实现模式：

1. 任务委托：主 Agent 识别出一个独立的子任务（如"分析这个 CSV 文件"），创建一个 Sub-agent，赋予它明确的指令、必要的上下文和限定的工具集。

2. 独立执行：Sub-agent 在自己的上下文中运行感知-思考-行动循环。它与主 Agent 隔离——看不到主 Agent 的完整对话历史，只知道自己被分配的任务。

3. 结果汇总：Sub-agent 完成任务后，将结果（或失败信息）返回给主 Agent。主 Agent 将这些结果整合到自己的推理中，继续规划下一步。

4. 上下文预算管理：这是 Sub-agent 的关键优势。一个需要 50 轮交互的复杂任务，如果全部在主 Agent 中完成，上下文窗口会被撑爆。分给 5 个 Sub-agent，每个只消费 10 轮交互的上下文。

复杂代码重构：主 Agent 规划重构方案，分发"改模块 A"给 Sub-agent 1、"改模块 B"给 Sub-agent 2、"更新测试"给 Sub-agent 3。

深度调研：主 Agent 分派 Sub-agent 分别研究不同数据源，最后汇总成报告。

多文件处理：每个 Sub-agent 独立处理一个大文件，避免上下文溢出。

多维度审查：代码审查时，一个 Sub-agent 检查性能、一个检查安全、一个检查代码规范。

误区：Sub-agent 越多越好
✅ 实际上：过多的 Sub-agent 带来管理开销和协调成本。主 Agent 的"工作记忆"用于整合多个 Sub-agent 的返回结果——如果 Sub-agent 太多，主 Agent 自己反而处理不过来。

误区：Sub-agent = 多线程
✅ 实际上：虽然 Sub-agent 可以并行执行，但它们共享同一个 LLM 推理资源（通常是同一个 API）。真正的并行加速受限于 API 的并发限制和速率限制。