五个 AI 同时干活是什么体验
五个 AI 队友协同工作
十几个文件，一个人根本写不过来
Mio 是我在做的一个 AI 伴侣 Telegram Bot——五个不同性格的 AI 角色，每个都有自己的人格配置文件、记忆系统和对话风格。功能已经跑起来了，但三个大模块一直没做：多模态输入（语音、图片、视频）、增强版 Onboarding（角色预览、自定义故事、用户画像采集）、自拍生成。
三个模块加起来，涉及数据库迁移、新的 media 处理模块、Telegram 文件下载、五个角色的配置更新、onboarding 流程重写、system prompt 改造、selfie 生成管道——横跨三层架构、十几个文件。
以前的话，我会花半天拆任务，然后一个一个写。或者把计划扔给 Claude Code 让一个 agent 串行干——但十个任务串行下来，上下文窗口肯定撑不住。
这次我用了 Claude Code 的 Agent Team。
Agent Team 是什么
简单说：一个 Lead agent 负责协调，多个 Teammate agent 并行干活。每个 Teammate 是一个独立的 Claude 实例，有自己的上下文窗口、能读写文件、能发消息汇报进度。
核心机制：
- TaskCreate / TaskUpdate：创建任务、设依赖关系、追踪状态
- TeamCreate：启动 Teammate agent，分配任务
- SendMessage：Lead 和 Teammate 之间的消息通道
- 文件所有权：每个 Teammate 只编辑分配给它的文件，不碰别人的
不是"把大任务拆小然后顺序执行"——而是真正的并行。五个 agent 同时写代码，各自 commit，Lead 在中间协调依赖和调度。
十个任务，三批执行
我给 Claude Code 的输入是一份完整的实现计划——三个 Step、九个子步骤、带依赖关系的实现顺序表。Claude Code 先花两分钟探索了一遍代码库，然后把计划拆成了十个任务：
| # | 任务 | 依赖 |
|---|---|---|
| 1 | 数据库迁移（aboutUser, customStory 字段） | — |
| 2 | Media 处理模块（transcribe, vision, process） | — |
| 3 | Telegram 文件下载工具 | — |
| 4 | 接入 media 管道到 server | 2, 3 |
| 5 | 角色摘要 + 自定义故事 + UI | — |
| 6 | Onboarding 增强（故事流、用户画像采集） | 1 |
| 7 | aboutUser/customStory 注入 system prompt | 6 |
| 8 | /reonboard 支持切换角色 | 5, 6 |
| 9 | Selfie 生成模块 | — |
| 10 | Selfie 触发接入 | 9 |
关键在依赖关系。1、2、3、5、9 是独立的——可以同时开始。4 要等 2 和 3 都完成。6 要等 1。7 要等 6。8 要等 5 和 6。10 要等 9。
一个典型的 DAG（有向无环图），Claude Code 自动识别出了三批并行执行的任务。
五个 Agent，同时开工
第一波，五个 agent 同时启动：
5 agents launched
├─ @schema-migrator → #1 DB migration
├─ @media-builder → #2 Media module
├─ @file-downloader → #3 Telegram file download
├─ @preset-designer → #5 Preset summaries + UI
└─ @selfie-builder → #9 Selfie module
每个 agent 拿到的任务描述里包含：要创建/修改哪些文件、参考哪些现有代码、具体的实现规格。更关键的是——每个 agent 只被允许编辑特定的文件。schema-migrator 只碰 schema.ts，media-builder 只碰 media/ 目录下的文件。
文件所有权是防止冲突的核心机制。
Lead 的显示面板实时更新：
┌─────────────────┬──────────────────────────────────────┬─────────┐
│ Agent │ Task │ Status │
├─────────────────┼──────────────────────────────────────┼─────────┤
│ schema-migrator │ #1 - DB migration │ Running │
│ media-builder │ #2 - Media module │ Running │
│ file-downloader │ #3 - Telegram file download │ Running │
│ preset-designer │ #5 - Preset summaries + UI │ Running │
│ selfie-builder │ #9 - Selfie module │ Running │
└─────────────────┴──────────────────────────────────────┴─────────┘
Lead 不只是派活的
接下来发生的事情让我开始理解"Lead"到底在干嘛。
依赖解除，立刻调度
第一个完成的是 file-downloader——任务简单，一个文件搞定。然后 schema-migrator 完成了。
这一刻 Lead 做了一个关键判断：#1 完成了，意味着 #6（onboarding 增强）的依赖解除了。它立刻启动了第六个 agent：
● Task #1 done. That unblocks #6. Spawning onboarding-enhancer now.
不需要我干预。Lead 持续追踪依赖图，每当一个任务完成，它就检查哪些被阻塞的任务现在可以开始了。
然后 selfie-builder 完成了 #9，Lead 立刻启动 selfie-wirer 做 #10。media-builder 完成了 #2，加上之前已完成的 #3，Lead 启动 media-wirer 做 #4。
整个过程三波推进：
- 第一波（并行）：#1, #2, #3, #5, #9 → 5 个 agent
- 第二波（依赖解除后）：#4, #6, #10 → 3 个 agent
- 第三波（依赖解除后）：#7, #8 → 2 个 agent
并行的代价：噪声
并行不是没有代价的。
这个项目配了 Git hooks——如果一个 agent 空闲但工作目录有未提交的文件，hook 会触发警告。问题是：五个 agent 同时在写代码，每个 agent 只提交了自己的文件，但其他 agent 的未提交文件也在工作目录里。
hook 开始对已完成的 agent 反复报警：
@file-downloader❯ Hook blocks me — uncommitted files belong to other teammates
@schema-migrator❯ Idle — uncommitted files belong to other teammates
Lead 的判断：这是误报。它没有让 agent 去提交不属于自己的文件，也没有关掉 hook——而是识别出"并行工作产生的预期噪声"，选择忽略并继续等待活跃 agent 完成。
服务器掉线，Teammate 自己干完了
会话中间出了一件有意思的事：OAuth token 过期了，服务器断连。
❯ continue on this task, server was down
⎿ API Error: 401 — OAuth token has expired
重新登录之后，Lead 做的第一件事是 git status 和 git log。它发现工作目录是干净的——说明在服务器掉线期间，最后两个 agent（prompt-wirer 和 reonboard-builder）已经自行完成并提交了。
这是 Agent Team 一个很有意思的属性：Teammate 是独立运行的。 它们不依赖 Lead 的轮询或确认来完成工作。Lead 掉线了，Teammate 继续干。等 Lead 回来，活已经干完了。
最终整合
十个任务全部完成后，Lead 做了收尾：
- Typecheck — 运行
pnpm typecheck，发现两个 TS18048 错误（ctx.callbackQuery可能为 undefined），直接修复 - Test — 运行
pnpm test，确认没有新的测试失败 - 代码审查 — 检查所有新文件是否存在、导出是否正确
- 文档更新 — 又启动了两个 subagent 并行更新文档和 TODO
最终产出：
┌─────┬──────────────────────────────────────┬────────────────────┐
│ # │ Task │ Commits │
├─────┼──────────────────────────────────────┼────────────────────┤
│ 1 │ Schema migration │ 10aa550 │
│ 2 │ Media module │ 8aec253, b39551b │
│ 3 │ Telegram file download │ f243f20 │
│ 4 │ Wire media pipeline │ 620829d │
│ 5 │ Preset summaries + backstories │ 3733f3b, e8903da │
│ 6 │ Onboarding enhancements │ bd148cc, 90da519 │
│ 7 │ System prompt wiring │ 0f94c71 │
│ 8 │ Reonboard with preset switch │ 3d15317, af668b4 │
│ 9 │ Selfie module │ b749684 │
│ 10 │ Selfie trigger wiring │ 387c378, b02f291 │
└─────┴──────────────────────────────────────┴────────────────────┘
十个任务，十几个文件，三层架构，一个会话。
什么时候该用 Team，什么时候不该
用了几次之后，我的判断标准：
用 Team：
- 有 3 个以上可以并行的独立子任务，且任务之间有明确的依赖 DAG
- 涉及 3 个以上不同目录或模块的文件修改
- 单个 agent 的上下文窗口不够完成全部任务
别用 Team：
- 改动集中在 1-2 个文件——直接编辑就行
- 任务完全串行、没有并行空间——用 subagent 即可
- 需要深度上下文理解（比如仿真调试那种反复迭代）——Team 的每个 agent 上下文是隔离的，无法共享调试状态
Team 最大的优势不是速度（虽然并行确实快），而是上下文隔离。每个 agent 只需要理解自己负责的那片代码，不需要把十几个文件全读进上下文。Lead 只需要理解依赖关系和最终接口，不需要理解每个文件的实现细节。
这和管理人类团队是一样的道理：好的分工不是为了让每个人干得更快，而是为了让每个人只需要关心自己的部分。
Lead 像一个项目经理
回看这次实战，印象最深的是 Lead 的行为模式。
它不是一个简单的任务分发器。它在做的事情是：
- 依赖追踪：维护一张 DAG，每完成一个节点就检查哪些下游可以启动
- 资源调度：完成的 agent 被关闭，新的 agent 在需要时启动
- 冲突识别：区分"真正的问题"和"并行工作的预期噪声"
- 断点恢复：服务器掉线后，通过 git 状态重建进度
- 最终整合：所有 Teammate 完成后，做一轮统一的 typecheck、test 和修复
这些不是写代码的技能。这是项目管理的技能。
我在第六篇里写过："你才是 Manager"。Agent Team 让这个角色分成了两层：我是 Manager 的 Manager——我定义计划和验收标准，Lead 是项目经理，Teammate 是执行者。
我全程没有审查任何一个 agent 的具体代码，只在最后看了 typecheck 结果。
这是一种新的工作方式。不是"人+AI"的一对一协作，而是"人 → Lead → Teammates"的分层协调。人的判断在最上层——定义做什么、做到什么程度。AI 负责从拆解到执行到整合的全部中间层。
一个计划，十个任务，五个 AI，三波调度。