独自掌控 8 个会话！Claude Code 编排完整指南

“我在用 Claude Code，但规模一上去，上下文就溢出，精准度也掉下来了。”

“到最后，我自己动手给 AI 下达修正指令，反而成了最大的瓶颈。”

很多人大概都会卡在这个阶段。一开始我也是这样，把代码、测试、设计讨论全塞进一个会话里，眼睁睁看着 Claude 的准确率随着历史记录越来越长而下降。

我最近才意识到，Claude Code 官方其实提供了三种机制来并行运行多个会话。

而且，这三种机制类似但又各有不同，搞混了容易出问题。反过来，如果能按角色将它们区分开，你甚至不需要自己写一行代码，就能站到“指挥者”的一侧。

今天，我就来梳理一下这三种机制，以及在查阅官方文档一手信息的同时，固定角色边界的正确方法。

具体来说，我会把它拆解成一个三层结构（指挥、执行、质量），部署 8 个会话的配置。

作为 bonus，我还会用一手信息来解释，为什么像“在 CLAUDE.md 里写角色 ID 来切换”或“用 SQLite 共享记忆”这样的常见说法，和官方机制有点出入。

我是 tatsuki（@nobel_824）。

我在协助中小企业运用 AI，帮他们把 Claude / Codex 落地到业务中，同时自己每天也在跑 Claude Code。并行操作是我在工作和个人项目中每天都会接触的领域。

https://note.com/nobel/n/n8192ec07d689

1. 为什么"把所有东西塞进一个会话"会失败

第一个陷阱就是在一个会话里塞进太多信息。不管 Claude 模型多聪明，它都会遇到结构性的限制。

具体来说，你会遇到这三个问题：

上下文污染：当实现代码、测试、调试历史、设计讨论混在同一个上下文里，推理的基础就会变得模糊，准确率下降。
指令冲突：如果同一个地方既有“优先速度实现”，又有“严格把关安全”，判断就会变得模棱两可。
Token 膨胀：每次都加载庞大的历史记录，既浪费时间也浪费成本。

解决方法就是“让自己成为唯一的指挥官，排好一列专精的 Claude”。这有点像 CTO 下面有 Tech Lead 和 Backend Lead，但重要的不是感觉，而是正确利用官方的 Claude Code 机制。

你今天就能做的一件事：想想你当前的会话，检查一下“实现”、“研究”和“审查”是不是共存于一个上下文里。如果是，那就是你开始拆分的起点。

2. 纠正官方提供的“三种并行机制”

这是文章的核心。Claude Code 有三种并行机制，各自的适用范围不同。

第一种是 subagent（一个独立于主会话上下文的辅助 AI）。它用自己的上下文窗口、专属的系统提示和受限的工具权限来执行研究或审查等辅助任务，只把结果摘要返回给主会话。关键在于，subagent 在同一个会话内运行，只向主会话报告，并且 subagent 之间不能互相通信（官方文档）。

第二种是 agent teams（多个 Claude Code 会话作为团队协作的机制）。一个会话成为团队领导，生成队友，通过共享的任务列表和邮箱进行协作。与 subagent 不同，队友之间可以直接发送消息。这是一个实验性功能，默认是关闭的。你需要设置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 并使用 Claude Code v2.1.32 或更高版本（官方文档）。

第三种是 git worktree（一个 Git 功能，允许同一个仓库有多个工作目录）。通过 claude --worktree feature-auth 启动，Claude 会在一个不同分支/目录的隔离环境中运行。如果在另一个终端再运行一个，它们就能并行运行，不会互相干扰文件（官方文档）。使用桌面版应用时，每个新会话都会自动创建一个 worktree。

下面是三种机制的对比表：

只要记住 worktree 负责文件隔离，而 subagent 和 agent teams 负责工作本身的协调，你就不会混淆。

你今天就能做的一件事：先试试输入 claude --worktree bugfix-test，感受一下启动一个隔离会话。修改完成后结束时，它会询问是保留还是删除这个 worktree。

3. 实践：用“3 层结构”部署 8 个会话

这三种机制如何落实到 8 个会话上？我使用的布局分为指挥层、执行层和质量层。

指挥/设计层（2 个会话）

会话 1 PM（项目经理）：整体进度管理、任务拆解、向人类报告。
会话 2 架构师：决定技术一致性和目录结构。需要方案审批才能输出设计，不写代码。

执行/实现层（4 个会话）

会话 3 前端：组件创建、UI 调整。
会话 4 后端：接口实现、查询优化。
会话 5 基础架构/DevOps：Docker、CI/CD 维护。
会话 6 安全：漏洞检查、加固认证。

质量/维护层（2 个会话）

会话 7 QA/审查员：PR 审查、指出边界情况。
会话 8 技术文档写手：README、API 文档维护。

这个布局有三个要点：用 worktree 隔离实现层的四个会话，防止它们互相干扰文件。把质量层的角色固定为 subagent 定义或 agent teams 的队友。让每个会话通过共享的 Markdown 文件（设计说明或审查结果）来传递信息。架构师更新设计，实现层基于设计来行动，审查员把结果写回去。人类只需要在这些文件更新时，对每个会话下达指令。

需要注意的是：一个 agent team 的官方建议人数是 3–5 人，所以不要一次性把 8 个都塞进一个团队（官方文档）。更安全的做法是，结合使用 worktree 隔离的会话、一个 3–5 人的 agent team，以及按需添加的 subagent，总共达到 8 个工作者。

你今天就能做的一件事：从上面 8 个角色中，选择两个你觉得在当前项目中容易拆分出来的。很多情况下，架构师和审查员会是优先拆分的对象。

4. 用“Subagent 定义”而非“CLAUDE.md”来固定角色边界

关于并行操作，我要纠正一个常见的误解。你可能会看到一些解释，比如“在 CLAUDE.md 里写角色（ID: arch, ID: dev-main...），启动时切换身份”，但这种机制实际上并不存在。

CLAUDE.md 是 Claude Code 启动时读取的一个共享指令文件。然而，官方文档明确指出，CLAUDE.md 是“上下文，而非强制设置”。由于它是在系统提示之后作为用户消息传递的，所以不保证严格遵循。如果你一定要阻止某件事，应该使用 hooks（官方文档）。把它看作一个强有力的建议，而不是绝对的“宪法”。

那么，该在哪里固定角色呢？答案是 subagent 定义。通过在 .claude/agents/ 目录下放置一个文件，并在 frontmatter 中包含名称、描述、可用工具和模型，你就完成了一个可复用的专家。这是一个最小示例：

name: security-reviewer

description: 从认证、输入验证和会话管理的角度对代码进行严格审计。

tools: Read, Grep, Bash

model: sonnet

你是一位资深安全审查员。重点关注 token 处理、

会话管理和输入验证，并根据严重程度报告发现的问题。

此外，这些定义可以作为队友在 agent teams 中通过名称被调用。如果要求“设置一个 security-reviewer 类型的队友来审计 auth 模块”，它就会成为一个继承该定义中工具和模型的成员（官方文档）。这样设计的好处是，你只需编写一次角色作为 subagent 定义，就能同时作为 subagent 和团队成员复用。

可以尝试的提示示例（让 Claude 创建角色定义）：

创建一个要放在 .claude/agents/ 中的 subagent 定义。

这个角色的作用是“审查实现代码中的性能问题和 N+1 查询”。

在 frontmatter 中包含 name / description / tools / model，

并以资深工程师的身份编写正文。

5. 使用 Agent Teams 构建“架构师-审查员”团队来提升准确性

并行操作中一个非常有效的配置是，分别设置一个“创造者”和一个“质疑者”。这不仅仅是理论，官方文档提供了实际案例。

在官方的“并行代码审查”示例中，针对一个 PR，设置了三个队友分别负责安全、性能和测试覆盖率，各自从不同角度审查，同时由领导整合结果。此外，在“竞争性假设”示例中，五个队友被分配针对一个 bug 的不同假设，互相争论并反驳对方的理论，最后幸存的理论被视为根本原因（官方文档）。因为单个调查者容易偏向第一个理论，这种方法刻意制造冲突来提高准确性。

你也可以利用官方功能，让架构师“不被赋予写代码的权限”。通过要求队友的方案需要审批，该队友会保持在只读的方案模式，只输出设计，直到领导批准。审批标准可以写在领导的提示中，例如“只批准包含测试覆盖率的方案”。

可以尝试的提示示例（一次性创建冲突结构）：

创建一个 agent team 来审查 PR #142。设置三个队友：

一个负责安全，一个负责性能，一个负责测试覆盖率。

让他们独立审查，输出带有严重程度的发现，最后整合结果。

有两种显示模式：in-process（所有队友在同一个终端运行，用 Shift+Down 循环切换）和 split panes（每个队友在单独的窗格；需要 tmux 或 iTerm2）。从 in-process 开始更容易，因为它不需要额外设置。

6. 通过官方 Auto Memory（Markdown）而非“SQLite”来共享记忆

在运行多个会话时，下一个障碍是“跨会话的记忆共享”。虽然有时会介绍一些高级技巧，比如“在 SQLite 中存储带标签的记忆并动态注入”，但这并不是 Claude Code 的标准功能。通过 MCP（模型上下文协议）搭建数据库是可行的，但你应该将其与官方提供的记忆机制区分开来。

官方的 auto memory 使用的是 Markdown 文件。在 ~/.claude/projects/<项目>/memory/ 目录下，放置类似 MEMORY.md（索引）和特定主题的文件（如 debugging.md），Claude 在工作时会写入这些文件。加载规则很清晰：每个会话都会读取 MEMORY.md 的前 200 行或 25KB，Claude 只在需要时才会读取特定主题的文件。该功能从 Claude Code v2.1.59 开始可用，按仓库保存（因此在 worktree 之间共享），并存储在本地（官方文档）。

这种设计的美妙之处在于，“始终加载索引，只在需要时获取细节”，从而保持上下文窗口的整洁。即使有成千上万条小规则，只要索引不膨胀，上下文就不会每次都被污染。

按照顺序，你应该先充分利用官方的 Markdown 基础 auto memory，然后再考虑构建自定义的 SQLite 解决方案。

你今天就能做的一件事：在会话中键入 /memory 可以查看当前加载的 CLAUDE.md 和 auto memory 文件列表。先瞄一眼，看看你的记忆文件在哪里、有多少。

7. 并行操作中的三个陷阱（成本、数据库、权限）

现在你已经理解了机制，这里还有三个操作上的注意事项。

首先是 Token 成本。官方文档指出，由于 agent team 中的每个队友都有独立的上下文，Token 使用量会随着人数成比例增加。对日常任务使用 5 个人会导致成本上的亏损。这就是官方推荐 3–5 人的原因，并指出“三个专注的成员往往胜过五个分心的成员”（官方文档）。

其次是 worktree 的隔离范围。Worktree 只是用于文件分离的 Git 机制；数据库、环境变量和运行中的服务仍然是共享的。如果两个会话对同一个本地数据库运行迁移，就会出问题。官方文档警告要在每个 worktree 中初始化开发环境（安装依赖、设置虚拟环境），如果任务涉及到数据库，则需要分离 schema、Docker 容器或 .env 文件（官方文档）。

第三是权限。队友在生成时会继承领导的权限设置。如果你使用 --dangerously-skip-permissions 运行领导，所有队友也会处于同样的未确认状态。由于事故的影响会并行扩散，更安全的做法是在领导端限制权限。

8. 面向中高级用户的常见问题：人数、扩展和质量门禁

最后，对一些常见问题做一些补充回答。

问：多少个会话比较现实？

一个很好的指南是前面提到的 3 层、8 个会话的结构。关键不是把 8 个人都塞进一个 agent team，而是以一个 3–5 人的团队为核心，再加上 worktree 会话或 subagent。这与官方建议（每队 3–5 人，每位队友 5–6 个任务）相符。最终的极限是你能够监控和掌控的范围。如果数量增加到超出你的指挥能力，效率就会下降。

问：如果 subagent 和 agent teams 不够用了怎么办？

如果你想从一个地方监控大量独立的会话，官方关于 subagent 的页面提到了一种叫做 background agents 的机制。可以按层级来理解：subagent 用于会话内的辅助，agent teams 用于会话式的并行团队，而 background agents 用于管理大量独立的会话。

问：如何保证质量？

CLAUDE.md 中的建议只是“易于遵循的指示”。对于你绝对想要执行的检查，需要通过 hooks 来强制执行。Agent teams 有像 TeammateIdle、TaskCreated 和 TaskCompleted 这样的 hooks；返回退出码 2 会发送反馈并强制工作继续（官方文档）。这意味着你可以通过编程方式强制执行规则，比如“在测试通过之前不得完成”。

总结：从监控者到设计者/授权者

Claude Code 的价值不仅仅在于更快地写代码，更在于一个人可以控制多个专精的 Claude。以下是关键要点：

不要混淆三种机制：subagent 返回结果，agent teams 是会话式的团队，worktrees 隔离文件。将 8 个会话分为指挥层、实现层和质量层；用 worktree 隔离实现层，用 subagent 定义或 agent teams 固定质量层的角色。在 subagent 定义中固定角色边界，而不是在 CLAUDE.md 中，并用 hooks 强制执行绝对规则。在构建自定义 SQLite 方案之前，先充分利用官方的 Markdown 基础 auto memory。每队以 3–5 人为目标，通过增加层级构建起 8 个工作者。

今天就尝试的 3 个步骤：