AI Agent 架构设计与实践：React、Plan-Exec、Reflect 与混合模式(附开源代码)

这是一篇写给 AI Agent 初学者的技术博客。目标不是"背概念"，而是帮你真正建立一个判断框架：面对一个任务时，到底该让 Agent 直接行动、先规划再执行、边做边反思，还是采用混合架构？

如果你正在学习 AI Agent 开发，希望把"看起来很厉害的 Agent"拆成可实现、可落地、可调试的工程结构，这篇文章会很适合你。

---

1. 为什么大家都在聊 AI Agent 架构？

很多人第一次做 AI 应用，通常会从下面这个模式开始：

用户提问 -> LLM 生成答案 -> 返回结果

这类应用当然有价值，但它还不算真正意义上的 Agent。

因为一个真正的 Agent，通常不只是"回答问题"，而是要完成任务。比如：

• 帮你查询资料并总结
• 帮你调用工具读写文件
• 帮你拆解一个复杂需求并逐步执行
• 帮你检查自己的结果并修正错误
• 帮你根据上下文和记忆持续推进长期任务

这时候，问题就不再是"提示词怎么写"，而变成：

这个 Agent 应该如何思考、如何行动、如何调用工具、如何在失败后恢复？

这就是 Agent 架构模式存在的意义。

2. 什么是 Agent？它和普通聊天机器人有什么不同？

一个非常实用的理解方式是：

普通聊天机器人

核心能力是：

• 理解输入
• 生成文本

AI Agent

核心能力是：

• 理解目标
• 拆解任务
• 使用工具
• 获取环境反馈
• 根据反馈继续行动
• 必要时修正自己

也就是说，Agent 本质上是一个带闭环的决策系统。

可以把它抽象成下面这张图：

flowchart LR U[用户目标] --> A[Agent] A --> T[工具 / API / 数据库 / 文件系统] T --> O[观察结果 Observation] O --> A A --> R[最终结果]

在这个闭环里，LLM 不再只是"回答器"，而是扮演：

• 决策器
• 规划器
• 工具调用协调器
• 结果评估器

---

3. Agent 的核心运行闭环

无论你选择 React、Plan-Exec、Reflect 还是混合模式，底层几乎都绕不开这几个步骤：

1. 理解任务：用户到底想解决什么问题？
2. 判断策略：一次回答就够，还是要多步执行？
3. 调用工具：要不要访问搜索、数据库、代码执行器、文件系统？
4. 读取反馈：工具返回了什么？成功还是失败？
5. 继续推进：下一步做什么？
6. 输出结果：给用户一个最终可用的答案

常见闭环如下：

flowchart TD A[接收用户请求] --> B[分析任务复杂度] B --> C{是否需要多步执行?} C -- 否 --> D[直接推理 / 单轮工具调用] C -- 是 --> E[规划或迭代执行] D --> F[输出结果] E --> G[获取反馈] G --> H{是否达成目标?} H -- 否 --> E H -- 是 --> F

理解了这个闭环，再去看不同架构模式，就不会只停留在"名词记忆"层面。

---

4. React 模式：最经典、最实用的 Agent 工作流

注意：这里的 React 不是前端框架，而是 Reason + Act，即"推理 + 行动"。

React 模式的核心思想是：

1. 先思考当前要做什么
2. 选择一个动作（通常是调用某个工具）
3. 获取观察结果
4. 再思考下一步
5. 循环，直到任务完成

4.1 React 的工作流图

flowchart TD Q[用户问题] --> T1[Thought 思考] T1 --> A1[Action 执行动作] A1 --> O1[Observation 观察结果] O1 --> T2[Thought 再次思考] T2 --> A2[Action 再执行] A2 --> O2[Observation 新结果] O2 --> F[Final Answer 最终答案]

4.2 React 为什么流行？

因为它足够自然，几乎符合人类做事的直觉：

• 不需要先把全局计划想得特别完美
• 每做一步都根据反馈调整
• 特别适合外部环境不确定的任务

例如：

• 搜索资料
• 查询数据库
• 调用多个 API
• 逐步排查问题
• 代码分析与调试

4.3 React 的伪代码

async function reactAgent(userInput, tools, llm) {
  const messages = [{ role: 'user', content: userInput }];

  for (let i = 0; i < 8; i++) {
    const response = await llm.invoke(messages);

    if (response.type === 'final') {
      return response.content;
    }

    if (response.type === 'tool_call') {
      const toolResult = await tools[response.toolName](response.args);

      messages.push({
        role: 'assistant',
        content: `调用工具: ${response.toolName}`,
      });

      messages.push({
        role: 'tool',
        content: JSON.stringify(toolResult),
      });
    }
  }

  throw new Error('超过最大迭代次数，任务未完成');
}

4.4 React 的优点

• 实现简单，适合新手入门
• 对动态任务很友好
• 容易和工具系统结合
• 工程上可解释性较强，可以看到每轮 Thought / Action / Observation

4.5 React 的缺点

• 容易"走一步看一步"，全局性不足
• 复杂任务上可能来回试探，成本偏高
• 如果缺少终止条件，容易陷入无效循环
• 对 Prompt、工具定义、错误恢复比较敏感

4.6 React 模式适合什么场景？

非常适合：

• FAQ + 工具调用
• 助手型应用
• 客服 Agent
• 调试型 Agent
• 文件 / 数据查询型 Agent

如果你的 Agent 目标是：先做一个能跑起来的多工具智能体，React 往往是第一选择。

---

5. Plan-Exec 模式：先想清楚，再一步步做

Plan-Exec 模式的核心思想是：

1. 先生成一个执行计划
2. 再按计划逐步执行
3. 执行中可以根据反馈局部调整
4. 最终汇总结果

它很像一个项目经理先列 todo，再安排执行。

5.1 Plan-Exec 的工作流图

flowchart TD U[用户任务] --> P[Plan 生成执行计划] P --> S1[Step 1 执行] S1 --> S2[Step 2 执行] S2 --> S3[Step 3 执行] S3 --> C[汇总结果] C --> R[最终输出]

5.2 什么时候 React 不够用了？

当任务具有明显的多阶段结构时，React 容易显得"短视"。

例如：

• 写一份行业调研报告
• 构建一个多文件代码修改方案
• 先检索资料，再比较，再总结，再输出 PPT 大纲
• 做一个复杂数据分析流程

这类任务如果不提前规划，Agent 很容易：

• 执行顺序混乱
• 重复调用工具
• 漏掉关键步骤
• 在中间步骤偏题

5.3 Plan-Exec 的伪代码

async function planExecAgent(userInput, planner, executor) {
  const plan = await planner(userInput);

  const results = [];
  for (const step of plan.steps) {
    const stepResult = await executor(step, results);
    results.push({ step: step.title, result: stepResult });
  }

  return {
    plan,
    results,
    summary: await summarizeResults(plan, results),
  };
}

5.4 一个典型的计划结构

{
  "task_summary": "完成一篇关于 AI Agent 架构模式的技术博客",
  "steps": [
    {
      "step_id": 1,
      "description": "梳理 React、Plan-Exec、Reflect 的定义与应用场景",
      "depends_on": []
    },
    {
      "step_id": 2,
      "description": "设计对比表和架构图",
      "depends_on": [1]
    },
    {
      "step_id": 3,
      "description": "撰写面向新手的代码示例与实战建议",
      "depends_on": [1, 2]
    }
  ]
}

5.5 Plan-Exec 的优点

• 适合复杂任务和长任务
• 全局结构更清晰
• 更容易控制执行顺序
• 更适合做成本管理和步骤可视化

5.6 Plan-Exec 的缺点

• 计划本身可能不准
• 如果环境变化快，初始计划可能过时
• 实现成本高于 React
• 需要额外考虑"计划失败后如何重规划"

5.7 适用场景

• 长流程任务
• 多阶段内容生成
• 多文件代码处理
• 分析、调研、报告类任务
• 工作流自动化场景 -

---

6. Reflect 模式：做完一轮，还会自我复盘

Reflect 模式可以理解为：

Agent 不只会做事，还会检查自己做得对不对。

它通常会在一个阶段完成后，增加一个"反思 / 评估 / 自检"步骤。

6.1 Reflect 工作流图

flowchart TD U[用户任务] --> G[生成初稿 / 执行结果] G --> E[Reflect 评估与反思] E --> J{结果是否达标?} J -- 否 --> R[修正策略并重试] R --> G J -- 是 --> F[输出最终结果]

6.2 为什么 Reflect 很重要？

因为 LLM 有一个天然问题：

• 它能"看起来很像对了"
• 但并不总是真的对

如果没有反思环节，Agent 很可能：

• 把错误结果包装得很完整
• 工具调用失败后仍强行总结
• 在代码生成中遗漏边界情况
• 在报告撰写中出现逻辑跳跃

Reflect 的价值在于引入第二视角：

• 结果是否满足用户目标？
• 是否遗漏关键步骤？
• 是否存在明显冲突？
• 是否需要重试或补充信息？

6.3 Reflect 的伪代码

async function reflectAgent(task, worker, reviewer, maxRounds = 3) {
  let draft = await worker(task);

  for (let i = 0; i < maxRounds; i++) {
    const review = await reviewer(task, draft);

    if (review.pass) {
      return draft;
    }

    draft = await worker(task, {
      previousDraft: draft,
      feedback: review.feedback,
    });
  }

  return draft;
}

6.4 Reflect 的优点

• 质量更稳定
• 能减少明显错误
• 适合高质量内容生成
• 适合代码生成、报告生成、方案设计等任务

6.5 Reflect 的缺点

• 调用次数更多，成本更高
• 反思本身也可能出错
• 如果反馈过于抽象，修正效果有限
• 如果没有退出机制，可能过度打磨

6.6 适用场景

• 高质量写作
• 代码生成与审查
• 方案评估
• 数据分析报告
• 需要准确性或结构完整性的任务

---

7. 混合模式：真实生产环境最常见的答案

如果你在真正的项目里做 Agent，最后往往会发现：

没有一种模式可以解决所有问题。

于是，混合模式就出现了。

混合模式不是一种固定套路，而是组合策略。例如：

• 简单任务走 React
• 复杂任务走 Plan-Exec
• 每个关键步骤后增加 Reflect
• 出现失败时触发重新规划
• 某些高风险工具调用前先做人类确认

7.1 一个典型混合架构

flowchart TD U[用户请求] --> C[复杂度判断] C -->|简单| R1[React 模式] C -->|复杂| P1[Plan-Exec 模式] R1 --> RV[Reflect 校验] P1 --> RV RV --> D{是否达标?} D -- 是 --> O[输出结果] D -- 否 --> RP[重试或重规划] RP --> O

7.2 为什么混合模式是生产常态？

因为生产环境下你要同时考虑：

• 响应速度
• token 成本
• 成功率
• 工具失败率
• 用户体验
• 任务复杂度差异

一个简单问答没必要先生成 8 步计划； 一个复杂分析任务也不能只靠走一步看一步。

所以最合理的方式往往是：

根据任务复杂度和风险等级动态选择 Agent 模式。

---

8. 四种模式横向对比

模式	核心思想	优点	缺点	适合场景
React	边思考边行动	实现简单、灵活、适合动态任务	全局规划弱、可能循环试探	工具型助手、查询、调试
Plan-Exec	先规划再执行	全局结构清晰、适合复杂任务	计划可能失真、实现更复杂	长流程、多阶段任务
Reflect	执行后自我复盘	质量稳定、能纠错	成本更高、速度更慢	高质量内容、代码审查
混合模式	多模式组合	更贴近真实生产需求	设计复杂、调优成本高	通用型生产 Agent

如果只给新手一句建议：

• 先学 React，建立闭环思维
• 再学 Plan-Exec，理解任务分解
• 再引入 Reflect，提升结果质量
• 最后做混合模式，走向生产化

---

9. 代码示例：如何从 0 写一个简单 Agent 框架

下面我们用一个非常简化的 JavaScript 示例，把四种思想串起来。

9.1 第一步：定义工具

const tools = {
  async searchWeb(query) {
    return `搜索结果：找到与"${query}"相关的 3 条资料`;
  },
  async readDoc(topic) {
    return `文档内容：${topic} 的核心概念包括 ...`;
  },
  async saveMarkdown(content) {
    return `已保存 markdown，长度 ${content.length} 字符`;
  },
};

9.2 第二步：写一个最小 React Agent

async function runReactLoop(task, llm) {
  const history = [`用户任务：${task}`];

  for (let i = 0; i < 6; i++) {
    const decision = await llm(history.join('\n'));

    if (decision.type === 'final') {
      return decision.answer;
    }

    const result = await tools[decision.action](...(decision.args || []));
    history.push(`动作: ${decision.action}`);
    history.push(`观察: ${result}`);
  }

  throw new Error('React loop exceeded max iterations');
}

9.3 第三步：加入 Plan-Exec

async function createPlan(task, llm) {
  return await llm(`请将任务拆解为步骤：${task}`);
}

async function executePlan(plan, llm) {
  const outputs = [];

  for (const step of plan.steps) {
    const stepOutput = await runReactLoop(step.description, llm);
    outputs.push({ step: step.description, output: stepOutput });
  }

  return outputs;
}

9.4 第四步：加入 Reflect

async function reflect(task, outputs, llm) {
  return await llm(`请检查以下结果是否满足任务目标。任务：${task}\n结果：${JSON.stringify(outputs)}`);
}

async function runHybridAgent(task, llm) {
  const plan = await createPlan(task, llm);
  const outputs = await executePlan(plan, llm);
  const review = await reflect(task, outputs, llm);

  if (review.pass) {
    return review.finalAnswer;
  }

  // 不通过时，可以触发补充执行或重规划
  const revisedPlan = await createPlan(`基于以下问题重新规划：${review.feedback}\n原任务：${task}`, llm);
  const revisedOutputs = await executePlan(revisedPlan, llm);
  return revisedOutputs;
}

9.5 这个示例体现了什么？

它其实已经包含了生产 Agent 的雏形：

• React：执行单步任务
• Plan-Exec：负责全局任务拆解
• Reflect：负责质量检查
• Hybrid：根据结果决定是否重做

这也是为什么很多团队一开始做 Agent 是一个循环，最后逐渐演化成分层架构。

---

10. 新手最容易踩的坑

这一部分很重要，甚至比模式本身更重要。

坑 1：把 Agent 理解成"更长的 Prompt"

很多新手会觉得，Agent 不就是把提示词写复杂一点吗？

不是。

Agent 的关键不在"提示词长不长"，而在于：

• 是否有状态
• 是否能调用工具
• 是否能读取反馈
• 是否有循环与退出条件
• 是否有错误恢复能力

坑 2：工具很多，但没有调度策略

不是工具越多越强。

如果没有：

• 工具选择策略
• 工具参数约束
• 工具错误处理
• 工具结果格式统一

你的 Agent 很快就会变成"随机调用器"。

坑 3：没有最大迭代次数

React 和 Reflect 都可能死循环。

一定要有：

• 最大轮数
• 超时机制
• 失败降级策略
• 明确的结束条件

坑 4：没有区分简单任务和复杂任务

不是所有任务都值得规划。

如果用户只是问：

• "帮我总结这段话"
• "这个报错什么意思"

你还先规划 6 步，体验会非常差。

坑 5：没有可观测性

真正能把 Agent 做稳的人，都会重视日志和中间状态。

你至少应该能看到：

• 当前模式是什么
• 当前在第几轮
• 调用了哪个工具
• 工具返回了什么
• 为什么结束或失败

否则出了问题只能靠猜。

---

11. 如何选择适合自己的 Agent 架构？

可以用下面这个决策思路。

如果你是新手

建议顺序：

1. 先实现一个单工具或双工具的 React Agent
2. 给它加上最大轮数和错误处理
3. 再尝试把复杂任务前置为 Plan-Exec
4. 最后增加 Reflect 做质量提升

如果你在做课程项目 / Demo

优先考虑：

• React 或 Plan-Exec

因为这两种模式最容易展示结构，也最容易说明设计思路。

如果你在做生产系统

优先考虑：

• 混合模式
• 动态路由
• 状态管理
• 失败恢复
• 监控与日志

一个实用的判断表：

任务特征	推荐模式
简单问答、单步工具调用	React
明显多阶段任务	Plan-Exec
对质量要求高	Reflect
任务复杂度差异大	混合模式
工具不稳定、需要兜底	混合模式 + Reflect

---

12. 推荐的学习路径

如果你想真正学会 AI Agent，不建议一上来就堆框架名词。

更推荐下面这条路线：

第一阶段：理解闭环

目标：理解 Agent 不是一次性回答，而是"决策 + 行动 + 反馈"。

你应该能自己实现：

• 用户输入
• LLM 判断是否调用工具
• 调用工具
• 把工具结果回填给模型
• 输出最终答案

第二阶段：理解多步执行

目标：理解为什么复杂任务需要"任务拆解"。

你应该尝试：

• 生成计划 JSON
• 逐步执行计划
• 步骤之间共享上下文

第三阶段：理解质量控制

目标：让 Agent 不只是能做，还能检查自己。

你应该加入：

• 自检 Prompt
• 结果质量评估
• 不通过时重试

第四阶段：理解工程化

目标：把 Demo 变成可用系统。

你需要逐步加入：

• 日志
• 超时
• 重试
• 限流
• 记忆
• 任务模式切换
• 成本监控

---

13. 总结

最后，用一句话总结四种模式：

• React：边想边做，适合快速行动
• Plan-Exec：先规划再执行，适合复杂任务
• Reflect：做完复盘，适合提升质量
• 混合模式：按任务特点动态组合，适合真实生产环境

如果你现在正处在 AI Agent 学习初期，我建议你把重点放在这三件事上：

1. 理解闭环，而不是死背 Prompt
2. 学会工具调用，而不是只做文本生成
3. 理解任务分解与反馈机制，而不是幻想"一次输出全对"

真正的 Agent 开发，本质上不是"让模型更聪明"，而是：

设计一个让模型在不确定环境中持续逼近目标的系统。

这也是 AI Agent 最迷人的地方。

---

14. 开源代码分享

开源AI Agent Node脚手架