Cerebras 总结多智能体工作流的五种编排模式

2026年4月16日

我预付了订阅费（每月200美元），写下我希望能奏效的提示词（提示词兼上下文工程师），然后等待。35分钟过去了，它仍在“合成”、“细读”、“生效”和“萌芽”（这些词是谁想出来的）。到最后，我得到了一堆糟糕的代码文件、一个臃肿的上下文窗口，而我正掰着左手数剩下的token。

好吧，我拿起一个苹果，压缩上下文，敲下一通措辞严厉的咒骂，从头重新解释一切，并祈祷下一次尝试能比上一次走得更远……结果却只换来同样的失望。到这时，AI编程的火花与乐趣早已荡然无存。

这就是单智能体的天花板。每个用AI智能体开发的开发者，都会在项目从3D HTML贪吃蛇游戏升级为任何更实用的东西的那一刻撞上它。原因如下：

而就在这个时候，大多数人会向你推销（a）一门毫无用处的提示词工程课程，（b）又一个管理你上下文的SaaS工具，（c）或者问你为什么还没试试几秒前刚发布的新模型——我们今天不会这么做。

相反，我们将带你了解真正有效的方法：运行一个像样的后厨。多智能体工作流。

近几周来，多智能体工作流变得实用得多，原因有几个：底层模型变得更好了，而且流行的AI编程智能体让多智能体编排更容易搭建。上个季度，OpenAI在Codex工作流中推出了更深入的编排，而Anthropic则继续扩展Claude Code和MCP生态。

不过，最大的突破是速度。Codex Spark的运行速度约为每秒1,200个token，这使得引入并行和验证步骤变得切实可行，否则这些步骤的时间成本会过高。

以一个使用Codex和Figma MCP将网站复制到Figma的示例任务为例，单智能体工作流平均每次运行耗时36.5分钟，平均需要12次人工干预（且失败率100%），而多智能体工作流每次运行耗时5.2分钟，仅需2次人工干预，并且首次尝试即成功。

多智能体工作流在架构层面解决了单智能体的天花板问题。不再是一个厨师包揽一切，而是由一位主厨接单，将其拆解为范围明确、可验证的工单，再把每一张交给一名流水线厨师执行。

主厨（编排者）

主厨的职责是从人类那里接单，将其拆解为一份可执行的工单清单，然后呼叫流水线厨师，让每个人去完成一项更小的、范围明确的工作。

流水线厨师（子智能体）

流水线厨师的职责是接过主厨给出的工单（任务分配）并完成任务，不问任何问题。每位流水线厨师都有自己全新的工作台（上下文窗口），完成自己的工作，交回成品，然后打卡下班。

在Codex这类AI智能体中，你只需直接告诉你的智能体“使用子智能体”，就能创建一名流水线厨师。新实例会获得一个提示词、一组它可以访问的文件，以及它所需的任何上下文。

相比试图一次性完成你正在构建的任何东西，或坚持使用单一的、前沿的、昂贵的模型，编排者与子智能体能带来三项明确的优势。

1. Token：你的有效上下文窗口从约200K扩展到25M以上

以下是人类、编排者和子智能体之间的交互方式：

这意味着编排者永远不必直接读取文件、写入文件或查看工具调用结果，从而有效地将其上下文窗口扩展到它能生成的任意数量的子智能体。你可以全天工作而不丢失上下文、不压缩、不重新开始。

2. 控制：你可以在智能体循环的每一轮强制执行顺序化工作流

不再由一个智能体包揽探索、烹饪、品尝和摆盘，每个步骤都变成一张精确的、顺序化的工单。这也是针对不同任务使用不同模型的好地方。借助Codex Spark（约每秒1,200个token）这类速度显著更快的模型，我们可以加入通常时间成本过高的验证和QA步骤。

编排者按照脚本执行，每个阶段生成一个子智能体：

在内部试验中，与相同任务简报下的单智能体运行相比，这一顺序循环将人工干预减少了84.3%。

3. 速度：你可以并行运行定义明确的任务

如果你的任务允许，你可以并行生成多个子智能体。这非常适合：

并行运行五次吉祥物生成大约耗时一分钟，而顺序运行需要五分钟，在品味驱动的探索任务上约实现了5倍加速。

你刚刚被提升为专业厨房的主厨。你有一整支团队、一板的工单，却不知道从哪里开始。过去几周，我们在不同的AI智能体上尝试了数十种工作流和配置。以下是我们在构建多智能体工作流方面取得成功的五种模式。

如果你是新手，请从最上面开始，逐步往下看 ：)

在开餐之前，专业厨房不会让一个厨师慢慢地把每一种蔬菜都切丁。它会有一排备菜厨师，各自在同一工作台上独立工作，一个切洋葱丁，一个处理红葱头，一个分切蛋白质。最后，副主厨进行检查并挑选合格的部分。

这适合设计探索、代码变体或测试生成这类任务。让每位流水线厨师各自生成许多选项，然后手动挑选最好的那些。每位流水线厨师都独立地围绕同一份任务简报工作，而由你（没错，你确实有一项小任务）来筛选结果。这是上手多智能体工作流最简单的方式，因为每项任务都完全独立，不存在文件冲突、依赖图或合并逻辑。

举个例子：我们想为 Parchi 制作 50 个吉祥物变体，于是派出了 5 个 Codex Spark 子智能体，每个生成 10 个变体。然后我们挑出喜欢的，把其余的丢掉。

这种模式最妙的地方在于：它也是把品味注入 AI 工作流的好方法。如今的模型几乎没有什么品味。很可能，你也可能缺乏品味。对大多数开发者来说，蛮力解法是搜集设计或图形模式的示例，或者给 AI 编码智能体足够多的风格指南——多到你还不如自己写 html/css。与其做这种乏味的手工流程，不如让你的主厨召集一队流水线厨师，然后挑出你最喜欢的。

在周五晚的晚餐高峰，厨房里的每个工位——炒锅、烤炉、冷菜、糕点——都在同时开火。每位流水线厨师负责不同的工作，但他们同时装盘，都为同一张订单出力。

这就是“蜂群”背后的概念，由 MoonshotAI 在训练 Kimi-K2.5 时首创。在蜂群模式下，每位流水线厨师负责一项单一、范围明确、彼此不同的任务。这些流水线厨师同时运行，共同为一个共享目标出力。

适合的场景：构建一个应用的多个独立组件、为不同模块编写测试，或把页面从一个框架移植到另一个框架。

这套设置需要几件事同时到位：

重要：关键要求是任务之间不共享文件。一旦两位流水线厨师需要编辑同一个文件，你就需要换一种模式。

品鉴菜单不会一次性全部上齐。餐前小点在任何人开始做前菜之前就上桌，前菜清空后主菜才开始装盘，甜点则等待轮到自己。但在同一道菜之内，每个工位都在并行烹饪。

这就是分阶段并行执行背后的思路。你把项目拆成几道“菜”（或“波次”），每道菜严格依赖前一道菜。在每道菜之内，任意数量的任务和流水线厨师都可以并行运行。这非常适合更大的项目，比如完整应用重建或大规模重构。

要让这种模式奏效，你需要一棵依赖树、严格的顺序和精炼的提示词。值得参考 https://factory.ai/news/missions，看看他们是如何处理这一点的。

这里有一个重建整个 UI 的真实例子。第 1 道菜探索并梳理了一切，而第 2 道菜则建立在这份共享理解之上。两道菜的流水线厨师都不需要完整的对话历史。他们拿到的恰好是与自己工单相关的上下文简报。

作为人类，你清晰地定义需要什么。菜品结构为你提供了并行性和顺序性，这就是它比纯蜂群更能扩展到真实项目的原因。

你的流水线厨师并不是每人从零做一道菜。一个工位修整并给蛋白质调味，下一个工位将其煎封，再下一个工位在烤箱中完成，最后由出菜员装盘并点缀。每个工位都有一项明确的职责，干净地交接，不会把上一张订单的酱汁拖到下一张。

在这种模式下，流水线厨师沿着出菜口依次作业。每位厨师完成一项较小的任务，验证它，然后把工件交给下一个工位。

这种模式非常适合具有清晰、可观察、可验证结果的长周期任务、研究密集型任务或多步骤流水线。核心原则：不要把所有不相关的历史都拖进一条巨大的线程里。每个阶段获得足够的上下文来完成自己的部分，然后交接。状态存在于文件和任务队列中，而不是对话中。

阶段之间干净交接。状态存在于文件和任务队列中，而不是对话历史中。

这里有一个例子，目标是让自定义模型在特定硬件上运行。请特别注意每位流水线厨师是如何拥有清晰、有边界的职责的。

在专业厨房里，主厨做好菜，但菜不会直接送到顾客面前（我倒希望如此）。相反，它首先要经过检查。一个人检查是否烹饪得当，另一个人检查是否符合订单并正确装盘。

这最后一种模式与其说是项目架构，不如说是一种纪律：你把写代码的流水线厨师与检查代码的流水线厨师分开。一位构建者烹饪。两位验证者（一位代码审查者和一位视觉/功能测试者）并行运行以验证输出。如果任一验证者标记了问题，构建者就再获得一轮机会。尤其是有了 Codex Spark 这类近乎即时编码的模型，增加验证几乎是免费的。

在这个工作流中，同一时间只有一位构建者写入，但多个验证者可以同时运行。这是避免合并冲突和上下文漂移的最重要的一条规则，而且它适用于本清单上的每一种模式。

何时使用：始终使用。无论你在运行哪种模式，都把它叠加在上面。将构建与验证分离，可以在失败级联到下游任务之前将其捕获。验证步骤使用浏览器自动化、截图和确定性测试。目标是：没有证据表明其有效，任何流水线厨师的输出都不能上到出菜口。

性能对比基于第三方基准测试或内部测试。与基于 GPU 的系统相比，观察到的推理速度提升可能因工作负载、配置、日期和所测试的模型而异。

1237 E. Arques Ave Sunnyvale, CA 94085