子代理并行分流

解决什么问题

在大型工程任务中，当代码库的探索和重构涉及多个互不相关的模块时，如果由主线程逐一读取并处理所有细节，上下文窗口会迅速被海量的中间文件和冗余信息塞满。这不仅会拖慢响应速度，还会因为 token 的指数级膨胀导致成本失控。我们需要一种机制，让模型在不离开主线程的情况下，能够并行地探索庞大且独立的代码空间。

技能如何工作

子代理扇出 模式的核心在于分解与聚合，通过将繁重的探索工作下放给独立的子代理，主编排者（Orchestrator）仅需保留轻量级的结论。具体的工作流分为以下五个关键步骤：

• 分解任务：将大任务拆解为多个无共享可变状态的独立子任务。
• 编写简报：为每个子任务创建一份自包含的简报，明确目标、查找位置、返回格式及长度上限，并明确要求“不要粘贴完整文件内容”。你可以直接执行附带的 scripts/make_briefs.py 脚本，它将根据任务和子任务列表自动生成 N 份标准的简报文件。
• 成本路由：对于单纯的搜索和分类任务，使用 model:"lite" 以降低成本；仅在需要复杂综合推理时才使用默认模型。同时，务必设置 max_turns（如 8 到 15）来防止子代理陷入死循环。
• 并行执行：通过单条消息下发多个代理以实现并行，或使用 run_in_background:true 启动后台任务。
• 聚合结论：收集所有子代理返回的结构化摘要，整合成一份综合报告。

适用边界与注意点

• 紧耦合任务慎用：如果多个子任务需要依赖彼此的实时输出或共享演进中的上下文，使用单线程处理反而更划算。
• 避免过度拆分：建议的子代理数量上限约为 6 个，否则协调开销会抵消并行带来的收益，可将相关小项合并处理。
• 子代理盲区：由于子代理缺乏主上下文的历史记忆，简报必须编写得极其详尽且格式要求明确，否则容易产生误解或遗漏关键信息。