编者按你打开外卖App看到一排餐厅。你可能以为这个顺序主要由广告、销量、评分、距离或者平台想推哪家店决定。但从运营管理的角度看排序还有另一层含义它会改变订单未来要走多远、能不能顺路合单、会不会把某家餐厅的后厨压爆也会影响几十分钟后骑手分布在城市里的什么位置。换句话说外卖平台上的餐厅排序不只是一个推荐问题也是一个物流问题。这篇2026年2月发表在 Management Science 的论文《Integrated Fleet and Demand Control for On-Demand Meal Delivery Platforms》讨论的正是这个直觉。参考文献: Florentin D. Hildebrandt, Žiga Lesjak, Arne Strauss, and Marlin W. Ulmer. “Integrated Fleet and Demand Control for On-Demand Meal Delivery Platforms.” Management Science, 72(2), 2026, 932-954. DOI: 10.1287/mnsc.2022.02039.传统配送优化通常从“订单已经来了”开始顾客已经选好餐厅平台再决定派哪个骑手、怎么取送、能不能合单。但这漏掉了一个更早的控制点顾客还没下单时平台已经通过页面排序影响了他会选择哪家餐厅。假设顾客面前有三家餐厅 A、B、C。如果他选 A最近的骑手需要绕一段路如果他选 B刚好有一名骑手本来就要去 B 取另一单新订单可以顺路合并如果他选 C这家餐厅此刻已经积压很多订单备餐队列会继续变长。对顾客来说这只是三个餐厅选项。对平台来说它们对应三种完全不同的线下履约后果。论文的核心问题就是在不删除选项、也不替顾客作决定的情况下平台能不能把配送上更顺手、更不容易造成拥堵的餐厅放得稍微靠前一点一、一个被提前的物流决策这项研究把外卖系统看成一条连续决策链顾客进入平台并输入地址 - 平台读取餐厅队列和骑手路线 - 平台设置餐厅排序并为每个潜在选择准备暂定派单 - 顾客选择餐厅 - 餐厅备餐骑手取送 - 系统进入新的状态最关键的一步是“为每个潜在选择准备暂定派单”。顾客还没决定点哪家平台就先评估如果他选 A派谁如果选 B派谁如果选 C又派谁。只有先知道每个餐厅选择对应的配送代价平台才知道哪家餐厅值得展示得更靠前。论文把这个决策写成xk(σk,ιk).x_k(\sigma_k,\iota_k).xk​(σk​,ιk​).这里σk\sigma_kσk​是平台给第kkk位顾客展示的餐厅排序ιk(r)\iota_k(r)ιk​(r)则是一个条件派单规则表示“如果顾客选择餐厅rrr订单将分配给哪名骑手”。因此这不是“推荐系统先排序、物流系统再接单”的串联关系。排序本身就需要看见餐厅和车队的实时状态。论文把这个问题拆成三层需求层页面排序怎样改变顾客选择概率履约层一笔潜在订单怎样插入骑手路线、餐厅队列和合单计划学习层怎样给每个“餐厅-骑手”组合估计一个长期物流成本。二、需求层排序真的会改变选择联合优化能够成立首先要回答一个行为问题餐厅排在第几位真的会改变顾客选择吗作者使用了一家斯洛文尼亚外卖平台 2021 年 2 月到 7 月的顾客购买数据。清洗后样本包含 861,349 次顾客选择。研究删去了使用搜索框或筛选器的记录因为这类顾客目标更明确不太受默认排序影响这部分约占原记录的 22%。在后续模拟中作者也保守地假设有 22% 的顾客不受排序影响。作者用带展示位置效应的多项 Logit 模型描述顾客选择。直观地说餐厅被选择的概率由餐厅自身吸引力、配送费、预计送达时间和展示位置共同决定。一家餐厅rrr对第kkk位顾客的效用可以写成$$\begin{aligned}u_{rk}(\vec{\alpha}) :\ \alpha_{0r}\mathbf{1}{{t_k3pm}}\cdot \alpha{1r}\alpha_2\cdot \text{Delivery Fee}{rk}\ \alpha_3\cdot \text{Earliest Delivery Time}{rk}\alpha_4\cdot \text{Latest Delivery Time}{rk}\ \sum{\ell1}^{21}\alpha_{4\ell}\cdot \text{Display Ranking}(\ell)_{rk}.\end{aligned}$$其中Display Ranking(ℓ)rk1\text{Display Ranking}(\ell)_{rk}1Display Ranking(ℓ)rk​1表示餐厅rrr被展示在顾客kkk页面上的第ℓ\ellℓ个位置否则为 0。也就是说排序σk\sigma_kσk​不是在模型之外影响选择而是直接进入了顾客效用函数。相应的选择概率为$$p_{rk}(\sigma_k,\vec{\alpha})\frac{\exp(u_{rk}(\vec{\alpha}))}{\sum_{r’\in R_k}\exp(u_{r’k}(\vec{\alpha}))}.$$这里把σk\sigma_kσk​写在prkp_{rk}prk​中是为了强调排序会通过展示位置变量改变效用进而改变选择概率。论文报告了一个很直接的结果前五个展示位置与最后五个展示位置之间选择概率相差约 10%。这并不意味着平台能“决定”顾客吃什么。更准确地说平台不能控制单个顾客的选择结果却能改变大量顾客流向不同餐厅的概率分布。对物流系统来说这一点概率变化累积成几百、几千笔订单后就足以改变餐厅负荷、合单机会和城市里的骑手分布。三、从履约到学习用同一种价格衡量推荐和物流接下来平台还要知道如果顾客选择某家餐厅这个选择会给配送系统带来多大代价论文衡量的核心成本是延迟。对订单ooo延迟可以写成domax⁡{0, Todelivered−Toordered−δ}.d_o\max\{0,\ T_o^{delivered}-T_o^{ordered}-\delta\}.do​max{0,Todelivered​−Toordered​−δ}.实验中承诺配送时间δ40\delta40δ40分钟。也就是说39 分钟送到不产生延迟成本45 分钟送到才产生 5 分钟延迟。论文用一个 Q 值来连接需求和履约Q(Sk,r,v)E[从当前时刻起的累计延迟∣Sk,顾客选择 r,订单分配给 v].Q(S_k,r,v) \mathbb E[\text{从当前时刻起的累计延迟}\mid S_k,\text{顾客选择 }r,\text{订单分配给 }v].Q(Sk​,r,v)E[从当前时刻起的累计延迟∣Sk​,顾客选择r,订单分配给v].它回答的是在第kkk位顾客到达时的系统状态SkS_kSk​下如果顾客选择餐厅rrr并把订单分给骑手vvv从现在到一天结束系统预计会产生多少累计延迟这里Q 值不是“这名骑手送这一单要几分钟”。它还包含这次决策对后续订单、路线和车队灵活性的影响。有了这个共同尺度平台就可以做两件事。第一对每家餐厅找到当前最合适的骑手vk∗(r)arg⁡min⁡vQ(Sk,r,v).v_k^*(r)\arg\min_v Q(S_k,r,v).vk∗​(r)argvmin​Q(Sk​,r,v).第二把每家餐厅被选中的概率和它对应的未来延迟放在一起选择期望延迟最低的展示排序$$\sigma_k^*\arg\min_{\sigma_k}\sum_{r\in R_k}p_{rk}(\sigma_k,\vec{\alpha})\min_v Q(S_k,r,v).$$这就是论文最重要的观点排序负责改变“哪家餐厅被选中的概率”派单负责决定“这个选择一旦发生要付出多少履约代价”两者通过“未来累计延迟”被放到同一个优化问题里。四、关键数字联合优化带来了什么论文结合两类数据做仿真斯洛文尼亚平台数据用于估计顾客选择爱荷华城Iowa City和科拉尔维尔Coralville的公开数据用于构建餐厅、顾客位置与城市路网。作者测试了 20 个规模从 5 辆车扩展到 100 辆车。他们比较了几类策略Balanced类似实践中的派单规则兼顾当前履约和车队平衡RL(F)只用强化学习做前瞻性车队控制餐厅随机展示RL(FD)同时优化车队控制Fleet Control与餐厅展示Display其他排序规则按距离、餐厅负荷、预计送达时间排序以及设置固定赞助位。结果可以压缩成三句话。第一仅做前瞻性派单已经明显更好。RL(F)在全部规模上都优于Balanced。一个重要机制是合单Balanced的合单比例不到 1%而RL(F)大约为 2%-5%。前瞻性策略不只是让当前订单更快而是在完成当前订单的同时让车队在午餐和晚餐高峰前处在更好的位置。第二再加入需求控制延迟继续下降。RL(FD)在 20 个实例中的 18 个取得最低的平均延迟和平均最大延迟。相比只做车队控制的RL(F)加入展示优化后每个实例的平均延迟至少再减少 1 分钟平均最大延迟最多可再减少约 20 分钟。第三排序优化最终可以变成车队成本。在一个中等规模需求场景中若平台要达到同样服务水平RL(FD)相比Balanced可少用约 4-6 辆车相比只做车队控制的RL(F)需求控制还能再节省约 3-6 辆车。这说明页面上的排序调整并不是一个只停留在点击率上的变量。它可以一路传导最后体现在真实的车辆数量、司机时间和配送容量上。五、对平台管理的启发这篇论文最有价值的地方不是证明“应该永远把物流最优的餐厅排到前面”。更准确的启发是推荐、广告和物流不该各自优化。第一排序有履约成本。一个餐厅被放到更靠前的位置不只会带来更多曝光和订单也可能带来更长的备餐队列、更少的合单空间和更高的骑手调度压力。第二赞助位不是纯收入项。固定靠前的位置既有广告价值也有物流机会成本。需求低时订单集中到少数餐厅可能增加合单需求高时它也可能把赞助餐厅变成瓶颈使最大延迟迅速恶化。因此赞助位价格不应只有一个静态报价而应考虑时段、餐厅负荷、车队状态和服务压力。可以把这个管理含义粗略写成$$\text{展示位净价值}\text{广告收入}\lambda\cdot \Delta \mathbb E[\text{Delay}].$$其中λ\lambdaλ表示平台把服务延迟、额外车队需求和用户体验风险折算成经营成本的权重。这个表达不是论文的主模型而是对管理含义的翻译卖展示位时平台卖出的不只是流量也是在改变履约系统的压力分布。第三需求控制可以是容量管理工具。平台不一定要靠增加骑手来改善高峰服务水平。它也可以通过温和调整展示顺序把一部分订单引向更容易履约的位置从而减少延迟和车队需求。第四平台治理不能只看效率。动态排序会改变不同商户获得订单的机会。论文发现这种不均衡幅度较小并且比长期出售固定头部位置更公平但现实平台仍需要考虑透明度、商户权益和用户对推荐可信度的长期感受。这项研究提供的是严谨建模与大规模仿真证据而不是平台线上 A/B 测试。现实中排序变化可能影响用户退出平台、使用搜索、改选其他 App也可能改变用户对平台推荐的长期信任。此外实验中的餐厅在主要设置里相对同质。真实平台还要面对菜系、价格、品牌、备餐能力和口碑差异。也就是说这篇论文不应被理解为“平台可以简单地按物流效率重排所有餐厅”。因此更合适的理解是当线上界面与线下履约存在稳定的因果链条时平台需要把推荐、广告和物流放进同一个运营系统。外卖平台的排序算法不只是让顾客看见什么也是在决定城市里的订单怎样流动。页面上的一次顺序调整最终可能变成路网里少走的一段距离、后厨里少排的一段队、骑手路线上的一次顺路合单以及顾客手中仍然温热的一份饭。