Agent 架构模式

日期：2026-06-05
主题：Agent 架构模式
进度：16/40 概念

---

一、ReAct（Reasoning + Acting）

核心思想

推理 + 行动循环。每一步先想（Thought），再做（Action），看结果（Observation），然后决定下一步。

循环流程

用户输入 → Thought → Action → Observation → 问题解决了吗？
                                        ├─ 没有 → 回到 Thought
                                        └─ 是 → Final Answer

完整示例

用户问：“帮我查北京明天天气，如果下雨提醒带伞”

Thought 1：需要查北京明天天气，先调天气API。
Action 1：get_weather(city="北京", date="明天")
Observation 1：{"weather": "小雨", "temp": "18-24°C"}

Thought 2：天气返回"小雨"，用户需要带伞提醒。任务完成。
Final Answer：北京明天有小雨，18-24°C，记得带伞！

代码实现要点

def react_agent(user_input, max_steps=5):
    messages = [system_prompt, user_input]

    for step in range(max_steps):
        response = call_llm(messages)           # 1. 调用 LLM

        if "Final Answer:" in response:         # 2. 检查终止条件
            return extract_final_answer(response)

        action, input = parse_action(response)  # 3. 解析 Action
        observation = tools[action](**input)    # 4. 执行工具

        messages.append(response)               # 5. 追加结果，继续循环
        messages.append(f"Observation: {observation}")

关键设计

设计点 说明 Thought 让模型”想清楚再动手”，减少盲目调工具 循环上限 必须设 max_steps，防止死循环 Observation 注入 工具结果以 Observation 形式喂回模型 终止条件 输出 Final Answer 或达到步骤上限

局限

• 短视：每步只看当前，没有全局规划
• 容易跑偏：中间步骤可能偏离目标
• 步骤越多越不可靠：超过 5-7 步质量明显下降

适用场景

简单到中等复杂度的任务（≤3 步）

---

二、Plan-and-Execute

核心思想

先规划全局计划，再逐步执行。解决 ReAct 短视的问题。

流程

用户输入 → Planner（生成完整计划） → Plan（任务列表）
    → Executor（逐步执行） → 检查是否需要重新规划 → 最终结果

与 ReAct 的对比

维度 ReAct Plan-and-Execute 规划 没有，走一步看一步 先出完整计划 适合任务 简单（2-3步） 复杂（5+步） 灵活性 高——随时调整 中——可以重新规划 可控性 低——容易跑偏 高——计划可审查

关键特性：Replanning

执行过程中可能发现计划需要调整：

执行步骤3时发现搜索结果不准确
→ 触发 Replanning
→ 用更精确的关键词重新搜索，后续步骤调整

适用场景

• 任务步骤 ≥ 5 步
• 目标明确，可以提前列出所有步骤
• 需要可审查、可追踪的执行过程

---

三、Reflexion

核心思想

执行 + 反思 + 重试。Agent 完成任务后自我审查，分析哪里做得不好，下次改进。

流程

用户输入 → Actor（执行）→ Evaluator（评估）→ 达标？
    ├─ 是 → 输出结果
    └─ 否 → Reflector（反思）→ Memory（记录改进）→ 回到 Actor 重试

三种角色

角色 职责 实现方式 Actor 执行任务 LLM 生成代码/调用工具 Evaluator 判断结果是否正确 运行测试 / LLM 自评 / 人工反馈 Reflector 分析失败原因 LLM 分析错误，生成改进建议

示例：代码生成 + 自我修正

第1轮：
  代码：sorted(nums)[-2]
  评估：❌ 输入[5,5,5]时返回5，应该返回None
  反思：没有处理重复元素，需要先去重

第2轮（带着反思）：
  代码：sorted(set(nums))[-2]
  评估：✅ 通过

Reflexion vs 简单重试

简单重试 Reflexion 方式 相同输入再来一次 带着”上次错在哪”的反思重试 效果 可能重复同样的错误 避免犯同样的错 类比 裸考再考一次 分析错题后再考

Reflector 输出模板

好的反思包含三部分：

1. 问题诊断：错在哪，可能的原因
2. 改进方案：下次遇到同类问题怎么做
3. 优先级：先试哪个方案

限制

• 成本高：每轮反思都是额外的 LLM 调用
• 可能死循环：反思质量差可能越改越差
• 需要好的 Evaluator：评估不准，反思也没用
• 通常限制重试 2-3 次

适用场景

需要质量把关的任务：代码生成、数据处理、文本生成等

---

四、多步推理与任务分解

为什么要分解

LLM 推理能力随步骤数衰减：

• 1-3 步：准确率 90%+
• 5-7 步：准确率 70%
• 10+ 步：准确率 < 50%

解法：把一个 10 步的大任务，拆成 3 个 3 步的小任务。

三种分解策略

① 按功能分解

各部分相对独立，可并行。

竞品分析报告
├── 子任务1：数据收集
├── 子任务2：数据分析
└── 子任务3：报告撰写

② 按数据/对象分解

同一逻辑对多个对象执行，最适合并行。

分析 10 个城市销售数据
├── 子任务1：分析北京
├── 子任务2：分析上海
├── ...
└── 汇总：对比各城市

③ 按步骤链分解

前后有依赖，必须串行。

CSV 清洗导入
├── 步骤1：读取 CSV
├── 步骤2：识别质量问题
├── 步骤3：制定清洗策略
├── 步骤4：执行清洗
├── 步骤5：验证结果
└── 步骤6：导入数据库

选择策略

策略 适用场景 特点 按功能 各部分相对独立 可并行，互不依赖 按数据 同一逻辑对多个对象执行 最适合并行处理 按步骤 前后有依赖关系 必须串行，顺序重要

黄金法则

每个子任务应该能用一次 LLM 调用完成。
如果一个子任务还需要多次 LLM 调用，说明它还可以继续拆。

分解的常见错误

错误 例子 正确做法 粒度太粗 “完成竞品分析” 拆成收集、分析、撰写 粒度太细 “打开浏览器”→“输入URL” 合并为”搜索竞品信息” 遗漏依赖 先写报告再收集数据 明确先后顺序 子任务不完整 只拆主流程 加上异常处理分支

---

五、架构选择指南

决策树

任务步骤 ≤ 3 步？
├─ 是 → ReAct
└─ 否 → 任务步骤 ≥ 5 步且目标明确？
         ├─ 是 → Plan-and-Execute
         └─ 否 → ReAct（边做边看）

需要质量把关？
├─ 是 → 在上面的架构外加一层 Reflexion
└─ 否 → 直接执行

任务很复杂？
└─ 先做任务分解，再对每个子任务选架构

架构组合原则

架构不是单选题，是组合题。

• Plan-and-Execute 管”怎么做”——分解任务、有序执行
• Reflexion 管”做得好不好”——质量把关、迭代改进
• ReAct 管”简单直接”——低开销快速完成

实际开发中，大部分 Agent 都是多架构组合。

---

六、Day 3 核心认知总结

1. ReAct 是最基础的架构：Thought→Action→Observation 循环，简单但容易短视
2. Plan-and-Execute 解决短视问题：先规划再执行，适合复杂任务
3. Reflexion 解决质量问题：执行→评估→反思→重试，避免重复犯错
4. 任务分解是所有架构的基础：大任务拆成小任务，每步控制在一次 LLM 调用
5. 架构是组合题：实际开发中多种架构组合使用

‍