如何设计多 Agent 的协作与动态切换机制？

面试考察点

1. 架构抽象能力：面试官想看你能不能把 "多 Agent 协作" 这种模糊概念拆成清晰的拓扑模型，别一上来就堆代码。Supervisor、层级式、网络式这些结构的适用边界，你能说清楚吗？

2. 动态切换的工程实现：所谓 "动态切换" 到底切什么？是切 Agent、切模型、切工具，还是切 Prompt？切换由谁触发（规则、LLM 路由、状态机）？问这块基本是在看你有没有真的在 Production 踩过坑。

3. 成本与可控性意识：多 Agent 系统最容易翻车的两个地方，token 爆炸和循环失控。Handoff 密集的 Swarm 跑一次任务可能就 7 次以上 LLM 调用、14000+ tokens，你怎么收敛？

4. 框架选型的判断力：Spring AI、LangChain4j、Spring AI Alibaba Graph、LangGraph、OpenAI Agents SDK，这么多框架你怎么挑？知道它们各自的设计哲学和适用边界吗？

核心答案

先给结论：多 Agent 协作拆开来就三件事，拓扑结构、编排策略、切换机制。2026 年生产环境的默认搭配是 Supervisor 模式搭配 Tool Calling 做动态路由，前两年很火的自由 Handoff Swarm 已经基本退场。

下面这张表是整道题的骨架：

这里有个容易混淆的点：很多人把 "多 Agent" 和 "多 Workflow" 混为一谈。Anthropic 在 "Building Effective Agents" 里做过区分，Workflow 是预设代码路径的编排，Agent 是 LLM 自主决定路径。生产环境里 Workflow 占比远高于 Agent，因为可靠性更高。

深度解析

一、先搞清楚：多 Agent 协作的 4 种主流拓扑

这是答这道题的基础，得能画能讲。

四种拓扑的特点：

• Supervisor（主管模式）：一个中央协调 Agent 负责任务分解、分发、结果聚合。好处是可控性强、好追踪调试，问题是 Supervisor 容易成瓶颈。这是 2026 年生产环境的默认选择，Beam AI、Openlayer、LangChain 的实践报告都指向它。

• Hierarchical（层级式）：嵌套的 Supervisor，把复杂任务分层分解。比如顶层 Supervisor 负责 "做一份行业研究报告"，子 Supervisor 分别管 "数据收集"、"分析"、"撰写"，每个子 Supervisor 再带自己的 Worker。任务规模大、领域跨度大的时候适合。

• Network（网络式）：Agent 之间点对点自由协作，没有中央协调者。理论上最灵活，生产里最难落地，不可控、难调试、token 成本高。Medium 上有篇 "Multi-Agent in Production: What Actually Survived" 说得挺直白，自由协作的 Network 模式在生产环境基本没活下来，只有加了严格边界和监控的版本还勉强能用。

• Swarm（交接式）：OpenAI Agents SDK 和 LangGraph Swarm 推崇的模式，Agent 之间通过 "Handoff" 交接控制权。听起来优雅，实测 token 成本高得离谱。有对比数据显示，Swarm 在多领域任务上平均 7 次以上 API 调用、14000+ tokens，Subagent 模式只要 5 次调用、9000 tokens。

选型经验：除非你有特别强的理由（比如任务边界清晰、Agent 间需要高度自治），否则老老实实用 Supervisor。这条没什么好商量的。

二、5 种编排策略：Anthropic 的经典分类

光有拓扑还不够，拓扑回答 "Who"，编排策略回答 "How"。Anthropic 在 "Building Effective Agents" 里提了 5 种经典模式，Spring AI 官方文档直接把它们落成了代码：

5 种策略什么时候用，对照表如下：

注意：Routing 和 Orchestrator-Workers 看起来很像，关键区别在于，Routing 在 开始前 就能确定走哪条路（分类决策），Orchestrator-Workers 要到 运行中 才决定分解成哪些子任务（动态决策）。这个区别面试官常追问。

三、动态切换机制：这道题的核心

到了这道题最核心的部分。所谓 "动态切换"，就是运行时根据上下文决定下一个执行哪个 Agent。业界目前主流的有 4 种机制：

机制 1：基于 Router 分类器（最常用）

用一次轻量 LLM 调用做分类，把请求路由到专门的 Agent。Spring AI 的 Routing Workflow 就是典型实现。

核心思路是用一次便宜的 LLM 调用做意图分类，输出一个标签，再根据标签分发到对应 Agent。适合类别边界清晰、相对固定的场景。

机制 2：基于 Tool Calling 的动态路由（2026 推荐）

这是 LangChain 官方在 2026 年明确推荐的方式：把每个 Agent 包装成一个 Tool，让 Supervisor 通过 Function Calling 动态选择调用哪个 Agent。

为什么推荐它？LLM 原生就懂 Tool Calling，比独立搭一个分类器更自然、更准确，还能处理多轮协作（一次调用多个 Agent）。

机制 3：基于 Handoff 的 Swarm 交接

OpenAI Agents SDK 推崇的模式。每个 Agent 在处理过程中可以说 "这个问题我搞不定，交给 Agent B"，然后把控制权和上下文一起交接过去。

听起来优雅，2026 年的实践结论却是 Handoff 模式 token 成本高、调试困难、循环风险大，只适合任务边界需要 Agent 自主判断的场景。

机制 4：基于状态机或图（最可控）

用状态机（Spring State Machine）或图结构（Spring AI Alibaba Graph、LangGraph）显式定义 Agent 之间的流转关系。生产环境对可控性要求最高的时候，这是首选。

状态机模式的好处是流程可视化、可追溯，不会出现 "Agent 之间互相踢皮球无限循环" 的灾难。

4 种机制横向对比

四、代码示例：Spring AI 实现 Routing + Supervisor

下面这段代码演示了 Router 分类加 Supervisor 编排的组合实现，这也是生产环境最常见的组合：

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.stereotype.Service;
import java.util.Map;

/**
 * 多 Agent 协作的 Spring AI 实现
 * 演示 Routing（路由）+ Supervisor（主管）模式
 */
@Service
public class MultiAgentRoutingWorkflow {

    private final ChatClient chatClient;

    // 三个专门的 Agent，由 ChatClient + 不同 System Prompt 构成
    private final Map<String, String> agentPrompts = Map.of(
        "billing", """
            你是一名资深的账单专员。专门处理退款、重复扣款、账单疑问。
            回答时务必核对金额、时间，给出明确的处理路径。
            """,
        "technical", """
            你是一名技术支持工程师。擅长排查产品 Bug、性能问题、配置问题。
            回答时按 "现象 → 可能原因 → 解决步骤" 的结构输出。
            """,
        "general", """
            你是一名通用客服代表。处理产品咨询、功能介绍、使用帮助。
            回答要友好、简洁，必要时引导用户联系对应专家。
            """
    );

    public MultiAgentRoutingWorkflow(ChatClient.Builder builder) {
        // 用便宜的模型做 Router，用强模型做业务 Agent（成本优化）
        this.chatClient = builder.build();
    }

    /**
     * 第一步：Router 分类，用一次轻量 LLM 调用判断意图
     */
    public String classifyIntent(String userInput) {
        return chatClient.prompt()
            .system("""
                你是一个意图分类器。请把用户输入归到以下三类之一，只输出标签：
                - billing：账单、扣款、退款相关
                - technical：技术问题、Bug、配置相关
                - general：其他通用咨询
                只输出 billing / technical / general 中的一个词，不要任何解释。
                """)
            .user(userInput)
            .call()
            .content()
            .trim()
            .toLowerCase();
    }

    /**
     * 第二步：根据分类结果路由到对应 Agent
     */
    public String route(String userInput) {
        // 1. Router 分类
        String category = classifyIntent(userInput);
        System.out.println("路由分类结果：" + category);

        // 2. 兜底逻辑：分类失败走 general
        String prompt = agentPrompts.getOrDefault(category, agentPrompts.get("general"));

        // 3. 对应 Agent 处理
        return chatClient.prompt()
            .system(prompt)
            .user(userInput)
            .call()
            .content();
    }
}

这个实现有几个细节值得注意：

• Router 用便宜模型，Worker 用强模型：这是常用的成本优化套路。Router 只做三分类，gpt-4o-mini 或 qwen-turbo 就够，业务 Agent 可以用更强的模型
• 兜底逻辑必须有：LLM 分类不可能 100% 准确，分类失败要能优雅降级到通用 Agent
• System Prompt 要明确角色边界：让每个 Agent 知道自己擅长什么、不擅长什么，避免越界

五、代码示例：LangChain4j 实现 Supervisor + Tool Calling 动态切换

下面是 2026 年更推荐的 Tool Calling 模式，用 LangChain4j 的 langchain4j-agentic 模块实现：

import dev.langchain4j.agentic.*;
import dev.langchain4j.service.*;
import dev.langchain4j.model.chat.ChatModel;

/**
 * LangChain4j 多 Agent Supervisor 模式
 * 把每个 Worker Agent 包装成 Tool，由 Supervisor 动态调用
 */
public class SupervisorMultiAgentSystem {

    // 1. 定义 Worker Agent 接口（每个 Agent 就是一个 Tool）
    public interface BillingAgent {

        @SystemMessage("""
            你是账单专员。处理账单、退款、扣款问题。
            只回答账单领域的问题，其他问题请明确说 "不属于我的领域"。
            """)
        @Tool("处理账单、退款、扣款相关问题")
        String handleBilling(@P("用户问题") String question);
    }

    public interface TechAgent {

        @SystemMessage("""
            你是技术支持工程师。处理 Bug、配置、性能问题。
            按 "现象 → 原因 → 解决步骤" 结构化回答。
            """)
        @Tool("处理技术问题、Bug、配置问题")
        String handleTechnical(@P("用户问题") String question);
    }

    public interface GeneralAgent {

        @SystemMessage("""
            你是通用客服。处理产品咨询、功能介绍。
            友好简洁，必要时引导用户联系专家。
            """)
        @Tool("处理通用产品咨询、功能介绍")
        String handleGeneral(@P("用户问题") String question);
    }

    // 2. 定义 Supervisor Agent，它通过 Tool Calling 动态选择 Worker
    public interface SupervisorAgent {

        @SystemMessage("""
            你是客服系统的总调度。根据用户问题，调用合适的专员工具。
            - 账单、退款、扣款 → 调用 handleBilling
            - Bug、配置、技术故障 → 调用 handleTechnical
            - 其他通用咨询 → 调用 handleGeneral
            如果一个问题涉及多个领域，可以依次调用多个工具。
            最后请基于工具返回的结果，给用户一个统一的回答。
            """)
        String process(@UserMessage String userQuestion);
    }

    // 3. 组装整套系统（AiServices 是 LangChain4j 的核心装配器）
    public SupervisorAgent build(ChatModel chatModel) {
        return AiServices.builder(SupervisorAgent.class)
            .chatModel(chatModel)
            .tools(
                AiServices.builder(BillingAgent.class).chatModel(chatModel).build(),
                AiServices.builder(TechAgent.class).chatModel(chatModel).build(),
                AiServices.builder(GeneralAgent.class).chatModel(chatModel).build()
            )
            .build();
    }
}

这段代码做的事情是：Supervisor 不直接回答用户问题，而是通过 Function Calling 决定调用哪个 Worker Agent，再把 Worker 的结果汇总给用户。这就是 2026 年 LangChain 官方推荐的 "Supervisor via Tools" 模式。

相比 Router 分类，它的优势在于：

• 可以一次调用多个 Agent：跨领域问题不会被强行分到一类
• 决策与生成分离：Supervisor 专注调度，Worker 专注业务，各司其职
• 可扩展性强：加新 Agent 只需要加一个 Tool，不用改 Router 逻辑

六、生产环境的关键决策点

这块是面试加分项，能讲出来基本就是 "做过"，不是 "看过"。

1. 状态管理：多轮对话必须持久化

多 Agent 系统只做单轮请求很简单，一旦涉及多轮对话（用户在前一个 Agent 问到一半，切到下一个 Agent 还要能接上下文），就必须做状态持久化。

LangGraph 的标准做法是 PostgreSQL Checkpointer，把每个会话的状态（消息历史、当前所在 Agent、共享变量）都存到数据库，下一次请求时根据 session_id 恢复。

2. 防止 Agent 循环调用

多 Agent 系统有个经典翻车场景：Agent A 调用 Agent B，Agent B 又调用 Agent A，无限循环烧 token。必须加循环检测和最大调用次数限制。

Spring AI Alibaba Graph 和 LangGraph 都支持在图定义里加 max_iterations，超过就强制终止。这是上线前必须配的兜底。

3. 共享内存 vs 私有内存

Agent 之间要不要共享上下文？

• 共享内存：所有 Agent 看到同一份消息历史，协作流畅但 token 消耗大
• 私有内存 + Handoff 上下文：每个 Agent 只看自己相关的上下文，交接时只传必要信息，token 省但容易丢上下文

实测下来，私有内存加精准 Handoff 上下文在大型系统里更划算。

4. 可观测性：每一步都要埋点

多 Agent 系统是黑盒里的黑盒。生产环境必须有完整的 Trace，LangSmith、Langfuse、Spring AI 的 Observation API 都行。每个 Agent 的输入、输出、调用链路、token 消耗、耗时都要可追溯，否则出问题完全没法排查。

5. 框架选型决策树

七、常见踩坑

踩过的坑写出来，你少走点弯路：

• 坑 1：一上来就上 Network 模式。以为越灵活越好，结果 Agent 之间互相调用，token 烧得飞快，调试的时候完全不知道哪个 Agent 出了问题。生产环境老老实实从 Supervisor 开始。

• 坑 2：Router 用强模型。Router 只做分类，用 gpt-4 级别的模型又慢又贵，gpt-4o-mini 或 qwen-turbo 就够，准确率没差几个点，成本能省一半。

• 坑 3：没有兜底机制。LLM 分类总有概率出错，没做 default 分支，用户问题直接抛异常，体验极差。

• 坑 4：Agent 边界模糊。System Prompt 写得太宽泛，多个 Agent 都觉得自己能处理，Supervisor 反复纠结，调用链变长。每个 Agent 的 System Prompt 必须明确写 "我不处理什么"。

• 坑 5：忽略成本监控。多 Agent 系统的 token 消耗是单 Agent 的好几倍，不上监控分分钟烧爆预算。建议每个 Agent 都打上 agent_name 标签，按 Agent 维度统计成本。

面试高频追问

1. 追问：Supervisor 和 Orchestrator 有什么区别？

   • Supervisor 偏路由分发：把请求分给合适的 Worker，再聚合结果。Supervisor 自己不干活，只做调度。
   • Orchestrator 偏任务分解：把复杂任务拆成多个子任务，动态决定要分解成几个、由谁来做。Orchestrator 参与规划决策。
   • 实际工程里两者经常混用，边界没那么严格。

2. 追问：多 Agent 系统怎么评估效果？

   • 任务完成率：最终是否解决了用户问题
   • 路由准确率：Router 的分类是否正确
   • Token 效率：完成任务平均消耗的 token 数
   • 平均轮次：完成任务平均需要多少次 Agent 调用
   • 人工接管率：被 Escalate 到人工的比例
   • 业界常用 LangSmith、Langfuse、RAGAS 做自动化评估。

3. 追问：A2A（Agent2Agent）协议是什么？

   • 2025 年 Google 提出、2026 年逐渐成熟的 Agent 互操作标准。让不同框架（LangGraph、Spring AI、OpenAI Agents SDK）构建的 Agent 可以跨系统协作。
   • 解决的是 "Agent 孤岛" 问题，定位类似于微服务时代的 RPC 协议。
   • 目前还在早期，但值得关注。

4. 追问：什么时候不该用多 Agent？

   • 任务边界清晰、单 Agent 能搞定，就别上多 Agent，徒增复杂度
   • 实时性要求极高的场景，多 Agent 链路长，延迟是硬伤
   • 成本敏感的场景，多 Agent 的 token 消耗是单 Agent 的 3-10 倍
   • Anthropic 的建议挺实在：先用单 Agent + Workflow 解决，实在不够再上多 Agent。

常见面试变体

• 变体一："设计一个智能客服系统，怎么组织多个 Agent？"（架构设计题，套用这套框架）
• 变体二："Agent 之间怎么共享上下文？"（聚焦共享内存 vs Handoff 上下文）
• 变体三："多 Agent 系统的 token 成本怎么控制？"（聚焦成本优化，Router 弱模型、Subagent vs Swarm 对比）
• 变体四："为什么 2026 年业界从 Handoff Swarm 转向 Supervisor via Tools？"（聚焦趋势变化，生产实践结论）

记忆口诀

记住 "拓扑四件套，编排五模式，切换四机制"：

• 拓扑：Supervisor（生产默认）、Hierarchical（复杂分层）、Network（慎用）、Swarm（贵）
• 编排：Chain、Parallel、Routing、Orchestrator-Workers、Evaluator-Optimizer
• 切换：Router 分类、Tool Calling（2026 首选）、Handoff、状态机 / 图

再加一句 "Supervisor via Tools 是 2026 的主流解法"，基本就到位了。

总结

多 Agent 协作的设计就是在灵活性、可控性、成本三者之间找平衡。2026 年业界已经基本达成共识，Supervisor 模式搭配 Tool Calling 动态路由是生产环境的主流解法，Handoff Swarm 虽然优雅但成本太高，Network 模式基本只存在于实验室。代码层面，Spring AI 的 ChatClient + Routing Workflow 适合简单场景，LangChain4j 的 langchain4j-agentic 模块适合复杂的 Tool Calling 编排，Spring AI Alibaba Graph 适合强可控的图结构工作流。面试时记住一个原则：先单 Agent，再 Workflow，最后才考虑多 Agent，这个递进逻辑本身就是加分项。