Agent架构设计的三层分类体系与实践
思考
在agent开发浪潮下，经历过知识库构建 rag 图谱，reAct Agent ，openclaw caludecode 企业内部自主规划agent、有明确复杂拓扑限制的Agent，做了这么多在做分析、重构、新任务时，不由的思考这些架构模式有何异同点，随着openclaw harmessagent，langgraph 搭建的拓扑规则会丢掉吗？ 自主规划agent是否会全代替掉有人交互的agent。 因此在做技术重构之前，思考得到了这篇文章， 与当下大多数分析的简单的划分不一样，文章从业务分类到编排模式做了详尽科学的分析。
（市面上大多简单的分为： ReAct 、 plan-execute、Reflection、多agent架构，本事缺少最重要的，AI是效能 从业务上区分好才能真正的理解运用做好技术架构）
考虑到脱敏，本文章仅仅做大致方案，不会去讲述具体如何做企业级落地实际方案～
摘要与主结论
核心结论
-
整体研究方向：将"业务分类"“编排模式”"能力构件"三层拆分解耦，避免抽象层混淆
-
企业级AI应用架构定位：采用人机在环、可中断、可恢复、可审计的workflow方案
-
OpenAI Deep Research 架构定位：核心研究引擎更接近"自主规划类Agent"，但在交互壳层又明显带有人机在环workflow的特征
-
核心主线：结合Anthropic、LangChain、Google Cloud、Microsoft及AWS的官方材料，核心主线均为"先用足够简单的系统，仅在复杂度能带来明确收益时，再升级到更agentic的方案"，避免过度设计
一、术语与分层坐标系
1.1 三层分类体系
| 层级 | 核心问题 | 典型选项 | 作用 |
|---|---|---|---|
| 第一层：交互与控制权 | 谁主导流程？ | 人主导、Agent主导、混合主导 | 业务视角的核心分类依据 |
| 第二层：编排方式 | 流程如何执行？ | 固定流程、动态推理循环、单Agent或多Agent协作 | 工程实现的核心维度 |
| 第三层：能力与治理 | 具备哪些支撑能力？ | 工具调用、记忆、反思、审批、观测、恢复 | 横切能力，可按需组合到不同编排方式中 |
1.2 核心术语对齐
| 术语 | 定义 | 备注 |
|---|---|---|
| Workflow | 预定义代码路径、显式状态与流程约束的系统 | 强调可控性与可审计性 |
| Agent | 模型动态决定流程与工具使用的系统 | 强调自主性与适应性 |
| Agentic Node | 嵌入workflow中的具备局部推理能力的节点 | 平衡可控性与智能性 |
| HITL (Human-in-the-loop) | 人机在环，保留人工介入点的系统 | 确保关键决策可审阅、可接管 |
二、三类业务架构
2.1 自主规划类Agent（Autonomy-First Agent）
定义
以模型自主决策为主、以动态路径为主的Agent，在人类给出目标、工具权限与边界条件后，Agent自主分解问题、选择工具、决定下一步执行动作，核心是"弱流程约束下的自主闭环"。
核心特征
- 控制权：Agent主导，人类仅输入目标、设定边界，不参与中间执行步骤
- 编排方式：动态推理循环，可采用ReAct式的推理—行动循环，或Plan-then-Execute（先规划再执行）变体
- 核心能力：具备自主问题拆分、工具选择、多步骤连贯执行能力，可搭配记忆、反思等横切能力
- 风险点：可控性较弱，易出现推理偏差，缺乏强流程约束，不适用于强合规场景
适配场景
目标模糊、任务周期长且无需强流程约束的场景，例如会议调研、多文档汇总、复杂信息整理、跨部门任务统筹等。
2.2 轻量语义辅助类Agent（语义路由/语义工具助手）
定义
不强调"完整Agent"属性，更接近"tool-augmented assistant"或"语义路由节点"，核心功能是意图识别、槽位抽取、结构化输出、单次工具调用或单轮检索，实现单轮交互闭环。
核心特征
- 控制权：人类主导，需每次输入单一指令，Agent仅负责响应指令，不具备自主决策能力
- 编排方式：单步执行，无复杂流程，采用单轮请求—单轮响应的交互模式
- 核心能力：具备基础语义解析、单次工具调用能力，可按需搭配会话级有限记忆
- 风险点：功能单一，无法承载复杂业务链路，仅能满足简单即时需求
适配场景
简单问答、单一工具查询、短会话交互等场景，例如简单会议信息查询、基础业务咨询、一次性数据检索等。
2.3 人机交互Workflow Agent（人机在环工作流编排系统）
定义
以workflow为核心，内部嵌入agentic节点（如ReAct、planner等），构建用户主导、AI辅助的交互模式，核心价值来自共享状态、interrupt、checkpoint、resume、trace和approval。
核心特征
- 控制权：人类主导，Agent承担辅助执行职责，不突破预设流程边界
- 编排方式：固定流程（预定义路径），可通过StateGraph等机制承载子图与分支，支持流程中断与恢复
- 核心能力：具备上下文记忆、多轮人机穿插交互、操作审计、断点恢复能力，可嵌入agentic节点提升智能辅助水平
- 风险点：自动化程度低于自主规划类Agent，流程固定、灵活度有限，前期需完成完善的流程编排设计
适配场景
企业级强交互、强约束长会话场景，例如审批流程、企业级客服、长周期业务跟进等需多步骤人机穿插操作、且要求流程可控可审计的业务场景。
三、常见Agent模式与能力构件
3.1 编排模式
| 模式 | 核心功能 | 适配场景 |
|---|---|---|
| ReAct | 推理—行动—观察循环，自主规划类Agent中最常见的执行环之一 | 简单任务与即时响应场景 |
| Plan-then-Execute | 先规划后执行，包括Plan-and-Solve、ReWOO等变体 | 复杂、多步骤、长周期任务 |
| Reflection / Evaluator-Optimizer / Critic Loop | 评审—修正循环，通过自我校验与迭代优化输出结果 | 对结果准确性、严谨性要求较高的任务 |
| Hierarchical | 分层智能体架构，上层为总控Agent，下层为子Agent | 超复杂、多领域融合任务 |
| Routing | 语义路由，根据用户意图将任务分发到对应Agent或工具 | 多场景分流 |
| Parallelization | 并行执行多子任务，提升复杂任务处理效率 | 多维度同步分析场景 |
| 顺序工作流/Prompt Chaining | 按预定义顺序执行多步任务，无动态分支 | 简单固定流程 |
| Orchestrator-Workers/Coordinator | 协调者—工作者模式，类似Hierarchical的简化版 | 多子任务协同 |
| Swarm/Collaboration | 多Agent去中心化协作，无明确总控 | 分布式复杂任务 |
| Human-in-the-loop/Custom Logic | 人机在环逻辑，嵌入人工审批、干预节点 | 强合规场景 |
3.2 横切能力
| 能力 | 定义 | 适用场景 |
|---|---|---|
| 工具调用能力 | 接口契约和执行能力 | 所有架构类型 |
| Memory（记忆） | 横切能力，分为短期记忆（会话级）、长期记忆（持久化） | 自主规划类、Workflow类 |
| 观测 | 监控、日志、追踪、调试 | 所有架构类型 |
| 审批 | 人工审阅、审批、接管 | Workflow类（核心） |
| 恢复 | 断点恢复、故障回溯 | Workflow类 |
| 限流、重试 | 流量控制、错误处理 | 所有架构类型 |
3.3 设计原则
组合原则：大多数真实系统都会混合多种模式，组合不是例外，而是常态。
四、企业级AI应用落地架构
4.1 核心定义
企业级AI应用建议定义为：以显式状态图为核心的人机在环工作流系统，内部嵌入局部agentic子图。
这一定义既保留"AI辅助+可控合规"的核心需求，又严格区分workflow与agent的术语边界，避免混淆。
4.2 四层架构设计
| 层级 | 职责 | 核心组件 |
|---|---|---|
| 交互层 | 用户操作入口：点击触发、自然语言补充、暂停/恢复操作、审批确认、结果反馈 | 用户点击节点、自然语言输入节点、流程控制节点 |
| 编排层 | 用StateGraph或类似机制承载子图与分支，定义流程路径、子图触发条件、分支逻辑 | 子图A（确定性工作流）、子图B（Bounded ReAct） |
| 状态层 | 保存全局共享状态：业务数据、筛选条件、执行进度、操作证据和审计日志 | 共享图状态、线程级检查点、可选长期记忆 |
| 工具与治理层 | 工具调用（数据检索、摘要生成、导出等）、治理控制（限流、重试、权限管控、观测回溯） | 工具调用、审批机制、观测系统、回溯能力 |
4.3 子图设计
子图A（点击触发链路）
- 核心功能：点击触发检索、列表刷新、条件筛选
- 工程实现：确定性工作流节点或"受约束工具流"
- 映射模式：顺序工作流/Prompt Chaining + 工具调用能力
子图B（自然语言处理链路）
- 核心功能：处理自然语言意图，如"仅筛选复盘类会议"
- 工程实现：Bounded Planner/Router 或 Bounded ReAct Node
- 映射模式：Routing + Bounded ReAct + Plan-then-Execute（计划机制）
- 特点：明确输入边界、最大工具调用次数、失败回退机制和人工接管边
4.4 状态与记忆管理
表述为"共享图状态 + 线程级检查点 + 可选长期记忆"——LangGraph文档明确区分state、thread、checkpoint、short-term memory、long-term memory，该表述可同时解释中断恢复、多轮交互、故障恢复与审计回放，更贴合工程实现。
五、OpenAI Deep Research架构深度解析
5.1 核心定位与架构特征
OpenAI Deep Research是一个agentic、multi-step、tool-using、planning-heavy、citation-backed的研究系统，核心功能是完成深度研究任务并输出带引用的结构化报告。
5.2 架构分层分析（基于官方公开资料）
5.2.1 官方明确确认的部分（有公开文档支撑）
| 能力维度 | 官方确认内容 | 对应架构模式 |
|---|---|---|
| 核心定位 | agentic、multi-step、tool-using、planning-heavy、citation-backed的研究系统 | 自主规划类Agent核心 |
| 规划能力 | 会先生成结构化研究计划（Research Plan），用户可修改计划、限定可用来源、查看进度并随时打断 | Plan-then-Execute模式 |
| 工具调用 | 在API与产品层，均会自主分解子问题、调用web search、code interpreter、MCP/file search等工具，形成工具调用闭环 | ReAct循环 |
| 交互控制 | ChatGPT产品层包有一层用户控制流程，支持审阅计划、中断执行、重定向任务，带有明显的人机在环特征 | HITL Workflow壳层 |
| 输出特征 | 返回带内联引用的结构化报告，暴露reasoning summary、搜索调用和代码执行等中间步骤，具备基础校验与可追溯能力 | Reflection/Evaluator-Optimizer |
| 优化方式 | 采用与o1相同的强化学习方法，在需要浏览器与Python工具使用的真实任务上进行训练 | 强化学习优化 |
5.2.2 合理推断的部分（有公开线索，无明确官方披露）
| 推断内容 | 推断依据 | 推断结论 |
|---|---|---|
| 多Agent拓扑 | OpenAI的Deep Research cookbook明确演示了single-agent和multi-agent两种research pipeline，且通用Agents文档将多Agent分为manager pattern与decentralized handoff pattern | 多Agent是其支持的工程实现方式之一，但无法确认"ChatGPT产品内部一定恒为多Agent层级架构" |
| 反思能力 | 官方明确提到"会用multi-step reasoning来compare and validate findings，暴露reasoning summary与中间步骤" | 具备回查、比较、校验与修正能力，但无法确认"内部存在命名明确的Reflection node或Critic agent" |
5.2.3 尚未公开的部分（无任何官方文档支撑，需注明边界）
| 未公开内容 | 边界说明 |
|---|---|
| 内部拓扑细节 | ChatGPT产品内部是否固定采用多Agent架构，官方未完整公开 |
| 模块命名 | 内部是否存在显式的"Reflection node""Critic agent"等模块，官方未公开 |
| 记忆实现 | 产品级长期记忆与状态持久化的具体技术实现方式，官方未公开（仅明确"具备stateful/context-managed能力"） |
| 强化学习细节 | 是否采用"端到端多Agent强化学习调优"，官方未公开（仅明确"面向真实任务与工具使用的强化学习"） |
5.3 从OpenAI Deep Research看三类架构的组合应用
5.3.1 架构组合模式
┌─────────────────────────────────────────────────────────────────────────────┐
│ OpenAI Deep Research 架构组合模式 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ 外层：HITL Workflow壳层 │ │
│ │ • 用户可审阅计划、修改计划、限定可用来源 │ │
│ │ • 支持查看进度、随时打断、重定向任务 │ │
│ │ • 明显的人机在环特征 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ 核心层：Autonomy-First Agent │ │
│ │ ┌───────────────────────────────────────────────────────────────┐ │ │
│ │ │ Plan-then-Execute模式 │ │ │
│ │ │ • 先生成结构化研究计划 │ │ │
│ │ │ • 用户可修改计划 │ │ │
│ │ │ • 按计划执行研究任务 │ │ │
│ │ └───────────────────────────────────────────────────────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌───────────────────────────────────────────────────────────────┐ │ │
│ │ │ ReAct循环（工具调用闭环） │ │ │
│ │ │ • 自主分解子问题 │ │ │
│ │ │ • 调用web search、code interpreter、MCP/file search │ │ │
│ │ │ • 形成工具调用闭环 │ │ │
│ │ └───────────────────────────────────────────────────────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌───────────────────────────────────────────────────────────────┐ │ │
│ │ │ Reflection/Evaluator-Optimizer（校验修正） │ │ │
│ │ │ • multi-step reasoning来compare and validate findings │ │ │
│ │ │ • 暴露reasoning summary与中间步骤 │ │ │
│ │ │ • 具备回查、比较、校验与修正能力 │ │ │
│ │ └───────────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
5.3.2 与三类业务架构的映射关系
OpenAI Deep Research体现了三类业务架构可正交组合的特点：
| 层级 | OpenAI Deep Research实现 | 对应架构类型 |
|---|---|---|
| 第一层：交互与控制权 | 外层HITL Workflow壳层，用户可审阅计划、修改计划、限定可用来源、查看进度、随时打断、重定向任务 | 人机在环Workflow类（外层控制） |
| 第二层：编排方式 | 核心层采用Plan-then-Execute + ReAct循环，具备动态推理循环能力 | 自主规划类Agent（核心执行） |
| 第三层：能力与治理 | 工具调用（web search、code interpreter、MCP/file search）、记忆（stateful/context-managed）、反思（multi-step reasoning校验）、观测（暴露reasoning summary与中间步骤） | 横切能力组合 |
关键洞察：OpenAI Deep Research不能粗暴归为"纯自主规划类Agent"，而是"自主规划核心 + 人机在环控制"的混合形态。
5.4 从OpenAI Deep Research学习架构设计原则
5.4.1 渐进复杂度原则
OpenAI Deep Research的设计体现了"先用足够简单的系统，只有在复杂度能带来明确收益时，再升级到更agentic的方案"的核心原则：
| 复杂度层级 | 适用场景 | OpenAI Deep Research体现 |
|---|---|---|
| 单Agent/单调用 | 简单查询、基础咨询 | 基础ChatGPT对话 |
| Workflow系统 | 强约束、强审计、多轮交互 | Deep Research外层HITL Workflow |
| 多Agent协作 | 超复杂、多领域融合任务 | Deep Research核心层（推断） |
5.4.2 人机在环的价值
OpenAI Deep Research在产品层明确加入人机在环控制，这给我们重要启示：
- 可控性优先：即使核心是自主规划Agent，也要保留人工介入点
- 透明度关键：暴露reasoning summary与中间步骤，让用户理解AI决策过程
- 灵活性重要：支持用户修改计划、限定可用来源、随时打断、重定向任务
5.4.3 组合而非例外
OpenAI Deep Research的设计证明了"组合不是例外，而是常态"：
- Plan-then-Execute + ReAct循环
- 自主规划核心 + 人机在环控制
- 工具调用 + 记忆 + 反思 + 观测
5.5 精简表述
OpenAI Deep Research ≈ agentic deep-research model + 规划与分解 + 工具调用闭环 + 来源比较/校验 + 引用化报告输出；在ChatGPT产品层又包了一层可审阅计划、可中断的用户控制流程。它的工程实现可以是单Agent，也可以扩展成多Agent流水线，但官方并未完整公开ChatGPT内部的唯一拓扑。
六、选型原则与演进路线
6.1 核心选型原则
渐进复杂度原则：先用足够简单的系统，只有在复杂度确实带来收益时再升级到更 agentic 的方案。
6.2 决策树
┌─────────────────────────────────────────────────────────────────────────────┐
│ Agent架构选型决策树 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 开始：明确业务需求 │
│ │ │
│ ▼ │
│ 是否需要强合规、强审计？ │
│ │ │
│ ├── 是 ──→ 是否需要多轮人机交互？ │
│ │ │ │
│ │ ├── 是 ──→ 🎯 人机在环Workflow系统 │
│ │ │ （审批流程、企业级客服） │
│ │ │ │
│ │ └── 否 ──→ 考虑其他方案 │
│ │ │
│ └── 否 ──→ 任务复杂度如何？ │
│ │ │
│ ├── 复杂长周期 ──→ 🎯 自主规划类Agent │
│ │ （会议调研、多文档汇总、复杂信息整理） │
│ │ │
│ └── 简单单次 ──→ 🎯 语义路由/工具助手 │
│ （简单查询、基础咨询、一次性检索） │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
6.3 演进路线
┌─────────────────────────────────────────────────────────────────────────────┐
│ Agent架构演进路线 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 阶段1：单Agent/单调用 │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ 工具调用 + 简单推理 │ │
│ │ 适用：简单查询、基础咨询、一次性检索 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ 阶段2：Workflow系统 │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ 显式状态图 + 人机在环 + 可审计可追溯 │ │
│ │ 适用：审批流程、企业级客服、长周期业务跟进 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ 阶段3：多Agent协作（仅在复杂度确实带来收益时） │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Orchestrator-Workers + Hierarchical + 复杂编排 │ │
│ │ 适用：超复杂、多领域融合任务 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
七、开放问题与边界
7.1 关于OpenAI Deep Research的边界
公开资料更强调的是能力、接口、控制方式与输出形态，而不是内部唯一拓扑。
因此，最终文档最稳妥的写法不是"我断定它内部就是某种单一架构"，而是"根据官方公开能力与工程范式，它最接近哪类架构、由哪些模式组合而成、哪些部分是已确认事实、哪些只是高概率推断"。
这样既严谨，也最适合企业内部评审、方案汇报和对外讲解。
八、最终核心原则
- 术语严谨：严格区分workflow与agent，不混淆编排模式、横切能力、拓扑结构的抽象层
- 表述稳妥：避免绝对化判断，对未公开信息明确区分"推断"与"事实"，主动注明研究边界
- 落地导向：架构设计与分类均贴合企业工程实践，优先"简单可用"，再考虑"复杂升级"，避免过度设计
- 逻辑清晰：按"控制权—编排方式—能力构件"分层，让三类业务架构、模式库、落地方案的逻辑闭环，无矛盾点
- 组合思维：大多数真实系统都会混合多种模式，组合不是例外，而是常态（参考OpenAI Deep Research）
总结
核心要点
- 分层思维：把"业务分类"“编排模式”"能力构件"三层拆开写，避免混淆不同抽象层
- 术语对齐：workflow与agent是两个不同概念，前者强调可控性，后者强调自主性
- 渐进复杂度：先用足够简单的系统，只有在复杂度确实带来收益时再升级到更agentic的方案
- 严谨表述：区分"官方确认"“合理推断”"尚未公开"三层，避免把推断写成事实
- 组合原则：参考OpenAI Deep Research的设计，大多数真实系统都会混合多种模式，组合不是例外，而是常态
企业级AI应用架构定位
企业级AI应用是"以显式状态图为核心的人机在环工作流系统，内部嵌入局部agentic子图"，对当前强约束、强审计、多轮交互场景更适配。
OpenAI Deep Research架构启示
OpenAI Deep Research的核心研究引擎更接近"自主规划类Agent"，但在交互壳层又明显带有人机在环workflow的特征，体现了"自主规划核心 + 人机在环控制"的混合形态，这为我们的架构设计提供了重要参考。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
9
0- 0
已为社区贡献6条内容
所有评论(0)