AI Agent Orchestration

AI 智能体编排决定由哪个智能体、模型或工具处理任务的每个步骤、各自能看到哪些上下文，以及如何合并它们的结果。

AI 智能体编排是由多个 AI 智能体、模型和工具组成的系统中的协调层。它负责决定每个任务部分由哪个组件处理、各组件接收哪些上下文、按什么顺序运行、如何相互移交工作，以及如何合并和检查结果。编排器可以是采用固定控制流的普通代码、在运行时进行规划和委派的 LLM，也可以是两者的组合。编排能将搜索智能体、编程智能体和计算机视觉模型等专业组件整合成一个系统，完成单次大型语言模型（LLM）调用无法完成的任务。

编排层的作用#

路由：将每个子任务发送给最适合处理它的智能体或模型，通常简单步骤使用小型快速模型，困难步骤使用前沿模型。
上下文管理：只向每个智能体提供所需的指令、文件和先前结果。在独立上下文窗口中工作的子智能体可以深入探索，再返回简短摘要，避免占满主智能体的上下文。
结构化交接：以经过验证的数据在智能体之间传递结果，例如使用固定架构的 JSON，使下一步能够依赖这些数据的格式。
错误处理：重试失败的步骤、强制执行超时和预算限制，并在执行重大操作前暂停以等待人工批准。
可观测性：记录每次调用、工具结果和决策的跟踪信息，以便发现并重放故障。

常见编排模式#

大多数系统都会组合几种常见编排模式：

顺序流水线：每个智能体按固定顺序处理前一个智能体的输出，例如先起草，再审核，最后翻译。
并发扇出：多个智能体并行处理相同输入，再由聚合器合并结果或投票决定结果。
编排器-工作者：主智能体在运行时将任务拆分为子任务，委派给工作智能体，并综合它们返回的结果。这种分层模式适合步骤无法预先列出的开放式任务。
交接：一个智能体将整个对话转交给更适合处理问题的专业智能体，例如，分流智能体把计费问题交给计费智能体。
群聊与辩论：多个智能体在共享线程中轮流发言，在主持人的监督下批评并补充彼此的观点。
评估器—优化器：一个智能体生成结果，另一个智能体根据标准对其评分，并反复迭代，直到结果达标。

诸如 LangGraph、OpenAI Agents SDK、Google 的 Agent Development Kit，以及作为 AutoGen 和 Semantic Kernel 后继项目的 Microsoft Agent Framework 等框架，会将这些模式实现为具有共享状态的智能体和工具图。两个开放协议将这些组件连接起来：模型上下文协议 (MCP)将智能体连接到工具和数据，而智能体对智能体 (A2A) 协议让不同厂商构建的智能体能够相互委派任务。

智能体工作流：工作流是一套预先定义好的 LLM 调用和工具调用序列。编排则是对多个智能体和工作流进行更广泛的协调，可以由代码驱动，也可以由 LLM 在运行时规划和驱动。
智能体混合（MoA）：一种特定的并发模式，多个模型针对同一提示分别作答，再由一个聚合模型生成一份改进后的答案。通用编排通常会把不同子任务分配给不同智能体。
复合式 AI 系统：用于统称结合了模型、检索器和工具的系统。编排是这类系统内部的控制逻辑。
Kubernetes 与容器编排：在多台机器间调度和扩展容器。智能体编排协调推理和工具调用步骤，而智能体平台通常运行在底层的容器编排系统之上。

视觉模型编排#

视觉系统也会使用相同模式，只不过由模型充当工作节点：快速的目标检测器处理每张图像，并判断哪些图像需要交给速度较慢的专业模型。Ultralytics Platform Agents可以通过可视化方式构建这些工作流，将 YOLO26模块连接到用于检查检测数量或置信度范围的 Gate 模块，再连接到视觉语言模型、数据集、Slack 和 webhook 模块。这样，“YOLO → VLM Monitor”工作流只有在 YOLO 检测到人物时，才会让 VLM 描述场景。在 Python 中采用相同的路由方式时，只有检测器发现人物，才会将图像发送给姿态估计工作节点：

from ultralytics import YOLO

# Worker models: a general detector and a pose specialist
detector = YOLO("yolo26n.pt")
pose_worker = YOLO("yolo26n-pose.pt")
image = "https://ultralytics.com/images/bus.jpg"

# Orchestrator step 1: run the detector and read its findings
detections = detector(image)[0]
people = int((detections.boxes.cls == 0).sum())

# Orchestrator step 2: route to the pose worker only when people are present
if people:
    poses = pose_worker(image)[0]
    print(f"{people} people detected, {len(poses.keypoints)} poses estimated")
else:
    print("No people detected, pose worker skipped")

检测器的结果决定是否运行第二个模型，这正是门控流水线避免让昂贵模型处理不需要它们的图像的方法。

实际应用#

制造业：传感器发出警报时，编排器会将摄像头画面发送给缺陷检测智能体，并让 LLM 智能体搜索维护日志，随后把两边的发现汇总成维修工单。
文档处理：扫描页面会交给目标检测和 OCR 工作节点，以提取表格和字段；推理模型会根据政策核查提取出的数值，置信度较低的页面则交由人工审核。
智能体编程：编程智能体会启动子智能体来搜索代码库、运行测试并审查差异，从而让自身上下文专注于主要修改。
客户服务：分流智能体识别请求后，将其转交给拥有相关工具和权限的计费、技术支持或退货智能体。

成本与失效模式#

编排能带来更强的能力，但也会消耗 token 并增加复杂性。在 Anthropic 的多智能体研究系统中，由 Claude Opus 4 主智能体指挥 Claude Sonnet 4 子智能体，在一项内部研究评估中的表现比单个 Claude Opus 4 智能体高出 90.2%；不过，多智能体运行消耗的 token 约为聊天交互的 15 倍，因此这种模式主要适用于范围广、可拆分为并行部分的任务。协调也会带来新的失效方式：智能体可能误解指令、对彼此隐瞒信息，或者在任务得到核查前就停止。对多智能体 LLM 系统为何会失效的一项研究，将来自七个框架的 1,600 多条标注轨迹归纳为 14 种失效模式，并分为系统设计问题、智能体间目标不一致和任务验证三类。