多 Agent 系统是什么？什么时候需要多个 Agent 协作？
这道题考的是你对 LLM 应用架构的理解深度。核心就两件事：多 Agent 系统长什么样，以及什么时候该用它。
多 Agent 系统是什么
简单说，多 Agent 系统就是多个独立的 Agent 联手干活。
每个 Agent 有自己专属的 System Prompt（决定它扮演什么角色）、自己的工具集、自己的记忆系统。它们不是简单的函数调用，而是像真实员工一样，有自己的职责边界和决策空间。
Agent 之间怎么配合？靠消息传递。一个 Agent 把结果发给下一个，下一个处理完再继续传递，像接力赛一样把任务完成。
用一个你熟悉的场景来理解：软件开发团队。有产品经理分析需求、有架构师做技术设计、有程序员写代码、有测试工程师验证质量。每个人各司其职，通过文档、会议、代码审查来传递信息。多 Agent 系统就是这个逻辑——每个 Agent 扮演一个专业角色，通过消息机制协作。
单 Agent 为什么会不够用
先别急着上多 Agent，先看看单 Agent 有什么问题。
第一个瓶颈：角色冲突。
你让一个 Agent 同时扮演"专业客服"和"销售推荐员"，它的 System Prompt 就会打架。客服要耐心倾听，销售要主动推销，这两个行为模式放在一起，模型会纠结，输出质量下降。
第二个瓶颈：上下文窗口限制。
一个 Agent 要处理所有任务的上下文，prompt 越来越长，模型处理的信息量越来越大。到最后，重要的上下文被淹没在海量信息里，模型开始"失忆"或者"糊涂"。
第三个瓶颈：串行执行。
所有任务排队一个个处理，A 任务没完成，B 任务就得等着。效率低下，响应时间长。
就像一个人同时扮演全栈工程师的所有角色——需求分析、技术设计、前端开发、后端开发、测试、运维。听起来能行，实际上精力分散、错误频出、进度缓慢。
多 Agent 协作的核心优势与四种模式
核心优势
多 Agent 解决的就是上面那三个问题：
专业分工降低认知负荷。每个 Agent 只专注一件事，System Prompt 简单清晰，模型知道自己在干什么。
上下文隔离。专业任务只看自己相关的信息，不会被无关上下文干扰。
并行执行。独立的子任务同时跑，效率翻倍提升。
交叉检验。一个 Agent 的输出可以交给另一个 Agent 验证，像质检员检查产品质量。
四种协作模式
多 Agent 不是一种固定模式，它有几种常见的协作形态：
中心化模式（Supervisor）。一个主 Agent 当"包工头"，负责调度和分配任务，子 Agent 各司其职。主 Agent 像项目经理，子 Agent 像执行团队。
对话/辩论模式（Debate）。多个 Agent 对同一个问题各抒己见，互相反驳，最终通过讨论得出更好的答案。适合需要多角度思考的复杂问题。
流水线模式（Sequential）。任务按固定顺序流经各个 Agent，像工厂流水线。A 的输出是 B 的输入，B 的输出是 C 的输入。适合有明确步骤的工作流。
层级模式（Hierarchical）。多层 Agent 形成树状结构，上层 Agent 负责任务分解，下层 Agent 负责具体执行。适合大规模复杂任务。
什么时候需要多 Agent（选型决策）
多 Agent 不是银弹，别一上来就搞一堆 Agent。
适合用多 Agent 的场景：
任务需要多种专业技能。比如一个新闻分析系统，需要搜索 Agent 抓取信息、阅读 Agent 提炼要点、评论 Agent 写出观点。
任务需要多角度验证。比如代码生成后需要审查 Agent 检查安全性、需要测试 Agent 验证功能性。
任务规模大，需要层级分解。大型报告生成，需要主 Agent 规划结构、子 Agent 负责各章节、汇总 Agent 整合输出。
慎用多 Agent 的场景：
简单问答、单一工具调用、或者原型验证阶段。单 Agent 就够用的时候，别给自己找麻烦。
框架怎么选：
CrewAI 适合快速原型，多 Agent 协作模式清晰，上手简单。
AutoGen 擅长多 Agent 对话和辩论场景，支持复杂的 Agent 间交互。
LangGraph 适合需要管理复杂状态和条件分支的工作流，灵活性最高。
选型没有绝对标准，关键看你的场景复杂度、团队技术栈、学习成本这几个因素。
面试怎么答
基础版
多 Agent 系统是由多个独立 Agent 组成的架构，每个 Agent 有自己的角色定义、工具集和记忆，通过消息传递协作。单 Agent 存在三大瓶颈：角色冲突、上下文限制、串行执行。多 Agent 通过专业分工解决这些问题，具备四大优势：降低认知负荷、上下文隔离、并行执行、交叉检验。常见的协作模式有四种：中心化、辩论、流水线、层级模式。
加分版
在基础版基础上，加上选型判断和框架认知。不是说多 Agent 就一定好，简单任务用单 Agent 足够了。选型时要看任务复杂度、是否需要多技能协同、是否需要交叉验证。框架方面，CrewAI 适合快速上手，AutoGen 擅长多 Agent 讨论，LangGraph 适合复杂状态管理。另外也要意识到多 Agent 的代价——调试复杂性增加、系统开销增大，不是所有场景都值得引入。
一句话总结
多 Agent 系统通过专业分工和协作机制解决单 Agent 的瓶颈问题，但要用对场景，别把简单问题复杂化。