◢◤ DYNAMIC WORKFLOWS ◢◤

当AI自己锻造刀刃时，人的角色是什么

Claude Code 动态工作流的思想考古

◈ 一、引子：当工作记忆成为瓶颈

你有没有过这样的经历：同时参加三个会议，每个会议的信息都在脑子里打架，最后你发现自己什么都不记得了？

这不是你的错。1956 年，乔治·米勒在《心理学评论》上发表那篇著名的《神奇的数字 7±2》时，他真正想说的不是"人脑能记住 7 样东西"，而是人脑的意识带宽有硬上限。后来纳尔逊·科万把这个数字修正到更残酷的 3-5 个"组块"。也就是说，你的意识——那个你称之为"我"的东西——在同一时刻只能稳定地握住 3 到 5 个概念。

传统 AI 辅助编程，本质上就是在强迫一个"数字大脑"做同样的事。你给一个智能体下达复杂指令，它开始推理、搜索、修改文件、运行测试……所有中间结果都必须塞回那个被称为"上下文窗口"的有限空间。就像一个人试图同时记住二十个对话的每一个细节，直到认知负荷崩溃。

Claude 代码工具（Claude Code）在今年 2 月推出的智能体团队（Agent Teams）某种程度上缓解了这个问题：你把任务拆给几个预设角色的智能体，像前端专家、后端工程师、质量工程师各司其职。但这里有一个隐含的假设——<你必须事先知道怎么拆。你要像指挥交响乐团一样，在演出开始前就确定每个乐手的谱子。

而现实工程中最痛苦的任务，恰恰是那些你不知道该怎么拆的：一个遗留系统的全量安全审计、一个框架迁移的依赖分析、一个架构方案的应力测试。这些任务的共同特征是"未知的未知"。你甚至不知道问题空间有多大，又怎么预设角色分工？

2026 年 5 月 28 日，Anthropic 发布了动态工作流。官方博客的标题很克制："在 Claude 代码工具中引入动态工作流"。但在我看来，这不是一个功能发布，而是一次关于认知如何分布式展开的工程化尝试。它的野心不在于"并行运行更多智能体"，而在于回答一个更古老的问题：当一个系统的复杂度超过任何单一节点的处理能力时，这个系统如何不崩溃，反而涌现出更高阶的智能？

◈ 二、动态工作流是什么：官方叙事之外的解读

让我先陈述事实，基于 Anthropic 官方文档和博客：

• 动态工作流与 Claude Opus 4.8 一起发布，目前处于研究预览阶段。

• 它的核心机制是：Claude 根据你的提示词动态生成 JavaScript 编排脚本，由独立运行时在后台执行。

• 脚本可以并行调度最多 16 个并发智能体，单次运行上限 1000 个智能体。

• 所有中间结果保存在脚本变量中，而不是回流到主会话的上下文窗口。

• 支持对抗性验证：一组智能体提出方案，另一组智能体专门寻找漏洞，迭代直到收敛。

• 两种触发方式：在提示词中包含"workflow"关键词，或开启超代码模式（超高努力 + 自动判断）。

• 运行可中断、可恢复，进度保存在运行时状态中。

• 典型案例：贾里德·萨姆纳使用动态工作流将 Bun 从 Zig 迁移到 Rust，约 75 万行代码，11 天完成，99.8% 测试通过（但官方注明"尚未投入生产"）。

现在，让我说出官方文档不会告诉你的事。

2.1 "计划存在于代码中，而非上下文窗口中"

这是架构上最深刻的改变。传统子智能体模式中，Claude 是唯一的编排者：它每轮决定生成什么智能体，每个智能体的结果都回到 Claude 的上下文窗口，由 Claude 决定下一步。这意味着计划的载体是内存——而且是极易溢出的内存。

动态工作流把计划移到了代码里。编排脚本持有循环、分支、中间状态，Claude 的上下文窗口只保留最终结果。这就像从"脑子里记住所有待办事项"进化到"写一张待办清单，让团队按清单执行"。

当我读到官方文档里那句"该脚本协调智能体；脚本本身没有直接的文件系统或 shell 访问权限"时，我意识到这不仅是安全设计，更是一种函数式编程哲学——编排层是"纯函数"，副作用被隔离在子智能体层。这让我想到 React 的声明式 UI：你说"我要什么状态"，React 决定怎么操作 DOM；动态工作流中，你说"我要什么结果"，运行时决定怎么调度智能体。

2.2 对抗性验证：不是测试，是负反馈调节

官方描述说："智能体从独立的角度处理问题，其他智能体试图反驳它们发现的结果，运行不断迭代直到答案收敛。"

这不是传统的单元测试。单元测试是前馈验证——你写断言，代码跑一遍，通过或不通过。对抗性验证是闭环反馈——系统持续检测自身偏差并修正，直到达到稳态。这让我立刻想到诺伯特·维纳在 1948 年的《控制论》中描述的负反馈调节：恒温器不是"知道"室温应该是多少，而是通过持续比较设定值和实际值，动态调整加热功率。

动态工作流的对抗性验证，本质上是一个认知恒温器。它不知道"正确答案"是什么，但它知道"当前答案还不够好"，于是驱动系统向更低误差的方向演化。

◈ 三、与传统工作流的根本区别：从开环到闭环

为了理解动态工作流的颠覆性，我们必须先理解传统工作流是什么。

传统工作流——无论是 BPMN、Airflow、n8n 还是 Temporal——有一个共同假设：工程师必须事先知道所有分支和边界条件。你画 DAG 图，定义每个节点的输入输出，预设错误处理路径。这是开环控制：输入 → 处理 → 输出，一切可预测，一切在控制中。

这种范式在工业时代是伟大的。福特的流水线、丰田的精益生产，都是开环控制的巅峰。但软件工程不是汽车制造。软件工程中的"原料"（需求、代码、依赖关系）每天都在变化，"工艺"（最佳实践、框架版本）每季度都在过时。当你面对一个遗留系统的安全审计时，你不可能事先知道所有漏洞位置；当你面对一个框架迁移时，你不可能事先画出所有文件的依赖图。

动态工作流的回应是：把闭环控制引入编排层。它不预设路径，而是运行时根据提示词动态分解任务；它不预设验证规则，而是让智能体互相挑战直到收敛。

传统工作流就像工厂流水线，动态工作流就像急诊室——你不知道下一个病人是什么，但你知道有一套自适应的响应机制。

如果是，那我们作为工程师的核心技能，是否要从"写正确的代码"转向"设计正确的边界条件"？

◈ 四、与智能体团队的区别：交响乐团与爵士乐即兴

今年 2 月，Claude 代码工具推出了智能体团队。你可以预设角色：前端专家负责 UI 组件，后端工程师负责 API 设计，质量工程师负责测试。它们像一支交响乐团——固定编制，排练好的曲目，每个乐手知道自己的位置。

动态工作流则像爵士乐即兴。它不知道任务需要什么角色，直到你告诉它问题，它才临时组建乐队。没有预设的前端专家，只有"当前这个任务需要有人分析 React 组件依赖"——然后一个智能体被派出来做这件事，做完就解散。

这个"空白"是什么？是已知未知与未知未知之间的地带。

• 智能体团队：当你知道角色分解时（已知未知）。你知道你需要前端、后端、QA，你只是需要它们协作。

• 动态工作流：当你还不知道如何分解时（未知未知）。你不知道一个遗留系统的漏洞分布，你不知道一个迁移任务的依赖复杂度，你甚至不知道应该问什么问题。

这让我想到组织行为学中的经典区分：职能部门 vs 项目制组织。智能体团队是职能部门——每个角色有固定职责，长期协作。动态工作流是项目制——临时组建，任务完成即解散。

赫伯特·西蒙在《管理行为》中分析过这两种组织形式的优劣。职能部门的优点是专业化深度，缺点是跨领域协调困难；项目制的优点是灵活响应，缺点是资源重复配置。动态工作流的巧妙之处在于，它用计算资源替代了人力资源的重复配置问题——生成 100 个智能体的成本是 token，不是招聘和培训。

但我好奇的是：当一个团队同时使用智能体团队和动态工作流时，权力结构如何设计？谁来决定什么时候用"交响乐团"，什么时候用"爵士乐即兴"？在超代码模式下，这个决策权被让渡给了模型。这是效率提升，还是一种微妙的控制转移？

◈ 五、上游理论：控制论、认知科学与涌现

现在，让我们向上游追溯。动态工作流不是凭空出现的，它是一系列古老思想在 AI 时代的工程化投影。

5.1 控制论：诺伯特·维纳，1948

维纳创造"控制论"这个词时，取自希腊语的"舵手"。他的核心洞察是：一个系统的稳定性不来自完美设计，而来自信息反馈。恒温器、生物体内环境、社会经济系统，都遵循同一套原理：感知 → 比较 → 行动 → 再感知。

动态工作流的对抗性验证，就是这个原理的直接映射：

• 一组智能体提出方案（行动）

• 另一组智能体检测漏洞（感知）

• 比较发现偏差（比较）

• 修正方案（再行动）

• 循环直到收敛（稳态）

这不是"多找几个人干活"，这是在构建一个自我纠正的认知系统。维纳如果活到今天，可能会说："看，我 1948 年说的反馈循环，现在被写成了 JavaScript 脚本。"

5.2 分布式认知：埃德温·哈钦斯，1995

哈钦斯的经典研究是飞机驾驶舱。他发现，飞行员的安全着陆不仅依赖于飞行员的个人记忆和技能，还依赖于仪表盘的布局、检查单的设计、机组人员的对话流程。认知超越了单个大脑，分布在人、工具、环境构成的系统中。

动态工作流是哈钦斯理论的数字版本：

• 认知不再局限于单一模型，而是分布在编排脚本、运行时状态、子智能体的独立上下文、文件系统的修改记录中。

• 编排脚本就是"检查单"——它不记得所有细节，但它知道去哪里找细节。

• 子智能体是"机组人员"——每个只负责自己的仪表，但共同完成着陆。

在动态工作流中，"专业能力"不仅存在于 Claude 的权重中，也存在于脚本如何组织智能体的结构里。

5.3 有限理性：赫伯特·西蒙，1947

西蒙是诺贝尔经济学奖得主，但他研究的不是市场，而是真实的人如何做决定。他发现，真实决策者受限于时间、信息、认知能力，不可能找到最优解，只能追求"满意解"——差不多行了。

单个大语言模型智能体就是典型的"有限理性行动者"：

• 上下文窗口有限（信息约束）

• 推理深度有限（计算约束）

• 单次响应时间有限（时间约束）

动态工作流的回应是西蒙式的：用组织设计弥补个体认知局限。多个有限理性的智能体并行工作，通过对抗验证互相修正，最终产生的全局结果超越任何单个智能体的能力。这正是西蒙所说的："组织的正式结构帮助修正认知局限。"

西蒙还有一个著名的"剪刀"隐喻："人的理性行为……由两片刀刃决定，一片是任务环境的结构，一片是行动者的计算能力。" 动态工作流改变的不是单一边，而是整个剪刀的形状——它让 AI 自己决定任务环境的结构。

5.4 复杂自适应系统与涌现：圣塔菲研究所，1990 年代

约翰·霍兰德在《涌现：从混沌到秩序》中研究了一个问题：蚂蚁没有中央大脑，蚁群如何建造精密的巢穴？答案是涌现——从局部简单规则的交互中，自发产生全局秩序。

动态工作流让我看到"涌现式编程"的雏形：

• 每个子智能体只遵循局部规则（"分析这个文件的依赖"、"检查这个函数的安全漏洞"）

• 没有中央节点知道全局最优解

• 但通过编排脚本的协调和对抗验证的筛选，全局层面产生可靠结果

霍兰德警告过："工程化涌现的问题在于，要为复杂的模式找到简单的规则。" 动态工作流的"简单规则"就是：分解任务、并行执行、对抗验证、迭代收敛。它的"复杂模式"是：75 万行代码的框架迁移、全量安全审计、跨文件架构重构。

但霍兰德也提醒我们，涌现不可预测。你无法从蚂蚁的局部规则推导出巢穴的全局形状。同样，你无法从动态工作流的脚本推导出最终输出的精确形态。这是它的力量，也是它的风险——我们获得了突破个体认知上限的能力，却失去了对输出形态的精确控制。

5.5 并行分布式处理：认知科学，1980 年代

并行分布式处理模型（也被称为连接主义）认为，大脑通过不同神经通路同时处理信息，然后在更高层整合。多个子智能体并行工作，就像大脑的不同区域同时激活；结果聚合就像神经振荡同步。

动态工作流的"多智能体并行 + 结果聚合"，在抽象层面与并行分布式处理模型同构。这不是巧合——因为两者都在解决同一个问题：如何用有限容量的局部处理器，产生全局一致的高阶表征。

◈ 六、与工程思想的深层契合

动态工作流不是孤立的创新，它与软件工程中的多个成熟范式产生深层共鸣。

6.1 微服务架构 → 分布式系统编排

从单体应用（单智能体）到微服务（多智能体），软件工程花了十年才接受一个事实：你需要一个编排层。Kubernetes 不直接运行业务逻辑，它调度容器；服务网格不处理请求，它管理流量。动态工作流的运行时就是这个编排层——它不直接读写文件，它调度智能体。

6.2 站点可靠性工程（SRE）

Google 的可靠性工程核心不是"避免失败"，而是"快速检测和恢复"。对抗性验证就是 AI 时代的混沌工程——你不是等待生产环境出错，而是主动让智能体互相攻击，在错误到达用户之前发现和修复。

"错误预算"的概念也有对应物：Anthropic 官方警告动态工作流"消耗的 token 明显更多"。这意味着你需要为"不确定性"预留预算——不是预算时间，而是预算 token。

6.3 演员模型（Actor Model）

每个子智能体就是一个演员：有独立状态（自己的上下文窗口），通过消息传递（脚本变量）通信，由运行时监督处理失败。Erlang/OTP 和 Akka 花了二十年证明这个模型的可靠性，动态工作流把它应用到了 AI 编排层。

6.4 声明式编程

传统工作流是命令式：你告诉计算机"先做这个，再做那个，如果出错则回滚"。动态工作流是声明式：你告诉计算机"我要一个通过所有测试的 Rust 版本 Bun"，让它自己决定怎么做。这像 React 的声明式 UI（"我要这个状态"，React 决定怎么操作 DOM），也像 Terraform 的声明式基础设施（"我要这个架构"，Terraform 决定怎么创建资源）。

◈ 七、结语：在控制与涌现之间

动态工作流让我看到的不是"更快的编码工具"，而是一个自适应认知生态系统的雏形。它从控制论借来了反馈循环，从分布式认知借来了外部记忆系统，从有限理性借来了组织修正机制，从涌现理论借来了局部规则的全局秩序。

我还没用过它。但写作这篇文章让我意识到，我真正想理解的不是它的 API，而是它背后那个更大的问题：当 AI 开始自己决定如何组织工作时，人类的角色是什么？

也许答案就在西蒙的剪刀隐喻里：一边是任务环境的结构，一边是行动者的计算能力。动态工作流改变的是整个剪刀的形状——它让 AI 自己锻造刀刃。

而人味？人味可能在于，当剪刀剪下去的时候，人仍然握着刀柄，决定剪什么，不剪什么。维纳在 1948 年说我们设计的是适应目标的系统，而不是执行命令的机器。2026 年，这个"系统"学会了自我编排。当我们握着刀柄的手还能感受到控制吗？也许就像西蒙暗示的，真正的人味不在于写每一行代码，而在于决定哪些代码值得写、哪些边界条件值得设、哪些长期价值不能被短期收敛所牺牲。

◈ 附录：延伸阅读与源头信息

官方一手信息

• Anthropic 官方博客：《在 Claude 代码工具中引入动态工作流》（2026-05-28）

• Claude 代码工具官方文档：《大规模编排子智能体：动态工作流》

• GitHub：oven-sh/bun 的 claude/phase-a-port 分支（Bun 迁移的实际代码）

技术社区

• Reddit r/ClaudeAI / r/LocalLLaMA —— 真实用户反馈和成本报告

• Hacker News —— 对 Bun 迁移案例的深度讨论

• Discord：Anthropic 开发者社区

深度分析博客

• azukiazusa.dev —— 日本开发者的一手实践记录

• mejba.me —— 对抗性规划循环的实践经验

• claudefa.st —— 动态工作流完整指南

理论源头（按出现顺序）

• 米勒，G. A.（1956）。神奇的数字 7±2。《心理学评论》。

• 科万，N.（2001）。短期记忆中的神奇数字 4。《行为与脑科学》。

• 维纳，N.（1948）。《控制论：动物与机器中的控制与通信》。麻省理工学院出版社。

• 哈钦斯，E.（1995）。《荒野中的认知》。麻省理工学院出版社。

• 哈钦斯，E.（1995）。驾驶舱如何记住它的速度。《认知科学》。

• 西蒙，H. A.（1947）。《管理行为：行政组织中决策过程的研究》。自由出版社。

• 西蒙，H. A.（1990）。人类行为的不变量。《心理学年评》。

• 霍兰德，J. H.（1998）。《涌现：从混沌到秩序》。牛津大学出版社。

• 霍兰德，J. H.（1995）。《隐藏的秩序：适应如何构建复杂性》。艾迪生-韦斯利。

• 鲁梅尔哈特，D. E.、麦克莱兰，J. L. 等（1986）。《并行分布式处理：认知微观结构的探索》。麻省理工学院出版社。

• 伯钦格，N.、纳什莱格，T.（2004）。混沌边缘递归神经网络的实时计算。《神经计算》。

• 伯钦格，N.、奥尔布里希，E.、艾，N.、约斯特，J.（2008）。自主性：一个信息论视角。《生物系统》。

工程模式参考

• AWS Step Functions / Temporal / Cadence —— 传统工作流编排

• Kubernetes —— 分布式系统调度

• 演员模型（Erlang/OTP, Akka）—— 并发抽象

• Google SRE 手册 —— 可靠性工程

◢◤ TRANSMISSION COMPLETE ◢◤

本文由 [小糖糖同学] 原创出品     当 AI 自己锻造刀刃时，人的角色是什么