Field note · 2026
Claude Code Projects：多会话并行的瓶颈在哪？
Projects 把 Claude Code 从「一个 session 一个任务」升级为「一个 Coordinator 调度 N 个并行 session」。本文拆解 Coordinator–Threads 架构、上下文分层、Git 并发协议、成本模型与适用边界。
系列文章 · Claude Code 笔记7 篇
新版 Claude Code Projects 于 2026 年 9 月 17 日推出公测。截至 2026 年 10 月 15 日，仍不支持 Third-Party Inference；CLI 没有 Projects 的直接操作入口，但可以作为它的本地执行端。
一句话： Projects 把 Claude Code 从「一个 session 一个任务」升级为「一个 Coordinator 调度 N 个并行 session」。你只和一个长期对话打交道，Claude 负责拆任务、派线程、汇总结果、盯 PR。
- 发布：2026-09-17，Beta；Pro / Max 灰度，Team / Enterprise 暂不可用
- 入口：claude.ai/code、Desktop Code tab、手机 App；CLI / VS Code / JetBrains 不支持
- 定位转变：旧 Projects 是「文件夹」（对话 + 参考文件）；新 Projects 是「对话」（Coordinator + Threads + Memory）
1. 什么时候推出的？它是什么？
Anthropic 在 2026 年 9 月 17 日发布了官方公告 Projects redesigned: from folder to conversation。这不是普通的代码项目目录，而是一个持续协调多个 Agent 会话的项目工作空间：你在主对话中提出目标，Coordinator 负责分拆任务、启动或复用 threads、协调并行工作并汇总结果。Claude
可以把它理解为：你不再手动管理多个 Claude Code 会话，而是把这项协调工作也交给 Claude。例如，一次跨后端、Web 和移动端的迁移，可以由同一个 Project 分配到不同线程完成。Claude
当前仍是 Pro / Max 的渐进式公测，Team / Enterprise 尚未开放；有订阅也不一定已经拿到入口。Claude
2. Third-Party Inference 能用了吗？
还不能。官方明确排除了 Amazon Bedrock、Google Cloud’s Agent Platform、Microsoft Foundry，并规定：无论线程在云端还是本机运行，模型提供方都是 Anthropic。
3. Claude Code CLI 能用吗？
不能直接在终端里使用 Projects 的完整管理与协调界面。官方支持入口是网页、Desktop 和 Claude 移动端，不包括 CLI、VS Code 扩展和 JetBrains 插件。code.claude.com
不过，Projects 已经可以把某个任务线程交给你的本机执行，通过 Remote Control 连接。这和“Projects 只能在云端运行”不同。该能力要求本机 Claude Code v2.1.280 或更高版本。
Projects 解决什么问题？
多 session 并行早就能做（worktree、agent view、cloud session），真正的瓶颈是协调成本落在人身上：
| 没有 Project | 有 Project |
|---|---|
| 自己决定每个 session 干什么 | 把 bug、stack trace、任务清单丢进同一个对话，Claude 路由 |
| 每个 session 开头重复背景 | Instructions + Memory 设置一次，所有 Thread 继承 |
| 轮询哪个跑完、哪个卡住 | Overview 按状态聚合：待评审 / 等你 / 运行中 |
| 关电脑即中断 | 云端 Thread 继续跑，手机上 steer |
本质：把“人做 Orchestrator”变成“模型做 Orchestrator”。并行不是卖点，托管调度才是。
一个 Project 由四部分组成
图 1：Project conversation 连接多个 Thread，并把状态汇总到 Overview。
图 2：新建 Project 时填写名称、目标，并选择仓库作为共享上下文。
一个 Project 由四部分组成：
| 组件 | 角色 | 关键特性 |
|---|---|---|
| Project conversation | Coordinator（Chief of staff） | 长期运行；决定原地回答 / 新建 Thread / 转发给已有 Thread；只看 Thread 汇报，不看每一步 |
| Threads | Worker | 每个都是完整 Claude Code cloud session；独立上下文窗口、独立 sandbox、独立 branch；可再用 subagent / loop 拆分 |
| Standing context | 共享状态 | Project instructions、Project memory、仓库、文件、cloud environment |
| Overview | 控制面 | Threads / Library / Pull requests / Routines 四个 tab |
三个交互演示
三个 tab：
- ① 消息如何被 Coordinator 路由；
- ② Thread 的事件驱动生命周期；
- ③ 不同角色启动时装载哪些上下文。
技术原理
Coordinator–Worker 编排
典型的 Orchestrator-Worker 模式，但有两个关键设计：
- 路由三选一：快问题原地答（不付 session 成本）；新工作开新 Thread；同领域 follow-up 转发给已有 Thread（复用上下文）。一条消息里多个无关任务会被拆成多个 Thread。
- Context firewall：Coordinator 只接收 Thread 的结果汇报，不接收执行轨迹。这是它能无限期运行的前提——否则 N 个 Thread 的工具调用会瞬间撑爆协调者上下文。
Coordinator 的工作集 = 近期消息 + 近期 Threads + 项目记忆，而非完整历史。必须永不丢失的信息只能放进 memory。
隔离与并发：用 Git 做并发协议
- 每个云端 Thread：独立 sandbox → clone 全部项目仓库 → 从默认分支切新 branch → 需要时开 PR
- 不做锁、不做调度级冲突检测。多个 Thread 改到同一处代码，冲突就是普通的 merge conflict
- 这是一种乐观并发：把一致性问题下推给成熟的 Git/PR 流程，Coordinator 只负责建议合并顺序（如“哪个 PR 先合”）
分层上下文：Push vs Pull
| 层 | 加载方式 | 适合放什么 |
|---|---|---|
| Project instructions（≤16,000 字符） | 每个新 Thread 和 Coordinator 都推送 | 分支策略、自检命令、缺资源时的行为、需审批的动作 |
| Project memory | MEMORY.md 索引启动即读，其余文件按需打开 | 决策、需求变更、踩坑记录（“发布改到周五”） |
仓库 CLAUDE.md / .claude/skills|agents|commands | clone 后从每个仓库加载 | 仓库级构建命令、规范 |
仓库 .claude/settings.json | 仅单仓库项目生效（权限、hooks、env） | 多仓库时改用 instructions + environment |
| Connectors（claude.ai 账号级 MCP） | 所有云端 Thread 自动可用；Coordinator 没有 | 需要外部工具的活必须派给 Thread |
| Cloud environment | 沙箱级 | 网络白名单、network secrets、setup script |
关键判断：memory 是索引 + 懒加载，不是全量注入，这让记忆可以持续增长而不线性膨胀启动成本。
另一个关键点：云端 Thread 不继承本机任何 Claude Code 配置。要共享的 skill 必须提交到仓库，插件要在 Project settings 里加。
事件驱动的长生命周期 Thread
Thread 不是“做完即销毁”的 subagent，而是挂在 PR 上的常驻 Agent：
- 开 PR 后强制开启 auto-fix：CI 失败自动修、Review 评论自动回应
- 状态机：Working → Ready for review → Landing → Resolved；任何时候可能落入 Waiting on you（审批 / 失败）
- Resolved 触发：你手动标记、Claude 在你完成最后一步（如合并）后标记、或一周无活动自动关闭
- Sandbox 在轮次间暂停、继续时恢复；恢复失败则从 fresh clone 继续——未提交的改动会丢，长任务要让它勤 commit/push
权限模型
- Thread 默认跑在 auto mode，大部分工具调用无需审批
- 审批提示只存在于 Thread 内部：在项目对话里说“继续”传不到 Thread
- 通过对话设置的偏好（如“最多同时跑 2 个”）会被写入 memory，但只是软约束，不是硬上限；要精确约束写进 instructions
混合执行：Remote Control 本地 Thread
需要本地数据库、模拟器、VPN 内 API 时，可让单个 Thread 跑在本机：
- 依赖 Remote Control（Claude Code ≥ v2.1.280），Desktop 开关或
claude remote-control [--spawn worktree] - 使用本机的文件、MCP、hooks、权限规则；带 instructions，但不加载项目记忆文件
- 仅在机器唤醒且在线时运行；开启 Require trusted devices 时不可用
成本模型
- 与其他 Claude Code session 共用套餐额度，但消耗快得多：每个 Thread 都是完整 session + Coordinator 自身也在读汇报
- 默认：Thread = Opus + high effort，Coordinator = Opus + low effort
- 硬限制：每天跨项目最多新建 200 个 Thread
- 隐性成本：空闲超过 prompt cache 生命周期（Pro/Max 为 1 小时）的 Thread 被唤醒时要重读整段对话——新任务开新 Thread 往往比复活老 Thread 便宜
- 触达限额时 Thread 自动等待并在重置后继续（routine 启动的除外）
设计渊源：对照 Anthropic 工程文章
以下为对照解读：Projects 的关键设计，在 Anthropic 此前公开的 Agent 工程文章中都能找到对应原则与实验依据。官方未公开 Projects 内部实现，此处只做映射。
| Projects 设计 | 对应原则 / 证据 | 出处 |
|---|---|---|
| Coordinator 按输入动态拆任务 | Orchestrator-workers：子任务不预先定义，由编排者根据具体输入决定 | Building effective agents |
| Thread 独立上下文，只回报结果 | 子 agent 是“智能过滤器”：在各自上下文中探索，压缩出最重要的 token 交给 lead agent；关注点分离降低路径依赖 | Multi-agent research system |
| Library + PR 作为交付物 | 子 agent 产物写入外部存储，只向协调者回传轻量引用，避免“传话游戏”式信息损失 | 同上（Appendix） |
| 额度消耗快得多 | Agent ≈ 4× chat token，multi-agent ≈ 15×；token 用量单独解释 80% 的性能方差。本质是用 token 换能力，只适合高价值任务 | 同上 |
| 异步、可随时 steer 的 Thread | Research 系统的 lead agent 同步等待子 agent、无法中途转向，被列为瓶颈；异步是方向，代价是结果协调与状态一致性 | 同上 |
Project memory（MEMORY.md 索引 + 按需打开） | Structured note-taking / memory folder：让模型自己决定持久化什么，而非外挂检索；索引常驻、正文按需读取，与 Skills frontmatter 的渐进式披露同构 | Effective context engineering、Harnessing Claude’s intelligence |
| Thread 自动 compact；Coordinator 只用近期工作集 | Compaction（原地摘要，同一 agent 延续）vs Context reset（清空上下文 + 结构化交接）；新模型“上下文焦虑”减弱后，compaction 已足够 | Harness design for long-running apps |
| 长任务勤 commit / push；sandbox 失效则 fresh clone 续跑 | 进度文件 + git 历史让全新上下文快速接手；每轮结束保持环境干净 | Effective harnesses for long-running agents |
| Coordinator 审阅产出；CI / Review 驱动 auto-fix | 生成与评估分离：独立评估者比自评可靠得多；Code review 与 QA 充当外部评估者 | Harness design for long-running apps |
| Coordinator 与 Thread 分设模型；冷 Thread 复活成本高 | 缓存按模型隔离，会话中换模型会击穿缓存，“要更便宜的模型就用 subagent”；缓存命中仅 10% 成本 | Harnessing Claude’s intelligence |
与相邻功能的边界
| 功能 | 粒度 | 谁发起 | 生命周期 |
|---|---|---|---|
| Subagent | session 内的子任务 | 当前 session | 返回摘要即结束 |
| Agent teams | 一个任务内的 teammate sessions；共享任务列表、可互发消息（实验性，默认关闭） | Lead session | 随任务结束 |
| Dynamic workflows | 一个 session 内由脚本驱动大量 subagent，并交叉验证结果 | 脚本（持有计划） | 随运行结束 |
| Worktree / Agent view | 本地多 session | 你 | 你管理 |
| Routines | 定时任务 | 调度器 | 周期性；可挂在 Project 下运行 |
| Claude Tag | Slack 频道内多人协作 | 团队任何人 | Team/Enterprise |
| Projects | 一条持续的工作流 | Coordinator | 与目标同寿 |
嵌套关系：Project → Threads → Subagents / Workflows。
官方选型三问：谁来协调？worker 之间要不要通信？会不会改同一批文件？Projects 的答案：Claude 协调；Thread 向 Coordinator 汇报；靠独立 sandbox + branch 隔离。
适用场景
适合：目标比单个 session 长、且持续产生任务的工作
- 跨多仓库的一致性改造（每仓一 Thread 一 PR）
- 持续投喂的领域（某服务的 bug 与 review 流）
- 超出单 session 的构建 / 迁移（“按
docs/spec.md实现”） - 非代码工作：上传合同、工单导出等文档，产出写入 Library
不适合：单个小任务（直接开 cloud session）；每个任务都依赖本机（用本地 session / agent view）；纯定时无对话（用 routine）。
上手最佳实践
- 先写 instructions 再派活：项目目的、分支与 PR 命名、自检命令、缺资源时的行为、需审批的动作
- 先跑一个小任务校准 Thread 的汇报方式，再放量
- 调低默认配置：Opus + high 消耗最快，按任务降模型或 effort
- 初期让 Claude“先提议 Thread、等我确认、最多同时 N 个”，稳定后放开
- 仓库只加核心的 1–2 个，其余在 instructions 里点名，让 Thread 按需自行添加
- 纠正一个 Thread 后，顺手让 Claude“记住”，写入 memory 惠及后续 Thread
- 多个 Thread 同时猜错 / 卡住时，通常是同一个配置缺口：先让 Coordinator 汇总各 Thread 的假设与阻塞，修 instructions 或 environment，再重发
Instructions 示例（官方）：
This project holds p95 latency for the payments API under 200 ms ... in the payments-api repository.
- Branch from main and open one draft pull request per thread.
- Before you call work done, run `make test` and `make lint` and paste the summary lines in your final message.
- If you can't reach something you need, say exactly what's missing in your first message and stop. Don't substitute, mock, or guess.
- Don't merge, force-push, or change CI configuration without asking me in the thread.限制
- 仅 GitHub（不支持 GHES / GitLab / Bitbucket），需安装 Claude GitHub App（
/web-setup的 token 不够） - 项目归属单用户，不能共享；Thread 不能跨项目移动，项目不能合并
- 本地手动启动的 session 无法加入项目（只能反向通过 Remote Control 跑本地 Thread）
- 不支持 Bedrock / Vertex / Foundry，模型提供方只能是 Anthropic
- 上传文件是副本：本地修改后需重新上传并 Replace
架构启示
对自建 Agent 系统（如视频生成 Agent）最有价值的几点：
- 协调者只吃摘要：Worker 的执行轨迹留在 Worker，Coordinator 上下文才能长期稳定
- 记忆 = 索引 + 懒加载：启动成本恒定，记忆可无限增长
- 用现成的一致性机制做并发控制：Git branch / PR 替代自研锁与冲突检测
- Worker 是事件驱动的常驻实体：外部事件（CI、Review）唤醒，而不是一次性函数调用
- 软偏好与硬约束分层：对话里的偏好进 memory（可漂移），必须遵守的进 instructions（每次推送）
- 成本可观测：按 Thread / 模型拆分 token；警惕缓存过期后的“复活成本”
- 记忆记意图，代码记结构：memory 只在写入时刻准确，不绑定代码版本，会过期；接口契约、依赖关系等结构性事实应实时从代码或依赖记录（如 MCP）读取
Projects 与 Agent Teams 有什么区别？
是，非常像。两者都采用“一个 Coordinator + 多个拥有独立上下文的 Claude Code 会话”来并行完成工作。
真正的区别是：协调的是一次任务，还是一个持续产生任务的长期项目。
参考：Run agents in parallel - Claude Code Docs
可以这样理解：
Agent Teams 像为一项任务组建的协作小组；
Projects 像长期存在、持续接收需求和分派工作的项目协调中心。
1. 相似在哪里？
两者都不只是“同时开几个窗口”：Claude 会承担任务拆分、委派和结果汇总，而执行者拥有各自的上下文。你也可以绕过主协调者，直接进入某个执行会话进行指导。Projects 将这些执行会话称为 threads，Agent Teams 则称为 teammates。Claude
所以，从你看到的使用体验来说，确实都是：
提出目标 → Claude 分工 → 多个会话并行执行 → Claude 汇总，你在必要时介入。
2. 核心区别：任务级协作与项目级持续协调
| 维度 | Agent Teams | Projects |
|---|---|---|
| 核心目标 | 组织多个 Agent 协作完成当前任务 | 持续接收、安排和跟踪一个项目的多批任务 |
| 协调者 | 当前会话中的 Team Lead | 长期运行的项目 Coordinator |
| 协作重点 | 成员间直接通信、共享任务列表、协调依赖 | 将需求路由给新建或已有 thread，跟踪结果 |
| 使用入口 | Claude Code 交互会话，包括 CLI；目前需要开启实验功能 | 网页、Desktop、移动端 |
| 时间尺度 | 偏向当前任务及其会话生命周期 | 面向跨数天、数周的持续工作 |
这是官方文档划分的侧重点，并不是说 Agent Teams 只能处理小任务。Projects 文档直接将 Agent Teams 描述为：由一个会话启动队友会话，围绕一项任务协作，并随该任务结束。Claude
拿一个假设的 Agent 服务开发场景来说：
使用 Agent Teams，你可能说：“排查这次任务延迟，安排一个成员检查消息队列，一个检查沙箱启动，一个检查模型请求，互相交换发现，最后给出结论。”
使用 Projects，则更像：“持续推进这个 Agent 服务。”今天提交延迟问题，明天加入断点恢复需求，下周再处理新出现的错误。你关心的是这一系列工作的连续性，而不只是当前这一组 Agent 是否完成任务。
3. 更深的区别：保留“项目经验”，还是维持“当前团队”
Projects 的长期性不只是把聊天记录保存下来。它有项目级 instructions、memory、文件与产物库；云端 threads 可以共同积累和读取项目记忆，让后续任务继承前面形成的决策和经验。Claude
Agent Teams 则更偏向当前团队的执行状态。需要注意，它并非完全不持久化：任务列表会保留在本机，但当前 /resume、/rewind 不会恢复 in-process teammates。因此，“恢复任务记录”和“把整个团队原样恢复运行”不是一回事。Claude
另外，Projects 的记忆也有运行位置差异：本地执行的 thread 会收到项目 instructions，但目前不会预加载项目 memory 文件，不能把云端与本地线程的上下文继承视为完全相同。Claude
4. 所以，Projects 是 Agent Teams 的云端加强版吗？
作为体验类比可以，但作为技术定义不准确。
Agent Teams 明确提供成员之间的直接消息和共享任务列表；Projects 文档强调的是 Coordinator 对 threads 的持续调度、结果跟踪与项目上下文。公开文档没有把 Projects 定义为“Agent Teams 外面套一层界面”，不能据此断定底层实现相同。Claude
而且，Projects 的每个 thread 本身就是完整的 Claude Code 会话，内部仍可使用 subagents、loops 和 workflows。因此，项目级协调与单个任务内部的执行编排可以同时存在，并不是二选一。Claude
我的判断是：Projects 的新增价值，不主要是“组队能力更强”，而是让你不必持续担任多个会话之间的项目经理。Agent Teams 解决“这件事怎么一起做”，Projects 进一步解决“这一系列事情接下来做什么、交给谁、之前的经验怎么延续”。
所以 Projects 看起来像是有个 Project 维度、更高级的 Agent Teams 是吗？
对，作为心智模型，可以把 Projects 理解为“项目维度、长期化的 Agent Teams”。这里的“更高级”主要指管理范围和生命周期更高一层，不一定是单次任务的协作能力更强。官方也明确区分：Agent Teams 围绕一项任务组织队友，Projects 则持续协调一系列相关工作。Claude
可以用这组角色类比：
| Agent Teams | Projects | |
|---|---|---|
| 协调者像谁 | 当前任务的技术组长 | 长期负责这个项目的项目经理 |
| 主要管理什么 | 多个队友如何协作完成任务 | 不断到来的需求交给哪些线程、如何跟踪结果 |
| 连续性重点 | 当前任务中的沟通、分工与协作 | 跨任务延续的目标、指令、记忆和工作状态 |
这张表是对官方能力的类比归纳：Agent Teams 强调成员直接通信及任务协调；Projects 强调持续接收工作、创建或复用线程，以及项目上下文的延续。Claude
例如，假设你在开发一个 Agent 服务：
Agent Teams 对应：“组一个团队，把断点恢复功能实现好。”
Projects 对应：“持续推进这个服务。今天做断点恢复，明天处理性能问题，后天增加新功能；沿用之前的项目决策，不要每次让我重新交代背景。”
唯一需要保留的边界是：
这不代表 Projects 在实现上就是“外面套了一层 Project 的 Agent Teams”，也不代表它是 Agent Teams 的严格功能超集。
官方描述的 Projects 结构是 Coordinator → Threads，而 Agent Teams 是 Team Lead → Teammates，后者还明确强调队友之间的直接协作。Claude
参考资料
官方文档
- Let Claude coordinate ongoing work with Projects：主文档，含上下文装载规则、成本与限制
- Projects redesigned: from folder to conversation：发布文章，设计意图与 roadmap
- Run agents in parallel：Subagents / Agent view / Agent teams / Dynamic workflows / Projects 五种并行方式对比与选型
- Cloud sessions（Claude Code on the web）：云端 Thread 的运行时
- Cloud environments：Thread 的网络白名单、network secrets、setup script
- Remote Control：本地 Thread 的接入通道
- Dynamic workflows：Thread 内部再拆分的脚本化编排
- Memory tool：API 层文件式记忆工具，可对照理解 Project memory
原理：Anthropic 工程文章
- How we built our multi-agent research system：协调者–工作者的工程实践、token 经济学、委派提示词写法。最值得精读
- Building effective agents：Orchestrator-workers 模式的原始定义
- Effective context engineering for AI agents：Compaction、structured note-taking、multi-agent 三种长程上下文技术
- Effective harnesses for long-running agents：跨上下文窗口交接：progress file + git
- Harness design for long-running application development：Planner / Generator / Evaluator 三 agent 架构；compaction vs context reset
- Harnessing Claude’s intelligence：编排决策从 harness 移交模型；记忆、渐进式披露与缓存设计原则
社区实测与讨论
- Claude Code Projects: How Parallel Coordinator Sessions Work：多仓库实测，Coordinator 主动指出跨仓 PR 合并顺序；文中“本地 Thread 暂不支持”已过时
- Claude Code found my app’s shared contract in two MCP calls：The New Stack，讨论 memory 的边界：记录意图，但不绑定代码版本
- GitHub Issue #99156：社区诉求，让本地 Claude Code session 成为一等 Thread
视频
- A glance at project threads：25 秒，Thread 交互一览
- Getting started with Claude Code Projects：上手演示
系列 · Claude Code 笔记