主题
当用户提出一个相对更复杂的问题时，大模型可能需要多次调用不同的工具来完成任务。Agent 就是能够自主规划、自主调用工具，直至完成用户下达的任务的系统。
上面查天气、找卖雨伞店铺的过程里，Agent 一直在「思考 → 调用工具 → 看结果」之间循环，直到凑齐最终答案——这其实就是最经典的一种 Agent 架构。真正落地时，构建 Agent 的方式远不止这一种：当任务变复杂、要同时兼顾多个步骤时，让单个模型包揽全部决策，容易出现「思考爆炸」和「上下文污染」，于是业界逐渐沉淀出七种常见架构，复杂度和适用场景层层递进。
单 Agent 架构：一个大模型从头包到尾，输入 → 思考决策 → 调用工具 → 输出，链路单向。结构最简单、成本最低，适合普通问答、简单自动化这类轻量场景（基础版 ChatGPT、Copilot 就是这一类）；一旦任务复杂、要同时兼顾多件事，单模型就容易「想岔」。
ReAct 架构：名字取自 Reason（推理）+ Act（行动）。模型在「思考（Thought）→ 行动（Action）→ 观察（Observation）」之间反复循环，边想边试、按反馈调整，直到达成目标——上面天气雨伞的例子就是它。过程透明、可解释，擅长多步骤和探索性任务；代价是循环会消耗大量 Token，也容易跑偏，不适合追求稳定的大规模工程系统。
Plan & Execute 架构：把任务拆成「先规划、后执行」两段——Planner 先列出完整步骤清单，Executor 再照单逐步执行。确定性和稳定性比 ReAct 高，适合代码生成、项目自动化这类长流程；但它高度依赖前置计划，一旦计划出错容易全盘崩，灵活性不如边走边调的 ReAct。
多 Agent 架构：多个智能体分工协作、各司其职。顶层由 Orchestrator 统筹派活，下面挂 Planner、Coder、Reviewer、Tool 等子 Agent，像一支软件研发团队。任务拆解清晰、每个角色独立上下文能降低污染、扩展性强；缺点是搭建与运行成本高，彼此的协调调度也更复杂。
Router + Skill 架构：核心思路是「不让模型自由地『想』，而是让它『选』」。用户输入先经意图路由器（Intent Router）判断意图，再直接分发到预先封装好的技能（Skill）执行，每个 Skill 都是「一段能力 + 一份知识说明」的封装。企业级稳定、执行路径可缓存、性能与性价比都好，命中率还能量化评估；代价是前期要投入成本设计 Skill 库，需求边界模糊时可能出现「命中冲突」。GitHub Copilot 的技能系统就是典型代表。
Blackboard 架构（黑板系统）：系统维护一块公共「黑板」（共享状态），所有 Agent 都能读写；谁更新了状态，就触发相关 Agent 接着行动。子智能体之间上下文无缝共享，擅长状态频繁变化、需要自发协同的复杂场景；代价是状态管理复杂、出了问题不易追根溯源。这种「共享状态驱动」的思路，常被一些工作流引擎和分布式系统借鉴。
Graph / Workflow 架构（企业级主流）：企业级生产环境里最主流、也最「重」的一种。用有向无环图（DAG）把整个流程编排成节点，支持条件分支与并行，整条任务链可回溯、可观测、可重试。稳定、透明、好 Debug，能扛长周期复杂业务；代价是体系庞大、前期编排工作量最重。代表工具有 LangGraph、Temporal、Airflow、n8n、Prefect。
**做 AI 编程助手或技能型系统，优先考虑 Router + Skill。**它把「自由推理」换成「路由到固化技能」，机制上更可控、更稳定；固定路径可缓存，省掉长链推理的 Token 开销；命中率可监控、便于迭代优化；GitHub Copilot 等头部产品也基本走这条路，已在复杂研发场景里被验证。它同样贴合 Claude Code 这类工具的技能（Skill）设计——这也是下一节要展开的内容。
说到底，没有最好的架构，只有最合适的架构。大致可以按「单 Agent（快速验证）→ ReAct（多步探索）→ Plan & Execute（工程化）→ 多 Agent（团队协作）→ Router + Skill（精细技能系统）→ Blackboard（共享状态）→ Graph / Workflow（企业级流水线）」这条复杂度阶梯来理解，按业务复杂度和对流程的掌控需求，决定往上走到哪一层。