一个集装箱从船到火车的两个小时，AI 搭档 Coco在中间做了什么

导读海铁联运的理想画面是集装箱从远洋货轮卸下一个小时内装上进港铁路的平板车发往内陆。但现实中从卸船到装上火车这条短短几公里的路径经过三套互不通信的系统——码头的 TOS 管卸船计划、铁路平台管车皮调度、拖车公司管短驳安排。调度员需要逐个系统翻看手动推算时间窗口。《交通运输数据安全管理办法》2026 年 7 月施行后舱单和调度数据还不能离开港区内网。本文聚焦一个具体问题当三套系统各跑各的一个跑在本地服务器上的 AI 搭档能不能把时间窗口对齐。一个船到车流程三套独立运转的系统集装箱从货轮卸下到装上火车这条路径叫船到车。以长江沿线一座典型的多式联运港口为例流程是这样的货轮靠泊 3 号泊位TOS 生成卸船计划——哪个箱子先卸、哪个后卸、卸完放到堆场哪个区位。卸船需要 40 分钟这期间铁路场站的调度平台已经排好了车皮计划——14:00 空车皮到达铁轨区。拖车公司需要在这 40 分钟内把卸下来的箱子从堆场短驳到铁轨区装车窗口是 13:10 到 13:50。三套系统各管一段互不通信。TOS 只管卸船不知道铁路车皮什么时候到。铁路平台只管车皮不知道卸船进度。拖车公司只管短驳既不知道卸船排到了第几个箱子也不知道铁路那边有没有延误。结果就是调度员的工作变成了逐个系统查看手动推算。打开 TOS 看卸船进度——嗯比计划晚了 15 分钟。切到铁路平台看车皮状态——车皮还在编组站可能迟到。打开拖车 App 看车辆位置——三号车在路上还剩两公里。把这些信息在脑子里拼起来推算出新的时间线然后分别通知三方。每天有几十个箱子走船到车这套操作每天重复几十次。一个箱子延误下游箱子跟着排队。一个拖车迟到整个装车窗口作废。更深的麻烦在于这些因 A 系统延迟导致 B 系统调整的动态关系没有沉淀在任何地方。调度员心里清楚——每次 X 船公司靠泊都晚要留 15 分钟 bufferY 铁路段周二上午车皮最紧千万别卡那个窗口——但这些经验只存在于人脑换一个人值班就从头来过。Coco 怎么对齐三个时间窗口中奥Coco 是一个企业级 AI Agent 平台。在这个场景里它不碰 TOS 的卸船算法不做铁路调度不给拖车派单——而是通过 MCP 协议读取三套系统的数据在同一份上下文中生成联运动态表。第一步MCP 接入。Coco 通过 MCPModel 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官网https://coco.sinoaus.net