AI Agent 系统设计方法导论

从调用模型到系统工程在当前 AI 领域单纯的 Prompt Engineering 已无法满足日益复杂的业务逻辑。作为后端 AI 工程师我们必须建立一个核心共识模型能力的上限决定了产品的下限而架构设计的优劣直接决定了产品的上限。模型提供了最基础的智力保障而架构设计如何规划、协作、纠错则赋予了系统解决复杂问题的能力。本文通过三个递进的决策层级梳理从顶层方法论到底层执行逻辑的完整知识体系层级关注点核心问题开发范式用什么思路解决问题战略选型系统架构系统的组件如何组织与协作结构设计设计模式单个节点内的智能体如何思考与行动执行逻辑⚠️ 这三个层级不是严格的上下级替代关系而是不同维度的设计决策在实际项目中往往需要组合使用。一、开发范式 (Development Paradigms) —— 战略选型开发范式是解决 AI 问题的顶层方法论决定了系统设计的思维底色。关键认知以下范式并非互斥的四选一而是可组合的能力维度。一个成熟的系统往往是多种范式的叠加例如使用 Fine-tuned 模型 RAG 检索 Agentic Workflow 编排。1.1 推理阶段 (Inference-time) 策略这些范式作用于模型的使用阶段不改变模型参数本身。范式核心理念解决的痛点典型场景RAG(检索增强生成)外部知识库检索 LLM 生成模型的幻觉、知识时效性、私域知识缺失企业知识问答、文档分析Agentic Workflow(智能体工作流)强调迭代、规划、工具调用与循环反馈的系统化流程单次 Prompt 生成质量不稳定、复杂任务不可控自动化研究、代码生成、数据处理流水线Prompt 程序化优化(Programmatic Prompt Optimization)将 Prompt 视为可编译、可自动调优的程序模块手动调优 Prompt 的不可维护性、脆弱性与不可复现性大规模 Prompt 管理、A/B 测试驱动的优化关于 DSPyDSPy 是Prompt 程序化优化这一范式的代表性框架实现而非范式本身。类似地LangGraph 是 Agentic Workflow 的框架实现。1.2 训练阶段 (Training-time) 策略范式核心理念解决的痛点典型场景Fine-tuning(参数微调)在特定数据上调整模型参数特定领域专业技能、特殊输出格式、极低推理延迟需求医疗/法律领域专用模型、结构化数据提取 Fine-tuning 改变的是模型本身的能力基线它为推理阶段的所有策略提供更优的底座。二、系统架构 (System Architectures) —— 结构设计架构定义了系统的组件构成、拓扑关系及协作协议是落地一个 AI 系统时最先需要确定的工程决策。以下按复杂度递增排列2.1 单智能体架构 (Single Agent)定义基础原子单元。由 Memory记忆、Planning规划和 Tools工具围绕单个 LLM 核心组成。适用场景单一职责的任务如对话机器人、简单的工具调用助手。局限面对复杂多步任务时上下文窗口和推理能力容易成为瓶颈。2.2 工作流架构 (Workflow / Graph)定义基于状态机或 DAG有向无环图的结构。控制流由开发者在编译时预定义AI 在各节点内执行推理。核心特征路径确定性高——哪些节点之间可以跳转、在什么条件下跳转由代码逻辑决定而非 LLM 决定。适用场景步骤明确、流程固定的业务如文档处理流水线、多步表单填写。代表框架LangGraph、Apache Airflow LLM 节点。2.3 编排架构 (Orchestrator-Workers)定义中心化层级结构。主 AgentOrchestrator负责理解需求、动态拆解子任务并路由分发子 AgentWorker负责特定领域的执行。核心特征控制流由 LLM 在运行时动态决定——Orchestrator 根据任务语义判断应该调用哪个 Worker、以什么顺序执行。适用场景业务逻辑复杂但层级清晰的场景如客服系统主路由 退款/物流/咨询子 Agent。代表框架OpenAI Swarm、Google A2A 协议下的 Agent 编排。⚡工作流 vs 编排的本质区别维度工作流架构编排架构控制流编译时确定开发者定义运行时动态LLM 决定确定性高路径可预测中依赖 LLM 路由质量灵活性低新流程需改代码高新任务类型可自动路由2.4 协同架构 (Multi-Agent Collaboration)定义多角色 Agent 通过共享消息通道进行交互各 Agent 具有独立的目标和专业分工。核心特征通过角色专业化与分工协作解决复杂开放性问题。适用场景软件开发模拟、多角度辩论与决策、复杂研究分析。代表框架AutoGen、CrewAI、ChatDev。⚠️工程实践提醒当前主流 Multi-Agent 框架大多仍依赖预设的通信拓扑或某种程度的中心化调度。真正的去中心化自组织在生产环境中可控性较低。Multi-Agent 的核心工程价值在于角色分工带来的专业化质量提升而非抽象的智能涌现。三、设计模式 (Design Patterns) —— 执行逻辑设计模式是在架构的各个节点内部实现特定逻辑目标的通用模板关注的是单个 Agent 如何思考与行动。3.1 推理与行动类ReAct (Reasoning Acting)推理与行动的交织模式将推理链Chain-of-Thought和工具调用Action交织在同一个生成序列中形成思考 → 行动 → 观察 → 思考的闭环。Thought: 用户问的是今天北京天气我需要调用天气 APIAction: call_weather_api(city北京)Observation: 晴25°C东北风3级Thought: 我已经获得了天气信息可以回复用户了Answer: 今天北京天气晴朗气温25°C……核心价值将推理与行动统一到同一个决策流中使模型能够实时感知外部环境反馈动态调整后续策略。适用场景需要工具调用的交互式任务。Plan-and-Execute (规划-执行分离)先全局规划再逐步执行将任务拆分为两个阶段Planner 先生成完整的执行计划Executor 逐步执行每个子任务执行结果可反馈给 Planner 进行计划修正。核心价值避免 ReAct 模式在长任务链中迷失方向的问题提供全局视野。适用场景步骤多、依赖关系复杂的任务。3.2 质量提升类Reflexion (反思模式)从失败中学习的自我进化模式引入Evaluator评估者角色对执行结果进行评判若不达标则生成反思日志Reflection存入记忆后重新执行直至通过评估。核心价值将失败经验转化为可复用的记忆资产通过微观闭环最大化榨取模型能力。适用场景对输出质量要求高的生成任务如代码生成、学术写作。Self-Correction (多轮自纠错)基于规则或模型的即时修正执行后对输出进行格式校验、事实核查或一致性检查若发现问题则立即修正无需完整的反思流程。核心价值轻量级的质量保障适合对延迟敏感的场景。与 Reflexion 的区别Self-Correction 是即时修补Reflexion 是深度复盘。3.3 推理增强类Chain-of-Thought (CoT) / Tree-of-Thought (ToT)结构化推理模式CoT引导模型逐步推理生成线性的思维链。ToT在每一步生成多个候选推理路径通过评估选择最优分支形成树状搜索。核心价值提升模型在复杂逻辑推理、数学计算和多步决策中的准确性。适用场景CoT 适用于大多数需要推理的任务ToT 适用于需要探索多种可能性的开放性问题如创意写作、博弈策略。3.4 工具使用类Tool Use (工具调用模式)赋予模型与外部世界交互的能力模型根据任务需要自主选择并调用外部工具API、数据库、代码解释器等将返回结果整合到推理流程中。User: 帮我查询订单 #12345 的物流状态LLM Reasoning: 需要调用订单查询 API→ Action: query_order_api(order_id12345)→ Observation: {status: 已发货, location: 北京转运中心, eta: 2025-01-20}LLM Response: 您的订单 #12345 已发货目前在北京转运中心预计1月20日送达。核心价值突破 LLM 纯文本生成的边界使其具备执行真实操作的能力。关键设计要素要素说明工具描述 (Tool Schema)清晰定义每个工具的名称、用途、参数格式供 LLM 理解和选择调用决策LLM 判断何时需要调用工具、调用哪个工具结果解析将工具返回的结构化数据整合进自然语言响应中错误处理工具调用失败时的重试、降级或反馈机制3.5 设计模式速查表类别模式一句话概括核心解决的问题推理与行动ReAct思考-行动-观察的交织循环动态环境下的工具调用与决策推理与行动Plan-and-Execute先规划全局再逐步执行长任务链中的方向迷失质量提升Reflexion评估-反思-重试的深度复盘输出质量不达标质量提升Self-Correction即时校验与修补格式错误、事实偏差的快速修正推理增强CoT / ToT线性思维链 / 树状搜索复杂逻辑推理准确性不足工具使用Tool Use自主选择并调用外部工具LLM 无法直接执行现实操作四、核心术语辨析建立团队统一语境为消除团队协作中的概念混淆以下对核心术语做出明确定义与边界划分。4.1 三大层级定义层级定义决策时机示例开发范式 (Paradigm)解决问题的基本策略方向是最顶层的方法论选型项目立项 / 方案设计初期本项目采用 RAG Agentic Workflow 的组合范式系统架构 (Architecture)系统组件的组织方式、拓扑关系与协作协议系统设计阶段采用编排架构1 个主 Agent 路由 3 个领域子 Agent设计模式 (Pattern)架构中各节点内部的具体思考与执行逻辑节点实现阶段在代码生成节点引入 Reflexion 模式以确保输出准确性4.2 层级关系全景图五、实战选型决策参考面对一个具体项目时可按以下顺序进行决策Step 1范式选型 —— 用什么策略判断维度条件推荐范式是否需要私域 / 实时知识是✅ 引入RAG任务是否涉及多步骤、工具调用是✅ 引入Agentic Workflow是否有大量 Prompt 需要系统管理和优化是✅ 引入Prompt 程序化优化通用模型在目标领域表现是否不足是✅ 引入Fine-tuningStep 2架构选型 —— 系统怎么组织判断维度条件推荐架构任务简单单一职责是✅单智能体流程固定步骤明确是✅工作流架构任务复杂需动态拆解和路由是✅编排架构需要多角色专业协作是✅协同架构Step 3模式选型 —— 节点内怎么执行判断维度条件推荐模式需要调用外部工具并根据结果推理是✅ReAct任务步骤多需要全局规划是✅Plan-and-Execute对输出质量要求极高允许多次重试是✅Reflexion需要快速格式校验和事实修正是✅Self-Correction涉及复杂逻辑或数学推理是✅CoT / ToT