如果你做过 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 做得更好，而是换一种机制来做？