Anthropic 推出 Claude Code Projects：面向长期开发任务的 AI 协调智能体

Anthropic 今日推出了 Claude Code Projects， 这是为使用其热门“氛围编程”（vibe coding）工具 Claude Code 的开发者提供的一种新方式，帮助他们在构建某个项目——例如一款应用、一个网站或其他开发任务——时保持条理清晰；此类项目通常需要持续、长期的开发工作。

全新的 Claude Code Projects 本身即是一个由 Claude 驱动的 AI 协调智能体（agent），据 Anthropic 所述，它始终处于运行状态，可接收开发者关于其特定持续性任务的自然语言输入，并将其拆分为并行线程，从而加快并提升开发工作的效率。Claude Code Projects 随后会随时间自动协调这些线程，在开发持续进行并不断演进的过程中，维护该项目的共享记忆（shared memory）。

对于那些曾多次跨会话使用 Claude Code 来持续推进某项长期项目的用户而言，这是一项重大变革：此前，持续性开发工作要求用户自行在外部单独维护一份项目状态记录，并在新会话中将其重新输入 Claude Code；或者让 Claude Code 查阅上一次关于该项目对话的压缩版本，重新调查其最新状态，并尝试重构上一会话的终止位置以及用户在当前会话中提出的要求。

对企业而言，此举极具意义：其数字门店、网站、内容管理系统、采购平台或其他业务应用极少存在明确的终点。这些系统往往需在数年内持续更新、打补丁、扩展和适配。

Anthropic 提出，与其每次需要变更时都让开发者启动一个全新的 Claude Code 会话，并重新建立该持续性工作的上下文、决策及当前状态，不如由 Claude Code Projects 来跨整个开发过程保存共享记忆与项目上下文，将新工作与既往进展协调一致，并更轻松地从先前线程中断处继续推进。

然而，该命名方式略显混淆：Anthropic 此前已推出一项名为 Claude Projects的独立功能，该功能最早于 2024 年 6 月发布，是一种通用型 Claude 工作区，用于归组聊天记录、文件、指令及项目知识。基础版 Claude Projects 可包含多个聊天记录，并在其中保留共享知识，但每个聊天仍为独立对话；除非相关上下文被纳入项目知识或记忆中，否则一个聊天中的上下文不会自动带入另一个聊天。

此次于 9 月 17 日宣布的全新 Claude Code Projects 体验虽名称相似，但旨在解决不同问题：即在多个 Claude Code 会话之间协调具身式（agentic）软件开发。该测试版最初仅面向部分使用 Claude Code 云会话的 Claude Pro 和 Max 订阅用户开放，且这些用户尚未在网页端或桌面端启用 Projects 功能。

Anthropic 表示，未来一周内，访问权限将逐步扩大至上述订阅计划中的更多 Claude Code 用户，而此次重构后的体验最终也将覆盖更广泛的 Claude 用户群体，包括 Team 和 Enterprise 版本用户。在推广期间，Pro 和 Max 用户现有的 Claude Projects 将照常运行。

这一转变意义重大，因为编码智能体（coding agents）正日益具备处理超出单次提示（prompt）或单个拉取请求（pull request）范围的工作能力。

OpenAI、GitHub 和 Google 均已转向异步、并行及更长时间运行的智能体工作流。

Anthropic 推出 Claude Code Projects 的核心判断在于：开发者日益需要的不再仅仅是另一次编码会话，而是一个 横跨多个会话的持久化协调层 ，该层能记住整体目标，并在线程间分派任务。

在 X 平台发布的上线帖文中，Anthropic 将该交互比作向首席幕僚（chief-of-staff）下达简报：用户可一次性以任意顺序向 Claude 提交多项任务，而 Claude 将自行判断每项请求应归属新线程还是现有线程。

从单个会话到协同开发工作

使用多个编码智能体的开发者，往往需将较大功能拆分为若干离散任务，为每个会话分别建立上下文，并最终自行整合各项结果。Claude Code Projects 的设计目标正是将此类协调工作大量交由 Claude 完成。

Claude Code Project 在创建针对不同工作模块的独立执行线程的同时，维持着更宏观的目标与上下文。Anthropic 在最终上线公告中将该架构描述为“线程执行任务，Claude 指导方向”。每个 Project 均设有一个位于各工作线程之上的协调器（coordinator）。

随着需求演变，开发者可继续与该协调器对话，而无需等待某项任务完成后再发出下一项指令。Claude 可将新请求路由至现有线程，或新建一个线程；用户亦可在需要检查或引导底层工作时打开特定线程。

Anthropic 还提供一个“概览”（Overview）面板，显示需用户关注的事项。在其 X 平台上线帖文中，该公司表示开发者可通过手机引导单个线程，使人类操作员得以介入，而无需在工作站上始终保持所有 Claude Code 会话处于开启状态。

这使得交互的基本单位从孤立的编码任务转变为更长期持续的工作体。

例如，Anthropic 表示，开发者可创建一个目标为降低某应用结账流程 p75 延迟的 Claude Code Project。Claude 随后可创建并行线程，分别用于分析端点性能、测试优化方案及发起拉取请求。

在另一示例中，一个团队可连接 API、Web 和移动应用代码仓库，并要求 Claude 淘汰已弃用的 v1 端点。多个独立线程可分别迁移调用方并测试各仓库，而协调器则追踪依赖关系，并告知开发者哪些变更需优先合并。

每个工作线程本身即为一个在独立分支及代码仓库副本上运行的 Claude Code 云会话。线程还可借助子智能体（subagents）、循环（loops）及工作流（workflows）进一步拆分任务。不过，协调机制并不能消除常规软件开发中的冲突：若多个线程修改重叠代码，Anthropic 表示仍将产生常规合并冲突（merge conflicts），其解决方式与其他拉取请求相同。

共享记忆有助于确保所有参与该项目的智能体均能同步获取项目状态

仅凭并行执行本身，在编码智能体中已不再罕见。Claude Code Projects 更具实质意义的部分，或许是凌驾于单个会话之上的持久化状态。

每个工作线程均向共享 Project 记忆贡献信息并从中读取信息。在更长期的工作过程中，Claude 可保留诸如发布日期推迟、某项功能被取消，或关于修改特定服务前须咨询何人的指令等决策。Anthropic 表示，用户还可调整 Claude 的检查频率、新建线程的频次，以及其更新内容的详细程度。

Claude Code Projects 还包含一个库，用于收集用户提供的文件以及 Claude 生成的产物，从而为后续工作提供一个持久化的素材池。该项目可配置其专属的云环境、连接器、插件、指令和模型设置。

这与 Claude Projects 中的知识库（knowledge-base）概念相关，但又彼此不同。Claude Projects 利用上传的知识和指令为对话提供上下文；而 Claude Code Projects 则在工作线程（worker threads）之间添加了共享的操作记忆（shared operational memory），使得在某项计划的一部分进行过程中所作的决策，能够影响开发工作中其他部分的后续工作。

对于企业级工程团队而言，这一区别可能与生成更多智能体（agents）的能力同等重要。当前的挑战已日益不再仅仅是某个智能体能否修复一个缺陷或实现一项功能，而是当多个智能体并行工作时，团队如何保存需求、依赖关系、先前决策以及人工监督。

因此，这一区别可简单概括如下：

• Claude Projects 帮助 Claude 记住 你所提供的 上下文。

• Claude Code Projects 旨在帮助 Claude 记住并 协调 它正在执行的工作。

竞争焦点正从编码智能体转向智能体管理者

Anthropic 并非唯一意识到编排（orchestration）问题的公司。OpenAI、GitHub 和 Google 均已超越“开发者在一次线性对话中与单一编码智能体协作”的模式。

日益重要的竞争层面在于：开发者如何委派一系列工作任务、保留上下文、监控并发智能体，并在不成为它们之间人工调度员的前提下纳入新需求。

OpenAI 可能是最直接的对比对象。其 Codex 应用被设计为一个多智能体工作区（multi-agent workspace），开发者可在其中并行运行多个编码智能体、隔离其变更，并监督耗时更长的任务。其与 Claude Code Projects 的重叠程度很高：两者均将并行智能体视为标准工作流，而非仅作为高级工作流处理。

Anthropic 公开的设计中一个显著差异在于，其在工作线程之上明确设有一个协调器（coordinator）。开发者持续与单个 Claude Code Project 对话，而 Claude 自身可决定新指令应进入现有流程流，还是创建另一条流程流。Anthropic 还明确描述了跨越这些工作线程的共享 Project 内存。

因此，差异化因素并非 Claude Code Projects 独家支持并行或长时间运行的编码智能体——竞争对手早已实现这两点。更具体的构想是： 一个持久化的对话式协调器 成为监督这些会话的顶层接口。

GitHub 则从另一方向应对该问题：其优势在于代码仓库（repository）本身及整个开发生命周期。GitHub 的智能体工具支持多个相互隔离的会话，并可将其紧密关联至分支（branches）、议题（issues）、拉取请求（pull requests）及持续集成（CI）工作流。这使得 GitHub 在代码仓库本身已是开发工作天然控制平面（control plane）的场景中具备优势。

Anthropic 则试图在单个代码仓库和会话之上叠加一层对话式协调层。其自身已弃用端点（deprecated-endpoint）示例横跨 API、Web 和移动应用三个代码仓库，而单个 Claude Code Project 协调器则追踪整体迁移及合并顺序。

Google 的 Jules 提出了第三种模型。Jules 支持异步编码工作及仓库级内存（repository-level memory），使后续任务可访问在该仓库上累积的偏好设置与指导原则。

Anthropic 的 Claude Code Projects 将持久化提升至更广泛计划（broader initiative）的层级：多个工作线程可共同贡献于同一共享内存，并始终处于一个协调器对话的统管之下。

这些产品正趋同于许多相同的基础构件（primitives）——并行执行、隔离环境、异步工作、内存机制及人工干预——但它们将控制平面（control plane）置于不同位置。

OpenAI 强调多智能体编码工作区；GitHub 强调原生仓库（repository-native）的执行与监督；Google 的 Jules 强调围绕仓库的持久化、异步工作；而 Claude Code Projects 则将关于开发计划的一次长期持续、不断演进的对话本身作为协调层。

当前为云端执行，未来支持本地执行

Claude Code Project 的工作线程目前在云端运行。这使其能在开发者关闭笔记本电脑或离线后继续工作；但 Anthropic 的发布说明中明确指出一项重要限制：这些云端工作线程尚无法访问开发者计算机上的文件或工具，亦无法访问内部网络中的系统。

Anthropic 表示，本地支持“即将很快”推出，届时 Claude Code Projects 将可与本地代码及工具协同运行，并部署于组织内部网络之后。

这一区别对那些开发环境依赖私有软件包、内部服务、受限网络或无法暴露至云端执行环境的本地工具的企业而言至关重要。

Anthropic 表示，开发者仍可通过手机引导正在进行的工作，而这些工作会话则远程执行。这使得移动设备转变为一种监督界面，而无需开发机器本身保持在线。

Anthropic 并未为 Claude Code Projects 单独制定定价方案。Projects 消耗订阅者现有的 Claude 使用额度，且每个工作线程均为一次完整的 Claude Code 会话。由于一个 Project 可同时运行多个线程，Anthropic 提醒用户其可能更快达到使用上限。用户可查看特定 Project 的用量详情，并分别为协调器和工作线程选择模型及工作强度级别。

因此，更广泛的竞争已超越‘AI 智能体能否编写代码’这一问题。OpenAI、GitHub、Google 和 Anthropic 均已能让智能体以异步方式并行开展工作。

更难的问题正日益变为：由谁来协调这些智能体？由什么来记住它们积累的决策？开发者又该前往何处管理可能超出任何单次会话生命周期的一整套工作？

借助 Claude Code Projects，Anthropic 的答案是一个持续进行的协调器对话：开发者随计划演进持续向其简报，共享内存承载各项决策向前推进，而一组动态变化的 Claude Code 工作线程则在其下方执行具体任务。

这与现有的 Claude Projects 产品有所区别，后者目前仍是用于组织聊天、文件、指令和知识的更通用工作区——至少现阶段如此。