多开 Claude Code 就是在做 Multi-Agent：编排的真相与选型
先说结论：你多开的每个窗口，就是一个独立 Agent
很多人以为 Multi-Agent 是什么高深框架、要装 LangGraph 配 AutoGen 才算入门。不是。
当你打开三个终端窗口，一个跑后端、一个写前端、一个做集成的时候——你已经在做 Multi-Agent 了。
这不是类比，是字面意义：
| 你做的事 | Multi-Agent 术语 |
|---|---|
| 每个窗口独立运行，各自上下文互不干扰 | 独立 Agent + Context Isolation |
| 把中间结果记在 XMind/共享文档里，不直接让窗口之间对话 | 共享黑板（Blackboard Architecture） |
| 你判断谁先谁后、哪些能并发、哪些必须串行 | Orchestrator（任务编排） |
这套操作实际上是 Multi-Agent System + Context Isolation + 外部记忆层 的完整实现。不是"像"Multi-Agent，是"就是"Multi-Agent——只不过 Orchestrator 是你的大脑，黑板是你的 XMind，通信协议是你的肉眼。隔离 > 压缩——这是业内现在公认唯一能 scale 的底座思路。与其执着于更长的上下文窗口（Long Context），不如做好精准的上下文注入和隔离。你的物理多开，硬生生把这块地基打牢了。
单窗口 vs 多窗口：核心差异矩阵
| 维度 | 单窗口（串行） | 多窗口（并发） |
|---|---|---|
| 核心优势 | 全局视野极佳，跨模块逻辑连贯 | 上下文绝对纯净，无干扰并发 |
| 致命弱点 | 上下文滚雪球，历史污染严重 | 缺乏原生全局观，需要人工协调 |
| Token 消耗 | 极高（每次对话携带大量历史包袱） | 按需加载，用完即走 |
| 最佳战场 | 强耦合的长链条任务、巨型重构 | 独立模块的并行开发、批量 CRUD |
多窗口通过物理隔离实现高内聚、低耦合的并发处理，确保单点任务极致准确率；单窗口共享同一套上下文空间，逻辑连贯性强，但随着上下文膨胀，极易引发"幻觉传染"与准确率断崖式下跌。
核心判断：能拆就拆，能隔就隔。
用一个案例感受：多窗口 = Multi-Agent 编排
光说概念没体感，用点赞功能看一下多窗口编排到底在编排什么。
"用户可以给文章点赞，再点一次取消"——按五步拆解法走到第四步（原子任务颗粒度），产出 6 个原子任务，后端链路 Model → DTO → Service → Controller：
点赞功能（互动功能模块）
├── 原子任务 1：ArticleLikes Model + 联合唯一索引
├── 原子任务 2：ToggleLikeRequestDto / ToggleLikeResponseDto
├── 原子任务 3：ArticleService.toggleLike（事务：关系增删 + 计数更新）
├── 原子任务 4：ArticleController.toggleLike（Guard + 参数校验）
├── 原子任务 5：前端 LikeButton 组件 UI 绘制
└── 原子任务 6：前端接口定义 DTO 及页面调用接口
这些任务不是拍脑袋拆的——它们经过了三层分工的过滤：领域拆分（人类把项目切成独立模块）→ 宏观编排（人类定下模块间的规则和依赖）→ 微观执行（AI 按原子任务颗粒度执行，人 Review）。五步拆解法就是把这三层分工落地的操作方法。
多窗口并发的第一步不是"开几个窗口"，而是画依赖图：
| 任务 | 依赖 | 可并发 | 并发窗口 |
|---|---|---|---|
| 任务 1：Model | 无 | ✅ 可并发 | 窗口 A |
| 任务 2：DTO | 1 | ❌ 等 1 | 窗口 A |
| 任务 3：Service | 1、2 | ❌ 等 1、2 | 窗口 A |
| 任务 4：Controller | 2、3 | ❌ 等 2、3 | 窗口 A |
| 任务 5：前端组件 UI 绘制 | 无 | ✅ 可并发 | 窗口 B |
| 任务 6：前端接口定义 DTO 及页面调用接口 | 2、5 | 🟡 DTO 完成后即可 | 窗口 B |
关键并发点有两个：
- 任务 1（Model）和任务 5（前端 UI 绘制）可以同时启动——UI 绘制不依赖任何后端产出
- 任务 2（DTO）完成后，窗口 A 继续推进 Service → Controller，窗口 B 同时开始任务 6——DTO 就是前后端的契约，契约一定，两边各自开工
你不是在开窗口，你是在做 Multi-Agent 编排。 Orchestrator（你的大脑）做领域拆分和宏观编排，每个窗口是独立 Agent 做微观执行。下一篇文章会用这个案例走完整链路。
Claude Code 官方解法：Subagents 与 Agent Teams
既然"手动多开"本质就是 Multi-Agent，Claude Code 官方有没有把这层能力内建？有，给了两个层级。
Subagents：稳定的并行执行单元
每个 Subagent 在自己的 context window 中运行，主代理分发任务，拿到摘要结果后做整合。
核心特征：
- 独立上下文：互不污染
- 结果摘要：只把摘要返回主会话，不把中间过程全量灌回
- 星形拓扑：N 个子 agent 各自独立、只跟主 agent 通话，消息边数 O(N)
- 官方稳定能力：不是 experimental，生产环境可用
Subagents 把你手动多开中最常用的 80% 做成了产品机制——它就是你手动多窗口的框架化版本。
Agent Teams：方向对，但现在不能用
Agent Teams 在 Subagents 基础上补了"对等通信 + 自协调"——共享任务列表、队友间直接消息、Lead 审批工作流。架构意图是对的，但官方自己把它标成 experimental、默认关闭，且明确列了 known limitations。
当前核心问题：
- 会话恢复不行：
/resume无法恢复 in-process teammates，中断后团队状态要重建 - 任务状态会丢：teammates 有时忘了标记 completed，下游依赖卡死
- Token 消耗约 7 倍：实测数据，对个人订阅者配额烧穿
- CLAUDE.md 不加载：子 agent 不读项目规范，产出质量无法预期
一个稳定到默认开启（Subagent），一个实验到默认关闭（Agent Teams）——产品状态自己已经把答案说清楚了。现阶段不要在生产流程中使用 Agent Teams，了解它的发展方向即可。
务实选型：两种模式各归其位
| 场景 | 推荐 | 为什么 |
|---|---|---|
| 独立子任务并行跑，只要结果摘要回主会话 | ✅ Subagents（稳定） | 污染隔离，结果只汇摘要；官方稳定能力 |
| 你想靠"肉眼+XMind"把控边界 | 继续手动多窗口 | 隔离正确性不输框架，且拥有完全可控性 |
对绝大多数日常开发，Subagent 已经够了——三个子 agent 拆任务跑、独立上下文回报，wall time 接近最慢的那一支。手动多窗口是 Subagents 的"人肉版"，隔离效果相同，多一层可控性。
Agent Teams 等它摘掉 experimental 标签、修掉核心问题再说。
一句话收束
你多开 Claude Code 窗口，本质上就是在做 Multi-Agent 编排——独立 Agent、共享黑板、你当 Orchestrator。这在工程上命中了正确解：隔离 > 压缩。三层分工决定了谁做决策谁做执行，五步拆解法把复杂需求变成可编排的原子任务，多窗口是微观执行层的并发实现。Subagents 把这层做稳了；Agent Teams 方向对但现阶段不可用，别当成熟产品闭眼托付。
正确的姿势：日常用 Subagents 做并行执行，手动多窗口始终是兜底。 两者是同一种 Multi-Agent 思路在不同自动化程度上的实现。
