前两天有位朋友去面一个 AI 应用岗回来跟我吐槽“面试官问我什么时候该用 Multi-Agent什么时候一个 Agent Skill 就够了我讲了一堆 Multi-Agent 多好多好结果对方反问一句那你怎么不在所有项目里都用它”这个问题听起来像送分题实际上能问倒一大片人。原因很简单很多人把 Multi-Agent 当成 Agent 的“升级版”觉得多个 Agent 一定比一个 Agent 高级。但工程界恰恰相反用错架构的代价比不用更痛。我亲眼见过团队把一套本来稳定的文档助手从单 Agent 改成“三 Agent 协作”结果延迟翻倍、token 成本暴涨、线上问题变多最后又老老实实改回去。也见过一些确实需要多角色对抗的业务被硬压在一个 Agent 里怎么调 prompt 都达不到效果。这篇文章不打算给你一套“银弹”而是分享一个我在实际项目中反复用过的决策框架先拆任务空间再算成本最后看可靠性。如果你正在准备 AI agent 相关的面试或者正在纠结自己的智能体到底要不要拆成 Multi-Agent这篇内容应该能帮你理清思路。而且我会把面试中怎么说、怎么做取舍也一并购讲清楚。1. 先把概念放平Agent、Skill、Multi-Agent 各是什么1.1 Agent 不是“机器人”是一个“能自己做事的单元”很多同学把 Agent 理解成“有对话框的 AI”这个理解不够准确。Agent 的核心是自主完成一个闭环接收目标、拆解步骤、调用工具、验证结果、根据反馈调整行动。它更像一个“迷你员工”而不是聊天框。举个例子你给它一个目标“帮我把这批销售邮件按客户优先级分类。”它不会只回你一句建议而是会自己决定先读取邮件、提取客户名单、调用评分工具、最后输出一张分类表。整个过程涉及多次大模型推理和工具调用而模型在其中扮演的是“决策中枢”工具和代码才是真正的“手脚”。理解这一点很重要因为很多人在做架构选型时把 Agent 当成“一个 prompt 模板”这是错的。Agent 是一个可以在运行时动态决定“下一步做什么”的单元。这也是它能承载多个 Skill 的基础。1.2 Skill 是 Agent 的“肌肉记忆”Skill 在 Agent 体系里是一个可复用的能力包通常由指令、可执行代码或函数定义、输入输出 Schema、以及验证逻辑组成。一个 Agent 可以挂很多 Skill就像一个人可以会多种技能。我这里给一个常见的 Skill 结构示例方便你理解它到底长什么样{ name: query_order, description: 根据用户ID查询最近订单状态, input_schema: { user_id: string, date_range: string }, output_schema: { order_list: array, total_count: number }, error_handler: retry_on_429 }关键原则是Skill 必须高内聚、低耦合。一个 Skill 只做一件事输入输出必须明确。如果某个 Skill 里塞了“查订单 查物流 发短信”模型在选工具时反而会犹豫到底该调用它还是只调用其中一部分这在实践中会直接影响准确率。1.3 Multi-Agent 是“多个人一起干活”不是多个 Agent 堆在一起Multi-Agent 的定义包含三个要素多个独立 Agent 实例、每个 Agent 有自己的角色和工具边界、它们之间通过消息或共享状态协作。它强调的不是“数量”而是“分工”和“交互”。我见过最大的误解是“只要在一个循环里轮流调用不同 prompt就是 Multi-Agent。”这是错的。比如你先让模型写文案再让模型审文案这只是一个多步流程。真正意义的 Multi-Agent需要每个 Agent 都有自己的记忆和决策空间A 的输出会影响 B 的下一步行动B 的结果也会反过来修正 A 的判断。为了方便对比我把它们的核心差异列在下面对比维度单 Agent 多个 SkillMulti-Agent 多个角色决策主体一个上下文统一多个各自独立决策协作方式状态机/工具调用按顺序切换消息传递、任务分发、结果回传调试难度相对低链路扁平相对高需要看角色间消息流成本推理次数少上下文利用率高额外通信开销token 消耗更高适用场景线性任务、共享上下文、快速迭代角色对抗、并行处理、权限隔离、长链路看完表你应该有直觉了Multi-Agent 不是“更高级”而是“更重”。2. 判断的核心从“任务空间”出发而不是从“流行度”出发2.1 三个问题快速自测遇到不确定的情况我会先问自己三个问题。如果三个答案里有至少两个是否定的那就老老实实用单 Agent Skill。第一个问题存在多个不可合并的角色吗角色不仅是“职责不同”还包括立场、权限、上下文隔离方式。比如“写文案”和“审文案”就是天然对立的两个角色而“查订单”和“查物流”只是两个工具不是两个角色。第二个问题这些角色之间需要中间结果交换和反复学习吗如果 A 的结果只是流水线上传给 B没有反馈回路那就没有多 Agent 的必要。真正的多 Agent 协作中双方会基于对方的输出做进一步决策甚至反驳对方。第三个问题并行或交互带来的收益是否大于协调损耗这里的损耗包括延迟、token 成本、状态不一致概率。我曾经帮一个团队评审项目他们的需求是“让 AI 写一份行业分析报告”方案里设计了“资料员 Agent”“分析师 Agent”“撰写 Agent”。我问了一句这些角色之间有信息对抗吗没有。那就没必要拆一个 Agent 加资料检索和写作两个 Skill 就够了。2.2 成本的账单 Agent Skill 的维护边界我见过很多方案评审只讲收益不讲代价。这里替大家算一笔账。假设一个任务原本用单 Agent 需要调用 3 次模型。拆成三个 Agent 后即使每个 Agent 只调用 2 次总调用次数就变成 6 到 8 次。再加上 Agent 之间的消息传递每一条消息又是一次额外的模型调用或至少一次上下文重写。以现在主流大模型的 token 计价这可不是小数目。更关键的是延迟。用户感知到的响应时间等于所有串行调用之和。如果任务里的 Agent 是链式协作A 做完 B 做B 做完 C 做耗时可能是单 Agent 方案的两到三倍。如果拆完以后又加一个协调者 Agent让它先理解任务再分发给其他人那又是额外一整轮调用。我自己的经验是如果整个链路的内部状态不超过 5 个节点且没有明显的角色对抗需求单 Agent 方案在延迟和费用上几乎一定胜出。别为了采用新技术而制造复杂度。2.3 从架构演进看什么时候会从单 Agent 变成多 Agent你还可以换个角度思考多 Agent 不是一开始就要设计出来的而是从单 Agent 长出来的。我见过一个项目最开始就是单 Agent 挂了 5 个 Skill后来业务扩展接入了好几个不同权限的第三方系统单 Agent 已经无法管理工具权限了才逐步把其中两个 Skill 升级成独立 Agent。这种“演进式架构”是最可靠的做法。你在单 Agent 阶段不建议刻意预留太多的角色抽象因为需求没跑通之前你根本不知道哪些边界是对的。只需要做一件事让 Skill 的输入输出 Schema 足够清晰保证未来把一个 Skill 升级成 Worker Agent 时上层调用方不需要大改。这样既不会过度设计也不会把未来的路堵死。3. 什么时候“一个 Agent Skill”就够三种典型情况3.1 任务线性、状态可控有些任务从头到尾是一条直线输入 → 解析 → 处理 → 输出。比如合同信息抽取读取合同 PDF抽取关键字段输出结构化 JSON。这个流程里所有步骤共享同一个文档上下文中间状态简单清晰用一个 Agent 挂三个 Skill文档解析、字段抽取、校验就能做得很好。硬要拆成“抽取 Agent”和“校验 Agent”反而会出问题合同全文要传两遍token 消耗翻倍两个 Agent 对合同的理解可能不一致校验 Agent 可能把抽取 Agent 的正确结果误判成错误。这就是典型的“多 Agent 制造问题”。3.2 所有步骤共享同一份上下文模型能力的上限很大程度受上下文影响。当你的每一步操作都依赖同一批数据和历史信息时一个 Agent 天然拥有完整记忆不需要做跨 Agent 的信息同步。比如写周报助手需要读取一周的聊天记录、邮件、项目管理平台然后梳理成周报。单 Agent 可以先把所有素材读进上下文再一步步完成汇总、分类、排序、成稿。如果拆成“素材整理 Agent”和“周报撰写 Agent”前者要输出一份中间摘要后者又要重新阅读摘要信息损耗非常严重。这种场景用单 Agent Skill 开发效率高效果也稳定。我做过的另一个例子是法律文书审查最大难点是整套文书前后文要一致条款之间互相引用。如果把“审查 Agent”和“修订 Agent”拆开很可能会出现“审查说你违约修订里却写你没违约”的乌龙。共享上下文在这里就是刚需。3.3 可靠性要求高、需要人 debug还有一个很少被讨论的选型标准可调试性。单 Agent Skill 的链路相对扁平Agent 通过工具调用执行 Skill每个 Skill 都是独立函数出问题可以单步调试。Multi-Agent 一旦出现“A 让 B 去做 CB 又让 A 确认 C”日志就会变成聊天记录排查问题需要像读小说一样往前翻。如果你的业务对准确率要求很高需要频繁灰度、回归测试那一定要从单 Agent 开始。我做过一个财务票据审核 Agent团队要求每一笔异常必须有明确的处理原因。最初设计成“识别 Agent 审核 Agent 出纳 Agent”三个角色测试了一周发现问题极难定位。后来改回单 Agent 多个 Skill在每个 Skill 里加结构化日志错误率反而下降了一个档次。3.4 真实项目一个 FastAPI LangGraph 的单 Agent 文档助手展开说一个我自己的落地案例。技术栈是 FastAPI 做服务LangGraph 做流程编排底层接支持 function calling 的模型。核心功能是上传一个混合格式文档自动抽取客户信息、合同条款和风险点。起初需求方说“让多个 Agent 协作”但我在原型阶段只定义了一个主 Agent挂了三个 Skillresume_document、extract_fields、risk_check。LangGraph 里就是一个 state graphgraph StateGraph(AgentState) graph.add_node(resume, call_skill(resume_document)) graph.add_node(extract, call_skill(extract_fields)) graph.add_node(risk, call_skill(risk_check)) graph.set_entry_point(resume) graph.add_edge(resume, extract) graph.add_edge(extract, risk) graph.add_edge(risk, END)上线后效果出奇地稳因为文档内容全程在一个 state 对象里没有一个环节需要跨 Agent 传消息。这个例子印证了一句话很多所谓的“多角色需求”本质上是“多工具需求”。3.5 需要警惕的“升级信号”单 Agent Skill 当然不是万能的。你在使用过程中要留意几个信号出现了就说明可能要考虑 Multi-Agent同一个 Agent 的工具列表越来越长模型开始频繁选错 Skill上下文被多个互不相干的业务字段塞满互相干扰不同业务方要求不同的权限边界但你无法在一个 Agent 里做 token 级隔离任务链路上开始出现“如果结果不合理需要换一个立场重新推导”的需求。这些信号意味着任务空间可能已经发生了质变。下一章我会讲什么时候真的该上 Multi-Agent。4. 什么时候真的需要 Multi-Agent四种信号4.1 领域知识或角色之间存在对抗/制衡如果任务本身就依赖不同视角的碰撞Multi-Agent 就非常合适。最典型的是内容安全审核一个 Agent 写文案另一个 Agent 从合规角度审它。这两个角色立场天然不同放在同一个 Agent 里很难同时做到“创造”和“挑刺”。再比如做 AI 辩论、红蓝对抗、商业策略推演需要两个 Agent 分别扮演正方反方或不同部门。它们各自维护独立的记忆和观点才能产生真正有价值的思想碰撞。这种多角色不是“堆人数”而是刻意制造信息差。4.2 需要大量并行处理当任务可以被切分成多个互不依赖的子任务时Multi-Agent 可以显著提速。比如给 100 份简历做初筛你可以拆成 5 个“筛选 Agent”每个处理 20 份最后汇总结果。这个场景里每个子 Agent 不需要知道其他 Agent 在做什么也不需要太多交互本质上是一个数据并行问题。用编程类比单 Agent 是单线程Multi-Agent 是线程池。只要分片合理、结果能合并收益就非常明显。但注意并行任务的通信协议仍然要结构化设计否则合并环节会成为新的瓶颈。4.3 长链路、长期状态的复杂业务有些业务流程特别长比如“从需求到代码发布”的研发助手先理解需求再写设计文档再写代码再跑测试再修 bug最后生成发布说明。如果全程一个 Agent 做它的上下文会被各种中间产物塞满前面捏造的信息会污染后面的决策。这时拆成“需求 Agent”“编码 Agent”“测试 Agent”反而是更干净的架构每个 Agent 负责一段生命周期通过共享的工程状态Git 分支、测试报告、代码规范检查结果协作。这种模式下Agent 之间与其说在对话不如说它们在操作同一个工作台。各自私有上下文隔离只把标准产物写入全局状态降低信息污染。4.4 多系统对接与安全隔离当不同环节需要访问不同权限的系统时多 Agent 可以帮你做权限隔离。比如一个 Agent 有权限访问数据库另一个 Agent 只能查公开资料第三个 Agent 负责跟外部 API 通信。你把它们拆开每个 Agent 只暴露必要工具避免一个 Agent“权限过大”的风险。这在企业级应用里非常重要不是你信不过模型而是你无法保证模型不会被提示词注入骗着调用敏感工具。多 Agent 等于加了一层隔离墙调度层成了唯一的“交通警察”。哪怕调度 Agent 被诱导它手里也没有实际工具的凭证。4.5 协作模式与通信机制选型如果你决定上 Multi-Agent下一步要选协作模式。最常见的三种Orchestrator-Worker调度者-工人一个协调 Agent 负责任务分解、分发、结果聚合。适合任务类型多、但单个子任务边界清晰的场景。Peer-to-Peer平级协作多个 Agent 地位平等自由交换消息。适合辩论、评审这类需要往返讨论的场景。Blackboard/共享工作台Agent 不直接对话而是读写共享状态。适合长链路研发流程缺点是状态版本管理需要自己实现。在通信机制上一定要优先选择结构化消息。我会在第六章详细展开为什么。5. 同一需求两种方案怎么选我用一个下单场景做了对比5.1 需求描述为了把上面的标准串起来我讲一个尽量真实的场景智能客服助手。用户发来一句话“帮我查一下上周买的耳机物流到哪了要是还没发货就帮我退了吧。”这个需求至少支持四件事识别用户身份、查订单状态、查物流轨迹、判断退货条件并执行退款。你会怎么设计5.2 方案 A单 Agent 订单 Skill方案 A 里只有一个客服 Agent挂四个 Skillauth_user鉴权、query_order查订单、query_logistics查物流、apply_refund退款。Agent 的决策逻辑在 LangGraph 里是一条线性链加一个条件分支调用 auth_user 获取用户身份上下文并行调用 query_order 和 query_logistics拿订单状态和物流轨迹判断“未发货”条件是否成立如果成立调用 apply_refund否则只回复物流信息。这样设计的好处是状态转移非常直观所有中间结果都存在同一个 state 对象里调试时直接看状态字段即可。因为它没有第二个角色参与决策所以不会出现角色间理解不一致的问题。这个方案的局限也很明显如果未来要增加多种不同的售后退款策略比如不同商品走不同审批流这个逻辑会越来越庞大。到那一步你可能就需要升级架构了。5.3 方案 BOrchestrator Worker Agents方案 B 是设一个“客服协调者 Agent”它本身不执行具体动作只负责理解意图然后把子任务派发给三个 Worker Agent订单 Agent、物流 Agent、退款 Agent。每个 Worker 有自己的工具集和权限执行完把结构化结果返回给协调者。这套架构的好处是职责清晰。订单 Agent 和退款 Agent 可以分别迭代、分别测试权限隔离也好做。缺点是协调者本身就是一大段复杂逻辑它可能理解错意图派错活而且每次用户问题涉及多步时要等两轮以上的 Agent 往返响应延迟明显上升。我在原型里给这种协作写过一个消息协议示例供你参考{ task_id: ORD-2024-0001, from: coordinator, to: order_agent, message_type: query_order, payload: { user_id: u_1024, order_no: OD20240711 }, callback: refund_decision }5.4 我的取舍经验我把两个原型都写出来跑过一轮。结论是如果这个客服系统只服务一个业务线用户问题类型不超过 20 种我的首选是方案 A。因为大多数流量都是“查状态”这个动作退款规则简单单 Agent 可以覆盖而且好排查。但如果公司有多个业务线、多套订单系统各自的权限模型还不一样我会直接选方案 B。因为这时候天然存在多个角色边界硬塞进一个 Agent 只会让 Skill 之间的上下文爆炸。所以“什么时候选多 Agent”不是一个技术偏好问题而是一个组织架构问题。为了更清楚地对比我给出一张实际评估表评估项方案 A单 Agent Skill方案 BOrchestrator Workers开发时间2-3 天5-7 天平均响应延迟约 2 次模型调用约 4 次模型调用权限隔离能力弱全工具都暴露给主 Agent强Worker 各持所需凭证扩展新业务线需要改主 Agent 逻辑增加一个新 Worker调试难度低看状态机高看消息流适用条件单一业务、规则稳定多业务、多系统、多权限6. 工程落地中的几个细节和坑6.1 别把“多个 Agent”做成了“多个流程”很多团队所谓的 Multi-Agent其实是把原来的 if-else 逻辑改成了“A 做一步B 做一步C 做一步”的线性链。这种写法在代码层面是流程编排在概念上并不是多 Agent 协作。真正的多 Agent 要有信息交互和决策回路B 的输出会影响 A 的下一步行动或 A 可以反驳 B。如果你只是把旧管线拆给不同的模型实例那建议直接用单 Agent Skill。代码更少、延迟更低效果只可能更好。否则你只是在用更复杂的技术做同一件事。6.2 通信机制别只靠自然语言这是最容易踩坑的点。设计多 Agent 协作时很多人让 Agent 之间用自然语言互发消息比如“我已经完成了订单查询结果是 xx你可以去退款了”。短期能用长期会很脆模型偶发措辞变化会导致下游 Agent 解析错误。成熟的方案是定义结构化消息 Schema用 JSON 包裹工具调用结果和状态。例如每个 Agent 输出协议统一为{ task_id: …, status: success, data: { }, errors: [] }下游 Agent 只需要读取 Schema不需要理解散文。面试时如果能主动提到这一点非常加分。6.3 避免“上下文串台”和循环调用多 Agent 用久了会遇到一个非常头疼的问题Agent A 在某个分支的临时记忆被错误地传给 Agent B导致 B 做出错误判断。我建议在编排层维护“全局状态”和“角色私有状态”分离结构。全局状态放任务 ID、截止时间、共同目标私有状态放各 Agent 自己的推理记录。另外一定要给每条协作链设置最大轮数防止两个 Agent 互相“甩锅”死循环。我在生产代码里通常设 max_rounds 6超过就进入人工接管候选队列。6.4 性能与并发模型调用不能无限并行面试里经常被追问“AI agent 怎么扛并发”。这里给一个直接的回答并发瓶颈几乎都在模型服务层而不是 Agent 层。你用 Multi-Agent 做并行任务本质上是把“单个请求内部的多步模型调用”变成了“同时发起多个模型调用”对后端模型服务、限流、队列都要做对应设计。用 LangGraph 做分支并行时要控制并发上限避免一瞬间打爆供应商接口。常见的做法是在编排层加一个简单的信号量或令牌桶同一任务的分支最多同时跑 2 到 3 个。这能显著降低 429 报错率。6.5 调试与可观测性没有好日志的 Multi-Agent 是灾难单 Agent 看 trace 就够了多 Agent 除了 trace还要看“角色间消息流”。我建议每一项协作消息都记录from_role、to_role、message_type、duration、token_cost、status。这样出问题时可以快速回放。我认识一个团队用商业观测平台做 Agent 追踪我们没那么重就自己写了一个中间件把消息落库。这个中间件后来成了团队排查线上问题最常用的工具。如果你的项目刚起步至少要在编排层打一个清晰日志记录每一步输入输出截断后的摘要。6.6 Skill 设计的一些建议不管用单 Agent 还是多 AgentSkill 的质量都是下限。我踩过的坑主要有三个。第一Skill 的输入输出必须声明清楚别让模型猜字段类型能定义 JSON Schema 就定义。第二一个 Skill 只解决一个问题宁可拆细一点也不要把“解析文档 写摘要 发邮件”放在一个 Skill 里否则模型选工具时会犹豫。第三Skill 里要有错误处理和重试提示比如“接口返回 429 时等待 2 秒重试一次”这能明显减少 Agent 胡编乱造。7. 面试答题思路与“标准”话术7.1 回答结构先判场景再给标准最后说代价如果你正在准备 AI agent 相关的面试这道题其实有一个还不错的答题骨架先指出“选择取决于任务结构和协作需求”再给两条路各自的适用场景最后补一句“不管选哪个都要先考虑维护成本”。具体话术可以这么说“我会先画一遍任务图。如果任务图是一棵单路径树、每个节点都共享同一份上下文那我用一个 Agent 加一组 Skill 实现用状态机或图编排把这些 Skill 串起来。如果任务图里出现了明显的角色冲突、需要隔离权限或并行加速我才考虑拆成 Multi-Agent并且优先选择 Orchestrator-Worker 模式让一个协调 Agent 负责任务分发和结果聚合。”这样讲既显得有结构又体现你关心工程成本。7.2 一些加分表达除了框架面试官往往还想听到你对“协作机制”的理解。可以主动说多 Agent 之间通信我会尽量用结构化消息而不是自然语言我还关注最大轮数和状态隔离如果需求方只是觉得“多个 Agent 听起来厉害”我会在评审阶段把 token 成本和延迟增量列出来。这些表达会让面试官觉得你踩过坑而不是只会背概念。另外可以提一句“Agent 的边界比数量重要”这句话在很多面试官那里会很加分。7.3 现场可能遇到的追问面试官大概率会追问“如果需求接下来会变复杂怎么考虑”你可以回答先保证单 Agent 的核心路径稳定把可能延伸成角色的部分预留在 Skill 边界上比如每个 Skill 的输入输出都用独立 Schema。假如未来确实需要拆出“退款专员”把一个 Skill 升级成 Worker Agent对上层是透明的。还有一种追问是“怎么防止 Agent 之间互相干扰”你可以从私有状态与全局状态分离、消息 Schema 校验、以及可观测性日志三个方面答。这些都答上来基本上这道题就稳了。7.4 一个更完整的回答示例最后我给一个可以直接套用的完整回答片段适合面试时用“我选架构主要看三件事角色边界、信息交互方式、成本预算。如果任务是线性推进所有步骤共享同一份上下文我用单 Agent Skill把每个能力封装成独立函数再用状态机串起来这样调试最方便。如果任务里有多个立场不同的角色需要对抗或互相校验或者不同环节需要隔离权限我会用 Multi-Agent。先说结论单 Agent 是最小可行实现Multi-Agent 是优化方案而不是默认方案。我不会在需求还不清晰时提前引入角色拆分的复杂度。”这段回答的长度控制在 1 分钟内重点清晰你应该能直接拿去用。8. 最后再说一点私货我自己刚开始做 Agent 项目的时候也是重度 Multi-Agent 爱好者看到那种“十个 Agent 开会”的架构图就觉得很酷。但真正上了生产之后我才意识到复杂度本身就是一种负债。优先选最简单的方案直到你有明确证据证明它不够用这条路在 Agent 工程里尤其成立。每次团队讨论架构我都会把一句话贴在文档第一行“一个 Agent 如果能做完就不要让两个 Agent 开会。”后来很多让我头疼的线上问题都是因为违反了这句话。如果你现在也正卡在选型上我的建议只有一条先拿真实流量跑一次单 Agent Skill 的原型把指标记下来然后想想你在 Multi-Agent 方案里要解决的那个问题是否真的无法被现有工具覆盖。大部分情况下你会发现自己省下了一个月的开发和无数个失眠夜晚。等哪天确实碰上了强角色对抗、并行提速或权限隔离的需求再从容地打开 Multi-Agent 的抽屉那才是它该上场的时候。
