AI Agent 技术概念分层体系

引言

本文用于厘清 AI Agent 领域的技术概念分层，避免将”实现手段”、“架构模块”、“设计范式”和”系统形态”混淆。

在快速发展的 AI Agent 领域，各种术语和概念层出不穷，工程师和研究人员往往难以准确把握不同概念之间的层次关系和依赖关系。

通过建立清晰的四层架构模型，本文旨在帮助读者：

• 理解各层概念的边界与联系
• 正确选择技术方案
• 避免常见的设计误区
• 建立系统化的知识体系

四层架构总览

关键原则：上层依赖下层，下层支撑上层。

四层架构的核心思想是将复杂的 Agent 系统分解为相互依赖、职责分明的层次。每一层解决不同层面的问题，上层构建在下层的基础之上，形成清晰的技术栈。

Level 1: 工程基础（Agent的”支撑技术”）

注意：这些是实现手段，不是 Agent 的组成部分。

工程基础层提供了构建 Agent 所需的底层技术能力。这些技术本身并不构成 Agent 的架构模块，而是作为支撑手段，驱动和增强上层模块的功能实现。

Level 2: 核心架构模块（Agent的”器官”）

模块间数据流

用户输入 → Memory检索 → Planning决策 → Action执行 → Tool调用 →
环境交互 → 观察反馈 → Memory更新 → Planning反思 → 继续/终止

Memory 三层结构（认知科学对齐）

Memory 体系
├── 工作记忆 (Working Memory)
│   └── 当前对话轮次、即时上下文
├── 短期记忆 (Short-term Memory)
│   └── 多轮对话历史（Context Window）
└── 长期记忆 (Long-term Memory)
    ├── 语义记忆 - 知识库、事实（RAG/Vector DB）
    ├── 情景记忆 - 过往任务轨迹（经验回放）
    └── 程序记忆 - 技能、工作流模式（Few-shot示例库）

Level 3: 实现范式（Agent的”思维模式”）

定义 Agent 如何循环往复地使用 L2 模块完成任务

重要区分：

• ReAct 不是模块，而是一种循环工作流：它定义了 Planning 和 Action 如何交替运行。
• CoT 不是架构，而是一种推理风格：它改变了 Planning 的思考方式。

新兴/进阶范式

Level 4: 系统形态（Agent的”组织形式”）

Multi-Agent 的本质不是创造新的模块，而是将多个 L2 Single-Agent 通过 L3 范式（通常是 ReAct 或对话循环）组织起来，并引入 共享 Memory 和 协作协议。

架构关系与数据流

四层架构预览图

flowchart TD
    subgraph L1 ["L1: 工程基础"]
        pe[Prompt Engineering]
        rag[RAG增强]
        fc[Function Calling]
        so[Structured Output]
    end

    subgraph L2 ["L2: 核心模块"]
        plan[Planning规划]
        mem[Memory记忆]
        tool[Tool Use工具]
        act[Action行动]
    end

    subgraph L3 ["L3: 实现范式"]
        react[ReAct循环]
        cot[CoT推理]
        tot[ToT树搜索]
        reflect[Reflection反思]
    end

    subgraph L4 ["L4: 系统形态"]
        single[Single-Agent]
        multi[Multi-Agent协作层<br/>（含多个Single-Agent）]
    end

    %% 支撑关系（虚线：技术支撑）
    pe -.-> plan
    pe -.-> mem
    pe -.-> tool
    rag -.-> mem
    fc -.-> tool
    so -.-> act

    %% 模块内部（实线：数据流）
    plan --> act
    mem <--> plan
    tool --> act

    %% 范式应用（箭头：定义工作流）
    react -.->|使用| plan
    react -.->|触发| act
    react -.->|调用| tool
    cot -.->|优化| plan
    tot -.->|扩展| plan
    reflect -.->|增强| plan

    %% 系统构建（粗线：基于下层构建）
    react ==> single
    single ==> multi

    style L1 fill:#e3f2fd,stroke:#1565c0
    style L2 fill:#e8f5e9,stroke:#2e7d32
    style L3 fill:#fff3e0,stroke:#ef6c00
    style L4 fill:#f3e5f5,stroke:#6a1b9a

模块间数据流

flowchart LR
    Input[用户输入]
    Plan[Planning规划]
    Mem[Memory记忆]
    Tool[Tool Use工具]
    Action[Action行动]
    Output[输出结果]

    Input --> Plan
    Plan --> Mem
    Mem --> Plan
    Plan --> Action
    Action --> Tool
    Tool --> Action
    Action --> Output

    Action -->|观察反馈| Plan

ReAct 循环工作流

sequenceDiagram
    participant User as 用户
    participant Plan as Planning
    participant Mem as Memory
    participant Tool as Tool Use
    participant Act as Action

    loop ReAct循环
        User->>Plan: 任务/观察
        Plan->>Mem: 检索记忆
        Mem-->>Plan: 返回上下文

        Note over Plan: Thought思考
        Plan->>Act: 决策
        Act->>Tool: 调用工具
        Tool-->>Act: 结果
        Act-->>Plan: 观察反馈

        Note over Plan: 继续或终止
    end

    Plan-->>User: 最终答案

常见误区

技术选型决策树

当你需要设计一个Agent系统时，按此顺序决策：

1. 选择系统形态 (L4)

• 任务单一明确？→ Single-Agent
• 需要多领域协作？→ Multi-Agent

2. 选择实现范式 (L3)

• 需要频繁工具交互？→ ReAct
• 纯逻辑推理？→ CoT/ToT
• 任务步骤可预先确定？→ Plan-and-Solve
• 需要探索不同工具调用策略？→ LATS
• 性能敏感？→ ReWOO

3. 设计核心模块 (L2)

• 需要外部数据？→ 配置 RAG 增强 Memory
• 需要计算/搜索？→ 配置 Tool Use 清单
• 容易出错？→ 在 Planning 中加入 Reflection 机制

4. 优化工程实现 (L1)

• 效果不佳？→ 优化 Prompt Engineering
• 领域知识不足？→ 引入 RAG
• 需要稳定行为？→ 考虑 Fine-tuning

工作流模式: ReAct 与其他

工作流分类

所有模式按两个维度分类：

各模式详细规格

CoT (Chain-of-Thought) —— 基础推理链

全称：Chain-of-Thought（思维链）

机制：通过提示词引导模型生成中间推理步骤，再得出最终答案

流程：输入 → 步骤1推理 → 步骤2推理 → ... → 最终答案

适用场景：

• 数学计算、逻辑推理
• 文本分析、因果推断
• 需要可解释性的简单决策

优点：

• 实现简单（仅需提示词工程）
• 延迟低（单次调用）
• 可解释性强（展示思考过程）

局限：

• 无法调用外部工具（闭卷考试）
• 错误无法修正（一错到底）
• 复杂多步骤任务容易中间跑偏

ReAct (Reasoning + Acting) —— 标准循环

机制：推理与行动交替循环，每步思考后决定下一步行动（工具调用或输出）

标准循环：Thought(思考) → Action(行动/工具调用) → Observation(观察结果) → 重复

适用场景：

• 需要实时数据的问答（搜索、数据库查询）
• 多步骤工具协作（查天气→算路线→订酒店）
• 动态决策（根据中间结果调整策略）

优点：

• 灵活应对不确定性（根据观察调整）
• 可集成任意工具（Function Calling）
• 错误可恢复（观察失败后可重试）

局限：

• 延迟高（多轮 LLM 调用）
• Token 消耗大（每轮都要生成 Thought）
• 可能陷入循环（需设置最大迭代次数）

ToT (Tree-of-Thoughts) —— 树状探索

机制：将推理建模为树搜索，每个节点是一个思维状态，可生成多个候选分支，通过评估函数选择最优路径

流程：

初始状态
  ├─ 候选思路A → 评估得分 0.8 → 继续展开
  ├─ 候选思路B → 评估得分 0.3 → 剪枝
  └─ 候选思路C → 评估得分 0.9 → 最优路径深入

适用场景：

• 创意写作（多版本对比）
• 游戏策略（棋类、谜题）
• 复杂规划（任务分解方案选择）
• 数学证明（多种证明路径探索）

优点：

• 突破局部最优（探索多种可能性）
• 适合创造性任务（头脑风暴模式）
• 可结合搜索算法（BFS/DFS/Beam Search）

局限：

• 成本极高（指数级 Token 增长）
• 延迟不可控（并行探索耗时）
• 需要设计评估标准（Heuristic 函数难定义）

Reflection / Reflexion —— 自我修正

机制：显式增加自我批评环节，生成初稿后由模型自身或独立评估器检查错误，然后修正

两阶段流程：

生成阶段：输入 → 生成初始答案
↓
反思阶段：输入 + 答案 → 评估错误 → 修正建议
↓
修正阶段：输入 + 原答案 + 建议 → 生成优化版本

适用场景：

• 代码生成（生成→测试→Debug→修复）
• 长文写作（初稿→审核→润色）
• 数据验证（计算结果→校验→修正）
• 医学/法律等高风险决策（多重检查）

优点：

• 显著提升准确率（尤其逻辑错误）
• 可独立于主流程（外挂审核模块）
• 可迭代多轮（直到通过验证）

局限：

• 至少 2-3 倍 Token 消耗
• 延迟翻倍（串行执行）
• 模型可能”过度修正”（把对的改错）

变体：

• Self-Refine：单模型自我修正
• Reflexion：结合外部反馈（如代码执行错误信息）
• Verification：独立验证器模型（Verifier + Generator）

Plan-and-Solve —— 先规划后执行

机制：分离规划与执行，先一次性生成完整执行计划（步骤清单），再严格按计划逐步执行，中间不再重新规划

流程：

规划阶段：任务 → 生成步骤清单 [步骤1, 步骤2, 步骤3]
↓
执行阶段：按清单顺序执行（可并行或串行）
↓
汇总输出：整合各步骤结果

适用场景：

• 标准化流程（数据分析、ETL、报表生成）
• 步骤明确且稳定的任务（编译代码、部署流程）
• 需要可预测执行时间的生产环境

优点：

• 执行效率高（减少重复推理开销）
• 可预测性强（提前知道需要哪些工具）
• 便于人工审核（计划阶段可人工干预）

局限：

• 缺乏灵活性（计划错误则全盘失败）
• 无法应对动态变化（如某步骤返回异常）
• 依赖前期规划质量（规划错误无法挽回）

LATS (Language Agent Tree Search) —— 混合搜索

机制：ToT + ReAct 的融合，在树搜索的节点上执行 ReAct 循环，既有多路径探索，又有深度工具交互

结构：

根节点：初始任务
  ├─ 分支1（策略A）：ReAct循环深入 → 评估结果
  ├─ 分支2（策略B）：ReAct循环深入 → 评估结果
  └─ 分支3（策略C）：ReAct循环深入 → 评估结果
              ↓
         选择最优分支结果

适用场景：

• 复杂工具调用策略选择（先用搜索还是直接查API？）
• 多步骤任务的不同执行路径对比
• 自动驾驶、机器人规划（物理世界交互+策略选择）

优点：

• 结合探索与执行（既有广度又有深度）
• 适合复杂决策空间

局限：

• 实现复杂度高
• 资源消耗巨大（ToT 的广度 × ReAct 的深度）

对比决策矩阵

选型决策树

开始
│
├─ 是否需要调用外部工具/API/数据库？
│  ├─ 否 → 进入"纯推理分支"
│  │       ├─ 是否需要探索多种解决方案？→ 是 → ToT
│  │       └─ 否 → CoT（简单任务）或 Reflection（需要高质量）
│  │
│  └─ 是 → 进入"工具交互分支"
│          ├─ 任务步骤是否可预先完全确定？
│          │  ├─ 是 → Plan-and-Solve（追求效率）
│          │  └─ 否 → ReAct（追求灵活性）
│          │
│          └─ 是否需要探索不同工具调用策略？
│             ├─ 是 → LATS（复杂策略搜索）
│             └─ 否 → ReAct + Reflection（质量优先）
│                 └─ 性能敏感？→ 改用 ReWOO