Supervisor 主管型和 Handoff 移交型多智能体有什么区别？

简化版

两者的区别在于控制权在哪。**Supervisor（主管型）**有一个中心 Agent 负责调度：它读任务、决定下一步交给哪个专职 Agent，专职 Agent 做完把结果交回主管，由主管决定继续派活还是结束，用户只和主管打交道，控制权始终在中心。**Handoff（移交型）**没有常驻的中心：当前 Agent 判断这件事该别人处理时，把对话和控制权整体移交给另一个 Agent，接手的 Agent 直接继续和用户对话，控制权沿着移交链条走。主管型便于统一管控、汇总和审计，但主管本身是瓶颈，每一轮都要多一次调度调用；移交型链路短、专职 Agent 直接面对用户，但要防止来回踢皮球、交接时上下文丢失或带进无关内容。选型看任务是「需要多个专家分工再汇总」（主管型）还是「按阶段把用户转给对口的人」（移交型）。

详细版

Supervisor：
  用户 ↔ 主管 ──派活──▶ 检索 Agent ──结果──▶ 主管
             ──派活──▶ 分析 Agent ──结果──▶ 主管 → 汇总回复用户

Handoff：
  用户 ↔ 前台 Agent ──移交──▶ 退款 Agent（接管对话，直接回复用户）
                                  └──移交──▶ 人工 / 其他 Agent

维度	Supervisor 主管型	Handoff 移交型
控制权	始终在主管	随移交转给接手方
谁面对用户	主管	当前持有控制权的 Agent
结果汇总	主管汇总各方结果	通常由最后接手的 Agent 直接回复
调用开销	每次派活前后都要经过主管	移交本身一次调用，之后直接处理
主要风险	主管成为瓶颈，上下文越来越长	来回移交成环，交接丢信息
适合	多个专家分工完成一件事再汇总	按问题类型或阶段转给对口的专职 Agent

完整版教学

一、为什么要拆成多个 Agent

一个 Agent 挂上几十个工具、写上所有领域的规则，会遇到三个问题：工具一多，模型选错工具的概率上升；提示词一长，不同领域的规则互相干扰；权限都集中在一个 Agent 上，任何一次误判都可能调到不该调的工具。拆成多个专职 Agent 后，每个 Agent 只带自己领域的工具和规则，权限也可以按角色收窄。

但拆分本身有代价：Agent 之间要传递任务和结果，多了调用次数、延迟和出错点。所以先问一句：一个 Agent 加清晰的工具说明能不能解决？能就不要拆。确实要拆时，才需要在主管型和移交型之间选。

二、Supervisor：中心调度、专家分工

主管型的核心是一个只负责「派活和汇总」的 Agent：

1. 主管读用户任务，决定先交给谁（比如「先让检索 Agent 查资料」）
2. 检索 Agent 用自己的工具完成，把结果交回主管
3. 主管看结果，决定下一步（「交给分析 Agent 做对比」）
4. 分析 Agent 完成，结果交回主管
5. 主管判断够了，汇总成最终回复给用户

它的好处是控制集中：每一步去哪、为什么去，都由主管决定并可记录，适合需要统一审计、统一预算控制的场景；多个专家的结果也由主管统一汇总，最终回复口径一致。代价是主管每一轮都要调用一次模型，而且它的上下文里累积了所有专家的结果，任务一长就会越来越重。常见做法是专家只把结论和关键证据交回主管，而不是把完整的工作过程都塞回去。

三、Handoff：移交控制权、直接接手

移交型更像客服转接：前台 Agent 判断用户要退款，就把对话移交给退款 Agent，后续由退款 Agent 直接和用户对话。在一些 Agent 框架里，移交被做成一个工具交给模型，比如一个「转给退款专员」的工具，模型调用它就表示把控制权交出去。

前台 Agent：识别问题类型 → 调用「移交给退款 Agent」
退款 Agent：接收对话历史 → 查订单、判规则 → 直接回复用户
            （需要时再移交给人工）

它的好处是链路短：接手之后不用每一步都绕回中心，专职 Agent 直接完成自己的事。代价是没有一个统一的地方掌控全局：谁在处理、处理到哪一步、要不要再转，都分散在各个 Agent 里。

记忆钩子：主管型像项目经理派活收活，移交型像客服转接电话。

四、交接时传什么

两种模式都有交接，交接内容决定了接手方能不能干好活：

传递方式	做法	问题
整段对话全传	接手方拿到所有历史	噪声多、可能带进上一个 Agent 的内部推理和敏感信息
只传结构化任务	任务目标、已知事实、约束、期望产出	信息精炼，但要事先定义好字段
结构化任务 + 必要的原文引用	关键原文按 ID 引用，接手方需要时再取	兼顾精炼和可追溯

推荐用结构化的交接单：这次交接要解决什么问题、已经确认的事实、还缺什么、有哪些不能做的事。接手方的权限也按它自己的角色给，不因为是从别的 Agent 转来的就继承对方的权限。

五、防止失控：上限和环检测

多智能体最常见的失控是来回踢皮球：A 觉得该 B 处理，B 又觉得该 A 处理。要有明确的上限：

最大移交次数：每次对话最多移交 3 次，超过就转人工
环检测：记录移交路径，A → B → A 出现回头就停止
主管型的上限：主管最多派活 N 轮；每个专家的单次执行有自己的轮数上限

用一组示意数字估算主管型的开销：主管派 3 次活，每次派活前后各一次主管调用，专家各自平均 4 次调用，总计 3 × 2 + 3 × 4 = 18 次模型调用；同样的任务如果单 Agent 能完成，可能只要 8 到 10 次。多出来的调用要换来明显的准确率或安全收益，才值得拆。

六、怎么选

你的任务	倾向
一件事需要多个专家分别处理，再汇总成一个结论	主管型
需要统一的审计、预算和权限控制	主管型
用户问题按类型或阶段转给不同的专职处理	移交型
接手方需要长时间直接和用户交互	移交型
任务不复杂，工具数量不多	单个 Agent

两者也可以混用：外层主管负责派活，某个专家内部再按问题类型把用户移交给更细分的 Agent。关键是每一层都说得清「控制权此刻在谁手里」。

七、常见误区与追问

误区：多智能体一定比单 Agent 强。 拆分增加调用次数、延迟和交接出错点，单 Agent 能解决就不要拆。
误区：主管型和移交型只是画法不同。 控制权归属不同：主管型始终在中心，移交型随交接转移。
误区：交接时把完整对话传过去最保险。 会带进噪声、内部推理和敏感信息，应传结构化的交接单。
误区：接手的 Agent 可以沿用上一个 Agent 的权限。 权限按接手方自己的角色给，不随交接继承。
误区：模型会自己判断什么时候不再转交。 要有最大移交次数和环检测，超过就停止或转人工。
追问：主管型的主管上下文越来越长怎么办？ 专家只交回结论和关键证据，完整过程存在外部，主管需要时按引用去取。
追问：移交型怎么知道当前是谁在处理？ 显式记录当前持有控制权的 Agent 和移交路径，日志里每次移交一条记录。

八、加强记忆

多智能体两种组织方式记「谁握控制权」：Supervisor 主管型控制权始终在中心，主管派活、专家做完交回、主管汇总回复，便于统一审计和预算，代价是主管成瓶颈、每轮多一次调度调用、上下文变长。Handoff 移交型控制权随交接转移，接手方直接面对用户，链路短，风险是来回踢皮球和交接丢信息。两者都要用结构化交接单、按接手方角色给权限、设最大移交次数和环检测。能用单 Agent 就不拆；多专家汇总选主管型，按类型转接选移交型，也可以分层混用。

项目实战落地

项目里怎么做的

《AI 多Agent智能相亲交友匹配平台》的一次智能匹配由四个角色完成：红娘主管、画像师、筛选官、审核官。四个角色用 LangGraph 的 StateGraph 手搭成主管型，没有用现成的主管封装：

    起点 → 主管 ─┬→ 画像师 ─┐
                 ├→ 筛选官 ─┼→ 回到主管
                 └→ 审核官 ─┘
                    └→ 终点

主管之后是一条条件边：它派谁就去谁那儿，说收尾（FINISH）就去终点。三个子角色各有一条回边通向主管，彼此之间没有边，不可能绕过主管互相移交。主管节点每一轮按固定顺序做五件事：

1 轮次先加一，超过 SUPERVISOR_MAX_ROUND（默认 12）就直接收尾，不再问模型
2 从数据库现查进展，拼成带固定小标题的文本：任务、当前候选统计、否决分类、本次画像、
  你可以派的角色（每个角色后面带着它当前真正可调的工具）、已经发生的事、
  已用调度轮次 / 上限、筛选官已放宽次数 / 上限等
3 把进展交给调度模型，要它只输出一个 JSON：next_agent（派谁）、instruction（给它的交代）、
  reason（这样决定的依据）
4 校验：next_agent 必须是启用中的角色编码或 FINISH，派角色时必须给出 instruction；
  不合规给一次纠正机会，第二次还不合规，整次运行判失败，并提示去检查主管的提示词
5 落一条「调度」步骤，记下派谁、交代和理由

主管手上没有工具，它只读进展、回一个决定；被派的角色拿主管的 instruction 当这一轮的任务说明，干完一律回到主管。

为什么这样取舍

下一步派谁要看全局。 还差几个交付人数、否决原因怎么分布、放宽用了几次、画像补到第几版，都要一个看得到全局的节点来判断；「人不合适换一批」和「画像不够先补画像」是两条不同的路，要按否决分类来选。
上限要有统一的闸门。 调度轮次、放宽次数、补画像版本都要有上限，中心节点就是天然的闸门；移交型要在每个角色里各判一次，容易漏，时间线上也没有统一的决策记录。
不替主管挑默认角色。 主管写了一个不存在的编码，代码顺手改成筛选官能让流程继续跑，但时间线上会记成「主管派了筛选官」，而主管并没有这么决定。这种记录看起来是成功的，比一次失败更糟。
能算准的数字不留给模型算。 「距离交付要求还差几人」「已用调度轮次 / 上限」都由代码算好摆在主管面前；让模型自己算「要 8 人、已通过 6 人、还差 2 人」，偶尔会算错，而且错得看不出来。把余量告诉主管，它才知道还能安排几轮。
轮次到顶不再问模型。 模型看不到自己已经跑了多少轮，问它只会拿到一个还想继续干的决定，能拦住它的只有代码。

代价是主管型每一轮多一次调度模型调用；移交型省掉这一次，在角色衔接固定的场景里更短、更省。项目的场景需要全局判断和统一闸门，所以选了主管型。子角色之间怎么交接产出，见「多智能体系统有哪些协作模式？如何避免失控和低效？」。

面试官还会追问

主管每一轮回看「已经发生的事」时，最多看几条？每条最长多少字？为什么要截？
「主管判断可以收尾」和「调度轮次用尽」都会让运行结束，运行记录里怎么区分？为什么要分开？
图的步数上限 recursion_limit 是怎么设的？为什么必须比调度轮次上限宽？

学完《AI 多Agent智能相亲交友匹配平台》，上面这些追问你都会迎刃而解。

简化版

详细版