Agent编排模式（Orchestrator/Worker/Critic）

可视化演示

动态展示Orchestrator-Worker-Critic三层编排架构：编排器分解任务分发给工作器并行执行，评论器评估输出质量，编排器聚合最终结果。

架构总览：一间分工明确的厨房

想象一家承办婚宴的餐厅后厨。客人订下五十桌流水席，主厨不会一个人从头炒到尾，而是把整张菜单拆成冷菜、热菜、汤品、甜品，交给不同灶台的师傅；每道菜出锅前，还有一位试菜员先尝一口——太咸打回重做，合格才允许出菜。主厨、灶台师傅、试菜员各干各的活，又紧紧咬合成一条流水线。

当我们要用大模型完成一项复杂任务时，同样的事正在发生。看似简单的问题背后往往藏着十几个步骤，比如“写一份行业研究报告”就涉及资料检索、数据分析、观点提炼、格式排版。与其让一个 Agent 用超长提示词包揽全部，不如派三个角色分工协作——这就是 Agent 编排模式中的 Orchestrator（编排器）、Worker（工作器）与 Critic（评论器）。

在这套架构中，编排器是“主厨”，负责把主任务拆解成子任务、分配给工作器并收集结果；工作器是“各灶师傅”，每个只负责自己的子任务、在自己的上下文里独立执行；评论器是“试菜员”，对照质量标准评估聚合后的结果，不合格就打回重做。三者通过结构化消息形成闭环：拆分 → 执行 → 聚合 → 评审 → 反馈 → 再执行。

就像婚宴上每道菜无论出自哪个灶台，最终都要被摆上统一规格的餐盘，汇聚成一桌完整的席面——编排器聚合所有工作器的产物，再由试菜员把关，才敢端到客人面前。

编排器职责：拆菜单的主厨

婚宴主厨接到订单后，第一步不是点火下锅，而是对着菜单想清楚：哪些菜可以提前备料、哪些必须现炒、哪几道菜共用一口锅需要错开时间。这份“拆单”的功力，直接决定后厨是否手忙脚乱。

在 Agent 系统中，Orchestrator 承担同样的“拆单”职责。它接收用户的高层级任务描述，将其分解为粒度合适的子任务，明确每个子任务的输入输出，再按依赖关系安排顺序——能并行处理的绝不串行，有依赖的排好先后。整体上，编排器做的是全局规划而非具体执行。

编排器的第二重职责是调度与聚合：把子任务分发给最合适的工作器，收集结果后按任务逻辑组织成完整答案，而不是简单拼接。实现上，编排器通常维护一个任务列表与执行状态表，支持失败重试与动态调整。

就像好主厨会把“红烧肉”分给炖菜师傅、把“糖醋鱼”分给案板师傅，编排器的价值不在亲自动手，而在于分得清、派得准、收得齐。

工作器职责：各守灶台的师傅

婚宴后厨里，冷菜师傅只碰凉菜，炖菜师傅守着砂锅，甜品师傅看管烤箱。每位师傅案板上的工具、火候习惯都不相同，但互不串台，把自己的菜做好就是全部职责。

Worker 角色正是如此。每个工作器在独立的上下文窗口中运行，拥有自己的提示词、工具集与知识范围，只处理编排器发来的那一个子任务。独立上下文带来最大的好处是：彼此不污染、相互不阻塞，可以真正并行推进，这也是该层被设计成多个而非一个的原因。

并行的时间收益可以直接量化。如果 n 个子任务彼此独立，串行执行总耗时是各子任务耗时之和，而并行执行的总耗时只取决于最慢的那个工作器。子任务拆得越均衡，加速效果越明显——前提是任务真能被拆开。

当然，后厨并非只有并行——炖汤要时间、摆盘要顺序，工作器执行完也会把成品端回传菜口，交给主厨统一安排。工作器只管做好自己的菜，这是它的本分，也是它高效的原因。

评论器职责：把守出菜口的试菜员

婚宴出菜口站着的那位试菜员，不是随便尝一口就放行的。他心里有一本账：这道菜咸淡如何、摆盘是否齐整、温度是否达标。一旦不合标准，他会把菜退回灶台，并附上一句具体的话：“少放半勺盐，回锅三十秒！”

在多 Agent 系统中，Critic 承担的就是这个“把门”角色。它接收聚合后的结果，对照预定义的评估标准进行质量评估——答案是否完整、格式是否符合要求、逻辑是否自洽、数据是否准确，然后将判定结果与改进意见一并返回。

评论器的关键价值在于反馈的“可操作性”。泛泛的“写得不好”无法指导工作器改进；而“第三章缺少数据来源、结论与论据脱节”这样的反馈，才能让下一轮迭代真正变好。逐轮改进的过程可以建模为质量迭代方程：每轮结果在吸收反馈后向目标质量靠近。

试菜员从不亲自炒菜，但整场婚宴的出品质量由他把控。评论器同样不产出内容，却是让系统从“大概率可用”走向“稳定达标”的那道闸门。

协作机制：后厨的铃声与传菜口

后厨能有序运转，靠的不只是各人埋头干活：出菜口有传菜铃，主厨根据上菜节奏喊“三号桌冷菜先上”；哪口锅糊了，师傅喊一嗓子，主厨马上重新安排。消息、状态、异常——这些看不见的协作细节，才是流水线的心脏。

在技术上，编排器、工作器、评论器之间的协作依赖清晰的消息传递与状态管理。子任务、执行结果、评审意见都以结构化消息（如 JSON 或函数调用）在角色间流转；编排器维护一张全局状态表，记录每个子任务的“待执行 / 执行中 / 已完成 / 失败”状态，这是全局调度与结果聚合的基础。

异常处理与终止条件是这个环节最容易忽视的部分。工作器超时或返回错误时，编排器要能重新调度或更换策略；评论器连续打回时，系统必须有最大迭代轮次与质量达标阈值来兜底，避免无限循环烧掉大量 Token。

就像婚宴上菜讲究节奏，传菜铃一响就要有人响应——这套协作机制决定了系统在真实负载下是行云流水还是一团乱麻。

架构价值：为什么后厨要分工

有人会问：主厨一个人把五十桌菜全做了不行吗？不行。一个人连轴转，速度快不了，出错也没人兜底，一旦某道菜失手整场宴席就毁了。分工的后厨，反而更可靠、更耐折腾。

这一逻辑映射到 Agent 系统就是架构价值的核心：可靠性、可调试性、可扩展性与成本控制。职责分离让每个角色的行为边界清晰，出错时能快速定位是“拆单错了、做菜错了、还是把关错了”；新增一个工作器就像给后厨加一个专做川菜的灶台，不必改动其他环节。

成本控制值得展开：与其让一个满身“技能”的超级 Agent 处理超大上下文，不如让多个专精工作器各自用小上下文干活，再让评论器把关重做。小模型单次调用便宜、上下文短，组合起来的整体成本往往低于一次“大而全”的调用，而迭代轮次 K 是成本的主要变量。

宴席办完，主厨最得意的事不是哪道菜惊艳，而是整场零失误；一套编排合理的 Agent 系统也是如此——不追求单次输出的侥幸，而是用体系保证“每次都还行”。

应用案例：真实的宴席菜单

不同规模的宴席，主厨的排兵布阵完全不同：十人小桌，主厨顺手就做；百人流水席，就必须拆单、分派、试菜一条龙。Agent 编排模式也是同样的道理——任务越复杂、环节越多，这套三层分工的价值越明显。

在工业界，最常见的落地场景是复杂报告撰写。一个投研报告任务被编排器拆成行业调研、财务分析、合规审核三个子任务，三个工作器并行检索与生成，评论器检查每个论断是否有数据支撑，不合格的章节打回补充。类似的流水线也出现在代码生成与评审中：API 设计、数据库建模、前端页面由不同工作器产出，评论器按编码规范和安全隐患清单逐条审查。

工程上选择工作器时，通常会计算“子任务与工作器技能的匹配度”，选出最合适的那一位。这套匹配逻辑可以形式化为公式——匹配度越高，越可能被选中执行该子任务。

宴席越大，越需要标准化的流程；Agent 任务越复杂，越需要这套“拆、做、评”的编排范式。从投研报告到代码交付，这套模式正在成为多 Agent 系统最实用的“后厨手册”。

AI 应用场景

Python 演示

class Worker:    def __init__(self, name, skill):        self.name = name        self.skill = skill     def execute(self, subtask):        return f"{self.name}({self.skill})完成[{subtask}]"  class Critic:    def evaluate(self, result):        passed = "修订版" in result        feedback = "质量达标,放行" if passed else "细节不足,退回修订"        return passed, feedback  class Orchestrator:    def __init__(self, workers, critic, max_rounds=3):        self.workers = workers        self.critic = critic        self.max_rounds = max_rounds     def decompose(self, task):        return [part.strip() for part in task.split(",")]     def aggregate(self, results):        return " | ".join(results)     def run(self, task):        subtasks = self.decompose(task)        final = ""        for round_no in range(1, self.max_rounds + 1):            mark = "" if round_no == 1 else "修订版"            results = [w.execute(mark + s) for w, s in zip(self.workers, subtasks)]            final = self.aggregate(results)            passed, feedback = self.critic.evaluate(final)            print(f"第{round_no}轮交付: {final}")            print(f"评论器反馈: {feedback}")            if passed:                break        return final  if __name__ == "__main__":    workers = [        Worker("市场组", "行业调研"),        Worker("财务组", "财报分析"),        Worker("合规组", "政策审核"),    ]    critic = Critic()    boss = Orchestrator(workers, critic, max_rounds=3)    print("最终交付:", boss.run("行业调研,财报分析,政策审核"))

1. subtasks = self.decompose(task)编排器把主任务按逗号拆成子任务，相当于主厨拆单。
2. results = [w.execute(mark + s) for w, s in zip(self.workers, subtasks)]循环让每个工作器并行执行自己的子任务。
3. passed, feedback = self.critic.evaluate(final)评论器评估聚合后的结果并返回反馈。
4. for round_no in range(1, self.max_rounds + 1):迭代直到通过或达到最大轮次，防止无限循环。
5. boss = Orchestrator(workers, critic, max_rounds=3)把工作器与评论器组装进编排器，形成完整系统。

常见误区

面试题