一文搞懂 Agent Loop、Graph Loop、Reflection、Reflexion：执行、编排与反馈改进的层次关系

很多人在学习大模型 Agent 时，容易把 Agent Loop、Graph Loop、Reflection、Reflexion 混为一谈。造成混淆的根本原因是：这些概念描述的并不是同一件事，有些属于执行机制，有些属于编排方式，有些属于反馈改进方法。

要真正理解它们，应当按照以下顺序：

• Agent 如何执行任务？——Agent Loop
• 如何控制任务的执行流程？——Graph Loop
• 执行过程中如何发现错误并改进？——Reflection
• 具体有哪些反馈改进方案？——Self-Refine、CRITIC、Reflexion
• 这些机制在实际 Agent 系统中如何组合？

一、首先建立三个不同的概念层次

理解这些技术，最重要的是区分三个维度。

这三个维度可以同时存在于同一个 Agent 系统中，并不相互排斥。

例如，用户要求 Agent 修复一段代码。

Agent 首先分析代码、调用工具、读取报错信息、修改文件。这一系列持续决策与工具交互，可以通过 Agent Loop 完成。

如果系统将“生成代码、运行测试、检查结果”拆成不同节点，并在测试失败时通过条件边返回修改节点，就形成了 Graph Loop。

而当系统根据测试结果分析错误原因，判断应该如何改进代码时，就使用了反馈与反思机制。

这里需要区分三种不同的东西：

• Agent Loop 关注执行过程；
• Graph Loop 关注控制流结构；
• Reflection 关注反馈如何用于改进。

它们不是互斥关系，也不存在固定的父子包含关系。

二、Agent Loop：智能体持续决策与执行任务的机制

2.1 什么是 Agent Loop？

Agent Loop 是指 Agent 根据当前任务状态不断进行决策、执行行动、获取观察结果，再利用新信息决定下一步操作的循环。

典型流程为：

LLM 决策 → 执行 Action → 获取 Observation → 更新上下文 → 再次决策

直到任务完成、达到执行上限，或者满足其他终止条件。

与普通固定工作流不同，Agent Loop 的核心在于：Agent 可以根据执行过程中获得的新信息，动态决定下一步做什么。

例如，用户要求 Agent 查询某个接口报错的原因。

第一轮：Agent 决定读取日志。

第二轮：根据日志发现数据库连接异常，决定检查数据库状态。

第三轮：发现连接池耗尽，决定进一步检查连接释放逻辑。

第四轮：定位问题，给出修复方案。

这个过程中，Agent 的后续行动并不是全部提前写死，而是依赖每一步的 Observation。

2.2 ReAct 与 Agent Loop 的关系

ReAct 是 Agent Loop 的典型实现范式。

ReAct 的核心思想是将推理与行动交替结合：

Reasoning → Acting → Observation → Reasoning → …

模型可以根据观察结果调整后续行动。

但需要注意：

ReAct 不等于 Agent Loop 的全部。

Agent Loop 是更一般的执行机制，而 ReAct 是其中一种经典的推理与行动组织方法。其他采用不同规划方式的 Agent，也可以具有执行循环。

另外，ReAct 并不要求模型把所有内部推理都明确展示出来。实际工程系统可以通过工具调用、状态更新等方式实现类似的决策与行动循环。

2.3 Agent Loop 一定在节点内部吗？

不一定。

Agent Loop 描述的是智能体的执行行为，而不是代码必须部署在哪里。

它至少可以有两种常见实现。

实现一：通过普通程序循环实现。

在一个函数中反复调用模型，根据模型输出执行工具，再将工具结果传回模型。

实现二：通过图编排实现。

把模型调用和工具执行拆成两个节点：

Agent 节点 → Tool 节点 → Agent 节点

只要 Agent 还需要调用工具，就继续循环；如果 Agent 给出最终答案，就结束。

因此，同一个 Agent Loop 既可以被封装在单个节点内部，也可以由多个图节点共同实现。

不能简单认为“Agent Loop 是节点内部循环，Graph Loop 是节点之间循环”。

三、Graph Loop：图编排中的循环控制结构

3.1 Graph Loop 的本质是什么？

Graph Loop 是指工作流图中的执行路径通过某条边返回先前节点，从而产生循环。

例如：

生成节点 → 校验节点 → 判断节点

如果校验成功，则结束；如果校验失败，则返回生成节点。

它的本质是图上的循环控制流。

Graph Loop 只规定流程可以怎样重复执行，本身并不规定循环的具体目的。

因此，它可以用于很多不同场景：

• Agent 反复调用工具；
• 文本生成失败后修改；
• 代码测试失败后重试；
• 审核不通过后重新生成；
• 完整任务失败后开启新一轮尝试。

3.2 Graph Loop 与 Agent Loop 的区别

最容易混淆的地方是：二者确实可能表现为相似的循环，但关注点不同。

Agent Loop 是按执行语义定义的：

它要求智能体能够根据状态和观察结果继续决策与行动。

Graph Loop 是按程序控制结构定义的：

只要图中存在可重复执行的循环路径，就可以构成 Graph Loop。

所以，Graph Loop 不一定包含 Agent。

例如，一个完全使用确定性程序的工作流：

调用接口 → 检查状态码 → 失败则重试接口

这也可以是 Graph Loop，但不一定属于 Agent Loop。

反过来，Agent Loop 也不一定通过图实现，它可以直接用普通 while 循环编写。

3.3 Graph Loop 一定是局部循环吗？

不是。

Graph Loop 可以是局部循环，也可以是整个图的循环。

例如：

局部循环：

生成答案 → 检查答案 → 修改答案

整体循环：

Agent 完整执行任务 → 评估是否成功 → 反思失败原因 → 重新执行任务

只要这些阶段被建模为图节点，并通过条件边返回先前节点，就属于图上的循环控制。

因此，不能把“同一个 trial 内部的局部重做”作为 Graph Loop 的必要定义。

Graph Loop 是否跨 trial、是否使用 Memory、是否重新开始完整任务，是系统设计者决定的，而不是由 Graph Loop 这个概念本身决定的。

3.4 Graph Loop 与 Agent Loop 可以重合

一个典型例子是用 LangGraph 实现 ReAct Agent：

Agent → Tool → Agent

这个循环可以同时被描述为：

• 从执行机制看，它是 Agent Loop；
• 从图编排结构看，它是 Graph Loop。

也就是说，二者不是非此即彼，而是从两个不同角度描述同一段执行流程。

四、Reflection：一种反馈驱动的检查与改进机制

理解 Reflection，首先要避免将其直接等同于某个特定循环。

Reflection 通常是指系统回顾已有输出、行动过程或执行结果，分析问题并生成可用于改进的反馈。

其一般逻辑是：

产生结果 → 评估结果 → 诊断问题 → 利用反馈改进

这里有两个需要区分的概念。

Evaluation（评估） 主要回答：结果是否正确、是否合格、得分是多少？

Reflection（反思） 更强调：为什么会出现问题，应该如何调整？

实际方法中，评估与反思往往紧密结合，但二者并不完全相同。

例如，单元测试报告某个测试没有通过，属于评估反馈；Agent 根据失败信息分析边界条件遗漏，并决定补充相应逻辑，则包含进一步的诊断与改进。

4.1 Reflection 是一个固定算法吗？

不是。

Reflection 更适合作为反馈改进思想或机制的宽泛称呼。

Self-Refine、CRITIC、Reflexion 都可以放在反馈驱动改进的框架下理解，但它们并不是某个严格标准化技术分类中的三个固定子类。

这点很重要，因为三者的研究目标和设计方式并不完全相同。

4.2 Reflection 必须使用自然语言吗？

不必须。

反馈可以来自多种来源：

• 模型自己生成的评价；
• 外部工具提供的运行结果；
• 规则系统给出的判断；
• 真实环境返回的反馈；
• 人类提供的评价或指导。

反馈可能是自然语言，也可能是测试结果、分数或其他结构化信号。

模型可以进一步将这些反馈转化为自然语言形式的改进建议。

需要强调的是，Self-Refine、CRITIC、Reflexion 这三种经典方法主要在推理和执行阶段利用反馈改进结果，而不是通过每次失败更新模型权重。但“绝不更新权重”并不是广义 Reflection 的普遍定义。

4.3 Reflection 必须构成循环吗？

也不必须。

反思之后，系统可能：

• 直接修改当前输出；
• 回到某个步骤重新执行；
• 保存失败经验，供下一次尝试使用；
• 只生成诊断报告，不自动重试。

所以，Reflection 描述的是反馈改进机制，而循环如何实现，则属于执行和编排层面的问题。

接下来真正需要重点比较的是 Self-Refine、CRITIC 和 Reflexion。

五、Self-Refine、CRITIC、Reflexion：三种具体方法

这三种方法可以放在同一个问题下比较：

模型第一次执行效果不好时，系统怎样利用反馈让后续结果更好？

三者选择了不同的解决方案。

5.1 Self-Refine：模型自己评价，并修改当前结果

Self-Refine 的核心思想是让同一个大模型承担生成、反馈和修改的角色。

典型流程：

初始生成 → 自我反馈 → 根据反馈修改 → 再次反馈 → …

例如，让模型写一封商务邮件。

模型先生成初稿，然后评估措辞是否正式、信息是否完整、结构是否清晰。

如果发现问题，就根据反馈修改原稿，并重复这一过程，直到满足停止条件。

关键特征：

• 反馈主要来自模型自身，而不是必须依赖外部工具。
• 改进主要针对当前候选结果，通常会将已有内容和反馈共同用于下一次修订。
• 不需要跨 trial 的经验记忆。

Self-Refine 的创新重点，是通过模型自身的反馈与迭代修订提升输出质量，而不是设计一种具有长期经验积累能力的 Agent。

需要注意：Self-Refine 是迭代优化方法，本身并不要求使用 Graph 框架实现。

5.2 CRITIC：借助外部工具验证，再修改结果

Self-Refine 有一个明显的局限：模型如果不知道自己错在哪里，单纯依赖自我评价，也可能无法发现错误。

CRITIC 试图利用外部工具提供额外的验证信息。

典型流程：

初始生成 → 工具交互与检查 → 获得外部反馈 → 模型分析并修改 → 再次验证

例如，让模型编写一个排序算法。

模型先生成代码，然后调用代码执行器运行测试。

如果发现测试失败，模型读取测试反馈，分析错误原因并修改代码。

然后重新执行测试。

与 Self-Refine 相比，CRITIC 的关键不是简单增加一个评审步骤，而是将外部工具提供的信息引入批评和修订过程。

不过，不能理解为 CRITIC 完全由工具自动判断所有错误。

工具通常提供检索证据、执行结果或可验证信息；如何根据这些信息形成批评、决定怎样修订，仍可能由模型完成。

因此，外部反馈也不必然正确。搜索结果可能不可靠，单元测试也可能覆盖不全面。

CRITIC 的原始方法重点是工具交互式的检查与修正，而不是跨 trial 反思记忆。

5.3 Reflexion：把一次失败变成下一次尝试的经验

Reflexion 与前两种方法最重要的区别，在于它关注的不只是当前输出的修订，还包括如何让 Agent 利用先前尝试的经验，改进下一次执行。

原版 Reflexion 的核心包含四个部分：

Actor、Evaluator、Self-Reflection、Memory。

它们分别承担以下职责。

Actor：负责执行任务。

Actor 可以采用 ReAct 等方式与环境交互，生成一条完整的执行轨迹。

Evaluator：负责评价结果。

根据任务结果或执行轨迹，判断本次尝试的表现，例如成功与否。

Self-Reflection：负责反思原因。

将执行轨迹和评价反馈转化为对后续行动有帮助的经验。

Memory：负责保存反思经验。

下一轮尝试时，Actor 可以读取这些经验，调整行动策略。

其典型流程为：

Trial 1：执行任务 → 评价失败 → 生成反思 → 写入 MemoryTrial 2：读取 Memory → 重新执行任务 → 再次评价

如果仍然失败，则可以继续反思与重试，直到满足成功条件或尝试次数上限。

例如，Agent 需要在一个复杂环境中找到某个物品。

第一次尝试中，它反复检查同一个位置，却忽略了其他房间。

任务失败后，Self-Reflection 可能总结出：

“之前重复检查了相同区域。下一次应先记录已经搜索过的位置，再探索尚未检查的房间。”

这条经验被保存到 Memory 中。

第二次尝试时，Actor 利用该经验调整搜索策略。

Reflexion 的关键不是简单地多执行一次任务，而是将前一次失败转化为可以影响后续决策的文字经验。

5.4 Reflexion 中的 trial 究竟是什么意思？

这是理解原始论文最关键的地方。

一个 trial 可以理解为一次完整的任务尝试。

如果 Actor 采用 ReAct，它在一次 trial 内部就可能进行多次行动与环境交互。

例如：

Trial 1 内部：

观察环境 → 选择行动 → 获取反馈 → 再次选择行动 → … → 本次尝试结束

然后 Evaluator 对这次尝试进行评价。

如果失败，Self-Reflection 生成反思并写入 Memory，之后进入新的 trial。

因此必须区分两个循环：

内层：Actor 的行动循环。

负责完成当前这次尝试。

外层：Reflexion 的 trial 循环。

负责通过反思记忆改进后续尝试。

在原版 Reflexion 的核心设计中，反思记忆主要用于后续 trial，而不是把当前已经发生的整条执行轨迹原地改写。

但这不意味着当前 trial 内不存在 Agent Loop，更不意味着整个 Reflexion 系统不能用 Graph Loop 实现。

另外，Reflexion 论文中的 Memory 主要是跨同一任务的不同尝试保存反思经验，不等于必须具有跨所有任务、永久持久化的数据库记忆。

六、三种方法究竟有什么本质区别？

可以从三个问题判断：

第一，反馈从哪里来？

Self-Refine 主要依靠模型自身反馈。

CRITIC 强调借助外部工具获取可用于验证的信息。

Reflexion 可以利用环境反馈、评价器、测试结果等多种信号，再通过自反思生成经验。

第二，反馈主要用在哪里？

Self-Refine 用于修订当前结果。

CRITIC 用于通过工具反馈检查并修订当前结果。

Reflexion 则强调将本次尝试的经验用于改进后续尝试。

第三，是否强调跨 trial 的反思记忆？

Self-Refine 和 CRITIC 的原始设计不以跨 trial 的反思记忆为核心。

Reflexion 则将跨 trial 的经验记忆作为关键设计。

可以用三句话概括：

Self-Refine：我检查自己刚才生成的内容，然后修改。

CRITIC：我利用外部工具验证刚才生成的内容，再根据结果修改。

Reflexion：我总结这一次为什么失败，把经验保存下来，在下一次尝试中避免重复错误。

但要注意，它们之间并不是完全互斥的关系。

一个 Reflexion Agent 完全可以在某次 trial 内部使用 CRITIC 或 Self-Refine 进行局部改进。

七、把三种方法放进一个完整的 Agent 系统

假设要设计一个自动修复代码的 Agent。

用户提交了一个存在 Bug 的 Python 项目，要求 Agent 找到错误并修复。

整个系统可以包含三个层次。

第一层：Agent Loop——执行修复任务

Agent 根据当前状态决定操作：

读取代码 → 分析异常 → 调用工具 → 查看执行结果 → 继续修改

它负责实际推进任务。

第二层：当前尝试中的反馈修订

Agent 编写补丁后，需要验证代码是否正确。

可以使用 CRITIC 风格的方法，通过运行测试获取外部反馈，再分析并修改代码。

如果测试失败，可以继续在当前尝试内修订补丁。

如果只是优化代码注释、错误提示或文档措辞，也可以使用 Self-Refine 风格的自评修订。

这部分循环可以通过 Graph Loop 实现。

第三层：Reflexion——完整尝试失败后的经验积累

假设当前尝试达到预算上限，仍然没有修复问题。

Evaluator 判断本次尝试失败。

Self-Reflection 分析本次完整轨迹，并生成经验：

“之前只检查了异常函数，忽略了调用方传入参数的类型。下一次应优先检查调用链和输入数据。”

系统将这条经验写入 Memory。

随后，Agent 开启新的 trial，利用已有经验重新制定修复策略。

这样就形成了三个不同的循环：

而 Graph Loop 可以用于组织上述任意一种循环。

这说明 Agent Loop、Graph Loop、Reflection、Reflexion 不应该机械地摆在同一张“谁属于谁”的分类树中。

它们描述的是一个 Agent 系统中不同层面的能力与设计。

八、工程实现中应该如何设计循环？

理解理论之后，还需要知道怎样在系统中正确组织循环。

首先，应当为不同循环设定独立的状态和终止条件。

8.1 Agent 执行循环

需要管理当前消息、工具调用结果、任务状态、执行步数与预算。

典型停止条件包括：

• Agent 已经完成任务；
• 不再需要工具；
• 达到最大执行步数；
• 超过时间或 token 预算；
• 触发异常或安全终止条件。

8.2 反馈修订循环

需要保存当前候选输出、评估反馈、修订历史和循环次数。

典型停止条件包括质量达标、达到修订上限、连续多次没有改善。

尤其需要注意：模型给出“已经正确”的自我评价，不一定意味着结果真的正确。

对于代码执行、数据计算等任务，应优先使用可验证的工具结果辅助判断。

8.3 Reflexion 的 trial 循环

需要区分：

当前 trial 的执行状态：保存本次行动、工具结果、临时工作上下文等。

跨 trial 的反思记忆：保存前几次尝试中提炼出的、对后续决策有用的经验。

进入新的 trial 时，不能简单地把全部失败日志无限追加到上下文中。

更好的方式是提炼具体、可执行、与当前任务相关的教训，并对 Memory 设置容量或长度限制。

此外，还需要区分两个概念：

Retry：失败后再次执行；

Reflection：分析问题并形成改进信息。

不是所有 Retry 都具有 Reflection，也不是所有 Reflection 都必须触发 Retry。

九、面试中最容易被问到的几个问题

问题一：Agent Loop 和 Graph Loop 有什么区别？

Agent Loop 描述智能体持续决策、行动和观察的执行机制；Graph Loop 描述工作流图中节点通过循环边重复执行的控制流结构。

二者不属于同一维度。

Agent Loop 可以通过 Graph Loop 实现，也可以通过普通程序循环实现；Graph Loop 也可以用于完全不包含 Agent 的重试工作流。

问题二：Reflection 和 Reflexion 有什么区别？

Reflection 是更宽泛的反馈检查与反思改进思想。

Reflexion 是一种具体的语言 Agent 框架，它通过 Actor 执行任务、Evaluator 评价结果、Self-Reflection 生成反思、Memory 保存经验，使 Agent 能在后续 trial 中利用先前失败的信息。

因此，Reflexion 使用了 Reflection 思想，但不应该把二者视为两个同级、互斥的算法。

问题三：Self-Refine 和 CRITIC 的区别是什么？

二者都强调根据反馈修改已有输出。

Self-Refine 的经典设计主要依靠同一个模型生成反馈并修改结果。

CRITIC 的关键是引入外部工具，通过工具交互获得更有依据的检查信息，再驱动模型修正输出。

最重要的区别是反馈与验证信息的来源，而不是是否使用 Graph 框架。

问题四：CRITIC 和 Reflexion 的区别是什么？

CRITIC 更关注如何通过工具反馈验证并修正当前生成结果。

Reflexion 更关注如何把一次完整尝试的执行反馈转化为反思经验，并在后续 trial 中加以利用。

需要注意，Reflexion 的 Evaluator 也可以使用外部工具，所以不能简单认为“用工具的是 CRITIC，不用工具的是 Reflexion”。

问题五：Reflexion 为什么需要 Memory？

因为 Reflexion 的核心目标不是只对当前结果做一次修补，而是使下一次尝试能够利用之前的经验。

如果不将反思结果传递给后续 trial，那么单纯重复执行任务未必能避免相同的错误。

不过，Memory 中保存的经验也可能不准确，因此实际工程实现还需要考虑记忆筛选、纠错和失效机制。

问题六：原版 Reflexion 在单次 trial 内是否存在循环？

需要区分循环类型。

如果 Actor 使用 ReAct，那么一次 trial 内就可能包含多轮 Thought、Action 和 Observation。

但 Reflexion 最有代表性的反思—记忆—重新尝试机制发生在 trial 之间。

所以，准确的表述应当是：

原版 Reflexion 的跨 trial 反思不等于在同一条执行轨迹中原地修订，但它并不排斥单次 trial 内部存在 Agent 行动循环。

问题七：Reflexion 可以用 Graph Loop 实现吗？

当然可以。

例如：

Actor → Evaluator → Self-Reflection → Memory → Actor

其中，从 Memory 返回 Actor 的循环边，表示开启下一次 trial，而不是返回当前 trial 的中间执行步骤。

这属于一种跨 trial 的图循环。

十、总结

Agent Loop、Graph Loop 和 Reflection 分别属于执行机制、图编排机制和反馈改进机制三个不同维度。

Agent Loop 负责让 Agent 根据环境观察结果持续决策和行动，ReAct 是典型的实现范式。

Graph Loop 则是工作流图上的循环控制结构，可以用来实现 Agent 的工具调用循环、结果修订循环，或者跨 trial 的重试循环，并不天然局限于节点内部或局部子图。

Reflection 是通过评估、诊断与反馈改善系统结果或行为的宽泛机制。

具体到经典方法，Self-Refine 主要通过模型自身反馈迭代修订当前输出；CRITIC 强调引入外部工具获取验证信息并修改输出；Reflexion 则通过 Actor、Evaluator、Self-Reflection 和 Memory，将一次尝试的失败经验用于指导后续 trial。

原版 Reflexion 的反思记忆主要在 trial 之间发挥作用，但每次 trial 内部的 Actor 仍然可以通过 ReAct 等方式进行多步行动。

最终需要记住的是：Agent Loop 解决怎么执行，Graph Loop 解决怎么编排循环，Reflection 解决怎么利用反馈改进，而 Self-Refine、CRITIC、Reflexion 是不同的反馈改进方案。