OPAR循环：Agent的迭代执行心脏——从Observe到Plan到Act到Reflect的闭环控制流

LIUDAN'S WORLD

343人浏览 · 2026-05-15 21:32:40

LIUDAN'S WORLD · 2026-05-15 21:32:40 发布

OPAR循环：Agent的迭代执行心脏——从Observe到Plan到Act到Reflect的闭环控制流

阅读导航：这篇文章会从一张"机票预订"的具体场景开始，先让你看到OPAR循环的全貌（宏观），再逐层剥开每个阶段的内部结构（中观），最后落到状态向量如何在每一步流转（微观）。如果你已经熟悉ReAct或RNN的循环概念，我们会不断用它们作为锚点。准备好了吗？我们出发。

0. 从一个让你头疼的问题开始

想象你对着一个AI说：“帮我订下周去东京的最便宜机票，要能用我的积分兑换，且起飞时间别早于上午9点。”

如果这是一个普通聊天机器人，它可能会立刻给你一段关于"如何查找机票"的说明文字——然后就没有然后了。但如果是真正的Agent，它应该像一位耐心的旅行助理一样：先查航班，再查积分规则，比较价格，发现某个航班时间太早，回头重新筛选，最后才下单。

问题来了：这个"查→比→改→再查"的过程，不是一次性完成的。Agent需要一种循环机制，让它能像人类一样边做边调整。这种机制就是本文的主角——OPAR循环（Observe-Plan-Act-Reflect）。

别急，这个名字听起来像四个生硬的模块，对吧？但如果我们把它画成图，你会发现它其实很像你每天早上出门前的决策流程。让我们先站在山顶，看看全貌。

1. 宏观视角：OPAR循环的全貌——如果画成一张地图会是什么样子？

如果我们把整个Agent的执行过程画成一张环形地铁线路图，它会有四个站点，列车顺时针循环行驶，直到抵达终点站（任务完成）。

如果画成图会是什么样子？ 想象一个四格传送带。每一格代表一个认知阶段，Agent的"意识"（也就是上下文窗口中的状态）像包裹一样在传送带上移动。每转一圈，包裹里就多装了一些新的观察结果和反思结论。

这和ReAct循环（Reason-Act-Observe）有什么区别？ReAct更像"边想边做"，而OPAR则强调先做全局规划（Plan），再执行（Act），最后系统性地反思（Reflect）。你可以把OPAR理解为在ReAct基础上增加了一个战略层：不是每一步都临时决定，而是有一个可以动态调整的蓝图。

听起来抽象对吧？让我们把四个站点逐个拆开。

2. 中观拆解：四个站点里究竟在发生什么？

2.1 Observe：Agent的"感官系统"

我们先问一个直觉问题：当你走进一个陌生房间，你首先做什么？——你会看。Agent也是如此。Observe阶段就是Agent的"感官系统"在收集环境信号。

在OPAR循环中，Observe不是简单地"读输入"。它同时处理三类信息：

外部感知：用户的新指令、API返回的数据、传感器读数
内部状态：上一轮循环留下的记忆、当前计划的执行进度
环境变化：上一次Action带来的世界状态改变

用你已知的概念类比：这很像RNN的输入门。在RNN中，当前时间步的输入x_t会和上一时刻的隐藏状态h_t-1一起决定新的隐藏状态。Observe阶段做的正是类似的事情：把新观察o_t和之前的"心智状态"融合成当前认知。

在继续之前，让我们先看一个toy example。假设Agent的任务是"查天气并建议是否带伞"。第一轮Observe阶段，Agent收到的观察向量可能是：

o_1 = [用户查询:"巴黎天气"; 历史记录:∅; 环境上下文:"上午8点"]

很简单对吧？但在真实规模中，这个向量可能包含数千维的嵌入（embeddings），来自多个传感器和API的JSON响应。原理一样，只是维度变大了。

2.2 Plan：从"看到"到"想到"——Agent的额叶皮层

现在我们已经了解了Observe，接下来看看Plan。听起来抽象对吧？别急，Plan阶段其实回答的是三个具体问题：

我在哪？（当前状态评估）
我要去哪？（目标分解）
哪条路最近且最安全？（路径规划与约束检查）

这和全连接层有什么关系？想象一个全连接层接收Observe阶段输出的特征向量，输出的是动作概率分布。Plan阶段做的更高级：它不是直接输出一个动作，而是输出一个动作序列的骨架（plan skeleton）。

问题驱动：如果没有Plan阶段会怎样？Agent会变成"无头苍蝇"——每一步只根据当前观察临时反应，就像一只只凭触觉爬行的昆虫，而不是有导航系统的无人机。

在机票预订的例子中，Plan阶段可能生成这样的计划：

π = ⟨搜索航班(东京, 下周), 查询积分余额, 筛选(价格<阈值 ∧ 时间>09:00), 预订最优选项⟩

注意这个计划不是死的。OPAR的Plan阶段会生成带条件分支的计划：“如果搜索结果为空，则扩大日期范围；如果积分不足，则只显示现金价格”。这就像一个带有if-else的有限状态机，而不是线性脚本。

2.3 Act：从"想到"到"做到"——Agent的运动皮层

现在我们已经了解了Plan，接下来看看Act。这是最容易理解的部分，对吧？但这里有一个微妙的认知疑点：Act执行的是谁的指令？

答案是：Act执行的是Plan阶段产生的当前步骤的实例化动作。Plan给了蓝图，Act负责搬砖。具体来说，Act阶段做三件事：

动作实例化：把抽象计划"搜索航班"转化为具体的API调用search_flights(origin="PEK", dest="NRT", date="2026-05-22")
工具调用：通过函数调用接口（Function Calling）触发外部工具
副作用执行：在真实世界或模拟环境中产生改变（写入数据库、发送邮件、控制机械臂）

锚定已知概念：如果你熟悉神经网络的前向传播（Forward Pass），Act阶段就像前向传播中的激活输出——输入是计划向量，输出是环境可解析的原始动作。不同之处在于，这里的"激活函数"是外部世界的API，而不是sigmoid或ReLU。

在toy example中，Act可能只是调用一个get_weather(city="Paris")的模拟函数。但在真实规模中，一个Act步骤可能涉及并行调用5个API，处理异步回调，并在500毫秒内完成超时判断。

2.4 Reflect：Agent的"元认知"——为什么这一步让OPAR与众不同？

好了，现在我们已经了解了Observe、Plan和Act。但OPAR循环真正区别于简单Plan-Act-Observe循环的，是这第四个阶段：Reflect。

先以一个问题开头：你写完一段代码后，是直接提交，还是先跑测试看看有没有bug？Reflect就是Agent的"跑测试"阶段。它让Agent具备元认知能力——思考自己的思考。

Reflect阶段评估三个维度：

任务完成度：目标g是否已经达成？还需要哪些子目标？
动作有效性：刚才的Action是否产生了预期效果？有没有副作用？
计划修正需求：原计划π_t是否需要调整？有没有更好的路径？

视觉化描述：想象Agent面前有一面镜子。Act阶段是Agent在镜子前做动作，Reflect阶段是Agent看着镜中的自己问：“我刚才那一下，动作标准吗？离目标更近了吗？”

在机票预订场景中，Reflect可能发现：“搜索结果返回了3个航班，但最便宜的那个起飞时间是7:30，违反了’不早于9点’的约束。因此任务完成度δ_task = 0.67（部分完成），需要重新进入Plan阶段，增加筛选条件。”

这就是反馈驱动的核心：Reflect的输出不是答案，而是控制信号——决定列车是继续开（CONTINUE）、掉头重开（REPLAN），还是进站停车（TERMINATE）。

3. 微观视角：状态如何在循环中流转？

现在我们已经了解了四个阶段的功能，接下来看看它们内部的状态是如何像水流一样传递的。别急，这部分我们从一个极简的toy example开始，再推广到真实规模。

3.1 Toy Example：两维状态向量

假设我们有一个极简Agent，它的世界只有两个维度：“知道多少”（knowledge）和"还剩多少步"（budget）。状态向量s_t = [k_t, b_t]。

初始状态：s₀ = [0, 5]（什么都不知道，还剩5步预算）。

第一轮循环：

Observe：收到用户查询"巴黎天气"，o₁ = [查询内容, ∅]
Plan：计划 = [搜索, 总结]，π₁ = ⟨search, summarize⟩
Act：执行search，获得结果"晴，22°C"，r₁ = “晴，22°C”
Reflect：检查——"得到天气了吗？是的。需要重规划吗？不需要。任务完成吗？还没，需要总结。"输出CONTINUE。

状态转移：s₁ = [1, 4]（知识+1，预算-1）。

第二轮循环：

Observe：观察到上一轮结果"晴，22°C"，以及剩余任务"总结"
Plan：计划 = [生成建议]，π₂ = ⟨generate_advice⟩
Act：执行generate_advice，输出"无需带伞"
Reflect：检查——"用户问题被回答了吗？是的。预算还有吗？还剩3步。可以终止。"输出TERMINATE。

如果画成图会是什么样子？ 想象两个水槽，一个叫"知识槽"，一个叫"预算槽"。每转一圈，知识槽流入一些新信息，预算槽漏掉一点水。Reflect就像水位监测器，决定什么时候关闸。

3.2 推广到真实规模：上下文窗口作为"记忆水槽"

在真实LLM-based Agent中，状态不是两个数字，而是整个上下文窗口（context window）中的token序列。让我们看看状态如何在循环中精确流转。

每一轮循环，上下文C_t都会追加新的轨迹片段：

C<sub>t</sub> = [系统提示, 用户目标, o<sub>1</sub>, π<sub>1</sub>, a<sub>1</sub>, r<sub>1</sub>, ρ<sub>1</sub>, o<sub>2</sub>, π<sub>2</sub>, a<sub>2</sub>, r<sub>2</sub>, ρ<sub>2</sub>, ...]

这和RNN的隐藏状态h_t = f(h_t-1, x_t)惊人地相似，只不过这里的"状态更新函数"是LLM的自回归生成，而"状态向量"是明文文本轨迹。

问题驱动：这里有一个隐蔽的瓶颈——如果上下文窗口有限（比如8K tokens），循环十几轮后就会溢出。怎么办？Reflect阶段同时承担记忆压缩的职责：把早期轮次的细节总结成摘要，释放token预算。这就像操作系统的内存分页机制，把不活跃的页换出到磁盘（长期记忆向量库）。

4. 结构化伪代码：OPAR循环的精确描述

好了，现在我们已经了解了直觉和状态流转，接下来看看如果用结构化伪代码描述OPAR循环，会是什么样子。这会比你想象的更简洁，因为循环的本质就是重复。

4.1 主控制循环

算法 1: OPAR主循环
输入: 用户目标 G, 环境接口 ℰ, 最大迭代次数 T<sub>max</sub>, 工具库 𝒯
输出: 最终答案 A, 执行轨迹 τ

 1: procedure OPAR_EXECUTE(G, ℰ, T<sub>max</sub>, 𝒯)
 2:     τ ← ∅                           ▷ 初始化空轨迹
 3:     C ← INITIALIZE_CONTEXT(G)       ▷ 加载系统提示与目标
 4:     t ← 0
 5:     
 6:     while t < T<sub>max</sub> do
 7:         t ← t + 1
 8:         
 9:         ▷ ====== 第一步: Observe ======
10:         o<sub>t</sub> ← OBSERVE(ℰ, C, τ)       ▷ 感知环境，融合上下文
11:         C ← C ⊕ o<sub>t</sub>                   ▷ 追加观察至上下文
12:         
13:         ▷ ====== 第二步: Plan ======
14:         π<sub>t</sub> ← PLAN(C, G, 𝒯)           ▷ 生成或调整计划
15:         C ← C ⊕ π<sub>t</sub>                   ▷ 追加计划至上下文
16:         
17:         ▷ ====== 第三步: Act ======
18:         a<sub>t</sub> ← SELECT_NEXT_ACTION(π<sub>t</sub>) ▷ 提取当前步骤
19:         r<sub>t</sub> ← EXECUTE(a<sub>t</sub>, ℰ, 𝒯)     ▷ 执行动作，获取原始结果
20:         C ← C ⊕ a<sub>t</sub> ⊕ r<sub>t</sub>             ▷ 追加动作与结果
21:         
22:         ▷ ====== 第四步: Reflect ======
23:         ρ<sub>t</sub> ← REFLECT(C, G, r<sub>t</sub>, π<sub>t</sub>)  ▷ 评估与元认知
24:         C ← C ⊕ ρ<sub>t</sub>                   ▷ 追加反思
25:         τ ← τ ⊕ ⟨o<sub>t</sub>, π<sub>t</sub>, a<sub>t</sub>, r<sub>t</sub>, ρ<sub>t</sub>⟩ ▷ 更新轨迹
26:         
27:         ▷ ====== 循环控制 ======
28:         if ρ<sub>t</sub>.status = TERMINATE then
29:             A ← EXTRACT_ANSWER(C)
30:             return (A, τ)
31:         else if ρ<sub>t</sub>.status = REPLAN then
32:             CONTINUE                 ▷ 下一轮将生成全新计划
33:         else
34:             CONTINUE                 ▷ ρ<sub>t</sub>.status = CONTINUE，沿计划推进
35:         end if
36:     end while
37:     
38:     A ← EXTRACT_ANSWER(C)            ▷ 达到最大迭代次数，强制终止
39:     return (A, τ)
40: end procedure

注意看第28-35行的控制逻辑。Reflect阶段输出的不是一个简单的"好/坏"，而是一个控制信号（control signal），直接决定循环的分支。这就像一个CPU的跳转指令：TERMINATE是HALT，REPLAN是JMP到Plan阶段，CONTINUE是NOP继续顺序执行。

4.2 Reflect阶段的内部展开

Reflect看起来像一个黑盒，对吧？让我们把它拆开。

算法 2: Reflect阶段
输入: 上下文 C, 目标 G, 执行结果 r, 当前计划 π
输出: 反思对象 ρ = (status, critique, memory_update)

 1: procedure REFLECT(C, G, r, π)
 2:     ▷ 子步骤 2.1: 任务完成度评估
 3:     δ<sub>task</sub> ← EVAL_GOAL_PROGRESS(C, G)
 4:     
 5:     ▷ 子步骤 2.2: 动作有效性评估  
 6:     δ<sub>act</sub> ← EVAL_ACTION_EFFECT(r, π.expected_outcome)
 7:     
 8:     ▷ 子步骤 2.3: 计划一致性评估
 9:     δ<sub>plan</sub> ← EVAL_PLAN_DEVIATION(π, r)
10:     
11:     ▷ 子步骤 2.4: 综合决策
12:     if δ<sub>task</sub> ≥ threshold<sub>complete</sub> then
13:         status ← TERMINATE
14:         critique ← "目标已达成，所有约束满足"
15:     else if δ<sub>plan</sub> > threshold<sub>drift</sub> ∨ δ<sub>act</sub> < threshold<sub>valid</sub> then
16:         status ← REPLAN
17:         critique ← GENERATE_CRITIQUE(δ<sub>plan</sub>, δ<sub>act</sub>)
18:     else
19:         status ← CONTINUE
20:         critique ← GENERATE_PROGRESS_NOTE(δ<sub>task</sub>)
21:     end if
22:     
23:     ▷ 子步骤 2.5: 记忆压缩（上下文管理）
24:     if LENGTH(C) > C<sub>max</sub> then
25:         memory_update ← SUMMARIZE_OLD_TRAJECTORY(τ<sub>old</sub>)
26:         C ← COMPRESS_CONTEXT(C, memory_update)
27:     else
28:         memory_update ← ∅
29:     end if
30:     
31:     return (status, critique, memory_update)
32: end procedure

锚定已知概念：Reflect的评估函数EVAL_GOAL_PROGRESS、EVAL_ACTION_EFFECT很像强化学习中的奖励函数（Reward Function）。不同之处在于，强化学习的奖励通常是标量信号（比如+1/-1），而OPAR中的Reflect输出的是结构化诊断报告，包含文本级别的批评建议（critique），这些文本会直接流入下一轮Plan阶段，成为"可读的梯度信号"。

5. 迭代执行与反馈驱动：OPAR的"动力系统"

5.1 为什么需要迭代？一次性规划不行吗？

先用一个设问开头：如果你开车去一个从未去过的地方，你会在出发前把每一个转弯都精确计划好，还是每开一段就看一下导航？

Agent面对的真实世界就像那个未知的城市——充满了部分可观察性（partial observability）和动态变化。OPAR的迭代执行不是为了炫技，而是因为初始计划几乎必然包含错误假设。

视觉化描述：想象OPAR循环是一个弹簧-阻尼系统。每一次Reflect发现偏差，就像弹簧被压缩，产生一个"恢复力"推动Agent在下一次Plan中修正轨迹。没有Reflect的循环就像没有阻尼的简谐振动——Agent会围绕目标震荡，永远停不下来。

5.2 反馈驱动的三种模式

反馈不是单一的。在OPAR中，反馈有三种时间尺度：

反馈类型	来源	作用时机	类比
即时反馈	Act阶段的API返回值	当前轮次Reflect	神经网络的即时损失
短期反馈	几轮循环后的子目标达成度	每轮Reflect的δ_task	小批量梯度
长期反馈	整个任务结束后的用户评分	跨 episode 学习	强化学习的episode回报

渐进披露：先理解单轮反馈——就像你按电梯按钮，灯亮了（即时反馈）。再理解短期反馈——你等了30秒发现电梯没动，于是走楼梯（多轮调整）。最后理解长期反馈——你记住了这个写字楼电梯经常坏，下次直接走楼梯（长期记忆）。

6. 与ReAct和经典控制论的对话

6.1 OPAR vs ReAct： cousins with different personalities

你可能已经熟悉ReAct（Reason-Act-Observe）了。让我们把两者放在同一张图里比较。

关键区别：

ReAct的Reason是战术推理（“下一步做什么”），OPAR的Plan是战略规划（“接下来五步怎么做，以及每一步的退出条件”）。
ReAct的Observe是Act的直接结果，OPAR的Observe是环境的全局快照，包含比Act结果更多的上下文。
Reflect是OPAR独有的。ReAct没有显式的反思阶段，反思隐含在下一轮Reason中。OPAR把反思显式化，让它成为一个可以插入人类监督、外部评估器或安全护栏的检查点。

6.2 控制论的血脉：从Cybernetics到OPAR

OPAR不是凭空出现的。它的血脉可以追溯到1948年维纳（Norbert Wiener）提出的控制论（Cybernetics），以及工程中的闭环控制系统（Closed-Loop Control）。

锚定已知概念：如果你熟悉PID控制器（比例-积分-微分控制器），可以把OPAR的Reflect看作一个**“认知PID”**：

比例项（P）：当前轮次的误差（δ_task）——偏差多大？
积分项（I）：历史累积误差（轨迹中的重复失败模式）——是不是一直在同一个地方犯错？
微分项（D）：误差变化趋势（δ_task是否在缩小）——是在靠近目标还是远离目标？

Reflect根据这三项的综合判断，输出控制信号。这就是为什么OPAR比开环的"一次性规划"更鲁棒。

7. 多Agent场景下的嵌套OPAR循环

现在我们已经了解了单Agent的OPAR循环，接下来看看更复杂的场景。如果一个任务需要多个Agent协作，OPAR循环会发生什么变化？

问题驱动：想象你不是一个人在订机票，而是一个旅行规划团队——有人专门查航班，有人专门算积分，有人专门比价。团队怎么协作？

答案是：嵌套OPAR循环。每个子Agent运行自己的OPAR循环，而父Agent（Orchestrator）的Act阶段包含"调用子Agent"这一动作。

视觉化描述：想象一个俄罗斯套娃。大娃娃（Orchestrator）打开自己的Act阶段，发现需要调用小娃娃（子Agent）。小娃娃内部也有一个完整的OPAR循环，它转完自己的四步后，把结果塞回大娃娃的Observe阶段。大娃娃接着做自己的Reflect：“三个小娃娃都回来了，信息齐全吗？可以进入最终决策了吗？”

这种嵌套结构的伪代码如下：

算法 3: 多Agent嵌套执行
输入: 用户目标 G, 子Agent集合 𝒮 = {S<sub>1</sub>, S<sub>2</sub>, ..., S<sub>m</sub>}
输出: 最终答案 A

 1: procedure NESTED_OPAR(G, 𝒮)
 2:     C ← INITIALIZE_CONTEXT(G)
 3:     while true do
 4:         o ← OBSERVE(environment, C)
 5:         π ← PLAN(C, G)
 6:         
 7:         ▷ 检查计划是否需要子Agent
 8:         if π.contains_delegation then
 9:             for each (subtask, S<sub>i</sub>) ∈ π.delegations do
10:                 ▷ 子Agent运行完整OPAR循环
11:                 r<sub>i</sub> ← S<sub>i</sub>.OPAR_EXECUTE(subtask)
12:                 C ← C ⊕ r<sub>i</sub>
13:             end for
14:         end if
15:         
16:         ▷ Orchestrator继续执行自身Act（整合、决策）
17:         a ← SELECT_ACTION(π)
18:         if a.type = "FINAL_ANSWER" then
19:             return a.content
20:         end if
21:         
22:         r ← EXECUTE(a)
23:         ρ ← REFLECT(C, G, r, π)
24:         
25:         if ρ.status = TERMINATE then
26:             return EXTRACT_ANSWER(C)
27:         end if
28:     end while
29: end procedure

注意第11行：子Agent的调用是阻塞式的完整OPAR执行。Orchestrator会等待子Agent完成自己的Observe-Plan-Act-Reflect循环，拿到最终答案后，才继续自己的循环。这就像函数调用中的子程序返回。

8. 生产环境中的OPAR：这到底意味着什么？

好了，原理讲完了。但"这在训练/实际使用中意味着什么？"

8.1 在训练时意味着什么

OPAR循环不是通过端到端梯度下降"训练"出来的——至少目前还不是。它的四个阶段更像是**提示工程（Prompt Engineering）和编排（Orchestration）**的产物。但在训练视角下，有几点值得注意：

轨迹数据的价值：每一轮OPAR循环产生的轨迹τ = ⟨o, π, a, r, ρ⟩是宝贵的过程监督数据（Process Supervision）。你可以用这些轨迹去微调LLM，让它在Plan阶段生成更好的计划，在Reflect阶段做出更准确的判断。
奖励塑形（Reward Shaping）：Reflect阶段的评估函数δ_task, δ_act, δ_plan可以被设计为可微分的辅助损失函数，用于强化学习微调。这类似于AlphaGo中的价值网络——评估当前局面胜率。
上下文窗口即训练瓶颈：OPAR的循环深度受限于上下文长度。研究如何压缩早期轨迹（Reflect中的memory_update）本质上是在学习一个可微分的记忆读写机制，这是当前Agent研究的前沿。

8.2 在实际使用中意味着什么

如果你要在生产环境部署OPAR循环，这里有几个硬核建议：

生产要素	具体含义	最佳实践
终止条件	防止无限循环	设置T_max（如20轮）、token预算上限、时间超时
工具安全	Act阶段可能调用危险API	在Reflect阶段插入安全护栏（Guardrails），拦截高风险动作
可观测性	调试循环比调试单次调用难10倍	记录完整轨迹τ，使用结构化日志（thought/action/observation分离）
成本管理	每轮循环至少消耗1次LLM调用	在Plan阶段使用轻量级模型，仅在Reflect阶段使用强模型；或缓存计划
人机协同	不是所有决策都适合自动化	在Reflect的TERMINATE/REPLAN决策中插入人类在环（Human-in-the-loop）检查点