从 Claude Agent Teams 到 Dynamic Workflows
用第一性原理解释两种多 Agent 机制、热度回落与实际采用边界
结论先行：Dynamic Workflows 不是 Agent Teams 的营销改名，也不是证明 Agent Teams 失败的替代品。两者把“谁持有计划、状态和质量循环”放在不同位置。Agent Teams 让一个 lead 与少量 peer session 在对话中协作，适合需要讨论、互相质疑和人工实时介入的问题。Dynamic Workflows 将编排写成可运行的脚本，把大量中间状态移出聊天上下文，适合大范围、同构、可验证的任务。后者补的正是前者难以稳定解决的控制平面与规模问题。
先校正问题：搜索热度不是喜欢，也不是采用
本文讨论的 Google Trends 查询为 Claude Agent Teams，条件为 Worldwide、2026-01-01 至 2026-07-16、All categories、Web Search。其发布窗口峰值为 100，最后完整日 2026-07-15 的读数为 4。截图采集于 2026-07-16。
图：上述 Google Trends 查询的截图，采集于 2026-07-16；日级数值截至 2026-07-15。
这个序列支持一个很窄的事实：在这组查询、地域和时间窗内，产品名被搜索的相对频率显著低于发布日。它不能证明用户不喜欢、没有使用，或 Dynamic Workflows 已经取代 Agent Teams。Google 明确说明，Trends 是经抽样、按地区和时间归一化后再缩放到 0 至 100 的相对兴趣，不是绝对搜索量、市场份额或科学民调。低量查询还可能混入统计噪声。Google Trends 方法说明
因此，以下把 100 → 4 当作“发布注意力衰退”的信号，并用产品机制、公开限制和社区反馈解释它，而不把相关性包装成因果。
1. 从第一性原理看，多 Agent 到底在优化什么
一个复杂工程任务的交付时间，不只等于模型生成代码的时间。可以粗略写成：
其中：
- $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 两者解决的不是同一层问题
Agent Teams 的组织模型是一个 lead 加一组独立 session。成员可互发消息、领取共享任务、在运行中讨论和改写下一步计划。官方把它定位为适合 research、review、竞争性 debug 假设与跨层协作的实验性机制。Agent Teams 文档
Dynamic Workflows 的组织模型是 Claude 生成一段 JavaScript，runtime 在后台执行这段脚本。脚本保存循环、分支与中间变量，subagent 负责读、写和执行，主会话只收到经过聚合的结果。官方对两者的划分很直接：Agent Teams 由 lead 在每一轮决定下一步，Workflow 由脚本决定下一步；前者的中间状态是共享 task list，后者是 script variables。Workflow 比较表
| 维度 | Agent Teams | Dynamic Workflows |
|---|---|---|
| 计划在哪 | lead 的持续推理和成员对话 | 可读、可保存、可重跑的 JavaScript |
| 协作关系 | 少量 peer 可以互相通信 | 大量 subagent 通常经脚本阶段汇聚 |
| 中间状态 | 共享任务和 mailbox | 脚本变量与 runtime 状态 |
| 最强场景 | 需要讨论、反证、实时改计划 | 大范围枚举、同构迁移、可重复审计 |
| 主要瓶颈 | lead 的协调能力与团队同步 | 脚本质量、成本与验证 oracle |
| 适当规模 | 少量长运行 peer | 每次 run 数十到数百个任务单元 |
这不是同一把锤子。它们的分界线是工作流是否足够确定，值得从自然语言决策固化为程序。
2.2 Agent Teams 暴露了“对话式编排”的上限
Agent Teams 让 Claude 模拟一个小组，但小组本身有不可消除的控制成本：
- 状态分散。每个 teammate 有独立 context，且不会继承 lead 对话历史。共享的是任务状态和消息，不是完整理解。spawn prompt 不完整时，成员从不同起点推断目标。
- lead 是串行瓶颈。只要后续任务取决于前一轮发现，lead 就要阅读、判断、分派和合并。并行 worker 多，不表示决策链并行。
- 协作需要人工操作语义。谁拥有文件、什么算完成、发现矛盾时谁裁决，都依赖 prompt 和 lead 的临场判断，难以复用和审计。
- 工程可靠性仍在试验阶段。官方列出 in-process teammate 无法随
/resume恢复、任务状态可能滞后、关闭可能慢、每个 session 只能有一个 team、不能嵌套 team、lead 不可转移等限制。已知限制 - 成本几乎按成员数增长。每个 teammate 都有独立 context 和 session。官方建议 team 保持小型，并说明 plan mode 下 Agent Teams 约为普通 session 的 7 倍 token 使用量。成本说明
这些并非实现细节，而是自然语言驱动的 peer 协作系统的结构性代价。若任务需要持续讨论，这些代价值得付。若任务其实是“对 500 个文件执行同一检查，然后交叉验证候选项”，它们就是不必要的摩擦。
2.3 Dynamic Workflows 补的是控制平面，不是 worker 数量
Dynamic Workflows 的核心创新是把编排从 context 迁到程序：
pipeline()可以对已发现的文件列表重复执行同一规则。- 脚本变量保存中间结果，不让每个结果都污染主会话 context。
- 固定阶段可以编码为发现、fan-out、反证、去重、验证和报告。
- 成功的脚本可以保存为项目 command，在下次运行同一质量闭环，而不是再次依赖 prompt 运气。
- runtime 在后台运行，能显示阶段、agent、token 与进度，并在同一 session 内恢复已完成任务。运行模型与恢复语义
这就是为什么 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 中接受用户输入。行为与限制
因此它不解决模糊 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 过早结束或成员出错时手工引导。官方最佳实践与故障处理
这造成一个反直觉结果：最有能力正确使用它的高级用户，往往已能用 worktree、多个 session 或自建脚本完成部分工作。新用户则最缺乏为并发系统提供边界和验收的能力。功能处在“专家觉得不够可控，初学者觉得过于复杂”的夹层。
3.3 试验性、默认关闭和环境约束压缩了漏斗
Agent Teams 在 Claude Code 2.1.32 的 2026-02-05 release 中以 research preview 发布，需要显式设置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1。发布记录 当前官方页面仍标为 experimental。split-pane 还依赖 tmux 或 iTerm2，并明确不支持 VS Code integrated terminal、Windows Terminal 与 Ghostty。显示模式限制
这不是小缺陷。使用者必须安装 Claude Code、启用实验开关、具备适合的终端环境，并且拥有可并行拆分的任务。
3.4 它放大产出，也放大 QA 债务
若单个 agent 的正确率不足以让结果直接合并，增加 peer 并不自动生成独立真相。它们可能读取同样的过期文档、误解同一条业务规则、或把同一个坏测试当作 oracle。此时多 agent 的共同错误高度相关，不能按“多数投票”被消除。
Hacker News 的 Dynamic Workflows 发布讨论呈现了相同担忧：不少评论者的瓶颈是正确性、人类中途纠偏和测试可信度，不是 agent 数量。也有人报告大任务因更干净的独立 context 和验证阶段而改善。两类观点可以同时为真，因为它们对应不同任务形状。社区讨论
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 发布记录
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 设置，正是在尝试降低这种选择成本。启动、批准与规模控制
4.4 Token 经济学限制了反复试错
Workflow 文档专门警告，多 agent run 的 token 使用会显著高于普通会话；超过 25 个 agent 或预测超过 150 万 token 时只给出 advisory Large workflow 警告，不会自动停止。成本与警告
这解释了为什么热度不会像免费、即时的功能一样持续上升。用户必须先有足够高价值的任务，才能合理承担探索成本。也解释了为什么真正可持续的用法通常会收敛为少数已验证 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 只作为可追溯的早期用户体验信号，不构成代表性调查。
- Anthropic, Orchestrate teams of Claude Code sessions. Agent Teams 架构、适用场景、成本提示和限制。
- Anthropic, Orchestrate subagents at scale with dynamic workflows. 工作流的控制模型、运行限制、恢复、审批与成本。
- Anthropic, Claude Code changelog. Agent Teams 于 2026-02-05 以 research preview 发布，Dynamic Workflows 于 2026-05-28 发布。
- Anthropic, Manage costs effectively. Agent Teams token 规模效应与 plan mode 成本说明。
- Google, FAQ about Google Trends data. 抽样、归一化、噪声和解释边界。
- Hacker News, Dynamic Workflows in Claude Code. 发布日的正负面体验与可观察担忧。