面试题 · Agent
搜索「RAG 架构」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请解释多智能体系统的基本概念，并分析在大模型背景下，多个LLM Agent协同工作相较于单一Agent的优势以及带来的新挑战。
多智能体系统（Multi-Agent System, MAS）是由多个自治、交互的智能体组成的分布式系统，核心特征：
| 维度 | 单Agent | 多Agent协作 |
|---|---|---|
| 任务处理能力 | 串行处理，上下文易爆炸 |
按学习路线查看教程、项目和面试题。
| 并行分解，子Agent专注子任务 |
| 专业化程度 | 通用但浅 | 角色定制（规划者/执行者/验证者），深度专业化 |
| 系统韧性 | 单点故障 | 某Agent失效可动态重分配 |
| 涌现能力 | 无 | 群体智能，创意组合（如辩论、模拟） |
LLM特性加持：自然语言成为通用通信协议，降低异构Agent集成成本；推理能力支持复杂协商（如CrewAI、AutoGen框架）。
1. 通信与协调开销
2. 一致性与冲突消解
3. 调试与可观测性
4. 上下文碎片化
建议系统学习该知识点
场景切入
假设你在做一套智能客服系统，现在要处理一个复杂退换货流程：需要客服先查订单、质检审核、仓库确认，最后财务退款。如果只用一个LLM来串，上下文很容易乱。你会不会想到拆成几个专门的小助手来协作？能不能具体说说这种多智能体系统是怎么回事？
层层追问
单个LLM Agent处理任务时有什么局限？……那如果我把一个复杂任务拆给多个Agent并行做，你觉得能带来什么好处？……但这样协作也会引入新问题，比如多个Agent之间怎么沟通、意见不一致怎么办？
直球架构
直接解释一下多智能体系统的基本概念，重点分析在大模型背景下，多个LLM Agent协作相比单个Agent有哪些优势？同时又会带来哪些新挑战？
这道题其实是在问，当你有多个LLM [[Agent]]一起干活的时候，跟只用一个大模型单打独斗相比，到底好在哪、难在哪。我先说基本概念。[[多智能体]]系统，说白了就是一群能自己拿主意、互相能说话聊天的智能体凑在一起干活。每个Agent独立决策，没有中央指挥官，但它们通过通信和协商分工，一起搞定一个Agent搞不定的复杂任务。
那在大模型背景下，为什么大家开始搞多个Agent协作呢？核心优势我觉得就三个。先看并行分解。单Agent处理复杂任务，要么串行一步步来，要么上下文越塞越满，容易爆。多Agent可以把大任务拆成子任务，比如一个Agent专门做规划，一个做执行，一个做验证，各干各的，效率高很多。再看深度专业化。单Agent再强也是通才，但多Agent可以给每个Agent定制角色，比如一个Agent只负责调用工具，另一个只负责记忆检索，这样每个Agent在自己那摊事上可以做到很精。还要看系统韧性。单Agent挂了就全挂了，多Agent里某个Agent出问题，任务可以动态重分配给别的Agent，系统不会完全瘫掉。
举个例子，像企业客服场景。传统做法是用一个[[RAG]]加一个LLM，用户问退款政策，模型去查知识库然后回复。但遇到复杂问题，比如订单异常同时涉及库存和价格，单Agent要么答不全要么上下文爆炸。多Agent怎么做？我见过一个架构：一个主管Agent先理解用户意图，然后派一个订单Agent查订单状态，一个库存Agent查库存，一个价格Agent查价格，最后汇总给回复Agent生成答案。每个Agent只专注自己那摊事，配合自然语言通信，整个流程清晰可控。
但落地的时候，挑战也很明显。首个坑是通信开销。Agent之间每说一句话都要调一次LLM，延迟和成本蹭蹭涨。所以实际落地得设计层级架构，比如Manager-Worker模式，主管Agent只跟几个Worker通信，Worker之间不直接对话，减少调用次数。再看一致性问题。每个Agent基于自己的上下文做决策，可能互相矛盾。比如订单Agent说已发货，库存Agent说缺货，这时候就要引入仲裁Agent或者投票机制来做冲突消解。最后是调试难。多Agent的调用链很长，出了问题不知道是规划错了还是执行错了。我上线前一定会做完整的日志追踪，把每个Agent的输入输出都记录下来，方便回溯。
还有一个容易被忽略的点，就是上下文碎片化。多个Agent对话历史加起来很容易超出上下文窗口，所以得设计摘要机制或者共享外部记忆。这个其实跟 [[GraphRAG]] 的思路有点像，通过图结构来管理多Agent的交互历史，避免信息丢失。
所以总的来说，我倾向于把多Agent看成一种架构模式，不是银弹。它特别适合任务可以自然拆解、各子任务需要不同专业能力的场景，比如客服、代码生成、游戏AI。但如果任务本身很简单，或者对延迟极度敏感，单Agent加 [[ReAct]] 反而更靠谱。我的取舍是：先看业务能不能拆，再看团队有没有能力做调试和监控，否则多Agent带来的复杂度可能比收益还大。