Claude Dynamic Workflows解析— 迎接全新的 AI 编程生态

Claude Dynamic Workflows解析— 迎接全新的 AI 编程生态 Claude Dynamic Workflows解析— 迎接全新的 AI 编程生态 Modified May 31 突破“上下文污染”的物理极限： 传统大模型在执行长时间、复杂任务时，容易因为上下文窗口塞满而出现遗忘或“幻觉”。动态工作流将执行计划卸载到后台代码中，确保主对话的上下文保持整洁。 将季度级任务缩短至几天： 通过大规模并发操作，它可以极大缩短工程时间。 内置对抗性审查机制提升可靠性： 它不是简单地分发任务，而是让子智能体从独立角度切入，互相验证甚至进行对抗性反驳（Devil's advocate），直到结果收敛，从而排除了单个智能体容易产生的漏洞。 3. Who（谁可以使用？） 适用人群： 需要处理超大代码库的开发者、架构师或 AI 工程团队。 开放范围： 在 Claude Code（支持 CLI、桌面版、VS Code 扩展等）中向 Max、Team 和 Enterprise 计划的用户开放。对于 Enterprise 用户，默认关闭，需要管理员手动开启。同时也可通过 Claude API 以及 Amazon Bedrock、Vertex AI 等云平台使用。 4. When（什么时候用？什么时候不用？） 极度适用的场景（大型重活）： 涉及数百上千个文件的大型迁移（例如 Bun 作者将 75 万行代码从 Zig 移植到 Rust 的史诗级案例）、代码库级别的全局 Bug 排查、深度的全量安全审计。 千万别用的场景（杀鸡用牛刀）： 对于单个文件的微小修改、修个小 Bug 或简单的格式化。由于启动工作流代价极高，这些小任务使用常规的交互模式（或 Fast Mode）即可，否则是极大的浪费。 5. Where（在哪里运行？） 在 后台隔离环境 中运行。用户的手头会话保持高度响应，你可以用指令打开特定的视图（如 Agent View 或执行 /workflows）来监控它在后台的执行进度。 6. How（如何触发与运作？） 如何触发： 有三种主要方式。第一，在提示词中直接包含“workflow”一词；第二，在 Effort（投入度）选项中开启 ultracode 模式（该模式结合了极高的推理投入和自动工作流编排）；第三，调用内置的 /deep research 宏命令。 如何执行： 接收任务 动态分解子任务 并行启动子智能体 对抗性验证与纠错 归总报告。 容错与恢复： 拥有自动保存检查点（Checkpointing）的能力。如果遇到网络中断或人为暂停，任务可以从断点恢复，无需从头重新消耗计算量。完成的工作流脚本还可以通过按 s 键保存下来，供未来团队复用。 7. How much（消耗多大？有何限制？） “烧钱”级别的 Token 消耗： 这是一个极其昂贵的模式。运行一次大型动态工作流可能会消耗数百万甚至几千万的 Token，导致你的账号迅速触及使用限额。官方甚至会在首次运行时弹出消耗警告提示。 硬性并发限制： 为防止失控，系统在后台施加了严格的上限：最多允许 16 个智能体并发执行，且单次运行的智能体总数封顶为 1,000 个 四、架构对比 首先来看下SubAgent、AgentTeams、Dynamic Workflows的对比： 之前很多人应该使用Subagents来解决问题（一个会话内派几个专家并行）和 Agent Teams（多会话直接通信）。它们能解决很多问题，但有一个共同的天花板——调度逻辑活在主 Claude 的 context 里。 实际后果： 你想扫完一个百万行仓库找 bug？派 50 个 subagent，每个查一个目录？主 context 装不下这么多 task 描述 + 结果摘要。 你想做一个跨 200 个文件的大迁移？Agent Teams 的协调消息会把主 context 顶爆。 你想让多个 agent 对同一个发现互相挑刺、迭代到共识？目前没有"对抗式校验"这层基础设施。 简单说：Subagents 是"一个老板带几个工人"，Agent Teams 是"几个团队互相打配合"，但你想要一个工厂——上百个工位同时干、生产管理跟干活的事分开。 再来看下它和子代理、skills的对比，都可以运行多步骤任务。区别在于谁掌握计划： 工作流将计划移入代码。使用子代理和 skills，Claude 是编排者：它逐轮决定接下来生成什么，每个结果都进入 Claude 的上下文。工作流脚本持有循环、分支和中间结果本身，所以 Claude 的上下文只持有最终答案。将计划移入代码也让工作流应用可重复的质量模式，而不仅仅是运行更多代理：它可以让独立代理在报告之前对彼此的发现进行对抗性审查，或从多个角度起草计划并相互权衡，所以您获得比单次通过更可信的结果。 Dynamic Workflows 解决的是编排规模。它不让主 Claude 每一轮都亲自协调，而是把调度逻辑交给脚本。脚本可以 parallel，可以 pipeline，可以循环，也可以在每个发现后安排对抗性 review。 从这个角度看，它在 Claude Code 里补了一层“编排运行时”。 我们在通俗的对比下，了解下这几个概念，拆解这四个概念： 1. Subagent（子代理）：专注局部的“外派调研员” 怎么工作： 当主 AI（比如你的项目经理）遇到一个需要查阅大量资料的具体问题时，它不会自己去死磕，而是临时派出一个 Subagent 去专门干这件小事。 解决什么痛点： 主要是为了“隔离噪音”。如果主 AI 自己去读几万行的日志找个小 bug，它的“脑子”（上下文窗口）很快就会被这些琐碎信息塞满，忘了原本要干嘛。有了 Subagent，主 AI 就能保持头脑清醒，只接收 Subagent 汇报的最终结果。 适用场景： 快速读取某个代码模块、顺藤摸瓜查一下函数调用链、或者对某一段代码做个局部审查。 2. Skill（技能）：固化经验的“标准操作手册（SOP）” 怎么工作： 它不仅仅是让 AI 即兴发挥，而是把过去成功的经验写成了一个“剧本”（Skill 文件）。下次再遇到同样的事情，AI 直接照着剧本走。 解决什么痛点： 核心是“沉淀资产”。把“碰巧做对了一次”变成“每次都能做对”。它消除了 AI 每次处理重复任务时的随机性，确保输出稳定。 适用场景： 生成特定格式的周报、遵循固定的代码提交流程、或者按照你们团队的特定规范来审查代码。 3. Agent Teams（代理团队）：跨职能的“敏捷项目组” 怎么工作： 这就像一个真实的项目组，有一个 Lead（组长）和多个 Teammates（比如前端 AI、后端 AI、测试 AI）。他们之间会共享协作状态，知道彼此在干什么。 解决什么痛点： 解决“各自为战”导致的风险。如果前端改了接口，后端不知道，项目就会报错。Agent Teams 通过分工协作，确保不同角色在同一个工作面上步调一致。 适用场景： 需要多角色配合的复杂任务，比如同时开发前端和后端、边写代码边写测试用例、或者多角度的代码交叉审查。 4. Workflow（动态工作流）：代码驱动的“自动化流水线” 怎么工作： 这是最高阶的编排。这里的计划不再只是一段给 AI 的提示词（Prompt），而是变成了真正的可执行代码（比如 JavaScript 脚本）。这个脚本在后台静默运行，精准地调度无数个 AI 去执行循环或并发任务。 解决什么痛点： 解决“规模化与可控性”的问题。正如图片底部强调的，Workflow 的价值不是简单地“增加人手”，而是让整个复杂的计划变得“可执行、可复查”。因为是用纯代码调度的，哪里出错了，工程师可以直接看脚本排查。 适用场景： 扫遍整个公司代码仓库找漏洞、超大规模的旧系统迁移、几万个文件的长尾清理工作。 总结来说： Subagent 是帮你“跑腿”的，Skill 是帮你“背书”的，Agent Teams 是帮你“打团战”的，而 Workflow 则是帮你建起一座“自动化工厂”。 五、生态发展 首先我觉得这个东西的发布，将会对那种图形化编排的软件FastGPT、Dify造成一定的冲击，同时让ClaudeCode中的一些场景执行的更稳定，同时也会让非技术人员，能够编写更强大，更厉害的应用场景。原来开发人员使用SDK开发的自定义Agent的场景也有一定的冲击。 在发布后的不久，Github上相继出现了一些新的生态项目，值得阅读的我推荐几个： 第1个：Claude Code 多 Agent 编排实战手册 仓库地址：https://github.com/AGI is going to arrive/workflow cookbook 在线预览：https://agi is going to arrive.github.io/workflow cookbook/ 本书从零到一带你走完整条路。你先理解工作流在几种扩展机制里的位置，再掌握 agent()/parallel()/pipeline()/schema 全部 API，然后实战 7 个真实运行的配方。接着你解锁对抗验证、循环到干、预算、续传这些进阶模式，横评四大社区系统并提取精华，构建属于你自己的 Workflow 库，最后掌握从意图到上线的创作、校验与调试全流程。 这是一本实战 Cookbook，不是 API 文档。它讲得深入浅出，配方都以真实运行为骨：已实跑的附 Run ID 与用量，仅作示意的脚本明确标注。 第2个：可视化 Claude Code 动态工作流 (Dynamic Workflows) 的轻量级辅助工具 项目地址：https://github.com/democra ai/claude workflow viz 项目介绍：当 Claude 用脚本在后台同时调度几十上百个 subagent 时，所有的执行细节（哪些代理在并行、卡在哪个环节、分别消耗了多少 Token）通常只会静默保存在本地的 JSON 日志里。这个工具的作用就是把这些隐藏的底层数据“提出来”，变成直观的可视化图表。 第3个：一套便携、抗造、能换引擎的轻量级施工脚手架 项目地址：https://github.com/akakabrian/agent workflows 项目介绍：它是一个无依赖、跨平台、纯 Python 的动态 Agent 工作流运行时环境。它的核心理念是：“用一个简单的 Python 脚本，搞定复杂的多模型协作、并发和容错，而且不绑定任何具体的模型厂商”。 第4个：交互式单页报告:Claude Code 动态工作流(Dynamic Workflows)使用调研 项目地址：https://github.com/cclank/cc dynamic workflows 在线预览地址：https://cc dynamic workflows.pages.dev/ 项目介绍：一份交互式单页 HTML 报告，讲清 Claude Code Dynamic Workflows（2026 05 28 随 Claude Opus 4.8 发布的研究预览功能）怎么用：定义、执行模型、触发与上手、监控成本、限制、脚本 API、编排模式、真实案例。 我觉得接下来还会出现DynamicWorkflow市场、企业DynamicWorkflow的应用、DynamicWorkflows的相关Skills，非常期待了。 六、避坑指南 一次 workflow 会 spawn 大量 agent,单次运行可能比在对话里做同一任务消耗明显更多 token;运行像普通会话一样计入你方案的用量与速率限制。在这个过程中，可以随时从 /workflows 停止,不会丢失已完成的工作。 控成本:盯住模型 workflow 里每个 agent 默认用你会话的模型,除非脚本把某阶段路由到别的模型。 大运行前先 /model 确认(尤其你平时会切到小模型做日常活时)。 描述任务时,可让 Claude 把不需要最强模型的阶段换成小模型。 关掉 workflow的几种方式如下： 不想用时三选一:/config 里关掉 Dynamic workflows;或 /.claude/settings.json 设 "disableWorkflows": true;或环境变量 CLAUDE CODE DISABLE WORKFLOWS=1。组织级可用 managed settings。关闭后:bundled 命令不可用、workflow 词不再触发、ultracode 从 /effort 菜单移除。 几个注意的地方： 场景： 突破“上下文污染”的物理极限： 传统大模型在执行长时间、复杂任务时，容易因为上下文窗口塞满而出现遗忘或“幻觉”。动态工作流将执行计划卸载到后台代码中，确保主对话的上下文保持整洁。 将季度级任务缩短至几天： 通过大规模并发操作，它可以极大缩短工程时间。 内置对抗性审查机制提升可靠性： 它不是简单地分发任务，而是让子智能体从独立角度切入，互相验证甚至进行对抗性反驳（Devil's advocate），直到结果收敛，从而排除了单个智能体容易产生的漏洞。 3. Who（谁可以使用？） 适用人群： 需要处理超大代码库的开发者、架构师或 AI 工程团队。 开放范围： 在 Claude Code（支持 CLI、桌面版、VS Code 扩展等）中向 Max、Team 和 Enterprise 计划的用户开放。对于 Enterprise 用户，默认关闭，需要管理员手动开启。同时也可通过 Claude API 以及 Amazon Bedrock、Vertex AI 等云平台使用。 4. When（什么时候用？什么时候不用？） 极度适用的场景（大型重活）： 涉及数百上千个文件的大型迁移（例如 Bun 作者将 75 万行代码从 Zig 移植到 Rust 的史诗级案例）、代码库级别的全局 Bug 排查、深度的全量安全审计。 千万别用的场景（杀鸡用牛刀）： 对于单个文件的微小修改、修个小 Bug 或简单的格式化。由于启动工作流代价极高，这些小任务使用常规的交互模式（或 Fast Mode）即可，否则是极大的浪费。 5. Where（在哪里运行？） 在 后台隔离环境 中运行。用户的手头会话保持高度响应，你可以用指令打开特定的视图（如 Agent View 或执行 /workflows）来监控它在后台的执行进度。 6. How（如何触发与运作？） 如何触发： 有三种主要方式。第一，在提示词中直接包含“workflow”一词；第二，在 Effort（投入度）选项中开启 ultracode 模式（该模式结合了极高的推理投入和自动工作流编排）；第三，调用内置的 /deep research 宏命令。 如何执行： 接收任务 动态分解子任务 并行启动子智能体 对抗性验证与纠错 归总报告。 容错与恢复： 拥有自动保存检查点（Checkpointing）的能力。如果遇到网络中断或人为暂停，任务可以从断点恢复，无需从头重新消耗计算量。完成的工作流脚本还可以通过按 s 键保存下来，供未来团队复用。 7. How much（消耗多大？有何限制？） “烧钱”级别的 Token 消耗： 这是一个极其昂贵的模式。运行一次大型动态工作流可能会消耗数百万甚至几千万的 Token，导致你的账号迅速触及使用限额。官方甚至会在首次运行时弹出消耗警告提示。 硬性并发限制： 为防止失控，系统在后台施加了严格的上限：最多允许 16 个智能体并发执行，且单次运行的智能体总数封顶为 1,000 个 四、架构对比 首先来看下SubAgent、AgentTeams、Dynamic Workflows的对比： 之前很多人应该使用Subagents来解决问题（一个会话内派几个专家并行）和 Agent Teams（多会话直接通信）。它们能解决很多问题，但有一个共同的天花板——调度逻辑活在主 Claude 的 context 里。 实际后果： 你想扫完一个百万行仓库找 bug？派 50 个 subagent，每个查一个目录？主 context 装不下这么多 task 描述 + 结果摘要。 你想做一个跨 200 个文件的大迁移？Agent Teams 的协调消息会把主 context 顶爆。 你想让多个 agent 对同一个发现互相挑刺、迭代到共识？目前没有"对抗式校验"这层基础设施。 简单说：Subagents 是"一个老板带几个工人"，Agent Teams 是"几个团队互相打配合"，但你想要一个工厂——上百个工位同时干、生产管理跟干活的事分开。 再来看下它和子代理、skills的对比，都可以运行多步骤任务。区别在于谁掌握计划： 工作流将计划移入代码。使用子代理和 skills，Claude 是编排者：它逐轮决定接下来生成什么，每个结果都进入 Claude 的上下文。工作流脚本持有循环、分支和中间结果本身，所以 Claude 的上下文只持有最终答案。将计划移入代码也让工作流应用可重复的质量模式，而不仅仅是运行更多代理：它可以让独立代理在报告之前对彼此的发现进行对抗性审查，或从多个角度起草计划并相互权衡，所以您获得比单次通过更可信的结果。 Dynamic Workflows 解决的是编排规模。它不让主 Claude 每一轮都亲自协调，而是把调度逻辑交给脚本。脚本可以 parallel，可以 pipeline，可以循环，也可以在每个发现后安排对抗性 review。 从这个角度看，它在 Claude Code 里补了一层“编排运行时”。 我们在通俗的对比下，了解下这几个概念，拆解这四个概念： 1. Subagent（子代理）：专注局部的“外派调研员” 怎么工作： 当主 AI（比如你的项目经理）遇到一个需要查阅大量资料的具体问题时，它不会自己去死磕，而是临时派出一个 Subagent 去专门干这件小事。 解决什么痛点： 主要是为了“隔离噪音”。如果主 AI 自己去读几万行的日志找个小 bug，它的“脑子”（上下文窗口）很快就会被这些琐碎信息塞满，忘了原本要干嘛。有了 Subagent，主 AI 就能保持头脑清醒，只接收 Subagent 汇报的最终结果。 适用场景： 快速读取某个代码模块、顺藤摸瓜查一下函数调用链、或者对某一段代码做个局部审查。 2. Skill（技能）：固化经验的“标准操作手册（SOP）” 怎么工作： 它不仅仅是让 AI 即兴发挥，而是把过去成功的经验写成了一个“剧本”（Skill 文件）。下次再遇到同样的事情，AI 直接照着剧本走。 解决什么痛点： 核心是“沉淀资产”。把“碰巧做对了一次”变成“每次都能做对”。它消除了 AI 每次处理重复任务时的随机性，确保输出稳定。 适用场景： 生成特定格式的周报、遵循固定的代码提交流程、或者按照你们团队的特定规范来审查代码。 3. Agent Teams（代理团队）：跨职能的“敏捷项目组” 怎么工作： 这就像一个真实的项目组，有一个 Lead（组长）和多个 Teammates（比如前端 AI、后端 AI、测试 AI）。他们之间会共享协作状态，知道彼此在干什么。 解决什么痛点： 解决“各自为战”导致的风险。如果前端改了接口，后端不知道，项目就会报错。Agent Teams 通过分工协作，确保不同角色在同一个工作面上步调一致。 适用场景： 需要多角色配合的复杂任务，比如同时开发前端和后端、边写代码边写测试用例、或者多角度的代码交叉审查。 4. Workflow（动态工作流）：代码驱动的“自动化流水线” 怎么工作： 这是最高阶的编排。这里的计划不再只是一段给 AI 的提示词（Prompt），而是变成了真正的可执行代码（比如 JavaScript 脚本）。这个脚本在后台静默运行，精准地调度无数个 AI 去执行循环或并发任务。 解决什么痛点： 解决“规模化与可控性”的问题。正如图片底部强调的，Workflow 的价值不是简单地“增加人手”，而是让整个复杂的计划变得“可执行、可复查”。因为是用纯代码调度的，哪里出错了，工程师可以直接看脚本排查。 适用场景： 扫遍整个公司代码仓库找漏洞、超大规模的旧系统迁移、几万个文件的长尾清理工作。 总结来说： Subagent 是帮你“跑腿”的，Skill 是帮你“背书”的，Agent Teams 是帮你“打团战”的，而 Workflow 则是帮你建起一座“自动化工厂”。 五、生态发展 首先我觉得这个东西的发布，将会对那种图形化编排的软件FastGPT、Dify造成一定的冲击，同时让ClaudeCode中的一些场景执行的更稳定，同时也会让非技术人员，能够编写更强大，更厉害的应用场景。原来开发人员使用SDK开发的自定义Agent的场景也有一定的冲击。 在发布后的不久，Github上相继出现了一些新的生态项目，值得阅读的我推荐几个： 第1个：Claude Code 多 Agent 编排实战手册 仓库地址：https://github.com/AGI is going to arrive/workflow cookbook 在线预览：https://agi is going to arrive.github.io/workflow cookbook/ 本书从零到一带你走完整条路。你先理解工作流在几种扩展机制里的位置，再掌握 agent()/parallel()/pipeline()/schema 全部 API，然后实战 7 个真实运行的配方。接着你解锁对抗验证、循环到干、预算、续传这些进阶模式，横评四大社区系统并提取精华，构建属于你自己的 Workflow 库，最后掌握从意图到上线的创作、校验与调试全流程。 这是一本实战 Cookbook，不是 API 文档。它讲得深入浅出，配方都以真实运行为骨：已实跑的附 Run ID 与用量，仅作示意的脚本明确标注。 第2个：可视化 Claude Code 动态工作流 (Dynamic Workflows) 的轻量级辅助工具 项目地址：https://github.com/democra ai/claude workflow viz 项目介绍：当 Claude 用脚本在后台同时调度几十上百个 subagent 时，所有的执行细节（哪些代理在并行、卡在哪个环节、分别消耗了多少 Token）通常只会静默保存在本地的 JSON 日志里。这个工具的作用就是把这些隐藏的底层数据“提出来”，变成直观的可视化图表。 第3个：一套便携、抗造、能换引擎的轻量级施工脚手架 项目地址：https://github.com/akakabrian/agent workflows 项目介绍：它是一个无依赖、跨平台、纯 Python 的动态 Agent 工作流运行时环境。它的核心理念是：“用一个简单的 Python 脚本，搞定复杂的多模型协作、并发和容错，而且不绑定任何具体的模型厂商”。 第4个：交互式单页报告:Claude Code 动态工作流(Dynamic Workflows)使用调研 项目地址：https://github.com/cclank/cc dynamic workflows 在线预览地址：https://cc dynamic workflows.pages.dev/ 项目介绍：一份交互式单页 HTML 报告，讲清 Claude Code Dynamic Workflows（2026 05 28 随 Claude Opus 4.8 发布的研究预览功能）怎么用：定义、执行模型、触发与上手、监控成本、限制、脚本 API、编排模式、真实案例。 我觉得接下来还会出现DynamicWorkflow市场、企业DynamicWorkflow的应用、DynamicWorkflows的相关Skills，非常期待了。 六、避坑指南 一次 workflow 会 spawn 大量 agent,单次运行可能比在对话里做同一任务消耗明显更多 token;运行像普通会话一样计入你方案的用量与速率限制。在这个过程中，可以随时从 /workflows 停止,不会丢失已完成的工作。 控成本:盯住模型 workflow 里每个 agent 默认用你会话的模型,除非脚本把某阶段路由到别的模型。 大运行前先 /model 确认(尤其你平时会切到小模型做日常活时)。 描述任务时,可让 Claude 把不需要最强模型的阶段换成小模型。 关掉 workflow的几种方式如下： 不想用时三选一:/config 里关掉 Dynamic workflows;或 /.claude/settings.json 设 "disableWorkflows": true;或环境变量 CLAUDE CODE DISABLE WORKFLOWS=1。组织级可用 managed settings。关闭后:bundled 命令不可用、workflow 词不再触发、ultracode 从 /effort 菜单移除。 几个注意的地方： 场景： 成本： 系统： 这个东西在使用的时候，我们还是需要根据自己的情况进行选择： 七、总结 如果说过去两年的 AI 编程革命，主要是在不断提升模型的能力边界，那么 Dynamic Workflows 的出现，则是在重新定义 AI 完成工作的方式。 它本质上并不是一个“更强的代码助手”，而是一种全新的软件工程执行范式： 从「单 Agent 对话式编程」演进到「可持久化、可恢复、可验证的大规模并行 Agent 集群编排系统」。 它背后的几个关键创新包括： • 上下文卸载（Context Offloading） • JavaScript 动态执行计划 • 数百至上千个 Agent 的并行协作 • 自动化对抗验证机制（Adversarial Verification） • 检查点恢复与长任务持续运行能力 而这一切创新的背后，其实都指向同一个核心思想： 把“计划”从对话搬进代码。 在传统模式下，Claude 需要在自己的上下文窗口里完成全部工作： 规划、推理、循环、分支判断、中间状态管理…… 所有信息都会不断堆积在有限的上下文中。随着任务规模扩大，Token 持续增长，上下文逐渐被污染，模型也更容易出现逻辑漂移、遗忘甚至幻觉。 Dynamic Workflows 则选择了一条完全不同的道路。 它把循环、条件判断、任务拆解、并行调度以及中间状态管理全部迁移到动态生成的 JavaScript 编排脚本中，由独立 Runtime 持续执行；而主对话上下文只负责接收经过验证的最终结果。 从某种意义上说，这已经不是在扩展 Context Window，而是在绕开 Context Window。 这也是为什么 Claude 能够从过去一次只能驱动一个 Agent，演进到同时协调数百甚至上千个 Subagent，并持续运行数小时甚至数天而不失控。 如果说： • MCP 解决的是「AI 如何连接世界」； • Skills 解决的是「AI 如何沉淀经验」； 那么 Dynamic Workflows 解决的，则是： 「AI 如何组织大规模工作」。 这或许才是它真正重要的地方。 因为软件工程从来都不是写出一段代码那么简单，真正困难的是规划、拆解、协作、验证、追踪以及持续迭代。 而 Dynamic Workflows 第一次让我们看到，AI 开始具备承担这些工程组织工作的能力。 对于大型代码迁移、安全审计、仓库级重构以及长周期研发任务来说，它展现出的已经不再是一个编程助手的能力，而更接近于一个能够自主协作的“软件工程团队”。 当然，这项技术仍然面临 Token 成本、资源管理、模型调度效率以及质量控制等现实挑战。 但即便如此，它依然释放出了一个非常明确的信号： 未来的软件开发竞争，或许不再只是模型能力的竞争，而是 Agent 编排能力的竞争；未来最重要的资产，也许不再是 Prompt，而是 Workflow。 当 AI 开始学会组织工作，而不仅仅是完成工作时，一个全新的 AI 软件工程时代，或许已经拉开序幕。 作者：爱海贼的无处不在 原文链接：https://mp.weixin.qq.com/s/Xs7e3goFNUhJg5xEiO5YMA?token=925139605&lang=zh CN 一、前言 最近，Anthropic 发布了 Claude Opus 4.8，同时带来了一个很多人还没有意识到其意义的新能力——Claude Code Dynamic Workflows（动态工作流）。 如果说过去两年 AI 编程领域最重要的两个关键词是 MCP 和 Skills，那么在我看来，Dynamic Workflows 很可能会成为下一个被行业反复讨论、最终演变成标准范式的能力。 因为它改变的已经不是模型本身，而是软件开发任务的组织方式。 过去，我们习惯于把 AI 当作一个聪明的助手： 你提问，它回答； 你规划，它执行； 你发现问题，它继续修