7
0本章的主题是 “Teams 与多进程协作”。这一章深入剖析了 Claude Code 的 Swarm 团队协作机制 —— 一种基于平面结构的多 Agent 协作模型。与第20章介绍的“父子层级”派生模型不同，Teams 系统通过构建一个平面的团队，利用消息传递、共享状态和分布式调度来完成复杂任务。
以下是该章节的核心内容总结：
1. 核心定位：平面 Swarm 协作模型
平面结构约束：系统通过
TeamCreateTool创建团队，团队名册（TeamFile）是一个扁平数组。为了防止协调逻辑混乱，系统设定了强硬的架构约束：队友不能派生其他队友，且进程内队友不能派生后台 Agent。身份标识：队友使用
TeammateAgentContext上下文，其 ID 格式统一为name@team-name（如researcher@my-team），在 UI 中会被自动分配不同的终端颜色，便于一眼识别身份和归属。
2. 调度内核：共享任务图（TaskList & DAG）
Teams 的核心价值不在于“聊天”，而在于共享任务图（Shared Task Graph）：
Team = TaskList：团队与任务列表是一对一绑定的，创建团队的同时就会初始化对应的任务目录。
DAG 任务依赖：任务不仅有状态，还包含
blocks和blockedBy字段，将其从普通的 Todo 清单提升为显式的有向无环图（DAG）依赖节点。任务只有在所有前置依赖（Blockers）都完成后才变为可执行状态。自动抢占（Auto Claim）：运行时通过
useTaskListWatcher.ts监听任务目录。当 Agent 空闲或目录变化时，系统会自动筛选并抢占（claim）一个满足条件（pending、无 owner、无 blocker）的任务并分发给 Agent 执行。这实现了调度与推理的分离，Agent 之间不需要复杂的自然语言协商，冲突直接由运行时的状态机原子锁解决。事件驱动收尾：任务完成后，会触发
TaskCompleted和TeammateIdle专用事件钩子，用于通知 Leader 或驱动后续自动化流程。
3. Mailbox 通信协议与结果回传
SendMessageTool 寻址：支持多种寻址方式，包括具体队友名称、广播（
*）、本地 IPC 套接字（uds:）以及远程控制节点。文件系统邮箱：消息异步写入本地目录
~/.claude/teams/{teamName}/inboxes/{agentName}.json。并发控制通过async lockfile和指数退避重试来保证安全。控制消息：邮箱不仅传递文本，还承载结构化的 JSON 控制命令，如
idle通知、shutdown_request/response（优雅关闭）和plan_approval_response（计划审批）。Worker 结果回传：在协调者模式下，Worker 的工作结果会格式化为
4. 三种物理后端与进程隔离
系统支持三种物理后端，通过统一的接口管理，由运行时自动选择最优方案：
Tmux：独立 CLI 进程，在 tmux 中分屏显示，是 Linux/macOS 的默认后端。
iTerm2：独立 CLI 进程，在 iTerm2 中分屏显示。
In-Process（进程内回退）：无 tmux/iTerm2 环境时，在同一进程内运行，通过
AsyncLocalStorage隔离上下文，消息通信改用内存队列。
5. 权限同步与 Leader 代理审批
为了确保安全，运行在独立进程或分屏中的队友无权自行审批危险工具调用：
当 Worker 触发权限检查时，会创建审批请求写入
permissions/pending/并发送到 Leader 的邮箱。Leader 轮询并检测到请求后，在其终端向用户展示并等待审批。
审批通过后，结果写入
permissions/resolved/，Worker 轮询获取结果后继续执行，确保人类对危险操作拥有绝对控制权。
6. 共享团队记忆（Team Memory）
团队成员共享位于
~/.claude/projects/{project}/memory/team/MEMORY.md的团队记忆，与个人记忆相互独立。为了防止恶意项目代码通过路径逃逸攻击团队记忆，系统建立了极其严密的路径安全验证，能强力拦截空字符（Null byte）注入、URL 编码遍历、Unicode 正规化攻击以及符号链接循环（ELOOP）等漏洞。
7. 工程设计模式：基于文件系统的状态外化
Teams 做出了一个务实且反直觉的设计选择：用本地文件系统邮箱代替传统的 IPC/RPC。这种“共享状态”而非“共享内存”的设计，在 Agent 协作场景下带来了显著的优势：进程崩溃后消息不丢失（高持久性）、可以直接使用 cat 命令调试（高可观测性），且天然支持锁机制。
