Dynamic Workflows：把 Claude Code 从聊天工具变成程序

用 Claude Code 做过大任务的人，多半踩过同一个坑。

你让它分析 50 个文件，它分析了 30 个就停了，还信心满满地跟你说"任务完成"。或者你开了一个很长的 session，方向在不知不觉中偏掉，等你回过神来，最初的目标早就面目全非。

这两个问题有一个共同根源：当前的 Claude Code 本质上还是一个聊天界面。你在和它对话，而对话是模糊的、有状态漂移的。

Dynamic Workflows 要解决的，就是这个根本矛盾。

它到底是什么

Dynamic Workflows 的核心思路是：Claude 不再只是回答你的问题，而是帮你写一段 JavaScript 程序，用这段程序来调度多个子 Agent。

结构很清晰：你有若干个 Agent，每个 Agent 有自己的模型和职责，相互之间的上下文完全隔离。这些 Agent 可以并行跑，也可以串成流水线，前一阶段全部完成才推进下一阶段。

因为是在跑一段程序，任务执行变成确定性的。你让它处理 50 个文件，它就会起 50 个（或批量的）子 Agent，每一个都要跑完，没有"差不多就行"的空间。

这解决了三个长期存在的问题：

第一，Agent 懒惰。 主 Agent 面对大任务容易提前收工。程序不会，程序跑完就是跑完。

第二，自我偏好偏差。 在单一 Agent 的长 session 里，它倾向于给自己的早期结论打高分。子 Agent 各自持有独立上下文，没有这个包袱。

第三，目标漂移。 session 越长，偏离初始目标的概率越高。短生命周期的子 Agent 只做一件事，做完即止。

博主 Artem 连续发了三个实操案例，值得仔细看。

他对 Claude 说了一句话：

go through my last 50 sessions and mine them for the corrections I keep making and turn them into CLAUDE.md rules

Claude 生成了一个三阶段 workflow：第一阶段用 10 个并行 Agent 从 session 里提取修正记录；第二阶段用一个 Agent 聚类分析；第三阶段把结论与现有 CLAUDE.md 对比，给出修改建议。

结果：分析了 49 个 session，挖出 86 条修正。最后产出一份 HTML 报告，每条规则都附有原始 session 里的真实引文。

Artem 的判断很有意思：他不打算把这些规则直接写进 CLAUDE.md，而是把它们打包进对应的 skill，让 skill 来吸收这些教训。这个思路值得借鉴。

31 篇日记，给每篇日记起一个 Haiku 子 Agent（速度快、成本低），然后用 Opus 子 Agent 跨全部笔记做聚类综合。

Haiku 那一层几乎是实时跑完的。最终报告里，每一个重复模式都附有对应的日期和原文 bullet point，可以追溯到原始记录。

这个用例说明 Dynamic Workflows 不只是给开发者用的，任何有大量结构化文本要处理的人，都可以套这个模式。

他把 NotebookLM 里存的每日摘要视频的文字稿喂进去，让 workflow 完成：提取文字稿 → 分析可以落地的想法 → 为每个想法生成一段可以直接粘贴到 Claude Code 的 prompt。

产出是一块"想法看板"，每张卡片对应一个想法，配一段即开即用的 prompt。

Artem 提到了一个他自己摸索出来的最佳实践：不要把 workflow 当成独立实体来维护，把它嵌进 skill 里。

他的做法是：每个 skill 目录下，除了 skill.md，还放一个对应的 JavaScript workflow 文件。当这个 skill 需要跑多 Agent 任务时，Claude 就调用这个文件。workflow 和 skill 绑定，不单独漂浮。

这样你只需要维护一套东西：skill。workflow 是 skill 的内部实现细节，不对外暴露。

这个思路和 Deep Modules 的设计哲学是一致的：把复杂性封装在内部，对外暴露简单接口。

除了 Artem 演示的这三种，Dynamic Workflows 还有几个典型模式可以探索：

这些模式的共同特征是：任务量大、需要并行、每个子任务的独立性强。只要满足这三条，就值得考虑用 workflow 来跑，而不是塞给主 Agent 一个超长 prompt 祈祷它不偷懒。