一、问题引入：为什么“多个 Agent”不是简单多开几个窗口
这个视频把 Claude Code 里的 agent teams 当成一个协作系统来讲，而不是把它包装成“更聪明的聊天机器人”。开场演示很直接：作者只要求 Claude 为一个虚构 AI 初创公司 Neuroflow 搭建落地页，主会话创建了三个 teammate，分别承担前端、后端和 QA。前端与后端完成实现后，把结果交给 QA；QA 找出三个关键问题，主会话再把问题派回两个实现者修复，第二轮 QA 才给出通过结论。
这个例子真正有价值的地方，不是页面“一次生成得很漂亮”，而是它展示了一个团队式闭环：主会话负责调度，多个 teammate 并行做自己负责的产物，QA 独立审查，发现问题后再回流给实现者。相比普通 subagent，agent team 更像一个有共享任务列表、直接消息和生命周期管理的小型项目组。它适合拆解大型目标，但只有在任务可以被分工、并且每个队友有清晰交付物时才值得开启。
Agent team 的核心价值不是“多几个模型同时说话”，而是让主会话组织角色分工、交付物流转、审查与返工。
二、核心概念解释：orchestrator、teammate、共享任务与直接通信
主会话是 orchestrator，负责目标和秩序
视频里反复出现的角色是主会话，也就是用户正在对话的 Claude Code session。它不是要亲自完成所有实现，而是把目标翻译成团队配置、角色说明和任务分配。与一次性 subagent 不同，agent team 的 teammate 可以持续存在一段时间，围绕同一个目标持续更新状态、接收新指令、互相传递结果。
这意味着提示词必须先建立“团队为什么存在”。作者在示例 prompt 里先写目标：构建一个带 REST API、React 前端、用户与帖子功能、可在 localhost 运行的 full-stack app，并且最终要有 QA test report。这个目标会被主会话传递给 teammate，否则刚启动的 teammate 只知道自己的角色，却不知道为什么要和别人协作。
Teammate 不是普通角色扮演，而是有交付边界的工作者
一个有效 teammate 需要知道三件事：它负责什么文件或模块、它应该产出什么、它需要向谁发送什么信息。视频中的前端、后端、QA 分工非常典型：前端负责 UI 与交互，后端负责 API 和数据层，QA 负责独立验证并生成问题清单。每个 teammate 都可以调用可用工具，也会继承主会话的权限设置，所以工具权限和计划审批不能事后才想。
直接消息让团队减少“主会话中转”
作者展示了 researcher、strategist、critic 三个 teammate 的文档分析场景。Researcher 完成结构化 inventory 后，需要分别发送给 strategist 和 critic；主会话发现它可能只发给了其中一个，就追问是否已经发送给两边。这个细节说明 agent team 的协作不是所有信息都回到主会话再转发，teammate 可以彼此发送消息，但主会话仍然要监督交付链有没有断。
三、关键论点与实操步骤
先让 Claude 建立本地参考文档
作者建议把 agent teams 官方文档链接交给 Claude，让它在项目的 docs 目录里生成 master reference guide。这样后续创建队伍、解释 display mode、hooks、task management 或 plan approval 时，主会话不必每次重新联网查资料，项目里也留下了可复用的团队协作规范。
用自然语言定义团队形状
最小可用 prompt 通常是：“Create a team of X agents using X model”，然后逐个列出 teammate 的角色、职责、交付物、能否和谁通信、完成后应该把什么发给谁。重点不是写华丽的人设，而是把角色依赖关系讲清楚。
给每个 teammate 明确文件所有权
视频提醒，如果团队输出不够整体，常见原因是多个 teammate 在覆盖彼此工作。解决方式是预先指定 ownership：谁负责前端目录，谁负责 API，谁只能写测试报告。它们可以互相发消息，但不应该随意编辑同一份核心产物。
用 QA 或 critic 形成闭环
Agent team 最适合的不只是并行开发，也包括并行审查。视频里的 QA teammate 找出三个 critical issues 后，主会话把这些问题返还给前后端 teammate；第二轮才通过。这比“主会话自己看一眼”更接近真实工程团队的质量门禁。
计划先审批，再执行
作者提到 plan approval mode：可以要求 teammate 先提交计划，由主会话或指定 reviewer 批准后再执行。对于多文件改动、权限敏感命令或昂贵模型调用，这一步能显著减少失控执行和重复返工。
结束前要清理团队生命周期
视频结尾特别强调不要粗暴 kill team。主会话应向 teammate 发送 shutdown 或 finalize 消息，让它们确认工作已保存、报告已发送、没有“don't shut me down yet”的未完成状态。这个习惯能避免产物散落或上下文状态没收尾。
四、决策矩阵：什么时候用 agent team，什么时候不要用
| 任务场景 | 适配度 | 主要收益 | 风险 | 建议配置 |
|---|---|---|---|---|
| 全栈功能开发 | 高 | 前端、后端、QA 可并行推进，缺陷能回流修复。 | 多人编辑同一文件会互相覆盖。 | 指定目录 ownership，QA 只读或只写测试报告。 |
| 大型文档/资料分析 | 高 | Researcher、strategist、critic 可从不同角度提炼结论。 | 如果没有共享结构，输出会碎片化。 | 要求 researcher 产出 inventory，并发送给所有下游角色。 |
| 小型单文件修改 | 低 | 几乎没有并行收益。 | 额外成本和等待时间高于收益。 | 用主会话或普通 subagent 即可。 |
| 架构方案评审 | 中高 | 可让 builder、security reviewer、product reviewer 同时给意见。 | 如果没有最终裁决者，建议会互相冲突。 | 设置一个 lead 或主会话负责合并取舍。 |
| 高风险命令执行 | 谨慎 | 可用 planner/reviewer 先审计划。 | 权限会从主会话继承，误配置会放大风险。 | 开启 plan approval，预批准命令要窄，避免全权限。 |
判断标准很简单：如果任务不能拆出清晰角色、交付物和依赖关系，就不要为了“看起来像团队”而开启团队。
五、常见失败模式：团队失控通常不是模型问题
权限频繁打断
如果 teammate 每隔几秒就停下来请求权限，团队会失去并行优势。作者建议在项目或本地设置中预批准必要工具，但这不等于无限放权。更稳的方式是按角色给权限：研究员读文件和搜索，开发者写指定目录，QA 运行测试和读日志。
产物被覆盖
当两个 teammate 同时修改同一块代码时，最终产物可能显得不完整或前后矛盾。视频里的建议是指定 file owner，并要求 teammate 通过直接消息提出修改建议，而不是越权改别人的文件。这一点对前端/后端/QA 三角色尤其重要。
某个 teammate 空转
如果一个 teammate 只是等待，说明 prompt 没有给它明确 dependency 或独立任务。可以把团队计划写得更像项目分解：谁先产出 schema，谁基于 schema 写 API，谁等前两者完成后验收。没有依赖关系的角色会闲置，有太多交叉依赖的角色会互相阻塞。
成本和延迟过高
作者明确提醒 agent teams 更贵、更慢。只有当它能换来更高质量、更完整审查或真正并行时才值得。对低风险小任务，用一个主会话加计划模式通常更快；对复杂任务，可以让 team 先只做计划和风险评估，再决定是否执行。
六、时间戳目录
七、相关推荐
这节课适合接在 Claude Code subagent 和多 Agent 工作流之后看：先理解单个专家代理怎么工作，再理解多个代理如何带着交付物互相协作。继续学习时，建议优先比较“团队”与“子智能体”的边界，而不是把每个复杂任务都升级成 team。