AI 也能带团队：多 Agent 协作的设计艺术

一个人搞不定，就找帮手

你一定遇到过这样的场景：一个大型重构任务，涉及十几个文件、三四个模块，光是理清依赖关系就让人头大。如果是人类团队，项目经理会把任务拆解，分配给不同的开发者并行推进。

AI 能不能也这样干？

Claude Code 的回答是：能。而且它设计了一整套精巧的任务系统，让一个”主 Agent”像项目经理一样，指挥多个”子 Agent”协同工作。这不是简单的多线程调用，而是一个有状态管理、有权限隔离、有生命周期控制的完整协作框架。

今天，我们就来拆解这个”AI 团队管理”系统的设计艺术。

项目经理的工作哲学

想象一个优秀的项目经理是怎么工作的：

1. 1. 理解需求——老板说”把系统从 Python 2 升级到 Python 3”
2. 2. 拆解任务——梳理出要改的模块、要升级的依赖、要更新的测试
3. 3. 分配工作——前端交给小王，后端交给小李，测试交给小张
4. 4. 跟踪进度——时不时看看每个人的产出，遇到问题协调解决
5. 5. 整合结果——所有人的工作合并到一起，确保整体可用

Claude Code 的主 Agent 做的事情一模一样。当你给它一个复杂任务时，它可以创建子 Agent，把不同的子任务分配出去，然后监控每个子任务的状态，最终整合所有结果。

这一切的基础，就是任务系统。

七种武器：任务类型全览

Claude Code 的任务系统定义了 7 种任务类型，每种对应不同的协作场景：

这 7 种类型覆盖了从简单命令执行到复杂多 Agent 协作的所有场景。其中最有趣的是 in_process_teammate——这就是 Claude Code 的 Agent Swarms 能力，多个 Agent 在同一个进程中协同工作，共享状态、实时通信。

每种任务类型都有自己的 ID 前缀。比如 local_bash 任务的 ID 以 b 开头，local_agent 以 a 开头，in_process_teammate 以 t 开头。加上 8 位随机字符，一个任务 ID 就像 b1a2b3c4d5 这样，光看前缀就知道是什么类型的任务。

状态机：任务的生老病死

每个任务从创建到结束，都遵循一套严格的状态机模型。

任务状态机图

一个任务只有 5 种状态：

• • pending（等待中）——任务已创建，但还没开始执行
• • running（执行中）——任务正在跑
• • completed（已完成）——任务成功结束
• • failed（失败）——任务执行出错
• • killed（被终止）——任务被主动杀掉

状态转换的规则非常清晰：pending → running → completed/failed/killed。没有回退，没有跳跃，一旦进入终止状态（completed、failed、killed），就不能再变了。

这种设计看似简单，实则优雅。它让整个系统可以通过一个 isTerminalTaskStatus() 函数来判断任务是否已经结束，进而决定是否可以清理资源。想想看，如果状态转换可以随意来回跳转，光是判断”这个任务到底完没完”都会变成一个噩梦。

一个任务的完整生命周期是这样的：

1. 1. 创建阶段——生成唯一 ID，初始化状态为 pending，注册到全局状态，创建输出文件
2. 2. 执行阶段——状态切换为 running，启动子进程或子 Agent，开始流式写入输出
3. 3. 终结阶段——根据执行结果切换到 completed/failed/killed，记录结束时间，通知父级
4. 4. 查询阶段——任何时候都可以查看任务状态、读取任务输出
5. 5. 清理阶段——从全局状态中移除，删除输出文件

每个任务的输出都存储在磁盘文件中，并且支持增量读取。主 Agent 可以随时通过 offset 参数来获取子任务的最新进展，就像项目经理翻看开发者的工作日志一样。

Agent Swarms：同一个屋檐下的团队

如果说 local_agent 是”派一个人去出差独立完成任务”，那么 in_process_teammate（Agent Swarms）就是”大家坐在同一间办公室里一起干”。

多Agent协作图

Agent Swarms 的核心架构是这样的：

• • AgentTool——创建 local_agent 类型的子 Agent，每个子 Agent 是一个独立任务
• • TeamCreateTool——创建 in_process_teammate 类型的 Teammate，在同一进程内运行
• • SendMessageTool——Agent 之间的通信管道，通过 AppState 中的 mailbox 传递消息
• • TaskOutputTool——父 Agent 用来读取子 Agent 产出的窗口

Teammate 模式特别有意思。想象一下，主 Agent 发现一个前端重构任务需要同时处理 CSS 迁移和组件改造，它可以创建两个 Teammate：一个专门处理样式，一个专门处理组件。这两个 Teammate 在同一个进程内运行，共享文件状态缓存，可以通过 mailbox 互相通信——“我这边的样式变量已经改好了，你可以开始用新变量名了。”

这和真实团队的协作多像：同一个项目组的人，共享 Git 仓库，通过消息互相通知进度。

但多人协作最大的问题是什么？权限和安全。你不会希望实习生有权限删除生产数据库吧？

权限冒泡：给实习生一把合适的钥匙

Claude Code 的权限系统有 7 种模式，其中有一种专门为子 Agent 设计：bubble 模式。

顾名思义，就是权限请求像气泡一样”冒泡”到父级去处理。

具体是怎么运作的呢？当主 Agent 创建一个子 Agent 时：

• • 子 Agent 继承父级的 deny 规则——父级不允许做的事，子 Agent 也不能做
• • 子 Agent 继承父级的 allow 规则——父级已授权的操作，子 Agent 可以直接使用
• • 子 Agent 的权限模式可以不同于父级：
• • 后台 Agent 设置 shouldAvoidPermissionPrompts=true，尽量避免打扰用户
• • Coordinator Worker 设置 awaitAutomatedChecksBeforeDialog=true，先做自动检查
• • In-process Teammate 使用 bubble 模式，权限请求冒泡到主 Agent
• • 每个子 Agent 有独立的拒绝追踪状态，防止某个子 Agent 因为一个操作被拒而反复重试

这种设计的精妙之处在于：子 Agent 不需要自己决定什么操作是安全的——它把这个决定权交给父级，最终交给用户。就像公司里的权限审批流程：新员工想访问某个系统，不是自己开权限，而是向经理申请，经理根据情况批准或拒绝。

而拒绝追踪机制更是一个贴心的设计。如果一个子 Agent 连续 N 次被拒绝同一类操作，系统会自动调整策略，而不是像个执拗的孩子一样不停地问”我可以吗？我可以吗？”

Bridge 系统：AI 团队的远程协作平台

当你在 VS Code 或 JetBrains 中使用 Claude Code 时，背后是 Bridge 系统在搭桥。在 Agent Swarms 场景下，Bridge 的角色更加关键：

IDE 通过 Bridge 连接到主 Agent（Coordinator），而主 Agent 下面可能有 Agent A、Agent B、Agent C 在并行工作。IDE 能实时接收所有 Agent 的状态更新——你能在 IDE 里看到整个”AI 团队”的工作进展。

Bridge V2 使用 SSE（Server-Sent Events）实时推送状态，主 Agent 的每一个决策、子 Agent 的每一个输出，都能实时反映到 IDE 界面上。这就像项目管理工具里的实时看板——你不需要逐个询问进度，所有信息自动呈现。

会话恢复：读档与续集

多 Agent 协作的任务往往不是一次能完成的。如果中途退出了怎么办？Claude Code 提供了两种恢复方式：--resume 和 --continue。

它们的区别，用一个比喻就能说清楚：

• • -resume = 游戏读档。你从上次退出的地方完全恢复，所有状态原封不动，就像时间暂停了一样。该跑的任务继续跑，该等的结果继续等。
• • -continue = 看完上集摘要开始新一集。系统会总结之前的进展，然后开始一个新的对话。你知道之前做了什么，但不是回到那个时间点。
• • -resume 恢复的状态有 7 大类：

1. 1. 消息历史——之前所有的对话内容
2. 2. 文件历史快照——哪些文件被修改过，修改前是什么样
3. 3. 归属状态——哪些代码变更是 AI 做的（用于 commit 归属）
4. 4. 上下文折叠提交——之前提到过的 Git 提交信息
5. 5. TODO 列表——之前规划的任务清单
6. 6. Agent 设置——子 Agent 的配置和状态
7. 7. Worktree 状态——Git 工作树的状态

此外还有一个容易被忽略但非常关键的状态：成本追踪。

Claude Code 的成本追踪器会记录每次 API 调用的 token 消耗（输入、输出、缓存读取、缓存写入）并计算费用。当你 --resume 一个会话时，之前累积的成本也会恢复，这样你看到的费用是整个任务的真实总成本，而不只是本次会话的开销。

成本数据通过 projectConfig 持久化到项目配置中，格式类似：sessions.{sessionId}.costs。每次会话结束时保存，恢复时读取。在多 Agent 场景下，这意味着主 Agent 和所有子 Agent 的开销都被精确记录。

Dream 模式：AI 的”夜间值班”

在 7 种任务类型中，dream 是最神秘的一种。

Dream 模式的理念是：AI 可以在”空闲时间”做一些后台分析工作。就像人类开发者有时候会在下班后想想明天的架构方案，Dream 任务在后台执行代码分析或预计算，为后续的交互做准备。

虽然 Dream 的具体功能还没有完全公开，但从任务系统的设计中可以看出，它和其他任务类型遵循完全相同的生命周期管理——创建、执行、完成或失败，一切都在状态机的控制下有序运行。

从独行侠到 AI 团队

回顾 Claude Code 的多 Agent 协作设计，我们能看到一条清晰的演进路线：

单 Agent → 一个 AI 独立完成所有工作，适合简单任务。

多 Agent（本地子 Agent）→ 主 Agent 派出独立的子 Agent，各自完成分配的任务，通过输出文件传递结果。适合可以明确拆分的并行任务。

Agent Swarms（进程内 Teammate）→ 多个 Agent 在同一进程内协作，共享状态，实时通信。适合紧密耦合、需要频繁协调的复杂任务。

跨会话持久化 → 通过 --resume/--continue 和成本追踪，让多 Agent 协作可以跨越时间边界，不必一次完成。

跨机器协作（远程 Agent）→ 通过 Bridge V2 和 CCR Client，Agent 甚至可以跨越物理机器的边界协作。

这不仅仅是技术能力的堆叠，更是一种设计哲学的体现：把人类团队协作中验证过的模式——任务拆解、权限管理、进度跟踪、状态持久化——移植到 AI 系统中。

如果把单个 Agent 比作一个全栈工程师，那多 Agent 系统就是一个有组织、有分工的开发团队。项目经理（主 Agent）不需要亲自写每一行代码，它需要的是理解全局、合理分工、有效协调。

而这，或许才是 AI 走向真正实用化的关键一步——不是打造一个无所不能的超级 AI，而是让多个各有所长的 AI 学会协作。就像人类社会一样，团队的力量永远大于个人。

下一篇，我们将进入 Claude Code 的最后一个核心模块——看看这个复杂的系统是如何测试和保障质量的。