Claude Code Projects 进了 PR 时代，难的不是多开 Agent

一个项目里同时跑着六个 Agent，听起来很像效率神话。可只要它们改过同一套代码，你大概率见过另一面，六个分支、四个 PR、两处冲突，还有一条没人愿意碰的测试失败。

Anthropic 这次重做 Claude Code Projects，最有意思的地方不在于又加了几个并行线程，而是把这个尴尬场面当成产品边界摆在台面上。它没有承诺协调器能神奇地消灭冲突。官方的原话很克制，线程在自己的 branch 和 repo 副本里工作，如果碰到同一段代码，仍然按普通 PR 那样解决 merge conflict。

这句不够性感，却比许多多 Agent 演示更重要。

因为 AI 编程从单个对话走向一组持续运行的 Agent 后，真正稀缺的已经不是生成代码的手速，而是把工作拆开、把结果验掉、把变更合进去的工程秩序。

从文件夹到项目，产品形态变了什么

根据 Anthropic 9 月 18 日发布的说明，新版 Projects 目前以 beta 形式向部分使用 Claude Code cloud sessions 的 Pro 和 Max 用户开放。一个 Project 不再只是放说明、文件和对话的文件夹。你给它一个目标，再连上 repo 或上下文，它会先提出可立即开工的事项，然后由一个 coordinator 分派多个 threads。

每个 thread 都是一段独立的 Claude Code 云端会话，有自己的 branch 和代码副本。它可以读仓库、运行测试、开 PR，也可以在需要时继续调用 subagent、loop 和 workflow。主对话负责汇总，你既能在项目对话里调整方向，也能钻进某个 thread 看它到底改了什么。

这套描述里有三个关键词，目标、线程、可合并变更。

过去不少 Agent 产品的使用方式还是「给它一个大 Prompt，等它回来」。它解决的是单次交付。新版 Projects 试图处理的是一周内持续推进的工作，前一轮的决策、文件和产物会留下来，下一轮能接着用。官方把这件事称作 shared memory 和 library。

我觉得这个方向是对的。软件工程从来不是把一个问题答出来，而是不断接住上一次修改留下的后果。没有状态的 Agent 再聪明，也会在第二天像刚入职一样问你接口在哪、约定是什么、为什么这个看似多余的校验不能删。

但记忆不是项目管理。

它只能减少解释成本，不能替你定义所有权、验收条件和发布顺序。把这两个东西混在一起，后面会很难受。

它瞄准的不是写代码，而是派活

Anthropic 给了两个例子。一个是降低结算链路 p75 延迟，Project 可以同时让不同线程 profile 各个 endpoint、测试优化方案、分别开 PR。另一个是退役旧版 v1 API，它会按 API、Web、Mobile 仓库分线程迁移调用方，跑测试、开 PR，再告诉你哪些 PR 应该先合。

如果你做过 Java 或 Spring 系统改造，会知道这里真正值钱的不是「能改三个 repo」，而是依赖顺序被显式放到台面上。

退役一个接口，最糟的做法通常不是漏改，而是改得太齐。服务端把 v1 关了，Web 的灰度还没开，移动端版本还在审核，线上用户先替团队完成了集成测试。人类工程师会在脑中维护一张很粗糙的依赖图，谁先提供兼容层、谁迁调用、谁补监控、谁最后下线。多 Agent 也得有这张图，否则并行只是在更快地产生半成品。

所以我更愿意把 coordinator 看成一个轻量的调度层，而不是会自动管理项目的虚拟技术负责人。它的价值是把任务切成能独立提交的单元，把进度和证据带回一个地方。它不该替代人对架构边界的判断。

这块需要注意一下。

很多人会把「一个 Agent 负责后端、一个负责前端、一个负责测试」当作天然合理的拆法。实际项目往往没这么干净。一个 API 字段改名会同时碰 DTO、OpenAPI、Feign Client、BFF、前端类型、埋点和回滚脚本。按技术栈分工看起来整齐，按变更边界分工才更安全。

对 Projects 而言，最好的任务不是「重构订单系统」，而是「为订单查询 v2 加兼容响应字段，补 contract test，并开一个独立 PR」。前者听着像领导交代的活，后者才像一个可以被审查和回滚的工程任务。

并行的上限，藏在 merge conflict 里

官方没有回避线程重叠会产生 merge conflict。这个设计很工程化，也因此有点别扭。协调器可以同时启动很多 branch，但 Git 并不会因为提交者是 Agent 就变得更好说话。

想想看，一个线程在抽公共校验逻辑，另一个线程正给同一个 Controller 加接口，第三个线程只想补测试却顺手整理了 fixture。它们各自都可能是正确的，放在一起却未必能合。更麻烦的是，冲突解决不只是选左还是选右，它经常需要理解哪个修改更贴近业务约束。

这不是模型能力差，而是并行系统的老问题。数据库有事务隔离，分布式系统有一致性协议，Git 则把最后一道协调留给 merge。代码 Agent 没有逃出这个规律。

所以一个反直觉结论是，Agent 数量不该按团队人数扩容，而该按可并行的变更面扩容。一个模块边界清楚、测试能独立跑、接口契约稳定的任务，开四个线程很舒服。一个核心领域模型正在迁移、多人都要动同一批对象的任务，两个线程可能都嫌多。

我一直觉得，真正成熟的 AI coding workflow 会先问「哪些改动绝不能同时发生」，再问「还能并发多少」。

这和 LangGraph 一类工作流里给 Agent 设 state、checkpoint、human approval 是同一件事。图里的并行节点不是越多越先进，它们必须有明确的 join 点。落到代码仓库，PR 就是一个很现实的 join 点，CI、review 和 merge 顺序则是不可跳过的关卡。

Anthropic 让每个 thread 工作在独立 branch，其实是默认选择了隔离优先。这个选择牺牲了一点即时协作的幻觉，换来可以审查、可以撤销、可以追责的变更记录。对生产系统，这个 trade-off 很值。

shared memory 很诱人，也最容易被误解

新版 Projects 说，每个 thread 会向共享记忆写入，也会从中读取，随着项目推进减少复杂 Prompt 的需求。它还会记住你的工作和沟通方式，比如多久汇报一次、何时开新线程、更新写多细。

听上去很顺手。你终于不用在每次会话开头粘贴项目背景、编码规范、失败历史和那条「不要动支付开关」的提醒。

可一旦记忆被多个线程共同读写，它就不再是便利功能，而是一份会影响执行的项目状态。

这里至少有三类东西必须分开。

第一类是相对稳定的事实，比如 Java 版本、构建命令、模块职责、接口契约。这些适合进共享记忆，最好还能追溯来源。

第二类是暂时性的决策，比如本周只做灰度、某个兼容层两周后删除、一个线上问题正在观察。这类信息应该有过期时间和负责人。否则一个 thread 把临时补丁当永久规范，后面会越积越脏。

第三类是指令和偏好，比如「不要改数据库 schema」「PR 描述里写风险」「先问再删文件」。它们最好是版本化的 repository instruction，而不是埋在模型自动摘要里。因为你需要知道它何时生效，又被谁修改。

这一点和企业里做 RAG 很像。把所有文档塞进去，不等于知识库可用。没有来源、权限、时效和冲突处理的记忆，最后只是一台更会引用旧话的复读机。

Anthropic 还没有在公告里展开 shared memory 的可见性、冲突策略和审计粒度。对于个人项目，这可能不是第一优先级。可一旦它开始接多个 repo、多个贡献者和真实生产凭据，这些问题会迅速从体验问题变成治理问题。这里我愿意保留疑问，产品的方向值得期待，具体边界还得看后续落地。

对 Spring 团队，怎么把它用得不冒险

不是说传统的单 Agent 编程不行。修一个空指针、补一段单测、写一个迁移脚本，开一个干净会话往往更快。Projects 适合的是超过一轮回复、包含多个可以拆分成果的工作。

如果把它拿来处理一个 Spring Boot 服务的中等改造，我会用下面这个节奏。

先由 coordinator 只做侦察，不改代码。让它产出模块地图、关键调用链、现有测试、风险点和一个按依赖排序的任务清单。这个阶段的输出必须能被人快速读完，别让它写三十页调研报告。

然后按变更边界分线程。一个线程改 API contract 和 OpenAPI，一个线程改 service 与 repository，一个线程补 integration test 和 Testcontainers，一个线程检查 metrics、日志、feature flag 与回滚路径。每个任务都写清不允许碰的目录和验收命令。

再把 shared memory 当作项目备忘录，不当作事实来源。真正的事实仍然放在代码、ADR、接口文档和 CI 日志里。记忆只负责帮新线程快速定位，不能替代证据。

最后设置一个人类 merge gate。Agent 可以开 PR、跑测试、整理差异，合并核心路径前仍由知道业务的人判断。特别是鉴权、金额、库存、幂等和数据迁移，CI 绿了只是入场券，不是批准章。

这套做法一点也不酷，甚至有点像把一个实习生团队管得很细。

可多 Agent 的现实就是这样。你获得了一批速度极快、上下文有限、偶尔会自信越界的执行者。好的系统不是假装它们不会犯错，而是让错误只能停在小分支里。

云端执行带来的边界，别等出事才补

目前这些 threads 跑在 cloud，官方说让它们与本地工具、代码以及内网一起运行的能力即将到来。这也是新版 Projects 最需要冷静看待的限制。

云端 Agent 能连什么 repo、能读什么 connector、能否访问 issue、日志和密钥，决定了它到底是助手还是高权限自动化账号。把「能自动开 PR」理解成「可以随便给权限」，很容易出事。

我会把权限切成三个层次。默认只读用于侦察和计划。受控写入只允许创建 branch 与 PR，禁止直推 main。高风险操作例如生产发布、删除资源、修改密钥、执行数据修复，一律需要单独审批。

同样别忽略成本。Anthropic 明确提醒，多个完整 Claude Code session 并行运行会更快触到 usage limit，用户可以分别选择 coordinator 和 worker 的模型与 effort level。这个提醒很实在。一个大模型主管配多个便宜 worker 也许划算，所有线程都上最高档却在重复读仓库，就未必了。

工程上的成本单位不该只是 Token，还要算上 review 时间、CI 排队、冲突处理和出错后的回滚。省下十分钟编码，换来两小时合 PR，不叫效率。