Part V: 多智能体 -- 从独行侠到团队

一个 Agent 不够用时，怎么变成一支队伍？

这个 Part 要解决什么问题

让 Agent 重构一个认证模块。它需要先调研现有实现，再修改代码，最后跑测试验证。三件事串行执行效率低下，更麻烦的是，调研过程产生的大量中间信息会污染工作上下文，等到真正动手改代码时，关键信息已被淹没在几十轮对话里。

多智能体的根本问题是：如何让一个 Agent 体系既能并行工作，又能保持每个工作者的上下文纯净？ 再进一步：谁来决定创建几个子 Agent、分别做什么、结果怎么汇总？树形的父子结构够用吗，还是需要网状的对等通信？

Part V 用四章构建了从最简到最复杂的多智能体光谱。从单个子 Agent 的创建和隔离，到协调者模式的四阶段编排，从后台任务的基础设施，到 Team/Swarm 的群体智能。复杂度逐级递增，但每一级都在前一级的基础上自然生长。

包含章节

Chapter 12: 子 Agent 的诞生 -- fork、隔离与通信。 两条创建路径：空白 Agent（轻装上阵）和 fork Agent（继承全部认知）。fork 路径的精密工程——为什么工具集要字节级一致？为什么系统提示词要冻结传递？如何用软硬两道防线防止无限递归？

Chapter 13: 协调者模式 -- 四阶段编排法。 项目经理不写代码，好的协调者也不碰文件。四阶段工作流（Research --> Synthesis --> Implementation --> Verification）如何让理解问题和解决问题分离？为什么 Coordinator 的工具集被精简到只有三个？

Chapter 14: 任务系统 -- 后台并行的基础设施。 子 Agent 和 Worker 在后台运行时，前台怎么知道它们的状态？任务创建、监控、中止的完整生命周期。进度通知如何非侵入地出现在用户视野中？

Chapter 15: Team 与 Swarm -- 群体智能的实现。 从树形到网状是复杂度的质变。Team 的文件系统配置中心、双通道身份识别、Mailbox 消息路由。为什么团队结构必须扁平（Leader + Members，不允许递归）？权限白名单如何让 Leader 一次审批全队共享？

与其他 Part 的关系

• 前置知识：Part II 的 Agent Loop（子 Agent 运行自己的循环），Part III 的工具系统（AgentTool 和 TeamCreate 是多智能体的入口工具），Part IV 的权限模型（子 Agent 的权限继承和 Team 权限白名单）。
• 后续延伸：Part V 的子 Agent fork 机制是 Part VIII Chapter 21（Dream 系统）的运行时基础——Dream 本质上是一个受限的 fork 子 Agent 在后台执行记忆整合。协调者模式中 Worker 的系统提示词构建与 Part VI 的 System Prompt 工程紧密关联。