Multi-Agent还是单Agent+Skill？架构选型决策框架

前两天有位朋友去面一个 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 的判断。

为了方便对比，我把它们的核心差异列在下面：

看完表你应该有直觉了：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 去做 C，B 又让 A 确认 C”，日志就会变成聊天记录，排查问题需要像读小说一样往前翻。

如果你的业务对准确率要求很高，需要频繁灰度、回归测试，那一定要从单 Agent 开始。我做过一个财务票据审核 Agent，团队要求每一笔异常必须有明确的处理原因。最初设计成“识别 Agent + 审核 Agent + 出纳 Agent”三个角色，测试了一周，发现问题极难定位。后来改回单 Agent + 多个 Skill，在每个 Skill 里加结构化日志，错误率反而下降了一个档次。

3.4 真实项目：一个 FastAPI + LangGraph 的单 Agent 文档助手

展开说一个我自己的落地案例。技术栈是 FastAPI 做服务，LangGraph 做流程编排，底层接支持 function calling 的模型。核心功能是：上传一个混合格式文档，自动抽取客户信息、合同条款和风险点。

起初需求方说“让多个 Agent 协作”，但我在原型阶段只定义了一个主 Agent，挂了三个 Skill：resume_document、extract_fields、risk_check。LangGraph 里就是一个 state graph：

graph = 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，挂四个 Skill：auth_user（鉴权）、query_order（查订单）、query_logistics（查物流）、apply_refund（退款）。

Agent 的决策逻辑在 LangGraph 里是一条线性链加一个条件分支：

1. 调用 auth_user 获取用户身份上下文；
2. 并行调用 query_order 和 query_logistics，拿订单状态和物流轨迹；
3. 判断“未发货”条件是否成立；
4. 如果成立，调用 apply_refund，否则只回复物流信息。

这样设计的好处是：状态转移非常直观，所有中间结果都存在同一个 state 对象里，调试时直接看状态字段即可。因为它没有第二个角色参与决策，所以不会出现角色间理解不一致的问题。

这个方案的局限也很明显：如果未来要增加多种不同的售后退款策略，比如不同商品走不同审批流，这个逻辑会越来越庞大。到那一步，你可能就需要升级架构了。

5.3 方案 B：Orchestrator + 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”不是一个技术偏好问题，而是一个组织架构问题。

为了更清楚地对比，我给出一张实际评估表：

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 还是多 Agent，Skill 的质量都是下限。我踩过的坑主要有三个。

第一，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 的抽屉，那才是它该上场的时候。