你做企业级Agent开发用的是什么框架？

1. 概述

截至 2026 年，业界对 Agent 并没有完全统一的唯一分类方法，但在工程实践中，主流的 Agent 构建范式已经比较清晰。严格来说，很多系统并不是“自治 Agent”，而是LLM + 工具 + 检索 + 记忆的增强型应用。因此，在讨论 Agent 时，通常需要区分：

• 模块范式：系统由哪些能力模块组成
• 编排范式：系统如何驱动任务执行
• 协作范式：多个 Agent 或人如何参与任务完成

工程上最常见的起点并不是复杂多 Agent，而是从可控的工作流或单 Agent 工具调用开始。

2. Agent 的基础组成

很多论文和框架会把 Agent 拆成四个核心模块：

• Profile / Role：角色、目标、约束、权限
• Memory：短期上下文、长期记忆、外部知识
• Planning：任务拆解、计划生成、重规划
• Action / Tools：工具调用、环境交互、执行反馈

这是一种模块视角，不等同于具体的构建范式，但有助于理解不同范式的差异。

从设计逻辑上看，几乎所有 Agent 范式都在回答五个共通问题：

• 流程控制权放在哪里，是放在代码里，还是放在模型里
• 任务如何拆解，是按步骤拆、按角色拆，还是按搜索分支拆
• 状态放在哪里，是只放在对话上下文里，还是外置到数据库、图状态或记忆系统中
• 反馈从哪里来，是工具返回、环境观察、自我批评，还是人工审批
• 终止条件如何定义，是固定步数、目标达成、评分达标，还是人工停止

不同范式的本质差异，通常不是“谁更高级”，而是这五个问题的答案不同。

3. 当前主流构建范式及其设计逻辑

3.1 Workflow / 编排型

这类系统由开发者预先定义流程，LLM 只在局部节点承担理解、生成、分类、决策等任务。

常见子模式：

• Prompt Chaining：多个步骤串行处理
• Routing：根据问题类型路由到不同分支
• Parallelization：并行执行多个子任务后汇总
• Orchestrator-Workers：主控节点拆解任务，多个执行节点完成子任务
• Evaluator-Optimizer：先生成结果，再由评审节点打分或修订

设计逻辑：

• 这类范式假设任务结构总体稳定，真正不确定的部分只是局部语义理解或内容生成
• 因为大多数业务问题不是“完全开放式探索”，而是“在固定流程中的若干智能节点”，所以把主控制权保留在代码里更稳妥
• 它的核心思想是把 LLM 当作一个高能力但不完全可靠的组件，而不是唯一控制器

核心机制：

• 用代码、DAG 或状态流显式定义步骤顺序、输入输出、异常分支和重试规则
• 用结构化输出约束每个节点的结果，减少自由生成带来的不可控性
• 在关键节点加入校验器、规则引擎、打分器或人工审批

为什么有效：

• 它把问题空间压缩到可控范围内，模型只需要解决“这一小步该怎么做”
• 由于步骤边界清晰，观测、测试、缓存、回放和审计都更容易
• 当任务失败时，能够快速定位是路由错了、节点错了，还是外部工具错了

设计代价与典型失效点：

• 过于刚性的流程会让系统缺乏应对新情况的能力
• 如果开发者把流程切得过细，系统会出现上下游提示词耦合严重、维护成本高的问题
• 如果节点之间的数据契约不清楚，工作流会演变成一串难以维护的 prompt 拼接

适用场景：

• 客服分流
• 文档处理流水线
• 报表生成
• 审批流
• 企业内部知识助手

3.2 Single-Agent Loop / 单 Agent 循环型

一个 Agent 在循环中反复执行“观察 -> 思考/决策 -> 调工具 -> 获得反馈 -> 继续行动”，直到完成任务或触发停止条件。

典型代表：

• ReAct
• 基于函数调用的 Tool-Using Agent

设计逻辑：

• 这类范式假设开发者无法预先穷举完整流程，因此把“下一步怎么做”的决策权交给模型
• 它适合开放式任务，因为任务路径只有在与环境交互后才逐渐显现
• 本质上，它把 LLM 当成一个在线策略函数，输入当前状态，输出下一步动作

核心机制：

• 保留一个持续更新的行动历史，包括观察、推理痕迹、工具结果和中间结论
• 将工具调用视为动作空间，Agent 在每轮选择“回答、查询、计算、检索或继续行动”
• 通过停止条件、最大步数、工具权限和错误恢复机制控制循环边界

为什么有效：

• 它不要求一开始就规划完整路线，因此面对模糊问题更灵活
• 它能根据环境反馈即时调整，不容易被预先设定的错误流程锁死
• 在任务链路不长时，单 Agent 足以覆盖“理解、决策、执行、反馈”闭环

设计代价与典型失效点：

• 单个 Agent 很容易出现局部贪心，只关注眼前可做的动作，而忽略全局目标
• 对话历史不断增长后，容易出现上下文污染、重复行动、工具滥用或循环漂移
• 如果工具描述和权限边界不清晰，Agent 会频繁做出高成本但低收益的调用

适用场景：

• 通用问答助手
• 带检索和工具调用的办公助手
• 较短链路的自动化执行

3.3 Plan-and-Execute / 规划执行分离型

先规划，再执行；执行过程中根据环境反馈进行重规划。与单 Agent 直接边想边做不同，这类范式会显式保留“计划”这一中间层。

典型代表：

• Plan-and-Solve
• ReWOO

设计逻辑：

• 这类范式要解决的是“长任务中的短视问题”，也就是单 Agent 容易每一步都只做局部最优决策
• 它把长程推理和短程执行拆开，让系统先形成任务骨架，再逐步落地
• 设计上的关键判断是：规划是一种稀缺能力，不需要每一步都重新做；执行是一种局部能力，应该与全局规划解耦

核心机制：

• 规划器先输出步骤列表、依赖关系、成功标准和可用工具
• 执行器按步骤完成具体动作，必要时将执行结果反馈给规划器进行重规划
• 有些实现还会把变量引用、工具结果和阶段性结论显式记录下来，避免重复推理

为什么有效：

• 它把高成本的全局思考前置，可以减少边做边想导致的反复试错
• 计划作为中间对象可以被审查、缓存、复用和解释
• 在复杂任务中，显式计划有助于约束 Agent 不要偏离主题

设计代价与典型失效点：

• 如果初始计划质量差，后续执行可能一直建立在错误前提上
• 如果规划过细，系统会失去灵活性；如果规划过粗，执行阶段又会重新回到单 Agent 的混乱状态
• 在动态环境里，如果没有重规划机制，计划很快会失效

适用场景：

• 长链路信息搜集
• 多步骤数据处理
• 复杂任务自动化
• 研发与分析类任务

3.4 Search / Tree / 搜索型

系统不是只沿一条推理路径前进，而是同时探索多条候选路径，再通过评分、投票、回溯或剪枝选出更优结果。

典型代表：

• Tree of Thoughts

设计逻辑：

• 这类范式要解决的是“单路径推理高方差”问题，也就是只走一条思路时，前面一步错了，后面往往全部失真
• 它把推理看作搜索问题，而不是线性文本生成问题
• 核心思想不是让模型一次想对，而是允许系统保留多个候选思路，再通过外部评价机制筛选

核心机制：

• 将中间思路视为搜索节点，将下一步可能思路视为扩展动作
• 使用评分器、价值函数、启发式规则或投票机制选择保留哪些分支
• 支持回溯、剪枝、束搜索或多轮扩展，以控制搜索深度和成本

为什么有效：

• 它显著降低了早期错误不可逆的问题
• 对需要组合探索的问题，搜索比线性生成更符合问题本身的结构
• 当评分机制足够可靠时，系统能在多个候选方案中找到明显更优的路径

设计代价与典型失效点：

• 分支数一旦上升，成本会指数级放大
• 如果评分器本身不可靠，系统只是“更系统地走错路”
• 对很多普通业务任务来说，这种范式明显过重

适用场景：

• 数学推理
• 复杂决策
• 规划类问题
• 高质量方案生成

3.5 Reflection / Critic / 反思修正型

系统先生成初稿，再对结果进行自我批评、打分、纠错和重写，形成“生成 -> 评估 -> 修正”的闭环。

典型代表：

• Reflexion
• Self-Refine

设计逻辑：

• 这类范式基于一个重要观察：模型第一次生成未必可靠，但往往有能力识别自己的明显缺陷
• 生成和评估在认知上是两种不同任务，因此把它们拆开通常优于一次性完成
• 它的本质是用额外推理预算换更高的输出质量

核心机制：

• 先生成候选结果，再由批评器给出错误分析、改进建议或失败记忆
• 将反馈转化为下一轮的约束条件，而不是简单要求“请再试一次”
• 在代码和工具型任务中，常与测试、执行结果、日志或外部判题器结合

为什么有效：

• 很多错误在“检查阶段”比在“首次创作阶段”更容易暴露
• 明确的反馈使下一轮修正更有方向，而不是随机重写
• 当批评器使用不同视角、不同提示词或不同模型时，往往能减少初稿偏差

设计代价与典型失效点：

• 如果批评质量低，系统只是在重复空泛反馈
• 同一个模型既当作者又当评委时，容易产生自我确认偏差
• 如果没有停止准则，反思过程可能进入小修小补但总体不提升的循环

适用场景：

• 代码生成与修复
• 复杂文案写作
• 研究分析
• 对输出质量要求高的任务

3.6 Multi-Agent / 多 Agent 协同型

多个 Agent 按角色分工协作，共同完成任务。它解决的核心问题不是“更聪明”，而是“分工、隔离、并行和协作”。

常见子模式：

• Manager-Worker：一个主控 Agent 负责分派和汇总
• Specialist Team：多个专业 Agent 各司其职
• Handoff：多个 Agent 平级接力，按阶段移交控制权
• Debate / Committee：多个 Agent 独立给出方案，再投票或仲裁

设计逻辑：

• 这类范式的前提是任务天然具有角色分工、专业边界、权限差异或并行空间
• 单 Agent 把所有目标、工具、规则和上下文塞进一个控制循环后，往往会产生注意力竞争和角色冲突
• 因此多 Agent 的核心设计思路不是增加“人数”，而是降低单 Agent 的认知负载，并把系统拆成多个责任单元

核心机制：

• 通过角色定义、工具边界、消息协议和共享状态来明确每个 Agent 的职责
• 通过管理者、黑板系统、任务队列或交接协议协调 Agent 之间的信息流
• 在一些设计中，仲裁 Agent 或汇总 Agent 负责统一结论，避免多个 Agent 产生冲突输出

为什么有效：

• 角色专业化后，每个 Agent 需要处理的上下文更窄，提示词和工具也更容易对齐
• 多个 Agent 可以并行工作，缩短整体完成时间
• 权限隔离和职责边界清晰后，更适合做企业级治理

设计代价与典型失效点：

• 多 Agent 系统最常见的问题不是推理能力不足，而是通信成本高、重复劳动和责任不清
• 如果共享状态设计不好，不同 Agent 会基于不同事实版本工作，导致结果冲突
• 如果管理者过强，系统会退化成单 Agent 外包；如果管理者过弱，系统会失去协调

适用场景：

• 软件研发代理系统
• 复杂业务流程协同
• 多角色决策支持
• 多部门流程自动化

3.7 Graph / State Machine / 图式状态机型

把 Agent、工具、状态、条件分支、检查点、回滚和人工审批显式建模为图或状态机。

设计逻辑：

• 这类范式主要解决“生产可治理性”问题，而不是单纯追求推理能力
• 一旦任务跨越长时间、多步骤、多系统，单轮对话式 Agent 很难保证可恢复、可回放和可审计
• 因此需要把隐式对话流程转化为显式状态迁移，把运行时行为变成一个可以持久化和观测的系统

核心机制：

• 用节点表示动作或子任务，用边表示状态转移条件
• 在每个节点上存储结构化状态、执行结果、重试信息和检查点
• 将失败恢复、人工接管、超时处理、并发控制和幂等性作为一等公民纳入设计

为什么有效：

• 显式状态让系统具备恢复能力，任务中断后可以从中间继续
• 图结构天然适合可视化、监控、调试和治理
• 在复杂企业流程中，这种范式比纯聊天循环更接近真实系统架构

设计代价与典型失效点：

• 建模成本较高，前期需要把状态和边界设计清楚
• 如果图设计得过度精细，会牺牲灵活性并增加维护负担
• 如果状态定义模糊，图只会把混乱从 prompt 中搬到状态机中

适用场景：

• 企业级 Agent 平台
• 长流程自动化
• 多阶段审批系统
• 需要高可观测性的生产应用

3.8 Human-in-the-Loop / 人在回路型

这不是独立的执行架构，而是一种治理和控制范式。人在关键节点负责审批、纠偏、澄清、接管或终止任务。

设计逻辑：

• 这类范式的根本出发点不是提升模型能力，而是补足责任、信任和合规边界
• 在高风险任务中，系统真正缺少的往往不是“答案生成能力”，而是“谁来承担决策责任”
• 因此，设计上会把人放在不确定性高、后果严重或价值判断强的节点上

核心机制：

• 设定审批门、置信度阈值、异常升级规则和人工接管入口
• 将模型输出转化为待审核对象，而不是直接执行对象
• 记录人工反馈并回写到策略层、规则层或训练数据中

为什么有效：

• 它把自动化系统纳入组织治理链条，而不是让模型绕过组织机制
• 对高价值操作，人类判断仍然是最强的最终保险
• 在实际企业环境中，用户往往更愿意接受“可干预的自动化”，而不是完全黑盒自治

设计代价与典型失效点：

• 如果人工介入点过多，系统吞吐量会迅速下降
• 如果审批标准不一致，人类会成为新的不稳定因素
• 如果人工只做形式化点击通过，系统实际上并没有获得真正治理

适用场景：

• 金融、医疗、法务等高风险流程
• 企业权限审批
• 高价值内容生成
• 对正确性和可追责性要求高的任务

4. 按工程成熟度理解这些范式

如果从落地角度排序，典型演进路径通常是：

1. Augmented LLM：LLM + 检索 + 工具调用
2. Workflow：显式编排业务流程
3. Single-Agent：让 Agent 在有限范围内自主决策
4. Plan-and-Execute / Reflection：增强复杂任务能力
5. Multi-Agent / Graph：面向复杂系统和生产治理扩展

这也是多数团队更稳妥的建设路线。不是所有场景都需要多 Agent。

5. 各范式对比

6. 各范式典型结构图

说明：

• 以下示意图使用Mermaid语法
• 如果当前 Markdown 查看器不支持渲染，可以直接阅读节点名称和箭头关系
• 这些图展示的是典型结构，不代表唯一实现方式

6.1 Workflow / 编排型

flowchart TD A[用户输入 / 任务触发] --> B[入口编排器] B --> C[步骤1: 解析/分类] C --> D{路由判断} D -->|分支A| E[步骤2A: 检索/生成] D -->|分支B| F[步骤2B: 规则处理] E --> G[校验器 / 评分器] F --> G G --> H{通过?} H -->|是| I[结果汇总] H -->|否| J[重试/回退/人工审批] I --> K[输出]

理解方式：

• 主控制权在编排器和流程定义中
• LLM 通常只存在于局部节点，而不负责整个流程调度

6.2 Single-Agent Loop / 单 Agent 循环型

flowchart TD A[用户任务] --> B[Agent] B --> C[观察当前状态] C --> D[思考/决策] D --> E{下一步动作} E -->|调工具| F[工具调用] E -->|直接回答| G[输出答案] F --> H[观察工具返回] H --> I{目标已达成?} I -->|否| B I -->|是| G

理解方式：

• Agent 自己决定下一步做什么
• 运行质量很大程度取决于上下文管理、工具描述和停止条件

6.3 Plan-and-Execute / 规划执行分离型

flowchart TD A[用户任务] --> B[规划器 Planner] B --> C[任务计划 / 步骤列表] C --> D[执行器 Executor] D --> E[执行当前步骤] E --> F[工具/环境] F --> G[执行结果] G --> H{是否需要重规划?} H -->|是| B H -->|否| I{还有剩余步骤?} I -->|是| D I -->|否| J[输出结果]

理解方式：

• 全局思考和局部执行被拆成两个层次
• 关键设计点在于计划粒度和重规划触发条件

6.4 Search / Tree / 搜索型

flowchart TD A[问题] --> B[根节点/初始思路] B --> C[扩展候选思路] C --> D[分支1] C --> E[分支2] C --> F[分支3] D --> G[评分/价值评估] E --> G F --> G G --> H{保留哪些分支?} H --> I[继续扩展] I --> G G --> J[选择最优路径] J --> K[输出答案]

理解方式：

• 系统不是线性生成，而是在“候选空间”里搜索
• 重点不是多想几次，而是保留、比较和剪枝多个中间路径

6.5 Reflection / Critic / 反思修正型

flowchart TD A[任务] --> B[初稿生成] B --> C[批评器/测试器] C --> D[错误分析/改进建议] D --> E[修订器] E --> F{达到质量门槛?} F -->|否| C F -->|是| G[最终结果]

理解方式：

• 先生成，再评审，再修订
• 真实效果通常取决于批评器是否能给出具体、可执行的反馈

6.6 Multi-Agent / 多 Agent 协同型

flowchart TD A[用户任务] --> B[协调者 / Manager] B --> C[Agent 1: 规划] B --> D[Agent 2: 检索] B --> E[Agent 3: 执行] C --> F[共享状态 / 黑板 / 消息总线] D --> F E --> F F --> G[汇总 / 仲裁 Agent] G --> H[最终输出]

理解方式：

• 关键不在“多个模型同时说话”，而在角色边界、共享状态和协调协议
• 如果这三件事不清楚，多 Agent 只会放大混乱

6.7 Graph / State Machine / 图式状态机型

flowchart TD A[Start] --> B[状态S1: 任务接收] B --> C[节点N1: 解析] C --> D{条件判断} D -->|正常| E[节点N2: 执行] D -->|异常| F[节点N_err: 回退/重试] E --> G[Checkpoint] G --> H{需要人工审批?} H -->|是| I[Human Review] H -->|否| J[节点N3: 汇总] I --> J J --> K[End]

理解方式：

• 重点是显式状态迁移、检查点和恢复能力
• 这类系统更像工作流引擎与 Agent 能力的结合

6.8 Human-in-the-Loop / 人在回路型

flowchart TD A[任务进入系统] --> B[模型生成方案] B --> C{风险/置信度检查} C -->|低风险| D[自动执行] C -->|高风险| E[人工审核] E --> F{审核结果} F -->|通过| D F -->|修改后通过| G[修订执行] F -->|驳回| H[终止/回退] D --> I[记录日志与反馈] G --> I

理解方式：

• 人不是“兜底客服”，而是系统治理链上的正式节点
• 该范式通常叠加在其他主执行范式之上

7. 选型决策树

一个容易产生误导的做法，是试图用一棵树把所有范式变成互斥选项。实际上：

• Workflow、Single-Agent、Plan-and-Execute、Search、MultiAgent更像主执行范式
• Reflection、Graph / State Machine、Human-in-the-Loop

更像增强层或治理层

因此更合理的做法是分两层决策。

7.1 第一层：选择主执行范式

flowchart TD A[开始选型] --> B{流程是否稳定且可预定义?} B -->|是| C[优先 Workflow] B -->|否| D{任务是否开放式且链路较短?} D -->|是| E[优先 Single-Agent] D -->|否| F{是否需要长程规划或多步骤依赖?} F -->|是| G[优先 Plan-and-Execute] F -->|否| H{是否需要同时探索多条思路并比较优劣?} H -->|是| I[优先 Search / Tree] H -->|否| J{任务是否天然存在角色分工、并行空间或权限隔离?} J -->|是| K[优先 Multi-Agent] J -->|否| E

解释：

• 如果任务本质上是固定流程中的若干智能节点，应优先Workflow
• 如果问题开放但步骤不长，通常Single-Agent就够用
• 如果任务跨多个阶段且容易走偏，需要显式规划，就转向Plan-and-Execute
• 如果问题核心难点是“要比较多条思路”，而不是“按步骤执行”，才考虑Search
• 只有在分工、权限和并行真的带来收益时，才选择Multi-Agent

7.2 第二层：叠加增强与治理能力

flowchart TD A[已选主执行范式] --> B{任务是否长时运行/需要可恢复/可审计?} B -->|是| C[叠加 Graph / State Machine] B -->|否| D{输出质量是否需要多轮打磨?} C --> D D -->|是| E[叠加 Reflection / Evaluator-Optimizer] D -->|否| F{是否涉及高风险决策、外部执行或合规要求?} E --> F F -->|是| G[叠加 Human-in-the-Loop] F -->|否| H[保持轻量实现] G --> I[形成最终架构] H --> I

解释：

• Graph / State Machine主要回答可恢复、可追踪、可治理问题
• Reflection主要回答质量优化问题
• Human-in-the-Loop主要回答责任、风险和审批问题

7.3 快速决策口诀

• 流程稳定，先上Workflow
• 开放任务但不长，先上Single-Agent
• 长任务易跑偏，转Plan-and-Execute
• 需要比较多条思路，才用Search
• 角色、权限、并行明显，再上Multi-Agent
• 需要恢复与审计，叠加Graph
• 需要更高质量，叠加Reflection
• 高风险任务，一定加Human-in-the-Loop

7.4 典型组合方案

• Workflow + Human-in-the-Loop：适合审批流、客服分流、企业内部流程自动化
• Single-Agent + Reflection：适合代码助手、研究助理、复杂写作
• Plan-and-Execute + Graph：适合长任务执行、跨系统数据处理
• Multi-Agent + Graph + Human-in-the-Loop：适合企业级复杂协作系统
• Search + Reflection：适合高难推理、方案比较和复杂规划

8. 当前业界的实际共识

当前比较一致的工程经验包括：

• 不要一开始就上多 Agent
• 优先选择Workflow或Single-Agent + Tools
• 只有当角色边界明确、工具复杂、权限隔离有必要时，多 Agent 才通常值得
• 高风险场景应优先加入Human-in-the-Loop
• 长流程生产系统更适合图式编排或状态机建模

换句话说，复杂范式并不天然优于简单范式。范式选择应以可控性、成本、治理和任务复杂度为核心依据。

9. 选型建议

如果你的目标是快速落地

优先选择：

• Workflow
• Single-Agent + Tools

如果你的任务链条很长

优先选择：

• Plan-and-Execute
• Graph / State Machine

如果你的输出质量要求很高

优先选择：

• Reflection
• Evaluator-Optimizer

如果你的任务天然存在分工

优先选择：

• Multi-Agent
• Orchestrator-Workers

如果你的业务风险高

必须考虑：

• Human-in-the-Loop
• 审批、日志、回滚和权限边界

10. 结论

Agent构建，区分三层：

• 基础能力层：LLM + tools + retrieval + memory
• 执行编排层：workflow、single-agent、plan-and-execute、search、reflection
• 协作治理层：multi-agent、graph/state machine、human-in-the-loop

如果只看当前工程实践，最主流、最稳妥的仍然是：

• Workflow
• Single-Agent Loop
• Plan-and-Execute
• Reflection
• Multi-Agent
• Graph / State Machine
• Human-in-the-Loop

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】