如何配置Google Fleet Routing参数以充分利用所有车辆

我正尝试用Google Fleet Routing API解决车队调度问题：每月约700个服务点位，配10名技术人员（对应10辆车）。技术人员周一至周四外出服务，周五内勤，每周一从家出发，服务区域内工作并住酒店，周四返回住所。因为理解API默认车辆每日往返起点，所以把4天工作压缩为1天，将每个点位的服务时长和行驶时长除以4（设置TravelDurationMultiple: 0.25）。初始方案总里程低，但只用了约一半车辆；希望均衡分配工作量并尽早完成调度，之后尝试官方Scenario 2指导，计算耗时增10倍，且10辆车仅2辆被使用。

请求参数示例 #

{
    "Model": {
        "Shipments": [
            {
                "Deliveries": [
                    {
                        "ArrivalLocation": {
                            "Latitude": 52.4289138,
                            "Longitude": 10.7940308
                        },
                        "Duration": {
                            "Seconds": 675
                        },
                        "Label": "6868"
                    }
                ]
            },
            {
                "Deliveries": [
                    {
                        "ArrivalLocation": {
                            "Latitude": 52.4289138,
                            "Longitude": 10.7940308
                        },
                        "Label": "6482"
                    }
                ]
                // 700+ 更多配送点...
            }
        ],
        "Vehicles": [
            {
                "DisplayName": "Technician 1",
                "StartLocation": {
                    "Latitude": 53.17496,
                    "Longitude": 8.71998
                },
                "EndLocation": {
                    "Latitude": 53.17496,
                    "Longitude": 8.71998
                },
                "StartTimeWindows": [
                    {
                        "StartTime": {
                            "Seconds": 1780300800,
                            "Nanos": 0
                        }
                    }
                ],
                "EndTimeWindows": [
                    {
                        "SoftEndTime": {
                            "Seconds": 1780329600,
                            "Nanos": 0
                        },
                        "CostPerHourAfterSoftEndTime": 10,
                        "HasCostPerHourAfterSoftEndTime": true
                    }
                ],
                "TravelDurationMultiple": 0.25,
                "HasTravelDurationMultiple": true,
                "CostPerKilometer": 2.5,
                "Label": "11:0"
            }
            // 49辆更多（每周每位技术人员对应1辆"车辆"）
        ],
        "GlobalStartTime": {
            "Seconds": 1780300800,
            "Nanos": 0
        },
        "GlobalEndTime": {
            "Seconds": 1780682400,
            "Nanos": 0
        },
        "GlobalDurationCostPerHour": 150
    },
    "Label": "Period planing"
}

返回结果片段 #

"Metrics": {
    "AggregatedRouteMetrics": {
        "PerformedShipmentCount": 724,
        "TravelDuration": {
            "Seconds": 193104,
            "Nanos": 0
        },
        "WaitDuration": {
            "Seconds": 0,
            "Nanos": 0
        },
        "DelayDuration": {
            "Seconds": 0,
            "Nanos": 0
        },
        "BreakDuration": {
            "Seconds": 0,
            "Nanos": 0
        },
        "VisitDuration": {
            "Seconds": 488700,
            "Nanos": 0
        },
        "TotalDuration": {
            "Seconds": 681804,
            "Nanos": 0
        },
        "TravelDistanceMeters": 12871052,
        "MaxLoads": {}
    },
    "SkippedMandatoryShipmentCount": 0,
    "UsedVehicleCount": 6,
    "EarliestVehicleStartTime": {
        "Seconds": 1780379222,
        "Nanos": 0
    },
    "LatestVehicleEndTime": {
        "Seconds": 1780674065,
        "Nanos": 0
    },
    "Costs": {
        "model.vehicles.end_time_windows.cost_per_hour_after_soft_end_time": 1876.775,
        "model.vehicles.cost_per_kilometer": 32177.63,
        "model.global_duration_cost_per_hour": 12285.125
    },
    "TotalCost": 46339.53
}

问题根源分析 #

1. 时间窗口与压缩逻辑冲突：把4天工作压缩为1天，但车辆的EndTimeWindows设置的是单日软结束时间，而GlobalEndTime是周四结束。混合设置让API无法正确理解跨天工作模式，车辆被限制在单日任务，倾向于用更少车辆完成集中任务。
2. 车辆配置冗余且成本导向偏差：配置了50辆车（远超实际每周10人的需求），且未设置车辆启用固定成本，API优先选择“少车高里程”的低成本方案，自然少用车。
3. Scenario 2适配错误：未正确配置车辆中途停留点（酒店）和每日时间窗口，反而增加模型复杂度，导致计算耗时飙升，同时约束设置不当，仅少量车辆能匹配可行路径。

修正方案 #

• 重构时间与车辆模型：放弃“4天压缩为1天”的逻辑，为每个技术人员创建4条每日任务链：
  • 周一：家→服务点位→酒店
  • 周二至周三：酒店→服务点位→酒店
  • 周四：酒店→服务点位→家
    为每辆车配置对应每日的StartLocation、EndLocation和准确时间窗口。
• 添加车辆启用成本：在每个Vehicle对象中设置FixedCost（比如每辆车每日启用成本500），让API权衡“少车高里程”和“多车均衡任务”的成本，强制启用更多车辆。
• 调整成本权重：降低CostPerKilometer权重，提高GlobalDurationCostPerHour或车辆时间成本，引导API优先考虑尽早完成任务和均衡工作量，而非单纯追求低里程。
• 正确适配多日场景：参考官方多日调度配置，为车辆添加IntermediateLocations（酒店），并通过Shipment的TimeWindows绑定任务到具体日期，明确任务时间分布。
• 简化初始模型：先测试小规模任务（如50个点位+10辆车），验证配置逻辑正确后再扩展到700个点位，避免模型过于复杂导致计算异常。

内容的提问来源于stack exchange，提问作者ub_coding