什么是 Multi-Agent？Single-Agent 和 Multi-Agent 的设计方案？

面试考察点

1. 概念分水岭：面试官想确认你是不是真懂 Single-Agent 和 Multi-Agent 的区别。不是那种 "一个对多个" 的表面回答，而是要你说清楚为啥要拆、啥时候拆。
2. 架构设计能力：Multi-Agent 可不是把几个 Agent 凑一块就完事，重点在协同模式上（顺序、并行、路由、监督）。面试官想看你懂不懂主流的编排方式。
3. 工程权衡意识：不少人一上来就吹 Multi-Agent 有多强，可真到生产环境，Single-Agent 加上 MCP 工具往往就够用了。能不能讲清楚两者的适用场景、成本和稳定性差别，是区分 "背了概念" 还是 "真做过" 的分水岭。

核心答案

Multi-Agent（多智能体） 说白了，就是把一个复杂任务拆成几块，交给多个专业化的 Agent，让它们按某种协同模式一起把活干完。

一句话区分两者：

• Single-Agent：一个 Agent 揣着一堆工具，从头到尾自己干。
• Multi-Agent：好几个分工明确的 Agent，按顺序、并行、路由、监督这些模式配合着干活。

打个比方，Single-Agent 像个全能管家，啥事自己扛；Multi-Agent 就是一个团队，产品、架构、开发、测试各管一摊。

关键结论：Multi-Agent 不是银弹。它真正解决的，是 Single-Agent 在复杂任务里会遇到的三个坑：工具太多选不准、上下文太长记不住、专业度不够做不精。

深度解析

一、Single-Agent：单兵作战的经典架构

Single-Agent 是目前绝大多数 AI 应用采用的架构，它就是一个 Agent 配一组 Tools，靠 ReAct（Reasoning + Acting）循环反复折腾："思考 → 调用工具 → 看结果 → 再思考"。

上图就是 Single-Agent 的执行流程，说白了就是一个 ReAct 循环：

• 感知：接收用户输入和工具返回结果
• 规划：LLM 决定下一步该干啥、该用哪个工具
• 执行：调用对应的 Tool（搜索、数据库查询、API 调用等）
• 反思：根据工具返回结果，判断是否已经足够回答用户
• 循环：不满足就继续，满足就输出最终答案

Single-Agent 的好处挺明显：

• 实现简单：一个 Agent 配几个工具就跑起来了，Spring AI 的 ChatClient + @Tool 注解几十行代码搞定
• 维护成本低：没有跨 Agent 通信、没有状态同步问题
• MCP 协议加持：通过 MCP（Model Context Protocol）可以把外部能力以工具形式接入，不用动架构 就能一直加能力

但短板也摆在那：工具一旦超过 10-15 个，LLM 选工具的准确率就明显往下掉；任务一复杂，上下文堆到几万 token，模型就开始 "失忆"、逻辑乱套。

二、Multi-Agent：团队协作怎么搞

Multi-Agent 的思路就四个字：专业分工。官方的定义挺直白：

Multi-agent 将复杂的应用程序分解为多个协同工作的专业化 Agent。与依赖单个 Agent 处理所有步骤不同，Multi-agent 架构允许你将更小、更专注的 Agent 组合成协调的工作流。

上图就是 Multi-Agent 的大致样子：上面有个编排层（Orchestrator / Supervisor）管调度，底下挂着一堆专业 Agent。每个 Agent 只管自己那一摊，上下文各过各的，互不打扰。

碰到下面这三种情况，Multi-Agent 就派上用场了：

• 工具太多：单个 Agent 揣的工具太多，挑哪个容易选错
• 上下文太长：上下文或记忆越积越多，单个 Agent 跟不过来
• 任务需要专业化：比如得分规划器、研究员、数学专家这些角色

有实验数据可以参考：在软件开发和自动化审计场景里，多智能体协作比单 Agent 循环效率高出约 300%，4 个专业 Agent 并行跑，任务完成时间从小时级压到分钟级，准确率还能提 40%。

三、Single-Agent vs Multi-Agent：到底怎么选？

这道对比题面试官特别爱问。我把关键维度整理成了下面这张表：

选型建议（这条一定要记住，面试加分）：

• 先试 Single-Agent + MCP 工具，这是性价比最高的方案，也不增加架构复杂度
• 当出现这些信号时，再升级到 Multi-Agent：
  • 工具数量爆炸，LLM 选不准
  • 任务能明显拆成独立子任务
  • 需要并行提速
  • 需要多角色协作（如代码开发 + 代码评审）

四、Multi-Agent 四大协同模式（重点！）

这块是 Multi-Agent 设计的核心，也是面试高频考点。Spring AI Alibaba 1.1.x 把这些模式都封装好了，拿来就能用。

1. 顺序执行（SequentialAgent）

好几个 Agent 排着队依次跑，上一个的输出就是下一个的输入，流水线那种。

上图就是顺序执行：写作 Agent 先把文章写出来，结果存进状态的 article 字段；翻译 Agent 再从状态里把 article 取出来，翻译完输出最终结果。

适用场景：写文章 → 翻译、需求分析 → 代码生成、草稿 → 审校。

Java 代码示例（Spring AI Alibaba）：

// 写作 Agent：产出文章
ReactAgent writerAgent = ReactAgent.builder()
        .name("writer_agent")
        .model(chatModel)
        .description("专业写作 Agent")
        .instruction("你是一个知名作家，请根据用户提问创作：{input}")
        .outputKey("article")  // 输出存到状态的 article 字段
        .build();

// 翻译 Agent：通过占位符引用上一步的输出
ReactAgent translateAgent = ReactAgent.builder()
        .name("translate_agent")
        .model(chatModel)
        .description("专业翻译 Agent")
        .instruction("""
                你是一个翻译官，请翻译以下文章：
                {article}          // 通过占位符引用写作 Agent 的输出
                只返回翻译结果。
                """)
        .outputKey("translated_article")
        .build();

// 组装成顺序工作流
SequentialAgent blogAgent = SequentialAgent.builder()
        .name("blog_agent")
        .description("先写文章再翻译")
        .subAgents(List.of(writerAgent, translateAgent))
        .build();

// 执行
Optional<OverAllState> result = blogAgent.invoke("帮我写一篇 100 字的散文");

这里有个关键设计要看明白：outputKey 会把每个 Agent 的输出存进共享状态（OverAllState），后面的 Agent 拿 {article} 这种占位符去取就行。状态隔离 + 占位符传值，这就是 Multi-Agent 数据流转的基础。

2. 并行执行（ParallelAgent）

几个 Agent 同时拿到一样的输入，各跑各的，最后把结果合到一起。

上图就是并行模式：输入同时发给三个创作 Agent，各自独立产出，再由自定义的合并策略（MergeStrategy）把结果归拢到一块。

适用场景：多维度的并行查询（用户信息 + 订单信息）、多角度内容创作、批量数据处理。

// 三个并行的创作 Agent
ReactAgent proseAgent = ReactAgent.builder()
        .name("prose_writer")
        .model(chatModel)
        .instruction("你是散文作家，根据主题 {input} 创作一篇 100 字散文")
        .outputKey("prose_result")
        .build();

ReactAgent poemAgent = ReactAgent.builder()
        .name("poem_writer")
        .model(chatModel)
        .instruction("你是诗人，根据主题 {input} 创作一首现代诗")
        .outputKey("poem_result")
        .build();

// 并行 Agent，支持自定义合并策略
ParallelAgent parallelAgent = ParallelAgent.builder()
        .name("parallel_creative")
        .description("并行创作散文和诗歌")
        .subAgents(List.of(proseAgent, poemAgent))
        .mergeOutputKey("merged_results")
        .mergeStrategy(new CustomMergeStrategy())  // 自定义结果合并逻辑
        .build();

并行模式最大的好处就是 快。3 个 Agent 一起跑，耗时只看最慢的那个，不是三个加起来。

3. 智能路由（LlmRoutingAgent）

让 LLM 临场决定把请求派给哪个专业 Agent，相当于一个智能调度员。

上图就是路由模式：路由 Agent 拿着 description 和用户意图，让 LLM 判断这活儿该交给谁。每个子 Agent 的 description 写的是自己的本事，路由 Agent 就照这个来选。

适用场景：客服系统分流（售前 / 售后 / 投诉）、多技能助手、按类型分发的处理流程。

LlmRoutingAgent routingAgent = LlmRoutingAgent.builder()
        .name("content_router")
        .model(chatModel)
        .description("根据用户需求路由到合适的专家 Agent")
        .subAgents(List.of(writerAgent, reviewerAgent, translatorAgent))
        .systemPrompt("""
                你是一个智能路由 Agent，根据用户意图选择最合适的子 Agent。
                可选 Agent：writer_agent（写作）、reviewer_agent（润色）、translator_agent（翻译）
                只返回 Agent 名称，不要其他解释。
                """)
        .build();

// 路由 Agent 会自动判断：写作任务 → writer_agent，翻译任务 → translator_agent
Optional<OverAllState> result = routingAgent.invoke("帮我把这段话翻译成英文");

路由模式有个关键：description 一定得写清楚，LLM 全靠它来判断这活儿该派给谁。

4. 监督者模式（SupervisorAgent）

这是功能最强、也最复杂的一种。你可以把它理解成给 Multi-Agent 配了个 "项目经理"，循环调度各个子 Agent，直到任务做完为止。

上图就是监督者模式的核心循环：监督者每次都先分析当前状态，再决定下一步叫哪个子 Agent 上场；子 Agent 干完活回到监督者这儿，监督者接着判断，是继续派别的 Agent，还是直接返回 FINISH 收工。

它跟路由模式最大的差别在于：监督者能做多步骤循环。举个例子，用户说 "先写文章再翻译"，路由模式只能二选一，监督者却能分两步走，先叫写作 Agent，再叫翻译 Agent。

SupervisorAgent supervisor = SupervisorAgent.builder()
        .name("content_supervisor")
        .model(chatModel)
        .systemPrompt("""
                你是内容管理监督者，负责协调多个 Agent 完成用户需求。
                1. 分析需求，拆解为子任务
                2. 依次选择合适的子 Agent 处理
                3. 所有任务完成后返回 FINISH
                可用 Agent：writer_agent、translator_agent
                只返回 Agent 名称或 FINISH。
                """)
        .mainAgent(writerAgent)
        .subAgents(List.of(writerAgent, translatorAgent))
        .build();

// 监督者会自动分步执行：写作 → 翻译 → FINISH
Flux<NodeOutput> flux = supervisor.stream("先写一篇春天短文，然后翻译成英文");

四大模式对比小结

5. 混合编排：真实业务的组合拳

真到了生产环境，很少有只用一种模式的，基本都是几种混着来。拿电商售后处理举个例子：

上图是一个完整的电商售后工作流：先用 并行模式 把用户信息和订单信息一起查了，接着让一个分析 Agent 判断问题类型，最后用 LLM 路由 把任务分发到退款、换货、补发这几个处理 Agent。整条链子靠 顺序模式 串起来。

ParallelAgent + ReactAgent + LlmRoutingAgent + SequentialAgent 这么一组合，就是企业级 Multi-Agent 常见的模样。

五、进阶：业界主流的 Multi-Agent 拓扑

除了 Spring AI Alibaba 的四大模式，LangGraph 这类框架还总结了三种通用拓扑。面试时顺嘴提一句，能体现你看过的东西不少：

• Network 模式（网状）：每个 Agent 都能调其他任意 Agent，最灵活，也最容易失控
• Supervisor 模式（主管）：中央调度器统一分发任务，最常用的形态
• Hierarchical 模式（层级）：监督者上面还有监督者，适合超大规模的 Agent 编排

真到了生产环境，Supervisor 模式是大多数团队的最终选择，灵活性和可控性都兼顾到了。

Java 这边，LangChain4j 也搞了个 langchain4j-agentic 模块来编排多 Agent，声明式、编程式两种写法都支持。配上 Spring State Machine 或者 Quarkus Messaging，能玩出更复杂的协同花样。

六、生产环境的真实建议

架构聊完了，再说点实战里的坑。这块面试官特别爱听：

1. 不要为了 Multi 而 Multi：很多团队上来就搞 Multi-Agent，结果发现 Single-Agent + 好的工具组合就够了。先 Single，遇到瓶颈再升级
2. 状态管理是难点：多 Agent 之间的状态共享（OverAllState）、上下文隔离、并发安全，是真正耗费精力的地方
3. 成本会翻倍：Multi-Agent 每个环节都调用 LLM，Token 消耗是 Single-Agent 的数倍，要做好成本预算
4. 可观测性必须跟上：哪个 Agent 出错了、为什么路由到了错误的 Agent、耗时分布怎样，没有链路追踪根本调不出来
5. 分布式部署：企业级场景下，Spring AI Alibaba + Nacos 提供了分布式 Multi-Agent 方案，Agent 可以部署在不同节点

面试高频追问

1. Multi-Agent 之间怎么通信和共享数据？

   靠共享状态（比如 Spring AI Alibaba 的 OverAllState）加占位符传值（{outputKey}）。每个 Agent 把输出塞进状态，后面的 Agent 拿占位符去取。生产环境里还得考虑状态持久化和分布式同步的问题。

2. Single-Agent + MCP 能替代 Multi-Agent 吗？

   大多数场景可以。MCP 厉害就厉害在 不用动架构：Agent 根本不用管 MCP 背后接的是另一个 Agent 还是普通函数。可一旦碰到要并行、要多角色深度协作的活儿，Multi-Agent 还是更对路。

3. Multi-Agent 如何保证稳定性？

   几个关键手段：description 写明确让路由别走偏、加个审核 Agent 来反思纠错、设个最大循环次数防死循环、再引入人工接管（Human-in-the-loop）兜个底。

4. Multi-Agent 的成本怎么控制？

   小模型干路由、分析这种轻活，大模型留给核心生成；中间结果该缓存就缓存，别重复调；再按任务重要性分级挑模型。

常见面试变体

• "什么时候该用 Multi-Agent？什么时候用 Single-Agent 就够了？"
• "Multi-Agent 有哪些协同模式？分别适合什么场景？"
• "Multi-Agent 的状态怎么管理？Agent 之间怎么通信？"
• "你在项目中用过 Multi-Agent 吗？踩过哪些坑？"

记忆口诀

单 Agent 单兵全能，多 Agent 团队分工。四大模式记住就行：顺序走流水线、并行提速度、路由做分流、监督者管全程。选型原则一句话：先单后多，撞了瓶颈再升级。

总结

Multi-Agent 说到底，就是 靠分工协作打破单 Agent 的能力天花板。面试按三个层次答就行：先把 Single 和 Multi 的区别讲透，再展开四大协同模式（顺序、并行、路由、监督者），最后落到选型和生产经验上。要是能说出 "先 Single + MCP，撞了瓶颈再上 Multi" 这种实在话，高分基本稳了。