“你负责的项目里，为什么要把任务拆给多个 Agent 来做？当时是怎么设计的？”
这是我在面试一家做 AI 应用的公司时，被面试官追问的第一个问题。我当时把项目里的多 Agent 协作流程复述了一遍，面试官点了点头，又补了一句：“如果换一种场景，你会用哪种架构？”
那一刻我才意识到，面试官真正想听的，不是“我用了什么”，而是“我为什么这么选”。多 Agent 系统的方案设计，本质上是一次系统设计考察：任务怎么拆、角色怎么分、消息怎么传、失败怎么处理、成本怎么控。如果你只背过一份架构图，很容易在追问环节露馅。
这篇文章我想从面试答题的角度，把多 Agent 系统中出现频率最高的 4 种经典架构完整拆一遍：每种架构的核心思路、适用场景、优缺点，以及面试时怎么说才显得“有系统设计功底”。不管你是准备面试，还是自己正在搭多 Agent 项目，应该都能用得上。
1. 面试官问多 Agent，考的不是架构图，是系统设计思维
先聊一个很多人忽略的问题：为什么面试官偏爱问多 Agent 系统？
因为多 Agent 系统不只是一个技术名词，它天然覆盖了一道系统设计题的所有环节。面试官可以从一个 Agent 的内部设计问到多个 Agent 之间如何协作，从任务拆分问到结果合并，从串行执行问到并行调度，甚至从 token 成本问到故障恢复。这不就是一个微服务架构的 LLM 版本吗？所以这个问题非常能考察候选人的全局设计能力。
我在准备过程中，把面试官的考察点归纳成三个维度：
1.1 第一问：你真的需要多 Agent 吗？
很多人一上来就说“用多 Agent 更智能”，这是最大的扣分点。面试官心里多半在等你说一句：“其实很多场景根本不需要多 Agent。” 单 Agent 就能解决的问题，强行拆成多 Agent，只会带来更高的延迟、更贵的 token、更多的失败点。
什么场景才真正需要多 Agent？
- 任务本身有明确的子任务边界，比如“先做需求分析，再写代码，再跑测试”，每个阶段需要不同的工具和知识。
- 子任务之间存在并行关系，比如同时搜索三个方向的资料再汇总。
- 单个 Agent 的能力边界不够，比如一个 Agent 既要懂代码又要懂运维又要懂产品，提示词会被撑爆。
- 需要对过程做可观测、可干预的控制，比如某些子任务需要人工审核。
面试时把这个判断讲清楚，你已经在起跑线上领先了。
1.2 第二问：多 Agent 之间的“关系”是什么？
多 Agent 系统的本质是划分子任务 + 定义协作关系。这个关系可以是一对多、多对多、父子、平级、串行、并行、动态协商……每种关系都对应一种架构。
面试官考察的就是你能不能根据任务的依赖关系选择正确的协作拓扑。所以你需要掌握的不是“4 个架构名词”，而是“4 种任务协作模式”。弄懂这一点，后面讲什么架构都通了。
1.3 第三问：系统的稳定性、成本、可观测性如何保障？
多 Agent 系统最难的不是跑通 Demo，而是让它稳定地跑在生产环境。Agent 的输出天然带有不确定性，多个 Agent 之间的不确定性会被累积放大。面试官会追问：
- Agent 之间怎么通信？共享上下文还是消息传递？
- 任务失败怎么办？重试还是降级？谁来负责兜底？
- 多 Agent 的 token 成本怎么控制？
- 系统的一整条执行链路怎么追踪？
这些问题没有标准答案，但你必须有一套完整的回答思路。带着这三个考察维度去准备，会比死记硬背架构定义有效得多。
2. 架构一：Supervisor-Worker，最稳妥的“领导拍板”模式
第一个要讲的架构，也是我实际项目里用得最多的架构，叫Supervisor-Worker（主管-工人）模式。你可以直接把它理解为职场里的“一个 Leader 带一群执行者”。
Supervisor 是唯一的决策中心，负责理解用户请求、拆解任务、给 Worker 分派任务、收集结果、决定是否重试或结束。Worker 不自己做决策，只负责执行被分配的子任务，把结果交回给 Supervisor。
2.1 这个架构的核心工作机制
用伪代码表达一下核心逻辑：
# 伪代码，展示 Supervisor-Worker 的核心循环 def run_supervisor(user_request): supervisor = create_agent("Supervisor") tasks = supervisor.plan(user_request) # 任务拆解 results = [] for task in tasks: worker = create_agent(task.role) # 可以并行，也可以串行 result = worker.execute(task) results.append(result) supervisor.collect(task, result) # 汇报阶段 final_answer = supervisor.aggregate(results) return final_answer关键点在于：所有的控制流都收拢在 Supervisor 里。Worker 不需要知道全局任务是什么，只需要知道自己当前这一步要干什么。这样做的好处非常明显：
- 下一跳可控：Supervisor 可以根据前一个 Worker 的输出动态决定下一步派什么任务，而不是提前定死整个流程。
- 失败处理集中：某个 Worker 超时或出错，Supervisor 可以自己决定重试、换 Agent、或换一种任务描述。
- 上下文可控：每个 Worker 只接收它需要的最小上下文，不会被整个对话历史污染。
2.2 面试时怎么把这个架构讲出彩
我建议按“机制 -> 场景 -> 取舍”三步讲。
先说机制：Supervisor 是控制中心，Worker 是执行单元，控制流和数据流分离。
再说场景：适合“任务边界清晰、需要动态规划”的场景。比如某跨境电商客服系统，用户说“帮我查一下订单并申请退款”，Supervisor 规划出“查订单 -> 校验退款资格 -> 生成退款申请”三个任务，分别交给三个 Worker，每一步都依赖上一步的结果。
这里最容易出彩的是讲取舍。不要只说“这个架构很稳定”，要主动说出它的代价：
- 单点瓶颈：Supervisor 要做所有决策，是整个系统的性能和可靠性瓶颈。一旦它输出错误，整个链条都会歪。
- 上下文逐层传回的放大效应：每个 Worker 的结果都要交给 Supervisor 再加工，会导致最终汇总时需要处理的信息量很大，token 消耗呈线性甚至指数增长。
- 决策质量受限于 Supervisor 本身的能力：本质上 Supervisor 也是一个人工智能模型，规划能力能到 80 分，整个系统就到不了 85 分。
你可以说：“所以我在实际落地时，会对 Supervisor 的规划结果做一次结构化校验，比如要求它输出 JSON 格式的 task list，不符合格式就重试一次。”这种细节非常加分。
2.3 一个小提醒：Supervisor 不等于“只会串行派活”
很多人误以为 Supervisor-Worker 就一定是串行执行。其实 Supervisor 完全可以并行调度多个 Worker——它把任务拆成互不依赖的两份，同时交给两个 Worker 执行，等两边结果都回来再汇总。这也是多 Agent 相对单 Agent 最大的优势之一。
我在设计一个多源资料调研 Agent时就这么干过：Supervisor 把“查行业报告”“查用户评价”“查竞品动态”三个任务并行派给三个 Worker，极大地缩短了整体耗时。面试时提到这个细节，能让面试官看到你真正理解了这个架构的调度潜力。
3. 架构二：Hierarchical，把大问题拆成树的层层分包
第二种是Hierarchical（层级式）架构。你可以把它理解为 Supervisors 一层套一层：顶层 Supervisor 拆出几个子任务，每个子任务又由一个中层 Supervisor 继续拆，再往下分配给更具体的 Worker。整张图是一棵任务树，控制流从根节点往叶子节点流动，结果从叶子节点一层层往上汇总。
3.1 为什么需要这种“二次拆解”？
因为当任务规模变大之后，一个 Supervisor 管太多 Worker 会很快失控。我见过最典型的问题是：顶部只有一个 Supervisor，直接面对 20 个 Worker，它要在同一轮决策里协调十几个子任务，输出质量明显下降，而且每轮决策要读回的上下文越来越多，很快就把上下文窗口撑爆。
Hierarchical 架构解决的就是这个“管理幅度”问题。顶层主管只面向 3 到 5 个中层主管，中层主管只面向自己的 3 到 5 个执行者，每层的上下文压力都被控制住了。
用伪代码表达：
class AgentNode: def __init__(self, role, subtasks=None): self.role = role # "顶层主管" / "中层主管" / "执行者" self.subtasks = subtasks # 子节点可选 def execute(self, objective, context): if not self.subtasks: return run_llm_with_tools(self.role, objective, context) sub_results = [] for st in self.subtasks: result = st.execute(objective, context) sub_results.append(result) return aggregate_and_report(self.role, sub_results)3.2 什么场景下你会用到层级式？
当任务本身是多层嵌套结构时，Hierarchical 模式几乎是自然映射。举个例子，我要做一个企业年度经营分析报告 Agent：
- 顶层 Supervisor 拆成“财务分析”“市场分析”“组织效能分析”三个子任务。
- 财务分析这个子任务下面，再由中层 Supervisor 拆成“收入结构分析”“成本结构分析”“现金流分析”三个叶子任务。
- 每个叶子任务再调用对应的数据查询工具或 Expert Agent 完成执行。
每一层只处理自己视野内的信息，不会一上来就把全公司的数据全部塞给一个 Agent。
再比如代码仓库重构 Agent：顶层拆成“前端代码分析”“后端代码分析”“数据库迁移评估”；后端分析再拆成“接口梳理”“服务拆分”“依赖分析”；接口梳理还可以继续往叶子节点拆。树有多深，任务就有多细。
3.3 面试回答的加分点：讲清“深度由什么决定”
面试官大概率会追问：“层级拆到多深合适？”
这里我有一个很实用的回答框架：
- 决定拆分深度的关键，是单层任务之间的耦合度和单个节点的上下文需求。如果叶子任务只需要很少的上下文就能执行，说明它已经足够独立，不用继续拆。
- 如果拆到某个层级后，子任务之间频繁需要交叉核对数据，说明拆得太细了。数据依赖比任务个数更能反映拆分粒度。我一般用一句话判断：每个叶子 Agent 接收到的上下文，应该不超过它完成本步任务所需信息量的 1.2 倍。
- 控制每层节点数在 3 到 5 个，可以降低上一层的规划压力。
这些话一出口，面试官基本就能确认你不是只背过概念，而是真做过深度设计。
3.4 层级式架构的代价
要说代价，最大的就是延迟和成本。一个任务从根节点一路执行到叶子节点，再一路返回，中间要经过多轮 LLM 调用，每一次调用都要花钱花时间。如果某一条分支失败，重试还会倍增成本。
另一个坑是，层级多了之后，底层信息在逐层汇总过程中很容易被浓缩丢失。叶子节点执行完成后返回的如果只是一个结论摘要，上层主管就看不到过程细节，一旦结论有误，排查链路会非常痛苦。我的对策是：让每个节点的返回结果带上“结构化日志”，包括执行过程、关键中间结果、置信度评分，而不只是最终答案。
4. 架构三：Collaborative-Debate，让 Agent 互相挑错
第三种架构和前两种完全不同，它不再强调“上下级”，而是让多个 Agent平级协作，互相挑战、互相审查。这就是Collaborative-Debate（协作-辩论）模式。
你想象一个场景：三个专家围着一张桌子，对同一个问题给出各自的答案，然后互相质疑，最后达成共识或给出多数意见。多 Agent 系统也可以这样做——多个 Agent 扮演不同视角的角色，通过多轮辩论逼近更高质量的回答。
4.1 这个架构的核心机制：多视角对抗
在 Collaborative-Debate 里，每个 Agent 都有自己独立的视角、知识侧重点和“人设”。比如做一个内容审核 Agent 集群：
- Agent A 负责从“事实准确性”角度审查。
- Agent B 负责从“安全合规”角度审查。
- Agent C 负责从“技术深度”角度审查。
它们分别阅读同一篇文章，输出自己的意见。然后进入辩论环节：每个 Agent 能看到另外两个 Agent 的审查意见，再给出自己的反驳、补充或让步。几轮之后，由一个汇总器（或者让三个 Agent 投票）产出最终结论。
这个模式很契合一个场景：答案质量要求高，没有唯一标准答案，且需要多角度校验。典型如：
- 复杂逻辑推理题验证。
- 医疗/法律等领域的知识问答（强调多方交叉验证）。
- 代码走查：一个 Agent 写代码，另一个 Agent 负责找 bug。
- 内容安全审核：不同 Agent 负责不同维度的风险识别。
4.2 你不需要让 Agent 真的“吵起来”
很多文章会把这种模式描述成“让 AI 互相吵架”，但在实际落地时，你完全不需要真让它们自由对话。更可控的做法是结构化辩论：
# 结构化辩论轮次示意 def debate(rounds, context, agents): opinions = [agent.initial_analysis(context) for agent in agents] for r in range(rounds): for i, agent in enumerate(agents): others = [op for j, op in enumerate(opinions) if j != i] opinions[i] = agent.review(opinions[i], others, round_num=r) return final_vote(opinions)每一轮，Agent 都会拿到其他人的观点摘要，然后输出：自己是否坚持原判断、如果调整则说明原因、对别人的哪个观点最不认同。你可以限制每一轮输出长度（比如 200 token 内），防止出现毫无意义的车轱辘话。
4.3 面试怎么讲这个架构的取舍
这个架构最大的优势是能显著降低单模型盲区导致的错误率。尤其是当任务涉及“生成之后要自我评审”的情况，单 Agent 自我纠错经常失灵——因为同一个模型用同样的思维模式，很难发现自己的漏洞。多 Agent 用不同角色视角去审，效果会好很多。
但它也有非常明显的代价，你面试时一定要主动提：
- 成本高：N 个 Agent × M 轮辩论，每一轮都是完整 LLM 调用。成本呈倍数膨胀。
- 共识可能不收敛：如果几个 Agent 各执一词、互不退让，系统可能在所有轮次结束后仍无法达成一致。你必须设计一个最终的投票或裁决机制。
- 角色设计难度大：如果几个 Agent 的角色区分度不够高，辩论效果趋近于同一个模型自我重复，基本没有增益。
我自己的经验是，辩论轮数控制在 2 到 3 轮就已经足够，再多轮边际收益急剧下降，而成本线性上升。
4.4 一个细节：什么时候用“投票”，什么时候用“裁判”
有一种变体会用一个独立的Judge Agent来听取各方辩论并输出最终结论，而不是让参与者自己投票。我在实际项目中通常这么选：
- 如果参与辩论的 Agent 角色相对客观，比如“事实核查类”，投票就够用。
- 如果参与辩论的角色本身有立场偏移，比如“市场增长看好方 vs 保守方”，一定要用独立 Judge 做裁决，否则结果会被某一方的论证气势带偏。
这个细节很小，但面试时讲出来很能体现设计的完整性。
5. 架构四：Pipeline，一条生产线上干到底
第四种架构叫Pipeline（流水线）模式。和多 Agent 的“商量着来”不同，Pipeline 强调任务顺序执行，前一个 Agent 的输出直接作为后一个 Agent 的输入，像工厂里的流水线一样，每一站只干一件事。
如果你处理的任务有明确的先后依赖关系，而且中间不需要回流和协商，那 Pipeline 就是最简单高效的架构。
5.1 Pipeline 模式的经典结构
一个非常典型的三级流水线：
# 代码生成流水线示意 code = code_gen_agent(requirement_text) review_report = code_review_agent(code, requirement_text) fixed_code = code_fix_agent(code, review_report)每一步都是单向传递，没有回环。这在“规范化、流程化”的任务里特别好用。比如：
- 新闻稿件生产流水线：选题 Agent -> 信息采集 Agent -> 初稿撰写 Agent -> 编辑润色 Agent -> 标题提炼 Agent -> 排版校对 Agent。
- 数据处理流水线：数据清洗 Agent -> 特征提取 Agent -> 分析报告生成 Agent -> 可视化 Agent。
- 客服工单处理流水线：意图识别 Agent -> 信息核对 Agent -> 解决方案生成 Agent -> 人工复核辅助 Agent。
Pipeline 的要点是：每一步的输入输出协议必须定义得非常干净。前一步给后一步的是结构化数据还是自由文本，决定了整条流水线的稳定性。
5.2 Pipeline 和 Supervisor-Worker 有什么区别？
这是面试中最容易混淆的两组概念，我专门对比一下：
- Supervisor-Worker 的控制流在 Supervisor 手里。Supervisor 可以看完第一步结果后再决定下一步做什么，任务序列是动态生成的。
- Pipeline 一旦启动，每一步做什么、谁执行、按什么顺序，都是提前定义好的静态流程，没有中央决策者。
用大白话说：Supervisor 模式像一个项目经理，当天看情况给下面派活；Pipeline 模式像一条传送带，零件放上去就按固定顺序加工到底。
所以面试你要记住：如果任务的执行路径固定，写死流程的 Pipeline 更稳定；如果任务的执行路径不确定，需要根据中间结果动态调整，Supervisor 模式更合适。
5.3 Pipeline 模式下隐藏的巨型难点：错误如何回滚
很多人觉得 Pipeline 最简单，没什么好聊的，但实际上它有个非常难处理的问题：错误会在流水线里向后传导。
假设第一站的 Agent 输出了一份有严重缺陷的中间结果，第二站、第三站的 Agent 不会察觉，它们只会拿这个错误结果继续加工，最终生成一份“看起来很完整但根上是错的”结果。单 Agent 或多 Agent 动态调度至少还有机会在中间发现问题，Pipeline 每个节点都默认“上游是对的”，所以污染会一路蔓延下去。
我处理这个问题的方案是：
- 在关键节点之间加一个质量闸门（Quality Gate），比如用一个校验 Agent 或一套规则，对中间产物做格式、完整性、合规性检查，不通过就触发重跑或回退。
- 给每个节点限定输出字段的结构化格式，让非法输出更容易被机器自动发现。
- 对流水线的每个中间产物都做版本快照，一旦最终输出有问题，可以定位到具体是哪一站的哪个版本出了问题。
这些内容面试时说出来，会显得你对 Pipeline 的理解远超“按顺序调几个 Agent”。
6. 四种架构的选型对比与面试答题框架
讲完四种架构，现在用一个更直观的方式对比一下，顺便把选型思路也讲清楚。
| 维度 | Supervisor-Worker | Hierarchical | Collaborative-Debate | Pipeline |
|---|---|---|---|---|
| 核心控制方式 | 中央决策者动态派活 | 多层决策者逐层拆解 | 平级互相审查、对抗 | 静态流程顺序传递 |
| 适用场景 | 任务边界清晰、路径需动态调整 | 任务规模大、可自然分层 | 答案需多视角验证、质量要求高 | 流程固定、前后依赖明确 |
| 并行能力 | 支持多个 Worker 并行 | 支持分支并行 | 多 Agent 同时分析、多轮交互 | 各节点通常串行，可异步解耦 |
| 主要风险 | 单点决策瓶颈 | 层级过深导致信息损耗与成本膨胀 | 成本高、可能不收敛 | 错误单向传导、难以回退 |
| 成本水平 | 中等 | 较高 | 高 | 相对低，但重试可能推高成本 |
6.1 我的选型决策四步法
面试如果遇到“请设计一个多 Agent 系统”的大题，千万不要上来就画架构图。按下面四步走，逻辑会非常清楚：
第一步：画出任务的依赖关系图。用方框和箭头把子任务之间的依赖关系画出来。哪个任务必须在前，哪个可以并行，哪个需要反复校验——这张图决定了后面的所有选择。
第二步：判断控制流是静态还是动态。如果依赖关系基本固定，优先考虑 Pipeline 或分层固定的层级式；如果中间需要不断根据结果调整后续计划，用 Supervisor 模式。
第三步：判断是否需要多视角对抗。如果任务对错误率极其敏感，且存在评审、审查、校验环节，考虑在关键节点加入 Debate 机制，而不是整条流程都用辩论。
第四步：明确兜底和观测方案。无论选哪种架构，都要交代清楚：失败怎么重试，上下文怎么传递，成本怎么控制，链路怎么追踪。这一部分往往是面试官最想听你展开的。
6.2 高频追问的答题模板
这里整理四个我在准备时总结的高频追问和我的应对思路：
追问一：Agent 之间怎么通信？
不要只说“用消息传递”。要补一句：“在 LLM 层面，消息本质上就是结构化文本。我会给每条消息定义统一的 schema，比如{sender, receiver, task_id, content_type, content, timestamp}。同时区分控制消息和数据消息，控制消息走轻量级协议，数据消息可以直接引用上游中间产物的文件路径，避免把大段内容反复塞进上下文。”
追问二：状态和数据放在哪里？
经典回答：“每个 Agent 保持无状态，共享状态放在外部存储（比如内存数据库或向量库）。每个子任务的输入输出都持久化记录，方便断点续跑和审计。” 这其实借鉴了微服务设计的思路，面试官会很受用。
追问三：多 Agent 带来的额外成本如何控制？
“我会做三层控制：第一层是入口控制，能单 Agent 解决的任务绝不启用多 Agent；第二层是执行控制，限制每个 Agent 的 max token 和最大调用次数；第三层是出口控制，设置超时和总成本上限，超过阈值直接降级为单 Agent 兜底。”
追问四：如何评估多 Agent 系统效果？
不要只盯着准确率。要说综合指标：任务完成率、端到端延迟、token 成本、重试率、人工干预率、以及端到端输出质量。可以采用“先小样本人工评估 + 再大样本自动化指标验证”的两阶段评估，避免依赖单一指标。
6.3 一个“先给结论、再展开”的万能开场
如果是开放式的设计题，我的答题开场固定是这样的：
“如果让我设计这个多 Agent 系统，我会先做一个判断：这个任务的依赖关系是偏静态还是偏动态。从目前的需求看，它包含 A、B 两个固定阶段，其中 B 阶段又依赖 A 的多种输出结果，同时 B 本身质量要求很高。所以我会选择 Supervisor-Worker 作为整体骨架，把 A 阶段作为 Worker 并行执行，B 阶段引入一个审查 Agent 形成小范围 Debate。整体成本预估在每任务 XX 元左右，后续可以用淘汰机制验证效果。”
先给架构，再给理由，再给成本和验证方案。这个顺序本身就体现了系统设计思维。
7. 实战踩坑记录：状态、成本、死锁与评估
最后分享几个我在自己搭多 Agent 项目时真实踩过的坑。这些不一定写在教科书里，但遇到的时候真的很要命。
7.1 上下文污染问题，比预想中严重
早期我做过一个多 Agent 内容分析系统，为了让每个 Agent 都“理解全局”，我把对话历史直接传给所有 Agent。结果项目上线后发现：上游 Agent 随口提的一句“用户好像不太满意”，传到下游后竟然被当成事实引用进了最终报告。
后来我规定：Agent 之间的上下文传递必须经过两次过滤，第一次是结构化摘取，第二次是相关性校验。每个 Agent 只接收当前任务必须的信息，其余信息一律不外传。系统的准确性一下子就上来了。
7.2 “死锁”真的会发生，不要笑
多 Agent 系统里有一种类似死锁的状态：两个 Agent 互相等待对方先给结论，又没有哪个 Agent 有权限主动推进，整个任务就卡住了。尤其是你用 Collaboration 模式时，A 说“还需要 B 的确认”，B 说“必须等 A 给出最终方案”，两边谁都不让步。
我的解决办法是：任何多 Agent 系统都要有一个总超时机制，到时间后由固定的一方仲裁或降级。不要相信 Agent 自己能协商出结果，你就当它们是一群初级工程师，必须有人拍板。
7.3 token 成本失控，算账要提前
我曾经做过一个带辩论机制的 Agent 系统，原本心里预计每轮辩论消耗 5000 token，结果上线后发现实际每轮要 8000 多 token。因为 Agent 会在复述对方观点时把整段原文都带上，导致一轮辩论的信息放大好几倍。
后来我在系统里加了两个约束：一是要求 Agent 在引用他人观点时只能引用编号，二是限制每轮辩论输出不超过 150 字。成本立刻降回预期范围。多 Agent 系统的成本不是靠预估出来的，是靠结构约束出来的。
7.4 评估链路不能只看“最终答案”
多 Agent 系统的另一个隐蔽坑是：最终答案对了，但你根本不知道是哪个环节起的作用，出了问题也没法定位。我给这类系统做评估时，会同时记录三个层面的数据：每个 Agent 的独立输出、Agent 之间传递的中间消息、最终汇总结果。
线下抽测时，如果最终结果错误，我会溯源到具体是哪一层出了问题。如果是某个 Worker 的信息有误，我会回头修它的提示词；如果是汇总层把信息浓缩坏了，我会调整汇总策略。没有中间过程记录的多 Agent 系统，出了问题就是黑盒，只能推倒重来。
7.5 一点个人体会
如果你正在准备面试，我最想跟你说的是：不要只背架构图，一定要亲自动手搭一个小 Demo，哪怕只是用现成框架跑通一个最简单的主管-工人流程。因为在跑通的过程中，你会自己发现上下文怎么传、超时怎么设、结果怎么汇总、失败怎么兜底——这些真实体验才是面试时最宝贵的谈资。
多 Agent 系统的本质，不是“Agent 很多”，而是“解决一个复杂问题的组织方式”。把组织逻辑讲清楚，你的答案就已经超过大多数背稿选手了。
