万字长文拆解Agent 架构设计（四）：多 Agent 协作

核心结论

多 Agent 协作真正切开的不是“能力”，而是“上下文”——父 Agent 负责规划和汇总，子 Agent 在全新上下文里吃掉局部大材料，最后只把最终结论带回，从而用更干净的桌面换取更稳定的判断。

分类提炼

知识节点（8 个独立概念）

关联图谱

上游（基于 / 来自）

下游（应用于 / 验证于）

同级（横向 / 并列）

正文要点（6 条）

  1. Claude Code 对多 Agent 的回答，不是把同一个模型硬拆成不同职能，而是把大任务拆成多个干净上下文。
    文章最重要的反直觉点是：子 Agent 并不因为“角色名不同”就更强，它之所以值钱，是因为只拿到一段任务描述和有限材料，能在更小上下文里集中注意力。

  2. 父 Agent 和子 Agent 的核心分工不是“谁更聪明”，而是“谁负责规划，谁负责执行”。
    父 Agent 有 task、只读工具和汇总责任；子 Agent 拥有 bash、write_file 之类副作用工具，但默认不能再派子 Agent。这样既防父线程绕过规划直接动环境，也防子线程无限递归。

  3. Task 是一个很薄的委派接口，真正的复杂度不在“调用方式”，而在“契约设计”。
    prompt 是唯一输入，子 Agent 定义文件则决定角色边界和权限。换句话说，多 Agent 的稳定性主要取决于你是否把任务说明、工具白名单和 system prompt 写成了清晰接口。

  4. “只交最后一条消息”是整个设计里最关键的压缩动作。
    子 Agent 的中间轨迹、工具详情和试错过程不自动回流父上下文，这个设计直接决定了父线程还能继续保持“桌面干净”，否则多 Agent 只会把多个长轨迹重新塞回同一窗口。

  5. 权限与预算的默认策略都是收缩，而不是扩张。
    子 Agent 的工具权限来源于交集裁剪，预算是从父线程继承后再向下分配，默认不能无限生长。这说明多 Agent 体系要先设计“怎么收口”，再设计“怎么变强”。

  6. 并行并不是框架层写死的 scheduler，而是模型利用 task 原语做出来的运行时选择。
    Claude Code 没有专门写一层显式并发调度器，哪些任务该并行、哪些该串行，仍然由模型根据上下文判断；框架真正提供的是安全护栏、权限边界和返回格式。

6 个对 Seetong / APP AI 开发流程可借鉴动作

  1. 把多 Agent 触发条件从“任务复杂”改成“上下文过载”：只有单个上下文已经吃不下、记不牢、聚不焦的任务，才值得拆子 Agent。
  2. 让主线程默认做编排，不直接拿高风险副作用工具：研究、排障、方案生成、知识库编译这类任务里，主线程优先负责拆解、指派和收束。
  3. 为每类子 Agent 固化三段定义：一句角色说明给父模型选人、一组工具白名单给权限系统、一段 system prompt 给子 Agent；不要混成一坨长说明。
  4. 子 Agent 强制只回传结构化结论：例如“结论 + 证据 + 风险 + 建议动作”，不要把整个思维轨迹和原始材料直接回灌父上下文。
  5. 所有子 Agent 权限走交集裁剪，默认禁递归派发：先把系统做成收敛的，再按需放开，而不是先给全权限再靠 prompt 劝它克制。
  6. 并行决策交给模型，但审计与预算交给系统：让模型判断读多个模块、查多份资料时是否要并行；系统负责记录预算、限制工具和收敛输出。

备注与限制

相关链接