---
title: 从 Claude Agent Teams 到 Dynamic Workflows
description: 用第一性原理解释两种多 Agent 机制、热度回落与实际采用边界
---

> **结论先行**：Dynamic Workflows 不是 Agent Teams 的营销改名，也不是证明 Agent Teams 失败的替代品。两者把“谁持有计划、状态和质量循环”放在不同位置。Agent Teams 让一个 lead 与少量 peer session 在对话中协作，适合需要讨论、互相质疑和人工实时介入的问题。Dynamic Workflows 将编排写成可运行的脚本，把大量中间状态移出聊天上下文，适合大范围、同构、可验证的任务。后者补的正是前者难以稳定解决的控制平面与规模问题。

## 先校正问题：搜索热度不是喜欢，也不是采用

本文讨论的 Google Trends 查询为 [`Claude Agent Teams`](https://trends.google.com/trends/explore?date=2026-01-01%202026-07-16&q=Claude%20Agent%20Teams)，条件为 Worldwide、2026-01-01 至 2026-07-16、All categories、Web Search。其发布窗口峰值为 100，最后完整日 2026-07-15 的读数为 4。截图采集于 2026-07-16。

![](https://r2.unono.app/2026/07/bb321fb47dc7a62d6b5c38d8cc571df6.png)

*图：上述 Google Trends 查询的截图，采集于 2026-07-16；日级数值截至 2026-07-15。*

这个序列支持一个很窄的事实：在这组查询、地域和时间窗内，产品名被搜索的相对频率显著低于发布日。它**不能**证明用户不喜欢、没有使用，或 Dynamic Workflows 已经取代 Agent Teams。Google 明确说明，Trends 是经抽样、按地区和时间归一化后再缩放到 0 至 100 的相对兴趣，不是绝对搜索量、市场份额或科学民调。低量查询还可能混入统计噪声。[Google Trends 方法说明](https://support.google.com/trends/answer/4365533?hl=en)

因此，以下把 `100 → 4` 当作“发布注意力衰退”的信号，并用产品机制、公开限制和社区反馈解释它，而不把相关性包装成因果。

## 1. 从第一性原理看，多 Agent 到底在优化什么

一个复杂工程任务的交付时间，不只等于模型生成代码的时间。可以粗略写成：

$$
T = T_{serial} + \frac{T_{parallel}}{N} + T_{coordination}(N) + T_{verification}(N)
$$

其中：

- $T_{serial}$ 是问题定义、架构选择、共享接口和最终合并。这些工作不能靠增加 worker 线性加速。
- $T_{parallel}$ 是可以按文件、路由、假设或来源拆开的工作。
- $T_{coordination}$ 是分工、消息、依赖、冲突和重试的代价，通常随 $N$ 增长。
- $T_{verification}$ 是证明结果正确的代价。它不会因为产出更快而消失，反而可能因候选结果更多而增大。

多 Agent 的可取之处不是“有更多智能”，而是同时购买了三种资源：更多独立 context window、更多工具调用槽位，以及更多独立尝试。它也同时放大三种风险：共同误读 spec、共享工作区写冲突，以及 token 和人类 QA 的支出。

所以真正的问题不是“能否调度 100 个 agent”，而是：**任务的并行部分是否足够大，单元边界是否明确，是否存在能裁决结果的外部 oracle。** 这个 oracle 可以是测试、类型检查、性能基准、精确规则或人工验收。没有它，多 Agent 只是更快地在错误方向上扩散。

## 2. 为什么有了 Agent Teams，还要推出 Dynamic Workflows

### 2.1 两者解决的不是同一层问题

```mermaid
flowchart TB
  U[Developer goal and acceptance criteria] --> L[Agent Teams lead]
  L <--> A[Peer session A]
  L <--> B[Peer session B]
  A <--> B
  L --> T[Shared task list and mailbox]

  U --> W[Workflow script]
  W --> P[Discover phase]
  W --> F[Fan-out phase]
  W --> V[Independent verification phase]
  P --> R[Script variables and resumable run state]
  F --> R
  V --> R
  R --> O[One synthesized result]
```

Agent Teams 的组织模型是一个 lead 加一组独立 session。成员可互发消息、领取共享任务、在运行中讨论和改写下一步计划。官方把它定位为适合 research、review、竞争性 debug 假设与跨层协作的实验性机制。[Agent Teams 文档](https://code.claude.com/docs/en/agent-teams)

Dynamic Workflows 的组织模型是 Claude 生成一段 JavaScript，runtime 在后台执行这段脚本。脚本保存循环、分支与中间变量，subagent 负责读、写和执行，主会话只收到经过聚合的结果。官方对两者的划分很直接：Agent Teams 由 lead 在每一轮决定下一步，Workflow 由脚本决定下一步；前者的中间状态是共享 task list，后者是 script variables。[Workflow 比较表](https://code.claude.com/docs/en/workflows#when-to-use-a-workflow)

| 维度 | Agent Teams | Dynamic Workflows |
| --- | --- | --- |
| 计划在哪 | lead 的持续推理和成员对话 | 可读、可保存、可重跑的 JavaScript |
| 协作关系 | 少量 peer 可以互相通信 | 大量 subagent 通常经脚本阶段汇聚 |
| 中间状态 | 共享任务和 mailbox | 脚本变量与 runtime 状态 |
| 最强场景 | 需要讨论、反证、实时改计划 | 大范围枚举、同构迁移、可重复审计 |
| 主要瓶颈 | lead 的协调能力与团队同步 | 脚本质量、成本与验证 oracle |
| 适当规模 | 少量长运行 peer | 每次 run 数十到数百个任务单元 |

这不是同一把锤子。它们的分界线是**工作流是否足够确定，值得从自然语言决策固化为程序**。

### 2.2 Agent Teams 暴露了“对话式编排”的上限

Agent Teams 让 Claude 模拟一个小组，但小组本身有不可消除的控制成本：

1. **状态分散**。每个 teammate 有独立 context，且不会继承 lead 对话历史。共享的是任务状态和消息，不是完整理解。spawn prompt 不完整时，成员从不同起点推断目标。
2. **lead 是串行瓶颈**。只要后续任务取决于前一轮发现，lead 就要阅读、判断、分派和合并。并行 worker 多，不表示决策链并行。
3. **协作需要人工操作语义**。谁拥有文件、什么算完成、发现矛盾时谁裁决，都依赖 prompt 和 lead 的临场判断，难以复用和审计。
4. **工程可靠性仍在试验阶段**。官方列出 in-process teammate 无法随 `/resume` 恢复、任务状态可能滞后、关闭可能慢、每个 session 只能有一个 team、不能嵌套 team、lead 不可转移等限制。[已知限制](https://code.claude.com/docs/en/agent-teams#limitations)
5. **成本几乎按成员数增长**。每个 teammate 都有独立 context 和 session。官方建议 team 保持小型，并说明 plan mode 下 Agent Teams 约为普通 session 的 7 倍 token 使用量。[成本说明](https://code.claude.com/docs/en/costs#manage-agent-team-costs)

这些并非实现细节，而是自然语言驱动的 peer 协作系统的结构性代价。若任务需要持续讨论，这些代价值得付。若任务其实是“对 500 个文件执行同一检查，然后交叉验证候选项”，它们就是不必要的摩擦。

### 2.3 Dynamic Workflows 补的是控制平面，不是 worker 数量

Dynamic Workflows 的核心创新是把编排从 context 迁到程序：

- `pipeline()` 可以对已发现的文件列表重复执行同一规则。
- 脚本变量保存中间结果，不让每个结果都污染主会话 context。
- 固定阶段可以编码为发现、fan-out、反证、去重、验证和报告。
- 成功的脚本可以保存为项目 command，在下次运行同一质量闭环，而不是再次依赖 prompt 运气。
- runtime 在后台运行，能显示阶段、agent、token 与进度，并在同一 session 内恢复已完成任务。[运行模型与恢复语义](https://code.claude.com/docs/en/workflows#how-a-workflow-runs)

这就是为什么 Anthropic 同时保留两条线。Agent Teams 把“人类会怎样组织一场讨论”产品化。Dynamic Workflows 把“可靠的重复工序应怎样执行”产品化。前者适合探索不确定性，后者适合消灭可枚举的重复性。

### 2.4 Dynamic Workflows 真正解决的问题

它只在四个条件同时成立时有明显优势：

| 条件 | 例子 | 若条件缺失会怎样 |
| --- | --- | --- |
| 可枚举对象 | 每个 route、文件、依赖项、研究来源 | agent 无法稳定切片，重复与遗漏增加 |
| 同构判断 | 检查鉴权、废弃 API、依赖许可证 | 每个 worker 都重新发明方法 |
| 独立执行 | 不同文件或隔离副本 | 并行 edit 冲突，合并成本反超收益 |
| 可验证输出 | test suite、linter、benchmark、人工规则 | 反复投票也不能建立正确性 |

公开产品案例，例如大规模审计、跨数百文件的迁移和多来源交叉研究，恰好符合这四条。Dynamic Workflows 的上限也说明它是受控批处理，不是无限 swarm：官方 runtime 最多 16 个并发 agent、每次最多 1,000 个 agent，且不允许在 run 中接受用户输入。[行为与限制](https://code.claude.com/docs/en/workflows#behavior-and-limits)

因此它**不**解决模糊 feature 的产品判断、共享 schema 的整体设计或测试本身失效的问题。对这些任务，让数十个 agent 同时推进，只会把 $T_{coordination}$ 与 $T_{verification}$ 推高。

## 3. Agent Teams 的采用边界

公开证据不足以衡量 Agent Teams 的实际采用情况。以下讨论的是官方限制和任务形状带来的使用门槛，而不是对用户态度或使用规模的判断。

### 3.1 价值门槛高于演示门槛

演示很容易：开五个 pane，让 agent 并行读仓库。产生净收益很难，因为需要先具备清晰的文件边界、任务依赖、验收标准和 review 能力。多数日常 feature 都包含共享接口、连续决策和业务语义，真正可并行的比例有限。

换言之，Agent Teams 优化的是一个已经被工程化拆解好的问题。它不替用户完成拆解本身。没有 task design 时，用户看到的是更多输出、更多冲突和更多等待，而不是更短的交付时间。

### 3.2 控制感与可观察性不匹配

多人协作的价值取决于人能否随时理解与纠正系统。Agent Teams 虽提供 in-process 和 split-pane 模式，却要求用户监控成员、避免 file conflict，并在 lead 过早结束或成员出错时手工引导。[官方最佳实践与故障处理](https://code.claude.com/docs/en/agent-teams#best-practices)

这造成一个反直觉结果：最有能力正确使用它的高级用户，往往已能用 worktree、多个 session 或自建脚本完成部分工作。新用户则最缺乏为并发系统提供边界和验收的能力。功能处在“专家觉得不够可控，初学者觉得过于复杂”的夹层。

### 3.3 试验性、默认关闭和环境约束压缩了漏斗

Agent Teams 在 Claude Code 2.1.32 的 2026-02-05 release 中以 research preview 发布，需要显式设置 `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`。[发布记录](https://code.claude.com/docs/en/changelog#2-1-32) 当前官方页面仍标为 experimental。split-pane 还依赖 tmux 或 iTerm2，并明确不支持 VS Code integrated terminal、Windows Terminal 与 Ghostty。[显示模式限制](https://code.claude.com/docs/en/agent-teams#limitations)

这不是小缺陷。使用者必须安装 Claude Code、启用实验开关、具备适合的终端环境，并且拥有可并行拆分的任务。

### 3.4 它放大产出，也放大 QA 债务

若单个 agent 的正确率不足以让结果直接合并，增加 peer 并不自动生成独立真相。它们可能读取同样的过期文档、误解同一条业务规则、或把同一个坏测试当作 oracle。此时多 agent 的共同错误高度相关，不能按“多数投票”被消除。

Hacker News 的 Dynamic Workflows 发布讨论呈现了相同担忧：不少评论者的瓶颈是正确性、人类中途纠偏和测试可信度，不是 agent 数量。也有人报告大任务因更干净的独立 context 和验证阶段而改善。两类观点可以同时为真，因为它们对应不同任务形状。[社区讨论](https://news.ycombinator.com/item?id=48311705)

### 3.5 使用成本可见，收益常常不可归因

Agent Teams 的 token 开销立即可见，收益却常以“少漏了一个假设”或“缩短了等待”形式出现，难以在一次试用中归因。因此应在相似任务上记录成本、人工 review 时间和返工率，再决定是否固化工作流。

### 3.6 风评应按代价来读

公开体验中的正面评价集中在协作带宽，负面评价集中在控制权与 QA。两边都不能单独代表实际效果：

| 机制 | 被认可的价值 | 必须接受的缺点 |
| --- | --- | --- |
| Agent Teams | peer 可直接讨论、竞争性假设能并行验证、人可随时重定向成员 | lead 仍是协调瓶颈，共享工作区会冲突，成员恢复与终端环境仍受限制，token 和 review 成本随成员增加 |
| Dynamic Workflows | 重复的发现、fan-out、反证和汇总可写成可审阅脚本，适合大量同构单元 | `acceptEdits` 会放大错误范围，run 中不能自然插入人工裁决，只能在同一 session 恢复，成本警告不自动熔断 |

因此，“更多 agent”不是优点本身。能把缺点控制在可接受范围的前提，是清晰的输入边界、独立文件所有权、可信验收器、明确的 token 上限和足够的人类 review 时间。

## 4. 为什么 Agent Teams 和 Dynamic Workflows 的热度都会回落

### 4.1 发布型关键词的正常生命周期

发布日搜索混合了新闻、设置、价格、教程、兼容性和围观。首次答案被文档、视频和社区文章覆盖后，重复检索需求自然下降。对一个窄产品名，后续用户更可能搜索具体错误、`tmux`、`ultracode`、模型名或任务本身，而不是反复搜索完整 feature 名。

所以 `100 → 4` 首先像一个典型的 announcement curve，不是产品死亡证明。Dynamic Workflows 在 2026-05-28 发布，比 Agent Teams 更晚，观察窗口也更短，更应该避免从早期回落推出长期结论。[Dynamic Workflows 发布记录](https://code.claude.com/docs/en/changelog#2-1-156)

### 4.2 两者都属于低频、高门槛能力

它们不像 chat 或补全一样每天被每位用户显式调用。它们适用于大范围 review、迁移、审计、研究和复杂调试。高价值事件本来就低频，因此持续的品牌搜索低不奇怪。

企业里的实际使用还可能在私有仓库、内部 runbook、managed settings 和 usage dashboard 中发生，天然不会转化为公开搜索或社交讨论。反过来，公开讨论多也不等于长期留存。

### 4.3 产品复杂度切分了注意力

Claude Code 同时有 subagent、skills、Agent Teams、workflows、`/deep-research`、不同 effort level 和 `ultracode`。用户首先要回答“此刻该选哪个”，才会得到功能收益。概念数量增多会造成选择成本，并把原本集中在 Agent Teams 的搜索意图分散到 `workflow`、`Claude Code`、`Opus 4.8`、`ultracode` 等词上。

这并非只靠文案能解决。产品需要把默认路径变成“系统在正确风险边界内自动选择规模”，同时让用户能理解、暂停和审阅。Dynamic Workflows 的 `ultracode`、计划预览、进度页和 workflow size 设置，正是在尝试降低这种选择成本。[启动、批准与规模控制](https://code.claude.com/docs/en/workflows#let-claude-decide-with-ultracode)

### 4.4 Token 经济学限制了反复试错

Workflow 文档专门警告，多 agent run 的 token 使用会显著高于普通会话；超过 **25 个 agent** 或预测超过 **150 万** token 时只给出 advisory `Large workflow` 警告，不会自动停止。[成本与警告](https://code.claude.com/docs/en/workflows#cost)

这解释了为什么热度不会像免费、即时的功能一样持续上升。用户必须先有足够高价值的任务，才能合理承担探索成本。也解释了为什么真正可持续的用法通常会收敛为少数已验证 command，而不是每天开一次 swarm。

## 5. 对产品路线的批判性判断

目前证据支持的最强判断不是“Anthropic 放弃 Agent Teams”，而是它认识到多 Agent 不该只有一个交互模型：

- **Agent Teams** 保留了协作的开放性。适合不确定问题，需要 peer 互相质疑，也允许人直接重定向成员。
- **Dynamic Workflows** 追求可控的吞吐量。适合确定的批处理形状，把质量模式编码为脚本与阶段。
- **两者的共同前提** 是外部可验证性。没有 spec、测试和 review，更多 agent 只会加速不确定性。

真正的风险是产品同时暴露太多原语，却没有可靠的 task classifier。若用户必须自己判断“subagent、team 还是 workflow”，复杂度本身会吞掉并行收益。最好的默认策略应是先从单 agent 或少量 subagent 开始，仅当系统能证明任务存在独立切片与明确 oracle 时，才升级为 Agent Teams 或 Workflow。

## 6. 给工程团队的可操作结论

| 任务 | 首选 | 原因 |
| --- | --- | --- |
| 两三个互斥 root-cause 假设 | Agent Teams | 需要互相反证和实时调整调查 |
| 一个 PR 的 security、performance、test review | Agent Teams 或少量 subagent | 视角独立，产出可由 lead 汇总 |
| 500 个文件的同构 API 迁移 | Dynamic Workflow | 可枚举、可隔离、可循环验证 |
| 全仓鉴权规则审计 | Dynamic Workflow | 单位清晰，可做发现、复核、去重 |
| 新业务 feature 或共享 schema 设计 | 单 session 加人类 plan review | 核心工作是目标澄清和共享决策 |
| 测试不可信或验收标准缺失 | 先修 oracle，不开 swarm | 无法证伪时并行没有可靠收益 |

建议用一个小型实验代替信仰或反感：固定同一类任务，先比较单 session、3 人 Agent Team 与小型 Workflow。记录 wall-clock、接受后的人类 review 时间、返工率、token、漏报和误报。只有当收益覆盖协调与 QA 成本，再扩大规模或固化 command。

## 最终判断

Claude Agent Teams 的热度下降，最可能说明发布好奇心退去，而不是已经被判定为失败。它的价值高度依赖任务拆分、监督和验收。它的问题也真实存在：实验性、默认关闭、状态恢复和协作边界限制、昂贵的独立 context，以及把 QA 负担转移给人的倾向。

Claude Dynamic Workflows 的出现恰好针对这些缺口，但只针对可程序化的部分。它把多 Agent 的计划、循环和质量门从临场对话移入可审阅的 runtime 脚本，使大范围且同构的任务不必由 lead 逐轮协调。它不会使不清晰的需求变清晰，也不会让坏测试变成真相。

如果只能记住一句话：**Agent Teams 是协作界面，Dynamic Workflows 是批处理控制平面。前者扩大讨论带宽，后者扩大可验证吞吐量，二者都无法替代清晰目标和可信验收。**

## 来源与方法

研究截至 2026-07-16。产品机制、限制、可用性与成本优先依据 Anthropic 官方文档和 release notes。Google Trends 只用于相对搜索兴趣的描述，不能用于推断采用率或用户满意度。Hacker News 只作为可追溯的早期用户体验信号，不构成代表性调查。

1. Anthropic, [Orchestrate teams of Claude Code sessions](https://code.claude.com/docs/en/agent-teams). Agent Teams 架构、适用场景、成本提示和限制。
2. Anthropic, [Orchestrate subagents at scale with dynamic workflows](https://code.claude.com/docs/en/workflows). 工作流的控制模型、运行限制、恢复、审批与成本。
3. Anthropic, [Claude Code changelog](https://code.claude.com/docs/en/changelog). Agent Teams 于 2026-02-05 以 research preview 发布，Dynamic Workflows 于 2026-05-28 发布。
4. Anthropic, [Manage costs effectively](https://code.claude.com/docs/en/costs#agent-team-token-costs). Agent Teams token 规模效应与 plan mode 成本说明。
5. Google, [FAQ about Google Trends data](https://support.google.com/trends/answer/4365533?hl=en). 抽样、归一化、噪声和解释边界。
6. Hacker News, [Dynamic Workflows in Claude Code](https://news.ycombinator.com/item?id=48311705). 发布日的正负面体验与可观察担忧。