Agent 架构选型：七种架构与选型逻辑（口播版）
面试高频问题：Agent 架构怎么选？Single-Agent、Multi-Agent、Workflow 这些分别什么场景用？ 一句话答案：架构没有统一标准，按场景复杂度和所需控制力选；多数人选错不是因为架构不好，是认知盲区 —— 只见过自己用的那一种。 适用面次：二面深度 / 三面综合（架构视野 + 选型判断力） 本版定位：口语应答脚本 —— 先给「开口就能说」的话术，再给速记要点。
【30 秒极简版】（面试官随口一问时用）
架构没有最好，只有合不合适 —— 按场景复杂度和要的控制力选。演进脉络是 Single-Agent → Multi-Agent 协作 → 基于图的 Workflow。轻场景一个 Agent 就够；要分工就上 Multi-Agent；流程复杂、要精确控制就走图编排。做 AI Coding 或 Skill 系统的话，我优先选 Router+Skill 架构。不用一步到位，按业务复杂度匹配档位就行。
【2 分钟完整口播】（正式被问到时的主干回答）
我先说一个观察：多数开发者对 Agent 架构的选择，其实是被认知盲区限制住了，不是基于自己的场景选的 —— 只会用自己熟的那一种，拿着锤子找钉子。
我的选型逻辑就两条：场景复杂程度、需要的控制力。控制力要求越高，越往确定性强的架构走；探索性越强，越往自由度高的架构走。
按从轻量到企业级排，我会把这七种架构串成一条线讲：
最轻的是 Single-Agent，一个 Agent 带一组工具，一条 ReAct 循环跑到底 —— 简单场景够用，任务一长就失控。 往上加约束是 Reasoning 架构，把思考过程显式化，用思维链约束推理质量 —— 适合要深度推理的决策类任务。 再往上是 Plan-and-Execute，先规划再执行，规划器和执行器分离 —— 解决长任务失控的第一步，但规划可能过时，要配动态重规划。 需要分工就上 Multi-Agent，多个角色协作 —— 并行、隔离、角色差异大的场景才划算，代价是 token 翻倍、延迟上升、一致性风险。 做 AI Coding 或 Skill 系统，我优先选 Router+Skill：路由收口做分发，Skill 封装能力 —— 工具多、场景可枚举的系统这是最优解，可控、好扩展。 最复杂的是 Blackboard 黑板系统，多 Agent 围绕共享黑板读写、协同求解 —— 适合解空间大、没有固定流程的复杂问题，是偏学术/重工程的架构。 企业级要精确控制就走 Graph Workflow，基于图编排，节点、边、条件分支全显式 —— 流程确定、审计要求高的场景用它，LangGraph 就是这个路数。
最后给选型建议：不用一步到位。按业务复杂度匹配档位：简单场景 Single-Agent，流程复杂上 Graph Workflow，中间地带按控制力需求挑。架构可以演进，但别为没到来的复杂度提前过度设计。
一、选型核心逻辑（先立框架）
开口说：
选型不问"哪个最好"，问两件事：场景有多复杂、要多强的控制力。演进脉络就是控制力不断加强的过程：Single-Agent → Multi-Agent 协作 → 基于图的 Workflow。
速记：
复杂度（纵轴）× 控制力（横轴）→ 定位到档位
探索性强 → 自由度高的架构（Reasoning / Blackboard）
控制力强 → 确定性强的架构（Router+Skill / Graph Workflow）
AI Coding / Skill 系统方向 → 优先 Router+Skill⚠️ 认知盲区提醒（拔高点）：多数人选型失败不是技术问题，是只见过一个档位。把七种铺开，才有"选"的资格。
二、七种架构拆解（从轻量到企业级）
速记主线：一单 → 一思 → 一划 → 一队 → 一枢 → 一板 → 一图
| # | 架构 | 一句话运作方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|---|
| 1 | Single-Agent | 一个 Agent + 一组工具，ReAct 循环跑到底 | 简单、延迟低、好调试 | 长任务失控、工具多了选择困难 | 简单任务、原型验证 |
| 2 | Reasoning | 显式思考过程，思维链约束推理 | 推理深、决策质量高 | 慢、贵、过程不可控 | 深度决策类任务 |
| 3 | Plan-and-Execute | 规划器先拆解，执行器逐步执行 | 长任务有章法、可控性提升 | 规划可能过时，需动态重规划 | 中长任务、步骤明确的流程 |
| 4 | Multi-Agent | 多角色分工协作（路由/专家/handoff） | 并行、上下文隔离、角色专精 | token 翻倍、延迟升、一致性风险 | 深度调研、编程等可并行/需隔离的场景 |
| 5 | Router+Skill | 路由收口分发 + Skill 封装能力 | 可控、好扩展、Skill 可复用 | 需要场景可枚举、Skill 有维护成本 | AI Coding、Skill 系统（优先选） |
| 6 | Blackboard 黑板 | 多 Agent 读写共享黑板，协同求解 | 解空间大也能收敛、灵活 | 实现重、调试难、偏学术 | 无固定流程的复杂求解问题 |
| 7 | Graph Workflow | 基于图编排：节点+边+条件分支全显式 | 精确控制、可审计、可回滚 | 搭建成本高、灵活性低 | 企业级复杂流程、强合规审计场景 |
每种的「开口说」补充句（被点名追问时用）：
- Single-Agent：> 90% 的场景它就够，别上来就多 Agent。
- Reasoning：把思考显式化才有抓手，不然推理就是黑盒。
- Plan-and-Execute：规划器和执行器分离，是治长任务失控的第一步（呼应第 10 篇）。
- Multi-Agent：三类场景才划算 —— 并行、隔离、角色差异（呼应第 09 篇）。
- Router+Skill：路由是确定性收口，Skill 是能力沉淀 —— 工具一多这是唯一能维护的形态。
- Blackboard：适合"没有流程可编排"的问题，靠共享状态自发协作。
- Graph Workflow：LangGraph 就是这个路数；流程确定 + 要审计，选它。
三、选型建议（收尾）
开口说：
不用一步到位。按业务复杂度匹配档位，架构是可以演进的。
速记（演进阶梯）：
原型期 → Single-Agent（先跑通）
流程固化 → Plan-and-Execute / Graph Workflow（管住轨迹）
场景多工具多 → Router+Skill（收口 + 沉淀）
真需要分工 → Multi-Agent（三类场景判定）演进思维 ≠ 过度设计：别为没到来的复杂度提前加架构；也别在复杂度到了之后还守着旧档位不放。
四、避坑提醒
- ❌ 别说"X 架构最好" → ✅ 说"我的场景需要什么档位"（选型判断力，不是背榜单）。
- ❌ 别只认识 Multi-Agent → ✅ 七种至少能报出运作方式 + 一优一劣一场景。
- ❌ 别把 Blackboard 讲成玄学 → ✅ 一句话讲清"共享黑板 + 多 Agent 自发协作"即可。
- ❌ 别编落地数据 → 被追问效果时如实说"以监控数据为准，具体值暂未带"。
五、面试官在考什么
| 维度 | 你的证据 |
|---|---|
| 架构视野 | 七种架构铺得开，不是只会一种 |
| 选型判断力 | 有明确的两条选型逻辑（复杂度 / 控制力），不是跟着热点走 |
| 工程务实 | "不用一步到位"、按档位演进 —— 不为架构而架构 |
六、追问预案（Q&A 演练）
Q1：你的 mewhelp 项目为什么不用 Graph Workflow 全量编排？
当前规模流程还不够复杂到需要全图编排，用 Workflow 固化主干 + 单主力 Agent 收敛执行（呼应第 09 篇）；流程再长、审计要求再高，会演进到 Graph。
Q2：Router+Skill 和 Multi-Agent 的路由 Agent 有什么区别？
路由 Agent 是模型做分发，有不确定性；Router+Skill 的路由是确定性逻辑收口（规则/小模型），可控好排查 —— 这正是 Skill 系统优先选它的原因。
Q3：Plan-and-Execute 和 Graph Workflow 都管流程，怎么选？
Plan-and-Execute 的规划是模型生成的、动态的，适合探索性任务；Graph 的流程是人定义的、显式的，适合确定流程 + 审计场景。一个弹性大，一个可控强。
Q4：Blackboard 现在还有实际用处吗？
有，但窄 —— 适合解空间大、无法预定义流程的问题（复杂求解、多源信息融合）；一般业务系统很少需要，别为用而用。
全篇串联（考前 10 秒扫这个）
认知盲区（立观察）→ 两条选型逻辑：复杂度 × 控制力（立框架）
→ 七种架构：一单 一思 一划 一队 一枢 一板 一图（从轻到重）
→ AI Coding / Skill 方向 → Router+Skill 优先
→ 选型建议：不用一步到位，按档位演进收尾关联笔记：09多Agent架构取舍-客服场景为什么不用多Agent（Multi-Agent 划算三类场景）、10Agent长任务失控治理-任务管控三层体系与执行闭环（Plan-and-Execute 与管控体系呼应）、22多Agent场景边界与部署模式-串行与层级分发（多 Agent 的适用边界与部署模式）