Anthropic 最近发了 dynamic workflows。Paweł Huryn 跑了一个端到端 demo：113 agents、1.95M tokens、12 分钟、3 个可点击原型，协调它们的 JavaScript 一行 model token 都没花。这行「0 token」才是真正的升级。
Demo 长什么样
他给 Claude 一个产品 discovery 任务 + 一个关键词：ultracode。Claude 没直接回答他——它先写了一段 JavaScript，然后用这段 JS 拉起一支 agent 部队把活儿派下去。
12 分钟后发生了什么：113 个 agent 读完 100 段合成客户访谈（合计 1.95M tokens），抽出 622 个 raw opportunity，聚类到 11 个真需求、打分，再产成 3 个可点击原型——built and verified。
协调这一切的 JS 花了 0 个 model token。Model 负责 judgment，code 负责 coordination。
Orchestrator moved off the model and into code.
关键机制：Claude 现场写 JS
Dynamic workflow 的本质：一段 JS 程序，Claude 在需要时现写。触发方式：命令里打 ultracode，或者直接跟 Claude 说「use a workflow」。
它会做四件事：
- fan out N agents
- gather outputs
- drop repeats（去重）
- route survivors（路由）
关键区别：以前 orchestrator 就是 model——每一条路由决策都是一次付费 turn。现在 orchestrator 是 plain code：loops、filters、a sort。Agents cost tokens. The glue is fast, free, and deterministic.
它跟 n8n 是什么关系
不是 n8n 的替代品。
- n8n 问的是：怎么连接你已经认识的 tools？
- Dynamic workflow 问的是：怎么让 agent 这一次自己现编 procedure？
另一个常被混淆的边界：Claude SDK 也能让 Claude 写 code 协调 agent。但 SDK 协调的是 embedded agents——你 ship 到自己 app 里的 agent。Dynamic workflow 协调的是 workspace agents——在 Claude Code 里你真正用来干活的 agent（coding、research、knowledge work）。
SDK 是你 ship 出去的 agent。Dynamic workflows 是你一起干活的 agent。
何时用 workflow，何时用 subagent
判断线很锋利：
- Subagent 适合「一轮并行 judgment」——一次 fan-out 一次 merge，比如竞品拆解：十个 agent、一份合成、之间没决策。
- Workflow 适合「步骤之间互相说话」——stage N 的输出决定 stage N+1：先路由再打分、先打分再过滤、先生成再验证再 build。
为什么长任务必须把 plan 移出 model
长任务让 model 自己跑，会在三个地方爆。爆的原因都是「model 在 hold 这个 plan」：
- Laziness——让它 review 50 条，它干 35 条就宣布 done。换成 loop 跑到 list 空了——loop 不会累。
- Self-preferential bias——让它给自己打分，它会慷慨。Harness 在独立 context 里spawn 一个独立 judge（有时是不同 model），要求多数通过。grader 不再是被 grader 的那个。
- Goal drift——长 session 里「别碰 auth」在 turn 80 可能就蒸发了。Goal 活在 script 里它就 drift 不了——script 不在被挤的 context 里。
六个重复出现的形状：学名字就够了
Orchestrator 一旦落进 code，六个 shape 会反复出现。学名字就是学识别——任务在请求哪一种自己会告诉你：
- Classify-and-act：一个 agent 决定类型，script 路由。入站 triage：bug vs feature vs noise。
- Fan-out-and-synthesize：每段一个 agent，code 层合并。Market map、竞品拆解。
- Adversarial verification：独立 agent 按 rubric 校验输出。拿 PRD 对照信源 fact-check。
- Generate-and-filter：大量候选，去重，留存者留下。命名、定位文案。
- Tournament (compare)：agent 用不同方式做同一件事，judge 比到分出胜负。战略备忘录这种没有唯一正确答案的题。
- Loop-until-done：spawn 到停止条件命中。审计场景——你不知道工作量有多少。
PM 的真实工作：哪三件能立刻变 standing workflow
不要在学怎么写 code。在学哪些每周 PM 活儿能变成常驻 workflow——定一次目标，把 procedure 存成 skill，让 /goal 端到端跑。
- 100 段客户访谈 → themes-and-JTBD 表：一段访谈一个 agent，合成主题。每段都读，不是只读前 20。
- 80 条 user story 对照 INVEST 检查：loop 跑到每条都查过，不是 model 累在 50 条。
- PRD review 之前先压测：独立 agent red-team 它对你的目标，顶出你在 launch 那天会死守的隐藏假设。
Paweł 自己的 113 agent demo 怎么搭的
他跑的产品 discovery pipeline 是六阶段环：
- Extract——每段访谈一个便宜 model agent（Haiku 或 Sonnet，不要 Opus），返回结构化 opportunity、persona、verbatims。
- Canonicalize——一个 agent 把 raw opportunity 聚类成 canonical 集合。同一个需求挂着十几个名字；合并同义词是 judgment，必须是 model 不是 code。
- Score（code，无 model）——用
frequency × importance × (5 − satisfaction)给每个 canonical opportunity 排序。 - Generate and triage——top opportunity 上一个 agent 提方案，独立 judge 按 ROI 排、前 3 进 build。
- Build——一个 agent 调 frontend-design skill 写可点击 HTML 原型。
- Inspect and rerun——smoke check 任何渲染失败的原型重跑、任何低 confidence 的 extraction 重抽。这才是真 loop——某一阶段的输出决定前一阶段要不要再跑。
他碰到的真实卡点：第一版 prompt 写「merge and dedupe」，counts 出来碎成 30 多个（实际只有 11 个真需求）。他加了一行「cluster synonyms before counting」，Claude 把 harness 重写了——加了一个 clustering agent 顶在 scorer 前面。连修复都 off the model。
最终：113 个 agent fan out，1.95M tokens，12.5 分钟，3 / 3 原型 built and verified。JS 那一层 0 token。
这条 thread 在 2026 agent 栈里的位置
Dynamic workflow 解决的是**「多步之间需要决策、决策不需要 model」这种场景里glue 层的成本**。它不是「取代 subagent」也不是「取代 n8n」——它是第三条：
- Subagent：单轮并行 judgment。
- n8n：连你已经认识的 tools。
- Dynamic workflow：让 agent 现场编 procedure，deterministic 层 0 token。
下一次你想让 Claude 处理 100 条脏数据，别问它「能不能再努力点」。给它目标，让它自己写 harness。