# Claude Code 动态工作流：把确定性边界画在了控制流、执行和验证之间

> 原标题：Claude Code Dynamic Workflow：确定性边界画在了哪里

- 来源：Computing Life · Share · 鸭哥调研
- 发布时间：2026-05-29T00:00:00.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/30540
- 原文：https://yage.ai/share/claude-code-workflow-determinism-20260528.html

## 摘要

Anthropic 给 Claude Code 加了个动态工作流功能，本质是用一段 JS 脚本接管控制流，让脚本决定先做什么、后做什么、什么时候并行，但具体干活还是交给多个子 agent 各自在自己的上下文窗口里跑。这么设计是因为 agent 跑久了会忘事、自己验自己也不靠谱，所以把不会忘的控制流交给代码，把需要灵活探索的执行交给 agent，把验证拆...

## 推荐理由

这篇文章不是 Anthropic 官方发布，也没有实验数据，但它的价值在于把 Claude Code 动态工作流里“哪里该写死、哪里可以放手让模型跑”这个边界问题讲透了。三层机制拆得干净，对正在踩坑的从业者来说，比泛泛讲 agent 靠谱多了。我会先打个折，因为正文没披露具体验证指标，判断更多是架构层面的分析，所以放在 featured 里偏中上的位置。

## 锐评

这篇文章把 Claude Code 动态工作流的设计逻辑讲得很透。核心判断是：agent 长期跑会忘事、自己验自己不靠谱，所以 Anthropic 把控制流交给不会忘的 JS 脚本，把需要灵活探索的执行交给子 agent，把验证拆成多 agent 交叉检查。这个分工思路比“换更强模型”或“全用代码锁死”都更务实。

文章举了 Bun 从 Zig 迁移到 Rust 的例子：75 万行代码，十一天，靠的就是脚本拆任务、并行执行、多 reviewer 验证。数字本身说明这种分工在代码迁移这类可预先规划的任务上效率很高。但文章也坦诚指出了限制：脚本不能中途改策略，验收标准还是得用自然语言写，agent 可能严格跑完流程但结果不对，因为标准本身就写偏了。而且脚本是 Claude 生成的，如果脚本逻辑有缺陷，整个流程会可靠地执行一个错误计划。

信息缺口在于：正文没给出动态工作流相比纯 agent 模式在任务完成率或错误率上的量化对比，也没说明脚本生成失败或需要人工修正的比例。这些数据会直接影响“把编排交给代码”这个主张的可信度。