像管理开发者一样管理AI编程Agent：yolobox深度指南

当一个Agent不再够用时，才是真正的开始。

AI编程Agent已经足够强大，可以帮你写代码、修Bug、做重构。但当你尝试同时运行多个Agent时，一切开始崩塌——Git冲突、Docker容器互相践踏、文件系统乱成一锅粥。

本文是Finbarr Taylor的深度实践，介绍如何用yolobox将AI编程Agent当作真实开发者来对待：给每个Agent一个完整的工作目录、独立的运行时环境、自己的Git分支和独立的URL访问入口。

背景：单个Agent的困境

几个月前，我创建了yolobox，起因是我不敢把Claude Code放进我的主目录。

问题很简单：AI编程Agent最大的价值在于让你放手让它执行命令，不需要每次都问"你能帮我做这个吗"。但这也是它最可能出问题的时候——Agent可能误读指令，决定最干净的方案是rm -rf *，然后你的笔记本电脑就变成了一个"学习经历"。

解决方案是把Agent关进一个容器里：

• 项目挂载到容器的真实路径
• 容器内有sudo权限
• 主目录完全不挂载进去
• Agent可以"全力输出"，你的配置文件纹丝不动

这解决了一个人的问题。但当你想要同时运行多个Agent时，新的问题出现了。

单Agent工作流的伸缩困境

当你想要同时委派两件事时，麻烦就来了。

一个Agent去重构API，一个去修测试，一个去研究Docker问题，一个自信地把前端改坏了——这个过程看起来很美好。但实际上，我们只是把整个团队塞进了同一把椅子、同一块键盘、同一个文件夹里，然后惊讶于为什么它变成了一场"电话亭里的叉子大战"。

当你真的尝试并行运行多个Agent时，三个东西会首先崩溃：

1. Git崩溃

两个Agent修改同一个仓库的不同分支，会让你重新发现为什么人类发明了分支、代码审查和被动攻击性沟通（passive aggression）。

2. 文件系统崩溃

Agent会写入缓存、构建产物、lock文件、生成的代码、.env假设、SQLite数据库、截图、测试输出，以及你的项目晃动时留下的各种奇怪东西。这些东西都不在git status里，却会踩在另一个Agent正在做的事情上。

3. Docker Compose崩溃（最严重）

如果你的项目运行一个Web应用，每个Agent都想要相同的端口、相同的容器名、相同的网络和相同的命名卷。突然间，你的"并行"编程设置变成了三个Agent礼貌地互相谋杀对方的Postgres容器。

Git Worktree：技术上正确，最危险的正确

这时你可能想到：“用Git Worktree啊。”

这也是问题开始泄露的临界点。

Worktree技术上能解决问题。它是"我不想重新clone的情况下，在不同分支获得第二个仓库checkout"的正确答案。

但这不是真正的问题所在。

一个worktree共享一个.git，但不共享：

• node_modules
• 构建产物
• 你的dev server写入的SQLite文件
• 你三年来精心不提交的.env
• Compose在周二启动的运行中的Postgres容器

它也不是"共享"这些——它就是没有这些。每个新的worktree都是一个干净的checkout，在Agent的工具能工作之前需要手动"补水"。

所以让一个worktree对Agent可用的工作变成了：

1. clone env文件
2. 重新安装依赖
3. 重建重要的缓存
4. 用不同的项目名重启Compose，这样不会和原始的冲突
5. 希望代码库里没有硬编码路径

这些都不是不可能完成的。但都是仪式感（ceremony），而且是错误的层次——Git被要求去建模"另一台开发者的机器"，而它只会建模"另一个分支"。

有用的虚构：Agent就是开发者

真正想要的命令是这样的：

yolobox fork --name alice codex
yolobox fork --name bob claude
yolobox fork --name carol codex

关键是--name后面跟的不是功能名。不是--name new-billing-flow，而是像alice、bob、carol这样的名字。

这些不是分支。这些是人。

Alice有自己的文件夹。Bob有自己的文件夹。Carol有自己的文件夹，而且出于某种原因，她重建了六次node_modules。我们爱Carol。Carol在努力。

核心机制：完整拷贝而非干净checkout

每个fork都是当前项目文件夹的完整拷贝。

不是干净的Git checkout。不是聪明的过滤视图。不是"这个工具认为重要的所有文件"。而是整个文件夹——.git、.env、被忽略的文件、未跟踪的文件、node_modules、本地缓存、生成的垃圾、那个你不敢删除的奇怪的tmp/目录。所有东西。

这是粗糙的。粗糙是被低估的。

完整拷贝给Agent提供了项目实际运行的、相同的混乱现实——对于本地开发来说，这本身就是产品的大部分。拷贝位于../.yolobox-forks/<folder>/<name>（宿主机上），在容器内部yolobox把它挂载到原始的source路径，所以任何路径相关的东西——Agent自己的会话历史、构建脚本中的硬编码绝对路径、IDE状态——都能继续正常工作。

yolobox还为每个fork导出一组环境变量：

最后这个COMPOSE_PROJECT_NAME就是阻止Alice的Postgres容器谋杀Bob的Postgres容器的东西。

fork的生命周期命令：

# 创建fork
yolobox fork --name alice codex

# 恢复已存在的fork
yolobox fork resume alice codex

# 丢弃fork（强制删除）
yolobox fork discard alice --force

运行时隔离：每个Agent自己的Compose命名空间

仓库只是问题的一半。

如果每个Agent都在搞Web应用，它们也需要自己的运行时。否则一个Agent的docker compose up会变成另一个Agent的故障。

这就是每个fork的COMPOSE_PROJECT_NAME的作用。Compose用这个key来命名空间它拥有的所有东西——容器、网络、命名卷——所以Alice得到自己的Postgres卷，Bob得到自己的Postgres卷，Carol得到自己的Postgres卷（里面装满了令人困惑的测试数据），没人需要关心别人。

退出时的清理：

# yolobox会自动运行（如果发现Compose文件）
docker compose -p "$COMPOSE_PROJECT_NAME" down --volumes --remove-orphans

这样运行时清理自己，同时拷贝的文件夹保持原样供检查或恢复。

这不完美。硬编码的宿主机端口、显式的container_name指令、外部网络和绝对bind挂载仍然可能冲突。但这些变成了你能看到并修复的例外，而不是世界的默认状态。

Web应用的URL问题：不要端口表格

一旦你有了多个运行Web应用的Agent，端口就成了下一个税。

Alice想要5173。Bob想要5173。Carol想要5173、3001、5432，还有你的灵魂。

你当然可以用随机宿主机端口解决，但然后你就要把docker compose ps读成洞穴铭文：

0.0.0.0:58423->5173/tcp
0.0.0.0:58424->3001/tcp

不。

文明的版本是这样的本地反向代理：

https://alice.myapp.localhost
https://alice-api.myapp.localhost

https://bob.myapp.localhost
https://bob-api.myapp.localhost

一个共享的宿主机端Traefik或Caddy在:80/:443。每个fork的随机宿主机端口。共享的外部代理网络。从YOLOBOX_FORK_NAME派生出的友好名字。.localhost所以DNS不是问题。mkcert所以本地HTTPS能工作，浏览器不会像个罪犯一样对你吼。

用户看到的URL来自开发者名字，不是Compose项目哈希，也不是随机端口。Alice得到Alice的URL。Bob得到Bob的URL。哪天你走到同事桌前问"你的URL是啥来着"的时候，Agent做同样的事情你也不会退缩。

为什么完整拷贝胜过所有聪明的替代方案

比"拷贝整个文件夹"更优雅的设计是存在的。

你可以用worktree、稀疏checkout、rsync加排除依赖、一个overlay文件系统（让你短暂地像个内核工程师然后毁掉你的下午）。

其中一些可能对某些团队更好。但无聊的完整拷贝方法有三个特性，迄今为止胜过了我尝试过的每个聪明替代方案：

1. 保留项目运行所需的精确本地状态

包括那些不在版本控制中、你已停止想起的 parts。

2. 在容器内部把拷贝挂载到原始路径

所以任何路径相关的东西——Agent会话历史、构建脚本、IDE状态——都能继续工作而无需转换。

3. 心理模型显而易见

不需要在脑子里hold一个新的抽象。每个fork就是另一台开发者的机器。

这就是整个API。

磁盘使用不是免费的。拷贝大型仓库带依赖需要时间。如果你的项目带着40GB本地垃圾，你就会亲自学到这个事实。但存储便宜，而我对本地开发仪式感的耐心不便宜。

实战一天的样子

实际上工作流程收敛成这样的东西：

几个命名的fork同时打开，每个在各自的终端tab里，每个在浏览器里pin了友好的URL。

• 一个从堆栈跟踪中调查Bug
• 一个在flag后面原型化功能
• 一个在磨我本人不会自愿做的重构
• 一个在运行我一直想修的测试套件

它们提交并push到分支，我用和审查人类pull request相同的方式审查。合并冲突是正常的合并冲突。CI反馈是正常的CI反馈。审查是正常的审查。

四个fork并排运行。每个有自己的checkout、自己的Compose项目、自己的路由器pin的URL。

浏览器侧也是同样的fork——每个通过Traefik在单独的.localhost子域上。

让我惊讶的是：大部分摩擦是协调摩擦，不是能力摩擦。Agent已经足够好能做这个工作了。缺少的是无聊的基础设施——让多于一个Agent同时工作而不互相踩脚的无聊基础设施。

这只是教程关卡

一个人监督一个终端Agent在一个checkout里不是最终形态。这只是教程关卡。

下一步是小团队：

• 一个Agent调查
• 一个Agent实现
• 一个Agent写测试
• 一个Agent审查
• 一个Agent尝试让你紧张的那个迁移，在你可以删除而不产生小情绪的环境中

要这能工作，Agent需要和人类一样的东西：自己的workspace、自己的运行时、发布工作的方式、检查运行内容的方式、在变奇怪时删除整个东西的方式。这些都不是有趣的研究问题。它们是我们已经为人类开发者解决的操作性问题——分支、远程、隔离的开发环境、preview URL、代码审查。

让Agent更有用，原来需要把Agent不那么当作神奇的自动补全，而更多地当作带着笔记本电脑的初级开发者。

给它一张桌子。 给它一个clone。 给它自己的Compose命名空间。 然后让它像所有人一样push一个分支。

总结

并行性需要隔离。没有隔离，你没有四个Agent——你只有一个非常困惑的有四个终端的Agent。

只有当代码库和运行时随着Agent数量一起翻倍时，工作流程才开始工作。

原文：Treat Your Coding Agents Like Developers by Finbarr Taylor，2026年5月5日