这个我还以为就是个本地文件夹功能。请向我介绍如何通过其进行多ca配合

这段引用的“各家 ca 的 project 功能”，我理解的“project”就是：给一个任务建独立工作区，天然带自己的文件、分支或 worktree，以及自己的 agent 会话，这样多个 agent 就能同时干活又不互相踩。核心机制基本都是 git worktree 加会话隔离，再加一个任务列表或信箱负责协调。 以 Claude Code 为例。它的 project 层就是项目目录和.claude/ 下的配置，记录设置、agent 定义、skill 等。多 agent 配合目前有两档： 一档是 subagent，在主会话里派出去。它是同进程派生的任务，有自己的上下文窗口，干完把结果回报给主 agent；主 agent 负责所有调度。适合同步的、只需要结果的活，比如“查一下这个报错在哪个模块”“跑一遍测试并总结”。成本低，但它们之间不会互相商量，只能往上报。 另一档是 agent teams（实验功能，要在 settings.json 里设 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 才开）。开起来之后，一个会话当 lead，用自然语言让它 spawn 几个 teammate，比如“spawn 4 个 teammate 并行重构这几个模块，都用 Sonnet”。每个 teammate 都是完整独立的 Claude Code 实例，有自己的上下文、自己的权限模式（默认继承 lead 的），共享一个任务列表：任务有 pending、in progress、completed 三态，可以设依赖，认领时用文件锁防并发抢同一个。agent 之间靠信箱直接通信，信箱是 ~/.claude/teams/{team}/inboxes/{agent}.json，lead 的对话历史不会带给 teammate，所以 spawn 时要把任务背景写清楚。你可以用上下键在 agent 面板里切到任意 teammate 直接和它说话，也可以让它先出计划再动手。 真正配合好的关键，是三个约束： 一是文件隔离。同一时刻不要让两个 agent 改同一个文件，改之前先切成各自负责的模块或目录；需要同一仓库并行，就用 git worktree，一个 agent 一个独立的 checkout。 二是任务拆分要独立。teams 最适合的是调研不同方面、各自负责一个新模块、并行验证不同假设的 debugging、前后端加测试分层推进；不适合串行任务、改同一文件、依赖特别多的情况，这种用单会话或 subagent 更划算。 三是 token 账要算。每个 teammate 都是独立实例，token 用量随人数线性涨，coordination 本身也有成本，所以并不是人越多越好，要按能不能独立推进来决定开几个。 Cursor 这边思路类似，但 project 层弱一些，多 agent 的主要手段是 worktree。Agents Window 里每个 agent 可以进独立 checkout，IDE 里用 /worktree 让这条 chat 在独立 checkout 里跑，用 /best-of-n sonnet,gpt,composer 同一个任务多模型各跑一个 worktree 再比结果；/apply-worktree 拿回主工作区，/delete-worktree 清掉。worktree 的初始化可以用.cursor/worktrees.json 配 setup-worktree，比如自动 npm ci、把主 worktree 的.env 拷进来，省得每个新 workspace 都要重新配环境。 Codex 的 app 也是这个路子：多个 agent 并行，各自 worktree 隔离改动，你在面板里跟进度、中途纠正。Gemini CLI 除了并行 subagent，还能通过 Jules 扩展把任务派到云端会话。 所以你要自己搭一套多 ca 配合，落地顺序我建议这样： 先把单 agent 的 project 目录规矩立好，配置、约定、skill 都放进仓库，让任何新实例一启动就有同样的上下文，这是并行不跑偏的前提。然后用 worktree 做物理隔离，每个任务一个目录、一个分支，测试和构建不会互相干扰。接着用任务列表或 ISSUE 当协调层，写清楚每个任务的边界、依赖和验收条件，agent 之间只在这个层面通信。最后加 hook 做质量关卡，比如 agent 要结束或任务要标记完成时跑 lint 和单测，不过就挡回去继续干。 先别一上来就开四个 agent，容易全是返工，从两个能独立推进的任务开始试。