第五章 Agent 架构设计

在第四章中，我们系统学习了模型微调（Fine-tuning）技术——从全参数微调到 LoRA、QLoRA 等高效方法，掌握了如何让通用大语言模型适配特定领域和任务。然而，即便模型再强大、微调再精细，它本质上仍是一个"被动应答"系统：你问一句，它答一句，既不会主动规划步骤，也无法在对话过程中调用外部工具，更没有跨会话的记忆能力。

这就像一个博学但被束缚在椅子上的专家——他知识渊博，却无法起身去查资料、打电话或翻阅档案。我们要做的，就是给他"松绑"，赋予他行动力。这就是 Agent（智能体） 的使命。

本章我们将从架构层面，系统讲解 AI Agent 的设计原理。从核心架构模型到规划策略、记忆机制、工具调用，再到多智能体协作，逐一拆解 Agent 的每一块"积木"。让我们从最基础也是最重要的概念开始。

---

5.1 Agent 核心架构：LLM + Planning + Memory + Tools

5.1.1 什么是 AI Agent？

要理解 Agent，不妨先回想一个生活场景：你让一位新来的助理帮你"订一张明天去上海的机票"。

一个只会"问答"的系统会告诉你："您可以通过携程或航司官网预订。"——它回答了问题，但没有解决问题。

而一个真正的**助理（Agent）**会这样做：

1. 确认你的出发城市和偏好（感知与理解）
2. 想想该先做什么：查航班 → 比价格 → 确认时间 → 下单（规划）
3. 记住你上次说过喜欢靠窗座位（记忆）
4. 打开订票系统执行预订（工具调用）
5. 发现价格偏高，换一个时段再查（反思与重试）
6. 最终把订单信息反馈给你

这就是 Agent 的本质：不是回答问题，而是完成任务。

用一句话定义：

AI Agent 是一个能够自主感知环境、制定计划、调用工具执行动作，并从反馈中持续学习与调整的智能系统。

它与普通 LLM 应用的区别，可以用下表清晰对比：

特征	传统 LLM 应用	AI Agent
交互模式	单轮问答，一问一答	多轮自主循环，持续推进
外部工具	无或极少	丰富工具调用（搜索、API、代码执行等）
状态管理	无状态，每次对话从零开始	持续状态跟踪，跨步骤记忆
决策能力	被动响应，用户说什么做什么	主动规划，自己决定下一步
错误处理	无，出错就出错	自我反思，发现错误能重试
目标导向	无明确目标，完成单次回答即终止	目标驱动，直到任务完成

为什么要引入 Agent 这个概念？ 核心原因在于：真实世界的任务很少能靠"一轮对话"解决。一个看似简单的"帮我分析最近一周特斯拉的股价走势并生成报告"，实际上需要获取数据、计算指标、画图、写报告等多个步骤，每一步都可能依赖上一步的结果。没有规划、记忆和工具，LLM 就算再聪明也只能"纸上谈兵"。

5.1.2 四层核心架构

一个成熟的 AI Agent 由四个核心层次组成。如果用人体来类比：

• LLM（推理引擎） —— 大脑，负责理解、推理和决策
• Planning（规划层） —— 前额叶皮层，负责拆解任务、制定策略
• Memory（记忆层） —— 海马体，负责短期工作记忆和长期经验存储
• Tools（工具层） —— 双手和双脚，负责与外部世界交互

四者缺一不可。没有 LLM，Agent 就没有"智能"可言；没有 Planning，它只能做单步反应；没有 Memory，它每次都从零开始，无法积累经验；没有 Tools，它只能"纸上谈兵"，无法改变外部世界。

下面是完整的架构图：

┌─────────────────────────────────────────────────────────┐
│                    用户输入 / 环境感知                     │
└────────────────────────┬────────────────────────────────┘
                         ▼
┌─────────────────────────────────────────────────────────┐
│                   🧠 Planning（规划层）                    │
│  · 任务分解（Task Decomposition）                         │
│  · 路径规划（Path Planning）                              │
│  · 资源分配（Resource Allocation）                        │
│  · 思维框架：CoT / ToT / ReAct                            │
└────────────────────────┬────────────────────────────────┘
                         ▼
┌─────────────────────────────────────────────────────────┐
│                   📝 Memory（记忆层）                      │
│  · 短期记忆：当前对话上下文                                │
│  · 长期记忆：向量数据库持久化知识                           │
│  · 情景记忆：历史交互经验                                  │
│  · 语义记忆：概念与事实知识                                │
└────────────────────────┬────────────────────────────────┘
                         ▼
┌─────────────────────────────────────────────────────────┐
│                   🔧 Tools（工具层）                       │
│  · API 调用（搜索、数据库、文件系统）                       │
│  · 代码执行（Python 沙箱）                                │
│  · 外部服务（日历、邮件、云服务）                           │
│  · 多模态工具（图像生成、语音识别）                         │
└────────────────────────┬────────────────────────────────┘
                         ▼
┌─────────────────────────────────────────────────────────┐
│                   🤖 LLM（推理引擎）                       │
│  · 自然语言理解与生成                                      │
│  · 推理与决策                                             │
│  · 工具选择与参数构造                                      │
│  · 反思与自我修正                                         │
└─────────────────────────────────────────────────────────┘

生活类比：想象你在装修房子。LLM 是你这个"决策者"——你懂设计、会判断；Planning 是你的施工计划表——先拆墙再走水电最后刷漆；Memory 是你的笔记本——记下上次买了什么型号的瓷砖、师傅什么时候来；Tools 是你的工具箱——电钻、扳手、卷尺。你（LLM）拿着计划表（Planning），翻看笔记本（Memory），拿起电钻（Tools），才能把房子装修好。

接下来逐层拆解。

1. LLM（推理引擎）—— Agent 的"大脑"

LLM 是整个架构的核心枢纽。它不是简单的"聊天机器人"，而是承担了四项关键职责：

• 自然语言理解：解析用户的模糊指令。用户说"帮我看看特斯拉最近怎么样"，LLM 要理解"看看"意味着做一份分析报告。
• 推理与决策：判断当前该做什么。是继续搜索？还是已经收集够了信息可以回答了？
• 工具选择与参数构造：决定调用哪个工具，并生成正确的调用参数。比如决定调用股票 API，并构造 {"symbol": "TSLA", "period": "1W"} 这样的参数。
• 反思与自我修正：当工具返回的结果不符合预期时，LLM 要能意识到问题并调整策略。

为什么 LLM 是核心而不是 Tools？ 因为工具本身是"哑"的——搜索引擎不会自己决定该搜什么，计算器不会自己决定该算什么。是 LLM 的推理能力赋予了整个系统"智能"。换个角度说：工具是"手"，但"手"要听"大脑"的指挥。

生活类比：LLM 就像一个全能的项目经理。他不一定亲手敲代码或做设计，但他能理解需求、分配任务、判断结果质量、在出问题时调整方案。没有他，一群工具就是一堆散落的零件，谁也不知道该干什么。

2. Planning（规划层）—— Agent 的"战略参谋"

规划层负责将复杂目标分解为可执行的步骤序列。没有规划层，Agent 面对复杂任务就会"手忙脚乱"——不知道先做什么后做什么，容易陷入局部最优。

举个例子，当用户说"帮我分析最近一周特斯拉的股价走势并生成报告"，规划层需要将其分解为：

1. 获取特斯拉股票代码（TSLA）
2. 调用金融 API 获取最近一周的股价数据
3. 对数据进行分析（计算涨跌幅、均线等）
4. 生成可视化图表
5. 撰写分析报告

为什么要做任务分解？ 因为 LLM 的上下文窗口有限（即便 128K 也有上限），一次性处理太多信息会导致"注意力稀释"——就像让一个人同时做五件事，每件都做不好。分解后每一步聚焦一个小目标，成功率大幅提升。

生活类比：你准备做一桌年夜饭。如果直接开干，很可能手忙脚乱——红烧肉炖糊了、青菜还没洗、汤还没烧。但如果你先列个计划：先炖汤（耗时最长）→ 腌制红烧肉 → 准备蔬菜 → 炒菜 → 最后摆盘，一切就井然有序了。Planning 之于 Agent，就是那张"做菜计划表"。

规划层常用的思维框架包括：

• CoT（Chain of Thought，思维链）：让 LLM 一步一步推理，而非直接给答案
• ToT（Tree of Thoughts，思维树）：在关键决策点生成多条分支路径，选最优
• ReAct（Reasoning + Acting）：推理和行动交替进行，边想边做

这些框架的细节我们将在 5.2 节深入展开。

3. Memory（记忆层）—— Agent 的"经验宝库"

记忆层让 Agent 拥有"记住过去"的能力。没有记忆，Agent 就像电影《记忆碎片》的主角——每次对话都从零开始，无法积累经验，也无法处理需要跨步骤引用中间结果的任务。

记忆层分为四种类型：

记忆类型	对应人类记忆	在 Agent 中的作用	实现方式
短期记忆	工作记忆	当前对话的上下文窗口	LLM 的 context window
长期记忆	长期记忆	跨会话的持久化知识	向量数据库（Chroma、Pinecone 等）
情景记忆	情景记忆	历史交互的具体经验	对话日志的结构化存储
语义记忆	语义记忆	概念与事实知识	知识图谱 / RAG

为什么需要长期记忆？ 短期记忆受限于 LLM 的上下文窗口（如 128K tokens），对话一长，早期的内容就会被"遗忘"。长期记忆通过向量数据库将历史信息持久化，需要时再用检索（RAG）的方式召回相关片段，相当于给 Agent 装了一个"可以随时翻阅的笔记本"。

生活类比：短期记忆就像你打电话时嘴里默念的那个电话号码——挂了电话就忘了。长期记忆就像你的日记本——虽然你不可能把所有日记都背下来，但需要的时候可以翻到某一页找到信息。向量检索就是"翻日记"的过程：你不会逐页翻，而是直接跳到"去年夏天去上海"那一页。

4. Tools（工具层）—— Agent 的"手和脚"

工具层赋予 Agent 与外部世界交互的能力。没有工具，Agent 就像一个被锁在房间里的学者——满腹经纶，却连一杯水都倒不了。

常见的工具类型包括：

• 信息获取类：搜索引擎 API（Google、Bing）、知识库检索、数据库查询
• 计算执行类：Python 沙箱执行、数学计算器、SQL 执行引擎
• 文件操作类：文件读写、PDF 解析、Excel 处理
• 外部服务类：日历管理、邮件发送、云存储、第三方 API
• 多模态类：图像生成（DALL-E、Stable Diffusion）、语音识别（Whisper）、OCR

为什么要让 Agent 使用工具而不是"自己想"？ 因为 LLM 的知识有截止日期，无法获取实时信息；LLM 做数学计算容易出错（尤其是大数运算）；LLM 无法直接操作文件系统或调用外部 API。工具补全了 LLM 的能力边界。

生活类比：你问一个经济学家"今天人民币汇率是多少"，他可能知道大致走势，但给不出精确数字。但如果给他一部手机（工具），让他打开银行 App 查一下，几秒钟就能给你准确答案。工具之于 Agent，就是那部"手机"。

常见误区：工具越多越好

初学者常以为给 Agent 配越多工具越强大。实际上，工具过多会导致两个问题：一是 LLM 在选择工具时更容易"选错"——面对 20 个工具，选择难度远大于面对 5 个；二是每个工具的描述都占用上下文窗口，工具太多会挤占留给推理的空间。实践建议：每个 Agent 配 5-10 个工具为宜，功能相近的工具应该合并。

5.1.3 PEAR 循环：Agent 如何"思考和行动"

了解了四层架构后，一个自然的问题是：这四层是如何协同工作的？答案是 PEAR 循环。

PEAR 是四个阶段的缩写：Perception（感知）→ Execution（执行）→ Analysis（分析）→ Reflection（反思）。它描述了 Agent 完成一个任务步骤的完整思维过程。

      ┌──────────────────────────────────────┐
      │                                      │
      ▼                                      │
┌──────────┐    ┌──────────┐    ┌──────────┐ │
│Perception│───▶│Execution │───▶│ Analysis │ │
│  感知    │    │  执行    │    │  分析    │ │
└──────────┘    └──────────┘    └────┬─────┘ │
                                     │       │
                          ┌──────────▼──┐    │
                          │ Reflection  │────┘
                          │   反思      │
                          └─────────────┘

四个阶段分别做什么？

1. Perception（感知）

Agent 接收输入并理解当前状态。输入可能来自用户（"帮我查一下今天的天气"），也可能来自上一轮工具的返回结果（"北京今天 25°C"）。Agent 需要判断：当前的目标是什么？已经完成了哪些步骤？还差什么？

2. Execution（执行）

根据感知阶段的判断，Agent 决定下一步行动并执行。这通常意味着调用某个工具——搜索、计算、查询数据库等。执行阶段是 Agent 真正"动手"的时刻。

3. Analysis（分析）

执行完成后，Agent 拿到了工具返回的结果。分析阶段要回答：结果是否符合预期？信息是否足够？有没有出现错误？这一步至关重要——它决定了 Agent 是继续推进、还是需要调整策略。

4. Reflection（反思）

这是 PEAR 循环中最有"智能"的一步。Agent 审视整个感知-执行-分析的过程，思考：我的规划是否合理？工具选择是否正确？有没有更好的做法？如果发现问题，反思的结果会指导下一轮循环的感知和规划。

生活类比：你开车去一个陌生的地方。Perception 是你看了看导航和路况——"现在在哪儿，要去哪儿"；Execution 是你踩油门转方向盘——"往前走 500 米右转"；Analysis 是你到了路口发现路被封了——"导航说的路走不通"；Reflection 是你想了想——"那我绕一下走另一条路吧"。然后进入下一轮循环。

PEAR 循环是一个持续迭代的过程。简单任务可能一轮就完成，复杂任务可能需要多轮。每次循环产生的经验（成功或失败），都可以存入记忆系统，供未来类似任务参考。

常见误区：Reflection 等于"重试"

很多人把 Reflection 理解为简单的"再试一次"。实际上，Reflection 的核心不是"重试"而是"改进"。如果只是不加思考地重复同一个动作，那不叫反思，叫"撞墙"。真正的 Reflection 要回答：为什么失败？应该改什么？换个策略还是换个工具？只有带着这些思考进入下一轮，循环才有意义。

5.1.4 经典设计模式

在 Agent 工程实践中，已经形成了几种经典的设计模式。每种模式都有其适用场景和权衡。

1. ReAct（Reasoning + Acting）

ReAct 是最基础也是最广泛使用的 Agent 模式。核心思想很简单：让 Agent 交替进行推理（Reasoning）和行动（Acting）——想一步，做一步，看看结果，再想下一步。

一个典型的 ReAct 执行过程如下：

思考：我需要获取今天的天气数据，但我没有这个信息。我应该调用天气API。
行动：调用 get_weather(city="北京")
观察：API返回 - 北京今天晴，25°C
思考：我已经获取了天气数据，可以直接回答用户了。
最终答案：北京今天天气晴朗，气温25°C。

为什么 ReAct 如此流行？ 因为它最接近人类的自然思维方式。你查资料的时候不会先写一份完整的计划书再去执行，而是"想到什么查什么，查完看看够不够，不够再查"。ReAct 捕捉了这种"边想边做"的直觉。

适用场景：信息检索、问答系统、简单任务执行。当任务不太复杂、步骤不多（通常 3-5 步）时，ReAct 是最佳选择。

常见误区：ReAct 适合所有任务

ReAct 的短板在于它是"走一步看一步"的——没有全局规划。对于需要 10+ 步骤的复杂任务，ReAct 容易在中间步骤"跑偏"：可能第三步走错了方向，但到第七步才发现，白白浪费了四步。对于这类复杂任务，应该使用 Plan-and-Execute 模式。

2. Plan-and-Execute

先制定完整计划，再逐步执行。这种模式将规划和执行分离——先用一个 LLM 调用生成全局计划，再用后续的 LLM 调用逐步执行每个步骤。

规划阶段：
  步骤1：获取特斯拉股票代码
  步骤2：调用金融API获取一周股价数据
  步骤3：计算涨跌幅和均线
  步骤4：生成可视化图表
  步骤5：撰写分析报告

执行阶段：
  执行步骤1 → 完成
  执行步骤2 → 完成
  执行步骤3 → 完成
  ...

优势：全局视角，减少中间步骤的"跑偏"；规划只调用一次 LLM，后续执行步骤更轻量。

劣势：计划可能不适应执行中的变化——如果第二步发现数据源不可用，整个计划可能需要重来。

适用场景：复杂多步骤任务、数据分析报告生成、项目管理类任务。

3. Multi-Agent 协作

将复杂任务分配给多个专业化的 Agent，每个 Agent 负责特定领域，通过通信机制协作完成整体任务。

例如，一个"软件开发"任务可以分配给：

• 产品经理 Agent：负责需求分析和任务拆解
• 程序员 Agent：负责编写代码
• 测试工程师 Agent：负责编写和执行测试
• 代码审查员 Agent：负责审查代码质量

为什么要用多 Agent？ 因为单一 Agent 在上下文窗口有限的情况下，很难同时精通所有领域。就像一个全科医生什么都能看，但复杂病症还是需要专科医生会诊。多 Agent 模式让每个 Agent 聚焦自己的专长。

适用场景：复杂软件工程、科研分析、需要多种专业知识的综合任务。AutoGen、CrewAI 等框架均采用此模式。

常见误区：多 Agent 一定比单 Agent 好

选择模式的标准不是"高级"，而是"适配"。

5.1.5 动手实践：构建一个简单的 Agent

理论讲完了，让我们用 LangChain 构建一个能够搜索信息并回答问题的 Agent，亲手感受四层架构的协作。

# ============================================================
# 导入所需库
# ============================================================
from langchain_openai import ChatOpenAI          # LLM 接口：负责调用大模型
from langchain.agents import create_react_agent, AgentExecutor  # Agent 框架核心
from langchain.tools import Tool                  # 工具定义接口
from langchain_community.tools import DuckDuckGoSearchRun  # 预置的搜索工具
from langchain.prompts import PromptTemplate      # 提示词模板
import os

# ============================================================
# 第 1 步：初始化 LLM（对应架构中的"推理引擎"层）
# ============================================================
# 设置 API 密钥（实际项目中应使用环境变量或密钥管理服务）
os.environ["OPENAI_API_KEY"] = "your-api-key"

# 创建 LLM 实例：
# - model="gpt-4"：使用 GPT-4 模型，推理能力更强
# - temperature=0：温度设为 0，让输出更稳定、确定性更强
#   （Agent 需要可靠的推理，而非创造性发散）
llm = ChatOpenAI(model="gpt-4", temperature=0)

# ============================================================
# 第 2 步：定义工具（对应架构中的"工具层"）
# ============================================================
# 工具 1：互联网搜索——让 Agent 能获取实时信息
search = DuckDuckGoSearchRun()

# 工具 2：数学计算器——让 Agent 能精确计算
def calculate(expression: str) -> str:
    """安全地计算数学表达式"""
    try:
        # eval 执行字符串形式的数学运算，如 "3.14 * 100"
        # 注意：生产环境中应使用 ast.literal_eval 或专用计算库，
        # 避免 eval 带来的安全风险（代码注入）
        return str(eval(expression))
    except Exception as e:
        # 出错时返回错误信息，Agent 可以据此调整策略
        return f"计算错误: {e}"

# 将两个函数包装为 LangChain Tool 对象
# name：工具名称，Agent 通过名称选择工具
# func：实际执行的函数
# description：工具描述，LLM 据此判断何时使用该工具
#   （描述写得好不好，直接影响 Agent 选工具的准确率）
tools = [
    Tool(
        name="Search",
        func=search.run,
        description="用于搜索互联网获取最新信息"
    ),
    Tool(
        name="Calculator",
        func=calculate,
        description="用于执行数学计算，输入数学表达式"
    ),
]

# ============================================================
# 第 3 步：定义 ReAct 提示词（对应架构中的"规划层"）
# ============================================================
# ReAct 提示词告诉 LLM：你有哪些工具，以及应该用
# Thought → Action → Observation 的格式来工作
react_prompt = PromptTemplate.from_template(
    """你是一个有用的AI助手。请使用以下工具来回答问题。

可用工具：
{tools}

工具名称：{tool_names}

使用以下格式：
Question: 需要回答的问题
Thought: 你应该思考要做什么
Action: 要采取的行动，必须是 [{tool_names}] 之一
Action Input: 行动的输入
Observation: 行动的结果
... (这个 Thought/Action/Action Input/Observation 可以重复多次)
Thought: 我现在知道最终答案了
Final Answer: 对原始问题的最终答案

开始！

Question: {input}
Thought: {agent_scratchpad}"""
)

# ============================================================
# 第 4 步：创建 Agent 和执行器
# ============================================================
# create_react_agent：将 LLM、工具和提示词组装成一个 ReAct Agent
agent = create_react_agent(llm=llm, tools=tools, prompt=react_prompt)

# AgentExecutor：Agent 的运行时环境，负责循环执行
# - verbose=True：打印每一步的思考过程（调试时非常有用）
# - handle_parsing_errors=True：LLM 输出格式出错时自动处理
# - max_iterations=5：最多循环 5 次，防止 Agent "死循环"
agent_executor = AgentExecutor(
    agent=agent,
    tools=tools,
    verbose=True,
    handle_parsing_errors=True,
    max_iterations=5,
)

# ============================================================
# 第 5 步：运行 Agent
# ============================================================
# invoke 方法接收一个字典，input 是用户的问题
# Agent 会自动进入 PEAR 循环：感知问题 → 规划步骤
# → 调用工具 → 分析结果 → 反思是否需要继续
result = agent_executor.invoke({
    "input": "2024年诺贝尔物理学奖颁给了谁？请用中文回答。"
})

# 输出最终结果
print(result["output"])

运行后，你会看到类似这样的输出（verbose=True 打印的思考过程）：

> Entering new AgentExecutor chain...
Thought: 用户想知道2024年诺贝尔物理学奖的获奖者，这是一个事实性问题，我需要搜索最新信息。
Action: Search
Action Input: 2024年诺贝尔物理学奖
Observation: 2024年诺贝尔物理学奖授予John Hopfield和Geoffrey Hinton...
Thought: 我已经找到了答案，可以直接回答用户。
Final Answer: 2024年诺贝尔物理学奖授予了John J. Hopfield和Geoffrey E. Hinton，
以表彰他们在人工神经网络和机器学习领域的基础性发现和发明。

> Finished chain.
2024年诺贝尔物理学奖授予了John J. Hopfield和Geoffrey E. Hinton...

你可以清晰地看到 ReAct 模式的运作：Thought（思考）→ Action（行动）→ Observation（观察）→ Thought（再思考）→ Final Answer（最终回答）。这正是一轮完整的 PEAR 循环。

5.1.6 常见误区

在 Agent 开发中，以下误区非常常见，值得特别留意：

误区一：Agent = 套壳 LLM + Function Call

很多人以为接上 Function Calling 就等于做了 Agent。实际上，Function Calling 只是工具调用的一种技术手段，它解决的是"怎么调工具"的问题。而 Agent 还需要规划（先做什么）、记忆（之前做了什么）、反思（做对了没有）。缺少任何一层，都只是"半成品 Agent"。

误区二：Agent 一定能自主完成所有任务

Agent 的"自主性"是有边界的。在当前技术条件下，Agent 在面对高度模糊的指令、需要创造力突破的任务、或涉及安全风险的操作时，仍然需要人类的介入和监督。把 Agent 当成"全自动黑箱"是一种危险的过度信任。实践中，应该在关键步骤设置人工审批（Human-in-the-Loop）。

误区三：max_iterations 越大越好

为了让 Agent"不放弃"，有人把 max_iterations 设到 50 甚至 100。但更多迭代不等于更好结果——如果 Agent 在第 3 步就走错了方向，100 次迭代只会让它在错误的道路上越走越远。更好的做法是设置合理的迭代上限（5-10 次），并在 Agent 超出限制时优雅降级，返回中间结果并提示用户。

误区四：Memory 就是存聊天记录

单纯把所有对话历史塞进上下文窗口不是真正的 Memory。当对话变长，上下文窗口很快就会溢出，而且大量无关信息会干扰 LLM 的注意力。真正的 Memory 设计需要区分短期和长期、需要做信息压缩和检索、需要在"记住什么"和"遗忘什么"之间做权衡。

5.1.7 本节小结

本节我们从零开始，建立了对 AI Agent 的完整认知框架。核心要点回顾：

1. Agent 的本质：不是"回答问题"的问答系统，而是"完成任务"的智能系统。它能够自主感知、规划、执行和反思。

2. 四层架构模型：Agent = LLM（推理引擎，大脑）+ Planning（规划层，战略参谋）+ Memory（记忆层，经验宝库）+ Tools（工具层，手和脚）。四层缺一不可，协同工作。

3. PEAR 循环：Perception（感知）→ Execution（执行）→ Analysis（分析）→ Reflection（反思）是 Agent 持续迭代、自我改进的核心机制。Reflection 的关键不是"重试"而是"改进"。

4. 经典设计模式：ReAct 适合简单任务（边想边做）、Plan-and-Execute 适合复杂任务（先规划后执行）、Multi-Agent 适合需要多种专业知识的综合任务。选择模式的标准是"适配"而非"高级"。

5. 工程实践：LangChain 提供了成熟的 Agent 开发框架，通过 create_react_agent 和 AgentExecutor 即可快速搭建一个具备搜索和计算能力的 Agent。

理解了这些概念，你就掌握了 Agent 设计的"地图"。但地图上标注的每一条路线——CoT、ToT、ReAct 等规划策略具体怎么实现？任务分解有哪些最佳实践？这些问题我们将在下一节深入探讨。

---

下一节预告：在 5.2 节中，我们将深入 Agent 的规划层（Planning），系统讲解思维链（CoT）、思维树（ToT）、ReAct 框式的原理与实现，以及任务分解策略和路径搜索方法。从"知道要规划"到"知道怎么规划好"。