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

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


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

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

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

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

因为一个真正的 Agent,通常不只是“回答问题”,而是要完成任务。比如:

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

这时候,问题就不再是“提示词怎么写”,而变成:

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

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


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

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

普通聊天机器人

核心能力是:

  • 理解输入
  • 生成文本

AI Agent

核心能力是:

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

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

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

用户目标

Agent

工具 / API / 数据库 / 文件系统

观察结果 Observation

最终结果

在这个闭环里,LLM 不再只是“回答器”,而是扮演:

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

3. Agent 的核心运行闭环

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

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

常见闭环如下:

接收用户请求

分析任务复杂度

是否需要多步执行?

直接推理 / 单轮工具调用

规划或迭代执行

输出结果

获取反馈

是否达成目标?

理解了这个闭环,再去看不同架构模式,就不会只停留在“名词记忆”层面。
在这里插入图片描述


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

注意:这里的 React 不是前端框架,而是 Reason + Act,即“推理 + 行动”。

React 模式的核心思想是:

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

4.1 React 的工作流图

用户问题

Thought 思考

Action 执行动作

Observation 观察结果

Thought 再次思考

Action 再执行

Observation 新结果

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 的工作流图

用户任务

Plan 生成执行计划

Step 1 执行

Step 2 执行

Step 3 执行

汇总结果

最终输出

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 工作流图

用户任务

生成初稿 / 执行结果

Reflect 评估与反思

结果是否达标?

修正策略并重试

输出最终结果

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 一个典型混合架构

简单

复杂

用户请求

复杂度判断

React 模式

Plan-Exec 模式

Reflect 校验

是否达标?

输出结果

重试或重规划

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脚手架

Logo

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地,聚焦技能开发、插件实践与部署教程,为开发者提供可直接落地的方案、工具与交流平台,助力高效构建与落地 AI 应用

更多推荐