Claude Code的“动态工作流”，正在把智能体开发拆成脚本工程

智能体编程走到一个有点分裂的阶段：一边是对“更聪明模型”的期待，另一边是实际开发里不断暴露的工程瓶颈。

单通道对话式Agent曾经是主流路径——给模型一个目标，它在同一上下文里推理、拆解、执行。但在复杂任务场景里，这种结构很快出现三个隐性问题：模型开始“自我确认”，输出趋于顺滑但不可靠；长对话让目标逐渐漂移；更现实一点的，是上下文越拉越长，token成本失控。

Claude Code团队这次提出的“动态工作流”，其实是在承认一个事实：Agent开发正在从“对话设计”转向“执行系统设计”。

Thariq Shihipar分享的这套实践，把原本藏在聊天里的逻辑拆了出来。核心变化不在模型，而在编排方式。

在Claude Opus 4.8的版本里，模型可以直接生成JavaScript脚本，用来调度多个子智能体。这个动作看起来像自动化增强，但本质更接近“把prompt工程外包成代码工程”。

原本的开发流程是：人在对话框里写指令，模型在单线程中逐步执行。

现在变成：模型先生成执行计划，再在隔离的Git工作区里并发启动多个子Agent，各自处理子任务，最后再合成结果。

对开发者来说，这一步变化很微妙，但影响结构性很强——上下文不再是唯一工作空间，代码仓库开始成为“第二运行时”。

这种结构直接回应了一个长期问题：单Agent在复杂任务中的能力上限。

动态工作流用的不是“更强的推理能力”，而是拆分执行路径。六种设计模式基本构成了它的骨架：分类执行、扇出合成、对抗校验、生成过滤、双向对决、循环验证。

这些名字看起来像算法设计模式，但实际更像工程化prompt模板，只是从自然语言升级成了可执行脚本。

比如“扇出与合成”，本质是把一个任务拆成多个并行Agent，各自独立生成，再由汇总Agent进行归纳；“对抗校验”则是让两个模型互相审查输出，降低单模型幻觉的概率。

这套体系真正试图解决的，不是能力问题，而是可靠性问题。

不过并发调用带来的token消耗，反而把成本问题推到前台。Agent不是免费扩展算力的工具，它在本质上是放大了计算密度的结构。于是教程里给出的建议也很工程化：控制token预算、用指令约束执行边界、把常用技能模块化。

这些建议听起来不像AI教程，更像云计算成本优化手册。

一个更有意思的变化在开发范式本身。

过去Agent开发依赖“对话调试”，现在逐步转向“脚本编排 + Git版本控制”。开发者不再只是和模型对话，而是在维护一套可执行的智能体系统。这种转变，让Agent更接近传统软件工程，而不是交互式AI产品。

某种意义上，这也是大模型应用层正在发生的分裂：一部分继续停留在聊天式工具层，另一部分开始进入“可编排计算系统”。

动态工作流属于后者。

它并没有让模型变得更聪明，但让模型变得更“可控”。而在Agent系统走向规模化之后，可控性往往比智能本身更重要。