多 Agent 并行写代码时，别把协作退化成终端堆叠：CrewCode 的 Worktree、审批与交接实战
当一个仓库里同时跑 Claude Code、Codex 或其他编码 Agent，最先失控的通常不是模型输出，而是工作现场：每个 Agent 各占一个终端，分支和 worktree 的对应关系只存在于人的记忆里；一个会话刚改完共享配置，另一个会话又在旧上下文中继续修改；等到准备合并时，才发现两边碰到了同一组接口。把多个 Agent 放进同一个项目，并不自动等于形成了协作。
CrewCode 是一个 Apache-2.0 许可的本地优先桌面开发环境，定位是多 Agent 软件开发的控制台。它把聊天、真实终端、编辑器和 Git worktree 放在一个应用中，并提供 Mission Control 用于观察和审批。官方 README 列出的接入对象包括 Claude Code、Codex、OpenCode、Pi、Ollama、Hermes、OpenRouter 与 Grok Build；这不是说它能替这些工具决定任务，而是给并行执行提供一个可检查的工作面。
本文关心的不是“再装一个 AI IDE”，而是如何把并行 Agent 的边界变得可见、可复查，并在任务结束时回到正常的 Git 评审流程。
先拆开三个容易混在一起的问题
多 Agent 开发至少有三层约束，不能用一个聊天窗口解决。
- 上下文边界：每个 Agent 应明确知道自己负责的子问题、允许修改的文件和验收方式。提示词能帮助描述它，但无法隔离文件写入。
- 文件边界：两个 Agent 同时在同一工作目录改代码，即使 Git 分支不同，也可能互相读取未提交状态、覆盖生成文件或启动冲突的开发服务。
- 合并边界：即使每个分支都能通过测试，也仍需要人或独立 Agent 检查 diff、接口契约和最终合并次序。
CrewCode 的核心取舍是把第二层建立在 Git worktree 上：每个并行任务使用隔离的工作目录和分支，而不是让所有终端共享当前 checkout。它还会在合并前呈现文件重叠和潜在的跨文件契约冲突提示；这类提示应被视为审查入口，而不是“已自动解决冲突”的承诺。
安装前先审查脚本，再做 dry run
官方 Linux 安装器会针对 Debian/Arch 系发行版使用原生包管理器；其他 x86_64 Linux 发行版采用用户目录下的 AppImage 方式。README 建议先下载并阅读脚本，安装器会验证所选 v0.2.1 发布产物的 SHA-256，并且拒绝以 root 身份运行。
curl --proto '=https' --tlsv1.2 -fsSLo install-crewcode.sh \ https://crewcode.logixhub.icu/install less install-crewcode.sh sh install-crewcode.sh --dry-run sh install-crewcode.sh
这里的顺序值得保留：--dry-run 先展示它准备采用的安装路径，随后才写入本地应用文件。对需要在公司开发机上使用的桌面 Agent 工具，还应把脚本来源、release 版本和校验方式纳入团队的软件引入流程，而非只在个人终端执行一条 pipe-to-shell 命令。
用“一个任务，一个 worktree”建立最小协作面
首次使用时，不要一上来就拉起四个 Agent。先选一个可以独立验收的任务，例如“为某个 API 增加输入校验并补单元测试”，然后按下面的流程组织：
- 在 CrewCode 中添加或 clone 仓库，确认默认分支和本地测试命令可用；
- 为任务创建 worktree，并让该 Agent 只在这个 worktree 的聊天、终端与编辑器面板中工作；
- 在任务说明中给出允许修改的目录、不可触碰的配置、测试命令和完成条件；
- 通过聊天输出、终端记录和 diff 观察过程，而不是只等待 Agent 的“完成”消息；
- 任务完成后先审 diff、运行测试，再决定提交、开 PR、合并或丢弃该 worktree。
这套流程看起来比让 Agent 直接修改主工作区慢一点，但它把失败的代价压低了：错误实验留在可丢弃的工作目录中，未通过评审的改动不必先污染当前分支。对于会修改锁文件、迁移脚本或共享类型定义的任务，隔离尤其重要，因为这些文件往往是并行改动最早发生语义冲突的位置。
Crew 与 Workbench：并行不等于共享写入
CrewCode 的 crew 功能允许配置多个 lane，每条 lane 可以指定角色、Agent、模型与 effort，并选择隔离 worktree 或共享工作区模式。实际使用中，优先把共享工作区视为例外：只有当一个 Agent 专门做只读分析、另一个 Agent 明确执行同一任务且由人实时协调时，才考虑共享。
更稳妥的分工是让 lane 的产物天然不同。例如：
| Lane | 目标 | 推荐产物 |
| — | — | — |
| 调研/诊断 | 找到根因与影响范围 | 问题清单、相关文件、复现步骤 |
| 实现 | 修改一个受限模块 | 独立 worktree 中的提交与测试结果 |
| 审查 | 只读检查实现分支 | 风险项、遗漏测试、接口意见 |
| 验证 | 在干净环境复跑 | 命令输出与是否可合并的结论 |
这种设计避免“两个 Agent 都去修同一个 bug”。如果诊断 lane 发现实现任务需要扩大范围，应先把结论交给操作者，再新建或调整任务；不要让它顺手进入另一个 Agent 的 worktree 改文件。
还可以把冲突预防前移到派工阶段：把修改点按“文件所有权”和“接口所有权”分别标注。前者规定谁可以写某个目录或配置文件，后者规定谁负责改变公开类型、数据库 schema 或 HTTP 契约。两个任务即使没有编辑同一文件，也可能分别改了调用方和被调用方；此时应让接口负责人先提交可审查的契约变更，其他 lane 以该提交为基线继续。这样，worktree 隔离解决的是物理写入冲突，而任务拆分解决的是语义冲突。
会话交接要交付证据，而不是摘要幻觉
长任务常常需要换模型或中断后续跑。CrewCode 支持持久会话和会话内切换 provider，并会生成 hand-off summary；它还有 delegated threads，用于让编码 Agent 在一个 turn 中驱动可持续查看的真实聊天会话。这些能力能减少人工复制粘贴，但交接是否可靠仍取决于交接内容。
建议在每次 hand-off 前要求当前执行者留下四类可验证信息：当前分支/worktree、已修改文件、已经运行且通过或失败的命令、仍未解决的假设。新 Agent 应先读取 diff 和测试输出，再继续工作，而不是把 summary 当成事实。若一个任务牵涉数据库迁移、外部 API 或生产凭据，审批应放在实际副作用发生前；Mission Control 的价值正是让操作者有机会在这里暂停，而不是替代权限设计。
插件与远程能力的边界
CrewCode 的本地插件从 ~/.crewcode/plugins/ 载入，可提供面板、动作、Git lens、终端 watcher、MCP server 声明及自定义 Agent provider。其 provider runtime 包括 mock、exec 与 http。这很适合连接本地 CLI 或内部 Agent 网关，但也意味着插件是新的信任边界：应审查 manifest、所需权限和 provider 启动命令，只为必要的 workspace 启用。
README 还说明，托管 provider 的密钥由 Electron 主进程保存，不进入 renderer 状态。这个设计不能替代操作系统账户隔离、最小权限 token 或仓库级 secrets 规则；尤其不要因为“本地优先”就把生产凭据交给所有 Agent lane。远程工作区和 SSH 连接同样应先限定目标主机、密钥用途和可执行命令。
适用场景与不适用场景
CrewCode 适合已经采用 Git、需要同时监督多个编码 Agent 的个人开发者、小团队和技术创始人：你希望把 worktree、终端、会话和 diff 放在同一处，同时仍保留提交与 PR 作为合并门槛。它不适合替代 CI、代码所有权、发布审批或密钥管理；也不应被当成“多个 Agent 可以安全写同一目录”的理由。
最有价值的实践并不复杂：一个任务对应一个 worktree；每个 Agent 的写入范围可说明；每次交接附带 diff 与命令证据；所有合并仍经过独立审查。这样，多 Agent 才从一堆同时闪烁的终端，变成可以停下、检查和撤回的工程流程。