一项 AI 功能只要越过“单次提示—单次回答”，就会进入编排问题：哪些步骤固定，哪些需要模型判断；哪些可以并行，哪些必须等待；失败后从哪里恢复；一次运行最多可以消耗多少 Tokens。
Vercel 总结了六种常见模式。它们不是从初级到高级的能力排行榜，而是一组针对不同任务结构的工具。最重要的原则只有一个：从能够解决问题的最低复杂度开始，只有出现明确能力缺口时再升级。
#1. 单 Agent 循环：默认起点
模型调用工具、读取结果、更新上下文，然后继续下一步，直到完成或触发停止条件。这种结构共享一个上下文，调试简单，没有跨 Agent 交接损耗，适合能放进单一上下文窗口、步骤之间依赖较强的任务。
单 Agent 并不等于只能调用一次模型。只要循环具备工具权限、状态和明确上限，它已经能够完成大量研究、客服和编码工作。原文引用的研究指出，在相同计算预算下，多跳推理任务中的单 Agent 基线可以持平甚至超过多 Agent；不少所谓多 Agent 优势，本质上来自使用了更多计算。
升级信号应该是可观察的问题，例如上下文拥塞、存在真正独立的子任务，或者不同输入确实需要不同专长，而不是“多 Agent 听起来更先进”。
#2. 提示链：步骤已知，顺序固定
提示链把工作拆成预先定义的顺序，例如提取事实、生成草稿、检查格式、发布。每一步只处理一个窄问题，输出成为下一步输入。它适合边界稳定、可以插入程序化校验的流程。
代价是错误会沿链条传播。若每一步准确率为 95%，十步全部正确的概率约为 60%；每步 90% 时只剩约 35%。因此，Schema 校验、必填字段检查、政策阈值和人工审批不是附加功能，而是阻止错误继续扩散的闸门。
#3. 路由：不同输入走不同处理器
路由先判断输入类型，再交给对应模型、提示或工具链。它适合类别边界清晰的业务，例如账单问题、技术支持和退款请求由不同流程处理。
路由器的准确率决定整个系统上限。只要分类错了，后面再强的专家也在处理错误问题。能用规则、关键词或结构化字段稳定完成的分类，不必强行增加一次模型调用；需要模型判断时，则必须用接近生产分布的数据验证边界案例，并保留“不确定”出口。
#4. 并行化：子任务预先可知且互相独立
并行模式同时运行多个已知子任务，再用程序或模型聚合结果。它可以降低总延迟，也可以通过多种视角提高覆盖率。典型例子是同时检索多个独立来源、让多个评审检查不同风险，或将一组互不依赖的文件分配给不同工作单元。
真正的约束在聚合端。若输出格式、证据标准和冲突处理规则没有在并行前定义，节省的时间会在合并阶段全部还回去。对共享状态有强依赖的任务也不适合直接扇出，否则会引入竞态、重复工作与覆盖冲突。
#5. 编排器—工作者：运行时才知道怎样拆解
当子任务数量和类型无法在开发时预先确定，可以让中央编排器读取请求、动态分解、选择工作者并综合结果。代码修改是典型场景：要改几个文件、需要查哪些文档，只有理解任务和仓库后才知道。
这种模式给每个工作者独立上下文，能隔离大量细节，但也同时增加调用次数、信息压缩损失和协调成本。它不是并行模式的豪华版本：并行化的子任务在运行前已知，编排器—工作者则把分解本身交给模型。
#6. 评估器—优化器：质量标准清晰时反复改进
一个模型生成结果，另一个模型按明确 Rubric 评估并给出反馈，随后进入下一轮，直到达到阈值或触发次数上限。它适合确实能通过批评持续改善的写作、代码和方案设计。
如果质量标准含糊，循环会退化成无休止的“再改一下”。所以必须设置可测量的终止条件、总成本与轮次上限。初稿已经足够好、或者用户需要实时响应时，这种模式通常得不偿失。
#一张选择顺序比一张架构图更有用
可以用四个问题快速选择：
- 任务能否在一个上下文和工具循环里完成？能，就用单 Agent。
- 子任务是否固定且有先后依赖？有，就用提示链。
- 是否只是不同输入需要不同流程？是，就用路由。
- 子任务能否独立并行？已知就并行，未知才使用编排器—工作者。
- 是否存在清晰、可执行的质量标准？存在且迭代收益明确，再增加评估器—优化器。
成本必须和结构一起估算。原文指出，多 Agent 系统的 Token 消耗可能达到普通对话的 15 倍。工作者数量、独立上下文、重试和批评循环都会乘法放大费用；高价值任务可以承担这些成本，普通任务则可能被架构本身拖垮。
#生产化的共同底座
无论选择哪一种模式，都需要四类运行时能力：持久化状态与断点恢复、统一模型路由与故障切换、对不可信代码的隔离执行，以及贯穿编排器和工作者的追踪。它们决定系统出错时能否继续、能否解释和能否安全停止。
编排模式解决的是任务结构，不是产品价值。先用最小结构把端到端流程跑通，再根据真实失败数据增加路由、并行或评估循环，往往比一开始搭建复杂“Agent 团队”更快进入可靠生产。