构建多智能体工作流的经验教训：从单智能体瓶颈到五种实用模式
本文分享了构建多智能体工作流的实践经验，从单智能体的局限出发，介绍了使用协调者和子代理的多智能体架构，并详细阐述了五种经过验证的工作流模式，帮助开发者突破AI编码的效率瓶颈。
在AI编码工作流中，许多开发者很快就遇到了单智能体的天花板：一个代理无法处理复杂项目，往往导致耗时且结果不佳。本文通过厨房的比喻，深入介绍了多智能体工作流的实践方法，并总结了五种经过验证的模式。
单智能体的问题在于期望过高且任务分解不足。当项目从简单的HTML游戏转向更实际的应用时，开发者会发现自己花费大量时间等待AI“合成”、“浏览”，最终得到糟糕的代码和膨胀的上下文窗口。而多智能体架构引入了一位“主厨”（协调者），负责将订单分解为可验证的任务，并分派给多位“厨师”（子代理）执行。每个子代理拥有独立的上下文窗口，专注于自己的任务，从而避免了单智能体上下文膨胀和效率低下的问题。
多智能体工作流近期变得更为实用，原因包括底层模型性能提升和流行AI编码代理简化了多智能体编排。例如，OpenAI的Codex工作流和Anthropic的Claude Code及MCP生态系统都支持这种架构。最大的突破在于速度：Codex Spark的运行速度约为每秒1200个token，使得引入并行和验证步骤变得可行。一个实际案例中，使用Codex和Figma MCP将网站复制到Figma的任务，单智能体工作流平均耗时36.5分钟，需要12次人工干预且全部失败；而多智能体工作流仅需5.2分钟，2次人工干预，首次尝试即成功。
这种架构带来了三个直接优势：
- Token效率：有效上下文窗口从约20万扩展到2500万以上。协调者不直接读写文件或查看工具调用结果，而是通过delegate_task生成子代理，每个子代理拥有全新的上下文窗口，从而避免了上下文丢失和频繁压缩。
- 控制力：可以通过顺序执行的工作流严格控制每个步骤。协调者按照脚本生成每个阶段的子代理，包括任务分解、探索、测试、文档等步骤。内部试验表明，这种顺序循环将手动干预减少了84.3%。
- 速度：可以并行运行明确定义的任务。生成五个吉祥物变体，并行仅需约一分钟，而顺序执行需五分钟，速度提升约5倍。
文章还总结了五种实用的多智能体工作流模式：
- 预备线（Prep Line）：多个子代理独立生成多个选项，然后人工筛选最佳结果。适合设计探索、代码变体或测试生成。例如，为Parchi创建50个吉祥物变体，使用5个Codex Spark子代理各生成10个，然后挑选最佳。
- 晚餐高峰（Dinner Rush）：多个子代理同时处理不同的独立任务，共同完成一个目标。此模式借鉴了MoonshotAI的“群”概念，适合构建应用的多个独立组件。关键要求是任务不共享文件。
- 顺序套餐（Courses in Sequence）：将项目分成多个波次，每个波次内并行，波次之间顺序依赖。适合大型重构或全面重建。每个波次的子代理只需获取与自身任务相关的上下文。
- 备料到上菜（Prep-to-Plate Assembly）：子代理顺序执行，每个完成一个小任务并验证，然后传递给下一个。适合长期研究或多步骤流水线，状态保存在文件和任务队列中，而非对话历史。
- 戈登·拉姆齐（Gordon Ramsay）：增加专门的验证子代理，对编码结果进行检查，确保质量。这是一种纪律而非架构，将编写代码的子代理与检查代码的子代理分离。
这些模式都基于一个核心原则：将问题分解为小而明确的任务，并让每个子代理拥有最小必要上下文。通过实践这些模式，开发者可以突破单智能体的限制，构建更可靠、高效的AI工作流。随着模型速度的持续提升，多智能体工作流将成为AI编码的主流范式。