一、项目背景

客户是一家连锁餐饮品牌，两百四十多家直营店，每家店十到二十五个员工，有全职有兼职。排班这件事一直是店长的心病：每周日晚上坐在办公室里，对着一张 Excel 排下一周的班，考虑谁请假、谁上学、谁擅长哪个岗位、周末客流大要多排几个人。排完发到群里，周一就有人说排错了，改一版，周三又有人临时请假，再改一版。

区域经理给我看过一个数字，他们统计过店长平均每周花在排班和调班上的时间是三小时二十分钟，两百四十家店一年就是四万多小时。这还不算排得不好带来的隐性成本。忙时缺人，顾客等太久流失；闲时窝工，人力成本白烧。他们抽样测算过，人效在门店之间的差距能到百分之四十，其中相当一部分是排班质量造成的。

跨店支援更是个灰色地带。A 店缺人，店长在区域群里喊一声，谁有空谁去，全凭人情。有的店长脸皮薄从来不喊，宁可自己顶班；有的店长天天喊，别人开始不接他电话。

二、落地场景

这套东西我们做成了多个智能体协同的形态，跑在客户的 AI 私有化底座上，和 XpShop 的门店运营数据打通。

客流预测智能体负责算出未来两周每家店每个时段的客流和订单量。输入是历史交易数据、天气预报、周边活动日历、节假日安排、门店周边的商圈类型。输出是按半小时粒度的客流曲线和折算的用工需求。

排班生成智能体拿到用工需求后，结合员工的可用时间、技能标签、合同类型、法定工时限制，生成排班草案。它不追求全局最优，追求的是在硬约束下给出一个店长能接受的方案。

临时调岗智能体处理运行中的扰动。有人请假、客流突然超预期、设备故障导致某岗位不需要人，这些情况下它给出调整建议，包括本店内部换岗和跨店支援两种。

合规校验智能体是个把关角色，独立于前面几个，专门检查排班结果是否违反工时规定：连续工作时长、休息间隔、周工时上限、未成年员工的特殊限制。它有一票否决权。

四个智能体之间通过消息协作，共享一份门店排班状态。店长在小程序上看到的是最终结果，可以调整，调整后再走一遍合规校验。

三、关键技术挑战与解决思路

客流预测的难点不在算法，在特征。我们最初用的特征很常规，历史同期、星期几、天气、节假日，跑出来的整体误差百分之十八，看着还行，但在几类门店上错得很厉害。深入分析发现漏了很重要的东西：写字楼店受周边公司加班文化影响，学校旁边的店受寒暑假和考试周影响，商场店受商场自身活动影响。这些都是外部信息，历史数据里体现不出来。

我们做了两件事。一是接了几路外部数据，商场的活动日历、学校的校历、周边的大型活动信息。二是给店长开了一个"事件登记"的入口，让他们提前录入知道的信息，比如"下周三隔壁写字楼有招聘会"。店长录入的信息经过验证后成为模型特征。加了这两块之后误差降到百分之九点四。这个提升几乎全部来自特征而不是模型。

排班的约束求解我们纠结过很久。这是个典型的组合优化问题，硬约束加软约束，理论上可以用整数规划求解。我们做了一版，二十人规模的门店求解时间大概四十秒，能接受。但问题出在解的可解释性和可接受度上：求解器给的排班在数学上很优，店长看了说"不对，小李不能和小王排同一班，他俩有矛盾"。这类隐性约束根本写不进模型。

后来改成了两阶段：求解器负责生成三到五个候选方案，尽量在结构上有差异，店长挑一个再微调。同时我们把店长的每次微调都记录下来，分析出高频的调整模式，比如某两个员工总是被分开，就把这种模式固化成软约束回灌给求解器。跑了两个月之后，店长的平均微调次数从每周十一次降到三次。

跨店支援的设计花了心思。技术上不难，难的是机制。我们的做法是把支援做成明码标价的资源：支援方门店获得人力成本转移和一定的绩效加成，被支援方承担成本。系统自动匹配支援人选时会考虑通勤距离、技能匹配、员工本人的意愿标签（提前设置是否接受跨店）。店长不用去群里求人，系统直接发起，对方店长确认即可。人情因素被规则替代之后，跨店支援的发起量涨了四倍多。

合规校验独立成一个智能体是个正确的决定。一开始我们想把工时约束直接写进排班生成的求解器里，后来意识到这样有风险：店长手工调整之后的方案不会再过求解器，可能违规而没人发现。独立出来做后置校验，任何路径产生的排班都必须过这一关，包括店长手改的、临时调岗产生的。这个校验智能体上线后第一个月就拦下来一百多次违规排班，其中有几十次是店长为了应急自己改出来的。

案例片段（已脱敏）： 一次临时调岗的协同过程：14:20 某商场店后厨员工请病假，缺岗时段 17:00-21:00（晚高峰）。临时调岗智能体评估：本店内部可调 1 人但技能不匹配（收银转后厨需培训）；跨店候选 3 人，其中 A 店某员工通勤 12 分钟、技能匹配度 0.91、意愿标签接受跨店、当日排班 11:00-15:00 已满 4 小时。发起支援请求，A 店长 14:26 确认，合规校验通过（当日累计 8 小时，未超上限，两班间隔 2 小时符合规定）。14:28 通知到人。整个过程 8 分钟，按旧办法群里喊人平均要 40 分钟以上，还经常喊不到。 隐性约束回灌的一例：系统识别到某门店在 9 周内有 23 次把员工编号 0117 与 0132 从同一班次拆开，判定为强隐性约束，自动加入该门店的软约束集合，权重设为高。后续排班草案不再把这两人排在一起，店长该项微调归零。

四、效果数据

全量推开四个月后的复盘。店长每周花在排班上的时间从三小时二十分降到四十分钟左右，其中大部分时间是在候选方案里挑选和微调。两百四十家店一年折算下来省出的时间相当可观。

人效方面，按人均小时营业额口径，整体提升了百分之十一点三。提升最明显的是原来排班质量最差的那批门店，头部门店本来排得就不错，提升有限。这个分布符合预期。

缺岗时长，也就是实际用工低于预测需求的累计时长，从月均每店十四小时降到四点二小时。窝工时长（实际用工高于需求）从月均每店二十一小时降到九小时。

排班调整次数从每周十一次降到三次。跨店支援的月发起量从三十七次涨到一百六十二次，成功匹配率百分之八十九。

工时合规率从百分之九十一点四提到百分之九十九点七，这个指标客户的人力资源部最在意，因为剩下那百分之八点六在过去是实实在在的用工风险。以上均为项目复盘口径的脱敏数据。

五、可复用经验总结

多智能体这种架构，价值在于职责清晰而不是听起来时髦。这个项目里四个智能体各管一段，客流预测出问题不会连累合规校验，调岗逻辑改动不影响排班生成。如果做成一个大而全的服务，任何一处改动都要全量回归。把合规校验独立出来做后置守门，是整个设计里最有价值的一笔。

预测类的场景，先把特征找全再谈模型。我们在客流预测上误差从百分之十八降到九点四，几乎全是特征的功劳，模型基本没动。花两周找数据源，比花两周调参划算得多。

组合优化问题在真实业务里往往有大量写不出来的隐性约束。硬要求全局最优，得到的方案一线不认。给候选方案让人挑，再从人的调整里学约束，这个闭环比追求求解质量实用。我们绕过弯路才想明白这一点。

跨店支援这类涉及利益分配的功能，光有系统能力不够，配套机制得同时设计。明码标价加自动匹配，把人情消耗变成规则运转，参与度才真的起来。

给一线的入口要简单。店长的事件登记入口我们最初设计得很完整，有事件类型、影响范围、预计影响程度，结果没人填。简化成"填一句话加选一个日期"之后，填写量涨了十几倍，模型再从这句话里抽取结构化信息。别指望一线用户帮你填表。

附：工程落地细节

客流预测按门店类型分群建模，四类门店独立训练，新开店在积累够数据前用同类型门店的均值做冷启动。求解器用的是开源的约束规划库，二十人规模门店生成三个候选方案约一百二十秒，放在夜间批处理跑。软约束权重按门店独立维护，跨店不共享，因为员工关系是本地化的。临时调岗的候选人排序是多因子加权，通勤时间权重最高，其次技能匹配，再次是员工当月已跨店次数（避免总找同几个人）。合规校验的规则库支持按地区配置。所有排班版本留档，劳动争议时可追溯。

附：一点实在的提醒

排班系统碰的是员工的切身利益，推行阻力和技术无关。我们在试点期遇到过一次小规模抵触，几个老员工觉得系统排班"不近人情"，不像以前可以跟店长商量。后来加了"意愿设置"和"异议提交"两个入口，让员工能表达诉求，抵触情绪明显缓解。技术方案再优，如果让使用者感觉自己被机器安排而没有话语权，落地一定会打折。给人留一个说话的口子，成本很低，效果很好。