Claude Code Projects 将一条提示转化为受管理的智能体团队

9 月 17 日，Claude Code Projects 新增协调器、并行云端线程和共享记忆，将一项请求转化为受管理的编程智能体团队。这项测试版更新将开发者的角色从指挥彼此孤立的会话，转变为监督一个能够自行拆分工作的项目。这一承诺比又一次模型升级更具影响力：它将协调、上下文和交接流程纳入 Anthropic 的产品之中。

Anthropic 表示，重新设计后的系统能够界定请求范围、委派任务、审查输出并组装完成结果。每个工作线程都是完整的 Claude Code 云端会话，拥有各自的代码仓库副本和分支。用户可通过一个中央对话监控这些线程、调整其方向或检查它们的工作。

真正重要的竞争是 Claude Code 与 OpenAI Codex 之间的较量，而非不同 Claude 模型之间的比较。OpenAI 已将 Codex 定位为一个指挥中心，用于管理跨项目协作的多个智能体。Grok Bot 则将类似理念扩展到编程之外，让持久化智能体跨应用运行。Anthropic 的回应是：将项目而非单个聊天设为工作的核心单位。

这种结构对于可按服务、代码仓库或研究方向清晰拆分的工作具有明显优势，但也带来棘手问题。并行智能体会消耗更多用量，共享记忆可能保留错误假设，重叠代码仍会导致合并冲突。协调器减少了人工编排工作，但并不能取代工程判断。

Claude Code Projects 现可拆分工作

这项重新设计以主动协调器取代相关聊天的文件夹，由其决定如何拆分工作。

此前，Projects 主要将围绕共同主题的对话和辅助材料归类在一起。用户仍需决定由哪个会话处理每项任务，也必须在会话之间传递决策，并在之后整合结果。该界面会存储上下文，但并未将项目作为一项协调行动来管理。

重新设计的 Projects 测试版改变了这种关系。用户选择目标，并提供代码仓库或其他上下文来源后，Claude 就能建议工作内容、创建线程、向现有线程发送任务，并监控由此产生的输出。

Anthropic 将这种交互比作向幕僚长交代任务。这个说法概括了其预期的层级关系。主对话并非只是另一个编程会话，而是用户定义成果、Claude 组织执行人员的场所。

每个线程仍可供检查。开发者可以留在主项目视图中观察进度，也可以打开某个工作线程，审阅其推理过程并引导实现方向。这一点很重要，因为当测试失败或智能体修改了错误组件时，仅有协调器的界面会隐藏过多过程。

对于软件项目而言，每个线程都是独立的云端会话，拥有各自的代码仓库副本和分支。因此，后端迁移可以与移动端更新并行进行，而无需让两个智能体编辑同一个工作目录。线程还可以使用子智能体、循环或工作流，进一步拆分其获分配的任务。

Anthropic 给出了两个代表性场景。在其中一个场景中，智能体分别分析不同的结账端点、测试优化方案，并并行创建拉取请求。另一个场景中，线程先更新 API、Web 和移动端代码仓库中的调用方，随后协调器说明哪些变更应优先合并。

这些场景揭示了该功能的自然边界。当一个目标包含多个可识别的工作流，并且每个工作流都有可验证的成果时，Projects 的效果最佳。测试、拉取请求、性能分析数据和文档草稿，都为协调器提供了可供检查的具体产物。

这项重新设计的范围不止于源代码。当项目包含知识工作而非代码仓库时，线程可以阅读文档并产出草稿。项目资料库汇集用户提供的文件和 Claude 创建的产物，为后续任务提供此前工作的材料。

Anthropic 最初向使用 Claude Code 云端会话的部分 Pro 和 Max 订阅用户开放测试版。在 Anthropic 迁移旧体验期间，已有 Web 或桌面项目的账户暂不在初始开放范围内。该公司表示，在扩展至聊天、Cowork、Team 和 Enterprise 用户之前，将先扩大 Claude Code 的覆盖范围。

这种分阶段发布意味着，这项公告代表的是产品方向，而非已完成的平台迁移。现有 Projects 暂时仍按旧模式运行。发布时也尚不支持本地执行，不过 Anthropic 表示，对本地工具、代码和私有网络的支持即将推出。

因此，多智能体发布引入了新的控制层，但并未取代每一种既有工作流。开发者仍可进入单个线程并审查拉取请求。变化在于，最初的任务拆分和交接管理由谁执行。

为什么共享记忆会改变智能体工作流

只有当每个工作者都能依据同一套当前决策行动、而无需反复提示时，并行执行才真正有用。

同时运行多个智能体并非新的技术手段。开发者可以打开多个终端、创建工作树，或向子智能体分配狭窄任务。更难的问题是：在需求发生变化，或某个分支发现其他分支所需信息后，如何让这些工作者保持一致。

Claude Code Projects 通过项目级记忆来解决这一问题。Anthropic 表示，每个线程都可以向同一份共享记忆添加内容并从中获取信息。该系统能够保留诸如发布日期调整、已放弃的导出功能，或修改计费代码前必须获得批准等细节。

这不同于将整段对话复制到每个新线程中。共享记忆旨在保留跨任务仍然有用的决策和工作偏好。处理 API 变更的工作者不需要完整的设计讨论记录，但需要最终确定的契约及其中已建立的所有约束。

资料库提供了第二层上下文。它在项目中存放用户文件及创建的产物。新线程可以基于规范、早期草稿或另一位工作者的输出继续工作，而无需再次要求用户上传相同材料。

记忆与资料库共同将项目转化为持久化工作空间。协调器持有目标，工作者持有任务特定的上下文，共享层则跨越两者之间的边界传递决策。该架构瞄准了使用智能体时最重复的环节之一：每次委派前都要重新陈述背景。

它也将提示工程转化为产品设计。用户仍需要明确目标，但应不再需要大量复杂指令来描述智能体彼此之间必须如何交接。Anthropic 实际上是在宣称，协调器能够决定哪些上下文应进入某个线程，以及哪些内容应在项目中持续保留。

这一说法仍难以仅凭公告验证。记忆系统必须决定存储什么、何时修订，以及事实冲突时应以哪个来源为准。错误的项目记忆可能比孤立聊天更快地将同一个错误传播给多个工作者。

事实与偏好的区别尤为重要。例如，“状态更新应简洁”这样的偏好可以安全地影响每个线程；而有关身份验证行为的技术假设，则应始终关联证据、代码仓库状态和具体时间点。将两者视为同样持久的记忆，会导致偏离。

团队还需要了解记忆如何变化。如果一个线程报告结果后，协调器更新了共享假设，开发者需要知道变更了什么，以及后续哪些任务使用了它。否则，持久上下文的便利性可能削弱审计轨迹。

这正是知识融合在笔记记录之外变得重要的地方。智能体工作流日益结合代码仓库状态、规范、对话和生成产物。结果的质量取决于能否在提供足够行动上下文的同时保留来源可追溯性。

项目资料库可以降低搜索成本，但收集本身并不能保证相关性。旧草稿可能与当前计划相冲突，生成的产物也可能包含未经审查的主张。协调器需要可靠的方法，区分权威输入与只是方便使用的输入。

Claude 的记忆也延伸到工作风格。用户可以要求它调整汇报进度、启动新线程或提供详细更新的频率。这些设置可以减少长期项目的干扰，但较少的检查节点也会减少及早发现错误方向的机会。

真正有意义的进步并非无限记忆，而是用于分发上下文的层级结构。如果 Anthropic 能正确建立这种层级，开发者就不必再花那么多时间充当智能体之间的信息中转站。如果层级设计失误，Projects 可能会产出协调一致、却附带异常整洁状态更新的错误结果。

Claude Code 与 Codex 的竞争转向协调能力

Anthropic 和 OpenAI 现在竞争的是：谁能让监督多个智能体比直接操作单个智能体更安全、更简单。

OpenAI 将其 Codex 桌面应用作为一个工作空间推出，用于管理跨项目并行运行的智能体。其独立线程和工作树让开发者能够在不同任务之间切换，同时智能体继续在后台工作。该产品将此界面定位为处理长期技术工作的指挥中心。

Anthropic 的协调器则带来了不同的侧重点。用户不必创建并指挥每个工作者，Claude 可以解释项目目标并自行分派工作。用户仍是监督者，但 Claude 成为此人与单个会话之间的管理层。

OpenAI 正朝着相同的大方向发展。其 Codex 指挥中心支持并行智能体、项目组织、技能和后台任务。该公司更新的 Agents API 还将上下文管理、工具、环境和子智能体协调打包为托管基础设施。

因此，两者的差异比简单的功能清单所呈现的更为细微。两家公司都认为，开发者将管理异步工作的组合，而不是每一分钟都与一个智能体结对工作。它们的产品差异在于，任务拆分有多少会自动完成，以及用户对该过程拥有多明显的控制权。

Claude Code Projects 将对话式协调器置于核心位置。Codex 一直强调开发者可在智能体和项目之间切换的工作空间，而其底层执行框架可以协调子智能体。这些方法可能很快趋同，因为协调行为是软件能力，而非某个模型的固定属性。

这场竞争将由工作流质量决定。开发者需要看到哪些工作正在运行、某项任务为何被创建、哪些文件发生了变更、消耗了多少用量，以及哪些事项需要批准。如果一个聪明的协调器反而让这些问题更难回答，它的价值就会降低。

这种比较也改变了“模型性能”的定义。编程基准测试通常考察一个模型能否解决某项任务。而协同项目还必须正确拆分工作、保持依赖关系、发现不兼容的输出，并交付连贯的结果。

较弱的执行者有时能在更好的协调者引导下成功，因为系统提供了聚焦的上下文和可靠的验证。更强的执行者则可能失败：多个副本可能追逐重叠的改动，或基于不一致的假设开展工作。因此，产品架构本身也成为被衡量的智能的一部分。

Anthropic 现有的智能体模式已预示了这一方向。其指南区分了并行会话、专注型子智能体和可相互沟通的智能体团队。Projects 将这些要素整合进更高层级的界面，由它选择线程并维护共同上下文。

OpenAI 的托管式智能体框架则从另一个方向对 Anthropic 施压。开发者可以在与 Codex 所用同类云基础设施上构建自己的协同产品。Anthropic 必须让 Projects 足够实用，才能留住那些原本会自行搭建定制工作流的用户。

Claude Code 还在与内部编排脚本竞争。有经验的团队已经使用议题队列、持续集成、worktree 和审查机器人来协调智能体。他们不会仅仅因为新抽象能创建更多会话就采用它。它必须在保留现有控制权的同时，减少运营工作。

重新设计的产品可能会首先吸引希望获得并行执行能力、却不想自行构建编排层的小型团队和个人开发者。大型组织则会提出更深入的问题，包括身份、权限、审计日志、网络边界以及共享记忆的保留方式。

这种分化为 Anthropic 带来两项任务。它既必须让使用体验简单到可以从一段对话开始，也必须提供足够的结构来支持专业的软件交付。隐藏复杂性有助于推广，但隐藏过度会让系统不适合处理重要代码库。

因此，竞争正在超越代码生成。Claude Code 与 Codex 的较量，如今还涉及协调者行为、项目记忆、环境控制以及人工监督的质量。最优秀的执行模型依然重要，但它只是置身于一个更庞大的系统之中。

更广泛的竞赛正超越编程

Claude Code Projects 属于一场更大的转变：从单一助手转向围绕成果组织、可持续运行的智能体群体。

Grok Bot 最明确地展现了这一方向。SpaceXAI 将其描述为一支始终在线的智能体团队，能够操作计算机、跨应用工作，并在用户离开后继续执行。用户可通过手机或桌面端交互，而智能体会保留上下文。

Grok Bot 的发布瞄准的不只是软件开发。该公司将销售触达、营销活动、办公室运营和漏洞修复列为内部应用场景。群组对话可以让多个专业智能体共享项目上下文。

Claude Code Projects 从编程出发，但采用的结构可以延展至其他工作。协调者、执行线程、共享记忆、连接器和工件库，可以支持研究、规划、文档制作和运营任务。Anthropic 计划将其扩展到 Claude chat 和 Cowork，也让这一发展路径更加清晰。

Claude 近期的新增功能进一步强化了这一方向。Claude Docs 将起草和协作编辑纳入同一产品家族。Slides、Design、连接器和工件为智能体提供了更多输出形式。Projects 则提供了围绕更长期目标协调这些工具的层级。

这一转变之所以重要，是因为大多数商业工作都跨越应用边界。一次产品发布可能需要竞品研究、定位文档、演示幻灯片、网站改动、分析设置和支持材料。单个聊天会话可以协助处理每一项工作，但项目协调者可以将它们分配为相互关联的工作流。

编程是一个很好的试验场，因为其输出相对更容易验证。源代码可以编译，测试可以通过，拉取请求可以展示精确的改动。营销策略或研究综合的验证确定性更低，因此协调者判断的评估也更困难。

Anthropic 的示例因此仍贴近工程实践。分析端点性能和淘汰某个 API 版本都具有明确依赖关系。协调者可以要求执行者运行测试，并通过代码库分支隔离修改。这些控制机制并不能完美适用于所有知识型任务。

即使在工程领域，拆分质量也取决于架构。边界清晰的一组服务适合并行工作，而紧密耦合的遗留应用则不适合。当多个线程触及同一共享接口、配置或数据库假设时，反而可能增加冲突。

重新设计的 Projects 体验并未声称能消除这一限制。Anthropic 表示，重叠修改将作为普通合并冲突来解决。这是一个令人耳目一新的具体边界：协调可以隔离分支，但无法让相互冲突的变更自动兼容。

因此，更广泛的智能体竞赛可能会奖励那些懂得何时不该并行化的产品。为五项独立调查创建五个执行者可以节省时间；但为一次顺序迁移创建五个执行者，可能会增加审查工作和使用量，却无法缩短关键路径。

一个好的协调者必须在派发任务前评估依赖关系。当某项输出决定下一项任务时，它应保留顺序步骤。它也应避免在缺少关键决策时启动执行者，否则执行者将被迫猜测。

这让项目规划成为核心产品能力。智能体系统曾将规划视为实施前生成的一段文字。多智能体产品必须把计划转化为调度决策、上下文边界、验证关卡和升级规则。

开发者应当关注，因为这些决策决定了智能体是减少管理工作，还是仅仅将其转移到别处。手动协调多个会话很繁琐。审查一波协调不佳的改动可能更糟，尤其是每个线程单独看起来都言之成理时。

知识工作者面临同样的权衡。协同研究项目可以并行收集证据、起草章节并制作支撑材料。然而，共享记忆也可能把对某个来源的误读扩散到每一项输出中。可搜索的工程知识库只有在底层文档仍可追溯且保持最新时才有帮助。

持久趋势并不只是更多智能体，而是在人的目标与模型行动之间构建一个运行层。Claude Code Projects 是 Anthropic 试图让这一层感觉像一段对话，而不是塞满互不相关执行者的仪表盘。

共享上下文并不能消除共同风险

协调者减少了交接工作，但也将有关上下文、权限和资源使用的决策集中到一个自动化层中。

第一项约束是使用量。Anthropic 警告称，Projects 可能会更快触及使用限制，因为多个线程可能同时运行，而且每个线程都是一个完整的 Claude Code 会话。协调者在规划、审查和报告时也会消耗资源。

用户可以为协调者和执行者选择模型与投入级别，Anthropic 表示项目专属使用量是可见的。这些控制至关重要，因为并行化可能将一个请求转变为多次大量执行。一个简单提示词已无法描述实际启动的全部工作量。

产品需要让这种扩张变得可预测。开发者应在协调者投入大量资源前知道，它计划启动两个线程还是十个线程。他们也需要能够限制并发数，并停止不再服务于项目目标的工作。

第二项约束是合并质量。独立的代码库分支可以防止执行者立即互相覆盖，但无法防止架构冲突、不兼容的假设或重复实现。这些问题会在后续审查或集成过程中暴露。

协调者可以安排拉取请求的顺序并标记依赖关系，但 Anthropic 尚未证明测试版能可靠地解决复杂集成决策。开发者应将其组装出的结果视为一项需要常规测试和审查的提案，而不是分支已构成正确系统的证明。

第三项约束是记忆准确性。共享记忆可以免除重复说明，但每一项保留的信息都会成为后续工作的输入。错误的发布规则或过时的 API 假设，可能在任何人察觉前影响多个线程。

团队应考察产品是否展示记忆条目、来源、修订记录和使用者。他们还应测试更正是否能一致地传播。持久却难以审计的记忆会形成一种隐性的项目风险。

第四项约束是安全性。云端线程可能访问代码库、连接器、插件和外部服务。每增加一个执行者，直接人工关注之外发生的工具调用和决策数量也会增加。权限边界必须针对每项操作生效，而不应只在项目开始时生效。

这一担忧并非智能体领域的假设问题。近期关于意外智能体行为的报道，包括系统超出用户意图行动，或以令人意外的方式使用工具。这些案例并不能证明 Projects 存在缺陷，但解释了为何协同自主性需要可追溯的批准机制。

第五项约束是环境适配性。上线时，线程将在 Anthropic 的云端运行。拥有私有依赖、内部服务、受监管数据或严格网络控制的组织，可能需要本地或由客户控制的执行方式，才能广泛采用该系统。

Anthropic 表示，用户网络后的本地运行即将推出。这一承诺具有战略重要性，因为仅限云端执行会让许多企业代码库和工作流无法在测试版中实际使用。实现细节将比时间表更重要。

本地执行者也会使协调者模型更复杂。系统必须协调不同的工具可用性、凭据、网络策略和代码库状态。在受管云镜像中成功的线程，在定制开发环境中可能表现不同。

第六项约束是责任追溯。当一个执行者编写代码、另一个运行测试、协调者再组装结果时，团队需要清晰记录每个智能体产出了哪些工件。最终摘要无法替代执行轨迹。

当智能体相互修改工作成果时，这一点更加重要。协调者可能接受某项输出、将其退回修改，或派发审查者。一旦部署后出现缺陷，开发者需要能够还原这一过程。

这些风险并不否定产品的价值。它们界定了协调何时有用的条件。尤其在测试版阶段，并行智能体应应用于边界清晰、输出可观察且验证机制强的任务。

团队可以先在范围可控的迁移、文档更新或独立调查中测试 Projects，再将其用于紧密耦合的生产变更。这种方式能够衡量协调者是否真正减少了总体审查时间，而不是仅仅同时完成更多活动。

Anthropic 最有力的主张是，用户可以描述一个目标，然后让 Claude 管理工作。该 beta 必须证明，这种管理包含克制、升级处理和证据保留。启动代理很容易，决定何时让它们停止也是产品的一部分。

什么将证明 Claude Code Projects 模式的价值

三个信号将表明，协同式 Projects 会成为一种持久的工作流，还是仍仅仅是一场令人印象深刻的 beta 演示。

第一个信号是能否成功扩展到受选订阅用户和新创建的项目之外。Anthropic 计划先在 Claude Code 中扩大 beta 范围，再将这一重新设计引入聊天、Cowork、Team 和 Enterprise 账户。顺利的迁移将强化这样一种判断：Projects 可以成为 Claude 通用的工作容器。

迁移问题则会削弱这一判断。现有的 Projects 包含文件、指令和用户已经依赖的既定工作流。Anthropic 必须在引入旧模式中没有的记忆、资料库和协调者行为时，保留这些材料。

第二个信号是本地执行功能的到来，以及清晰的管理控制机制。Anthropic 表示，与私有工具和代码并行运行的本地线程即将推出。关键测试在于，这些线程能否在遵守网络、凭据和代码仓库策略的同时，保留同样的协同体验。

可信的本地选项将把 Projects 扩展到云端工作者无法访问所需系统的环境中。它也会让企业对执行过程拥有更多控制权。若实现延迟或功能受限，Claude Code Projects 将仍最适用于兼容云端的代码仓库和风险较低的实验。

第三个信号是协调是否能改善已完成的工作，而非只是增加可见的活动量。团队应将耗时、审查工作量、合并失败、返工和使用情况，与顺序式代理工作流进行比较。线程数量不是成功指标。

Anthropic 最终应提供测试项目级成果的评估。这些评估可以包括跨代码仓库迁移、相互冲突的需求、不断变化的规格，以及需要协调者暂停处理的失败情形。仅凭模型基准无法验证周边的管理系统。

OpenAI 和 SpaceXAI 也将通过竞争性回应提供另一种证据形式。如果 Codex 深化自动任务路由，或 Grok Bot 扩展结构化的软件工作流，协同项目将成为一个标准产品类别。如果竞争者反而强调直接的人类控制，这将揭示一个重要分歧：用户究竟愿意委托多少管理工作。

开发者无需等待这场竞争尘埃落定。他们可以测试 Claude 是否能在线程之间保留决策、创建合理的任务边界、解释依赖关系，并产出便于审查的成果。他们还可以观察，协调者是否会在作出具有重要后果的假设前请求澄清。

Claude Code Projects 最具说服力之处，在于它能够消除沟通开销，同时不隐藏执行过程。这种平衡将有用的编排与一大堆自主工作区分开来。共享记忆、云端线程和协调者提供了必要的组成部分，但它们之间的交互质量仍是真正的产品。

下次当一项任务跨越多个代码仓库或需要独立调查时，不妨将一个协同项目与现有工作流进行比较。记录用于向代理说明任务、解决冲突、核查假设和审查结果的时间。如果协调者降低了这一总负担，Anthropic 改变的就不只是 Projects 界面，而是让代理管理成为开发平台的一部分。