多AI编程助手管理实战：Worktree Control开源工具

当开发者订阅了多个AI编程助手（如Codex、Claude Code）并尝试并行运行多个代理时，资源冲突、上下文丢失和验证混乱等问题会迅速浮现。本文作者通过构建开源工具Worktree Control，将“订阅最大化”的初衷演变为一套多代理调度系统。以下基于其经验，拆解多代理协作的核心挑战与解决方案。

多AI编程助手管理

从简单任务到多代理困局

起初，作者仅用Codex处理孤立的小任务：写函数、补测试、修复缺陷。随着模型能力提升，他开始委托更大块的工作，但会话限制让他思考：能否让代理在睡眠时继续工作？能否从待办列表自动领取任务？这种“团队协作”的错觉很快带来管理负担——他成了自己口中的“微观管理者”。

增加第二个订阅后的混乱

朋友推荐Claude后，作者并行使用多个编程客户端。他用T3 Code管理跨客户端会话，但共享的待办列表仍靠Git仓库中的JSON和Markdown文件维护。分支和工作树导致每个代理拥有各自的待办版本，同步变得棘手：一个对话中的决策难以被另一个代理直接复用。更换模型容易，保持项目上下文一致却困难重重。

Git 工作树（worktree） 是 Git 提供的一种机制，允许在同一个仓库上同时检出多个分支到不同目录，而无需克隆多份仓库。每个工作树拥有独立的工作区和索引，但共享同一份 .git 对象数据库。在多代理场景下，这意味着每个代理可以拥有自己的分支和工作目录，互不干扰地并行修改代码。然而，共享的待办列表若以普通文件形式存在于仓库中，就会随工作树检出而产生多个副本，各代理的修改无法自动合并，导致决策和状态分散。理解这一点，就能明白作者为何需要独立的调度与知识管理模块，而非仅依赖仓库内文件同步。

硬件资源与并发控制的挑战

作者在一台6核、18GiB内存的Linux开发机上同时运行五个线程、四个开发服务器和两个端到端测试。每个代理都有理由启动自己的进程，但机器资源有限。内存限制虽能约束用量，却无法决定哪个开发服务器该运行、哪个测试该等待。作者回想起学生时代的信号量概念，决定构建Worktree Control来集中调度。

端口、预留与队列机制

Worktree Control的核心设计简单：限制同时运行的托管开发服务器数量，每个项目分配一个稳定端口，代理可在工作树间切换。代理使用前需“认领”项目，完成后释放。作者作为“最重要的代理”可通过仪表板锁定项目，阻止其他代理抢占。释放认领不会停止服务器，因此空闲预留不等于空闲槽位。

构建与测试走独立队列，限制并发运行数，且每个工作树最多一个活跃检查。提交测试不会切换开发服务器；需要浏览器的测试仍需认领服务器。若其他代理持有认领，测试必须等待；启动已停止的服务器也受服务器数量限制。这种区分在共享测试夹具的项目中至关重要——重置数据库必须在队列任务内完成，否则会干扰正在运行的测试。

控制器还显示资源使用和工作树磁盘占用，可清理已停止且未锁定工作树的Next.js缓存。但规则仅在代理使用控制器时生效，无法阻止无关终端启动额外服务器，因此工作流也写入项目代理指令。

信号量（semaphore） 是并发编程中的同步原语，用于控制对有限数量资源的访问。它维护一个计数器，线程在获取资源前执行 P（等待）操作使计数减一，释放时执行 V（通知）操作使计数加一；当计数为零时，后续获取者被阻塞，直到有资源被释放。Worktree Control 将这一思想从进程内扩展到多代理、多进程的调度层面：开发服务器槽位、测试队列并发数都相当于信号量保护的资源，代理必须显式认领和释放，从而把“谁先用、谁等待”从隐式竞争变为可审计的显式协议。

验证证据：测试到底跑了什么？

“测试通过”听起来安心，但作者想知道：哪个工作树？什么命令？测试入队后代码是否变更？结果是否仍适用于当前代码？

Worktree Control在运行前后记录Git观察值，将命令结果与来源证据分开保存。成功命令不自动意味着当前修订已验证。结果会记录提交哈希、工作树是否脏、变更路径的Git状态摘要，若运行前后HEAD变化则标记。局限在于本地检查使用工作树文件（含未提交更改），并非不可变快照，Git观察也无法捕获所有环境依赖。但比聊天中的口头保证更可审查。

测试队列与来源证据

Git 观察值（Git observation） 指在命令运行前后采集的仓库状态快照，通常包括当前 HEAD 提交哈希、工作树是否包含未提交更改、变更文件的路径与状态摘要等。它的作用是把一次测试结果与产生该结果的代码状态绑定起来。若运行前后 HEAD 发生变化，说明代码在测试期间被修改，结果的可信度下降。需要区分的是，本地工作树检查使用的是包含未提交更改的文件内容，并非不可变快照，因此观察值只能提供可审查的关联证据，不能替代在干净快照上进行的确定性验证。

知识库：跨会话的上下文延续

服务器和测试队列受控后，工作本身仍需存放之处。作者在Worktree Control中加入Knowledge模块，保存待办、讨论和项目记忆。任务可链接到来源讨论，决策保留来源和修订历史，保存记忆条目与批准为独立操作。

作者可在仪表板读写记录，代理通过MCP或CLI访问。不同会话因此有共同查找点，即使更换编程客户端也不受影响。交接时，任务的“下次会话上下文”会收集关联记忆和来源修订，下一个代理仍需阅读理解，但信息有了安身之处。

MCP（Model Context Protocol） 是一种开放协议，用于让 AI 应用以标准化方式连接外部工具和数据源。它定义了客户端与服务器之间的通信接口，使模型能够发现并调用工具、读取资源，而无需为每个客户端单独编写集成代码。在本文场景中，Worktree Control 通过 MCP 对外暴露知识库的读写能力，不同编程客户端（Codex、Claude Code、OpenCode 等）只要支持 MCP，就能以一致的方式访问共享的待办、讨论和项目记忆，从而降低跨客户端切换时的上下文丢失。

当前运行配置与开放问题

作者目前运行一台Linux开发机，使用Codex、Claude Code、OpenCode，配合T3 Code远程访问，n8n处理PR评审自动化，Worktree Control管理开发服务器、检查队列和共享上下文。控制器为单个Node.js进程，使用SQLite和浏览器仪表板，Next.js UI导出为静态文件，无需额外常驻服务器。项目仍处于pre-1.0阶段，将验证分发到独立工作节点仍在开发中。

作者仍在摸索委托的边界。让每个代理忙碌容易误认为进展，他更希望能回顾任务时看到：改了什么、检查了什么、还有哪些需要关注。Worktree Control已在GitHub开源，作者好奇其他多代理用户如何处理上下文存放和开发服务器使用权问题。