效率暴涨的背后：Claude Code动态工作流，正在埋下新的技术债？

快速阅读：Anthropic 为 Claude Code 推出了动态工作流（Dynamic Workflows），允许模型通过调度数十甚至数百个并行子代理来处理超大规模任务（如代码库迁移或大规模漏洞扫描）。虽然它展示了极高的工程效率，但也引发了关于“Token 消耗黑洞”与“代码质量债务”的激烈争论。

Anthropic 最近给 Claude Code 加上了一个名为 Dynamic Workflows 的功能。简单来说，它不再是让你跟一个智能体单聊，而是让 Claude 自己写脚本去调度成百上千个子代理，像工厂流水线一样并行干活。

这种模式在处理“重型工程”时确实很猛。比如把 Bun 从 Zig 迁移到 Rust，这种涉及几十万行代码、需要反复跑测试、查生命周期的问题，靠人工写 Prompt 几乎不可能。它通过“对抗式”逻辑，让一部分代理干活，另一部分代理专门找茬，直到结果收敛。这有点像是在系统层构建了一个临时的、任务驱动的分布式计算集群。

但这种“暴力美学”也让不少资深开发者感到不安。

有网友直言，这听起来像是一个高级的 Token 燃烧器。如果模型本身存在逻辑偏差，那么并行规模越大，产生的“代码垃圾（Slop）”就越恐怖。就像有人遇到过模型为了实现功能，在代码里疯狂堆砌强制类型转换，这种由于设计缺陷导致的“技术债”，靠增加代理数量并不能解决，反而可能让问题在自动化循环中被无限放大。

更有意思的讨论在于“正确性”与“共识”的博弈。

大家普遍担心，如果多个代理通过“共识”达成了一致，但这个共识本身是基于错误的理解，那结果依然是错的。测试用例能验证代码“跑得通”，但无法验证代码“写得好”。如果设计本身就偏了，代理们只会以极高的效率，把一个错误的设计实现得极其完美。

这种感觉很矛盾。一方面，它确实在把原本需要几周的迁移工作缩短到几天；另一方面，它似乎在把软件工程从“逻辑构建”推向一种“概率博弈”。当开发者不再是编写者，而变成了在成百上千个自动化动作中寻找异常的监视器时，我们到底是在提升生产力，还是在为一个不可控的黑盒支付高昂的订阅费？

也许，真正的挑战不在于如何让代理跑得更快，而在于如何让它们在跑偏之前，听得懂那句“别写这么烂”。

claude.com/blog/introducing-dynamic-workflows-in-claude-code