五种 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 做的事比任务分发复杂。它维护依赖图，节点完成就检查哪些下游可以启动。完成的 agent 关掉，新 agent 需要时拉起来——跟管人一样，不能让干完活的人干等。还得区分什么才是真正的问题、什么只是并行工作不可避免的代价。五个 agent 同时干活，工作区有别人的未提交文件，hook 报警不意味着出事了。服务器掉线 Lead 自己也会断，但回来之后靠 git 状态重建进度。所有 Teammate 跑完之后统一 typecheck，跑一遍 test，有问题当场修。
第六篇里写过："你才是 Manager"。Agent Team 把这个角色拆成两层：我定义计划和验收标准，Lead 做项目经理，Teammate 执行。全程没看任何一个 agent 的具体代码，只在最后看了 typecheck 结果。