在 Claude 旧版的 Projects（claude.ai 聊天与 Cowork 里的项目）中，项目只是把对话和参考文件归拢在一起，既没有线程，也没有协调者。想同时跑几个 Claude Code 会话，协调工作都得你自己做：决定每个会话做什么，在每个会话开头重复交代同样的背景，再挨个回去看哪个做完了、哪个在等你回答。碰上一项要做好几天、跨好几个代码仓库的活，你就是那个调度员。

Anthropic 在 Claude Code 的网页版（claude.ai/code）与桌面端上线了全新设计的项目（Projects）功能，目前处于面向 Pro 与 Max 订阅用户的公开 beta 阶段。这次改造的核心转变是从「静态资料夹」变成「带班主管」：整个项目收拢为一个持续运行的中央对话，你在对话里提出目标，由 Claude 担任协调者，自动将需求拆解成多个并行运行的线程（thread）。

这里的线程不是简单的后台命令，每一个线程本质上都是一个独立的云端 Claude Code 会话。它们各自拥有专属的上下文窗口，在云端独立的沙箱和 git 分支上并行编写代码、跑测试、在需要时开 PR，并且在电脑合盖离线后继续运转。

Projects 的主要能力：

• 一个对话派活：任务、bug、补充说明都丢进同一个项目对话，Claude 决定是就地回答、开新线程，还是转给正在做这块的线程。
• 多个线程并行，关了电脑也不停：每个线程是一个独立的云端 Claude Code 会话，有自己的上下文窗口、代码副本和分支。
• 需要你时才叫你：Overview（总览）面板按状态给线程分组，卡住等你拍板的排进 Waiting on you（等你处理），桌面端还会弹通知。
• 共享背景和记忆：每个新线程都带着同一份项目指令、仓库和项目记忆开工，你让 Claude 记住的决定，后面的线程都知道。
• 自己跟进 PR：线程开了 PR 就一直盯着，CI 挂了或来了评审意见会自己推修复，检查通过再告诉你。
• 能定时跑：可以让 Claude 把一部分工作做成例行任务（routine），按计划在项目里自动运行。
• 不止写代码：没有代码仓库也能用，上传文档让线程调研、写报告，成果交到 Library（资料库）。

运行机制：一条复合消息如何变成多个并行线程？

官方发布视频演示了这样一个上午：用户在一个名为 checkout-service 的服务项目里，一次性输入了一条包含三项诉求的复合指令——/checkout 接口的 p99 延迟在 4812 号部署后翻了一倍，查出原因并修复、起草周五的发布说明，顺便把 stripe-node（Stripe 的 Node.js SDK）升级到 v15。

在项目里，主对话里的 Claude 担任协调者，看到的是线程汇报回来的结果，而不是它们走的每一步。Claude 会自主决定消息的去向：快速简单的问题通常直接在对话中就地回答；新工作会开出新线程，或者交由已经在该领域工作的线程继续做，Claude 也会明确告诉你转交给了谁；一条消息里如果包含几件互不相干的事，则会拆成多个独立线程。如果它的分派不符合你的预期，直接告诉它调整即可。

在演示中，Claude 识别出这是三项独立工作，随即在界面上生成三张线程卡片并行派发：第一项任务在还剩 7 个提交的范围里二分查找出问题的提交；第二项任务检索 v4.11 以来已合并的 23 个 PR 开始归纳改动点；第三项任务更新 6 个文件里的 SDK 调用。此时右侧的总览（Overview）面板显示 3 个线程处于 Working（进行中）状态。

在线程各自推进期间，如果你临时产生新想法，不需要重新梳理全局。例如用户半小时后在主对话随口补充了一句「发布改到周一了，发布说明里要写对」，协调者会自动识别这条信息归属于哪项工作，直接将其转交给撰写发布说明的线程。该线程在自己的独立会话里接收到转交的消息，就地把发布日期改成周一（9 月 22 日），并把代码冻结的提醒挪到周五，完全不干扰另外两个正在排查代码的线程。

任务完成后的交付形式也各司其职。排查性能问题的线程最终定位出原因是 QuoteService 里的 N+1 查询，自动改回批量查询，在 GitHub 上推了新分支并开出 PR #4821，主对话随即收到「PR #4821 已开、CI 通过」的完工汇报。

当线程遇到无法擅自决定的技术断点时，会自动停下等待人工输入。升级 stripe-node 的线程在更新完 6 个文件后运行契约测试，42 项测试通过了 41 项，最后一项因下游 webhook-lambda 仍跑在 Node 18 上而失败（stripe-node v15 不再支持 Node 18）。该线程并没有胡乱猜测或绕过测试，而是将状态置为 Waiting on you（等你处理），向用户提供升级 Lambda 运行时至 Node 20（推荐选项）或锁定 stripe-node v14 的权衡建议。

需要说明的是，线程在模型支持时默认运行在 auto mode，绝大多数工具调用不需要向你确认。当某个线程确实需要你的批准时，提示只会出现在该线程内部，线程会一直等到你在该线程里作答；如果你在项目对话里告诉 Claude 继续，指令是传不到线程内部的。在线程专属的输入框里发消息会直达该线程，而在项目对话里发跟进消息，只有当 Claude 将其匹配给该线程时才会转交。在官方演示中，用户也是直接点开 stripe-node 线程，在其内部输入框中回复决策的。

在项目对话右侧的总览（Overview）面板中，线程的状态会按六个分组清晰归类：

• Ready for review（待审）：PR 已开、等待评审的线程；
• Waiting on you（等你处理）：等待你的回复或批准，或是执行失败的线程；
• Working（进行中）：仍在运行中的线程；
• Landing（即将合并）：PR 已获批准或已排队等待合并的线程；
• Idle（空闲）：已执行完毕且不等待任何事项的空闲线程；
• Resolved（已了结）：标记为已了结的线程（由你手动标记、在你走完合并 PR 等最后一步后由 Claude 标记，或在一周没有活动后自动标记）。

如果你使用的是桌面端，当线程报错、需要你输入或 Claude 在项目对话中发言时，系统会弹出桌面通知，无需时刻盯住界面；而在网页浏览器中，则可以通过 Overview 按钮上的提示圆点来获知有线程在等你。

回到开头那个上午，四个线程在这几组之间是这样移动的：

Projects 与 Claude Tag 有什么关系

Projects 与 Slack 里的 Claude Tag 采用了相似的分层：上层会话负责接收任务和协调，独立线程负责执行，多个任务通过共享记忆衔接起来。

• 接活与干活分层：在 Claude Tag 中，每个 Slack 频道有自己的会话处理顶层消息；遇到需要调查、调用工具或长对话的任务，它会在消息下的 Slack 线程里启动专门的工作会话（dedicated session）。在 Claude Code 项目中，同样是由项目对话里的 Claude 担任协调者负责接活，真正干活的是它开出的各个线程。
• 独立沙箱与生命周期：Claude Tag 中每个线程运行在独立的临时云端沙箱中，同频道的两个线程是两个独立会话，不直接共享状态，沙箱在线程安静下来后释放、有新回复时再重建；项目中的每个线程同样是独立的云端会话，在各自的 Git 分支上工作，沙箱在两轮交互之间暂停，继续时再恢复。
• 跨任务记忆：Claude Tag 在公开频道中学到的经验会存成工作区共享记忆，私密频道单独保存；项目中各个线程也共享同一份项目记忆。
• 定时与跟进机制：Claude Tag 支持按计划运行任务、跟随 PR 并在其变动时采取行动；项目中同样支持例行任务（routine），且线程在开出 PR 后会自动盯住状态并跟进修复。

两者的主要区别不是架构，而是使用者和工作环境：Claude Tag 面向 Slack 团队，Projects 面向一个人的长期工作。

Claude Tag 面向团队，常驻在 Slack 频道里，频道成员可以派活或中途引导，用的是管理员统一配置的服务账号。

而 Claude Code 的新版项目目前完全是个人专享的：只有你能向它发送任务或查看它的线程；线程使用的是你个人的 GitHub 推送权限和 claude.ai 绑定的连接器，线程记录也没有分享选项。

项目记忆由对话和线程共同维护

项目记忆（project memory）不是协调者独占写入的。你可以在项目对话或任何线程里让 Claude 记住需求、决策和踩坑点；纠正一个线程后，也可以把这次纠正写进记忆，让后续线程沿用。Claude 还会保存汇报频率、并发偏好等协调习惯。

项目记忆沉淀的是长期的业务背景与决策，例如发布改到了周五、为什么砍掉导出功能、动计费服务前要先找谁。

关于项目记忆，还有三点要知道：

1. 可随时查看与维护：记忆文件存放在 Project settings > Memory 中，列在 Auto memory 下，你可以随时查看、编辑或删除其中的文件；
2. 与本地记忆及仓库规则独立：它和你本机 Claude Code 的自动记忆（auto memory）是两套独立的存储，也和仓库里的 CLAUDE.md 分开。仓库特有的编码规范应写在 CLAUDE.md 中，而关于该项目的业务背景和决策记录则写入项目记忆；
3. 关键信息必须写入记忆：项目对话为了长久运行，并不读取完整的历史对话，而只基于最近的消息、最近的线程以及项目记忆来工作。所以任何绝对不能丢的信息，都要放进项目记忆。

官方博客的演示动画展示了一个名为 Launch readiness 的项目从周一到周四的演进过程：发布日期最初依据 timeline.csv 定为 10 月 14 日，后来两次推迟到 21 日和 28 日，每次改动都同步更新并沉淀在记忆中；当用户提出「Add pricing to it」这类补充要求时，协调者会自动将其接到已有的 Partner email 线程上；这几天下来，产出的结果（Results）和定下的决定（Decisions）在对话下方一层层累积。

线程是完整的云端会话

Projects 里的线程与 Claude Code 的 subagents（子 Agent）不是同一种东西。子 Agent 是单个会话内部的委托工作者，完成旁支任务后向主会话返回摘要。

而在项目中派生出的线程，每一个都是全功能的独立云端会话（cloud session）。每个线程有自己的代码副本和自己的上下文窗口。在需要应对大型任务时，每个线程自身还能根据需要在其内部调用子 Agent、循环执行器（loops）和工作流（workflows）来拆分工序，从而让大型工作更快完成。

它会在哪些情况下主动行动

Projects 的主动行动主要出现在三种场景：

• 首个项目的初始化探索：你的第一个项目建好后，只要你没抢先发消息，Claude 会自己先走一轮：项目里有它能读的仓库时，可能开一个只读不改的探索线程，看完提出下一步建议；也可能根据你最近的云端会话贴出设置建议（Setup recommendations），列出建议添加的仓库、建议创建的例行任务和它可以开的线程。这一轮同样消耗你的套餐额度。
• 例行任务（Routines）：你可以让 Claude 把一部分工作放到计划里做成例行任务（routine），它以线程的形式在这个项目里运行，出现在 Routines 标签页；而在项目外单独创建的例行任务照常各自运行。
• 分支监听与自我修复：只要线程开了 PR，不管你其他云端会话有没有开 auto-fix（自动修复），它都会主动盯住该 PR。一旦 CI 构建变红或仓库收到了评审修改意见，线程就会主动唤醒并推送修复提交，直到检查通过且 PR 准备好供你评审时再向你汇报。

实际使用时，还要提前配置并发、权限和额度规则：

• 并发线程没有固定上限：系统会根据任务需要启动相应数量的线程。你在对话里吩咐「最多同时跑两个」只是协调偏好，并不是系统的硬性上限；如果想让并发限制措辞精确且从一开始对所有线程生效，需要写进项目指令。唯一的硬性数量限制是：所有项目加起来每天最多新开 200 个线程。
• 批准规则写在仓库里：前面说过，需要你批准的提示只在线程内部出现。若想让所有线程对某些命令免问、或者一律禁止某些命令，要写进仓库 .claude/settings.json 的权限规则，而且只在单仓库项目里生效。
• 额度超限会自动重试并消耗后续窗口：当线程或项目对话撞上五小时或每周的用量上限时，系统会持续自动重试，一旦额度恢复就接着继续干，这会在你不发话的情况下直接用掉你下一个周期的额度窗口。如果你不希望它自动消耗新窗口，需要在线程里点击 Stop，或者直接暂停（Pause）整个项目。（例行任务启动的线程例外，碰到额度限制会直接报错停止，不会等待重试。）

横向对比：Claude Code 里的五种并行模式该怎么选？

一周前 Cursor 也推出了同名的 Projects，同样是一个协调者在云端规划、分派多个 Agent 干活。回到 Claude Code 自己，目前一共有五种让多项任务同时跑的方式。

很多开发者容易被这些概念弄混。它们的核心区别在于两点：谁来做任务调度，以及代码跑在本地还是云端：

需要提醒的是，同时运行多个会话或子 Agent，token 用量会成倍增加。

Claude Code 的跨会话消息能让你自己开的几个会话互相传递发现和状态，但开哪些会话、谁做什么、什么时候收尾，依然需要你自己来安排；而新版项目的改变，在于把「开会话、分派任务、跟踪进展」这些繁复的调度工作，完全交给了项目对话里的 Claude。

项目适合的是目标比单个会话更长、会不断冒出新任务的长线工作：例如一个目标跨多个仓库、一个持续往里丢 bug 的服务、一次比单个会话更大的开发或迁移，或是不写代码的纯文档工作（直接上传文件代替仓库，线程会把整理出的成果交到 Library（资料库）标签页）。而在以下四种情况下，用其他方式更为合适：

• 一个会话就能做完的单个任务（例如修一个不稳定的登录测试）：自己开一个云端会话即可；
• 需要只有你电脑能访问的工具或服务（例如本地数据库、设备模拟器、VPN 后面的接口）：用本地会话，或用 Agent 视图（agent view）同时跑几个；如果工作只需要本地文件，直接上传到项目即可；
• 按固定时间重复、不需要来回对话的任务（例如每周一发一份依赖报告）：单独建一个例行任务（routine）；
• 几个人在 Slack 频道里一起给 Claude 派活、一起引导：使用 Claude Tag。

用量：默认全用 Opus，比单个会话耗得快

新项目在默认配置下，项目对话和所有线程都默认使用 Opus 模型，其中线程默认开启高思考强度（High effort），而协调对话开启低思考强度。

项目消耗的是与你其他 Claude Code 会话相同的套餐配额，但用量会跑得更快：每个运行中的线程都是一个完整会话，几个同时跑就会同时消耗配额；项目对话自身阅读线程汇报、决定下一步也要消耗 token；此外，那些处于空闲状态但正在盯 PR 的线程，一旦遇到 CI 失败或新的评审意见就会被唤醒，再次消耗额度。因此，Pro 订阅用户在运行项目的日子里，要预期会更早碰到套餐上限。不过，若项目中没有正在运行的线程、没有被盯的 PR 且没有新消息，项目闲置时并不消耗额度，归档的项目也不会产生消耗。

想要控制并降低项目的用量，可以采取以下做法：

• 在 Project settings > Usage 中查看按线程、按模型拆分的 token 用量，以及项目对话自身的消耗；
• 如果把跟进消息发给一个闲置时间已超过缓存有效期（Pro 与 Max 套餐额度内为 1 小时）的旧线程，它在处理前会先把整段对话重读一遍；因此对于新工作，让 Claude 开一个全新线程往往比唤醒体积庞大的旧线程更省 token；
• 可以在通用设置（General）中，为线程或项目对话换用小模型，或者调低思考强度（effort）；
• 让 Claude 在项目对话中少开几个线程，或者对小问题直接就地回答，不要动辄新起线程。

开工前要配好的三件事

把一条长线工作交给项目之前，GitHub 权限、线程能用的工具、多仓库时的规则，这三处最容易卡住。

GitHub：必须装 Claude GitHub App

在终端运行 Claude Code 时，开发者常通过 /web-setup 从终端连接 GitHub 并获取 token。那个 token 虽然能让你其他的云端会话访问代码库，但并不足以供项目线程使用。项目中的线程完全运行在云端，必须在目标仓库上安装官方的 Claude GitHub App，且你的 GitHub 账号必须对仓库拥有 push（推送）权限；若仓库属于开启了 SAML SSO 的组织，还必须显式完成组织级的单点登录授权。如果仓库上没装 Claude GitHub App，线程启动前就会报错，根本开不起来。

你本机装的东西，线程一样都带不上

线程运行在云端的全新环境里，你本机 Claude Code 里装的技能、MCP 服务器、插件和工具，一样都不会带过去。如果任务需要使用特定工具或扩展，必须通过以下方式补齐：

• 技能、子 Agent 与自定义命令：提交到项目关联的代码仓库中（例如 .claude/skills/、.claude/agents/ 和 .claude/commands/），线程启动克隆时会自动加载它们；此外，线程也会自动加载你在 claude.ai 账号中启用的技能；
• 插件（Plugins）：在 Project settings > Plugins 中添加，每个新线程启动时都会加载；
• MCP 服务器：线程通过你 claude.ai 账号上绑定的连接器（connectors）来获取 MCP 工具，所有线程均可直接使用，无需针对每个项目重复配置。但需要特别注意：项目对话本身没有任何连接器，需要使用连接器的工作必须作为任务指派给线程执行；
• 命令行工具与包：在云端环境的 setup script（初始化脚本）中安装；
• 内网访问与环境变量：若需要访问公司内网 API、私有包仓库或需要 API 凭据，应在云端环境（Environment）中配置网络访问域名白名单、环境变量与 API 凭据。

多仓库：仓库里的权限规则和 hooks 不生效

项目支持关联多个代码仓库，但单仓库和多仓库时，仓库里的配置生效规则不一样。

关联多个仓库时，每个仓库的 CLAUDE.md、.claude/ 下的技能、子 Agent 和命令，以及各仓库 settings.json 里启用的插件，都会照常加载；两个仓库对某个插件意见不一时，以 Project settings > Plugins 里的设置为准。

不生效的是各仓库 settings.json 里定义的权限规则（permission rules）、hooks 和 env 环境变量，多仓库时一律不起作用，只有已启用插件自带的 hooks 仍会运行。原因是多仓库时线程从所有仓库克隆目录的上一层启动，不读任何一个仓库的这份文件。

所以在多仓库项目里，统一的规矩要写进项目指令（Project instructions），环境变量要在云端环境里配。另外，在 Project settings 里改的指令、仓库、插件和环境，只对新开的线程生效，已经在跑的线程不受影响。

当前可用范围

• 入口与平台限制：只能在 claude.ai/code 网页端、桌面端以及 Claude 移动端 App 中使用，终端 CLI 暂不支持（CLI 里的 claude project 命令用于管理本地目录状态，与此完全无关），也不能通过 Amazon Bedrock、Google Cloud 的 Agent Platform 或 Microsoft Foundry 等第三方平台使用；
• 仅限云端执行：本地会话无法加入项目，线程只在云端运行。官方说对本地工作流的支持「很快」会来；
• 单人私有与归属固定：项目只属于创建它的个人用户，无法与他人共享，线程记录也没有分享选项，beta 期间没有组织级管控；此外，线程严格归属于启动它的项目，无法在项目之间移动或复制；
• 没提交的改动可能丢：线程的沙箱在两轮之间暂停，继续时恢复；万一恢复不了，线程会从一份全新克隆接着做，没 commit 的改动就没了。长任务要在指令里让线程阶段性 commit 并 push 到远端分支。

总结：如何开始你的第一个长周期项目？

新版项目把开会话、分派和跟踪交给了协调者，你要花心思的地方变成了：规则写没写清、环境配没配好、交回来的活怎么验。

在向新项目正式派发成批工作之前，建议按照官方指引做好初始设置与验证：

1. 编写项目指令（Project instructions）：利用好最多 16,000 字符的指令空间，作为每个新线程的启动简报。明确写清工作在哪个代码库和分支上展开、PR 如何命名、线程在完工前如何自行检查（如运行 make test 和 make lint 并在最终汇报中附上摘要）、遇到依赖或凭据缺失时禁止自行猜测或 mock 伪造，以及哪些操作必须先在线程内获得你的许可。关于单一仓库特有的规则，则写在仓库的 CLAUDE.md 中。
2. 先试跑一小块任务并检查结果：先发送一小块真实工作，或者点击启动 Claude 推荐的建议线程；待其完成后，点开线程查看它如何汇报、在其分支上具体做了什么修改。若发现其做出了错误假设或缺少访问权限，及时回到指令或环境中修复。
3. 检查线程的模型与思考强度：前往 Project settings > General 检查 Thread model 与 Thread effort。新项目默认所有线程都运行在 Opus 模型的高思考强度（High effort）下，这会最快消耗套餐额度，可根据任务复杂度换用较小模型或调低思考强度。
4. 先设限磨合，符合预期后再放开：在项目对话中要求 Claude 先提出建议线程（propose threads）、等你看过点头后再启动，并限制一次最多同时跑几个线程。待跑过几轮、确认其拆解和汇报方式完全符合你的预期后，再放开这些限制。

谁现在能用

• 现在：公开 beta，先推给用过云端会话、且在 claude.ai 聊天或 Cowork 里没有旧项目的 Pro、Max 用户。
• 稍晚：用过旧版项目的用户晚一点推，好让旧项目顺利迁过来。
• 接下来一周：扩大到更多 Pro、Max 的 Claude Code 用户；之后才轮到整个 Claude，以及 Team 和 Enterprise 方案。
• 怎么判断轮到你没有：claude.ai/code 侧边栏或桌面端 Code 标签页里看不到 Projects，就是还没推到你的账号，可以先加入等候名单。
• 在哪用：网页（claude.ai/code）、桌面端，以及 iOS、Android 的 Claude 手机 App。
• 旧项目怎么办：照常能用，等新体验推广到聊天和 Cowork 时再统一升级。