Claude Code Workflow实测：68个子智能体并发工作

Claude Code隐藏的「超级编程」模式

Claude Code（Anthropic推出的命令行编程工具）中隐藏着一个强大但鲜为人知的功能——Workflow工作流模式。这个模式能让AI自动拆解复杂任务，派发数十个子智能体并发执行，实现真正意义上的「AI流水线作业」。近日，有B站UP主在实际项目中深度体验了这一功能，单次任务竟调度了68个子智能体，效率令人惊叹。

与市面上常见的IDE插件式AI助手（如GitHub Copilot、Cursor等主要在编辑器内提供代码补全和对话功能）不同，Claude Code是一款运行在终端中的命令行原生工具。它可以直接访问文件系统、执行Shell命令、操作Git仓库，拥有对整个项目工程的深度感知能力。这种架构设计与传统IDE插件有本质区别：IDE插件通常运行在编辑器的沙箱环境中，通过编辑器提供的API与文件系统交互，权限和能力受到宿主编辑器的限制；而Claude Code直接运行在操作系统的终端环境中，继承了Shell的全部能力——包括文件读写、进程管理、网络请求、环境变量访问等。这意味着它可以像一个真正的开发者那样操作整个项目：执行构建脚本、运行测试套件、查看Git历史、甚至通过SSH连接远程服务器。这种「系统级」的访问权限是实现复杂工程任务编排的前提条件，也使它天然适合承担更复杂的工程级任务编排，而不仅仅是单文件级别的代码辅助。Workflow模式正是在这一架构优势上构建的高级功能。

如何开启Workflow模式

开启这个功能的步骤并不复杂，但需要手动调整设置：

1. 在Claude Code中输入 /effort 命令
2. 默认的思考模式通常是 hi（高思考模式）
3. 将其切换到最高档位 also coder（超级编程模式）

开启后，Claude Code会根据你提交任务的复杂度，自动决定是否派发子智能体。这里的「子智能体」（Sub-agent）是多智能体系统（Multi-Agent System）中的核心概念——每个子智能体都是一个独立的AI推理实例，拥有自己的上下文窗口和执行环境，能够自主完成被分配的子任务并将结果返回给主智能体。从技术实现角度看，每个子智能体本质上是一次独立的模型推理调用（Inference Call），拥有独立的上下文窗口（Context Window）。上下文窗口是大语言模型的核心概念，指模型在单次推理中能够「看到」的文本长度上限——以Claude 3.5 Sonnet为例，其上下文窗口为200K Token，意味着每个子智能体最多可以处理约15万字的输入信息。独立的上下文窗口既是优势也是限制：优势在于子智能体之间互不干扰，一个子智能体的错误不会污染其他智能体的推理过程；限制在于子智能体之间无法直接共享中间状态，所有协调工作都必须通过主智能体进行。与简单的函数调用不同，子智能体具备一定程度的自主决策能力，可以根据任务需要自行规划执行步骤、调用工具、甚至进行多轮推理。这种架构使得复杂任务可以被真正地「分而治之」。

它本质上是一个自组织的编程工作流——AI会自己构建一个完整的任务编排方案（类似Harness），无需用户手动拆分任务。这里提到的Harness是DevOps领域知名的持续集成/持续部署（CI/CD）编排平台，它的核心能力是将软件交付流程拆解为多个阶段（Stage）和步骤（Step），定义它们之间的依赖关系和并行策略，然后自动化执行整个流水线。Claude Code的Workflow模式借鉴了类似的理念：AI扮演「编排引擎」的角色，自动分析任务依赖关系，决定哪些子任务可以并行执行、哪些需要串行等待，最终形成一个动态的任务DAG（有向无环图）。

DAG（Directed Acyclic Graph，有向无环图）是任务编排领域的核心数据结构，在Apache Airflow、Prefect等主流工作流引擎中被广泛采用。在DAG中，每个节点代表一个任务，有向边代表任务之间的依赖关系，「无环」则保证了不会出现循环依赖导致的死锁。在Claude Code的Workflow模式中，AI会自动分析任务描述，识别出哪些子任务之间存在数据依赖（必须串行执行），哪些子任务彼此独立（可以并行执行），然后动态构建一个任务DAG。例如，在批量测试场景中，各个提示词的测试彼此独立，因此可以全部并行；而验收环节依赖于所有测试结果，因此必须等待所有子任务完成后才能开始。这种动态DAG生成能力是Workflow模式的核心技术亮点，也是它区别于传统CI/CD工具的关键——传统工具需要人工编写Pipeline配置文件，而Claude Code的工作流完全由AI自主生成。

实战场景：数字人写作技能的批量测试

任务背景

UP主当前正在开发一个数字人项目，其中包含一个写作技能模块（Writing Skill）。数字人（Digital Human）是近年来AI应用的热门方向，指通过AI技术创建的具有人类外观和交互能力的虚拟实体。一个完整的数字人系统通常包含多个技能模块：语音合成（TTS）、语音识别（ASR）、自然语言理解（NLU）、视觉生成、以及本例中的写作技能等。写作技能模块的核心是一组精心设计的提示词（Prompt），每个提示词对应一个特定的写作场景（如新闻稿撰写、社交媒体文案、技术文档等）。提示词工程（Prompt Engineering）的质量直接决定了数字人的写作表现，因此需要对每个提示词进行系统性的测试和评估——这正是本次实测任务的核心需求。

任务分工：写审分离机制

具体的任务设计非常巧妙，采用了**「写审分离」**的原则：

• 主智能体：负责整体监督和任务调度，同时承担最终验收工作
• 子智能体：被派发去执行具体的写作任务，使用不同的提示词生成内容
• 验收环节：由主智能体统一审核，确保「写的人不审，审的人不写」

这种设计思路借鉴了软件工程中的代码审查（Code Review）理念——生产者和审核者必须分离，才能保证质量。在软件工程实践中，这一原则有着深厚的理论基础：心理学研究表明，内容创作者对自己产出的作品存在天然的「确认偏误」（Confirmation Bias），倾向于忽略自身作品中的缺陷。因此，从早期的「同行评审」（Peer Review）到现代开源社区普遍采用的Pull Request审查机制，「生产与审核职责分离」已成为软件质量保证的基石原则之一。Google内部的工程实践甚至要求每一行代码都必须经过至少一位非作者的工程师审核后才能合入主分支。Claude Code将这一人类工程智慧迁移到了AI多智能体协作中，让不同的AI实例分别承担「生产者」和「审核者」的角色，从而在AI系统内部构建了一套自洽的质量控制闭环。

Claude Code的Workflow模式天然支持这种多角色协作。

68个子智能体的调度实况

整个测试过程共进行了四轮，累计调度了68个子智能体。通过输入 /workflow 命令，可以清晰地看到当前的工作流编排状态。

从截图中可以看到具体的并发情况：

• 第一轮：并发启动了 9个子智能体
• 第二轮：再次并发启动 9个子智能体，加上前面的共计约10个在运行
• 后续轮次：持续高并发调度，四轮累计68个

单轮最多并发9个子智能体这一限制，很可能与Anthropic的API速率限制（Rate Limit）和资源调度策略有关。大语言模型的推理需要消耗大量GPU算力，服务提供商通常会对单个用户或单个会话的并发请求数设置上限，以确保服务的整体稳定性和公平性。此外，主智能体需要在其上下文窗口中维护所有子智能体的任务描述和状态信息，过多的并发子智能体会导致主智能体的上下文窗口迅速耗尽，影响其调度决策的质量。因此，9个并发子智能体可能是Anthropic在「执行效率」和「调度质量」之间找到的一个平衡点。

这意味着Claude Code并非串行地逐个执行任务，而是能够同时并发多个子智能体，大幅缩短了整体执行时间。四轮提示词测试「基本上很快都测完了」。

Workflow模式的优势与代价

核心优势

1. 自动任务拆解：无需手动规划，AI根据任务复杂度自主决定工作流结构
2. 高并发执行：单轮最多可并发9个子智能体，效率远超手动逐一测试
3. 内置质量控制：支持写审分离等协作模式，主智能体负责验收把关
4. 可视化监控：通过 /workflow 命令可以实时查看任务编排和执行状态

不可忽视的Token消耗代价

这个功能最大的缺点就是——极其消耗Token。

68个子智能体意味着68次独立的AI调用，每个子智能体都需要接收上下文、执行任务、返回结果。再加上主智能体的调度和验收开销，整体Token消耗量是普通对话的数十倍。对于按Token计费的用户来说，这是一笔不小的开支。

要理解这一代价的技术根源，需要了解大语言模型的Token计费机制。Token是模型处理文本的基本单位，中文大约每1-2个字对应一个Token，英文则大约每个单词对应1-1.5个Token。每次AI调用的费用由「输入Token数」和「输出Token数」共同决定，其中输入Token包含了系统提示词、上下文信息和用户指令。在多智能体场景下，Token消耗呈倍数级增长的原因有三：第一，每个子智能体都需要独立接收任务上下文（包括项目背景、代码结构、具体指令等），这些上下文信息会被重复传输；第二，主智能体在调度过程中需要维护全局状态，随着子任务增多，其上下文窗口会持续膨胀；第三，验收环节需要主智能体逐一审阅所有子智能体的输出结果，这又产生了大量的输入Token开销。以Claude 3.5 Sonnet的API定价为参考（输入约$3/百万Token，输出约$15/百万Token），68个子智能体的调度成本可能达到单次普通对话的50-100倍。不过，Claude Code的Max订阅计划（$100/月或$200/月）提供了一定额度的包月使用量，一定程度上缓解了这一成本压力。

适用场景与使用建议

基于这次实测，Claude Code Workflow模式特别适合以下场景：

• 批量测试：如本例中的提示词批量验证
• 大规模代码重构：需要同时修改多个文件的场景
• 多模块并行开发：各模块相对独立，可以并发处理
• 自动化QA：需要写审分离的质量保证流程

使用建议：

1. 任务足够复杂时再开启超级编程模式，简单任务用默认模式即可
2. 提前评估Token预算，避免意外超支
3. 善用 /workflow 命令监控执行进度
4. 在任务描述中明确分工要求（如写审分离），帮助AI更好地编排工作流

总结

Claude Code的Workflow功能展示了AI编程工具的一个重要发展方向：从单一对话式编程，走向多智能体协作式编程。这一趋势并非Claude Code独有——整个AI编程工具行业都在向多智能体架构演进。OpenAI的Codex CLI已经开始支持多步骤任务编排；Google的Jules（基于Gemini的AI编程代理）同样采用了任务分解与并行执行的设计理念；开源社区中，AutoGen、CrewAI等多智能体框架也在快速成熟，为开发者提供了自建多Agent编程系统的基础设施。

值得一提的是，这些框架代表了不同的设计哲学：微软的AutoGen采用「对话驱动」的架构，智能体之间通过结构化对话进行协作，更接近人类团队的沟通方式；CrewAI则采用「角色扮演」的架构，开发者为每个智能体定义明确的角色（如「研究员」、「写手」、「审核员」），框架负责协调角色之间的工作流；LangGraph（LangChain生态的一部分）则提供了基于图的智能体编排能力，允许开发者精确控制智能体之间的状态传递和流程分支。这些开源框架的快速发展，正在将多智能体编程从少数大厂的专属能力变为普通开发者可以触及的通用技术。

这场「从单兵作战到团队协作」的范式转变，本质上反映了AI能力从「工具级」向「系统级」的跃迁——AI不再只是回答问题或补全代码的助手，而是开始具备项目管理、任务分配和质量控制等系统性工程能力。

68个子智能体并发工作的场景，已经非常接近一个小型开发团队的协作模式。虽然Token消耗是当前的主要瓶颈，但随着模型推理成本的持续下降（过去两年间，主流大模型的API价格已下降超过90%，且这一趋势仍在加速），这种「AI团队作战」的模式很可能成为未来AI编程的主流范式。感兴趣的开发者不妨亲自体验一番。