A ─→ B ─→ C ─→ D

  ┌──→ A ──→ C ─┐
  │              ├──→ E
  └──→ B ──→ D ─┘

    ┌──→ Endpoint A
    │
DB ─┼──→ Endpoint B
    │
    └──→ Endpoint C

Team Code - 多智能体开发

Team Code 实现了 CAID（集中式异步隔离委派） 研究范式，用于协调多个AI智能体组成开发团队。

可以这样理解：不是让一个开发者独自处理复杂功能，而是让一个专家团队并行工作——每个专家在自己的独立工作空间中，由技术负责人（管理者）协调谁在什么时候做什么工作。

⚠️ 重要警告：

• - 从一开始就使用 Team Code — 不要先尝试单人模式。顺序尝试的成本几乎是两倍，收益却微乎其微。
• 物理分支隔离是强制性的 — 共享工作空间会导致静默冲突，破坏一切。
• 团队规模很重要 — 研究任务用2个智能体，清晰的代码库用4个，切勿超过8个。
• 更高成本，更好结果 — Team Code 提升准确率（+26%），而非速度。对重要代码值得投入。

类比：人类开发团队

人类团队	Team Code
技术负责人分配任务	管理者构建依赖图
开发者在分支上工作

智能体在git工作树中工作 | | 拉取请求进行审查 | 提交前自我验证 | | 作者解决合并冲突 | 智能体解决自己的冲突 | | 发布前进行代码审查 | 管理者最终审查 |

何时使用 Team Code

完美适用于：

• - 🏗️ 构建功能 涉及多个文件（认证、API、数据库）
• 🔄 复杂重构 具有清晰的依赖链
• 📚 从头实现库 包含测试套件
• 🔬 研究复现（论文实现）

跳过的情况：

• - 🔧 单行修复或单文件更改
• 🧪 纯探索，没有清晰结构
• ⏱️ 快速原型，足够好即可

工作流程

阶段0：设置（管理者 = 你）

在团队开始之前，准备环境：

bash
cd your-project

确保依赖项正常工作

pip install -r requirements.txt # 或 npm install 等

创建最小存根，使导入不会失败

mkdir -p src/feature touch src/feature/init.py src/feature/modulea.py src/feature/moduleb.py

提交，让团队从已知状态开始

git add . git commit -m setup: initial feature structure

阶段1：规划（依赖图）

分析需要构建的内容及其顺序：

你的任务：添加用户认证

依赖关系：
database.py ─→ models.py ─→ auth.py ─→ api.py
(无) (需要db) (需要 (需要
models) auth)

第1轮：database.py（基础）
第2轮：models.py（依赖db）
第3轮：auth.py（依赖models）
第4轮：api.py（依赖auth）

阶段2：委派给智能体

javascript
// 智能体1：数据库（无依赖）
await sessions_spawn({
runtime: subagent,
task:
在 src/feature/database.py 中实现数据库连接
- connect() 函数
- 连接池
- 错误处理

验证：pytest tests/test_database.py -v
限制：src/feature/init.py
,
agentId: coding-agent,
mode: run,
runTimeoutSeconds: 400
});

javascript
// 智能体2：模型（数据库完成后）
await sessions_spawn({
runtime: subagent,
task:
在 src/feature/models.py 中实现 User 模型
- 使用 SQLAlchemy 的 User 类
- 字段：id, username, email, password_hash
- 方法：setpassword(), checkpassword()

依赖：database 模块（已完成）
验证：pytest tests/test_models.py -v
限制：src/feature/init.py, src/feature/database.py
,
agentId: coding-agent,
mode: run,
runTimeoutSeconds: 400
});

阶段3：集成

bash

当智能体发出完成信号时

git checkout main
git merge feature/database

如果有冲突 - 创建冲突的智能体解决：

cd ../workspace-database git pull origin main

修复冲突

pytest tests/test_database.py -v git commit --amend

阶段4：最终审查

bash

所有轮次完成后

git checkout main
pytest tests/ -v # 完整测试套件
python -c from src.feature import auth; print(OK) # 冒烟测试

团队规模指南

任务类型	团队规模	原因
研究/论文复现	2	复杂依赖，管理者负担重
库实现

4 | 清晰的文件结构，可并行化 | | API + 前端功能 | 2-3 | 前端/后端并行 | | 简单的多文件重构 | 2 | 并行性有限 | | 切勿超过 | 8 | 协调成本超过收益 |

关键原则

1. 分支隔离是强制性的

bash

正确：物理隔离

git worktree add ../workspace-agent-1 feature/task-1
git worktree add ../workspace-agent-2 feature/task-2

错误：软隔离（导致冲突）

所有智能体在同一个目录中，不要碰彼此的文件

2. 提交前自我验证

智能体必须在提交前运行测试并修复失败：

bash
pytest tests/testmymodule.py -v # 必须通过
git commit -m implement: feature X # 然后才提交

3. 仅限结构化通信

使用JSON任务规范，而不是对话：

json
{
task_id: implement-auth,
description: JWT认证,
files: [src/auth/jwt.py],
verify: pytest tests/test_jwt.py -v,
restricted: [src/auth/init.py]
}

4. 智能体解决自己的冲突

如果合并失败，编写代码的智能体修复它——而不是管理者。

常见模式

模式：顺序依赖

A ─→ B ─→ C ─→ D

启动1个智能体，完成后启动下一个。不是并行但结构清晰。

模式：并行基础

┌──→ A ──→ C ─┐
│ ├──→ E
└──→ B ──→ D ─┘

A和B并行，然后C和D并行，然后E。

模式：星型（常见API结构）

┌──→ 端点 A
│
DB ─┼──→ 端点 B
│
└──→ 端点 C

数据库优先，然后所有端点并行。

权衡

方面	单智能体	Team Code
速度	更快的实际时间	相似/更慢
准确率

42-57% | 59-68%（+14-26%） | | 成本 | 较低 | 较高 | | 最适合 | 快速修复 | 重要代码 |

经验法则： 如果这个任务你会分配给人类团队，就使用 Team Code。

快速启动模板

javascript
// 1. 设置你的项目
cd my-project
git checkout -b feature/xyz

// 2. 创建存根
touch src/module.py
git add . && git commit -m setup: stubs

// 3. 规划依赖
// 绘制：什么依赖什么？

// 4. 启动第一个智能体（基础）
const agent1 = await sessions_spawn({
runtime: subagent,
task: 实现基础：src/core.py 包含...,
mode: run,
timeoutSeconds: 400
});

// 5. 等待，集成，重复
await waitFor(agent1);
git merge feature/core;

// 6. 启动依赖智能体...

// 7. 最终审查
git checkout main
pytest tests/ -v

参考资料

• - 研究论文：Effective Strategies for Asynchronous Software Engineering Agents (arXiv:2603.21489v1)
• 原始名称：CAID（集中式异步隔离委派）
• GitHub：https://github.com/JiayiGeng/async-swe-agents

详细实现示例请参见 references/examples.md。