一文读懂从 ReAct 到 Reflexion：LLM Agent 的本质不是“会调用工具”，而是可验证的闭环执行系统

写在前面

欢迎大家关注Rocky的知乎：Rocky Ding
《三年面试五年模拟》AIGC/LLM/AI Agent算法工程师/开发工程师求职面试秘籍独家资源：【三年面试五年模拟】WeThinkIn/AIGC-Interview-Book，欢迎大家Star～

Rocky最新撰写的10万字AI Agent（AI智能体）深入浅出全维度解析文章： 深入浅出完整解析AI Agent（AI智能体）的核心基础知识

AIGC/LLM/AI Agent算法岗/开发岗求职面试内推学习社群（涵盖AIGC、LLM大模型、AI Agent、传统深度学习、自动驾驶、机器学习、计算机视觉、自然语言处理、强化学习、大数据挖掘、具身智能、元宇宙、AGI等AI行业最新面试干货经验与核心知识）欢迎大家加入：https://t.zsxq.com/33pJ0

---

大家好，我是Rocky。

核心导读

过去几年，Agent 领域出现了一个很有意思的错位：模型侧不断强调更长的推理、更强的工具调用和更大的上下文，工程侧却反复被同一批问题绊住——参数填错、工具超时、计划漂移、结果不可验证、权限越界、循环停不下来。

这说明，一个系统是不是 Agent，关键不在它能否生成一段 tool_call，而在它能否把“目标、状态、行动、环境反馈、验证与恢复”接成闭环。 工具调用只是动作接口，规划只是中间状态，记忆只是状态载体；真正决定系统能否交付的，是闭环中的每一步是否可观测、可约束、可回滚。

ReAct、Plan-and-Solve 与 Reflexion 三篇经典工作之所以至今仍值得读，不是因为它们给出了一个永不过时的 Agent 框架，而是因为它们分别抓住了闭环中的三个基本矛盾：

• ReAct 解决“模型如何在思考与行动之间往返”；
• Plan-and-Solve 解决“复杂目标如何先显式分解，再逐步求解”；
• Reflexion 解决“失败信息如何转化为下一次尝试的上下文”。

但同样重要的是：三篇论文的实验范围、后续工程扩展与今天的产品实践不能混为一谈。Rocky 认为，读 Agent 论文最容易踩的坑，就是把一个局部机制的有效性，直接升级为一个生产系统的可靠性。本文会沿着论文原始逻辑展开，同时把事实、工程类比和进一步判断分开。

一、先把定义说清：工具调用不等于 Agent

工具可以被理解为模型访问外部信息或改变外部状态的接口。搜索、数据库查询、代码解释器、浏览器、地图 API、图像生成器都可以是工具。它们补足了语言模型的两类天然短板：一类是模型权重中的知识有截止时间，另一类是文本生成本身不能替代真实执行。

图 1 是一个直观示意：模型先识别需求，再选择搜索、规划或专业模型，最后把结果返回给用户。它说明了工具的价值，但还没有说明 Agent 的全部。一次函数调用可以是普通工作流节点；只有当系统能根据观察更新状态、决定下一步并判断何时停止时，才形成了 Agent 式闭环。

原文用 AGENT = LLM x（规划 + 记忆 + 工具） 作为助记，这对入门有帮助，却不是严格定义。一个更接近生产系统的抽象至少还应包含：目标 $G$、环境状态 $s_t$、可见观察 $o_t$、内部记忆 $m_t$、当前计划 $p_t$、工具集合 $\mathcal{T}$、验证器 $V$、权限策略 $P$ 与终止条件 $D$。

在时间步 $t$，Agent 控制器可以被写成：

$$(a_t,p_{t+1},m_{t+1})\sim {\pi }_{\theta }(o_t,m_t,p_t,G,\mathcal{T})$$

环境接收动作后发生状态转移：

$$s_{t+1}\sim \mathcal{E}(s_t,a_t),o_{t+1}=\mathrm{Observe}(s_{t+1})$$

随后，验证器与策略层决定接受结果、继续执行、重试、回滚还是交给人：

$$d_t=V(o_{t+1},G),z_t=P(a_t,s_t),\mathrm{stop}=D(d_t,t,\mathrm{budget})$$

这里真正重要的不是公式本身，而是它揭示了 Agent 的工程本质：LLM 只是策略生成器的一部分，环境负责给出真实反馈，验证器负责判断是否达标，权限和停止条件负责约束代价与风险。

图 2 把 Agent 放在规划、记忆、行动和工具之间。这个框架适合建立整体认知，但生产实现通常不是几个模块的静态拼装，而是一个反复运行的状态机。每次工具返回都会改变上下文，计划也可能随之失效。

图 3 给出了一条常见链路：任务规划、工具选择、工具调用、响应生成。对一次简单请求，它可以近似为线性流程；对长程任务，更准确的理解是循环：执行结果可能触发重新选工具、修改参数、补充信息或重建计划。因此，线性四阶段是教学抽象，不是所有 Agent 的固定协议。

还有一个容易混淆的概念是 RAG。检索器、搜索 API 或向量库查询可以作为 Agent 的工具，但 RAG 本身通常是“检索 + 上下文构造 + 生成 + 引用/验证”的系统范式。把整个 RAG 简化成一个工具，会掩盖召回质量、上下文污染和引用一致性等独立问题。

二、ReAct：第一次把“想”和“做”放进同一条轨迹

ReAct 的问题意识非常直接。在它出现之前，语言模型的推理与环境行动常被分开研究：Chain-of-Thought 让模型写出推理步骤，却不接触外部世界；Act-only 策略会根据观察选择动作，却缺少显式语言轨迹来跟踪目标、处理例外。

ReAct 的关键不是增加一个花哨模块，而是让模型交错生成语言推理与任务动作：

$$\tau =(o_1,r_1,a_1,o_2,r_2,a_2,\dots ,o_T)$$

其中 $o_t$ 是环境观察，$r_t$ 是语言推理片段，$a_t$ 是面向环境的动作。推理轨迹帮助模型更新计划、提取关键信息和处理异常；外部动作则把新的、可观察的信息带回上下文。

图 4 来自 ReAct 的核心对比。真正值得注意的不是多写了一个 Thought 字段，而是信息流发生了变化：模型不再只在参数内部循环，也不再机械地对上一次观察做动作，而是在每次行动前后更新语言化状态。

从论文证据看，ReAct 在 HotpotQA 和 FEVER 中通过简单的 Wikipedia API 缓解了纯 CoT 的幻觉与错误传播；在 ALFWorld 和 WebShop 两个交互式决策基准上，相对模仿学习或强化学习基线取得了 34% 和 10% 的绝对成功率提升，而且只使用一到两个上下文示例。这些结果说明，推理与行动的协同在特定任务上确实有效。

但它不能证明三个更强的结论。

第一，ReAct 的显式语言轨迹不等于模型内部真实、完整的因果推理。它首先是一种可用于条件生成的文本状态。第二，更多推理 token 不必然带来更高正确率；错误前提也可能被模型“推得更深”。第三，论文中的动作空间、观察格式和基准环境相对受控，真实系统还要面对工具延迟、权限、网页变化、脏数据和不可逆操作。

因此，ReAct 留给今天最有价值的资产，不是固定的 Thought -> Action -> Observation 文本模板，而是一个系统设计原则：让模型的决策受到外部事实反馈，让外部执行受到显式状态约束。

三、Plan-and-Solve：论文中的“先计划再求解”，与工程中的 Planner 不是一回事

ReAct 适合一边观察一边行动，但长任务会暴露另一个问题：局部动作都合理，整体目标却可能在多轮交互中逐渐丢失。Plan-and-Solve（PS）提出先制定计划，把任务拆成较小子问题，再按计划逐步求解；PS+ 则增加更详细的指令，以减少计算错误并改善推理步骤质量。

这里必须做一次严格的概念校准。Plan-and-Solve 原论文研究的是零样本 Chain-of-Thought 提示策略，不是一个完整的多 Agent 调度系统。 论文在十个数据集、三类推理问题上评估 GPT-3，目标是缓解 Zero-shot-CoT 的计算错误、漏步骤和语义理解错误，尤其聚焦“漏步骤”。它没有直接验证服务化的 Planner/Executor、DAG 编排、任务状态持久化、动态重规划或 human-in-the-loop。

图 6 展示的是合理的工程扩展：Planner 生成任务列表，Executor 执行单项任务，失败或新信息触发 Replan。这类设计今天很常见，但应当被称为“从先规划再求解思想延伸出的工程控制环”，而不是 Plan-and-Solve 论文已经证明的原始框架。

图 7 才对应论文中的核心证据：与一句“Let’s think step by step”相比，PS 明确要求模型先理解问题、抽取变量、制定计划，再按计划完成中间计算；PS+ 继续要求注意计算和常识。它说明显式计划可以减少漏步骤，却不能保证计划正确，也没有给计划执行提供外部事务语义。

从科研角度看，规划至少包含三个不同层级：

1. 提示级规划：计划只是同一次模型生成中的文本前缀，成本低，但计划和执行高度耦合。
2. 控制器级规划：计划被解析成结构化任务，具有依赖关系、状态、预算和重试策略。
3. 组织级规划：任务被分配给不同模型、工具或人工角色，还要处理权限、并发、审计与交付标准。

把这三个层级混在一起，会制造一种错觉：只要模型先列 Todo，复杂任务就已经被可靠分解。事实上，生产 Planner 至少要回答五个问题：子任务是否覆盖目标、依赖是否正确、结果如何验收、失败如何恢复、预算何时耗尽。

图 8 是产品运行截图，可用来说明“计划外显”和“状态更新”的交互价值，但不能作为 Plan-and-Solve 论文的实验证据。用户看到 Todo 列表，会更容易理解系统正在做什么；工程团队拿到结构化状态，才能实现恢复、并行与审计。前者改善体验，后者才改善可靠性。

Rocky 认为，规划真正的跨周期价值，不是让模型写出更漂亮的步骤，而是把长任务变成可以独立验证、失败隔离和重新调度的工作单元。计划如果不能被机器读取、被验证器验收、被状态机恢复，就仍然只是自然语言建议。

四、Reflexion：它不是更新权重，而是把失败变成下一轮的情景记忆

有了行动与计划，Agent 仍会失败。传统强化学习可以通过大量交互更新参数，但训练成本高，也不适合每个在线任务都微调模型。Reflexion 的创新点，是引入“语言化强化”：把奖励、测试结果或文字反馈转写为反思，写入情景记忆，在下一次尝试时作为额外上下文使用。

图 9 展示了三个功能角色。Actor 生成行动，Evaluator 根据环境反馈评估轨迹，Self-Reflection 把反馈提炼成语言经验。需要强调的是，三者是逻辑角色，不必然是三个独立基础模型；同一个模型可以用不同提示承担多个角色，不同模型也可以分别承担生成与评估。

Reflexion 的更新发生在上下文和记忆层，而不是模型参数层。可以把它写成：

$$e_k=R({\tau }_k,f_k),M_{k+1}=\mathrm{Update}(M_k,e_k)$$

其中 ${\tau }_k$ 是第 $k$ 次尝试轨迹，$f_k$ 是环境或评估器反馈，$e_k$ 是语言化反思，$M_k$ 是情景记忆。下一次策略条件变为：

$${\tau }_{k+1}\sim {\pi }_{\theta }(G,M_{k+1})$$

论文报告，Reflexion 在 HumanEval 上达到 91% pass@1，高于论文所引用的 GPT-4 80% 结果，并在序列决策、编程和语言推理任务上获得提升。这个结果支持“语言反思 + 情景记忆可以改善后续尝试”，但不能被解读为反思天然可靠。评估器如果给错反馈，反思会把错误解释写入记忆；同一个模型既生成又自评，还可能出现同源偏差。

更稳妥的生产实现通常会建立反馈优先级：可执行测试和确定性规则优先，结构校验与约束求解其次，模型评审最后。原因很简单：反馈越接近真实环境，反思越有机会修正问题；反馈如果只是另一段概率文本，系统可能只是把第一次幻觉改写得更像解释。

从论文机制到代码 Agent：错误必须成为可消费的 Observation

代码 Agent 是最适合观察闭环的场景之一，因为编译器、测试框架和静态检查器会给出明确反馈。下面三张图展示了一条典型工程轨迹：模型先执行检查，环境返回错误堆栈，模型据此继续定位，最终测试通过。

这组截图与 Reflexion 的思想相通，但属于后续代码 Agent 的工程类比，不是 Reflexion 论文实验本身。它揭示了一个更一般的规律：失败不可怕，不可结构化的失败才可怕。 如果工具只返回“执行失败”，模型只能猜；如果环境返回错误类型、文件位置、退出码、标准输出和最小复现，下一步才有可靠依据。

反思也必须有停止条件。没有尝试次数、成本预算、错误去重和升级策略的“自我修正”，很容易退化为昂贵的无限循环。对不可逆操作，系统更不能用“先做错再反思”的方式学习，而应在执行前加入权限检查、模拟运行或人工批准。

五、把三篇论文接起来：一个可交付 Agent 的最小控制闭环

如果把三篇工作的核心机制抽出来，可以得到一条比“规划 + 记忆 + 工具”更可执行的主线：

目标定义
  -> 读取状态与约束
  -> 生成/更新计划
  -> 选择工具并校验参数
  -> 权限检查与执行
  -> 收集结构化观察
  -> 用规则/测试/模型评估结果
  -> 接受、重试、重规划、回滚或转人工
  -> 满足完成条件后终止

ReAct 对应“思考—行动—观察”的局部循环，Plan-and-Solve 对应目标分解和执行顺序，Reflexion 对应失败后的记忆更新。生产系统还必须补上三篇论文并未共同解决的部分：权限、安全、并发、持久化、预算、幂等、回滚和最终验收。

这也解释了为什么很多 Agent Demo 看起来惊艳，进入真实业务却不稳定。Demo 只需要展示一次成功轨迹；产品要面对分布外输入、第三方接口波动、重复请求、半成功状态与责任边界。模型能做出一次正确选择，不等于系统能稳定恢复一百种错误。

一个实用的可靠性分解是：

$$P(\mathrm{success})\approx P(\mathrm{plan})\cdot \prod _{i=1}^{n}P({\mathrm{select}}_i)P({\mathrm{args}}_i)P({\mathrm{exec}}_i)P({\mathrm{verify}}_i)$$

这不是严格独立假设下的真实概率模型，而是工程上的提醒：长链路中任何一个环节持续低可靠，端到端成功率都会快速下降。Agent 产品不能只优化模型回答质量，还要缩短不必要的链路、提高工具确定性、增加中间验证，并把可恢复错误与不可恢复错误分开。

六、Agent 训练数据的核心，不是“多造工具调用”，而是保留可验证轨迹

原文进一步讨论了工具构建、任务合成、答案生成和轨迹校验。这部分非常重要，因为 Agent 能力不只来自模型规模，也来自训练数据是否真实呈现“调用—观察—修正”的因果链。

1. 真实工具与模拟工具服务于不同目标

真实工具能返回环境中的实际结果，适合训练参数约束、错误恢复与状态变化；代价是认证、费用、稳定性和安全隔离。模拟工具便宜、可控，适合扩大格式与场景覆盖，却可能让模型学到不存在的 API 行为。

因此，更合理的策略不是二选一，而是分层：先用模拟环境扩大任务覆盖，再用真实或高保真沙箱校准关键轨迹；凡是需要事实正确性或执行语义的数据，都应优先落到可运行环境中验证。

2. 任务难度不等于调用次数

高质量任务需要明确目标、角色、环境约束、工具可见性和验收标准。单纯把多个简单问题拼接起来，可能只增加 token 和调用次数，并没有增加决策难度。真正困难的任务通常包含信息不完整、工具冲突、延迟反馈、部分失败和不可逆动作。

3. 成功答案不等于高质量轨迹

最终答案正确，可能来自偶然猜中；最终答案错误，中间某些决策也可能是正确的。训练时至少应区分：

• 格式是否合法；
• 工具选择是否合理；
• 参数是否满足 schema；
• Observation 是否被正确使用；
• 中间状态是否推进目标；
• 最终结果是否通过外部验证。

对 SFT 而言，无法解析的工具调用可以被屏蔽，避免模型模仿无效格式；但对恢复训练、偏好优化或过程监督而言，“错误动作—环境反馈—正确修复”恰恰是高价值数据。失败步骤该不该丢弃，取决于训练目标，而不是一条统一规则。

4. 评估必须尽量落到环境

代码任务优先用测试和静态检查，数据任务优先用约束、校验和与查询结果，操作任务优先用状态读回和审计日志。只有当任务难以程序化验证时，才使用 LLM-as-a-Judge；即便如此，也应做多评审一致性、盲评、标尺校准和人工抽检。

七、Chat Template 不是排版细节，而是模型与工具之间的线协议

工具调用训练通常把 system、user、assistant、tool 等角色，以及工具 schema 一并编码到模型输入。Chat template 的作用，是把结构化消息稳定映射为模型训练时见过的 token 序列。

一个典型工具定义包含名称、描述、参数类型、必填项和约束：

{
  "type": "function",
  "function": {
    "name": "get_current_temperature",
    "description": "Get the current temperature for a location.",
    "parameters": {
      "type": "object",
      "properties": {
        "location": {"type": "string"}
      },
      "required": ["location"]
    }
  }
}

模型生成工具名称和参数后，运行时还要完成解析、schema 校验、权限检查、执行与结果回填。解析可以发生在推理服务、SDK、Agent 网关或应用层，并不天然属于某个特定推理框架。

这里的本质是协议一致性。训练时看的是一种工具描述，推理时却换了字段、角色标记或参数格式，模型性能可能因为分布漂移下降。反过来，即使模型输出 JSON 完全合法，参数也可能在业务语义上错误。所以生产系统需要同时处理两类校验：语法 schema 校验，以及与业务状态相关的语义校验。

八、三篇经典工作的证据，到底能支撑多强的结论

工作	论文直接支持的结论	不应直接外推的结论
ReAct	在特定问答、事实核验和交互基准上，交错推理与行动优于若干仅推理或仅行动基线	任意开放环境都能自主完成长任务；显式 Thought 等于真实内部推理；推理越长越正确
Plan-and-Solve	先制定计划再逐步求解，可缓解 Zero-shot-CoT 的漏步骤问题，并在论文评测集上提升表现	论文已经验证 DAG 调度、动态重规划、Planner/Executor 服务拆分和人工审批
Reflexion	不更新权重，通过语言反馈与情景记忆可改善后续尝试	自我反思天然正确；单模型自评可以替代外部测试；在线失败总能通过多试几次解决

这张表并不是削弱三篇工作的价值，恰恰相反。只有守住证据边界，才能看清它们真正的贡献：ReAct 改造了信息流，Plan-and-Solve 显式化了中间计划，Reflexion 把失败转成可复用上下文。它们提供的是机制积木，不是开箱即用的可靠性证明。

九、从技术到产品：基础模型会吸收工具语法，但不会替你承担交付责任

今天，主流模型越来越原生地支持工具 schema、并行调用、结构化输出与长上下文。很多曾经需要框架层手写的功能，正在被模型 API 和推理服务吸收。于是，单纯封装一次函数调用、画一个流程编排界面，长期看很难形成壁垒。

Rocky 认为，Agent 的跨周期价值会沉淀在五个更难被吸收的层面：

1. 工具契约：稳定的输入输出、错误码、幂等和版本治理。
2. 环境反馈：能否把真实执行结果转成结构化、可定位的 Observation。
3. 验证体系：规则、测试、评估器与人工验收如何分层。
4. 状态与权限：任务能否恢复，操作能否审计，高风险动作能否阻断。
5. 领域轨迹数据：哪些计划有效、哪些错误常见、怎样修复，能否形成持续积累。

对算法工程师来说，重点不应只放在更长 CoT，而要研究过程奖励、工具选择、长程信用分配和验证器偏差。对 Agent 工程团队来说，应该优先建设状态机、沙箱、可观测性、幂等与回滚，而不是继续堆叠抽象层。对产品经理来说，需要把“任务完成”写成可验证标准，不能把一句自然语言满意度当成验收。对创业者和投资人来说，真正的护城河不是接了多少模型，而是是否掌握高价值工作流、真实反馈和可复用交付数据。

工具会被标准化，框架会被重新封装，模型能力会继续下沉；但对真实任务的定义、约束、验证与责任不会自动消失。 这才是 Agent 从 Demo 走向基础设施时，最值得长期投入的部分。

十、这条技术路线仍有哪些边界

第一，显式计划和反思都会消耗 token 与时延，并可能把错误前提固化进更长轨迹。系统需要根据任务风险动态决定推理深度，而不是所有请求都启动长链路。

第二，很多真实任务缺少可靠验证器。销售方案、研究判断、开放式写作很难像代码一样通过单元测试。此时必须承认评估的不确定性，并保留来源、版本、人工审批和事后审计。

第三，记忆会引入污染与隐私风险。错误反思、过期信息和敏感数据如果长期写入，会在未来任务中被再次召回。记忆系统需要来源、时效、作用域、删除和冲突处理机制。

第四，工具权限决定风险上限。读取网页与转账、删库、修改生产配置不是同一类动作。高风险工具必须具备最小权限、参数白名单、预演、双重确认与可回滚设计，不能把安全完全交给语言模型判断。

第五，论文基准与生产分布之间仍有距离。受控环境中的成功率提升值得重视，但真实用户会带来模糊目标、上下文缺失、接口变化和组合式故障。上线前需要按时间切分的离线评测、故障注入、影子流量和逐级放权。

术语与概念速查

概念	更准确的理解
Tool	让模型读取外部信息或改变外部状态的受约束接口
Observation	工具或环境返回、可被下一步决策消费的状态信息
ReAct	交错生成语言推理与环境动作的轨迹范式
Plan-and-Solve	先制定计划、再按计划求解的零样本提示策略；不等同于完整调度系统
Reflexion	不更新权重，把反馈转成语言反思并写入情景记忆的框架
Planner	生成或更新结构化任务计划的逻辑角色
Executor	调用工具、收集结果并回写状态的执行角色
Evaluator	根据规则、测试或模型判断轨迹和结果是否达标
Chat Template	把角色消息、工具 schema 与工具结果编码成模型输入 token 的协议模板
Trajectory	从目标到行动、观察、修正和结果的一整条交互轨迹

拓展思考：下一阶段真正值得研究什么

未来 Agent 的竞争，不会只发生在“谁能调用更多工具”，而会集中到四个更本质的问题。

一是可验证性如何规模化。能否自动生成高质量测试、从业务规则构造验证器、对开放任务建立证据化评审，将直接决定 Agent 能否进入高价值流程。

二是长程信用如何分配。最终成功或失败，究竟应该归因于哪次规划、哪次工具选择、哪条观察？只有解决过程级标注与反馈，模型才可能真正学会少走弯路，而不是靠更多重试碰到答案。

三是不确定性如何触发不同控制策略。低风险任务可以自动执行，高不确定或不可逆任务应主动澄清、降级或转人工。把“我不知道”变成系统动作，比让模型始终给出一个答案更重要。

四是Agent 如何从单次成功变成组织记忆。有效轨迹、失败模式、工具变化和审核经验能否被治理、检索和复用，决定了系统是一次性 Demo，还是会随交付持续变强的生产基础设施。

回到最开始的判断：ReAct 让模型开始在思考与行动之间往返，Plan-and-Solve 让计划成为显式中间产物，Reflexion 让失败进入下一轮上下文。它们共同指向的不是一个更拟人的聊天机器人，而是一种新的软件执行范式——概率模型负责提出行动，确定性系统负责约束、验证与兜底。

Agent 真正的成熟，不是它看起来多像人在思考，而是它在犯错时仍然知道自己处于什么状态、为什么失败、下一步允许做什么，以及何时必须停下来。

推荐阅读

1. 深入浅出完整解析AI Agent（AI智能体）的核心基础知识

2025年可以说是AI Agent全面落地应用的元年，因此Rocky在持续撰写对AI Agent的全维度解析文章：

深入浅出完整解析AI Agent（AI智能体）的核心基础知识

2. 深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

Rocky对扩散模型的本质原理与和核心基础知识进行了全面系统的深入浅出分析讲解，同时不断跟进补充扩散模型的最新技术发展，希望能给大家带来帮助：

深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

3. 入浅出完整解析FLUX.2、Seedream（即梦）、Z-image、GLM-Image核心基础知识

Rocky对AIGC时代“中场时刻”之后的主流AIGC创作大模型的核心基础知识进行了全面系统的深入浅出分析讲解，力求让大家通俗易懂理解AIGC时代的技术浪潮的本质价值：

入浅出完整解析FLUX.2、Seedream（即梦）、Z-image、GLM-Image核心基础知识

4. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识

Rocky对FLUX.1 Kontext和FLUX.1 Krea的核心基础知识作了全面系统的梳理与解析：

深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识

5. 深入浅出完整解析DeepSeek系列核心基础知识

Rocky对DeepSeek系列模型的核心基础知识作了全面系统的梳理与解析：

深入浅出完整解析DeepSeek系列核心基础知识

6. 深入浅出完整解析Stable Diffusion 3（SD 3）和FLUX.1系列核心基础知识

Rocky对Stable Diffusion 3和FLUX.1的核心基础知识作了全面系统的梳理与解析：

深入浅出完整解析Stable Diffusion 3（SD 3）和FLUX.1系列核心基础知识

7. 深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识

Rocky对Stable Diffusion XL的核心基础知识作了全面系统的梳理与解析：

深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识

8. 深入浅出完整解析Stable Diffusion（SD）核心基础知识

Rocky对Stable Diffusion 1.x-2.x系列模型的核心基础知识做了全面系统的梳理与解析：

深入浅出完整解析Stable Diffusion（SD）核心基础知识

9. 深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识

Rocky对Stable Diffusion中最为关键的U-Net结构进行了深入浅出的全面解析，包括其在传统深度学习中的价值和在AIGC中的价值：

深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识

10. 深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识

对于AIGC时代中的“ResNet”——LoRA模型，Rocky进行了深入浅出的全面讲解：

深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识

11. 深入浅出完整解析ControlNet核心基础知识

AIGC图像创作开源社区已经形成以Stable Difffusion/FLUX为核心，ConrtolNet和LoRA作为首要AI辅助工具的变化万千的AIGC图像创作工作流。

ControlNet正是让AI图像创作社区无比繁荣的关键一环，它让AIGC图像创作过程更加的可控，更有助于广泛地将AIGC算法解决方案应用到各行各业中：

深入浅出完整解析ControlNet核心基础知识

12. 深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识

AI绘画和AI视频是两个互相促进、相互交融的领域，2024年无疑是AI视频领域的爆发之年，Rocky对AI视频领域核心的Sora、Seedance、Keling等大模型进行了全面系统的梳理与解析：

深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识

13. 深入浅出完整解析AIGC时代Transformer核心基础知识

在AIGC时代中，Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向，成为AI技术架构大一统与多模态整合的关键核心基座，大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析：

深入浅出完整解析AIGC时代Transformer核心基础知识

14. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

AIGC创作框架正是AIGC算法工作流的运行载体，目前主流的AIGC创作框架有ComfyUI、Diffusers、Stable Diffusion WebUI等。在传统深度学习时代，PyTorch、TensorFlow以及Caffe是传统深度学习模型的基础运行框架，到了AIGC时代，Rocky相信ComfyUI就是AIGC时代的“PyTorch”、Stable Diffusion WebUI就是AIGC时代的“TensorFlow”、Diffusers就是AIGC时代的“Caffe”：

深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

15. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

在AIGC时代中，如何快速转身，入局AIGC产业？如何成为AIGC/LLM/AI Agent算法/开发工程师？如何在学校中系统性学习AIGC/LLM/AI Agent知识，斩获心仪的AIGC/LLM/AI Agent算法/开发offer？

Don‘t worry，Rocky为大家总结整理了全面的AIGC/LLM/AI Agent算法/开发工程师成长秘籍，为大家答疑解惑，希望能给大家带来帮助：

手把手教你成为AIGC/LLM/AI Agent算法/开发工程师，斩获AIGC/LLM/AI Agent算法/开发offer！

16. AIGC产业的深度思考与分析

2023年3月21日，微软创始人比尔·盖茨在其博客文章《The Age of AI has begun》中表示，自从1980年首次看到图形用户界面（graphical user interface）以来，以OpenAI为代表的科技公司发布的AIGC模型是他所见过的最具革命性的技术进步。

Rocky也认为，AIGC及其生态，会成为AI行业重大变革的主导力量。AIGC会带来一个全新的红利期，未来随着AIGC的全面落地和深度商用，会深刻改变我们的工作、生活、学习以及交流方式，各行各业都将被重新定义，过程会非常有趣。

那么，在此基础上，我们该如何更好的审视AIGC的未来？我们该如何更好地拥抱AIGC引领的革新？Rocky准备从技术、产品、商业模式、长期主义等维度持续分享一些个人的核心思考与观点，希望能帮助各位读者对AIGC有一个全面的了解：

深入浅出全面解析AIGC时代核心价值与发展趋势（2025年版）

17. AI算法工程师的独孤九剑秘籍

为了方便大家实习、校招以及社招的面试准备，同时帮助大家提升扩展技术基本面，Rocky将符合大厂和AI独角兽价值的算法高频面试知识点撰写总结成《三年面试五年模拟》之独孤九剑秘籍:

【三年面试五年模拟】AIGC时代的算法工程师的求职面试秘籍（持续更新中）

18. 深入浅出完整解析AIGC时代中GAN（Generative Adversarial Network）系列模型核心基础知识

GAN系列模型作为传统深度学习时代的最热门生成式Al模型，在AIGC时代继续繁荣，作为Stable Diffusion/FLUX系列大模型的“得力助手”，广泛活跃于AlGC图像创作的产品与工作流中：

深入浅出完整解析AIGC时代中GAN（Generative Adversarial Network）系列模型核心基础知识