引言
他是一位老船长，手里有一张用了二十年的海图。那张海图画得很漂亮：从港口出发，经过灯塔、暗礁、洋流交汇点，最后抵达对岸。二十年来，他按这张图走了无数次，从未出错。直到有一天，一场突如其来的风暴把洋流推到了别处，灯塔被浓雾吞没，而暗礁的位置，因为潮汐的变化，已经和图上完全不同。
他站在船头，手里攥着那张不再可靠的海图，突然明白了一件事：真正的问题不是海图画得对不对，而是他有没有学会在风暴里重新画一张。
Dynamic workflow 教我们的，就是这个。
TL;DR
Claude Code 的 dynamic workflows 把复杂任务从聊天上下文里移出来，让 Claude 为当前任务生成 workflow script，再交给 runtime 执行。固定流程会漏掉输入差异，单个模型会把业务状态藏进对话。开发者要让模型根据输入状态生成流程，再让工程系统托管、记录、验证这条流程。
Workflow 像一条流水线。开发者把复杂任务拆成多个节点，前一个节点产出结果，后一个节点继续处理。比如做一个热点新闻短视频系统：
获取热点新闻 -> 分析新闻 -> 生成摘要 -> 生成脚本 -> 生成视频
每一步有职责，每一步留下输出。开发者看日志时，知道系统卡在了新闻抓取、摘要生成、脚本生成，还是视频工具。步骤不会遗漏，依赖关系清楚，前一个节点的输出变成后一个节点的输入。某个节点写错了摘要，后面的视频质量变差，开发者回头查那一段就行，不用在几十轮对话里找模型从哪里开始偏。
Claude Code 的 dynamic workflows 在这个基础上走了一步。Claude 根据当前任务临时写出一份 JavaScript orchestration script，由独立 runtime 在后台调度 subagents。中间结果留在脚本变量和 workflow 运行状态里，不堆进主会话上下文。主会话拿到经过合成和验证的结果。
并行 subagents 是外层现象。更值得看的是流程位置的变化：流程从对话里拿出来，变成一个可以生成、查看、保存、恢复的执行结构。
热点新闻短视频系统面对的问题是：开发者该写一条流程，还是该写一套能生成流程的规则？
固定流程会很快变形
热点新闻短视频适合 workflow。
系统先抓热点，再分析新闻，再生成脚本，再生成画面，再配音，再合成视频。
真实输入不会按这张图排队。
有些热点只有文字，系统要先写脚本、分镜、画面提示词和配音稿。有些热点已经有现场视频，系统该走素材筛选、剪辑、字幕、封面和节奏优化。有些热点来自多个来源，信息互相冲突，流程要先插入事实核验。有些新闻涉及事故、金融、公共安全或人物争议，系统需要风险审核和敏感表述检查。
开发者写死一条流程，系统只能处理那条流程适配的输入。输入一变，每个节点开始加 if-else：摘要节点塞风险判断，视频节点塞事实核验，发布节点塞人工审核。流程图看起来还在，真实逻辑已经散落在各个节点里。
表面上每一步都固定，实际每个节点都在处理不属于自己的问题。
单个 Agent 吞不下业务链路
另一种做法，是直接把目标交给 Agent：
请把今天最值得传播的热点新闻做成一条短视频。
Agent 自己决定先搜什么、看什么、写什么、用什么工具。它可能给出不错的结果，也可能绕过关键步骤。它觉得某个来源可信，就直接写进脚本。它觉得视频需要冲突感，就强化一个未经确认的细节。它觉得节奏太平，就加一句吸引眼球但不够准确的文案。
在开放式创作里，这种自由有时能带来惊喜。在垂直业务里，惊喜经常伴随风险。短视频生产还要处理来源、事实、版权、风控、素材状态、平台规则和发布时间。开发者不能只看最终视频好不好看，还要知道系统怎么走到这个结果。
没有可观察的流程，出错时很难修。你不知道它在哪里把来源 A 和来源 B 混在了一起，也不知道它为什么跳过审核。下一次它可能换一条路，犯一个新错误。
自由应该放在流程生成层。模型可以决定这次任务该走哪条流程，但执行过程要落在可观察的结构里。
Dynamic 指向流程结构生成
Claude Code 的 dynamic workflows 给了一个清楚的工程表达：模型先为任务生成 workflow script，runtime 再执行它。
放到热点新闻短视频系统里，开发者不用先问"完整流程应该长什么样"。系统拿到输入之后，先判断几个状态。
素材状态：只有文字 / 有视频素材 / 有图片素材 / 来源不足
事实状态：来源一致 / 来源冲突 / 无法确认
风险状态：普通娱乐 / 财经医疗 / 公共安全 / 人物争议
业务目标：追求速度 / 追求质量 / 追求规模化
这些状态决定 workflow 的形状。
素材只有文字时，系统生成"脚本 + 分镜 + 画面生成 + 配音 + 合成"的流程。素材里有现场视频时，系统生成"素材清洗 + 片段筛选 + 字幕 + 节奏优化 + 封面"的流程。来源冲突时，系统先插入"交叉核验 + 争议标注 + 人工确认"，脚本生成要等核验结果。新闻敏感时，系统在发布前插入风险审核，审核不过就回到脚本修改。
Dynamic 指的是系统根据任务状态生成一条合适的流程结构。流程一旦生成，交给 runtime 托管。每个节点做什么、由谁做、产出什么、失败后怎么办，都要留下记录。
模型负责提出结构，工程系统负责约束结构。模型只生成内容，它的作用被压在局部节点里。模型连执行过程都自己掌控，业务系统会失去可控性。Dynamic workflow 站在中间。
开发者要写边界
dynamic workflow 用到垂直业务里，开发者不再手写流程，转而定义流程生成的约束。
以前开发者写流程本身：
先抓热点，再摘要，再生成视频。
现在开发者要写流程生成的边界：
哪些状态必须先判断？
哪些结果必须验证，哪些动作需要人工确认？
哪些工具不能由低权限节点使用？
以热点新闻短视频为例，开发者不需要穷举所有新闻类型和素材组合。那会写出一堆脆弱分支。开发者要定义几类边界。
事实边界：来源冲突时，系统不能直接生成确定叙事，必须进入核验节点或把争议写进脚本。权限边界：负责读取公开新闻的 Agent 不该有发布权限，越靠近外部动作，权限越要收紧。
质量边界和成本边界决定流程的下限和上限。脚本可以动态生成，但视频发布前必须过审核，这个节点不能被跳过。很多热点不值得跑完整流程：普通娱乐新闻走轻量链路，高风险新闻才值得启动多 Agent 并行。
这些边界定义清楚，动态流程才有意义。否则 dynamic 只是在给系统增加不确定性。
Runtime 要托管模型生成的流程
Prompt 重要，但 dynamic workflow 这种形态里，runtime 要托管模型生成的流程。
流程一旦由模型生成，系统必须回答几个工程问题。
这个 workflow 能不能被查看和恢复？每个节点的输入输出能不能被记录？某个节点失败后，系统能不能重试或回滚？
Claude Code 的 dynamic workflows 把中间结果从主会话里剥离。Workflow runtime 在后台执行脚本，用户可以看进度，也可以保存 workflow。任务中断后，在同一 session 里还能继续。
垂直业务 Agent 不能只有"会调用工具的模型"。它还需要执行系统。
对热点新闻短视频来说，这个执行系统至少要管住素材状态、节点输出、事实来源、审核结果、失败原因和发布权限。系统生成视频越快，风险积累越快。
Dynamic workflow 是一种控制平面。Agent 没有消失，它被放进了更清楚的位置。它可以判断素材状态，可以生成流程，可以完成某个节点的创作，也可以审核另一个 Agent 的输出。它不该独自吞下整个业务闭环。
适合长链路、状态复杂的任务
Dynamic workflow 不适合所有任务。生成短文案，单次模型调用就够了。JSON 转格式，普通脚本更稳。固定素材套模板，传统 workflow 更便宜。
它适合长链路、状态复杂、需要交叉验证的任务。
热点新闻短视频正好有这些特征。素材可能不完整，事实可能冲突，平台规则会限制表达，业务目标还会变化。系统不能每次都走同一条路，也不能让 Agent 每次临场发挥。
系统面对不同输入时，先生成一条可执行的工作流，再把执行过程放到可观察的轨道上。普通 workflow 把复杂任务拆成固定节点。Dynamic workflow 先判断当前任务需要哪些节点，再组织它们的执行关系。
普通 workflow 解决"不要漏步骤"。Dynamic workflow 解决"不要在错误的输入上跑正确但不合适的步骤"。
收束
开发者不写 prompt，不画流程图。开发者设计流程生成的边界。
在热点新闻短视频这种垂直业务里，这个边界包括素材状态、事实核验、权限控制、成本限制和人工确认。模型可以根据这些边界生成 workflow，但 runtime 必须托管执行过程。
以前的问题是：这个业务用 Agent 还是 workflow？
现在要多问一步：业务状态会变化时，workflow 本身能不能被生成？生成之后，它能不能被记录、验证和暂停？
Agent 开发不能只放大自由度，还要让模型学会生成一套可以被工程系统托管的流程。
风暴过后，老船长把那张旧海图折好，收进了抽屉。他没有扔掉它——它曾经是对的，只是不再适合现在的海。他拿出一张空白纸，在船头坐下，开始画新的航线。灯塔的位置变了，他就标上新的；暗礁移动了，他就重新圈出禁区。他知道，下一场风暴还会再来，而这张新海图，也终将成为旧海图。
但他不再害怕。因为他终于学会了在风暴里画画。
Dynamic workflow 不是一张永远正确的海图。它是一套在风暴里重新画海图的能力。而开发者要做的，不是预测每一场风暴，而是教会系统：当灯塔消失、暗礁移动时，如何不迷失方向。