Anthropic 重新设计 Claude Code Projects：协调智能体、并行线程、共享记忆

Anthropic 今天推出了重新设计的 Claude Code Projects 体验，用一个两层的多智能体系统，取代了原先静态的文件与对话整理工具：上层是一个协调者智能体，接收用自然语言描述的工程目标；下层是一组工作线程，在并行的云端会话中执行工作。测试版自 2026 年 9 月 17 日起向部分 Claude Pro 和 Max 订阅用户开放，并计划在接下来一周内扩大推送范围。

在此之前，开发者如果要用多个 Claude Code 会话完成一次构建，得自己拆分工作、在会话之间手动传递结果，最后再把输出拼到一起。在重新设计的 Projects 中，开发者只需描述要做什么，由 Claude 负责拆解、分派和汇总。

协调者：像向幕僚长交代工作一样使用它

这套架构分为两个功能层。顶层是协调者：开发者用自然语言向这个 Claude 实例交代任务 —— 用 Anthropic 的话说，就是「像向幕僚长交代工作那样」。协调者负责界定接到的目标的范围，把每一部分分派给新的或已有的工作线程，监控进度，审阅产出，并汇总成最终结果。

每个工作线程都是一个完整的 Claude Code 云端会话，拥有自己的分支和独立的仓库副本。线程之间无法覆盖彼此正在进行的工作。当两个线程修改了同样的代码行时，结果就是一次普通的合并冲突 —— 没有引入新机制，由 Git 来处理。每个工作线程还可以利用 Claude Code 现有的子智能体和工作流原语进一步拆分自己的任务，因此一次大规模迁移可以铺开到许多文件上，而无需协调者直接跟踪每一个子智能体。

Anthropic 发布时给出的示例说明了这种模式：开发者设定目标，要降低结账接口的 p75 延迟，Claude 就开启多个并行线程，分别剖析每个接口、测试优化方案并提交拉取请求。在第二个场景中，Claude 连接 API、Web 和移动端三个仓库，为每个仓库创建一个线程，以下线一个已弃用的 v1 接口 —— 迁移调用方、运行测试、提交 PR，最后报告哪些需要先合并。开发者不需要分配任务、管理会话状态，也不需要划定线程边界。

共享记忆取代了逐会话的上下文交接

这次重新设计中最具持久价值的新增部分是记忆层。在单会话的 Claude Code 工作中，会话一结束，上下文就会重置。开发者重新开启一个项目会话时，不得不再解释一遍：计费相关的改动必须由哪位服务负责人批准、某个功能为什么被砍掉、发布日期又是什么时候推迟的。

重新设计的 Projects 提供了持久的共享记忆，所有线程都能读取和写入。一个线程得知计费服务设有强制审查关卡后，会把这一点记入共享记忆；之后的线程就会继承这个约束。周一记录的决定，周四运行的线程也能用上。除了记忆之外，项目资料库会汇集开发者上传的文件以及 Claude 生成的产出物 —— 这是一个持久的存储，而不是逐会话的输出。Anthropic 表示，Claude 还会学习开发者的工作方式和沟通风格，包括多久同步一次进展、每次更新写得多详细。

延伸阅读：Claude Code 桌面版加入 /resume，开发者不必再为丢失上下文交税

与 GitHub Copilot 和 OpenAI Codex 相比如何

在竞争格局中，并行线程协调并不新鲜。GitHub 的 Copilot 应用于 2026 年 6 月全面上线，支持在相互隔离的本地 git 工作树中运行并行会话，并提供一个汇总会话、议题和 PR 的 My Work 仪表盘。OpenAI 的 Codex 可以在隔离沙箱中运行最多八个并行云端子智能体。这两套系统都已投入生产使用。

Anthropic 在结构上的不同之处在于：协调者是一场自然语言对话。开发者描述想要的结果，由 Claude 决定线程边界。Copilot 需要开发者自己配置工作树；Codex 需要明确定义任务。这种抽象上的优势能否抵消下面这个最大的短板，在实际中很关键。

这个短板就是只能在云端执行。每个线程都作为 Anthropic 托管的云端会话运行，无法访问本地工具、私有网络资源，或企业防火墙之后的文件。GitHub Copilot 的工作树则在本地 —— 智能体可以针对开发者自己的环境运行测试，而无需把代码发送到外部服务器。Anthropic 的公告明确承认了这一点：本地执行「很快就会推出」，但目前的测试版里还没有。对于 CI 流水线或测试环境位于私有网络之后的企业团队来说，只能在云端运行这一限制，挡住了眼下最有价值的使用场景。

延伸阅读：Claude Code 的 SendFeedback 工具，让 AI 自己起草会话失败报告

并行线程会加快套餐额度的消耗 —— 还撞上了一桩正在进行的诉讼

在额度计算上，每个工作线程都算作一个完整的 Claude Code 会话。三个并行线程消耗滚动 5 小时用量窗口的速度，大约是单个会话的三倍。Anthropic 的公告明确警告，在协调者模式下，项目会更快触及用量上限。

这一变化恰逢一桩集体诉讼尚未了结。2026 年 6 月 14 日，原告 Karl Kahn 在美国加利福尼亚北区联邦地区法院提起一项拟议集体诉讼，指称 Max 5x 套餐提供的额度约为 Pro 基准的 3.5 倍，而非宣传的 5 倍；Max 20x 套餐约为 6 到 8 倍，而非 20 倍。Anthropic 的服务条款保留了其自行调整上限的权利；这一条款是这场诉讼的核心。Anthropic 已申请驳回起诉，听证会定于 2026 年 11 月 6 日举行。

Projects 的并行线程让这笔有争议的额度账变得更加直接。独立研究者引用的 Anthropic 成本文档显示，在 plan mode 下运行的智能体团队，消耗的 token 大约是单个普通会话的七倍。工作流上的好处 —— 自动拆解、持久记忆、并行执行 —— 是真实的。代价是，一个多线程项目实际可用的每周额度，只相当于同样的套餐额度按顺序使用时的一小部分。

在真实生产代码上的可靠性，仍是已知的短板

截至最近一次更新，Claude Opus 5 以 97.0% 的成绩位居 vals.ai SWE-bench Verified 排行榜榜首。SWE-bench 的题目取自公开的 GitHub 仓库，问题描述相对清晰，而该基准的局限 —— 提示过于详细、偏重单一编程语言、存在数据污染风险 —— 在研究文献中已有充分记录。

在私有生产代码库上测试智能体的 Real-SWE 基准，呈现出的图景要严峻得多。根据 The New Stack 2026 年 9 月 14 日的分析，Fable 5.1 在 Real-SWE 上的得分为 38.8% —— 也就是说，超过 60% 的任务它都没能完成。这个基准由 Y Combinator 投资的 Specific Labs 开发，使用获得授权的私有生产代码库，而不是公开仓库。干净的公开基准与杂乱的内部代码库之间的落差，是一个反复出现的发现：一旦被放进上下文隐含、测试不完整、相关业务逻辑并不写在问题描述里的环境中，智能体的表现就会大幅下滑。

协调者架构通过在工作线程的产出与最终汇总之间插入一道审阅步骤，部分地应对了这个问题。但协调者层面审阅的可靠性，并没有得到独立验证。在生产代码上部署 Projects 的开发者，应当把这道审阅步骤当作一道重要的质量关卡，而不是一个已经解决的问题。

值得关注的里程碑：本地执行与企业版开放

目前的测试版不包括已经在使用 Web 端或桌面端 Projects 的开发者 —— 在 Anthropic 为他们升级之前，他们仍停留在当前版本。尚未获得访问权限的 Pro 和 Max 订阅用户可以加入候补名单。Team 和 Enterprise 用户的开放将在更大范围推送之后进行，具体日期尚未公布。

接下来最重要的功能是本地线程执行。在线程能够访问内部测试基础设施、私有数据库和受网络限制的环境之前，Projects 架构足以展示这个概念，但也受限到足以挡住那些最能体现其生产力主张的企业部署场景。Anthropic 是在 GitHub Copilot 凭借本地工作树巩固领先之前还是之后推出本地执行，将决定这次测试版在全面推送完成后显得有多重要。