Worktrunk：面向并行AI Agent工作流的Git Worktree管理CLI

我最早被这个场景折磨是在跑多个AI Agent同时改同一个Git仓库的时候。当时我同时开着好几个Agent实例让它们分别改登录模块、支付模块和API错误处理结果不到半小时它们就开始在一个工作目录里互相踩脚一个Agent在跑测试另一个Agent在这份工作区里升级依赖一个Agent在分支A上改到一半另一个Agent切了分支把工作区搞得一团乱。老一辈工程师早就遇到过这种问题Git的worktree就是为多工作目录并行而生的但原生命令在AI Agent场景下还是太“手动挡”了。于是我自己写了一个面向并行AI Agent工作流的Git Worktree管理CLI叫Worktrunk。这篇文章就把它的定位、设计、实现和一些趟坑过程讲透适合正在用AI Agent做代码改动、又不想让Agent在同一个目录里互相打架的团队或个人开发者。1. 为什么并行AI Agent工作流需要独立的Worktree管理1.1 多Agent在同一个工作目录打架的典型场景先聊一个很现实的问题AI Agent跑代码任务时到底会动哪些东西。表面上你只是让它“帮我修一下登录模块的Bug”但它大概率会做这样一堆操作创建或切换分支、改源码文件、读写配置、安装新依赖、跑测试、跑构建、生成临时文件、提交commit。这些操作全部发生在一个共享的Git工作目录里。你可能会想多个Agent用不同分支不就行了确实只要它们不共享同一个工作目录分支本身是隔离的。但麻烦就麻烦在大多数Agent工具默认的“在某个目录里执行命令”是发生在同一个物理目录里的。两个Agent同时在这个目录里跑一个改了文件但没提交另一个执行git status看到的全是脏数据甚至可能把别人的半成品当基线继续改。更糟的是如果两个Agent同时执行git checkout或者git reset轻则会让其中一个Agent的工作现场丢失重则会让整个仓库进入不可预期的状态。这还没算锁冲突。Git在工作目录的.git/index.lock下面会做互斥同一个仓库同一个工作区同时写索引的时候第二个操作会直接报错“Another git process seems to be running”。AI Agent通常不会像人一样理会这种报错并去排查它可能反复重试几次之后直接给你本地仓库留下一个残留的index.lock文件整条流水线就卡死了。还有一个很容易被忽略的坑是环境依赖的互踩。只要有一个Agent更新了package.json或requirements.txt并执行了依赖安装另一个Agent在跑测试的时候可能就会莫名失败因为它读到了刚刚被替换的node_modules或.venv。这种问题的定位成本极高因为你很难从报错日志里想到是另一个Agent在“背后改环境”。1.2 Git Worktree到底解决了什么Git的worktree机制本质上是让你能在同一个仓库对象库基础上维护多个独立的工作目录。你可以理解为每一个worktree都拥有自己独立的源码目录、自己的暂存区、自己的HEAD但它们共享同一个.git对象库和远程配置。一个最简单的原生用法是这样git worktree add ../repo-agent-a -b feature/agent-a执行之后../repo-agent-a会成为一个新的可工作目录并且自动检出到新建的feature/agent-a分支。你原来的目录依然在原来的分支上。两个目录里的Git操作互不干扰git commit、git add、git status都可以同时进行。这里的本质原因是Git的索引和HEAD在每个worktree里是独立的而对象库本身支持并发读取和写入Git内部有足够完善的并发保护。但worktree原生命令在Agent场景下有几个别扭的地方。第一每次创建worktree都要手动指定路径和分支名Agent没法直观地知道“现在这个任务应该放哪”。第二worktree一多你很难快速搞清楚哪个worktree对应哪个任务、哪个Agent、哪个分支更不知道它是不是已经可以回收了。第三原生worktree缺少“状态”的概念你没法很方便地给某个worktree打个标签比如“这个正在被Agent A使用请勿删除”或者“这个worktree已经跑完可以清理了”。这些需求在人类开发者单线程工作的时候几乎不存在但放到并行AI Agent工作流里就成了刚需。Agent不像人它不会去记忆任务上下文它需要的是按照一个明确的、机器可读的状态来行动。1.3 Worktrunk的定位把worktree用Agent化的方式管起来Worktrunk的定位简单说就是做一个“Agent原生”的worktree管理CLI把worktree的创建、注册、查询、清理封装成Agent容易调用的命令并且用一份结构化的元数据记录每个worktree的状态。它的核心思路是“面向任务管理而不是面向分支管理”。也就是说用户和Agent都不需要去关心分支名怎么起、路径放哪里、用哪个base分支这些都是Worktrunk根据任务名和配置自动决定的。你只需要告诉它“我要为task-1234开一个工作空间”剩下的worktree路径、分支名、base分支、状态注册Worktrunk一次性完成。这个分工在实际用起来的时候很舒服。比如我要同时让三个Agent并行开干我只需要分别创建三个worktree然后让每个Agent进入对应目录干活。因为每个Agent有独立的工作目录彼此之间连环境依赖和索引锁都不用抢唯一的共享点是Git对象库本身这正好是Git设计上能并发处理的部分。一句话总结Worktrunk的核心价值它把“人类在命令行里手动切换分支、小心翼翼管理多个工作区”这件事变成了一套任何Agent都能理解和执行的机器友好接口。这也是为什么它天然适合嵌入到各种AI Agent工具链里。2. Worktrunk设计拆解命令、状态与元数据2.1 面向任务管理而不是分支管理Worktrunk的第一设计原则是让用户在绝大多数场景里只跟“任务”打交道。任务名是语义化的比如fix-login-bug、add-payment-tests、refactor-api-error。Worktrunk拿到任务名后会把它转换成一个合法的分支名再决定worktree的存放路径。举个例子我实现里的默认参数是任务名转小写、空格替换成连字符、非法字符剥离然后加上一个短随机后缀避免两个同名任务撞车。worktree路径则默认放在仓库根目录之外的../仓库名-任务名或者./.worktrees/任务名下。这个设计有讲究如果你把worktree目录放在仓库主工作区的子目录里后续可能出现一些工具递归扫描文件夹的问题比如IDE、测试工具、ESLint这类会递归扫整个项目目录的工具会把其它worktree里的文件也扫进去导致结果非常混乱。所以我建议默认把worktree放在仓库目录外部或者放在一个带上.前缀的隐藏目录里并让各类工具显式忽略它。如果用户有更复杂的需求比如想让某个Agent在指定目录下工作Worktrunk也支持通过参数覆盖默认路径但我自己实际用下来绝大多数场景遵循默认规则就够了。2.2 元数据设计每个worktree的状态从哪来光有worktree还不够Agent要能知道自己的“势力范围”和仓库全局状态靠的是元数据。Worktrunk的做法是在仓库根目录下维护一个.worktrunk.json文件这个文件记录了所有由Worktrunk创建的worktree信息。典型的结构大致长这样{ version: 1, worktrees: [ { id: task-1234, task: fix-login-bug, path: /abs/path/to/repo-fix-login-bug, branch: fix-login-bug-8f3a2c, base: main, agent: codex, status: active, createdAt: 2025-02-10T10:00:00Z, lastUsedAt: 2025-02-10T10:30:00Z } ] }为什么要把这些信息放在一个机器可读的JSON文件里因为AI Agent非常擅长解析结构化的东西但很不擅长从一段自由文本命令行输出里猜状态。有了这个文件Agent只需要一句worktrunk list --json或者直接让Agent读取.worktrunk.json它就能清楚地知道全局有哪些worktree、哪些属于自己、哪些还在被别人使用、哪些已经标记成完成状态。这里有一个我在设计早期差点做反的点我原本想用git的git worktree list --porcelain作为唯一数据源自己实时解析。后来发现这不够用因为Git的worktree列表只包含路径、分支和HEAD这些Git层面的信息它不知道这个worktree对应的是哪个Agent、什么任务、是active还是待回收。所以最终决定在Git之上加一层元数据以Git worktree为准、以元数据为补充两者结合使用。任何时候元数据和Git实际状态不一致都以Git当前存在性为准元数据只负责记录“人和Agent需要知道的额外信息”。2.3 命令表和常用操作流Worktrunk的命令设计是围绕Agent场景组织的我不追求覆盖Git的所有能力只求覆盖并行工作流的常见操作。我实现的核心命令如下命令作用说明worktrunk create task创建一个worktree自动选base分支、自动起分支名、自动注册到元数据worktrunk list列出所有worktree支持--json输出方便Agent解析worktrunk status task查看单个worktree状态显示分支、路径、Agent、状态、最近使用时间worktrunk destroy task销毁一个worktree会先检查是否有未提交变更可用--force跳过worktrunk mark task --status done修改状态适合Agent跑完后标记状态worktrunk prune回收失效worktree清理文件系统上已不存在但元数据还残留的记录worktrunk freeze task锁定某个worktree防止Agent或人误删正在使用的目录日常使用里最常见的一条链路是创建任务工作区 - Agent进入目录干活 - Agent跑完标记状态 - 人工审查合并分支 - 销毁worktree。有了这套命令之后我基本不再手动去跑git worktree add了。3. 从零实现核心步骤与选型考量3.1 为什么我用Go而不是Rust/PythonWorktrunk选型的时候我在Go、Rust、Python三者之间纠结过一阵最终选了Go理由是它最适合这个场景的“中庸之道”。先说为什么不选Python。Python写CLI很快但打包分发是硬伤尤其在Agent装进容器或者不同开发机上跑的时候Python环境依赖容易翻车。我不是说Python不行而是我不想让用户在引入Worktrunk时还得先解决Python版本和第三方依赖问题。再说为什么不选Rust。Rust的性能确实强编译产物也漂亮但开发效率相对于Go要慢不少而且这个工具的核心操作几乎全在调用git命令上Rust的性能优势体现不出来。对Worktrunk这类IO密集型的胶水CLI来说工程开发效率和维护成本更重要。Go的优势在于编译产物是单一静态二进制交叉编译非常简单启动速度快文件IO和进程调用标准库用着很顺手。我用os/exec直接调用系统中的git命令而不是用libgit2绑定主要是为了保留Git原生的凭证管理器、SSH配置、include配置和一系列credential helper行为。如果你直接用libgit2或者其他Git库最痛苦的事情就是经常要自己处理密钥、凭证缓存和各种.gitconfig兼容。直接调用系统Git等于把这些复杂问题全部丢回给Git自己处理对CLI工具来说是最稳妥的方案。3.2 create流程从任务名到可用worktreeWorktrunk的create子命令是整个工具的心脏。它做的事情看着简单但每一步都有坑。我整理一下核心流程校验任务名转换成合法的分支名。确定worktree路径。检查目标worktree是否已存在存在且是同一个task就直接返回避免重复创建。确认base分支存在并且base分支的远端是最新的。调用git worktree add path -b branch base创建worktree。将worktree信息写入.worktrunk.json元数据。对worktree执行一次git status验证可用性。其中第4步值得展开。并行Agent场景下base分支往往是main或develop。如果Agent创建worktree的瞬间base分支已经在远端更新过但本地还没有fetch那么这个Agent就会从一个过期的commit上开始开发最后合并时容易产生大量不必要的冲突。所以我干脆在创建时先执行一次git fetch origin base让base分支指向远端最新状态再创建worktree尽量把“冲突风险”往前压低。第5步也可能出问题就是worktree路径冲突。Git原生会报一个“already exists”的错误这时候Worktrunk不应该直接崩溃而应该去对比已有的worktree是不是同一个task如果是就复用并返回如果不是就提示用户换个任务名或路径。这种“Create Or Reuse”的语义对Agent场景很重要因为Agent的重试逻辑很常见没有幂等的创建接口任务稍微抖动一下就会留下一堆废弃目录。3.3 与Agent工具链的对接方式Worktrunk是一个CLI但CLI本身并不能让Agent“自己学会用它”你需要把命令暴露给Agent。目前我用到的几种对接方式各有适用场景。第一种最简单粗暴把Worktrunk的使用说明写进Agent的system prompt或者写进Agent工具配置的instructions文件里。比如Claude Code、Codex CLI这类工具都支持通过配置文件注入额外指令。你可以在里面写清楚“在开始任务前先执行worktrunk list --json查看当前所有worktree如果已有对应task的worktree直接进入该目录工作否则执行worktrunk create task新建工作区。”这样Agent就会自己主动去调用这些命令。第二种是针对可以自定义工具的Agent Harness比如n8n、自己写的Agent框架或者一些支持MCP协议的工具。你可以在工具定义里声明Worktrunk的各个命令为可用工具然后给每个命令写清参数和用途。Agent看到了工具列表就知道它可以调用worktrunk_create来新建工作区、用worktrunk_list来查看全局状态。这里有一个我踩过的坑不要把整个终端shell直接暴露给Agent说“你自己随便敲命令”。虽然很灵活但Agent在这种自由度下经常做出意外操作比如跑到别的worktree里去执行命令。更好的方式是做一个受限的工具层让Agent只能调用Worktrunk暴露的命令以及任务必要的构建命令这样既能隔离状态又能减少风险。3.4 清理、回收与生命周期并行Agent工作流里清理和创建同样重要。Agent跑完后worktree不会自动消失如果不及时清理过几天仓库旁边就会堆一堆“看起来不知道还有没有用”的目录。销毁一个worktree前我会强制检查两个东西一是worktree里有没有未提交的变更二是是否有相关进程还在这个目录里运行。未提交的变更可以用git diff --quiet或git status --porcelain来检测。进程占用则不太好自动判断因为Agent可能还挂着终端在跑。所以我在实现里给worktree加了一个freeze状态相当于一个显式锁Agent开始工作之前加锁工作结束之后解锁。销毁时如果发现worktree处于冻结状态Worktrunk会拒绝删除提示需要先解锁。另外Git自身偶尔会出现一些“失效”的worktree记录一般是因为worktree目录被手动删除或者Git元数据损坏。Worktrunk的prune命令会扫描元数据逐一验证每个worktree的目录是否真实存在、是否还能正常执行Git操作不行的就清理掉并把元数据文件同步修好。这条命令建议每天任务开始前跑一遍能省掉很多后续的“幽灵目录”问题。4. 实操用Worktrunk编排并行Agent的完整流程4.1 一个实际的多Agent并行任务拆分拿我自己最近一次真实场景举例。那是一个中型后端仓库同时有三块任务要推进一是修复登录模块的一个并发会话Bug二是给支付模块补单元测试三是重构API错误处理中间件让错误码统一。如果用串行方式一个Agent做完另一个再上整个流程要拉很长。用并行方式我必须保证每个Agent在第一秒开始就有一个隔离的、干净的工作区。这时候Worktrunk的价值就体现出来了。任务拆分之后我连续创建了三个worktreeworktrunk create fix-login-session --agent codex --base main worktrunk create add-payment-tests --agent claude --base main worktrunk create refactor-api-errors --agent other-agent --base main每条命令执行完Worktrunk都会告诉我创建好的worktree完整路径、自动生成的分支名以及对应的Agent名。然后我分配给三个不同的Agent让它们分别去各自的目录工作。4.2 初始化与启动Agent实际启动Agent时我会先让每个Agent跑一句worktrunk status task确认自己所在目录的worktree状态是对的再开始干活。这一步虽然感觉多余但能避免一种很反直觉的状况Agent因为系统提示或者上下文残留以为自己在fix-login-session目录其实实际工作目录已经被它自己切换到了另一个分支或者被别的工作流改动过。启动Agent的包装脚本大概是这个样子#!/bin/bash WORKTREE_PATH$(worktrunk status fix-login-session --json | jq -r .path) cd $WORKTREE_PATH worktrunk freeze fix-login-session # 启动Agent让它在这个目录里工作 agent-cli --model gpt-4o --workspace $WORKTREE_PATH这里把freeze放在Agent启动前执行就是给这个worktree加锁避免Worktrunk的清理任务误删它。Agent跑完之后我再执行worktrunk unfreeze和worktrunk destroy。在实际工程里如果你没有包装脚本的控制权也可以在启动Agent时直接在目标worktree目录里运行Agent的交互命令。我建议在Agent的system prompt里再补一句“你当前工作目录是你的专属工作区不要跳转出这个目录不要修改其他worktree”这类约束虽然不能100%防呆但实测能显著降低越界操作次数。4.3 Agent跑完之后的合并与清理三个Agent并行跑完后我的合并流程也不是一把梭。首先我会看一遍每个worktree里的git log和git diff确认改动是否符合预期。然后我再逐个把分支推送到远端在远端发起Merge Request或者Pull Request让Code Review和CI继续把关。这里有个值得说的并行优势因为每个Agent的改动都在独立分支上所以每个MR的运行是并行的不存在“你跑完我才能跑”的排队关系。人工Review也可以完全按风险优先级来而不是按提交时间排队。合并完一个分支后我会顺手把这个worktree销毁掉保持本地清爽。销毁命令worktrunk destroy fix-login-session如果某个分支要保留复现环境我就先worktrunk mark fix-login-session --status archived让它进入归档状态之后统一批量清理。归档状态的worktree不会出现在默认的list输出里但可以通过worktrunk list --all查到这个机制对复盘历史任务很有用。4.4 与CI/CD的衔接Worktrunk本身不替代CI/CD但它可以在本地为CI/CD搭好“互不阻塞”的基础结构。比如我有自己的GitLab CI或GitHub Actions流水线每个分支push到远端都会有对应的流水线运行。并行worktree模式下的最大好处是每个Agent分支的流水线都是独立的失败互不影响。你不需要像以前那样等一个合并到主线后再重新触发后续任务。另外如果Agent需要跑一些比较重的本地验证比如本地跑测试、构建镜像也可以利用worktree的隔离性来做。只要每个worktree的依赖目录是独立的它们之间几乎不会互相干扰。这里提醒一点如果你用了一些需要共享缓存的构建工具比如pnpm store、sccache它们内部已经有并发锁和管理机制是可以放心共享的。但如果你用的工具没有锁比如随手在全局目录里写临时文件的脚本就可能出现并发问题建议提前调研一下再用。5. 常见问题与排错实录5.1 index.lock冲突和worktree被占用使用过程中我遇到过最多的报错就是Git的index.lock冲突。表面现象是Agent在跑某个Git命令时报“Unable to create .git/index.lock: File exists”或者“Another git process seems to be running”。这种报错有三个常见来源一是两个Agent同时操作同一个worktree索引二是有其他进程在后台运行Git命令比如IDE的Git插件、自动格式化工具、文件监听器三是上次Agent运行到一半被杀掉留下了一个残缺的锁文件。排查顺序我建议这样先用ps aux | grep git或任务管理器看看还有没有真正的Git进程在运行如果没有再确认是不是IDE或自动化工具在后台操作确认没有真实进程后才能手动删除锁文件。这里要特别谨慎不要一手抖就把锁文件删了万一另一个Git命令正在执行中途删锁会导致索引写坏。我在Worktrunk的文档里特别标注了这个风险并建议普通用户不要手动随便删锁。5.2 “another git process seems to be running”错误的真相很多时候这个报错的真相不是真有另一个Git进程而是残留的.git/index.lock文件或者shallow.lock。AI Agent被强行中断命令的时候特别容易留下这个问题。对这种残留锁我的处理方式是先检查时间戳。如果锁文件的修改时间已经过去了十分钟以上且当前确实没有Git进程在跑那基本可以判定是残留文件可以安全清理。如果是在集群或远端开发环境里还需要注意是否有其他终端窗口在使用同一个工作区这种多人多终端共享目录的场景特别容易产生锁文件。Worktrunk在新版本里加了一个doctor子命令扫描当前仓库的所有worktree检查锁文件、worktree状态、元数据一致性发现异常就输出诊断报告。这个命令我强烈建议在Agent开始任务前跑一次属于“花几秒钟省一小时排障”的投资。5.3 Windows下的Path长度限制如果你在Windows上使用Worktrunk一定会撞上路径长度问题。Windows默认的MAX_PATH限制是260个字符而worktree路径一般是仓库路径/任务名加起来很容易超过限制尤其是当项目本身在C:\Users\用户名\...这种长路径下。解决这个问题的办法有几种。第一在仓库根目录放一个.gitattributes并配置长路径支持同时开启Windows的LongPathsEnabled注册表项。第二把worktree的存放根目录设置到一个短路径下比如直接放在C:\wt\下面Worktrunk支持通过环境变量WORKTRUNK_ROOT来统一指定worktree根目录。第三任务名不要起得太长尽量用fix-login而不是fix-login-bug-with-session-invalidation-xyz。如果你是团队推广我建议直接把worktree根目录统一配置成短路径这个收益最大。Windows上你还得注意有些Agent工具内部使用硬编码的相对路径或者临时目录worktree路径变了会导致工具找不到文件这个要提前在Agent工具配置里做好映射。5.4 磁盘占用和node_modules重复Worktrunk能解决并行目录的冲突但绕不开一个物理事实每个worktree都有自己完整的工作目录。如果你的项目里有庞大的node_modules、.venv或者构建产物那么每个worktree都会有一份拷贝磁盘占用会成倍增加。这不是Worktrunk的问题但作为实际操作的人你必须提前规划。我在项目里的应对方案是对依赖目录做符号链接。比如把第一个worktree的node_modules链接到C:\shared-cache\node_modules其它worktree也链接到同一个目录。这样依赖只有一份磁盘占用陡降而且并发的编译和测试基本能共享同一份依赖。但副作用是你不能同时在不同worktree里安装不同版本的依赖因为链接是共享的。如果你觉得这种共享依赖策略太“脏”也可以接受磁盘占用让每个worktree独立安装依赖。现代磁盘容量普遍够用这个取舍取决于你的项目大小和并发度。我个人的选择标准是如果项目依赖超过1GB就启用符号链接如果依赖很小就让它们各自独立。5.5 分支同步与冲突的几种处理策略并行分支的时代最终合并时的冲突概率会比串行分支高一些这是不可避免的。但有几个策略能把冲突降低到比较可控的程度。第一个策略就是我在create流程里在Base分支上做一次git fetch让每个Agent都从最新基线开始。这个能解决70%的“其实两边都没改只是起点不同”造成的冲突。第二个策略是Agent任务粒度拆分得足够细让不同Agent尽量改不同文件。我在任务拆解阶段就会注意模块边界比如一个Agent只改auth包另一个只改payment包它们几乎不会碰到同一个文件。第三个策略是合并不要太拖。并行分支一旦合完马上把最新主线同步回来让剩下还没合的分支尽快与最新主线同步减小时间差。这个同步也可以用Worktrunk去实现就是获取已合并的worktree状态后对还在active的worktree做一次git merge origin/main。我通常在Agent任务完成后统一执行一轮同步避免每个Agent自己乱合。6. 扩展方向Worktrunk未来还能做什么6.1 Task Graph依赖和拓扑排序现在的Worktrunk把每个worktree当成完全并行的单元处理但真实情况下任务之间是有依赖关系的。比如支付模块的测试用例依赖登录模块修复后的会话逻辑那Agent B就不应该在Agent A合入之前就开始基于旧的登录逻辑写测试。我计划在元数据里增加一个depends_on字段把worktree组成一个有向无环图。Worktrunk可以在创建worktree时检查依赖是否完成如果有未标记为done的前置任务就先提示用户或者自动把任务移动到“等待队列”。这个能力对复杂项目的并行编排非常关键毕竟纯并行只是理想情况真实工程大多数任务还是有先后顺序的。6.2 远程回收和自动休眠目前Worktrunk的清理逻辑是手动触发或者通过prune回收已经失效的目录。但Agent工作流跑多了之后服务器上很容易积攒一批“任务已经完成但忘了清理”的worktree白白占着磁盘和索引资源。我准备加一个自动回收机制根据lastUsedAt时间戳和status字段做判断如果worktree超过一定天数没有使用且状态已经是done或archived就从本地移除。同时考虑支持远端分支的自动删除策略这样清理可以从本地扩散到远端避免远程分支也堆成垃圾山。自动回收功能如果上线一定要在文档里提醒用户设置保守的过期时间否则容易把一个随手放着待复用的环境给删了。6.3 通过标准协议接入更多Agent工具每一类Agent工具都有自己的调用规范Worktrunk如果只对接一两种覆盖率太有限。我现在的Plan是让Worktrunk除了纯CLI命令之外也支持通过标准协议对外暴露能力比如MCP或者JSON-RPC。这样任何支持这些协议的工具都能直接把Worktrunk作为工具集加载进去。还有一个方向是让Worktrunk自己成为“Agent调度协调器”在创建worktree的时候自动给Agent实例下发任务说明让整条启动流程从“人工写脚本拉起Agent”变成“一个命令同时拉起N个Agent并分配工作区”。这个想法还在原型阶段因为牵扯到不同Agent工具的参数差异和会话管理方式要做通用化需要花不少精力但它确实是并行Agent工作流最终形态里很值得做的一环。回到我自己的使用感受。Worktrunk最初只是我从一次混乱的Agent并行开发中总结出的一个“临时脚本”结果越用越发现真正重要的不是怎么调用Git而是怎么让Agent和人都能清楚地知道“这个仓库现在处于什么状态”。很多AI Agent相关的工具都在炫模型能力但工程化落地往往败在环境隔离和状态混乱上。如果你也开始用多个Agent改同一个仓库我建议你先别急着加模型先把工作区隔离好这一步做好后面会省下大量扯皮时间。