--- title: "GitButler 并行 AI 智能体：多个分支，共享应用" canonical: https://wavect.io/zh/blog/gitbutler-parallel-ai-agents-one-workspace/ language: zh description: "用 GitButler 让并行 AI 编程智能体共享工作区。了解 CLI 选择性提交、共享构建测试、worktree 取舍，以及多人实时协同的现有边界。" image: "https://wavect.io/img/blog/headers/header_gitbutler-parallel-ai-agents-one-workspace.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 分钟 阅读 · 2026年10月8日 最近审核 2026年10月8日 [**下一篇**](/zh/blog/git-worktrees-vs-jujutsu-ai-coding-agents/) # GitButler 并行 AI 智能体：多个分支，一个运行中的应用 要点速览 GitButler 让多个 AI 编程智能体共享一个工作目录和开发服务器，同时在独立分支上组织各项任务的变更。提交时应明确选择变更，协调共享文件及影响整个工作区的操作，并同时测试各分支或已声明的分支栈与组合应用。远程分支协作已经可用；始终同步的多人上下文和已验证状态仍属于更广泛的愿景。应将 10 倍和 100 倍提速说法视为有待测量的假设。 **GitButler 让并行工作的 AI 编程智能体在同一个工作目录中，把各自的修改保存在独立分支上，使兼容的变更能够在同一个本地应用中一起运行。**其 [并行智能体文档](https://docs.gitbutler.com/ai-agents/parallel-agents) 明确介绍了共享依赖安装和开发服务器，同时分别提交各项任务变更的方式。 它的吸引力很直接：一个功能、一项无关的修复，以及另一个智能体的任务可以同时推进，而你能查看它们组合后的结果。智能体可以通过 CLI 处理版本控制操作，让开发者专注于确定方向和判断产品质量。 下一步机会是多人协同开发：多个人和多个智能体围绕持续更新的产品开展工作。难点在于，大家必须就“更新到最新”究竟指什么达成一致。当前文件、智能体掌握的当前信息，以及已经测试的集成状态，是三种不同的状态。 资料核查日期为 2026 年 10 月 8 日。以下命令依据当前官方文档编写，仅作示例，不是一次已执行的 GitButler 操作记录。建议的协作规则和验证矩阵属于 Wavect 的分析。“10x”提速和“100x”多人协作增益在文中作为体验说法和预测讨论，并非 Wavect 的实测结果。 ## GitButler 如何让多个分支在同一次构建中运行？ **GitButler 将已应用的分支组合到同一份检出文件中，同时保留各分支独立的历史。**其 [工作区分支文档](https://docs.gitbutler.com/workspace-branch) 解释了自动生成的 `gitbutler/workspace` 合并提交，以及普通 Git 工具所能看到的组合提交状态。 这并不意味着每个智能体都有独立的文件系统。它们看到的是相同的文件、依赖安装和生成产物。当客户筛选功能与一项无关的发票显示修复能够共存时，这很有用。如果两个智能体都要重写同一个共享类型，或生成同一个产物，就需要协调。 “同一个运行中的构建”指的是开发进程可以使用组合后的文件。它不保证每次文件更新都是原子的，也不保证热重载能处理所有修改，更不保证依赖或数据库状态变化永远不需要重启。我们的 [编程智能体多文件原子编辑指南](/zh/blog/atomic-multi-file-edits-ai-coding-agents/) 解释了多个文件发生变化时，正在运行的读取方可能看到什么。 在 GitButler 管理的工作区中，应使用它提供的写入操作。把 `gitbutler/workspace` 当成普通功能分支并直接向其提交，不符合工具所维护的组织方式。 ## AI 智能体何时应该共享 GitButler 工作区，何时应该使用 worktree？ **任务能够共享文件和运行时状态时，可以共享工作区；需要不兼容的检出状态或相互竞争的实现方案时，应使用独立 worktree。**Git 官方的 [worktree 文档](https://git-scm.com/docs/git-worktree) 介绍了多个工作树共享同一个仓库的方式，同时各自保留 `HEAD` 和索引等工作树专属状态。 | 任务场景 | 适合的起点 | 需要验证什么 | | --- | --- | --- | | 希望一起试用的独立功能 | 同一工作区中的 GitButler 并行分支 | 每个功能单独运行和在组合应用中都能正常工作 | | 两个智能体探索不同实现方案 | 独立 worktree | 分别评估方案，再集成选定的结果 | | 某个功能需要另一个分支的 API 变更 | 明确声明依赖的分支栈 | 基于声明的依赖进行审查和测试 | | 依赖版本不同，或生成文件不兼容 | 独立的检出目录和运行环境 | 依赖、构建产物和运行时是否分离 | | 需要提前审查同事分支的集成效果 | 协调后将其应用到共享工作区，或使用专门的审查 worktree | 预期的分支组合和当前目标分支 | Worktree 分离的是检出的文件。如果任务还需要隔离端口、数据库和外部资源，就必须另外配置。反过来，两个文件位于不同文件夹，也不能证明它们的修改彼此独立。共享数据结构、锁文件或迁移脚本都可能让任务产生依赖。 更广泛的仓库和环境准备决策，可参阅我们的 [面向 AI 编程智能体的 Git worktree 与 Jujutsu 对比指南](/zh/blog/git-worktrees-vs-jujutsu-ai-coding-agents/) 。本文讨论的选择更具体：你需要一个组合后的本地应用，还是需要将工作中的变更放在物理分离的目录里？ ## 智能体能不使用桌面应用，直接控制 GitButler 吗？ **可以。GitButler 文档提供了通过 `but` CLI 驱动的智能体工作流。**先阅读 [智能体设置指南](https://docs.gitbutler.com/ai-agents/getting-started) 。安装 CLI 后，在仓库目录中运行： ``` but agent setup but status ``` 向导可以安装技能、写入工作流指令，并在需要时初始化工作区模式。应审查它准备修改的范围和指令内容。技能教会智能体如何操作 GitButler；仓库权限与分支保护才负责限制访问能力。 接下来，就可以用自然语言描述目标。例如： > 在 `feature/customer-filter` 分支上实现客户筛选功能。将无关修复单独处理。修改共享文件前，与另一个智能体协调。只提交本任务的变更，并报告分支基线和已经执行的检查。 这是一条建议的任务提示，不是特殊命令。智能体应把它转换为合适的操作。人工检查时，GitButler 的 [智能体工作审查流程](https://docs.gitbutler.com/ai-agents/review-agent-work) 支持 CLI、TUI 和桌面视图。 **最容易犯的错误，是把另一个智能体的工作一起提交。**当前 [`but commit` 命令参考](https://docs.gitbutler.com/commands/but-commit) 说明，默认行为会包含所有未提交变更。仅指定目标分支，并不意味着只选择该任务的修改。应通过位置参数中的变更 ID，明确选择所需文件或差异块。 下面的 ID 仅作示例。请用你当前命令输出中的 ID 替换 `q3`、`w7` 和 `n2`，并在继续操作前检查每项选择。GitButler 的 [CLI ID 文档](https://docs.gitbutler.com/commands/but-help-cli-ids) 提醒，标识符可能随着工作区上下文变化而改变。 ``` but diff but commit -b feature/customer-filter -m "Add customer filter" q3 w7 but diff but commit -b fix/invoice-display -m "Fix invoice display" n2 but status ``` 这遵循了 [分支与提交教程](https://docs.gitbutler.com/cli-guides/cli-tutorial/branching-and-commiting) 中的选择性提交方式。如果指定的目标分支不存在，`-b` 会将其创建为并行分支。如果它已经存在但尚未应用，提交命令会拒绝该目标。应协调选择与写入操作，避免另一个写入方让你刚刚核查的内容失效。 ## 多个智能体如何避免覆盖或混入彼此的修改？ **分配分支之外，还需要明确共享文件的修改责任。**为每项任务指定分支和工作范围。提前列出常见冲突点：路由表、共享类型、依赖清单、锁文件、迁移脚本和生成代码。 假设两个智能体在任何修改发生前，都读取了同一个文件。第二个智能体随后如果基于过期内容整体替换文件，就可能删除第一个智能体的修改，此时甚至还没有两份已保留的提交可供合并。分支标签不会让这种文件系统操作自动获得独占权。 我们建议让独立实现继续并行进行，同时指定一名协调智能体或开发者，负责会整体改变共享工作区的操作。应用或移除分支、更新目标分支、整理历史，以及进入冲突解决模式，都需要协调。这类协调也可以由智能体完成，不必把每个常规决策都交回给人。 编辑共享文件前，重新读取相关内容，并约定由谁负责修改。提交前，检查实际选中的差异。如果同伴修改了你的任务所依赖的接口，就应更新原有假设，并重新执行受影响的检查。这些是工作流建议，不代表 GitButler 会强制执行文件所有权规则，或自动刷新每个智能体的上下文。 ## 为什么共享构建通过了，单个分支仍可能有问题？ **组合构建成功，只能验证你实际运行的那个组合，不能证明每个分支都能独立工作。**这就是 [文档所述隐性依赖风险](#source-parallel) 在实践中的表现。 设想一个例子：分支 A 在 API 响应中增加预计交付时间；分支 B 增加一个读取该字段的徽标。两个分支都应用时，功能正常。如果 B 的审查和发布基于一个尚未包含 A 的目标分支，即使没有任何文本行冲突，徽标仍然可能出错。 如果这个依赖是有意设计的，就应明确声明。当前 [`but branch` 命令参考](https://docs.gitbutler.com/commands/but-branch) 介绍了通过 `but branch new delivery-badge --above delivery-api` 创建依赖分支的方法。如果 B 原本应该独立，就需要消除意外依赖，或调整交付计划。 | 验证对象 | 要回答的问题 | 需要保留的证据 | | --- | --- | --- | | 单个分支或已声明的分支栈 | 这个审查单元仅依赖已声明的前置变更时，能否正常工作？ | 基线、分支版本和相关检查结果 | | 组合后的本地工作区 | 同时开发的功能能否一起工作？ | 已应用分支的版本、任何未提交修改，以及运行环境假设 | | 最终集成候选版本 | 这个确切的候选版本在当前目标分支上能否正常工作？ | 集成版本及针对该候选版本执行的检查 | 应在合适的检出目录或 CI 环境中，对分支或分支栈进行隔离检查。如果其他智能体仍在编辑共享工作区，却不断从中移除分支，反而可能产生新的干扰。 GitHub 的 [合并队列文档](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue) 体现了最后一种区别：必需检查针对最新目标分支与排队变更的集成结果运行。队列执行的是已配置的检查，不能证明那些检查从未覆盖的行为正确。 准确记录测试对象。如果智能体在测试期间继续修改文件，结果就可能覆盖一组混合状态。做出批准决定时，应使用稳定的候选版本；相关输入变化后，再重新验证。共享预览仍然可以提供快速反馈，同时审查证据应绑定到可复现的状态。 ## 审查他人的分支时出现冲突，应该怎么办？ **先区分能否合入目标分支，以及能否与当前工作区兼容。** [`but branch list` 和 `but branch show BRANCH --check`](#source-branch) 所描述的检查针对上游目标分支。能够合入该目标的分支，仍可能与本地已经应用的其他修改冲突。 开展可能扰动当前工作的审查前，应先约定分支组合并记录恢复点。 [操作日志命令参考](https://docs.gitbutler.com/commands/but-oplog) 介绍了 `but oplog snapshot -m "Before branch review"`。必要时，还应另外记录应用状态；版本控制检查点不是数据库备份。 [冲突解决 CLI](https://docs.gitbutler.com/commands/but-resolve) 支持通过 `--ai` 采用 AI 辅助路径。文档还介绍了 `but resolve conflicts` 和 `but resolve apply`，可用于处理存在冲突的提交，而不进入冲突解决模式。 传统交互式路径的影响有所不同。 [变基与冲突指南](https://docs.gitbutler.com/features/branch-management/merging) 说明，这条路径会暂时用存在冲突的提交替换组合后的检出内容。应考虑其他写入方和正在运行的应用，协调这一变化。不要假设所有冲突解决路径对工作区的影响都相同。 智能体可能很快就能解决简单的文本冲突，但“不到一分钟”的说法，不能证明结果保留了两项任务各自的意图。应审查变更后的接口、行为和生成产物，再执行相关的单独检查与集成检查。解决冲突的时间和验证结果的时间，是工作流中的两个独立部分。 ## GitButler 已经支持多人实时协同工作流了吗？ **GitButler 已经支持通过远程分支开展协作，但本次核查的文档并未确认，所有参与者的未提交修改都能在一个始终同步的工作区中共享。** [Butler Flow](https://docs.gitbutler.com/butler-flow) 介绍了如何将同事的远程分支与本地工作一起应用，提前检查集成效果，其中也包括并非通过 GitButler 创建的分支。 [`but pull` 命令参考](https://docs.gitbutler.com/commands/but-pull) 介绍了一项显式更新操作：获取远程变更，并将所有已应用分支变基到更新后的目标分支。`but pull --check` 可以预览更新。由于它可能影响共享工作状态，执行时应与正在工作的智能体协调。 多人协同是一个可信的发展方向。在 [A 轮融资公告](https://blog.gitbutler.com/series-a) 中，GitButler 描绘了这样的未来：更早发现与同事的冲突，在持续变化的分支上继续开发，并让智能体理解团队正在开展的工作。这是公开的产品愿景，并非对团队所期待的每一种同步行为作出发布承诺。 我们的判断是，下一个实质性进步将来自缩短这段距离：从同事完成一项有用变更，到其他人理解该变更并作出相应调整。共享代码只是其中一部分。共享哪个版本已通过审查、哪些内容仍属探索，以及为什么作出某个决定，同样不可缺少。 关于通过共享会话和组织上下文协作，可参阅我们的 [Mosaic 共享智能体会话分析](/zh/blog/mosaic-yc-s26-shared-agent-sessions-review/) 。同步对话和同步产品状态回答的是不同问题。 ## “所有人都处于最新状态”究竟需要什么？ **有用的多人协同系统，需要区分当前文件、当前智能体上下文，以及当前已经验证的分支组合。**这是我们建议用来评估这一理念的方法，不是对 GitButler 现有功能的描述。 | 含义 | 必须共享什么 | 混淆后可能发生的故障 | | --- | --- | --- | | 最新文件 | 变更、修改责任，以及哪些分支应该纳入工作区 | 智能体覆盖同伴的修改，或看到非预期的分支组合 | | 最新上下文 | 相关接口变更、决策和已经失效的假设 | 智能体读取当前文件，却仍按过期契约推理 | | 最新的已验证组合 | 固定候选版本、它的依赖，以及适用于它的检查 | 把之前通过的检查结果，当成对另一种状态的批准 | 自动同步应允许团队保留稳定的审查候选版本，同时在其他地方继续开发。审查者需要知道自己批准的是哪个版本；排查故障的开发者需要能够复现问题；同事应该可以拒绝加入一个探索性分支，同时继续访问已接受的工作。 依赖关系也必须随变更一同传递。如果 UI 分支依赖 API 分支，团队就应该在单独批准任一分支前看到这个关系。同伴修改 API 时，受影响的智能体需要知道为什么必须重新读取它，而不只是收到“某些文件发生了变化”的通知。 这才是“100x”愿景中有实质内容的目标：减少整个团队的协调等待，同时保持变更可理解、可测试。具体倍数和实现时间仍然只是预测。更多人或智能体同时编辑，本身不能证明会带来这样的提升。 ## 团队应该如何验证开发提速的说法？ **从一组规模小且有代表性的任务开始，衡量已被接受的工作和协调投入。**尝试同时处理一个功能和一项独立修复。检查各个审查单元，让它们一起运行，再基于当前目标分支集成。随后用团队现有流程重复实验；如果独立 worktree 是合理备选，也应纳入比较。 使用可比任务，并记录任务复杂度、智能体与模型配置，以及审查者是否有空处理。跟踪从开始到变更可审查且已测试所需的时间、每项已接受变更消耗的审查分钟数、集成返工，以及只有在独立测试分支时才发现的故障。重试和修复产生的模型与基础设施成本也要计算。 个人报告的“10x”体验可以成为尝试的理由，却不能决定另一支团队会得到什么结果。改善可能来自环境准备步骤减少、上下文切换减少、组合反馈更快，或人工版本控制操作减少。在把全部收益归因于一个工具之前，应先确定实际改变的是哪些环节。 Wavect 的 [AI 赋能服务](/zh/services/ai-enablement/) 可以帮助团队制定协作规则，并根据交付结果评估效果。我们的 [Hyperstate AI 工程案例](/zh/case-studies/hyperstate-ai/) 属于另一项独立产品合作，不能作为 GitButler 部署或提速基准的证据。 使用 [上线前软件 QA 检查清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 明确验收标准，或 [讨论团队的并行智能体开发流程](/zh/contact/) 。请准备两项有代表性的任务、一次近期集成故障，以及目前采用的审查流程。 ## GitButler 与并行 AI 智能体常见问题 ### 多个 AI 智能体能在同一个工作目录中使用 GitButler 吗？ 可以。GitButler 文档介绍了并行智能体会话共享工作区，同时把各项任务的变更提交到独立分支的方式。它们仍然共享文件、生成产物和运行时状态，因此重叠的工作需要协调。 ### 必须使用 GitButler 桌面应用吗？ 文档中的智能体工作流使用 but CLI。安装 CLI 后，but agent setup 可以安装技能并配置仓库指令。人工检查可以通过 CLI、TUI 或桌面应用进行。 ### GitButler 能替代 AI 智能体使用的 Git worktree 吗？ 它提供了一种共享工作区的替代方案。如果任务彼此兼容，而且希望一起运行，可以使用并行分支。如果任务需要不兼容的检出状态、相互竞争的实现方案，或分别配置的运行环境，应使用独立 worktree。 ### 共享构建通过，能证明每个分支都可以发布吗？ 不能。某个分支可能依赖另一个已应用分支，而后者并不会随它一起发布。既要基于已声明的基线和依赖测试每个审查单元，也要测试组合工作区和最终集成候选版本。 ### GitButler 能防止智能体互相覆盖修改吗？ 不要把分支分配当成文件锁。智能体共享同一个文件系统。应协调重叠编辑和影响整个工作区的操作，重新读取已过期的内容，并在提交前检查选中的差异。 ### GitButler 已经提供始终同步的多人协同模式了吗？ 截至 2026 年 10 月 8 日核查的文档，支持的是远程分支协作和本地并行工作，并未确认能实时、全面地同步所有参与者的未提交文件、智能体上下文和已验证的运行状态。 ### GitButler 真能让开发速度提升 10 倍吗？ 本文没有建立 10 倍提速的基准。个人提速报告和 100 倍多人协作预测，都应通过可比任务、产出已测试变更所需的时间、审查投入、返工，以及每项已接受变更的总成本来评估。 ## 最终思考 GitButler 让一种很有吸引力的工作流成为可能：多个智能体、可以分别审查的分支，以及一个能同时展示兼容变更的应用。应为智能体明确修改责任，选择需要提交的变更，并验证真正打算发布的审查单元。下一步多人协同的进展，将取决于能否在共享当前文件的同时，也共享当前决策和已经验证的分支组合。 架构与平台 ## 继续浏览此集群 对长期交付产生影响的框架、平台与系统设计选择。 [从核心文章开始**智慧城市软件架构：MQTT、LoRaWAN、Kubernetes 与 Terraform**](/zh/blog/smart-city-architecture-best-practices-2026/) - [AI 编程时代的软件护城河：谁来维护你构建的系统？](/zh/blog/ai-coding-software-moat-operations/) - [Shopify B2B 订单审批：原生功能、应用还是定制买方门户？](/zh/blog/shopify-b2b-order-approval-workflow/) - [Shopify–ERP 退货与退款：标准连接器何时不够用？](/zh/blog/shopify-erp-returns-refunds-integration/) - [ERP 没有 API，如何集成？文件交换、数据库读取、RPA 还是替换系统](/zh/blog/legacy-erp-integration-without-api/) - [管理多个 Shopify 店铺：报表应用还是定制运营看板？](/zh/blog/shopify-multi-store-operations-dashboard/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 分钟 阅读 · 2026年10月8日 最近审核 2026年10月8日 [**下一篇**](/zh/blog/git-worktrees-vs-jujutsu-ai-coding-agents/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/gitbutler-parallel-ai-agents-one-workspace/#webpage", "@type": "WebPage", "dateModified": "2026-10-08", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-10-08", "url": "https://wavect.io/zh/blog/gitbutler-parallel-ai-agents-one-workspace/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "GitButler 让多个 AI 编程智能体共享一个工作目录和开发服务器，同时在独立分支上组织各项任务的变更。提交时应明确选择变更，协调共享文件及影响整个工作区的操作，并同时测试各分支或已声明的分支栈与组合应用。远程分支协作已经可用；始终同步的多人上下文和已验证状态仍属于更广泛的愿景。应将 10 倍和 100 倍提速说法视为有待测量的假设。", "articleBody": " 博客概览/交付与 QA/架构与平台 GitButler 并行 AI 智能体：多个分支，一个运行中的应用 要点速览 GitButler 让多个 AI 编程智能体共享一个工作目录和开发服务器，同时在独立分支上组织各项任务的变更。提交时应明确选择变更，协调共享文件及影响整个工作区的操作，并同时测试各分支或已声明的分支栈与组合应用。远程分支协作已经可用；始终同步的多人上下文和已验证状态仍属于更广泛的愿景。应将 10 倍和 100 倍提速说法视为有待测量的假设。 GitButler 让并行工作的 AI 编程智能体在同一个工作目录中，把各自的修改保存在独立分支上，使兼容的变更能够在同一个本地应用中一起运行。其并行智能体文档明确介绍了共享依赖安装和开发服务器，同时分别提交各项任务变更的方式。 它的吸引力很直接：一个功能、一项无关的修复，以及另一个智能体的任务可以同时推进，而你能查看它们组合后的结果。智能体可以通过 CLI 处理版本控制操作，让开发者专注于确定方向和判断产品质量。 下一步机会是多人协同开发：多个人和多个智能体围绕持续更新的产品开展工作。难点在于，大家必须就“更新到最新”究竟指什么达成一致。当前文件、智能体掌握的当前信息，以及已经测试的集成状态，是三种不同的状态。 资料核查日期为 2026 年 10 月 8 日。以下命令依据当前官方文档编写，仅作示例，不是一次已执行的 GitButler 操作记录。建议的协作规则和验证矩阵属于 Wavect 的分析。“10x”提速和“100x”多人协作增益在文中作为体验说法和预测讨论，并非 Wavect 的实测结果。 GitButler 如何让多个分支在同一次构建中运行？ GitButler 将已应用的分支组合到同一份检出文件中，同时保留各分支独立的历史。其工作区分支文档解释了自动生成的 gitbutler/workspace 合并提交，以及普通 Git 工具所能看到的组合提交状态。 这并不意味着每个智能体都有独立的文件系统。它们看到的是相同的文件、依赖安装和生成产物。当客户筛选功能与一项无关的发票显示修复能够共存时，这很有用。如果两个智能体都要重写同一个共享类型，或生成同一个产物，就需要协调。 “同一个运行中的构建”指的是开发进程可以使用组合后的文件。它不保证每次文件更新都是原子的，也不保证热重载能处理所有修改，更不保证依赖或数据库状态变化永远不需要重启。我们的编程智能体多文件原子编辑指南解释了多个文件发生变化时，正在运行的读取方可能看到什么。 在 GitButler 管理的工作区中，应使用它提供的写入操作。把 gitbutler/workspace 当成普通功能分支并直接向其提交，不符合工具所维护的组织方式。 AI 智能体何时应该共享 GitButler 工作区，何时应该使用 worktree？ 任务能够共享文件和运行时状态时，可以共享工作区；需要不兼容的检出状态或相互竞争的实现方案时，应使用独立 worktree。Git 官方的 worktree 文档介绍了多个工作树共享同一个仓库的方式，同时各自保留 HEAD 和索引等工作树专属状态。 根据任务之间的干扰程度选择起点 任务场景适合的起点需要验证什么 希望一起试用的独立功能同一工作区中的 GitButler 并行分支每个功能单独运行和在组合应用中都能正常工作 两个智能体探索不同实现方案独立 worktree分别评估方案，再集成选定的结果 某个功能需要另一个分支的 API 变更明确声明依赖的分支栈基于声明的依赖进行审查和测试 依赖版本不同，或生成文件不兼容独立的检出目录和运行环境依赖、构建产物和运行时是否分离 需要提前审查同事分支的集成效果协调后将其应用到共享工作区，或使用专门的审查 worktree预期的分支组合和当前目标分支 Worktree 分离的是检出的文件。如果任务还需要隔离端口、数据库和外部资源，就必须另外配置。反过来，两个文件位于不同文件夹，也不能证明它们的修改彼此独立。共享数据结构、锁文件或迁移脚本都可能让任务产生依赖。 更广泛的仓库和环境准备决策，可参阅我们的面向 AI 编程智能体的 Git worktree 与 Jujutsu 对比指南。本文讨论的选择更具体：你需要一个组合后的本地应用，还是需要将工作中的变更放在物理分离的目录里？ 智能体能不使用桌面应用，直接控制 GitButler 吗？ 可以。GitButler 文档提供了通过 but CLI 驱动的智能体工作流。先阅读智能体设置指南。安装 CLI 后，在仓库目录中运行： but agent setup but status 向导可以安装技能、写入工作流指令，并在需要时初始化工作区模式。应审查它准备修改的范围和指令内容。技能教会智能体如何操作 GitButler；仓库权限与分支保护才负责限制访问能力。 接下来，就可以用自然语言描述目标。例如： 在 feature/customer-filter 分支上实现客户筛选功能。将无关修复单独处理。修改共享文件前，与另一个智能体协调。只提交本任务的变更，并报告分支基线和已经执行的检查。 这是一条建议的任务提示，不是特殊命令。智能体应把它转换为合适的操作。人工检查时，GitButler 的智能体工作审查流程支持 CLI、TUI 和桌面视图。 最容易犯的错误，是把另一个智能体的工作一起提交。当前 but commit 命令参考说明，默认行为会包含所有未提交变更。仅指定目标分支，并不意味着只选择该任务的修改。应通过位置参数中的变更 ID，明确选择所需文件或差异块。 下面的 ID 仅作示例。请用你当前命令输出中的 ID 替换 q3、w7 和 n2，并在继续操作前检查每项选择。GitButler 的 CLI ID 文档提醒，标识符可能随着工作区上下文变化而改变。 but diff but commit -b feature/customer-filter -m \"Add customer filter\" q3 w7 but diff but commit -b fix/invoice-display -m \"Fix invoice display\" n2 but status 这遵循了分支与提交教程中的选择性提交方式。如果指定的目标分支不存在，-b 会将其创建为并行分支。如果它已经存在但尚未应用，提交命令会拒绝该目标。应协调选择与写入操作，避免另一个写入方让你刚刚核查的内容失效。 多个智能体如何避免覆盖或混入彼此的修改？ 分配分支之外，还需要明确共享文件的修改责任。为每项任务指定分支和工作范围。提前列出常见冲突点：路由表、共享类型、依赖清单、锁文件、迁移脚本和生成代码。 假设两个智能体在任何修改发生前，都读取了同一个文件。第二个智能体随后如果基于过期内容整体替换文件，就可能删除第一个智能体的修改，此时甚至还没有两份已保留的提交可供合并。分支标签不会让这种文件系统操作自动获得独占权。 我们建议让独立实现继续并行进行，同时指定一名协调智能体或开发者，负责会整体改变共享工作区的操作。应用或移除分支、更新目标分支、整理历史，以及进入冲突解决模式，都需要协调。这类协调也可以由智能体完成，不必把每个常规决策都交回给人。 编辑共享文件前，重新读取相关内容，并约定由谁负责修改。提交前，检查实际选中的差异。如果同伴修改了你的任务所依赖的接口，就应更新原有假设，并重新执行受影响的检查。这些是工作流建议，不代表 GitButler 会强制执行文件所有权规则，或自动刷新每个智能体的上下文。 为什么共享构建通过了，单个分支仍可能有问题？ 组合构建成功，只能验证你实际运行的那个组合，不能证明每个分支都能独立工作。这就是文档所述隐性依赖风险在实践中的表现。 设想一个例子：分支 A 在 API 响应中增加预计交付时间；分支 B 增加一个读取该字段的徽标。两个分支都应用时，功能正常。如果 B 的审查和发布基于一个尚未包含 A 的目标分支，即使没有任何文本行冲突，徽标仍然可能出错。 如果这个依赖是有意设计的，就应明确声明。当前 but branch 命令参考介绍了通过 but branch new delivery-badge --above delivery-api 创建依赖分支的方法。如果 B 原本应该独立，就需要消除意外依赖，或调整交付计划。 并行开发中三个不同的验证对象 验证对象要回答的问题需要保留的证据 单个分支或已声明的分支栈这个审查单元仅依赖已声明的前置变更时，能否正常工作？基线、分支版本和相关检查结果 组合后的本地工作区同时开发的功能能否一起工作？已应用分支的版本、任何未提交修改，以及运行环境假设 最终集成候选版本这个确切的候选版本在当前目标分支上能否正常工作？集成版本及针对该候选版本执行的检查 应在合适的检出目录或 CI 环境中，对分支或分支栈进行隔离检查。如果其他智能体仍在编辑共享工作区，却不断从中移除分支，反而可能产生新的干扰。 GitHub 的合并队列文档体现了最后一种区别：必需检查针对最新目标分支与排队变更的集成结果运行。队列执行的是已配置的检查，不能证明那些检查从未覆盖的行为正确。 准确记录测试对象。如果智能体在测试期间继续修改文件，结果就可能覆盖一组混合状态。做出批准决定时，应使用稳定的候选版本；相关输入变化后，再重新验证。共享预览仍然可以提供快速反馈，同时审查证据应绑定到可复现的状态。 审查他人的分支时出现冲突，应该怎么办？ 先区分能否合入目标分支，以及能否与当前工作区兼容。but branch list 和 but branch show BRANCH --check所描述的检查针对上游目标分支。能够合入该目标的分支，仍可能与本地已经应用的其他修改冲突。 开展可能扰动当前工作的审查前，应先约定分支组合并记录恢复点。操作日志命令参考介绍了 but oplog snapshot -m \"Before branch review\"。必要时，还应另外记录应用状态；版本控制检查点不是数据库备份。 冲突解决 CLI支持通过 --ai 采用 AI 辅助路径。文档还介绍了 but resolve conflicts 和 but resolve apply，可用于处理存在冲突的提交，而不进入冲突解决模式。 传统交互式路径的影响有所不同。变基与冲突指南说明，这条路径会暂时用存在冲突的提交替换组合后的检出内容。应考虑其他写入方和正在运行的应用，协调这一变化。不要假设所有冲突解决路径对工作区的影响都相同。 智能体可能很快就能解决简单的文本冲突，但“不到一分钟”的说法，不能证明结果保留了两项任务各自的意图。应审查变更后的接口、行为和生成产物，再执行相关的单独检查与集成检查。解决冲突的时间和验证结果的时间，是工作流中的两个独立部分。 GitButler 已经支持多人实时协同工作流了吗？ GitButler 已经支持通过远程分支开展协作，但本次核查的文档并未确认，所有参与者的未提交修改都能在一个始终同步的工作区中共享。Butler Flow介绍了如何将同事的远程分支与本地工作一起应用，提前检查集成效果，其中也包括并非通过 GitButler 创建的分支。 but pull 命令参考介绍了一项显式更新操作：获取远程变更，并将所有已应用分支变基到更新后的目标分支。but pull --check 可以预览更新。由于它可能影响共享工作状态，执行时应与正在工作的智能体协调。 多人协同是一个可信的发展方向。在 A 轮融资公告中，GitButler 描绘了这样的未来：更早发现与同事的冲突，在持续变化的分支上继续开发，并让智能体理解团队正在开展的工作。这是公开的产品愿景，并非对团队所期待的每一种同步行为作出发布承诺。 我们的判断是，下一个实质性进步将来自缩短这段距离：从同事完成一项有用变更，到其他人理解该变更并作出相应调整。共享代码只是其中一部分。共享哪个版本已通过审查、哪些内容仍属探索，以及为什么作出某个决定，同样不可缺少。 关于通过共享会话和组织上下文协作，可参", "articleSection": "AI 工程", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "并行智能体文档", "url": "https://docs.gitbutler.com/ai-agents/parallel-agents" }, { "@type": "WebPage", "name": "工作区分支文档", "url": "https://docs.gitbutler.com/workspace-branch" }, { "@type": "WebPage", "name": "worktree 文档", "url": "https://git-scm.com/docs/git-worktree" }, { "@type": "WebPage", "name": "智能体设置指南", "url": "https://docs.gitbutler.com/ai-agents/getting-started" }, { "@type": "WebPage", "name": "智能体工作审查流程", "url": "https://docs.gitbutler.com/ai-agents/review-agent-work" }, { "@type": "WebPage", "name": "but commit 命令参考", "url": "https://docs.gitbutler.com/commands/but-commit" }, { "@type": "WebPage", "name": "CLI ID 文档", "url": "https://docs.gitbutler.com/commands/but-help-cli-ids" }, { "@type": "WebPage", "name": "分支与提交教程", "url": "https://docs.gitbutler.com/cli-guides/cli-tutorial/branching-and-commiting" }, { "@type": "WebPage", "name": "but branch 命令参考", "url": "https://docs.gitbutler.com/commands/but-branch" }, { "@type": "WebPage", "name": "合并队列文档", "url": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue" }, { "@type": "WebPage", "name": "操作日志命令参考", "url": "https://docs.gitbutler.com/commands/but-oplog" }, { "@type": "WebPage", "name": "冲突解决 CLI", "url": "https://docs.gitbutler.com/commands/but-resolve" }, { "@type": "WebPage", "name": "变基与冲突指南", "url": "https://docs.gitbutler.com/features/branch-management/merging" }, { "@type": "WebPage", "name": "Butler Flow", "url": "https://docs.gitbutler.com/butler-flow" }, { "@type": "WebPage", "name": "but pull 命令参考", "url": "https://docs.gitbutler.com/commands/but-pull" }, { "@type": "WebPage", "name": "A 轮融资公告", "url": "https://blog.gitbutler.com/series-a" } ], "dateModified": "2026-10-08", "datePublished": "2026-10-08", "description": "GitButler 让多个 AI 编程智能体共享一个工作目录和开发服务器，同时在独立分支上组织各项任务的变更。提交时应明确选择变更，协调共享文件及影响整个工作区的操作，并同时测试各分支或已声明的分支栈与组合应用。远程分支协作已经可用；始终同步的多人上下文和已验证状态仍属于更广泛的愿景。应将 10 倍和 100 倍提速说法视为有待测量的假设。", "headline": "GitButler 并行 AI 智能体：多个分支，一个运行中的应用", "image": "https://wavect.io/img/blog/headers/header_gitbutler-parallel-ai-agents-one-workspace.svg", "inLanguage": "zh", "keywords": "AI 编程智能体, GitButler, 并行开发", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/gitbutler-parallel-ai-agents-one-workspace/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/gitbutler-parallel-ai-agents-one-workspace/", "wordCount": 411 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/delivery-qa/", "name": "交付与 QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/architecture-platforms/", "name": "架构与平台", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/gitbutler-parallel-ai-agents-one-workspace/", "name": "GitButler 并行 AI 智能体：多个分支，共享应用", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "可以。GitButler 文档介绍了并行智能体会话共享工作区，同时把各项任务的变更提交到独立分支的方式。它们仍然共享文件、生成产物和运行时状态，因此重叠的工作需要协调。" }, "name": "多个 AI 智能体能在同一个工作目录中使用 GitButler 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "文档中的智能体工作流使用 but CLI。安装 CLI 后，but agent setup 可以安装技能并配置仓库指令。人工检查可以通过 CLI、TUI 或桌面应用进行。" }, "name": "必须使用 GitButler 桌面应用吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "它提供了一种共享工作区的替代方案。如果任务彼此兼容，而且希望一起运行，可以使用并行分支。如果任务需要不兼容的检出状态、相互竞争的实现方案，或分别配置的运行环境，应使用独立 worktree。" }, "name": "GitButler 能替代 AI 智能体使用的 Git worktree 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不能。某个分支可能依赖另一个已应用分支，而后者并不会随它一起发布。既要基于已声明的基线和依赖测试每个审查单元，也要测试组合工作区和最终集成候选版本。" }, "name": "共享构建通过，能证明每个分支都可以发布吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不要把分支分配当成文件锁。智能体共享同一个文件系统。应协调重叠编辑和影响整个工作区的操作，重新读取已过期的内容，并在提交前检查选中的差异。" }, "name": "GitButler 能防止智能体互相覆盖修改吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "截至 2026 年 10 月 8 日核查的文档，支持的是远程分支协作和本地并行工作，并未确认能实时、全面地同步所有参与者的未提交文件、智能体上下文和已验证的运行状态。" }, "name": "GitButler 已经提供始终同步的多人协同模式了吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "本文没有建立 10 倍提速的基准。个人提速报告和 100 倍多人协作预测，都应通过可比任务、产出已测试变更所需的时间、审查投入、返工，以及每项已接受变更的总成本来评估。" }, "name": "GitButler 真能让开发速度提升 10 倍吗？" } ] } ```