Anthropic 发了 Opus 4.8，所有人都讨论 benchmark 和 honesty 改进。
但跟它一起发布的 Dynamic Workflows 可能更重要——它改的是"agent 怎么协作"，不是"模型多强"。
Akshay Pachaar 拆解了三个层级的多 agent 架构。
三层级对比
Subagent（轻量 worker）
Claude Code 早期就有的多 agent 原语。
特点：
- 从主会话派生，做专注任务，汇报
- agent 之间不能直接通信
- 主 agent 是编排瓶颈——所有结果过它的 context
限制：单 main agent 串行处理，无法大规模并行。
Agent Teams（多 agent 协调）
Opus 4.6 引入。
改进：
- 多个 Claude 实例通过共享 task list + 消息互相通信
- 不再过单 main context
限制：
- 实际跑到 3-5 个队友就乱了
- 会话不持久——Claude 中途 crash，整个 team 没了
- 编排仍要预先设计——你写好 workflow，agent 跑流程
Dynamic Workflows（新层级）
Opus 4.8 引入。比 Agent Teams 高一层。
关键变化：
- Claude 不再在 context 里持有 plan
- 它写一个 JavaScript 编排脚本
- JS runtime 执行这个脚本
- 自动 fan-out 到 10-1000 个并行 subagent
Claude 的 context window 只看到最终收敛的答案——不看到 1000 步的中间结果。
关键数字
| 维度 | Subagent | Agent Teams | Dynamic Workflows |
|---|---|---|---|
| 并发上限 | < 5 | 3-5 | 16 同时 + 1000/flow |
| 编排 | Main agent context | 共享 task list | JS 脚本 |
| Adversarial verification | ❌ | ❌ | ✅ |
| 中途 crash 恢复 | ❌ | ❌ | ✅（脚本可重跑） |
| 主 context 压力 | 高 | 中 | 极低（只看结果） |
Adversarial Verification 是杀手锏
Dynamic Workflows 的真正突破不是"并行度"——是adversarial verification。
机制：
- 多个 agent 从独立角度解题
- 它们主动试图 break 对方的 finding
- 结果合并前互相验证
这比"自审"质量高 2-3 个数量级——因为自审有 confirmation bias（你写的代码你看着都对），adversarial 验证强制 cross-check。
类比：
- 单 agent 自审 = 一个人写代码 + 自己 review
- adversarial verification = 一个人写 + 三个人独立 review + 互相 break 对方的判断
后者找到的 bug 是前者的 5-10 倍。
Bun 的真实案例
最强证明不是 benchmark——是Bun 的 Zig→Rust 重写。
Jarred Sumner（Bun 创始人）用 Dynamic Workflows 重写 Bun：
- 75 万行 Rust
- 99.8% 现有测试通过
- 11 天（first commit → merge）
- 数百个 agent 并行
- 每个文件 2 个 reviewer
这种工作以前工程团队规划 1-2 个季度，Dynamic Workflows 11 天做完。
怎么触发
要使用 Dynamic Workflows：
- Claude Code v2.1.154+
- Max / Team / Enterprise plan
- 在 prompt 里输入 "workflow" → Claude 规划 + 确认后跑
- 或
/effort ultracode→ Claude 自动判断何时触发 - 先开 auto mode：
/permissions→ 选 auto
跟 4-agent pipeline 的关系
之前 darkzodchi 的 4-agent pipeline（Planner → Coder → Tester → Reviewer）手工 handoff 文件。
Dynamic Workflows 是同一思路的工业级实现：
- 4-agent pipeline = 4 个 subagent + handoff 文件 + 串行
- Dynamic Workflows = 100+ subagent + JS 编排 + 并行 + adversarial
Dynamic Workflows 取代的不是 4-agent pipeline——是4-agent pipeline 的"低效"。简单 task 仍用 subagent/4-agent 流水线，复杂 task 上 Dynamic Workflows。
适合谁 vs 不适合谁
适合
- 大规模代码迁移（Bun 那种，几十万行）
- 代码审查（adversarial verification 比人审质量高）
- 研究任务（多 agent 并行检索 + 验证）
- 复杂 bug 调试（多个 hypothesis 并行验证）
不适合
- 简单 task（"改个 typo"）—— overkill
- 实时响应（Dynamic Workflows 启动需要 30-60 秒）
- Plan B 需要快速迭代——Dynamic Workflows 一次跑完，难中途改
- 没开 auto mode——必须信任 Claude 自主决策
Akshay 没说的两件事
1. JS 编排脚本的 debugging 难题。Dynamic Workflows 跑完出问题时，debug 的是 Claude 写的 JS 脚本 + 1000 个 subagent 的执行轨迹——这远超传统编程的 debug 能力。Anthropic 当前提供的 observability 工具只能看"哪些 subagent 跑了、输出什么"，不能完整 replay。复杂 Dynamic Workflow 出问题，目前基本靠"重新跑一遍"。
2. Adversarial verification 的"对抗"程度不可控。Dynamic Workflows 让 agent "互相 break 对方 finding"——但"break 到什么程度"是 Claude 自己决定的。有时 adversarial 太弱（agent 互相放水），有时太强（agent 互相否定导致 result collapse）。adversarial 强度是隐式超参，没有显式配置。实操中需要"跑一次看结果"再调，没有"一次跑对"的把握。
结论
Dynamic Workflows 的核心创新是把 agent 编排从 LLM 内存移到可执行代码——这绕过了 LLM context window 的硬限制。
三层级架构（subagent → Agent Teams → Dynamic Workflows）解决的不是"哪个最好"，是**"不同规模的任务用不同工具"**。5 个 subagent 够的事别上 Dynamic Workflows——启动成本和 observability 复杂度不值得。
Bun 的 11 天重写 75 万行 Rust 是 Dynamic Workflows 的最强证明——这种规模以前根本不可能。
SOTA Sync 的判断：未来 12 个月，Dynamic Workflows 类能力会成为 AI 编码工具的标配——不是"每个工具都有 Dynamic Workflows"，是"不提供的工具会被淘汰"。这是 agent 编排从"单 agent 写代码"到"工业级多 agent pipeline"的范式转移。
但 observability 是 Dynamic Workflows 的下一道关卡——1000 subagent 跑完出问题怎么 debug、怎么 replay、怎么 audit，目前没有成熟方案。这会是 AI Ops 领域的新机会——专门做 Dynamic Workflow 调试工具的创业公司会出现。