- 先用业务规则收缩搜索空间，再把剩下的候选交给整数规划
- 装载区间和合同条款一起进模型，成本结构直接体现在目标函数里
- 没被合并的订单都会带一条可读原因，调度员不用回头猜
多约束智能合单服务
面向运输执行的算法服务。求解器本身不算难点，难的是模块怎么切：数据适配、分阶段分组、整数规划、未分配原因、下游下发，每一块的边界都得画清楚。边界清楚了，合单结果才能按批次进入既有运输系统，事后也查得到是哪一次算出来的。
3 段分阶段求解流程
全量未分配订单附原因码
可替换求解后端抽象层
What it proves
核心成果
- 求解
- 服务
- 集成
System flow
工作步骤
只呈现通用的模块关系和每一步要解决的问题。可交互的项目可以从上方直接进 Demo。
- 01订单接入与适配
上游订单与合同字段映射成求解器无关的内部结构。异常数据在进模型之前就被拦下来，并标注出处。
- 02规则过滤与分组
用硬性业务规则切开互不兼容的订单，一个大问题就此降解成若干个能并行算的小问题。
- 03合同区间匹配
装载区间、计费段和合同条款转成约束系数，成本结构因此直接参与目标函数。
- 04整数规划求解
在时间盒内求解组合问题。超时就返回当前最优的可行解，并标注求解状态。
- 05结果追踪与下发
输出带批次号的合单方案与诊断报文。同一批次重放一次，结果应该完全一样。
Integration
怎么接进已有系统
算法服务要和已经在跑的运输系统共存，这个案例最能说明我怎么处理。接口必须幂等，同一批次重算要得到同样的结果，失败要能解释，上线要能灰度。
| 对接系统 | 方向 | 接口约定 |
|---|---|---|
| 订单 / OMS | 上游输入 | 按批次拉取待合并订单，字段缺失在适配层就拦下并回报，不进求解 |
| 合同与主数据 | 上游输入 | 装载区间、计费段与有效期按版本号引用，同一批次因此可以复现 |
| 运输执行 / TMS | 下游输出 | 以批次号幂等下发合单方案，重复调用不会产生重复运单 |
| 消息与调度平台 | 双向 | 按调度窗口触发，求解状态与不可行原因以事件形式回流 |
表中系统名称为通用角色，不指向任何具体厂商产品或内部平台。
AI leverage
这一次人和模型各做了什么
这里只写这一个项目的分工。完整的工作方式见 AI 协作一页。
- 定义决策变量、约束语义，以及合同条款怎么落进模型
- 划服务边界：哪些归适配层，哪些归求解层
- 设计原因码体系和可复现的批次机制
- 按既定规格生成约束构造与数据适配代码，补齐边界用例
- 接口契约变更后同步重构调用方与文档
Production path
产业级可以做到什么
以下能力基于现有的模块边界和扩展点，是工程上的演进方向，和当前公开 Demo 已经实现的功能不是一回事。
- 支持多租户配置、调度窗口与幂等执行
- 替换不同求解后端做性能基准对比
- 对接数据库、消息系统与运输执行平台
Privacy boundary
公开展示边界
仅展示通用架构和抽象约束，不提供生产数据、表结构、平台标识、真实坐标或内部接口。