← 返回 PaperDaily 大模型与智能体

给LLM“乱打分”上保险！混合RL框架证明：奖励塑形不改变最优策略

这篇论文干了一件很“较真”的事：当大家都在用LLM给强化学习当“教练”时，它用数学证明了只要奖励塑形方式得当，教练再怎么“瞎指挥”，也改变不了最终的最优策略。不管是做LLM Agent还是RL的读者，都值得看看这份理论保障。

龙哥读论文发布于 2026-08-23 00:20:00 阅读 4 查看原文

#强化学习 #大语言模型 #Agent #人工智能

paperdaily_reaction_gif

原论文信息如下：

论文标题:
Policy-Invariant Reward Shaping from LLM Feedback: A Framework for Hybrid RL Agents（基于LLM反馈的策略不变奖励塑形：一种混合RL智能体框架）

发表日期: 2026年08月
发表单位: African Institute for Mathematical Sciences, Rwanda; AIRINA Labs; Sefako Makgatho Health Sciences University; African Center for Advanced Studies
原文链接: https://arxiv.org/pdf/2608.18008v1.pdf
开源代码链接: 原文提供参考实现（详见论文4.6节）

想象一下这个场景：你让一个只会“纸上谈兵”的导航员给一位经验丰富的司机指路。导航员说“前面右转”，但司机明明看到右边是死胡同。这时候该听谁的？如果把导航员换成大语言模型（LLM），把司机换成强化学习（RL）智能体，问题就变成了学术圈最热门的交叉方向之一：LLM规划能力与RL控制能力的结合。但这里一直有个隐忧——LLM给的指引如果本身是错的，会不会把RL智能体带沟里去？

这篇来自非洲多个研究机构合作的论文，就是来给这个隐忧上“保险”的。它不是再提出一个新的LLM+RL框架，而是从理论层面回答了一个更根本的问题：当我们用LLM的反馈来塑造奖励函数时，这些反馈是否安全？会不会因为LLM的“胡言乱语”导致RL智能体再也学不到最优策略了？

当LLM遇上强化学习：一个理论严谨的混合框架

先聊点背景。在“LLM+RL”这个大家族里，各路神仙的做法五花八门：有让LLM当纯规划器输出子目标列表的（比如SayCan、ReAct），有让LLM生成稠密奖励代码的（比如Text2Reward、Eureka），还有更极端的直接把LLM当策略网络用PPO去更新的（比如GLAM）。

但无论是哪一派，都绕不开一个问题：LLM的输出有对有错，那么由LLM反馈构成的奖励信号，会不会把RL智能体带到错误的最优策略上去？

本文的出发点就是对这个问题的“定点”求解。作者将LLM规划器与RL控制器的混合架构，形式化为一个目标增强马尔可夫决策过程，并利用经典的势函数奖励塑形理论，证明了策略不变性——无论LLM的评分有多“离谱”，最优策略集合都不会被改变。

为了看清整个框架的数据流，可以先看下面这张整体架构图。

图1：框架总览。实线表示单步数据流：环境发出状态s_t及其说明phi(s_t)；LLM规划器产生当前子目标g_t和有界势函数值Phi(s,g)；RL策略pi_theta基于状态s_t和子目标g_t选择动作a_t；塑形项F=γΦ(s',g)-Φ(s,g)被加到环境奖励上。虚线表示周期性数据流：记忆驱动策略更新，并按照4.4节的时间表触发计划修订。

框架总览。实线表示单步数据流：环境发出状态s_t及其说明phi(s_t)；LLM规划器产生当前子目标g_t和有界势函数值Phi(s,g)；RL策略pi_theta基于状态s_t和子目标g_t选择动作a_t；塑形项F=γΦ(s',g)-Φ(s,g)被加到环境奖励上。虚线表示周期性数据流：记忆驱动策略更新，并按照4.4节的时间表触发计划修订。

问题背景及相关工作：当“教练”变成“毒奶”

先看一个经典案例。SayCan让LLM根据机械臂的“可用技能”来规划任务步骤，Inner Monologue则把环境反馈的文字描述回灌给LLM做闭环修正。这些方法在实验中都取得了不错的效果，但它们的共同特点是：用LLM的输出作为高层指导，让底层策略去执行。

问题出在奖励塑造环节。Text2Reward和Eureka这类方法，是让LLM直接写稠密奖励函数的代码。LLM写的奖励函数中看不中用怎么办？论文引用了一项研究结论：当LLM对奖励函数的描述不准确时，非势函数的稠密奖励确实会改变最优策略。一个典型的非势函数塑形是“进度奖励”

你可以理解为：教练告诉运动员“跑快一点加10分”，但教练判断“快慢”的尺子本身是坏的。运动员为了拿分，可能把动作练变形了。

与这些“野蛮生长”的LLM-as-Reward方法相比，本文回到了强化学习理论中最经典的一块基石：势函数奖励塑形。Ng、Harada和Russell在1999年就证明过，如果施加的塑形项可以表示为某个势函数在相邻状态上的差值（F = γΦ(s') - Φ(s)），那么最优策略集合保持不变。

本文的巧妙之处，就是把LLM的“评分”直接定义为这个势函数Φ，从而让1999年的定理为2026年的LLM+RL框架“保驾护航”。

核心设计：把LLM反馈“装进”势函数的框子里

整个框架的设计思路非常模块化，主要包含三个核心组件。第一个是LLM规划器，它接收任务描述和当前状态的文字说明，输出一个有序的子目标列表。第二个是RL控制器，它接收环境状态和当前子目标，输出具体的动作，控制器会为每个子目标编码并输入策略网络。第三个是完成度测试器——论文中称为Done-oracle，负责判断当前子目标是否已完成。

其中最关键的设计是，LLM规划器不仅要输出子目标，还要输出一个进度分数——这个分数被定义为势函数Φ(s, g)。然后塑形项F = γΦ(s', g) - Φ(s, g)被加到环境奖励上。

为了让大家更清楚地理解这个设计，可以用一个“导航+司机”的比喻来说明：LLM规划器就像导航软件，它负责规划“前方300米右转”这样的宏观路线；RL控制器就是司机，负责具体的方向盘和油门操作。此时Done-oracle就是副驾驶的语音提醒“你已到达目的地”，负责判断导航规划的每个小目标是否达成。势函数塑形则是一个温和的引导机制——即使导航软件偶尔抽风让你“往河里开”，司机也不会把车真的开进河里，因为最终的最优路线集合没有变。

有趣的是，Done-oracle的实现方式有三种：环境事件标志、学习得到的MLP分类器、以及LLM本身。这个设计为后续实验中的失败诊断埋下了伏笔——不同实现方式之间的词汇不匹配，会让整个系统“卡壳”。

核心原理推导：势函数塑形如何保证策略不变性

这部分需要一点数学直觉，但龙哥尽量讲得通俗些。

先定义目标增强MDP。它是在原始MDP的基础上，把状态空间扩展为“环境状态 × 子目标”的乘积空间，状态转移包括环境状态转移和子目标更新两部分。子目标更新由Done-oracle决定——当子目标完成时指针前进到下一个子目标。

接下来是文章的核心命题，它的证明思路很直接：由于F是势函数的 telescoping 差分，增强MDP下的总回报可以分解为原始MDP的总回报、加上势函数的初始值偏移、再减去一个趋于零的尾项。因为Φ是一个有界的函数且折扣因子γ小于1，随着时间趋于无穷，γ^T·Φ(s_T, g_T)会趋于零。因此，最大化增强MDP回报的策略集合，与最大化原始MDP回报的策略集合完全一致。

为了让大家更直观地回顾这个证明的核心，可以看下面这个公式的推导过程：

J̃(π) = J(π) - Φ(s₀, g₀) + lim_{T→∞}γᵀΦ(s_T, g_T) = J(π) - Φ(s₀, g₀)

从公式可以看出，塑形只改变了回报函数的一个常数偏移量，对策略排序没有任何影响。这就是为什么即使LLM的评分完全错误，也不会改变最优策略集合。一个糟糕的评分最多是让学习过程变慢，但不会把agent带到错误的最优策略上去。

论文还做了一个非常“较真”的数值验证：在一个3状态2动作的确定性MDP上，测试了四种不同的势函数配置，包括一种完全反向的势函数和一种幅度是基础奖励20倍的对抗性配置。结果显示所有配置都保持了基础最优策略不变。

表1：命题4.1的数值验证。四种势函数配置，包括每个状态值的绝对值为基础奖励10-20倍的配置，都保持了基础最优策略。塑形后的价值V*按定理预测的势函数偏移量-Φ(s0)加上一个消失的telescoping尾项进行偏移。

表1：命题4.1的数值验证。四种Φ配置，包括一个每状态势函数值为基础奖励10-20倍的对抗性配置，都保持了基础最优策略不变。塑形后的价值Ṽ*按定理预测偏移-Φ(s₀)，加上一个消失的望远镜尾项。

从理论到代码：参考实现与算法细节

光有理论还不够，论文还发布了一套可直接运行的参考实现。这套代码把第4节的每个定义都对应成了一个模块：Planner（规划器）、PotentialShaper（势函数塑形器）、SubgoalScheduler（子目标调度器）、ReplanTrigger（重规划触发器）。接口都是类型化的，方便替换实现。

在工程实现上，有几个值得点赞的细节。第一，它支持Ollama本地部署的模型（Qwen、Llama），也支持云端LLM后端，这意味着没有GPU的研究者也能先在CPU上把整套流程跑通。第二，它内置了三种Done-oracle：环境事件标志（environment event flags）、学习得到的MLP分类器、以及LLM完成度提示（LLM completion prompt）。第三，它带了26个单元测试，其中包括一个在2状态MDP上对命题4.1的数值验证。

整个推理流程由一个主循环串起来。算法先让LLM生成初始计划，然后在每个环境步骤中，把当前子目标传给RL策略选动作，观测转移和奖励，再加上势函数塑形项，接着用Done-oracle判断当前子目标是否完成。如果完成了，子目标指针前进；如果长时间没完成（超过预算B），就触发一次失败驱动的重规划；另外每H个环境步骤还会做一次周期性重规划。伪代码如下：

输入：任务ℓ，初始状态s₀，策略π_θ，LLM，Done-oracle，势函数Φ，周期H，预算B
初始化：t←0, k←1, b←0
生成初始计划：πᴴ = (g₁, …, g_K) ~ p_LLM(· | ℓ, φ(s₀))
循环直到回合结束：
    当前子目标：g_t ← g_k
    选择动作：a_t ~ π_θ(· | s_t, g_t)
    执行动作，观测s_{t+1}和r_t
    计算塑形奖励：r̃_t ← r_t + γΦ(s_{t+1}, g_t) - Φ(s_t, g_t)
    如果 Done(s_{t+1}, g_k) = DONE：
        k ← min(k+1, K)；b ← 0   // 子目标指针前进
    否则：
        b ← b + 1
        如果 b ≥ B：触发失败重规划；b ← 0
    如果 t mod H = H-1：触发周期重规划
    t ← t + 1

这个算法本身就是论文理论的形式化落地——每个步骤都能对应到GA-MDP的定义上。更贴心的是，整个流程在CPU上就能端到端跑通，GPU只在大规模实验时才需要。这种“理论-算法-代码”三者一一对应的设计，在AI论文里确实不多见。

小规模验证：规划器审计与管道测试

论文没有做那种大规模多基准的炫目实验，而是老老实实地分两步走：先单独审计LLM规划器的输出质量，再做一个端到端的管道验证。

规划器审计用的是MiniGrid环境，这是一个经典的二维网格世界套件，用来测试智能体完成导航、取物、开门等组合任务的能力。论文挑选了20个任务，为每个任务手工标注了ground-truth子目标分解，然后用本地部署的Qwen-2.5:14b模型（通过Ollama加载）对每个任务生成计划，再自动评估计划质量。结果见下表：

表2：Qwen-2.5:14b（本地部署）在20个MiniGrid任务上的规划器独立审计。提示模板：P1（附录A）。

从指标上看，Qwen-2.5:14b的表现相当有意思：解析率100%，也就是每个任务都输出了可解析的计划，没有一例格式崩坏；平均ground-truth覆盖率为54.8%，也就是生成的子目标里约一半多和人工标注吻合；但平均每个计划里有5.3个额外子目标，计划偏冗长——模型喜欢输出“Turn left to face the wall”这类过细的低级动作描述，而不是“go to the key”这样简洁的目标描述。计划长度中位数7个，而ground-truth平均只有3.6个，确实啰嗦了不少。

这个发现其实已经为后面的失败埋下了伏笔。规划器输出的是“面向动作过程”的描述，而环境事件标志类Done-oracle匹配的是“面向结果”的关键词，两者之间的词汇鸿沟会导致一个严重后果。别急，这部分马上会讲。

端到端管道验证选的是MiniGrid-DoorKey-6x6环境。这个任务要求智能体先走到钥匙旁边、捡起钥匙、走到门前、用钥匙开门、最后走到目标格子，是一个教科书级别的组合任务。论文设置了两个配置：纯PPO基线（不用LLM）和混合框架实例（Qwen-2.5:14b做规划器）。每个配置3个随机种子，每个种子训练3万环境步。结果见下表：

表3：MiniGrid-DoorKey-6x6上的管道验证结果。所有运行的LLM预算：92次Qwen-2.5:14b调用、4,199个输出token、1.32小时的Ollama CPU运行时间。两种配置在该预算下都未收敛到高成功率；DoorKey-6x6的PPO收敛通常需要大约5×10⁵环境步，而本次试点只使用了3×10⁴步。

从数字上看，PPO基线的成功率是28.1%，置信区间[4.8, 65.2]，方差很大；混合配置只有9.3%，置信区间[0.0, 14.3]。最终回报和平均回合步数两者差不多。但这里要注意论文反复强调的一个背景：DoorKey-6x6通常需要大约5×10⁵环境步PPO才能收敛，而这次试点只跑了3×10⁴步——差了整整一个数量级。在这么短的预算下，两边都远未收敛，因此这个对比不构成“谁比谁强”的证据。

实际上，混合配置的LLM调用次数控制得非常好：得益于计划缓存设计，每个种子只需要大约30次LLM调用。全部运行加起来总共92次Qwen调用、4199个输出token、1.32小时的CPU推理时间。这说明这套框架在工程成本上是可控的。

失败诊断：Done-oracle词汇不匹配问题

这篇论文最诚实、也最让人佩服的地方来了。在管道验证中，作者发现了一个明确的失败模式：混合配置的所有三个种子里，子目标指针的推进次数全部为零。整个训练过程中，子目标调度器始终卡在第一个子目标上，一步都没有前进过。

原因非常有意思。Qwen-2.5:14b在MiniGrid任务里输出的子目标，是“Move down to reach the wall”（向下移动到达墙壁）、“Turn left to face east again”（左转再面朝东）这种面向过程、低层级的表述；而环境事件标志类Done-oracle匹配的是面向结果、高层级的关键词模式，比如“pick up X”（捡起X）、“unlock the door”（开门）、“go to the goal”（走向目标）。两边说的完全是两种“语言”，于是Done-oracle永远返回CONTINUE，调度器永远不推进。

这直接导致两个后果。第一，RL策略从头到尾只看到第一个子目标的文本嵌入，子目标条件化信号从一开始就退化成常量，等于“条件”没起作用。第二，这个失败模式恰恰是论文第6节在理论上预先指出的风险——子目标完成不匹配（Subgoal-Completion Mismatch）：当Done-oracle的词汇表与LLM计划的措辞不一致时，调度器就会卡死。理论预言和实际观测完美对上，这种“被自己的理论说中”的体验，做研究的人都懂。

怎么解决？论文给出了选项：换用LLM自己当Done-oracle。让LLM基于语义判断子目标是否完成，而不是靠关键词硬匹配。但代价是每个环境步都要调用一次LLM，在CPU上跑14B模型完全不现实，这个方案在本文的计算条件下不可行。这也解释了为什么论文在管道验证中选择了禁用塑形（c=0）——CPU推理14B模型如果每步调用两次LLM，训练周期会从几天变成几周。塑形项的理论验证靠的是第4节的严谨证明和数值检查，而不是在线实验。

尽管混合配置在成功率上没有占到便宜，管道验证还是确认了几个重要的工程事实：参考实现能在CPU上端到端跑完9万环境步无异常；MiniLM-L6-v2的子目标编码能和PPO无缝集成；计划缓存把LLM调用压到每个种子约30次；日志系统和IQM（插值分位数均值，Interquartile Mean）加Bootstrap置信区间分析管线输出稳定。这些都为后续大规模实验扫清了工程障碍。

未来展望：大规模实验与开放问题

这篇论文对自己的定位非常清醒，在摘要和正文里反复强调：它不声称这套混合架构在任何基准上打败了现有方法。大规模对比实验（涉及BabyAI、ALFWorld、Crafter多个环境、多个基线、更多随机种子、云LLM算力）是计划中的后续工作。

这种克制是明智的。论文的核心贡献是理论保证，是“如果混合方法work，那么它的不动点正确性是有构造性保证的，而且这个保证不需要信任LLM”。这句话的含金量在于：它把“LLM反馈是否安全”这个原本只能靠经验判断的问题，变成了一个可以靠构造保证的问题。

但也必须看到，策略不变性解决的是“定点正确性”，不是“收敛速度”。一个糟糕的势函数可以让你学得极其缓慢，甚至在有限时间内完全看不到进展——试想一个反向的势函数把探索引导到完全无关的区域，虽然理论上最优策略集合没变，但实际训练可能永远到不了那个最优。论文明确承认了这一点：“A bad Φ can slow learning arbitrarily”。

此外，论文还预告了三个需要实操中监视的失败模式：LLM评分偶尔跑出[0,1]区间可能导致塑形不再是严格势函数形式；Done-oracle词汇不匹配导致调度器卡死（已经在实验中亲身踩过）；以及失败触发的重规划如果频繁发生，LLM调用成本会随回合长度线性增长。这些“排雷指南”对复现和后续研究都非常有价值。

未来的开放问题也很明确：在真正的多基准大规模评测中，混合架构能否带来样本效率提升？LLM-based Done-oracle在GPU算力充裕时能否彻底解决词汇不匹配问题？势函数的质量（比如和真实进度的一致性）有没有办法自动评估和校准？以及，非势函数的LLM奖励到底在什么条件下会破坏最优策略——有没有可能给出一个可操作的判定准则？这些问题的答案，可能决定“LLM+RL”这个方向能走多远。

从PaperDaily已收录的相关工作来看，目前LLM+RL方向的主流方法大多默认“LLM给的奖励越密越好”，但对错误奖励的代价缺少理论刻画。本论文给出的一种“设计即安全”的思路——把LLM奖励限制在势函数类中——确实是低成本获得安全性的手段。不过也要注意，MiniGrid-DoorKey-6x6上的结果并不构成性能优势证明，管道验证的定位是“能跑通+复现了理论预言的失败”，而非“效果好”。结合PaperDaily已收录的其他MiniGrid研究观察，不同实验设置（环境版本、训练步数、种子数）下结论可能差异很大，不能简单地把这类结果外推为“混合方法更好”。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底在解决什么问题？本文提出一种基于LLM反馈的势函数奖励塑形框架，将其形式化为目标增强MDP，并证明只要LLM的评分作为有界势函数，无论评分多离谱，都不会改变最优策略集合。该研究为LLM与强化学习的结合提供了理论安全保障。

这篇工作最值得看的点是什么？规划器独立审计中Qwen-2.5:14b达到100%解析率、54.8%覆盖率；管道验证中混合方法成功率9.3%低于PPO基线28.1%，但置信区间重叠，且诊断出Done-oracle词汇不匹配的集成失败

这篇工作的边界或风险在哪里？优点：理论保证强（策略不变性），模块化设计清晰，可审计性强，对LLM错误鲁棒；缺点：经验验证规模极小（仅3种子×3万步），未显示混合方法优势，规划器覆盖率低（54.8%），子目标冗长导致Done-oracle不匹配，未在标准基准上比较

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

将LLM规划器与RL控制器混合架构形式化为目标增强MDP（GA-MDP），并证明当LLM的逐状态进度分数作为有界势函数时，基于势的奖励塑形项不改变增强MDP的最优策略集合。

实验合理度：★★★★☆

成功率（Success rate）、最终回报（Final return）、平均每回合步数（Mean steps/episode）、LLM调用次数、解析率（Parse rate）、覆盖率（Coverage）

学术研究价值：★★★★☆

将LLM规划器与RL控制器混合架构形式化为目标增强MDP（GA-MDP），并证明当LLM的逐状态进度分数作为有界势函数时，基于势的奖励塑形项不改变增强MDP的最优策略集合；更关键的是问题定义是否可复用到同类任务。

稳定性：★★★☆☆

现有材料未提供充分的极端条件、重复运行或扰动测试，稳定性暂按中性评价。

适应性以及泛化能力：★★★☆☆

现有材料未完整展示跨数据集、跨场景或分布外实验，泛化能力仍需进一步验证。

硬件需求及成本：★★★☆☆

CPU可运行端到端；MiniGrid-DoorKey-6x6实验中每种子约30次LLM调用，92次Qwen-2.5:14b调用共1.32小时Ollama CPU墙钟时间

复现难度：★★★☆☆

https://github.com/（原文未给出具体URL）

产品化成熟度：★★★☆☆

论文验证以研究实验为主，真实部署中的时延、成本、维护和异常场景仍需补充验证。

可能的问题：经验验证规模极小（仅3种子×3万步），未显示混合方法优势，规划器覆盖率低（54.8%），子目标冗长导致Done-oracle不匹配，未在标准基准上比较

主要参考文献

[1] Ng A Y, Harada D, Russell S. Policy invariance under reward transformations: Theory and application to reward shaping[C]. ICML, 1999.

[2] Ichter B, et al. SayCan: Do as you can, not as you say: Grounding language in robotic affordances[C]. CoRL, 2022.

[3] Yao S, et al. ReAct: Synergizing reasoning and acting in language models[C]. ICLR, 2023.

[4] Xie T, et al. Text2Reward: Reward shaping with language models for reinforcement learning[J]. arXiv:2309.11489, 2023.

[5] Ma Y J, et al. Eureka: Human-level reward design via coding large language models[C]. ICLR, 2024.

[6] Booth S, et al. On the impact of reward shaping on the performance of deep reinforcement learning agents[J]. 2023.

[7] Hounwanou C D, Eze J E, Gaba Y U. Policy-Invariant Reward Shaping from LLM Feedback: A Framework for Hybrid RL Agents[J]. arXiv:2608.18008, 2026.

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！