一、项目背景

我们给一个产业园区做通勤系统，原本几辆固定班车，路线死板，上座率低得可怜，空车跑的比坐人的多。晚班没人接，临时加班的员工叫不到车，只能自己打车，行政还不一定给报，怨气很大。排班全靠一张表，调整一次累半天，园区方和员工都不满意，园区方觉得钱花了没效果。我们进场时，行政最头疼的是晚班兜底，天天有人私信问"还有车吗"，微信根本回不过来，她自己的下班时间也被吞了，这事她吐槽了很久。我们翻了三个月的用车记录，晚班打车报销的票根比班车开的趟数还多，等于钱花了两遍，园区方这才意识到固定排班根本接不住真实需求，愿意让我们用智能体重新排。

二、落地场景

我们用多智能体协同重排了班车。需求智能体归集员工通勤申请，按片区聚合，把零散需求攒成批次；路线智能体动态规划线路，把同片区的需求串成一条；调度智能体管车辆和司机，闲时合并、晚班设兜底车次，资源不空转；核验智能体管乘车签到和异常补运，没人到站就触发补运。员工在小程序提需求、看班次、刷码上车。整个调度从人工表变成智能体之间互相喂数据，行政从填表员变成了监督员，只在异常时介入，日常不用盯。后台还能按周看上座率和空驶里程，园区方终于能用数据跟老板交代这笔班车预算花得值不值，不用再靠感觉。园区后来把访客临时通勤也并进了需求智能体，客户来访提前提需求，系统顺路带一程，行政不用再单独派车。班车之外我们还接了园区的共享单车点位，最后一公里太碎的需求引导去骑行，班车只兜底中长距离，资源更聚焦。调度智能体和园区的门禁系统打通，员工刷码上车的同时考勤也记了，行政少了对一遍表。我们复盘时发现，夜间兜底车上线后，加班到九十点的员工满意度涨得最明显，这块原本是投诉重灾区，现在几乎零差评，园区方据此把兜底车写进了通勤制度。

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

需求归集是第一道关。员工提的需求零散，我们按片区和时间窗聚合成批次，太碎的需求单独兜底，不强行拼车。动态路线最怕绕远，路线智能体用片区中心做锚，把顺路的需求一次带完，不走回头路，员工通勤时间也短了。上座率靠把相近时段的需求合并到一趟，空座少了成本就降，油费省下来。晚班兜底最棘手，人少但必须有人接，我们设了最小成行班次，不够人数也发兜底车，成本走园区统付，员工体验优先。这里走过弯路，第一版路线完全按算法最短，员工嫌绕，后来加了片区锚点才顺，算法要接地气不能只顾数学最优，最短路径不一定是员工愿意坐的路径，舒适度也是履约的一部分，我们后来把"绕路容忍度"做成可调参数才平了争议。

案例片段（已脱敏）： 班车需求聚合与路线排班配置（示意）： demand.window_min: 20 route.anchor: district_center merge.same_window: true night.backup_min_headcount: 0 checkin.mode: qr 某园区上线后班车平均上座率从 38% 升到 67%，晚班覆盖做到全天无缺口，空驶里程下降约三成。

四、效果数据

我们主要看上座率、晚班覆盖、空驶里程和缺乘率。上座率从不到四成升到约七成，空车明显减少；晚班覆盖做到全天无缺口，临时加班也有人接，打车报销的投诉没了；空驶里程下降约三成，油费省下一截；缺乘率维持在很低，基本没人掉车。我们把上座率和空驶数据反向给了园区做招商，晚间有班车的楼栋入驻率更好，园区方拿这个去跟新租户谈，班车从成本中心变成了招商卖点。行政那边最实在的是私信量掉了九成，她终于能把精力放在员工活动上，而不是天天当客服，年底述职第一次有了正经的数据支撑，不再是我觉得还行。

文中数据为项目复盘口径，实际值随园区入驻率波动，仅作趋势参考。行政最大的变化是不再被私信轰炸，系统自己把晚班兜住了，她终于能准点下班，园区方看上座率也觉得这钱花得值，续约也爽快了，还把这套推到了他们另外两个园区。

五、可复用经验总结

园区班车这种固定资源，路线死板是上座率低的根，用需求聚合加动态路线就能盘活，不用加车先盘活现有车，成本最优。晚班兜底别算小账，人少也得发车，员工体验比那点空驶成本重要，兜底车是口碑也是留存，算大账划算。我们后来觉得片区锚点比纯最短路径更接地气，员工认路也好接受，算法最优不等于人舒服，路线得让人愿意坐。做通勤调度的，先把"谁在什么时候从哪到哪"聚清楚，路线自然就出来了，别一上来就堆算法，需求不清算法再好也白搭，锚点这种土办法往往比纯最优解更扛事儿。