五个 AI 在同一个项目里同时动手改代码，谁保证它们不互相打架？这个问题过去只存在于自己折腾多 agent 的玩家手里，2026 年 11 月 15 日之后它变成了每个 Claude Code 用户都要面对的现实。Anthropic 重新设计了 Claude Code 的 Projects：一个项目里有一个协调者和若干并行干活的线程，各自在云端开独立分支、独立副本，冲突按普通 PR 的合并冲突处理。多 agent 并行从社区手搓的土办法，正式变成了官方产品形态。这一步跨出去，编码 agent 的竞争维度就变了。
这次改的不是功能，是分工方式
要看懂这次更新，先得明白过去人们是怎么用 Claude Code 多开任务的。模型越来越强、token 越来越省，auto 模式和云端会话让 agent 能一次跑更久，于是很多人自然开始同时挂好几个会话，一个改接口、一个补测试、一个重构模块。工具本身不管这件事，并行完全是用户自己的行为。
Anthropic 团队成员 Boris 在 Hacker News 上把动机说得很坦白：multi-Claude 玩法越来越普遍，但体验跟不上，在多个会话之间来回切换是一场注意力灾难。人被迫当了调度器，既要看每个会话的进度，又要记住谁在做哪块，还要手工把结果拼回去。
同时另一种需求也真实存在：有些活就是要单线程深钻，来回讨论，不想被别的任务打断。并不是所有工作都需要并行化，单线程的专注依然重要。这次设计要同时照顾这两类人。
所以 Projects 的重构方向很明确：把调度这件事从人手里接过来。官方描述是从文件夹变成对话，过去你要自己拆活、自己交接、自己缝合结果，现在你描述要做什么，Claude 来管理这项工作。范围界定、任务委派、并行协调、结果审查、成品组装，整条链路都由系统接管。
换句话说，这次发布的核心不是某个新按钮，而是 Claude Code 从一个单会话工具变成了一个多工人的工程组织。你不再是操作员，更像是一个给工程团队定目标的负责人。
谁来干活，谁来指挥
新 Projects 的结构只有两层：线程负责干活，协调者负责指挥。你在项目里选定目标和对应的仓库或上下文，协调者会先列出它认为可以立刻着手的活，然后把具体任务路由给新开的线程或已有的线程。
每条线程都是一个完整的 Claude Code 云端会话，它不是某个主会话的附属品，而是有自己独立分支和独立仓库副本的完整工作环境。这个设计保证了并行安全的地基：线程之间物理隔离，谁都踩不到谁的文件。
协调者这个角色用官方的话说，你要像给幕僚长布置工作一样向它简报。它收到目标后决定拆成几条线、分给谁、什么顺序推进。过程中它会主动检查和跟进，遇到需要你拍板的事会把问题冒泡到主线程，你随时可以从主线程跳进任意一条线程看细节、改方向。
线程如果觉得领到的活太大，还可以自己再往下拆，用子代理、循环、工作流把大任务切成小份。这意味着一个项目实际上可以长成一棵三层的工作树：协调者在顶层，线程在中层，子代理在底层。
这套层级并不新奇，做过多 agent 编排的人一眼就能认出它是经典的 orchestrator-worker 结构。真正的差别在于它第一次作为官方产品形态出现，配置、记忆、权限、界面全部打包好，不用自己拼。每一层只对自己的上一层负责，责任边界清楚。
改乱了就当合并冲突处理
并行改代码最大的恐惧是改乱：两个线程动了同一个函数，最后到底听谁的。Anthropic 给出的答案干脆利落，冲突不被消灭，而是被制度化。如果多条线程碰了同一份代码，重叠部分就按普通的 PR 合并冲突来解决，和你日常处理人类同事之间冲突的方式完全一样。
这个选择很克制也很聪明。它没有发明一套新的冲突协议，而是直接复用软件工程里最成熟的那套机制。每个线程的活最终都体现为一条分支上的提交和一个待合并的 PR，冲突浮出水面时，解决路径是你早就熟悉的 diff 和 review。
线程还能自动完成工程闭环：仓库连上之后，线程会自己开 PR、跑你的测试，然后告诉你哪些 PR 需要先合并。官方给的例子是退役一个废弃接口：把 API、网页、移动三个仓库连进项目，设定目标，每个仓库开一条线程迁移调用方、跑测试、开 PR，最后由协调者汇总出合并顺序。
这种隔离模型的物理基础，本地开发者用 git worktree 早就能体会到。每条线程一份独立工作目录的概念，手工版本大致长这样：
git worktree add ../proj-thread-auth feature/auth
git worktree add ../proj-thread-api feature/api
git worktree add ../proj-thread-test feature/tests
git worktree list
手工玩法的痛点恰好是官方要消灭的：worktree 只给你隔离的文件系统，不给你拆活的人、跟进度的人、合并时排顺序的人。Projects 把这三件事补上了，这才是从工具到组织的跨越。协议越老，心智成本越低，出错时排查的路径越熟。
记忆和素材开始跨会话累积
单会话时代的记忆策略靠 prompt 工程硬撑：每次开会话都要把上下文重新喂一遍。Projects 引入了一层共享记忆，每条线程既往里写也往外读，项目级的事实随时间不断累积。
官方举的例子都很日常：它记得发布日挪到了周五，记得当初为什么砍掉了导出功能，记得动计费服务之前要先和谁打招呼。这些细碎的项目知识过去散落在聊天记录和文档里，现在沉淀为项目的长期资产。
随记忆一起来的还有一个库。你往项目里添加的文件、Claude 在工作中产出的工件，都被收进这个库里，后续的新任务可以直接建立在过去的成果上，而不是从零开始。
沟通方式也能定制。你可以要求它调整汇报频率、开新线程的积极程度、每条更新的详细程度。记忆加上可调的工作风格，让协调者越来越像一个熟悉项目的同事，而不是每次都失忆的临时工。
这一层很容易被低估。并行能力解决的是速度问题，共享记忆解决的是连续性问题，而连续性恰恰是长周期工程真正稀缺的东西。一个能记住上周决策的工人，比一个每次都要重新解释背景的工人值钱得多。更重要的是这层记忆跨线程共享，任何一条线程学到的教训，其他线程立刻就能用上，知识在项目里只会增值不会蒸发。
两个现实代价：额度和云端
并行不是没有账单的。每条线程都是一个完整的 Claude Code 会话，一个项目同时挂着几条线程，额度消耗速度是单会话的好几倍。官方也明说项目会更快触及用量上限，补救手段是可以分别给协调者和工人线程选模型与算力档位。
协调本身也要花钱，但数字不算难看。Boris 在 HN 上透露，AB 测试和评测显示协调者的 token 开销相比直接跑会话只多出不到一成。用约一成的额外开销换注意力的解放，对重度并行用户来说是划算的买卖。
第二个约束是运行位置。目前所有线程都跑在云端，自动签出相关仓库，不需要你指定。但这也意味着你的本地工具链、私网环境、未推送的代码暂时都接不进来。官方承诺本机运行、和你本地的工具与网络同在的版本很快就来，只是今天还拿不到。
社区的反馈也集中在这里：有人抱怨接入本地项目时权限要得太多，有人困惑为什么功能放在云端优先，还有人发现 Claude Code CLI 里根本没有入口。这些声音说明官方方案离重度工程现场还有一段距离，今天它更适合云端标准化的仓库工作流。对完全离线或合规要求私网部署的团队，现在只能等。Anthropic 的优先级摆得很清楚：先把云端标准化场景打磨顺，再啃本地环境的硬骨头，这个顺序和当年 CI 云服务走过的路几乎一样。
跟自己搭的多 agent 班子比一比
官方方案不是唯一的玩法，HN 评论区里躺着不少手搓班子的人。有人同时养着十个次级编排器，每个再带二十个工人，用 GitHub issue 做任务分派、用 worktree 和 PR 防碰撞，自称跑得相当顺。也有人专门写了调度工具来干同样的事。
| 维度 | 官方 Projects 协调 | 社区手搓班子 | 单线程会话 |
|---|---|---|---|
| 协调者 | 内置协调者负责拆活与跟进 | 自己当调度或再养一个调度 agent | 无 |
| 隔离方式 | 每线程独立分支与云端副本 | worktree 加分支手工管理 | 天然无冲突 |
| 冲突处理 | 按普通 PR 合并冲突解决 | 同样靠 PR，但流程自己拼 | 不涉及 |
| 记忆 | 项目级共享记忆自动累积 | 需自建，多数靠重喂上下文 | 会话结束即失效 |
| 运行位置 | 目前仅云端 | 本地云端随意组合 | 本地云端均可 |
| 上手成本 | 零搭建，开箱即用 | 需要自建调度与约定 | 零 |
把三列摆在一起看，官方方案的价值不在原理，原理社区早就玩熟了。它真正补上的是体验和连续性：不用自己维护调度约定，记忆自动沉淀，还能从手机上盯进度。
不过也有评论者点出了天花板：这套系统能自动化到什么程度，最终取决于协调者的决策质量。拆活拆得对不对、问题冒泡及时不及时、合并顺序排得合不合理，都是模型能力问题，不是界面问题。编排器再漂亮，判断错了照样白干。
现在能用上的是哪些人
落地范围说得很清楚。新版 Projects 今天起以 beta 形态开放给一部分 Claude Pro 和 Max 订阅者，条件是用 Claude Code 的云端会话，并且在网页或桌面端没有存量 projects。没有覆盖到的同档位用户可以排队进 waitlist。
节奏上，未来一周会继续向这两个档位的更多用户放量，Team 和 Enterprise 计划排在更后面。已经有旧版 projects 的账户保持现状不动，官方会在功能扩展到对话和协作场景时再做升级。
这条新闻真正的分量不在功能本身，而在它标定的方向。当最大的编码 agent 厂商把多工人并行做成默认产品形态，说明单会话交互已经装不下真实工程了。接下来一年，竞争的焦点大概不再是单个 agent 多聪明，而是谁的编排层更会带团队。
对还没排上号的人，值得现在就做的事只有一件：想清楚自己项目里哪些活天然可并行、哪些必须串行。等入口开到你头上时，带着一张分好类的任务清单去，比临时发挥有效得多。官方演示里还有个细节值得记住：你可以从手机上盯进度、批问题，协调者把必须坐在电脑前的场景也压缩掉了。存量用户同样不用急，旧 projects 不会被强制迁移，新旧两版会并存一段时间，等升级路径打磨成熟再切换也不迟。判断该不该第一时间上车的标准很简单：手里的并行会话超过三个，协调者立刻就是刚需；还在单会话阶段的，先把任务清单整理好再进也不亏。
