--- layout: post.njk source: https://yage.ai/share/claude-code-workflow-determinism-20260528.html speaker: yage.ai title: |- Claude Code Dynamic Workflow：确定性边界画在了哪里 date: '2026-05-29' summary: 文章分析了 Anthropic 发布的 Claude Code Dynamic Workflow，探讨了在 Agent 系统中如何通过脚本（过程确定性）和 Subagent 自主执行（结果确定性）来平衡可靠性与灵活性。提出通过控制流交给代码、执行交给 Agent、验证交给多 Agent 交叉的设计分工，解决 Agent 长上下文丢失和自我确认误差问题。 area: tech-engineering category: ai-application tags: - agentic-rag - dynamic-workflow - process-determinism - result-determinism - multi-agent-verification people: - Jarred Sumner companies_orgs: - Anthropic products_models: - Claude Code - Bun media_books: [] draft: true status: evergreen --- 如果你做过 RAG 系统，大概率在两个设计之间犹豫过。 一种是传统 RAG：用户提问，程序把它转成查询，搜数据库，把结果喂给模型生成回答。流程是固定的：先搜再回答，不存在”要不要搜”或”搜几次”的问题。这种做法的好处是稳定、可预测、好调试。问题是它有一个硬上限：流程设计者能预见多少种情况，系统就能处理多少种。第一次搜索结果不够好，它不会自己换个关键词再试一次。 另一种是 agentic RAG：你把搜索工具交给 agent，让它自己决定什么时候搜、搜什么、搜几次、搜完要不要继续追。灵活得多，但代价是 agent 需要同时在脑子里记住搜索策略和搜索结果。任务简单的时候还好，但如果你让它做一次多轮、多角度、需要交叉验证的深度调研，搜索策略和中间结果同时挤在同一个 context window 里，agent 就开始丢信息。早期的判断不再被记得，后面的决策失去了基准。 这两个选项之间的张力，不是哪个更好的问题。它们是两种不同的确定性来源：传统 RAG 的信心来自过程：每一步怎么做，代码里写得清清楚楚。Agentic RAG 的信心来自结果：我不规定过程，但我规定终点长什么样，agent 自己决定怎么走到那里。 这不是 RAG 独有的问题。整个 agentic 系统领域都在面对同一个选择：什么东西应该用代码锁死（过程确定性），什么东西应该交给 agent 自主决定（结果确定性）。五月二十八日，Anthropic 发布的 Claude Code dynamic workflow（官方文档，博客），在这个问题上给出了一个具体的回答。 ## 不只是编排 先说明白这个功能是什么。Dynamic workflow 是一个脚本（官方说是 JavaScript），由 Claude 根据你的需求现场生成，由一个独立的 runtime 在后台执行。脚本负责控制流：先做什么、再做什么、什么条件下并行、什么条件下分支。但脚本本身不干活，它只 spawn subagent。每个 subagent 在自己的 context window 里跑，拿到一个具体任务，做完，把结果交回给脚本。 和普通 Claude Code session 的关键区别：在 subagent 模式下，“谁决定下一步做什么”的答案是 Claude，中间结果全在 Claude 的 context 里。在 workflow 里，答案是”脚本”，中间结果在脚本变量里。Claude 不再是编排者——编排者是一段代码。 举个例子。给定一个问题做深度调研，脚本可以把搜索拆成几个角度并行展开，抓取来源，让不同 agent 交叉验证彼此找到的 claim，只返回经过了验证的结果。 但最能说明问题的案例不是这个 demo。Jarred Sumner 用 dynamic workflow 把 Bun 的 runtime 从 Zig 迁移到了 Rust：大约 75 万行代码，十一天。第一个 workflow 分析所有 struct 的 lifetime 映射，第二个 workflow 并行写出所有 .rs 文件（每个文件配两个 reviewer 做验证），第三个 workflow 循环跑 build 和 test 直到通过，第四个 workflow 优化不必要的 data copy。 为什么这么设计，比做了什么更有意思。 ## 边界画在了哪里 把动态工作流和普通 Claude Code session 放在一起看，Anthropic 在一个产品里同时用了两种确定性，画在了一个具体的位置上。 控制流是过程确定性的。JS 脚本规定了每一步做什么、顺序是什么、什么时候并行、什么时候分支、什么时候验证。每次跑同一个脚本，执行路径完全一样。这层之所以要确定，是因为 agent 在长期运行中会丢信息。几十步之后，早期的判断被挤到了 context 窗口边缘，agent 忘了自己在做第几步、下一步该检查什么。脚本解决的就是这个问题：它不会忘。它是一个外部的、持久化的步进器。 执行层是结果确定性的。每个 subagent 拿到脚本分配的任务后，在自己的 context window 里自主决定怎么做：用什么工具、搜什么关键词、找几轮、什么时候停。脚本只告诉它”要什么”和”怎么验证”，不告诉它”怎么做”。这层之所以要 flexible，是因为单个任务的执行路径不可能被预先穷举。如果中间发现了一个意外的数据格式，agent 需要自己调整。如果第一次搜的结果不对，agent 需要自己换个词再试。 验证层同样走的是结果确定性。脚本可以规定验证的步骤（交叉检查、投票、只有经过验证的 claim 才汇报），但”这个 claim 可靠吗”的判断标准是用自然语言写的，由 agent 自主应用。这和 TDD 的做法有本质区别。TDD 里”正确”的定义就是 test suite 跑绿——标准被编码成了可执行程序，agent 没有判断空间。但在 dynamic workflow 里，标准是”这个来源独立吗”“这个推理有漏洞吗”——这些都是 agent 需要自己判断的事。验证协议（投票、聚合）的步骤是过程确定性的，但验证本身的判断是结果确定性的。Anthropic 没有试图把判断写成代码，而是用多个独立 agent 的共识来替代单个 agent 的自我确认。本质上就是用多个独立样本替代单个连续推理链，让验证误差不再同源。 ## 不只是工程决策 这个边界画在哪里，本质上回答了一个问题：在 agentic 系统里，什么东西应该交给代码，什么东西应该交给 agent？ 答案是：agent 做不好的事情，交给代码。具体来说，长期状态管理 agent 做不好，它会忘，所以控制流要写在脚本里，不放在 agent 的脑子里。自我验证 agent 也做不好：同一个推理链里错误是相关的，自己验自己等于没验。所以验证要设计成多 agent 交叉，而不是单 agent 自查。 这不是”代码比 agent 好”的问题，也不是哲学立场的问题。 把视角拉远一点，会发现圈里在面对 agent 可靠性问题时，大致踩在两个极端上。一个极端是”所有东西都用代码”——既然 agent 不可靠，那就回到代码。TDD 是个典型例子：你让 agent 按 TDD 流程写代码（先写测试，再写实现，跑测试，修到通过），每步都用代码级的检查来确保输出正确。但这条路有自己的天花板。近期一项研究发现了一个”TDD 悖论”：当 agent 被要求严格遵守 TDD 流程、但没有被告知哪些测试跟当前改动相关时，它的 regression 率反而从 6% 升到了 10%。纯过程约束在信息不足的时候，可能比没有约束更差。另一个极端是”agent 不够强就让它更强”——更大的 context window、更好的模型、更多的工具。这条路的瓶颈同样是结构性的：再强的模型也解决不了”自己验自己”的问题。 Anthropic 的动态工作流踩在了一个中间位置上。它不是”代码替代 agent”也不是”让 agent 做更多”。它是把问题拆开看：哪些事代码做得更好（控制流不会忘、状态不会漂移），哪些事 agent 做得更好（在模糊边界内探索、根据中间结果动态调整策略），然后把每件事交给最合适的机制。控制流交给脚本，执行交给 agent，验证交给多 agent 交叉。这三者之间的关系不是替代，是分工。 这个判断一旦成立，对 builder 的精力和技能的要求也会跟着迁移。以前你花大量时间在 prompt engineering 上：调整 context 结构、加检查点、写更长的指令来弥补 agent 丢掉的上下文。以后你花时间设计系统边界：这件事 agent 做得好吗？做不好的话用什么替代？替代机制跟 agent 之间的接口长什么样？精力从 prompt engineering 转移到了 system design。 ## 有限但不是缺陷 当然，这个设计有它的边界。 最难的部分没变：定义验收标准。脚本能精确地告诉 agent “现在做 X”，但 X 做到什么程度算够，还是得用自然语言写。这些自然语言的标准，还是由同一个 agent 来解释和执行。验证独立性的问题在控制流层解决了，但在标准定义层仍然存在。agent 可能严格按照流程跑完了全部步骤，每个标准也都”通过了”，但整体结果不是你想要的，因为标准本身就写偏了。 workflow script 本身也是 Claude 生成的。如果 Claude 写了一个有缺陷的脚本（交叉验证的逻辑太弱、分支条件太模糊），这个脚本会可靠地执行一个有问题的计划。 还有一个限制：脚本不能在中途根据中间发现动态修改策略。如果一个阶段的发现表明第二阶段的搜索方向需要完全改变，脚本是做不到的。目前动态工作流最适合的是”plan 可以被预先写清楚”的那类任务：代码审计、大规模迁移、多角度交叉验证的调研。如果任务本身需要探索性的、自适应的规划，它不够用。 但这些限制不改变一个更基本的信号：Claude Code dynamic workflow 是第一个把”过程确定性和结果确定性该在哪个层使用”这个问题做成产品功能的主要 agent 平台。它画的这条线（控制流用代码、执行用 agent、验证用多 agent 交叉）未必是最优解，但它让这个问题从一个哲学讨论变成了一个可以争论、可以对比、可以改进的具体设计。 下一次你搭 agentic 系统的时候，如果 agent 又在跑了几十步之后忘了计划，或又在自我确认一个错误结论，先别急着换模型。问自己：这件事是不是属于”agent 本来就不擅长”的范畴？如果是，有没有可能不是让 agent 做得更好，而是换一种机制来做？