三步给 Worktrunk 接上 CI 网关让 Agent 每次改动都先过测试再合入主干【免费下载链接】worktrunkWorktrunk is a CLI for Git worktree management, designed for parallel AI agent workflows项目地址: https://gitcode.com/GitHub_Trending/wo/worktrunk多 Agent 并行的开发模式已经跑起来了Claude Code、Codex 各自占一个 worktree互不干扰地改代码、写提交、推分支。但真正的瓶颈从来不是谁能改得快而是谁改的能安全地进主干。Agent 不会等测试不会看 CI 红灯它只会做完任务然后报告可以合了。如果合入动作没有一道强制门禁主干很快就会被一批本地能编译、远程全红的提交污染。Worktrunk 给出的答案是把这道门禁做成命令级网关用pre-merge钩子在合入动作发生前强制执行测试用wt list --full让每个 Agent 分支的 CI 状态随时可见再用wt merge的固定管线把测试通过→合入→清理变成不可跳过的单条命令。本文从源码出发拆解三步落地方案附带可直接抄走的配置。一、网关设计思路把门禁放在合入动作内部而不是外部约定先想清楚一个前提为什么不能用团队约定来兜底因为约定对 Agent 无效。Agent 不会自觉遵守合入前跑一遍测试的流程规范它只会执行被编排进命令链里的步骤。所以门禁必须长在合入这个动作本身里——要么合入前跑测试要么不允许合入。这就是网关的本质在信任边界上做强制校验。Worktrunk 把这道校验做进了wt merge的固定管线里merge.rs 的执行顺序是Commit/Squash— 未提交改动先被收敛成提交默认 squash合并前的工作树改动会先备份到refs/wt-backup/branchRebase— 把分支变基到目标分支之上Pre-merge 钩子— 变基之后、真正合入之前执行FailureStrategy::FailFast任何一个命令失败都会中止整个合入Merge— 快进推送到目标分支--no-ff时创建合并提交Pre-remove / Cleanup— 合入成功后移除 worktree 与分支Post-钩子* — 后台运行用于部署通知等非阻塞动作。关键在第三步pre-merge是阻塞型钩子失败即中止而中止发生时分支还停在原处、目标分支未动分毫——这就是先过测试再合入主干的语义保证管线细节见 merge.md 的 Pipeline 一节。配套的可观测性同样重要。Agent 分支推上去之后测试到底过了没有wt list --full的 CI 列直接回答这个问题每个分支显示其 PR/MR 编号GitHub/Gitea/Azure 为#3035GitLab 为!3035并用颜色编码管道状态——绿色 passed、蓝色 running、红色 failed、黄色 conflicts、灰色 no-ci、⚠表示拉取失败list.md。也就是说网关不是只在合入那一刻亮红灯而是让每一个 Agent 分支的 CI 状态在整个生命周期里都处于可视状态。二、命令级对接三步配置把测试变成合入的前置条件第一步声明项目钩子写入.config/wt.tomlWorktrunk 的钩子支持三种 TOML 形态字符串是单条命令表是并发执行的多个命令[[hook]]序列是带依赖顺序的管线。一个最简网关长这样# .config/wt.toml [[pre-merge]] test cargo nextest run lint cargo clippy -- -D warnings [[pre-merge]] build cargo build --release第一个块里test和lint并发执行第二个块在它们全部通过后才跑build。pre-merge钩子运行时{{ branch }}指向被合入的特性分支{{ target }}指向合入目标模板变量可以用{{ branch | hash_port }}这类过滤器动态生成测试端口hook.md。第二步打通 forge 识别让 CI 状态找得到门pre-merge只管本地校验而远程 CI 状态的可视化依赖 Worktrunk 对代码托管平台的识别。平台识别集中在 ci_platform.rsForgeKind枚举覆盖 GitHub、GitLab、Gitea 和 Azure DevOps解析优先级是配置 分支所属 remote 主 remote URL 主机名。也就是说GitHub/GitLab/Gitea 这类带品牌名的主机可以自动识别但自托管实例比如git.company.example上的 Forgejo需要在项目配置里显式点名# .config/wt.toml [forge] platform gitlab # 或 github / gitea / azure-devops hostname git.company.example多个仓库共享同一个自托管主机时也可以在用户配置里用[projects.git.company.example/*]模式一次声明仓库自身的[forge]永远覆盖用户级条目config.md。识别到平台后CI 状态的实际查询走各平台的官方 CLIgh、glab、tea、az。查询策略是先查 PR/MR再回退到分支工作流分支可能作为某个 PR 的 head 时先问 PR 的检查结果没有 PR 且分支有上游时再查分支管道本身platform.rs。PrStatus里还带一个is_stale字段本地 HEAD 与远端不一致时状态会变暗显示——这在多 Agent 场景下非常关键它提醒你CI 绿灯对应的提交不是本地这份。第三步预批非交互执行让 Agent 无需人工点确认钩子是项目级命令Worktrunk 的安全模型要求首次运行弹窗审批。但 Agent 是非交互的弹窗等于卡死。两条路预审批克隆项目后在 CI 编排环境里跑一次wt config approvals add把项目命令的批准持久化到~/.config/worktrunk/approvals.toml之后合入不再弹窗config.md 的 Approvals 一节运行时绕过给wt merge传--yes仅对当次运行授予同意且不落盘下次仍会询问——适合每轮合入都重新确认的严格策略。同样关键的是Worktrunk 在调用gh/glab时显式设置了GH_PROMPT_DISABLED1、NO_COLOR1并移除GH_FORCE_TTY保证 forge CLI 在无 TTY 环境下既不弹交互也不输出终端专属格式ci_status/mod.rs 的non_interactive_cmd。这条容易被忽略但对 Agent 流水线是生死线一旦gh在批处理里弹了浏览器认证或交互提示整条合入管线就会挂起。三行命令的完整闭环$ wt config approvals add # 预批准项目命令供无人值守使用 $ wt list --full # 观察各 Agent 分支的 CI 状态 $ wt merge # 测试通过后一次完成合入清理三、合并策略与失败回滚网关的兜底机制网关不是只拦测试不过它还要处理测试过了但合入时出问题的情况。wt merge的管线为此内置了三层防护。第一层变基冲突不销毁现场。默认管线会在合入前把分支变基到目标之上step.md 的wt step rebase一节。如果某个提交变基时产生冲突Worktrunk 不会自动回滚或强推而是把 rebase 停在冲突状态保留 git 冲突标记由你决定git rebase --continue解决后继续、git rebase --skip或git rebase --abort放弃并回到变基前。而且一旦检测到 rebase 进行中wt merge会直接拒绝启动merge.rs 的ensure_no_operation_in_progress防止带着一半变基的索引强行合入这类二次破坏。第二层合入前的工作树改动有备份。默认的 squash 步骤会把工作树里未提交的改动先备份到refs/wt-backup/branch再统一收敛成一个提交。这意味着即使合入中出了问题未提交的内容也能从备份 ref 找回不会随着 worktree 清理而蒸发。第三层合入策略可细分回滚路径明确。wt merge的六个布尔开关覆盖了从全自动到全手动的策略谱系场景命令行为默认推荐给 Agentwt mergesquash rebase pre-merge 门禁 快进合入 清理保留提交历史wt merge --no-squash不做 squash逐个保留提交要求线性历史、禁变基wt merge --no-rebase保留原图要求目标能快进到分支尖端否则拒绝创建合并提交wt merge --no-ffrebase 后创建 merge commit保留半线性历史合入后保留 worktreewt merge --no-remove便于失败后立即诊断现场完全跳过钩子wt merge --no-hooks显式放弃门禁应仅用于人为决策的场合注意到--no-rebase与--no-ff的组合语义--no-rebase要求目标是分支历史的祖先否则直接报NotRebased错误——这条检查在 merge.rs 里是硬性校验没有 force 变体从根上杜绝了悄悄改写历史再合入。另外合入失败时 worktree 与分支都还完整存在你可以直接wt switch回该分支修 bug 再重试合入成功后默认会移除 worktree 和分支如果想给 Agent 留一个复核现场用--no-remove即可。落地建议把网关接进 Agent 的调用链最后把整套方案嵌入 Agent 工作流的实际调用链。对每个 Agent 任务Agent 完成改动后不直接合入而是先git push让远程 CI 跑起来轮询wt list --full --formatjson读取每个分支的checks对象等待状态从running变绿passed或变红failed状态为passed时执行wt merge --formatjson一次完成本地测试门禁 → 变基 → 合入 → 清理状态为failed时把失败信息连同 CI 链接交还给 Agent 修复合入结果用 JSON 结构化输出解析committed/squashed/rebased/removed四个字段让编排器清楚知道每一步发生了什么。这套方案的价值在于本地pre-merge钩子兜住快速失败秒级拿到编译/单测结果远程 CI 状态兜住合入前全量校验wt merge的管线语义兜住合入动作原子化。三道兜底把Agent 改完就合变成了Agent 改完、验证通过、才能合而所有校验都长在命令内部——Agent 想跳过只有显式传--no-hooks而这本身就是一个可以被审计和禁止的动作。【免费下载链接】worktrunkWorktrunk is a CLI for Git worktree management, designed for parallel AI agent workflows项目地址: https://gitcode.com/GitHub_Trending/wo/worktrunk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考