当多个 AI 编码 Agent 需要同时 PR：AWF 用 Docker 隔离工作空间让协作不再冲突
问题：AI Agent 多了，PR 也乱了
2026 年 6 月 16 日，一位独立开发者发布了 Agent Workspace Fabric（AWF）——一个用 FastAPI 写的控制平面，专门解决一个被很多人忽视的问题：当你的 AI 编码 Agent 从一个变成多个时，工程工作流就崩了。
如果你同时使用 Claude Code、Codex、Gemini CLI、OpenCode 甚至 Cursor 来推动多个开发任务，你一定遇到过以下场景：
- Agent A 的本地环境变量被 Agent B 覆盖，测试莫名失败
- 两个 Agent 同时修改同一个 git 工作目录，分支冲突无法处理
- Agent 提交的 PR 通过测试后，base 分支已经变了，CI 又红了
- 评审者在 PR 下留了 comment，Agent 不知道，需要你手动传达过去
- 失败了没法排查——日志散落在不同的终端窗口里
这不是个别问题，而是 多 Agent 并发的运维瓶颈。
痛点对比
| 维度 | 传统多 Agent 手动管理 | AWF 方案 |
|---|---|---|
| 工作空间隔离 | 共享本地 git 目录 | 每个任务独立 Docker Compose + git worktree |
| PR 创建与监控 | 手动提 PR，盯着 CI | 自动 PR + review comment 处理 + CI 修复 + auto-merge |
| Agent 类型 | 单一 Agent | Codex / Claude Code / Cursor / Gemini / OpenCode / Grok 适配器 |
| 项目环境配置 | 人工记忆 Docker 依赖 | Profile 驱动，每项目一套声明式配置 |
| 失败排查 | 翻终端日志 | 保留失败工作空间 + 结构化事件日志 |
快速上手：5 分钟跑通第一个模拟工作空间
AWF 目前是 alpha 阶段，支持本地 Core 模式。前提条件：Git、Docker、uv 或 pipx。
uv tool install agent-workspace-fabric pipx install agent-workspace-fabric awf setup awf start awf service status --format pretty
然后创建一个测试项目并跑通模拟烟雾测试：
mkdir -p ~/awf-eval-project awf init ~/awf-eval-project awf smoke run --project ~/awf-eval-project --mocked-local --format pretty
awf start 会拉起 FastAPI API 服务（127.0.0.1:8000）和 Operator Console 界面（127.0.0.1:3000），你可以直接看到每个工作空间的实时状态。
💡 AWF 唯一特殊的设计是：它不写代码。 它只负责给 Agent 创造可重复的工作空间——代码由 Agent 写，AWF 管生命周期。
核心功能：从提交到合并的全自动流水线
AWF 把一个编码任务转化为 16 步的声明式生命周期。以下是关键步骤：
1. 工作空间隔离
每个任务启动时，AWF 会做三件事：
- 从 base 分支创建一个独立的
git worktree - 生成该工作空间专属的
docker-compose.yml（内含 Agent 容器 + 可选的 Sidecar 服务） - 挂载代码仓库到
/workspace目录
这样两个 AWF 任务之间完全隔离——没有共享的 node_modules、没有冲突的环境变量、没有互相覆盖的 .git 状态。
2. Profile 驱动的项目感知
AWF 不硬编码项目结构。每个项目在 awf init 时生成一个 Workspace Profile，描述：
runtime:
agent_image: "python:3.12-slim"
toolchain:
- "jdk=17" # 声明 JDK 版本
services:
- postgres:16 # 测试需要的数据库
phases:
setup: ["pip install -r requirements.txt"]
validate: ["pytest --junitxml=results.xml"]
planning:
policy: "plan-execute-compare"
Profile 把「项目特有的知识」从编排代码里解耦出来。切换项目时只需一个新的 profile，控制平面代码不变。
3. 全自动 PR 生命周期
提交代码后，AWF 接管了整个 PR 流程：
- 提交并推送：生成 commit，push 到远端，开 PR
- Review 监视：自动处理 Reviewer 的 comment——收到修改请求就重新调用 Agent 改代码并推送
- CI 修复：CI 失败时读取 logs，重新调用 Agent 修复后重新推送
- Base 同步：当 base 分支推进时，自动 rebase PR 分支
- Grace 周期：尊重 Reviewer 的时间——初始 review 宽限期内不会 auto-merge
- Auto-merge：所有 gate 通过后自动合并
失败保留：成功的 workspace 自动清理，失败的保留现场供人工排查。
横向对比：工作空间编排的几种路径
| 工具/方案 | 核心思路 | 隔离级别 | PR 自动化 | 多 Agent |
|---|---|---|---|---|
| AWF | Docker Compose + git worktree 控制平面 | ⭐⭐⭐ Docker 级 | 全自动（review/CI/merge） | 6 种 Agent 适配器 |
| emDash ADE | 桌面 App 并行跑多个 Agent | ⭐⭐ 进程级 | 手动提 PR | Agent 无关 |
| RelayMux | tmux 会话复用 | ⭐ 共享文件系统 | 手动 | 终端代理 |
| 手写 CI 脚本 | GitHub Actions + 脚本 | ⭐⭐⭐ Docker 级 | 需自定义 | 需自行集成 |
AWF 的独特价值在于将「Docker 隔离」和「PR 全生命周期自动化」打包成一个声明式的 CLI/API 接口。它不是 IDE 插件，也不是聊天机器人——它是一个执行基底（execution substrate），位于 Planner 和 Agent 之间。
注意事项
- Alpha 阶段：当前仅支持本地 Core 模式，GKE 和多租户部署尚未实现
- 依赖 Docker：每个工作空间启动一套 Docker Compose 栈，资源开销取决于并发数
- Forge 认证：GitHub 需要
gh认证，Bitbucket 需要BITBUCKET_API_TOKEN - 不包含 Planning：AWF 是一个执行引擎，不负责任务规划——需要配合 Planner 或 MCP Client 使用
总结
AWF 解决的是一个被低估但越来越突出的问题：当 AI Agent 从一个人工玩具变成团队的生产力工具时，运维层面需要什么样的基础设施？ 它的答案很清晰——不是更好的 Agent，而是更好的工作空间编排。
对于已经在使用多个 AI 编码 Agent 的团队来说，AWF 提供了一个自托管的、开源的（Apache-2.0）解决方案，让多 Agent 并行开发不再是大厂的专利。
- GitHub：https://github.com/dimileeh/agent-workspace-fabric
- 90 秒演示视频：https://youtu.be/aOzBx2gY39k
- HN 讨论：https://news.ycombinator.com/item?id=48554898