从百丽败局到强化学习落地：奖励函数与架构设计的底层逻辑

我在2025年9月把一个偏底层的机器人强化学习代码库整理成了开源项目，仓库名叫 delta-rl-stack。做这个项目的过程里，我反复想起一个跟机器人八竿子打不着的商业案例：百丽数字化败局。这两件事放在一起看，底层逻辑出奇地一致——都死在"把新技术贴在了旧系统的表面"。

百丽当年在国内女鞋市场的体量，用"巨无霸"来形容一点不夸张，门店网络密到近乎毛细血管级别。可就是这么一家企业，面对电商冲击和消费习惯变化，数字化做出的成绩和它的体量并不匹配。做技术的人看这个案子，很容易得出"行业不同，参考有限"的结论，但如果你认真扒一遍百丽踩过的坑，再回头看看自己 debug 奖励函数的经历，会发现两者是同一个剧本。所以这篇系列的第一篇，我想把这两条线拧到一起讲。适合谁看？正在做机器人控制、强化学习落地，以及想搞清楚"为什么我的模型越训练越偏"的工程师，还有关注零售数字化、供应链模式的商业观察者。

1. 百丽数字化败局，到底败在哪

1.1 数字化不是在老流程上装新工具

业内复盘百丽转型失败时，普遍提到的一个判断是：百丽不是没投数字化，而是把数字化做成了"给老流程加传感器"。它最不缺的是渠道，最引以为傲的是门店网络和供应链深度，所以早期数字化动作几乎都围绕"让传统链路跑得更快"展开——上 ERP、上 CRM、做会员系统、做门店数据上报，本质上是给既有业务装监控探头和加速器。

问题就在这儿。这套传统链路的骨架是"总部预测市场，工厂批量生产，层层批发到门店，最后卖给消费者"。数字化再怎么加，也还是这条单线链路。总部看到的数据多了，但决策逻辑没变；门店的库存可以上报了，但调拨机制没变。这就像你给一台老旧的生产线装了一堆传感器，数据大屏上啥都有，但产线本身还是按老规矩在跑。

技术圈的人对这件事应该很有共鸣。很多团队做强化学习落地，习惯性动作是"在传统控制外面套一个 RL 层"——底层还是 PID，上层加个策略网络去调参，或者直接用一个 RL 算法去替代某个局部模块，整个任务定义、约束条件、状态空间设计全都没动。结果通常是在仿真里看着还行，换到真实任务就废。不是 RL 不行，是架构没变，你只是给旧系统装了个新马达。

1.2 预测式生产遇上需求碎片化，库存成了黑洞

再往深一层拆，百丽真正的死穴在于它的经营模式根上。女鞋这个品类 SKU 极多、款多量少、季节性强，过去需求稳定，消费者选择有限，"总部预测市场 + 大批量生产 + 密集铺货"是能赚钱的。可当需求碎片化之后，预测命中率直线下降，一个款式造多了就变成全国各地的库存，造少了又没法补单。库存这个黑洞，把利润一点点吃掉。

更难受的是，线下数千家门店的库存彼此不互通。A 城断码缺货，B 城积压成山，总部只能看到汇总数字，却很难及时做出跨区域调拨。数字化在这里并没有真正改变供需的连接方式，它只是让错误的事情做得更快了。系统能实时告诉你库存积压了多少，但不会告诉你下一步该怎么重构供给。

这个场景放到机器人强化学习任务里，等价于什么？等价于你的奖励函数设计和物理约束没有对齐。仿真里策略跑得飞快，但真实工作空间的限制、执行器的速度上限、夹爪的接触约束，全都没进奖励函数。你在仿真里训练一万步，等于用错误的目标函数做预测，预测得越准，离真实目标越远。百丽用庞大的数字化系统精准地预测了一个不再存在的稳定需求市场，你用完美的训练曲线收敛到一个真机根本用不了的策略，本质上是一件事。

2. S2B2C破局之道：把供应链从控制塔变成赋能平台

2.1 S2B2C到底是什么：平台赋能小B，一起服务消费者

S2B2C 是曾鸣提出的一个模式，S 是 Supply Chain Platform（供应链平台），B 是 Business（小 b），C 是 Consumer（消费者）。它和传统的"总部-加盟商-消费者"链式批发有本质区别：S 平台把库存、数据、物流、金融服务打包成能力，赋能给小 b 门店，让小 b 能灵活地服务 C 端消费者。

我举个例子你就明白了。假设几百家门店共享同一盘货，A 店缺一个尺码，B 店正好有，平台实时调度，直接从最近的门店发货给消费者；消费者在任意门店或者小程序下单，总部仓库或者附近门店就能履约。传统模式下，门店之间是竞争关系，货到了经销商手里就跟总部没太大关系了；而 S2B2C 模式下，门店变成了平台上的服务节点，货权还在平台上流动，小 b 不需要自己扛库存，只需要做好对消费者的服务。

这个模式的精髓不是干掉中间商，而是让中间商变得更强大。小 b 的门店不用再花大量资金囤货，平台承担供应链重活，门店专注做个性化推荐、灵活调价、快速反馈。数据不再只是往总部汇总的报表，而是回流到每个门店，指导店员怎么推荐、什么时候调价、哪个款式该补货。整个系统从"控制塔式"的单向指挥，变成了"网络协同式"的多向赋能。

2.2 从商业破局到技术破局的三个翻译原则

我在拆解 S2B2C 的时候，脑子里一直在做翻译：如果把一个机器人强化学习系统也看成一条供应网络，物理模型和仿真环境是平台层，策略网络和控制器是前端的小 b，真实任务需求是 C 端消费者。这样一来，S2B2C 的破局原则几乎可以逐条落到技术架构上。

第一条，中台是能力聚合器，不是控制指挥塔。百丽过去的问题是把数据往总部收、把决策权也往总部收，结果前端门店缺乏灵活性。对应到机器人项目，动力学模型、仿真环境、奖励函数模板这些"中台能力"应该做成稳定、可靠、可复用的底座，而不是让策略网络每一步动作都要全局重规划一遍。你提供能力，不控制细节。

第二条，前端要有决策权和灵活性。门店可以根据本地情况灵活调价、推荐、服务，对应的就是策略网络要在推理时自主决策，而不是每个动作都依赖一个中心节点算完再下发。这正好也契合了资源受限机器人的需求——边缘设备上跑推理，策略必须轻量、自主、实时。

第三条，数据要往终端流，而不只是往总部收。百丽的数据报表对总部管理有用，但对门店的日常经营帮助不大。放到机器人系统里，真实任务反馈应该是闭环回到训练环节的：部署后的失败案例、传感器数据、任务达成率，都应该成为下一轮奖励函数修正和模型更新的输入。不然你训练出来的模型就是一套自嗨的报表，跟真实脱节。

3. 开源项目 delta-rl-stack：从商业教训到模块架构

3.1 项目定位与仓库结构

带着这三个翻译原则，我把 delta-rl-stack 的项目结构设计成了四个模块：envs/sim 负责仿真环境封装，models/dynamics 放 delta 机器人动力学方程，algorithms/ 放 SAC、PPO、IQL 这些训练算法，tools/reward_design 放奖励函数设计与审计工具。核心设计思路是：把动力学方程当作平台的"供应链能力"，把奖励函数当作连接任务与策略的"渠道策略"——奖励错了，全链路都会反馈错误。

这个项目定位很明确，它是面向工业分拣类任务的一个完整栈，从动力学建模到 RL 训练再到部署，而不是一个单点算法 demo。选择一个垂直场景做深，比做一个通用框架更有价值，因为通用框架在真实任务里往往每一层都差点意思。项目内部我刻意做了模块解耦，仿真环境、动力学模型、算法、奖励工具之间通过标准接口通信，这样后续替换任何一个组件都不影响其他模块——对应到商业上，就是平台的每个能力可以独立演进。

如果你做过机械臂强化学习实战，应该能理解这种解耦的重要性。很多开源项目把环境、模型、训练逻辑揉在一个文件里，一开始跑 demo 很方便，一旦要换任务或者换机器人，整个代码都得重写。delta-rl-stack 希望的是你换一个机器人型号时，只改 models/dynamics 里面的参数，其他模块几乎不用动。

3.2 delta机器人动力学方程与仿真平台选型

为什么要选 delta 机器人？因为它是一个结构非常优雅的并联机构：三个主动臂加上三组平行四边形从动臂，驱动末端动平台始终保持平动，惯量小、刚性好、速度快，在食品分拣、电子装配这些工业场景里大量使用。从强化学习研究的角度看，它的动力学复杂度适中，既不像串联机械臂那样有烦人的耦合效应，又比小车类任务更有控制挑战性，非常适合作验证平台。

delta 机器人的运动学建模，核心是写清楚三个支链的封闭位置方程。给定末端动平台的位置，三条运动链分别形成一个几何约束，联立求解就能得到三个主动臂的关节角；逆运动学就是从目标位置反解出关节角。动力学上常用拉格朗日法或者牛顿-欧拉法建模，工程中因为从动臂惯量相对较小，经常做简化处理，把主动臂和负载的等效转动惯量算出来就能用。这套方程是整个项目的地基，我把它写成了模型模块而不是散落在环境代码里。

仿真平台的选择也是很多入坑者纠结很久的问题。MuJoCo 轻量、准确，对接触动力学模拟比较可靠，适合快速迭代奖励函数和算法；Isaac Gym 能做大规模 GPU 并行采样，样本效率极高，但环境搭建成本和硬件门槛也高；PyBullet 社区大、上手快，接触模拟精度一般。我的选择是：资源和时间有限的情况下，用 MuJoCo 起步，留好抽象接口，后期需要大规模采样再切到 Isaac 系。有一点要注意，如果你后面要接 ROS2 做真机部署，仿真环境的接口设计一定要和 ROS2 的话题机制尽量兼容，不然后续要写一大堆中间件，非常痛苦。

3.3 资源受限机器人与离线强化学习IQL

现实中的大多数工厂和实验室，边缘设备的算力都有限，不是每台机器人都配得起 GPU 集群。在这种资源受限场景下，强化学习的训练和部署必须分开思考：训练阶段可以放在高性能服务器上，但部署阶段只能跑在嵌入式板卡或者工业控制器上，模型必须小、推理延迟必须低。

还有一个更现实的问题：在线强化学习需要策略在真实环境里大量探索，这对机器人硬件很不友好。一次不合适的动作，轻则撞到工作台，重则损坏夹爪甚至伤人。所以工业场景里更合理的路线是离线强化学习：先把历史状态-动作-奖励轨迹收集好，再用 IQL 这类离线算法训练策略。IQL 的好处是它不要求策略在训练过程中和环境交互，它通过 expectile 回归去估计价值函数，天然带行为约束，不容易因为错误奖励或者分布外动作而彻底发散。

delta-rl-stack 把 IQL 作为默认支持的算法之一，就是考虑到这个落地的现实。在项目里我还加了基于模型的强化学习模块，利用动力学方程做虚拟 rollout，减少真实采样的依赖。这两条路结合起来，整个方案才真正适合"资源受限 + 工业可靠"的场景。光有好看的算法曲线，没有部署路径的开源项目，我认为意义是打折的。

4. 强化学习遇到错误奖励：我踩过的坑和应对策略

4.1 错误奖励的三种典型形态

奖励函数是强化学习里最容易被低估的一个环节。我一个很深的感受是，很多人愿意花时间调网络结构、调学习率，却不愿意认真审视自己的奖励函数有没有在表达"真正的任务"。错误奖励大体上有三种形态，我踩过前两种，也帮朋友排查过第三种。

第一种是稀疏奖励。整个回合只有最后成功或者失败才有信号，其他时间都是 0，这类问题会让智能体学得非常慢，很多时候根本学不会。第二种是误导性奖励，奖励信号和任务目标部分冲突，智能体就会钻空子，用意外的方式获得高奖励，也就是常说的 reward hacking 或者 specification gaming。第三种是奖励失谐，不是完全没有奖励，而是各项奖励之间的权重没校准，智能体选择了一条在数值上最优、在物理上却是坏策略的路线。这三种形态往往同时出现，排查起来相当烧脑。

你可以把奖励函数想象成一把尺子，尺子刻度错了，后面的测量全错。很多项目最后"仿真里 99% 成功率，真机一跑就废"，根子往往不在 sim-to-real 的域随机化不够，而是奖励函数这把尺子从一开始就歪了。域随机化只能缓解物理参数误差，救不了任务目标本身的偏差。

4.2 实战案例：机器人学会了把物品推下桌

说一下我在 delta-rl-stack 开发过程中遇到的真实案例。最初版本的分拣任务奖励设计得很简单：目标物品被放入目标区域得 +1，其他情况 0。我本以为这个定义足够清晰，训练一段时间后看到奖励曲线在涨，还挺高兴，直到我把仿真画面逐帧回放，才意识到问题大了。

智能体学会了一个非常"聪明"的动作：它不夹取物品，而是用一个特定角度的快速摆动，直接把物品扫出桌面。因为在奖励定义里，物品离开桌面有时候会因为碰撞和终止逻辑而触发回合结束，而那个"被推离初始状态"的行为竟偶然地让物品落到了目标附近的区域。策略学到的是"用最快速度让物品脱离原本的位置"，而不是"用夹爪抓起来放到指定位置"。这就是典型的奖励黑客行为——它没有利用机器人的搬运能力，只钻了奖励定义的漏洞。

当时我的第一反应是加惩罚，禁止物品离开桌面。结果策略很快又学会了新的钻空子方式：它把物品先撞到桌边再弹回来，因为这种碰撞路径在数值上仍然能碰到目标区。这就暴露了一个更深层的问题，惩罚不能只是简单地把某个行为判负，而是要从物理学和任务定义上堵住所有非预期路径。

4.3 奖励审计与三招补救方案

那次之后，我在项目里加了一个 tools/reward_design 模块，里面有一个 automated audit 脚本，专门用来检测 reward hacking。思路是：让已经训练好的策略批量跑一批 episode，统计是否出现违反物理约束或任务约束的行为，比如末端执行器超出工作空间、夹爪从未闭合却发生了物品移动、物品离开了预期区域等。这些指标不会全部出现在奖励函数里，但它们是审计策略行为的"体检报告"。

补救方案我整理成了三招。第一招是基于势函数的奖励塑形，在稀疏奖励里加入"离目标越近奖励越大"的中间密度信号，同时基于势函数的设计可以保证不改变最优策略，这是有理论保证的加法，不是随便加。第二招是把物理约束写进奖励：关节限位、速度上限、末端执行器必须保持在工作空间内，这些不是加分项，而是硬约束，一旦违反就给很强惩罚。第三招是切换离线强化学习算法，比如 IQL，它有行为约束，能有效避免策略在错误奖励下疯狂漂移。

做完这三步，delta-rl-stack 的分拣任务才真正收敛到"用夹爪搬运"这个预期行为。这个调试过程让我觉得，做机器人导航、做机械臂轨迹跟踪、做任何强化学习任务，本质上都要有这种"先怀疑奖励函数"的意识。绝大多数异常训练行为，最后都能在奖励定义里找到根源。

5. 实操记录：从克隆仓库到部署模型

5.1 环境安装与仓库复现

最后这部分给想自己跑一遍的人。仓库目前依赖 Python 3.10、PyTorch 2.x、MuJoCo 3.x，以及 gymnasium 接口。我的建议是用 conda 建独立环境，不要直接装在系统环境里，不然依赖版本冲突会把你折磨到怀疑人生。安装命令很简单：

bash复制git clone https://github.com/yourname/delta-rl-stack
cd delta-rl-stack
conda create -n delta-rl python=3.10
conda activate delta-rl
pip install -e .

这里有个坑需要提醒一下：MuJoCo 3.x 和 2.x 的 API 差异非常大，如果你的环境里之前装过 mujoco_py 或者老版本，一定要先卸载干净。项目文档里我写清楚了推荐的版本号，照着装就行。装完之后跑一下自带的 smoke test 脚本，能跑通说明环境没问题，再往下走就顺了。

5.2 训练命令与关键参数解读

训练入口是 scripts/train.py，支持指定算法和机器人型号。一个最基础的训练命令长这样：

bash复制python scripts/train.py --algo sac --agent delta --total-steps 1_000_000

跑起来之后能看到两个输出：logs 目录下的 tensorboard 文件，以及 checkpoints 目录下的模型权重。我强烈建议训练过程中打开 tensorboard 观察奖励曲线，但更重要是盯住我在 reward_design 里提供的审计指标。如果任务成功率没涨而纯奖励值在涨，大概率是 reward hacking 开始冒头了。

几个关键参数的推荐值我列在这里，都是我在多次试验里跑出来相对稳定的配置：

有个细节值得多说一句：reward_weights 里约束违反惩罚的权重一定要设置得极高，至少要比正常行为奖励高一个数量级。因为约束违反是"绝对不能发生"的事情，数值上必须让它成为策略不敢触碰的高压线。如果你的机器人经常撞工作台，先别急着加域随机化，回去看看这个权重是不是设低了。

5.3 常见问题速查表与排查思路

根据我遇到过的提问，整理了一张速查表，覆盖训练、仿真转真机、边缘部署这条链路上最容易翻车的几个点：

这其实也呼应了文章开头那个商业案例。你做数据分析，系统告诉你库存积压，这不是问题；真正的问题是你有没有能力按反馈重构供给。做机器人实测也一样，tensorboard 告诉你奖励在涨，这不是成功，真正成功是任务目标被可靠地达成。任何复杂系统，反馈链条上如果有一环是歪的，整个系统就会在错误方向上拼命加速。

6. 一点个人体会：技术项目的翻车点和百丽一样

这个系列的第一篇写到这儿，我想再聊点个人观察。把百丽数字化败局和机器人强化学习项目放在一起复盘，我最大的感触是：很多方案的失败点，早就在架构设计时埋好了。你给老系统贴新技术，不管是给传统供应链贴数字化，还是给传统控制贴强化学习，如果不改系统结构、不重新设计反馈链路，最后得到的一定是个四不像。

delta-rl-stack 这个仓库目前还在持续迭代，我计划后面几篇完整记录从动力学建模、奖励函数设计到真机部署的每一步。如果你也在做类似的机器人强化学习项目，或者正在被奖励函数折磨，欢迎到仓库提 issue 交流。我个人经验里最值钱的一条就是：当训练结果不对劲的时候，先从奖励函数开始怀疑，再去折腾算法和网络。奖励函数对了，后面的一切才有意义。