Claude Code重启Projects

Claude Code 把 Projects 从“项目文件夹”变成了“云端 AI 开发团队”

Anthropic 近日重新推出 Claude Code 的 Projects 功能，让多个 Claude Code 智能体能够在同一个项目内共享记忆、目标、文件与产物，并通过多个线程并行处理开发任务。据 The Verge 9 月最新报道，每个线程在底层对应一个独立的 Claude Code 云端会话，拥有自己的代码仓库副本和 Git 分支，再由一个协调器统一分派、跟踪和汇总工作。

**Projects 是 Claude Code 面向复杂开发任务提供的云端多智能体工作空间。**它不再只是保存聊天记录或关联某个代码仓库，而是把任务拆分、上下文共享、并行执行和结果集成放进同一个容器里。开发者可以让不同线程分别排查后端故障、补充测试、修改前端和更新文档，而不是依次等待一个 Claude 完成所有工作。

这次变化的重点不是“多开几个 Claude”，而是让多个智能体在同一套项目状态下工作。过去开发者即使同时启动多个终端会话，也要自己复制背景信息、划分目录、同步进度和处理结果；新版 Projects 则把这些原本由人承担的协调工作，交给了产品内置的调度层。

共享记忆，不等于共享同一个上下文窗口

**共享记忆是多个智能体可以访问同一组项目事实、目标、文件和历史产物的机制。**这里的“记忆”不能简单理解为所有线程共用一段无限长的聊天记录，也不意味着一个智能体能够实时读取另一个智能体的全部推理过程。

新版 Projects 共享的对象至少包括四类信息：

• 项目的总体目标与当前任务状态；
• 代码、配置、文档等文件；
• 各线程生成的分析、修改和其他 artifacts；
• 经过协调器整理的项目级上下文与工作进展。

这种设计更像一间共享资料室，而不是所有工程师共用一个大脑。每个线程仍有自己的局部上下文和执行轨迹，只是在需要时读取统一的项目资料，并把可复用的结果写回项目空间。

上下文隔离仍然是多智能体系统的重要前提。一个负责数据库迁移的线程没有必要持续接收前端组件的每次修改，否则并行带来的速度优势，很快会被上下文膨胀、注意力稀释和额外推理成本抵消。真正有用的共享记忆，需要在“所有人都知道”和“只有相关线程知道”之间做筛选。

这也是新版 Projects 与第三方长期记忆插件需要区分的地方。社区工具通常通过本地 Markdown、SQLite、向量数据库或 MCP 服务，把历史事实跨会话保存下来；Projects 则把共享目标、云端会话、文件产物和并行执行整合进 Claude Code 自身的项目模型。两者都在解决“重新开会话就失忆”，但前者更偏记忆基础设施，后者更偏任务编排与软件交付。

每个线程都是一条独立分支

**线程（thread）是 Projects 中执行具体任务的独立 Claude Code 云端会话。**每个线程使用自己的仓库副本和 Git 分支，因此不同智能体可以同时修改代码，而不必争用同一个工作目录。

这一实现选择相当务实。Anthropic 没有发明一套取代 Git 的“AI 协作协议”，而是沿用了开发团队已经熟悉的分支、差异和合并模型。一个线程可以重构身份认证模块，另一个线程可以补充端到端测试，第三个线程可以分析性能问题；只要它们修改的区域相互独立，最终结果就有机会像多条普通 Pull Request 一样被整合。

**协调器（coordinator）是负责拆分任务、调度线程并整理结果的上层智能体。**它相当于技术负责人和项目经理的混合体：理解总体目标，决定哪些任务能够并行，把任务交给不同线程，并持续追踪各线程产出的代码或分析。

协调器并不是一个能够自动解决所有工程问题的超级合并器。如果两个线程同时修改同一段代码，重叠部分仍会产生标准的 Git 合并冲突，处理方式与两名开发者提交互相覆盖的 PR 没有本质区别。Projects 可以发现和组织冲突，但不能保证自动选择正确实现。

线程还可以继续拆出子任务，这使 Projects 具备层级式编排能力。例如，负责支付模块的线程可以进一步分派接口兼容性检查、测试补全和错误日志分析。不过，递归拆分也可能导致智能体数量、工具调用量和代码变更面迅速扩大，因此“可以继续拆”不等于“拆得越多越好”。

新版 Projects 与单智能体、Agent Teams 有什么区别

**新版 Projects 的核心差异是把多智能体协作包装成一个持久、统一的云端项目工作区。**它与单会话 Claude Code、此前的实验性 Agent Teams，以及开发者手工维护的多终端方案存在明显区别。

| 维度 | 单个 Claude Code 会话 | Agent Teams／手工多会话 | 新版 Projects | |---|---|---|---| | 执行方式 | 一个智能体顺序处理任务 | 多个实例并行运行 | 多个云端线程并行运行 | | 上下文结构 | 单会话局部上下文 | 各实例上下文相对独立 | 局部线程上下文加项目级共享记忆 | | 任务协调 | 主要由用户下指令 | 用户或实验性负责人协调 | 内置 coordinator 统一组织 | | 代码隔离 | 通常操作当前工作区 | 依赖用户配置 worktree 或分支 | 每个线程拥有仓库副本和独立分支 | | 进度共享 | 需要人工总结 | 通过消息或任务列表同步 | 在同一 Project 内汇总目标、状态和产物 | | 冲突处理 | 单会话内自行修正 | 最终由用户合并 | 仍遵循 Git 合并冲突机制 | | 持久性 | 容易受会话边界影响 | 取决于外部记忆方案 | 项目级信息持续保留 | | 适合任务 | 小型修复、明确改动 | 实验性并行开发 | 跨模块、可拆分的复杂工程任务 | | 价格与额度 | 取决于 Claude Code 方案 | 多实例通常增加消耗 | 截至 2026 年 9 月 17 日，公开资料未给出独立定价与固定线程上限 |

Agent Teams 更强调多个 Claude 实例彼此通信、认领任务和同步状态，而 Projects 更像承载这类协作的产品级外壳。它增加了项目记忆、云端执行、文件产物和分支隔离，让多智能体能力不再只是一项需要用户手动开启、反复配置的实验机制。

两者也不应该被理解为完全割裂的路线。Projects 很可能代表 Anthropic 把此前多智能体实验中有效的部分，重新整理成面向日常开发流程的产品形态：用户管理的是项目和目标，而不是一组零散的智能体进程。

真正的提升是吞吐量，不是单个智能体突然更聪明

新版 Projects 首先提高的是并行吞吐量，而不是单线程推理能力。假设一个版本发布前需要完成权限审计、数据库迁移检查、回归测试和文档更新，单智能体只能轮流处理；多线程则能同时启动四项工作，整体完成时间由各任务耗时之和，接近变为最长任务耗时加上协调与合并时间。

并行收益只会出现在能够合理拆分的任务上。如果四个任务分别需要 20、30、40 和 50 分钟，理论上的串行时间是 140 分钟，并行执行的理想下限是 50 分钟，理论时间缩短约 64.3%。但这只是调度模型，不是 Anthropic 公布的 Projects 实测成绩；真实项目还要加入初始化、上下文读取、代码审查、冲突处理和失败重试时间。

高度耦合的任务通常不适合多智能体并行。让三个线程同时重构同一个核心类、修改同一份数据库 schema 或调整同一条状态机，可能造成大量互相覆盖的实现。此时协调器再聪明，也需要面对需求歧义和代码依赖，而不是单纯处理文件冲突。

最适合 Projects 的任务具有三个特征：边界明确、输入可共享、输出可验证。测试生成、日志分析、模块级迁移、文档更新、跨平台兼容性检查和相对独立的功能开发，通常比“把整个系统架构优化一下”更容易获得稳定收益。

“共享记忆”也不会自动让 Token 消耗下降 90%

目前没有可靠公开数据证明新版 Projects 能把 Token 消耗固定降低 90%。网络上流传的类似数字，多数指向第三方 Claude Code 记忆工具、特定缓存方案或个别测试环境，不能直接套用到 Anthropic 这次重做的 Projects。

共享记忆确实可能减少重复说明。开发者不必在每个新线程里重新粘贴架构文档、编码规范和历史决策，协调器也能把项目事实分发给相关线程，这部分能够降低重复输入带来的成本。

多智能体并行同样可能显著增加总消耗。每个云端线程都要读取上下文、调用工具、分析代码并生成结果；当一个线程继续拆分子线程时，总推理量可能比单智能体高出数倍。Projects 优化的是完成复杂任务所需的人类时间与协调成本，不一定优化每一次任务的模型账单。

截至 2026 年 9 月 17 日，现有公开信息没有给出 Projects 的标准性能跑分、最大并发线程数、共享记忆容量、云端会话最长运行时间或单独价格。对这些指标作出确定结论都为时过早，团队在正式接入前仍应观察实际账户中的配额、审批能力和成本统计方式。

合并冲突只是表层问题，语义冲突更难处理

Git 能检测同一行代码被不同线程修改，却很难发现两个实现之间的语义冲突。一个线程可能把鉴权逻辑改成异步，另一个线程仍按同步接口编写测试；两边修改的文件完全不同，Git 可以顺利合并，但程序在运行时依然会出错。

多智能体系统因此需要比传统 CI 更强的集成验证。Projects 最终是否好用，不只取决于协调器能否启动足够多的线程，还取决于它能否理解任务依赖、安排合并顺序，并在集成后重新运行测试、类型检查、静态分析和安全扫描。

共享记忆还会引入“错误扩散”风险。如果某个线程把错误的架构假设写入项目记忆，后续线程可能把它当成既定事实继续工作。对个人偏好、编码规范、已确认决策和临时推测进行分级，会成为项目记忆能否长期使用的关键。

一套成熟的共享记忆至少应该区分以下内容：

1. 已由人类确认的项目规则；
2. 从代码与配置中提取的可验证事实；
3. 智能体生成但尚未审查的分析；
4. 已过期或被新决策覆盖的历史信息；
5. 涉及密钥、用户数据与内部基础设施的敏感内容。

如果 Projects 只是把所有会话摘要堆进同一个知识池，记忆越多反而越容易污染后续任务。相比“记住多少”，开发者更应该关注信息从哪里来、何时更新、谁确认过以及能否追溯。

云端执行把权限治理推到了台前

每个线程都是一个能够读取仓库、修改文件和运行工具的云端会话，因此 Projects 的安全边界比普通聊天窗口更宽。团队需要明确 Claude Code 能访问哪些仓库、环境变量、构建系统、测试数据库和外部服务，也要确认各线程的权限是否继承自项目，还是能够按任务进一步收窄。

最危险的配置不是智能体能力不足，而是它拥有不必要的生产权限。一个负责更新 README 的线程不应获得生产数据库凭据，一个负责测试的线程也不应默认具备部署主分支的能力。多智能体意味着同一时间有更多执行主体在行动，权限过宽带来的风险会随并发量增加。

企业团队还应重点检查审计记录。理想情况下，每项代码改动都应能够追溯到具体线程、输入任务、使用的文件和最终合并操作；共享记忆中的关键决策，也需要保留来源与更新时间。否则，Projects 提高了开发速度，却可能降低代码责任链的清晰度。

对开发者来说，Projects 更像 AI 原生 CI 前的一层

新版 Projects 最有价值的定位，是连接需求与代码集成的智能调度层。传统 CI 在代码提交后运行固定流程，Projects 则尝试在提交之前理解目标、拆分工作、生成变更并组织验证；前者执行确定性脚本，后者处理开放式工程任务。

它暂时还不能取代技术负责人。协调器可以分工，但很难替团队决定业务优先级；它可以汇总实现，却不能天然判断某项架构妥协是否值得；它可以解决部分代码冲突，却无法独立承担上线风险。

开发者更合理的使用方式，是把 Projects 当成一支速度很快但需要清晰边界的外部团队：先给出验收标准和禁止修改的范围，再让线程并行工作，最后通过测试、审查和人工决策完成合并。任务描述越模糊，智能体数量越多，偏离目标的成本往往越高。

Anthropic 正在把 Claude Code 从助手变成执行平台

这次更新说明 Claude Code 的竞争焦点已经从“能不能写代码”，转向“能不能管理一项完整的软件工程任务”。单次代码补全和聊天式问答越来越同质化，项目级记忆、云端执行、分支隔离、多智能体调度和可审计交付，才是下一阶段开发工具拉开差距的地方。

新版 Projects 的方向是对的，因为它承认软件开发天然是多任务、长周期和多人协作的。它没有试图用一个无限上下文窗口吞下整个代码库，而是采用独立线程、共享资料和 Git 分支，把复杂度拆开处理。

新版 Projects 也远没有到“一个人等于一家公司”的程度。协调器可能拆错任务，线程可能重复劳动，共享记忆可能保存错误结论，多个分支仍会冲突，云端执行还会增加成本与权限风险。它真正减少的是人工调度的机械工作，而不是软件工程本身的判断责任。

对于模块边界清楚、测试体系完整的代码库，这会是一项实用更新；对于缺少文档、没有自动化测试、核心逻辑高度耦合的项目，多智能体只会更快地放大混乱。Projects 能否成为 Claude Code 的关键护城河，最终要看协调器的任务拆分质量、记忆治理能力，以及 Anthropic 后续公布的价格、并发限制和企业控制选项。

参考来源

• Anthropic Claude Code 官方 GitHub 仓库：用于了解 Claude Code 的官方发布、问题追踪与基础产品信息。
• 知乎：Claude Code Agent Teams 多智能体协作开发模式：介绍多个 Claude Code 实例的任务拆分、通信与并行协作思路。
• Reddit：Claude-Flow 多智能体协调平台讨论：展示社区此前围绕共享记忆和多终端协调进行的探索。