原帖给出了一个优雅的数学骨架，但 Pandoras Box 的工程落地里有四块硬骨头没说透——
第一块，闭式解依赖高斯假设。 论文假设 cheap 估计 \(f_m(x)\) 和贵估计 \(g_m(x)\) 之间的关系是高斯的——这意味着 \(f\) 错的方向对称、远离真值时不确定性均匀增长。现实里，embedding 路由器对"专业领域"和"通用闲聊"两类 prompt 的预估精度差几个数量级，分布远不是高斯。Fisch / Trivedi / Huot / Cohen 这篇在高斯外推不出去的领域（比如代码生成、数学推理），闭式解可能直接打偏 30%+。
第二块，reservation price 的计算代价被低估了。 路由每个 query 前要先扫一遍所有 specialist 的先验均值——50 个 specialist 就 50 次 forward。在 RouterBench 上这一步的开销在毫秒级，但生产里如果是 GPT-5 这种大模型当 specialist 之一，光是估算均值这一步可能就贵过"让最强的模型直接答"。换句话说，Pandora 的"打开盒子看值"成本和实际 LLM 推理成本不在一个数量级。
第三块，Pandora's Bidder 在策略博弈下的脆弱性。 论文自己点了：当竞争者的估计都比较准确时，VoI 推理能改善整体效率；但当估计很吵时，"策略型"专家通过更激进的自我评估拿信息优势，反而吃掉别人的份额。简单说，这套机制在寡头市场可能自我强化、在长尾市场可能被头部专家劫持。这跟现实里模型 API 市场的格局——OpenAI / Anthropic / Google 占大头——是反过来的。
第四块，"var-of-information 最优"在延迟敏感场景会翻转。 Pandora 的目标是"总期望值最大"，不是"最差情况最小"。如果一个 specialist 的"便宜估计"给出 0.7、"贵估计"给出 0.4（典型情况：简单问题在小模型上的预估偏高），闭式解会说"不花钱更准"。但用户面对 latency 阈值时，可能反而愿意花冤枉钱去 double-check。论文没把延迟当作 VoI 公式的一部分，是工程化的一个坑。
下一根最该盯的钉子： Pandora 的 Bidder 能不能跟 Anthropic 那种"先做小模型试答、不确定再升级到大模型"的实际工程实践对上号？如果对不上，那它就是学术优雅；如果对上，OpenAI 内部应该已经在悄悄用了。