LLM亲自当调度员是Agent架构最失败的设计

💡 核心论点：让大语言模型逐轮决定下一步操作，好比让CEO亲自去按电梯按钮——不是不能做，而是性价比极低。Anthropic最新推出的Dynamic Workflows，本质上是一场"指挥官卸任"：LLM从编排者转变为被编排对象，这才是Agent架构走向成熟的标志。

● ● ●

11天。75万行Rust代码。99.8%的原有测试通过率。

这是Bun作者Jarred Sumner完成的项目——将整个Bun运行时从Zig迁移到Rust。不是重写，而是平移。就像把一栋精装修公寓从钢筋混凝土结构换成钢结构，住户（API）完全感知不到变化。

完成这项迁移的主力，不是十个高级工程师闭关一个月，而是Claude Code的新功能：Dynamic Workflows（动态工作流）。

Anthropic在5月28日随Claude Opus 4.8一起发布这个功能时，没有大张旗鼓地开发布会，但内行人一看就明白：这不是又加了个"更聪明的Agent"，而是彻底改变了游戏规则。

● ● ●

要理解Workflow为何重要，得先梳理清楚Claude Code已有的几层协作能力。如同游戏角色的技能树，每一层解锁新能力的同时，也暴露新的瓶颈。

第一层：单session。

一个Agent实例从头干到尾，串行处理。你让它改个函数，它改完；再让它改另一个，它再改。简单直接，适合"帮我写个爬虫"这类一次性任务。

第二层：Subagent。

主Agent能派助手了。"你去搜文件、你去读代码、你去跑测试"，完成后把结果汇报回来。听起来很美，对吧？但问题恰恰出在这里——

所有助手的汇报，都要先回到Claude的上下文窗口里。

上下文窗口是什么？可以理解为AI的短期记忆容量。人类的短期记忆大约能同时容纳7±2个信息块，LLM的上下文窗口虽然长得多（几十万甚至上百万token），但它有个致命弱点：信息多了会"稀释注意力"。就像你同时听十个人汇报工作，每个人的声音都变成了背景噪音。

第三层：Agent Teams。

今年年初推出的功能，多个独立的Claude Code实例像团队一样并行协作，成员之间还能互相通信。这已经有点像一个小型开发团队了，但编排者仍然是Claude本身——它逐轮决策下一步派谁去干什么。

这三层有一个共同的瓶颈：指挥官始终是Claude自己。

当任务规模不大时，这很灵活。Claude可以根据中间结果随时调整策略，像个经验丰富的项目经理。可一旦要协调几十上百个并行任务，问题就来了：上下文窗口装不下那么多中间结果，Claude的注意力也会被海量的过程信息稀释成一碗白开水。

● ● ●

Dynamic Workflows换了个思路。这一次Claude不再亲自逐轮调度，它先把整个编排过程写成一段JavaScript脚本——循环、分支、中间结果的收集全都固化在代码里——再交给一个独立的运行时去执行。

用Anthropic自己的话说：

翻译成人话：计划被搬进了代码。脚本自己持有循环、分支和中间结果，Claude的上下文里只剩下最后那个答案。

这个分工极其精妙：

● JavaScript运行时当指挥：它只会循环、拼字符串、await，本身不含任何LLM，是个"无脑"的确定性执行器。

● agent()按需调用LLM干活：只有当脚本执行到`agent(...)`那一行，运行时才去spawn一个subagent，调用模型的方式和主对话窗口完全一样。

● 主Agent全程在休眠："真正的Agent"——也就是你正在对话的主Claude——在脚本执行期间根本没在运行。它在发出Workflow调用后那一回合就结束了，脚本在后台独立跑，跑完用一条通知把它叫醒，让它去读最后的结果。

一句话概括：JavaScript运行时当指挥（无脑、确定性），在agent()点按需调用LLM干活，主Agent全程在休眠，只在最后被叫醒读结果。

这就像什么？就像你请了一个极其靠谱的行政助理。你把"本周所有会议安排"写成一份详细的执行清单给她，她自己去联系各方、预定会议室、处理冲突，只在最后拿一份汇总表给你签字。你不需要旁听每一通电话。

● ● ●

Workflow不是魔法，它是一个精心设计的四件套：

1. Workflow脚本：JS代码，定义编排逻辑。这是"作战计划"。

2. Workflow运行时：本地JS运行时，执行脚本。这是"传令兵"。

3. Subagent：`agent()`调用派生的LLM工作者。这是"前线士兵"。

4. 结果收集器：汇总subagent输出，只返回关键结果。这是"战报筛选员"。

这里的关键设计是：脚本本身无文件系统/shell权限。它不能擅自删库跑路，只能通过subagent去间接操作。这是一个很克制的安全边界——让"无脑"的运行时保持"无脑"，不给它犯错的机会。

同时，Workflow内置了journal缓存机制，支持可恢复性。如果执行过程中断，可以从断点继续，而不是从头再来。这对于动辄几小时的迁移任务来说，是救命的设计。

● ● ●

这个对比表揭示了一个容易被忽视的事实：Workflow的真正护城河不是"能并行跑更多Agent"，而是"可复用的编排逻辑"。

Subagent复用的是"一个工作者"——你训练了一个擅长读代码的助手，下次还能用。Skills复用的是"一条指令"——你写了一个"生成单元测试"的prompt模板，下次直接调用。

但Workflow复用的是一整套编排逻辑。"如何把一个大型迁移任务拆成1000个subagent、如何组织pipeline、如何处理失败重试"——这些经验被固化成了一段JavaScript代码。下次遇到类似的迁移任务，改改参数就能跑。

💡 核心论点：在AI工程化时代，"会写prompt"的门槛越来越低，"会设计编排逻辑"才是核心竞争力。Workflow让这种能力变得可积累、可复用、可分享。

● ● ●

Workflow提供了几个核心原语，其中最值得关注的是`parallel()`和`pipeline()`。这两个函数的区别，体现了Anthropic工程师对并发模型的深刻理解。

● `parallel(tasks)`：并行执行，有屏障（barrier）。等全部任务完成才继续。

● `pipeline(items, ...stages)`：让每个item独立流过所有stage，无屏障。

很多人第一反应是：并行嘛，当然是`parallel()`更厉害。但Anthropic明确告诉你：大多数并行任务用barrier是浪费。

为什么？因为barrier意味着"等人到齐"。你派了100个助手去搜资料，其中99个5分钟就跑完了，剩下1个卡在某个奇怪的文件里搞了半小时。如果用了barrier，那99个早就干完活的助手只能干等着——而Claude的上下文窗口也在等着，什么都不能做。

`pipeline()`的无屏障设计聪明在哪？它让每个item各自独立流过所有stage，不需要等别人。就像工厂的流水线：第一个零件进入焊接环节时，第二个零件已经在切割了，第三个还在进料——没有"全班到齐才上课"的浪费。

Anthropic甚至给出了明确的判断标准：只有三种情况才需要barrier——

1. 全集去重/合并：必须拿到所有结果才能去重；

2. 根据总数提前退出：比如"找到5个有效答案就停"；

3. 跨item横向比较：比如"选出最好的三个方案"。

其他情况？用pipeline，让数据流起来。

● ● ●

Bun迁移的案例被Anthropic当作Workflow的王牌战绩来宣传，但作为一个有判断力的读者，我们需要问一句：99.8%的测试通过，真的等于代码质量过关吗？

这里有几个值得警惕的点：

第一，测试覆盖率不等于正确性。

The Register确认Bun迁移实际超过100万行代码（不是Anthropic宣传的75万行），5月14日PR合并。但"原有测试通过"只说明"没破坏已知行为"，不说明"新代码没有引入新的bug"。就像你装修完房子，所有灯都能亮，不代表墙里没有多打几个洞。

第二，Hacker News社区的激烈讨论不是无的放矢。

社区对AI生成代码质量的担忧集中在几个方面：边界情况处理、性能回归、代码可读性和可维护性。AI很擅长"让测试通过"，但不太擅长"写出让人类愿意维护的代码"。

第三，Token消耗和递归风险是真实成本。

社区反馈Workflow的Token消耗很高——毕竟spawn了成百上千个subagent，每个都要调用模型。而且如果编排逻辑设计不当，可能出现递归风险：一个subagent spawn另一个subagent，层层嵌套直到失控。

💡 核心论点：99.8%测试通过是一个漂亮的营销数字，但工程决策不能只看通过率。Bun迁移的真正价值在于证明了Workflow的"规模可行性"，而不是"AI已经可以替代资深工程师做架构迁移"。

● ● ●

让我们回到文章的标题：LLM亲自当调度员是Agent架构最失败的设计。

这句话不是贬低LLM的能力，而是指出一个架构层面的反模式。LLM的强项是什么？理解复杂需求、生成创意方案、处理模糊输入、进行推理判断。LLM的弱项是什么？精确控制、确定性执行、大规模状态管理、避免注意力稀释。

让LLM逐轮调度subagent，等于让它的弱项去承担核心职责，同时浪费它的强项。

Dynamic Workflows的范式转移在于：LLM不再是编排者，而是被编排的对象。

Claude的角色从"指挥官"变成了"作战计划撰写者"。它一次性地把"怎么打"想明白，写成脚本，然后交棒给一个确定性的运行时去执行。这有点像军事史上的一个规律——

拿破仑可以亲自指挥一场战役，但他无法亲自指挥一场战争。战争需要参谋部把战略意图转化为可执行的作战计划，再由各级指挥官分头执行。LLM当"拿破仑"没问题，但别让它当"参谋部+传令兵+前线连长"的合体。

● ● ●

如果你读到这里，应该已经理解了Workflow的价值和边界。最后，一份可以直接落地的行动建议：

✅ 重新审视你的Agent架构：如果是LLM在逐轮调度，考虑哪些决策可以"前置"到脚本里

✅ 从"写prompt"进化到"设计编排逻辑"：prompt工程正在商品化，编排设计才是护城河

✅ 理解pipeline和parallel的适用场景：别让barrier成为性能瓶颈

✅ 对"AI完成大型迁移"保持审慎乐观：规模可行性 ≠ 质量可靠性，人工review仍是必须

✅ 关注可复用性：把你成功的Workflow脚本沉淀为团队资产，而不是一次性用完就扔

✅ 预留Token预算和递归防护：大规模Agent并行的成本和安全边界需要提前设计

● ● ●

Anthropic用Dynamic Workflows讲了一个简单的道理：最聪明的调度方式，是让调度本身不再需要聪明。

当编排逻辑被写成代码，它就获得了确定性、可复用性和规模扩展性。LLM从繁琐的"下一步该干什么"中解放出来，专注于它真正擅长的事——理解问题、生成策略、处理意外。

Bun的75万行（或100万行）迁移是一个惊艳的概念验证，但它更重要的意义是展示了Agent架构的进化方向：从"一个超级大脑包办一切"，到"大脑制定战略、脚本执行战术"的分层协作。

这场"指挥官卸任"的革命，才刚刚开始。

● ● ●

本文基于Anthropic 2026年5月28日发布的Dynamic Workflows及相关技术文档撰写。部分数据引用自The Register、TechCrunch、Hacker News等公开报道。