用 Multica 和 Git worktree 实现多 Agent 并发开发

Qifei
网站编程

发布于：2026年9月3日
次浏览

过去使用 AI 编程时，我通常只开一个对话：让 Agent 阅读需求、修改代码、运行测试，再提交结果。这个方式适合小改动，但项目稍大以后，一个 Agent 很容易同时背负产品背景、前后端代码、测试结果和历史讨论，等待时间与上下文也会越来越长。

Multica 提供了另一种组织方式：把一个项目拆成多个 issue，让多个 Agent 分别处理可以独立推进的任务。它们共享同一个 GitHub 仓库，却在不同的 Git 分支和 worktree 中工作。这样既能并发开发，又不会让几个 Agent 同时修改同一份本地文件。

本文以我当前使用的“聪明的二休”开发流程为例，说明这套方法如何运行、冲突如何解决，以及为什么并发 Agent 会消耗更多 Token。

一：为什么不能让多个 Agent 共用一个目录

假设要同时完成三个任务：

  1. Agent A 修改登录接口；
  2. Agent B 开发登录页面；
  3. Agent C 补充端到端测试。

如果它们共用同一个本地仓库，A 尚未提交的文件会直接出现在 B 的 git status 中；B 切换分支时可能影响 A；C 运行格式化工具时还可能改写二者正在编辑的文件。此时很难判断一次提交到底属于谁，误删或覆盖其他任务修改的风险也很高。

Git worktree 正好解决了这个问题。一个 Git 仓库可以同时拥有多个工作目录，每个目录检出不同分支：

1
2
3
4
5
GitHub 仓库 origin/main
          |
          +-- issue-login-api 分支  -> worktree-A -> Agent A
          +-- issue-login-ui 分支   -> worktree-B -> Agent B
          +-- issue-login-e2e 分支  -> worktree-C -> Agent C

三个目录共享 Git 对象数据库，因此不像完整克隆三次那样浪费空间；但工作区、暂存区和分支彼此隔离。每个 Agent 可以独立编辑、测试和提交。

二：Multica 在并发开发中负责什么

worktree 只负责文件隔离，真正的协作还需要任务层面的约束。Multica 用项目、issue、Agent 和运行时把这几部分连接起来：

  1. 项目资源指定要操作的 GitHub 仓库；
  2. 一个父 issue 描述完整目标，再把可并行部分拆成子 issue；
  3. 每个 issue 分配给一个 Agent，并有独立的状态、评论和验收条件；
  4. Agent 从 issue 中读取需求，在专属分支和 worktree 中完成修改；
  5. 结果经过测试、rebase 和推送后，再通过 issue 评论交付。

这里最重要的原则是：并发单位不是“多开几个聊天窗口”，而是边界清楚、可以验收的 issue。 如果两个任务必然频繁修改同一组核心文件，强行并行通常只会把开发时间变成解决冲突的时间。

适合并发的任务包括前端与后端的独立模块、代码与文档、功能实现与测试基建等。存在严格依赖的任务则应该串行，例如必须先确定数据库结构，才能可靠开发其上的接口。

三：一个 Agent 的完整工作流程

3.1 先读任务，而不是直接改代码

Agent 首先读取 issue 正文、元数据和评论线程。issue 正文是初始需求，最新评论往往包含新的验收条件或人工决策，所以不能只看标题就动手。

明确任务后再把 issue 标记为进行中。这样看板反映的是项目真实状态，也能减少多个 Agent 重复领取同一任务的情况。

3.2 只以最新的 origin/main 为基线

我的流程把 origin/main 作为唯一集成基线。开始开发前先更新远端引用并确认它存在：

1
2
git fetch origin --prune
git rev-parse --verify origin/main

然后为当前任务创建唯一分支和独立 worktree：

1
2
git branch issue-34-multica-article origin/main
git worktree add ../worktrees/issue-34 issue-34-multica-article

实际使用 Multica 时，仓库检出命令可以自动创建任务专属的分支与工作目录。这里给出原生 Git 命令，是为了说明背后的机制。

每个 Agent 只能修改自己的 worktree，不能进入其他任务的目录，也不能复用其他 Agent 的分支。即使发现别的 worktree 里有未提交修改，也应把它当成别人的工作现场，不进行清理。

3.3 在分支中实现、测试和提交

Agent 在自己的目录中完成代码和文档修改，并运行与风险相称的测试。例如后端改动需要单元测试，构建配置改动至少需要完成一次构建。

提交前应检查差异，确认没有把缓存、密钥或无关格式化结果混入提交：

1
2
3
4
5
git status --short
git diff --check
git diff --stat
git add <本任务相关文件>
git commit -m "Add concurrent agent development guide"

一次提交只承载一个 issue 的目标，会让后续审查、回滚和冲突定位简单很多。

四：如何安全地集成到 main

多个 Agent 并发时，自己开始工作的那个 origin/main 很可能已经过时。因此测试通过并不代表可以直接推送，集成前必须再次同步：

1
2
git fetch origin --prune
git rebase origin/main

rebase 会把当前任务的提交重新放到最新主线之上。如果没有冲突，重新运行关键测试，然后使用普通的快进推送把任务提交送入主线：

1
git push origin HEAD:main

不应对 main 使用强制推送。若远端在推送前又有新提交，普通推送会被拒绝，这是正常的并发保护。此时重复“fetch、rebase、测试、普通推送”即可。

如果仓库开启了分支保护，Agent 不应绕过规则。正确做法是推送任务分支并创建指向 main 的 Pull Request，保留本地工作现场，等待人工审核或 CI。

五：并发冲突应该怎样解决

冲突本身不是异常，而是 Git 在提示：两个任务对同一位置的意图无法自动合并。解决冲突的关键不是尽快消除标记，而是同时理解主线和当前任务。

一次可靠的冲突处理通常包含以下步骤：

  1. 阅读 origin/main 上相关提交，理解另一位 Agent 为什么这样修改；
  2. 阅读当前 issue、自己的提交和测试，确认本任务必须保留的行为；
  3. 逐个文件处理冲突，组合双方仍然有效的逻辑；
  4. 搜索残留的 <<<<<<<、======= 和 >>>>>>> 标记；
  5. 继续 rebase，并重新运行测试与构建；
  6. 审查最终差异，确认没有悄悄丢掉任意一方的功能。

不要为了让 rebase 尽快结束，对所有文件统一选择 ours 或 theirs。例如 A 给接口新增鉴权，B 同时修改同一接口的返回结构，正确结果通常是“保留鉴权并采用新返回结构”，而不是二选一。

可以重新生成的锁文件、编译产物是少数例外，但也应该在确认输入正确后重新生成，并通过测试验证结果。

从源头减少冲突比事后解决更划算。拆 issue 时应尽量划清模块边界；共享接口先确定契约；数据库迁移、依赖锁文件和全局配置等高冲突文件，可以安排单独任务或串行处理。

六：多 Agent 为什么更消耗 Token

多 Agent 缩短的主要是墙上时间，不一定减少总工作量。每个 Agent 开始任务时，都需要重新理解一部分相同背景：

  • 阅读 issue、评论和仓库规范；
  • 浏览目录、依赖和相关代码；
  • 理解公共接口和主线最新变化；
  • 在 rebase 后重新检查差异和测试结果；
  • 向 issue 汇报过程与交付结果。

如果一个任务拆给四个 Agent，相同的项目背景可能被读取四次。并发越高，主线变化越频繁，各 Agent 用于同步、冲突分析和重复验证的 Token 也越多。拆分过细时，任务本身只需改十行代码，理解上下文和写交付说明反而占了大头。

因此，多 Agent 的收益可以粗略理解为：

1
并发收益 = 缩短的等待时间 - 协调成本 - 重复上下文成本 - 冲突返工成本

并不是 Agent 数量越多越好。当任务存在大量共享状态或强依赖时，单 Agent 连续完成可能更便宜，也更准确。

七：控制 Token 成本的实践

7.1 按边界拆分，不按文件数量拆分

一个好的子 issue 应该包含目标、范围、输入、输出和验收方式，让 Agent 不必读取整个项目来猜需求。不要简单地把“改三个文件”拆成三个任务，因为三个文件可能共同实现一个不可分割的行为。

7.2 让上下文分层

把长期稳定的规则放进仓库说明或 AGENTS.md，把项目目标放父 issue，把当前实现细节放子 issue。Agent 只读取与自己有关的模块、评论线程和测试，不要把全部历史对话复制给每一个任务。

交付评论也应记录结论：改了什么、测试结果、提交或 PR 在哪里、还需要谁做什么，而不是粘贴冗长的命令输出。

7.3 限制无意义的并发

并发数应由真正独立的任务数决定。两个任务共享大量文件时，宁可排成先后阶段；很小的修复可以合并给同一 Agent；纯等待 CI 也不需要占用一个持续轮询的 Agent。

7.4 尽早定义公共契约

前端和后端并行前，先约定 API 请求、响应、错误码和类型定义。多个模块共享数据结构时，先由一个任务落地契约，其余 Agent 基于同一个版本开发。清晰的契约可以同时减少代码冲突和反复沟通。

7.5 使用增量读取与定向测试

评论很多时，先扫描线程摘要，只展开相关线程；代码很多时，先搜索调用关系，再读取目标文件；测试时优先运行受影响模块，集成前再运行必要的完整构建。减少无关输入，比单纯要求 Agent “回答简短”更能节省 Token。

八：一套可复用的协作策略

我更推荐下面这个节奏：

  1. 由一个负责人明确总体目标和模块边界；
  2. 把真正独立的工作拆为少量、可验收的 issue；
  3. 每个 Agent 基于最新 origin/main 使用独立分支和 worktree；
  4. Agent 在本地完成实现、定向测试和提交；
  5. 集成前 fetch 并 rebase，逐项解决冲突；
  6. 测试通过后快进推送 main，受保护仓库则提交 PR；
  7. 只有确认提交已经进入 main，才清理本任务的分支和 worktree；
  8. 在 issue 中记录基线、分支、提交、测试、冲突和最终集成结果。

这套流程的价值，不只是让 AI “同时写更多代码”，而是把并发开发变成可追踪、可验证、可恢复的工程活动。Multica 负责组织任务和运行 Agent，Git worktree 负责隔离工作现场，分支、rebase、测试与 PR 则负责安全地汇合结果。

真正高效的多 Agent 开发，需要在速度、正确性和 Token 成本之间取得平衡：能独立的任务大胆并行，强依赖的任务老实串行；让每个 Agent 获得完成工作所需的最小充分上下文，同时为集成留下清晰记录。这样，多 Agent 才不是把混乱放大，而是在工程约束下把等待时间压缩下来。

相关文章
git使用记录BLOG双线部署+https

博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议

本文永久链接是：https://blog.sci.ci/2026/09/03/%E7%94%A8Multica%E5%92%8CGit-worktree%E5%AE%9E%E7%8E%B0%E5%A4%9AAgent%E5%B9%B6%E5%8F%91%E5%BC%80%E5%8F%91/

更新于：2026年9月3日

Git

Multica

AI Agent

Worktree

评论