如何用 git worktree 隔离让多个 Archon 工作流并行运行互不冲突【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon你在同一个仓库里同时派发了多个 Archon 工作流比如一个修 issue #42一个做 issue #43两个任务都会改到auth.ts这类同一批文件——没有隔离时它们共享同一份 checkout中途互相踩文件Archon 也无法分辨哪些改动属于哪个任务。Archon 的 isolation 系统解决的就是这个问题每个工作流运行在自己的 git worktree一个与主仓库共享 Git 历史和对象、但目录独立的检出里运行时你的主工作目录不受影响跑完之后通过 PR 审查不满意直接关掉 PR 即可。本文覆盖如何按隔离模式启动并行的工作流、如何确认多个 worktree 正在独立运行、子工作流并发写入时如何避免路径锁冲突以及运行结束后的清理方式。前置条件archon命令已安装可用源码检出场景下可用bun link后直接使用archon跳过则用bun run cli且你的目标是一个 git 仓库——workflow 和 isolation 命令通常要求从 git 仓库内执行在子目录中执行会自动解析到仓库根目录。先理解 worktree 落在哪里、隔离是不是默认行为worktree 不是 clone它和主仓库共享 Git 历史、对象与 remote相当于同一代码库在另一个分支上的第二个工作目录。Archon 为工作流运行创建的 worktree 固定落在这里~/.archon/workspaces/ └── owner/repo/ └── worktrees/ ├── fix/issue-42/ - 任务 A 的工作区 └── feat/dark-mode/ - 任务 B 的工作区每个 worktree 都是完整可用的检出AI 可以在里面读文件、跑测试、改代码、提交。任务完成创建 PR 后该分支被推送到 GitHub随后就可以安全清理。workflow run的隔离行为由标志决定默认就是隔离# 不传标志自动生成分支名在隔离 worktree 中运行 archon workflow run archon-fix-github-issue --cwd /path/to/repo Fix issue #42 # 显式指定分支名在该分支的隔离 worktree 中运行 archon workflow run archon-fix-github-issue --cwd /path/to/repo --branch fix/issue-42 Fix issue #42 # 关闭隔离直接在当前目录运行 archon workflow run assist --cwd /path/to/repo --no-worktree 解释一下这里的错误处理--branch name指定 worktree 的分支名如果该分支已有健康的 worktreeArchon 会直接复用而不是新建。--no-worktree直接在目标目录运行不创建隔离。文档建议只用于不修改代码的任务提问、探索、archon-assist它会与--branch、--from、--base互斥。文档建议凡是会改代码的工作流都带上描述性的--branch如fix/login-crash便于日后识别 worktree并在 GitHub 上产生干净的分支名。并行运行多个工作流时的关键规则让多个工作流并行互不冲突主路径就是给每个任务不同的分支名让它们各自进各自的工作区。每个分支名恰好映射到一个 worktree。不要同时对同一个分支启动两次工作流——第二个会与第一个冲突这是文档明确列出的使用限制。每个 worktree 都是独立目录、独立分支任务之间互相看不到对方的进行中改动主仓库在运行期间不被触碰。这正是让 Archon 跑整晚的安全依据一个耗时一小时、产生几十个改动的任务全程在隔离中进行结果以 PR 形式交付。验证确认并行 worktree 都在独立运行archon isolation list archon workflow statusarchon isolation list按 codebase 分组列出所有活跃的 worktree 环境分支名、路径、工作流类型、平台、距上次活跃的天数。并行任务应各自出现在列表中、对应不同的分支与目录。archon workflow status显示当前项目的活跃运行running 与 paused项目解析时会经过已注册的 checkout包括链接的 git worktree加--all可看整个安装范围加--verbose附加每个运行的逐节点摘要。可选分支子工作流并发写仓库时的隔离如果你不是并行启动多个顶层工作流而是让一个父工作流在同一 DAG 层同时拉起多个workflow:子运行共享父 checkout 的写任务会撞上引擎的路径独占锁每个运行开始时对其工作路径加锁发现路径已被另一个活跃运行占用的运行会自我取消父运行随之失败而且父运行 resume 时failed 的子运行会重跑但 cancelled 的子运行原样透传——这种失败在每次 resume 上都会以同样方式复现只能靠新运行解决。三个并列的选择按子运行的实际行为挑子运行…做法只读仓库review、research、summarize在子工作流文件上声明mutates_checkout: false跳过路径锁可多个共存于同一 checkout会写仓库在每个workflow:节点上写isolation: worktree完全不允许重叠用depends_on串行化isolation: worktree只允许写在workflow:节点上其他节点类型会在加载时被拒绝。配置示例来自工作流作者指南- id: refactor-module workflow: refactor-block input: $plan.output isolation: worktree # 独立 checkout、独立分支 depends_on: [plan]使用它前需要知道四件事分支从仓库的 base branch 切出而不是从父运行切出worktree 在规范 checkout 中从origin/baseBranch创建父运行的未提交改动和父分支上的提交子运行都看不到所需内容要通过input:、artifacts 或仓库 base 分支传入。切出点遵循 base branch 优先级表的第 2–4 级.archon/config.yaml的worktree.baseBranch→ codebase 存储的默认分支 → Git 自动检测顶层派发时传的--base/--from不会传播给子运行。不会自动合回子运行的提交留在子分支上落地推分支、开 PR是工作流自己的职责自动返回的只有子运行的终态输出$nodeId.output。它成为受管理的隔离环境出现在archon isolation list中分支名形如archon/task-parentRunId8-nodeId-hash-child-n如archon/task-3f9a1c2b-refactor-module-6fd3f873-child-0受同样的cleanup/complete治理子运行结束后分支刻意保留以便检查或落地。resume 会复用原 worktree若已被清理则失败只要子运行的 run 记录还在resume 复用其上记录的路径该路径若期间被清掉节点会以 its working path no longer exists … start a fresh run 失败。在子运行树仍 resumable 时不要执行isolation cleanup留到整个运行结束再动子运行 worktree。如果项目是 folder project用--folder注册的非 git 工作区或运行时没有解析到任何 codebase节点会快速失败而不是悄悄退回共享 checkout——因为静默回退恰恰会造成隔离想避免的并发写冲突报错形如isolation: worktree on sub-run name requires an injected child-isolation resolver (available for git-repo codebases run via the CLI or orchestrator). Remove the isolation or use inherit (shared checkout).注意archon validate workflows检查不出这类问题能否创建 worktree 是运行时的属性而不是文件的属性所以含isolation: worktree的工作流在任何地方都能通过校验到不能创建 worktree 的环境运行才会在该节点失败。若工作流只适用于 git 仓库文档建议写进它的description:。运行结束后的清理complete 与 cleanupworktree 会随时间累积PR 合入后按生命周期收尾# 移除该分支的 worktree、本地分支和远程分支并把隔离环境标记为已销毁 archon complete fix/issue-42 # 一次接受多个分支名 archon complete fix/issue-42 feat/dark-modecomplete在移除前会校验补丁已在配置或探测到的远程默认分支上。若 GitHub 已删除 squash-merge 的分支先git fetch --prune originremote 非 origin 时换成对应名称让本地克隆反映该删除再执行complete。--force标志可跳过安全检查按需使用。批量清理陈旧环境# 默认移除超过 7 天的 worktree archon isolation cleanup # 自定义天阈值 archon isolation cleanup 14 # 移除分支已合入 main 的环境同时删除远程分支 archon isolation cleanup --merged # 连被放弃CLOSEDPR 的分支一起清理 archon isolation cleanup --merged --include-closed合并检测按顺序使用三种信号git 分支祖先关系fast-forward / merge commit、补丁等价squash-merge 经git cherry、以及经ghCLI 的 GitHub PR 状态gh可选缺失时只用 git 信号。几条保护规则要知道带 OPEN PR 的分支永远跳过带 CLOSED PR 的分支默认跳过除非加--include-closed。只要还有工作流运行可以认领running、pending、paused包括 failed——失败的运行仍可 resume无论多旧、合并与否都不会被清理移除因为删环境会连带删掉--resume和--adopt需要的本地分支。带未提交改动的 worktree 不会被移除若cleanup跳过了某个 worktree先用archon isolation list检查再手动处理。适用边界base branch 有四个来源优先级从高到低单次派发的--base branch同时设置 worktree 切出点与 PR 目标$BASE_BRANCH且分支必须已存在于远程否则是硬错误、.archon/config.yaml的worktree.baseBranch、codebase 存储的默认分支、Git 自动检测origin/HEAD然后origin/main。--from branch只覆盖切出点、不改 PR 目标可与--base组合分别驱动两者若本地起点副本可能过期传远程 ref如origin/release/2.0因为--from会原样交给git worktree add。顶层子运行并发还有一个约束同一时刻只有一个阻塞式子运行审批门——同一层两个都暂停等审批的子运行会争用父运行的单个审批槽第二个暂停被静默丢弃直到后续 resume 再次在该子运行上暂停。需要审批门的子运行用depends_on串行。相关文档隔离机制总览见 Isolation and Worktrees命令与标志的完整参数表见 CLI 参考子运行隔离与路径锁的完整语义见 工作流作者指南worktree配置项baseBranch、copyFiles、remote、initSubmodules等见 配置参考。PR 合入、archon complete branch执行成功之后用archon isolation list确认列表回到只剩仍在运行的任务——这就是这一轮并行运行的干净收尾。【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考