在《AI Workflow Owner：企业正在如何把 AI 变成组织能力》一文中，我曾经提到过，对于 AI 的可复制落地，需要对业务目标有理解的人对其进行工程化的 Workflow 改造。通常在一项业务里，只有部分环节需要 AI 的判断，而不是把整个业务都放进 AI 自由决策的风险当中去。比如说：让 Agent 分析服务异常，智能主要体现在它能否根据线索和素材找到原因，而这个过程中的执行重启需要什么权限、必须通过什么检查，则适合由程序直接处理。Workflow 的价值，就在于把任务变成了把 AI 精准安排在合适上下文环境的可执行流程。 也就是说，体现智能的模型可以专注于分析具体问题本身，已经明确的业务要求则使用稳定的执行方式和流程。

能用程序规则描述清楚的问题，交给 LLM 的推理去决策是对计算资源的浪费。约束让 AI 更好用，因为它减少了模型需要反复判断的负担，也让必要的检查脱离了模型的临时发挥。当 Workflow Owner 设计好一个 Workflow，就意味着这个任务采用的方法经过检验，可以成为后续工作的基础，使用者不必每次重新摸索。

但是，我们也很容易把 Workflow 做成僵硬，难以使用和维护的工具，而这事实上已经发生了。特别有意思的是，历史上不断重演 Workflow 的期待和滥用，每当有新的技术看起来强大而又难以调度时，以 DAG 和图形化编排为代表的 Workflow 就会出现。精美的流程图让决策者们有了更强烈的控制感，但也从一开始就埋下了失败的种子（这其实也是经典的“面向演示的编程”）。

以 AI 应用的角度来说，把 DAG 和图形化编排摆到中心，等于把 AI 的使用负担换成一张画布上的节点与连线。逻辑简单时，节点图清晰直观；可复杂判断一旦散进多个配置窗口，读流程就变成在画布与窗口之间反复来回。同样的一段逻辑，写成程序可以连贯读完，放进图形界面反而要费更多力气。“少儿图形化编程”的印象就是这么来的：形式友好，维护复杂业务却未必轻松。尤其是当 AI 已经能够编写程序，要求工程师亲手把复杂逻辑逐项翻译成节点配置，就更显得缘木求鱼了。人花费精力维护的是一种表达形式，AI 的编程能力却没有充分参与其中。对于这类工作，让 AI 编写 Workflow，比人工维护一张越来越庞大的流程图更合适，因为代码本身就是逻辑最好的承载工具。

而即使跳出了图形化编排的陷阱，我们（以及历史上的人们）又很容易立马陷入到另外一个困境：如何给业务逻辑建模。早期瀑布式的开发流程的基本思想大概可以总结为：规划得越早越详细，实现就能越简单越稳定。但互联网巨头们的成功很快就打击了这个观点，这个世界是不可能事先穷尽的（参考 Frame Problem），动态建立反馈以逐步模拟世界相对会灵活很多。所以在 Workflow 的编排上，面对尚未出现的任务，工程师要预先设想各种情况，把处理方式写进流程。稳定而重复的业务适合这样安排，探索性较强的工作却容易让流程随着新情况不断增加分支。人们试图提前描述尚未掌握的问题，也因此增加了流程的维护成本。此外，如同上一段中讲到 AI 编程能力进一步打击了图形化编排，固定流程的思路同样忽视了 AI 编程可以赋予的能力。

因此，通过 AI 来动态生成 Workflow，然后在 Workflow 中把上下文和工具精准喂给 AI 去执行，才是 Workflow 的正确打开方式。它并不要求工程师提前安排好所有步骤。权限范围可以固定，处理问题的路径可以随任务变化。分析服务异常时，哪些线索有用、需要调用哪些工具，往往取决于当前观察到的情况。运行框架按照人设定的规则检查操作权限，Agent 在允许的范围内组织处理过程。

《Claude Tag：让 Workflow 从工作现场长出来》讲的是 Ahthropic 设计的一种发现 Workflow 的方式。而 Claude 的 Dynamic Workflows，解决的就是如何创建和调用 Workflow 的方式。它于今年 5 月 28 日在 Claude Code 中发布，10 月 9 日扩展到云端托管服务 Claude Managed Agents。Anthropic 希望处理的是单个 Agent 一次难以完成的复杂任务，办法是让 Agent 根据任务生成编排程序，然后由运行框架执行。

这让流程的形成有了一个更合理的时机。面对一个需要审查的代码库，Agent 可以根据当前任务分析怎样拆分工作，把分工写成程序。每个任务可以获得适合自己的组织方式，人们无需为尚未见过的代码库预先画好同一张图。编排本身成为 AI 可以参与解决的问题。

生成的程序承载了已经形成的安排。循环何时继续、结果怎样传递，都可以按程序中的逻辑执行，主 Agent 无须通过一轮轮对话协调每个环节。Anthropic 在文档中把这个区别归结为谁持有工作计划：Dynamic Workflows 让脚本管理编排和中间结果。方法由推理形成，已明确的逻辑交给程序执行，Workflow 原本擅长的正是这样的分工。（BTW，程序管理控制逻辑和中间结果，也有机会减少协调过程中的 Token 开销。）

程序写出来以后，也就成为可以保存和复用的固化成果。Claude Code 支持把一次运行的 Workflow 脚本保存为命令，供后续任务直接调用。初次处理任务时由 AI 生成的方法，经过检查和实际使用，可以固定为一套常用流程。有效的方法不必每次从头产生，因为动态生成的解决方法本身就有了保存和复用的来源。

例如，某个代码库适用的一套审查流程形成以后，后续审查可以沿用同样的分工，也可以沿用同样的检查要求。如果代码变了，Agent 分析的是新的内容，组织工作的方式却保持不变。当业务需求变化时，工程师能够检查和修改已有脚本。固化下来的是经过认可的工作方法，而具体任务的判断则由 AI 完成。

AI 开始为自己的工作编写程序，经过检验的方法可以成为后续 Agent 的工作基础。 一次任务留下的成果，因此包含了解决这类问题的办法。人在实际工作中先发现哪些安排有效，再把它们保存为团队共用的流程。这样一来，某个人偶然成功的方法就可能被改造成其他人稳定使用的流程，个人探索也由此成为组织能力的一部分。

这使 Workflow 成为一种更适合 AI 的工作组织方式。它能够在任务到来时生成，在实践中接受检验，并随着经验积累固定下来。工程师可以把更多精力用在理解业务和验收成果上，判断生成的流程是否准确表达了业务要求。Workflow 既支持 AI 完成复杂工作，也让完成这些工作的经验有了可以保存和复用的形式。