一个 lead 协调、多个独立 session 并行作业、彼此直接通信。本报告拆解架构、与 subagent 逐项对比、给出绿/黄/红决策框架，并落到你的内容 pipeline 上。
核心是一个 lead（你直接对话的主 session），负责拆解、分派、综合，但不亲自写代码。它 spawn 的每个 teammate 都是完整、独立的 Claude Code 实例——自己的 context window（上限 1M token）、自己的指令、甚至自己的终端 pane。teammate 之间不共享上下文，全靠两条显式通道协调。
状态文件落在本地 ~/.claude/teams/ 与 ~/.claude/tasks/，自动维护、别手改。显示模式有 in-process（都在主终端）和 split-pane（各自窗格，需 tmux/iTerm2）。注意：teammate 不继承 lead 的模型，需单独指定（可全设 Sonnet 省钱）。
两者都能并行，但解决的不是同一个问题。Subagent 的本质是上下文卫生——把噪音隔离在外，保持主对话干净；Team 的本质是协同编排——让多个不被污染的判断互相通信。一句话判据：你的 worker 们需要彼此对话吗？
.claude/agents/ 下的 markdown，按 description 自动委派如果你正在跑并行 subagent，但开始撞 context 上限，或者 subagent 们需要看到彼此的发现才能做对——那就是从 subagent 升级到 agent team 的时机。反过来，team「比在一个 session 内协调更重、更贵」。
同一个决策的快速查表。左蓝右绿，蓝便宜简单、绿强大但贵。
需要「干净的隔离」选 Subagent；需要「会对话的协作」选 Agent Team。找不出至少 3 条真正独立的并行工作流，就别上 team。
核心始终是：协调开销，是否小于并行省下的时间？
/batch 或 async 更简单。没有固定价格，随 teammate 数量和工作量线性放大。反直觉点：并行不减少 token，而是把它乘起来——倍数在任何实际工作开始前就产生了。
典型 3 人 team 处理同任务的量级。4 人加载同一份项目上下文，初始化成本就是 4×，之后每条 agent 间消息还是一次计费往返。
多数工作流从 3 人最平衡。token 线性增长，但协调开销增长更快。三个角色清晰的 agent 持续优于五个范围模糊的。每人 5–6 个任务保持高产又不过度切换。
超 5 人需明确理由——只有确有并行工作流在等，才加人。
大规模 pipeline（10+ worker）下，subagent 的 orchestrator 会把所有结果累积进自己 context、轻松冲到 30–50k token 甚至撞上限。而 team 里没有单一 agent 背负全局历史，每人只加载自己那块——临界点在于：协调开销 vs. context 溢出，谁更贵。
你的 topic scout → 全文抓取 → 脚本合成是一条顺序、阶段间有依赖的流水线。诚实说：端到端用 team 大概率红灯——阶段必须串行。但单个阶段内部有几处是漂亮的绿灯。
多源（HN / Medium / RSS）抓取打分天然并行：一人负责时效筛选、一人评"复盘叙事潜力"、一人唱反调挑"是不是已被做烂"。三个隔离 context 给三份不被锚定的独立判断。
✓ 绿灯 · Agent Team（research/review 最佳入门）对 N 个 URL 做同构、独立、无需通信的批处理。worker 间无对话需求——上 team 黄偏红。用 /batch 或 subagent 扇出更简省，自动隔离。
合成是收敛性单点创作，强行多 agent 会因同文件、强耦合打架。但前面可挂一个 team：reviewer 分别从"事实核查 / 叙事节奏 / 钩子强度"三个独立 lens 审稿。合成本身留给单 session。
→ 合成单 session · 评审可用 Team 多 lens总结：team 用在"需要多个不被污染的独立判断"的节点（选题、审稿），串行流水线留给单 session + subagent 扇出。你在盯 token 配额，默认走便宜路径，只在"质量分歧值钱"处花 3–4× 的钱。
# 1. 确认版本 ≥ v2.1.32，模型为 Opus 4.6 claude --version # 2. 在 ~/.claude/settings.json 或环境变量中开启 export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 # 3. 重启 Claude Code（开关启动时读取，跳过重启 = "功能没出现"头号原因） # 4. 验证 echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS # 应输出 1 # 5. 自然语言描述任务和角色，lead 自动建 team、spawn、派活 "Spawn 三个 teammate 评审 PR #142：一个查安全、一个测性能、 一个验测试覆盖。让他们各自评审并汇报发现。"
中途弹权限确认会卡住并行执行、需手动干预，抵消大半收益。启动前先为工作目录预批准。
session 被清理后 /resume 和 /rewind 不恢复 in-process teammate。长跑前存好中间产物。
不经批准就跳进代码是一团糟。先用 plan mode 定角色、边界、产出文件，再放手跑。
操作不同文件的任务很少冲突；碰共享 config 的需小心排序。建议配 Git worktree。
Team 不是更聪明的 agent，而是把"会互相污染的判断"拆成独立 context 并行推进。需要干净隔离用 subagent，需要会对话的协作才用 team。
典型 3 人约 3–4× token，协调开销更快增长。90% 场景单 session 或 subagent 就够，team 只为少数高价值场景存在。
串行 pipeline 整体红灯；但选题验证、审稿是绿灯——在"质量分歧值钱"的节点花钱，其余走便宜路径。
一问定生死：worker 们需要彼此对话吗？找不出 ≥3 条真正独立的并行工作流，就别上 team。
Agent Teams 是实验特性，迭代很快（TeamCreate/TeamDelete 已在 v2.1.178 移除）。落地前以官方文档为准：code.claude.com/docs/en/agent-teams。时间/token 数字来自社区实测，非保证值；产品行为对照官方文档核实。