Claude动态工作流：真实体验
大多数AI智能体系统只给你结果。
Claude的新动态工作流给你结果以及产生结果的过程。
这听起来像是一个小差异，但使用之后，我认为这可能是Anthropic发布的最重要的东西。
AI智能体的营销方式和在真实工程问题上实际使用它们之间存在差距。
大多数智能体系统遵循一个熟悉的模式。你启动一批智能体，它们并行工作，结果开始返回，一些有用，一些错误，而你有责任把一切整合在一起。
智能体做了工作，但协调仍然发生在你的头脑中。
Claude Code的新动态工作流于5月28日发布，感觉像是试图解决这个问题。
在使用它们之后，我认为最重要的部分不是它们能运行的智能体数量。而是工作完成后协调逻辑会发生什么。
1、触发工作流时实际发生了什么
起初，动态工作流看起来只是另一种运行更多智能体的方式。
它们不是。
当你描述一个任务时，Claude不会立即开始生成智能体。相反，它首先在后台生成一个JavaScript编排脚本。
把这个脚本想象成整个操作的项目经理。
它定义了：
- 工作的各个阶段
- 每个阶段应该运行哪些智能体
- 每个智能体负责什么
- 工作流可以继续前进之前必须满足的条件
最有趣的架构细节是这个工作流在哪里运行。
与正常的聊天对话不同，工作流在与你的对话分离的隔离运行时中执行。
这很重要，因为中间结果不会持续推回到聊天上下文中。
相反，它们存储在编排脚本本身管理工作流变量中。
在实践中，这意味着Claude可以协调数百个智能体而不会填满上下文窗口或将对话变成不可读的中间输出流。
工作流记住了发生了什么。你的聊天不需要。
目前有两种触发工作流的方式。
第一种是显式的：只需在你的提示中包含 "workflow"这个词，Claude会自动生成一个。
第二种是通过/effort ultracode，它启用Claude的最深推理模式。在这种模式下，Claude根据任务的复杂性决定是否需要工作流。在撰写本文时，Ultracode需要Opus 4.7或Opus 4.8。
Anthropic目前执行两个重要限制：
- 最多16个智能体并发运行
- 每次工作流运行最多1,000个智能体的硬性上限
这些限制听起来可能很高，但它们的存在是有原因的。
一旦你协调数百个智能体，生成输出就不再是困难的部分。编排工作、验证结果、处理依赖关系以及决定一个阶段何时完成成为同等重要的问题。
这才是动态工作流真正在解决的问题。
2、Bun重写数字
为了展示动态工作流，Anthropic分享了一个涉及Bun运行时的案例研究。
对于不熟悉的人，Bun是一个最初用Zig编写的高性能JavaScript运行时。作为实验的一部分，动态工作流被用来用Rust重写代码库。
报告的结果立即引起了关注：
- 大约750,000行生成的Rust代码
- 99.8%的Bun现有测试套件通过
- 从第一次提交到合并仅用了十一天
无论你是否相信AI能否替代工程师，这些数字都很难忽视。
更有趣的是迁移是如何执行的。
不是要求单个智能体重写整个代码库，而是将工作分成三个不同的工作流阶段。
阶段1：生命周期分析
在任何代码被翻译之前，工作流专注于Rust最具挑战性的概念之一：生命周期。
第一阶段分析了整个代码库，并为结构体字段和引用映射了正确的生命周期注解。
这听起来可能像一个小细节，但任何使用过Rust的人都知道生命周期管理通常是大规模迁移中最困难的部分之一。
通过首先解决生命周期关系，工作流建立了后续翻译阶段可以一致遵循的约束。
换句话说，它在任何代码生成开始之前就减少了一个重要的下游错误源。
阶段2：并行翻译
生命周期分析完成后，工作流进入代码翻译阶段。
数百个智能体并行工作，每个负责将特定的Zig文件转换为Rust。
但这不是一个简单的"生成然后祈祷"的过程。
每个翻译文件在被接受之前都由两个额外的智能体独立审查。
这意味着工作流不仅在扩展代码生成。
它也在扩展代码审查。
这种并行生成和并行验证的组合是动态工作流更有趣的方面之一，因为它反映了工程团队在实践中的运作方式。
阶段3：优化
翻译阶段完成后，工作流切换到优化模式。
智能体扫描生成的Rust代码，寻找转换过程中引入的不必要的数据拷贝和其他低效问题。
目标不仅仅是功能正确性。
目标是使生成的代码更像经验丰富的Rust开发者编写的代码。
这个清理阶段在大部分迁移已经完成后运行，允许优化工作独立于翻译进行。
为什么99.8%的数字很重要
最令人印象深刻的数字不是75万行代码。
而是99.8%的测试通过率。
根据Anthropic的说法，这个结果主要由他们所说的对抗性验证驱动。
一些智能体执行工作。
其他智能体的任务是找出工作中的错误。
工作流不会自动信任它收到的第一个答案。
相反，结果在被挑战、审查和验证之后才会进入下一阶段。
简化版本看起来像这样：
这与要求单个AI智能体生成代码并希望它做对一切的传统方法非常不同。
工作流只有在多个智能体就结果达成一致后才继续前进。
3、真正的创新不是智能体数量
头条关注智能体数量。
我不认为那是最有趣的部分。
Cursor有/multitask。
GitHub Copilot有/fleet。
OpenAI的工具支持并行子智能体。
并行运行多个智能体正在成为AI编码工具的标准能力。
真正的差异在工作完成后出现。
对于大多数多智能体系统，输出是产生的代码。
产生该代码的过程消失了。
你最终可能获得一个成功的迁移、一份安全报告或一个完成的重构，但协调所有工作的编排逻辑已经消失。
下次你想要执行类似任务时，你实际上是在重新开始。
动态工作流采取了不同的方法。
当工作流完成时，Claude将编排脚本保存到.claude/workflows/。
工作流本身变成了一个制品。
你可以检查每个阶段。
你可以看到创建了哪些智能体，它们收到了什么指令，以及执行继续之前必须满足什么条件。
你可以保存它、版本化它、修改它，稍后再运行它。
这改变了输出的性质。
结果不再只是代码。
结果是：
- 产生的代码
- 产生它的过程
而那个过程是有价值的。
它可以在拉取请求中审查。
它可以与队友分享。
它可以跨代码库复用。
它可以随时间改进。
想象一下构建一次安全审计工作流，然后在你组织拥有的每个服务上运行它。
想象一下创建一个迁移工作流，团队中每个工程师都使用它。
想象一下通过给新工程师一个工作流来入职。
过程变成了可执行的。
对于金融、医疗、政府和其他受监管行业的组织来说，这可能更重要。
工作流脚本可以在执行前审查。
它可以被批准。
它可以被版本控制。
它可以几个月后被审计。
聊天对话不是为此设计的。
工作流文件是的。
这就是为什么我认为Anthropic发布的最重要的东西不是运行更多智能体的方式。
它是保存工作背后的编排的方式。
4、什么时候它是错误的工具
动态工作流不是每个问题的答案。
两个文件的bug修复不需要工作流。
重命名变量不需要工作流。
简单任务使用单个提示通常更快。
成本是另一个考虑因素。
Anthropic没有发布详细的工作流定价基准，独立数据仍然有限。清楚的是，协调数百个智能体比标准对话交互消耗更多资源。
在扩大规模之前在小范围内测试可能是最安全的方法。
还有一些操作限制。
你可以暂停或停止工作流，但你不能在执行中途轻松地重定向它。
如果你的任务需要频繁的人工判断，带有持续监督的直接子智能体可能仍然更合适。
一个让很多人惊讶的实现细节是工作流子智能体无论你的会话设置如何都以acceptEdits模式运行。
文件修改会被自动批准。
对于只读审计，这不是主要问题。
对于一个能够修改数百个文件的工作流，在按回车之前值得了解这一点。
执行状态也与当前会话绑定。
工作流脚本可以保存并稍后复用，但如果会话结束，正在运行的工作流不会存活。
5、自己试试
理解动态工作流最简单的方法就是运行一个。
打开Claude Code，使用"workflow"这个词描述一个任务。
例如：
"workflow：扫描此仓库的安全漏洞并独立验证每个发现。"
Claude将生成编排脚本，显示工作流阶段，并开始在后台协调智能体。
运行完成后，按s保存工作流。
你现在有了一个存储在.claude/workflows/中的可复用工作流，可以检查、修改、版本控制和与团队分享。
6、最终想法
行业目前痴迷于智能体数量。
100个智能体。
500个智能体。
1,000个智能体。
这不会永远是一个差异化因素。
一年后，每个主要的编码助手可能都支持大规模并行执行。
更有趣的问题是计划是否在工作完成后存活。
大多数系统给你结果。
动态工作流给你结果以及背后的编排。
而这可能最终成为更重要的创新。
原文链接：I Ran Claude's New Dynamic Workflows. The Bun Rewrite Makes More Sense Now
汇智网翻译整理，转载请标明出处