编者按：
你打开外卖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_k>3pm}}\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{\ell=1}^{21}\alpha_{4+\ell}\cdot \text{Display Ranking}(\ell)_{rk}.
\end{aligned}$$
其中，Display Ranking(ℓ)rk=1\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，延迟可以写成：
do=max{0, Todelivered−Toordered−δ}.d_o=\max\{0,\ T_o^{delivered}-T_o^{ordered}-\delta\}.do=max{0,Todelivered−Toordered−δ}.
实验中，承诺配送时间δ=40\delta=40δ=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)=argminvQ(Sk,r,v).v_k^*(r)=\arg\min_v Q(S_k,r,v).vk∗(r)=argvminQ(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(F&D)：同时优化车队控制（Fleet Control）与餐厅展示（Display）；- 其他排序规则：按距离、餐厅负荷、预计送达时间排序，以及设置固定赞助位。
结果可以压缩成三句话。
第一，仅做前瞻性派单已经明显更好。RL(F)在全部规模上都优于Balanced。一个重要机制是合单：Balanced的合单比例不到 1%，而RL(F)大约为 2%-5%。前瞻性策略不只是让当前订单更快，而是在完成当前订单的同时，让车队在午餐和晚餐高峰前处在更好的位置。
第二，再加入需求控制，延迟继续下降。RL(F&D)在 20 个实例中的 18 个取得最低的平均延迟和平均最大延迟。相比只做车队控制的RL(F)，加入展示优化后，每个实例的平均延迟至少再减少 1 分钟，平均最大延迟最多可再减少约 20 分钟。
第三，排序优化最终可以变成车队成本。在一个中等规模需求场景中，若平台要达到同样服务水平，RL(F&D)相比Balanced可少用约 4-6 辆车；相比只做车队控制的RL(F)，需求控制还能再节省约 3-6 辆车。
这说明，页面上的排序调整并不是一个只停留在点击率上的变量。它可以一路传导，最后体现在真实的车辆数量、司机时间和配送容量上。
五、对平台管理的启发
这篇论文最有价值的地方，不是证明“应该永远把物流最优的餐厅排到前面”。更准确的启发是：推荐、广告和物流不该各自优化。
第一，排序有履约成本。一个餐厅被放到更靠前的位置，不只会带来更多曝光和订单，也可能带来更长的备餐队列、更少的合单空间和更高的骑手调度压力。
第二，赞助位不是纯收入项。固定靠前的位置既有广告价值，也有物流机会成本。需求低时，订单集中到少数餐厅可能增加合单；需求高时，它也可能把赞助餐厅变成瓶颈，使最大延迟迅速恶化。因此，赞助位价格不应只有一个静态报价，而应考虑时段、餐厅负荷、车队状态和服务压力。
可以把这个管理含义粗略写成：
$$\text{展示位净价值}
\text{广告收入}
- \lambda\cdot \Delta \mathbb E[\text{Delay}].$$
其中，λ\lambdaλ表示平台把服务延迟、额外车队需求和用户体验风险折算成经营成本的权重。这个表达不是论文的主模型，而是对管理含义的翻译：卖展示位时，平台卖出的不只是流量，也是在改变履约系统的压力分布。
第三，需求控制可以是容量管理工具。平台不一定要靠增加骑手来改善高峰服务水平。它也可以通过温和调整展示顺序，把一部分订单引向更容易履约的位置，从而减少延迟和车队需求。
第四，平台治理不能只看效率。动态排序会改变不同商户获得订单的机会。论文发现这种不均衡幅度较小，并且比长期出售固定头部位置更公平，但现实平台仍需要考虑透明度、商户权益和用户对推荐可信度的长期感受。
这项研究提供的是严谨建模与大规模仿真证据，而不是平台线上 A/B 测试。现实中，排序变化可能影响用户退出平台、使用搜索、改选其他 App，也可能改变用户对平台推荐的长期信任。
此外，实验中的餐厅在主要设置里相对同质。真实平台还要面对菜系、价格、品牌、备餐能力和口碑差异。也就是说，这篇论文不应被理解为“平台可以简单地按物流效率重排所有餐厅”。
因此，更合适的理解是：当线上界面与线下履约存在稳定的因果链条时，平台需要把推荐、广告和物流放进同一个运营系统。外卖平台的排序算法不只是让顾客看见什么，也是在决定城市里的订单怎样流动。
页面上的一次顺序调整，最终可能变成路网里少走的一段距离、后厨里少排的一段队、骑手路线上的一次顺路合单，以及顾客手中仍然温热的一份饭。
)
