Claude Code 的多 Agent 与子任务机制

它早就不只是单线程助手了

如果只把 Claude Code 看成“一个主对话框里的模型”，你会错过它很重要的一条演化方向：
它已经明显在支持多 Agent、子任务和协作型运行。

从源码能看到几个非常关键的信号：

• AgentTool
• SendMessageTool
• TeamCreateTool
• TaskCreateTool
• agentNameRegistry
• viewingAgentTaskId

这已经不是单线程工具的思路了。

先看它在工具层的入口

export function getAllBaseTools(): Tools {
  return [
    AgentTool,
    ...
    ...(isTodoV2Enabled()
      ? [TaskCreateTool, TaskGetTool, TaskUpdateTool, TaskListTool]
      : []),
    getSendMessageTool(),
    ...(isAgentSwarmsEnabled()
      ? [getTeamCreateTool(), getTeamDeleteTool()]
      : []),
  ]
}

这段代码最重要的结论是：

多 Agent 能力不是隐藏实验，而是被当成正式工具体系的一部分。

先看结构图

状态层已经为多 Agent 预留了很多位置

来看 AppStateStore.ts 里的片段：

tasks: { [taskId: string]: TaskState }
agentNameRegistry: Map<string, AgentId>
foregroundedTaskId?: string
viewingAgentTaskId?: string

这几个字段很能说明问题：

• 系统内部有统一的任务表
• Agent 可以按名字注册和路由
• 某个任务可以被 foreground
• 还可以单独查看某个 Agent 的转录

这说明 UI 层和运行时层都已经接受了“不是只有一个主线程”的事实。

为什么要做多 Agent

因为复杂工程任务经常天然可拆分，例如：

• 一个 Agent 查代码结构
• 一个 Agent 跑测试和日志
• 一个 Agent 处理某个子模块
• 主线程最后汇总

如果所有事情都塞给一个上下文窗口，效率和稳定性都会下降。

它的本质不是“几个模型聊天”，而是任务分工

也就是说，多 Agent 机制的目标不是炫技，而是把复杂任务拆成更稳定的小块。

为什么这里一定要和状态系统绑定

只要有多个 Agent，就会立刻出现这些问题：

• 哪个任务正在前台显示
• 哪个 Agent 正在被查看
• 名称如何路由到具体 Agent
• 任务怎么暂停、恢复、后台化

所以多 Agent 能力不可能只写在工具层里，它一定会深入状态管理。

小结

Claude Code 的多 Agent 与子任务机制说明了一件事：

它已经不满足于做一个单线程开发助手，而是在向“任务可拆分、角色可协作”的智能体运行平台演化。

这也是它和普通代码生成器越来越不一样的地方。