导读
海铁联运的理想画面是：集装箱从远洋货轮卸下，一个小时内装上进港铁路的平板车发往内陆。但现实中，从卸船到装上火车这条短短几公里的路径，经过三套互不通信的系统------码头的 TOS 管卸船计划、铁路平台管车皮调度、拖车公司管短驳安排。调度员需要逐个系统翻看，手动推算时间窗口。《交通运输数据安全管理办法》2026 年 7 月施行后，舱单和调度数据还不能离开港区内网。
本文聚焦一个具体问题：当三套系统各跑各的，一个跑在本地服务器上的 AI 搭档，能不能把时间窗口对齐。
一个"船到车"流程，三套独立运转的系统
集装箱从货轮卸下到装上火车，这条路径叫"船到车"。以长江沿线一座典型的多式联运港口为例，流程是这样的：
货轮靠泊 3 号泊位，TOS 生成卸船计划------哪个箱子先卸、哪个后卸、卸完放到堆场哪个区位。卸船需要 40 分钟，这期间铁路场站的调度平台已经排好了车皮计划------14:00 空车皮到达铁轨区。拖车公司需要在这 40 分钟内把卸下来的箱子从堆场短驳到铁轨区，装车窗口是 13:10 到 13:50。
三套系统，各管一段，互不通信。TOS 只管卸船，不知道铁路车皮什么时候到。铁路平台只管车皮，不知道卸船进度。拖车公司只管短驳，既不知道卸船排到了第几个箱子，也不知道铁路那边有没有延误。
结果就是，调度员的工作变成了"逐个系统查看，手动推算"。打开 TOS 看卸船进度------嗯，比计划晚了 15 分钟。切到铁路平台看车皮状态------车皮还在编组站，可能迟到。打开拖车 App 看车辆位置------三号车在路上，还剩两公里。把这些信息在脑子里拼起来，推算出新的时间线，然后分别通知三方。
每天有几十个箱子走"船到车"，这套操作每天重复几十次。一个箱子延误，下游箱子跟着排队。一个拖车迟到，整个装车窗口作废。
更深的麻烦在于：这些"因 A 系统延迟导致 B 系统调整"的动态关系，没有沉淀在任何地方。调度员心里清楚------"每次 X 船公司靠泊都晚，要留 15 分钟 buffer""Y 铁路段周二上午车皮最紧，千万别卡那个窗口"------但这些经验只存在于人脑，换一个人值班就从头来过。
Coco 怎么对齐三个时间窗口
中奥Coco 是一个企业级 AI Agent 平台。在这个场景里，它不碰 TOS 的卸船算法，不做铁路调度，不给拖车派单------而是通过 MCP 协议读取三套系统的数据，在同一份上下文中生成联运动态表。
第一步，MCP 接入。Coco 通过 MCP（Model Context Protocol）分别连接 TOS 的卸船计划接口、铁路平台的车皮调度查询接口和拖车公司 SaaS 工具的车辆位置接口。每个连接需要单独开发和验证------周期取决于各系统的接口标准化程度，通常在数周到一两个月之间。连接建立后，Coco 可以读取三个系统的实时状态，但不写入或控制任何系统。
第二步，动态表生成。Coco 把三套系统的数据拉进同一个上下文中，按时间线排列------"12:30 船靠泊 3 号泊位 → 预计 13:10 卸船完成 → 铁路车皮 14:00 到达铁轨区 → 拖车短驳窗口 13:10-13:50"。这不是一张静态的时间表------当调度员发现 TOS 显示卸船延迟，在终端上刷新查询，Coco 在数秒内重新拉取三套系统的最新状态，生成更新后的动态表：拖车窗口后移、铁路装车窗口压缩、如果压缩到不可行则标记冲突节点。
第三步，经验注入。调度员可以把已知的规律------"X 船公司平均晚点 15 分钟""Y 铁路段周二上午车皮紧张"------配置进 Coco 的知识体系。这些经验以结构化规则的形式存储（船公司 = X, delay_buffer = 15min），也可以用自然语言描述后由 Coco 辅助整理。以后每次生成动态表时，Coco 将这些经验因素纳入推算。
TOS 和铁路平台的调度数据走港区局域网，不经过互联网。拖车公司的 SaaS 工具通过互联网读取------这是三套系统里唯一需要外网的数据源。Coco 本身的推理和经验检索在本地服务器上完成，不依赖外网。暴雨导致基站断电时，拖车数据可能暂时不可用，但 TOS 和铁路数据仍在------Coco 可以基于已有数据生成参考方案，拖车短驳信息由调度员手动补充。
调度员不再需要逐个系统跳转和手动推算。面对的不是 TOS、铁路平台和拖车 App 三个独立的界面，而是一个终端上的联运动态表------刷新查询后数秒内更新，哪个环节延迟了、哪些下游窗口被影响、有哪些经验提醒需要注意。
做完之后，调度中心得到了什么
第一，三套系统的时间线第一次出现在了同一个屏幕上。不是"为 AI 重建数据管道"，而是在现有系统上打开标准化的读取通道。
第二，老调度员的经验从"嘴上说说"变成了每次排程时随动态表一起调出的参考因子。人换班了，经验还在表里。
第三，卸船计划和铁路车皮信息留在港区内网，满足《交通运输数据安全管理办法》对舱单和调度数据的合规要求。推理在本地服务器上完成。拖车位置信息因 SaaS 工具性质经过互联网，断网时该数据源暂时不可用，但不影响 Coco 基于 TOS 和铁路数据继续生成排程参考。
Coco 不碰 TOS 的卸船算法，不接入铁路调度信号，不给拖车派单。它做的事用一句话概括：调度员触发查询后，Coco 在数秒内拉取三套系统的最新数据，注入调度员的经验因子，在延迟发生时标记冲突节点。判断始终由调度员做出------哪些冲突可以接受、哪些必须干预、优先保哪一票箱子。
回到最初的问题：一个集装箱从船到火车，三套系统各跑各的，AI 搭档能不能把时间窗口对齐？
答案是可以，但方式不是"AI 自己调度"。Coco 的角色是读懂三套系统的数据、记住老调度员的经验规律、在每次查询时把它们拼成一份完整的联运动态表。调度员不再逐个系统翻看和手动推算------刷新一次查询，最新的时间线和冲突节点就在面前。
这条路需要前期投入：系统对接、经验整理、规则配置。不是零成本。但它不要求港区把数据交给云、不限制港区只能用一家模型厂商、不碰任何已有系统的核心功能------它做的是在现有系统之间，把断掉的信息链接上一截。对于 2026 年 7 月之后必须面对数据不出港区这道硬约束的港口来说，这正是最务实的落点。
本文参考：
- 交通运输部《交通运输数据安全管理办法》(2026年7月28日)
- 交通运输部《综合运输服务发展"十五五"规划》(2026年7月24日)
Coco官网：coco.sinoaus.net