核心要点
多 Agent 的核心是把复杂任务拆给不同角色协作：常见模式有主管-工人、流水线、辩论评审和黑板协作。
协作协议比角色名字更重要：要定义消息格式、共享状态、交接物和终止条件。
多 Agent 不一定更好：它会增加通信成本、延迟、冲突和调试难度。
工程上必须处理失败和收敛：超时、重复讨论、结果冲突、责任边界不清都会让系统失控。
简要回答
Manager 分派子任务给 Worker；Debate 多 Agent 讨论达成共识；Pipeline 按阶段传递；关键在角色定义、消息协议和共享状态设计。
标准回答
一、先说明常见协作模式
多 Agent 系统不是“多开几个模型”这么简单，而是让不同角色围绕同一个目标协作。常见模式有：Manager-Worker，主管拆任务、工人执行、主管汇总；Pipeline，检索、分析、写作、评审按阶段交接；Debate / Critic，多个 Agent 提方案再互相批评；Blackboard，多个 Agent 读写共享状态，共同推进任务。
二、讲清系统设计上的关键点
候选人要主动说通信和状态：Agent 之间传什么消息、消息是否结构化、共享状态放哪里、谁有最终决策权、冲突怎么解决、什么时候停止。比如写作系统里，Research Agent 输出来源池，PM Agent 选题和约束，Writer 产出正文，Critic 找事实和结构问题，QA 决定能否发布。这比只说“一个负责搜索，一个负责写作”更像真实系统设计。
三、补上适用场景和反例
多 Agent 适合任务复杂、可拆分、需要多角色互审或可并行的场景；不适合简单问答和强实时低成本场景。工程上要限制最大轮次、超时、预算、共享状态写权限和人工 checkpoint，否则多个 Agent 会互相等待、重复争论或把错误放大。
常见误区
⚠️ 常见踩坑
误区一：认为 Agent 越多效果越好。多 Agent 会带来额外 token、延迟、冲突和观测成本，只有任务确实可拆时才值得用。
误区二：只定义角色，不定义交接物。没有结构化消息、共享状态和终止条件，多个 Agent 很容易变成聊天群，而不是可靠工作流。
追问
追问 1：多 Agent 一定比单 Agent 好吗？
不一定。简单任务用单 Agent 更省 token、延迟低，也更容易调试。多 Agent 适合三类场景：任务能自然拆成多个角色；不同阶段可以并行或互审；单 Agent 容易遗漏视角。反过来，如果只是普通问答、短摘要或一次工具调用，多 Agent 只会增加通信开销、协调失败和结果不一致风险。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习