船舶制造多智能体生产协同 | FDE模式效果对赌+断点续跑机制

一艘大型散货船的建造涉及上百万个零件、数千份设计图纸、几十个分段、上百个外包队伍与横跨两三年的工期，任何一个环节的延误都会沿着搭载网络放大成整船的节点失守。船舶制造多智能体生产协同正在把这种依赖调度会与经验的”人肉协调”，升级为可计算、可推演、可追责的协同系统：多个专职AI智能体分别负责计划编排、物料齐套、场地与设备调度、劳务平衡、变更影响传播与风险预警，在同一份数字底座上持续博弈与收敛。与常见的MES或排产软件不同，船舶制造多智能体生产协同的难点不在算法本身，而在真实船厂的”不完美现实”——网络中断、数据缺录、临时插单、设计变更、天气停工——系统必须能在中断后从断点精确续跑，而不是推倒重来。本文系统拆解它的产业背景、技术构成、FDE模式落地流程、真实案例、方案对比、常见误区与验收指标。

一、为什么船舶制造多智能体生产协同成为企业数智化必选项

1.1造船是典型的项目型制造，复杂度天然超标

与汽车、家电这类重复型制造不同，造船是典型的ETO（Engineer to Order，按订单设计）项目型制造。每一艘船都是一个独特项目：船东不同、船型不同、规范要求不同、设备选型不同。这带来三个结构性难题：

一是设计周期与生产周期高度重叠。很多船厂存在”边设计、边生产、边修改”的现实状态，设计图纸下发滞后、升版频繁，生产部门往往在图纸未完全到位的情况下开工，后续变更不断。

二是物量巨大且长周期采购项多。主机、舵机、甲板机械、配电板、电缆、管系附件等关键设备的采购周期从数月到一年以上，一旦到货延迟，会直接卡住舾装与调试节点。

三是资源约束极度复杂。船坞、船台、龙门吊、平板车、分段堆场都是稀缺资源，一个分段何时从堆场转运到搭载位置，需要同时满足场地可用性、吊车能力、转运通道、人员班组与技术状态（涂装完成、舾装完成、检验合格）等多重条件。

1.2经验调度的三条失效路径

传统船厂的生产调度高度依赖生产管理部门的经验，通常通过周计划会、日协调会与现场巡查来推进。这套方式在小批量、稳定船型时代是有效的，但在多船并行、船型切换频繁的今天，正在三条路径上失效：

第一条是信息滞后。会上讨论的进度信息，往往是昨日甚至上周的状态。当某个分段的焊接因为探伤不合格而返工时，这个信息要传导到计划部门、再传导到相关分段与坞期安排，通常要好几天。滞后的信息导致滞后的决策。

第二条是局部最优。每个车间都在优化自己的指标：钢料车间希望批量下料以提高切割效率，分段车间希望集中资源赶关键分段，涂装车间希望一次进场多干几个分段。各自合理，全局却可能冲突——钢料车间的批量下料导致分段车间急需的那块料排在队列末尾。

第三条是不可推演。当船东提出提前两周交船，或者某个关键设备延迟一个月到货时，调度部门很难在短时间内算出”如果这样调整，会影响哪些分段、哪些坞期、哪些其他船”。缺乏推演能力，就只能凭感觉承诺。

1.3断点续跑为什么是刚需而非锦上添花

这是船厂场景区别于普通工厂的特殊之处，值得单独强调。

船厂的网络与终端环境远比一般车间恶劣：露天作业、金属结构对无线信号的屏蔽、龙门吊移动带来的信号切换、临时断电、系统维护窗口、现场工人使用的移动端断网……这些都意味着任何依赖”持续在线服务”的系统在船厂都会频繁中断。

更关键的是，生产协同任务的本质是一系列长事务：一次全局排程可能涉及几千个任务节点的约束求解，耗时从几分钟到几十分钟；一次设计变更的影响传播要遍历整条任务网络；一次齐套检查要扫描上百万条物料记录。如果这些任务在执行到70%时因为网络中断或进程重启而失败，系统要么从头再来（浪费算力与时间，且结果可能已不一致），要么必须使用断点续跑机制从中断处精确恢复。

断点续跑不是一个技术细节，它决定了系统在船厂能否真正被信任。一个每次断网就要重跑两小时的系统，现场调度员用三次就会放弃。

1.4效果对赌为何在造船场景特别重要

造船项目的投入大、周期长，船厂对IT项目的普遍态度是”听过太多失败的案例”。过去十几年，不少船厂上过MES、上过三维设计平台、上过供应链系统，投入不菲但收效参差，原因往往是系统与实际生产两张皮。

要打破这种信任壁垒，最有效的方式就是把付款与可测量的业务结果绑定：计划达成率提升多少、分段平均制造周期缩短多少、等工率下降多少、坞期利用率提升多少。FDE模式的效果对赌正是为此设计的——供应商不再对”软件功能上线”负责，而是对”生产指标改善”负责。这一条对船厂决策者的说服力，远超任何技术白皮书。

二、船舶制造多智能体生产协同到底是什么（定义与能力边界）

2.1定义与Agent分工

船舶制造多智能体生产协同，是指面向船舶建造全流程（钢材预处理、切割加工、部件装配、分段制造、分段涂装、总组、船坞/船台搭载、舾装、系泊试验、试航交船），由多个具备独立职责、通过统一协议通信的AI智能体组成的生产协同与调度系统。

典型的Agent分工如下：

• 计划Agent：负责多船、多项目的分层计划编排，输出从三年线表到周计划的完整计划体系，并在扰动发生时做重排；
• 齐套Agent：以托盘（Pallet）为单位跟踪物料、图纸、设备的到位状态，预测缺口与到货风险；
• 场地Agent：管理分段堆场、平台、船坞/船台的占用，做空间-时间二维排布优化；
• 设备Agent：调度龙门吊、门座吊、平板车、焊接设备等关键资源，处理能力约束与冲突消解；
• 劳务Agent：按工种与班组平衡工作量，考虑外包队伍的产能、技能矩阵与出勤波动；
• 变更Agent：接收设计变更与船东变更，沿任务网络传播影响，输出受影响的任务清单与建议调整方案；
• 风险Agent：持续扫描计划与实际的偏差，提前预警可能失守的节点；
• 断点管家Agent：负责长事务的检查点、状态快照与恢复，是断点续跑机制的执行者。

2.2断点续跑机制的技术内核

展开说明这一机制，因为它直接关系到系统在真实船厂的可用性。

第一层：任务图与检查点。 任何一次长任务（全局重排、齐套扫描、影响传播）都会被分解为有向无环的任务图（DAG），每个节点完成后写入检查点记录，包含输入摘要、输出摘要、状态与时间戳。这样重跑时可以从最后一个完成节点继续，而不是从零开始。

第二层：事件溯源与状态快照。 系统状态不由”当前数据库值”单独定义，而是由”初始状态+事件流”定义。每次状态变更以事件形式追加写入日志，同时周期性生成状态快照。恢复时加载最近一次快照，再重放其后的事件，即可精确还原到中断前的状态。这种方式还带来额外好处——任何一次决策都可以追溯”当时是基于什么信息做出的”。

第三层：幂等与补偿。 生产协同任务常常需要写回MES或ERP。断网恢复后如果直接重做，可能产生重复数据。因此所有外部写操作必须设计成幂等的（带唯一业务键），失败时执行补偿事务回滚。这是断点续跑能否安全落地的关键。

第四层：离线优先的边缘执行。 在船厂信号薄弱区域，移动端与边缘节点采用离线优先设计：现场操作先写入本地队列，恢复连接后自动同步，冲突由服务器按业务规则仲裁。现场工人不需要因为没信号就停止报工。

第五层：人机接续。 当系统不可用时，调度员必须能够手工接管；而系统恢复后，应当能读取人工决策的结果继续推演，而不是推翻人的安排。这一条在船厂尤其重要——如果系统每次恢复都推翻现场已经执行的安排，它就会被彻底抵制。

2.3能力边界

能做到的： 在多船并行场景下给出全局更优的分段排程与搭载计划；把设计变更的影响在分钟级内传播到全部相关任务；提前数周预警可能失守的节点与关键设备风险；把齐套检查从人工翻表变为自动扫描；在断网、断电、进程重启后从断点精确恢复。

难以承诺的： 替代项目经理的判断与决策；在输入数据严重缺失（例如大量工序未报工）的情况下给出可靠排程；完全消除变更带来的影响（变更本身就是代价）；预测天气、船东付款节奏、供应链突发事件这类外部不确定性——系统只能做情景推演，不能预知未来。

前置条件： 具备基本的WBS/托盘/工序编码体系（不要求完美，但要有）；设计BOM与制造BOM至少有可用的映射关系；现场具备报工终端或至少每日的纸质报工可录入；生产管理部门愿意接受系统给出的建议并参与评审。

三、FDE模式合作流程

3.1需求诊断：把船厂的”乱”变成可计算的结构

诊断期通常3-4周，FDE团队驻场。造船场景的诊断比一般行业更重，因为需要先理解船厂特有的生产组织方式。

核心工作包括：梳理生产流程与分段划分规则；盘点现有系统的边界（设计系统、ERP、MES、物资系统各自管到哪一层）；抽取过去2-3个已交付船型的实际执行数据，分析计划达成率、分段周期分布、等工原因分布；跟随调度员参加完整的周计划会与日协调会，记录真实决策逻辑；访谈钢料、分段、涂装、搭载、舾装等关键车间。

诊断的产出是《生产协同现状诊断报告》《数据可用性评估》《对赌指标候选清单》。这一阶段最常见的发现是：船厂以为瓶颈在吊车，实际数据分析后发现瓶颈是堆场面积与分段转运通道；或者以为问题是计划不准，实际是齐套信息不透明导致的临时抢工。

3.2方案设计：架构、算法与对赌口径

方案设计要明确三件事。

一是Agent边界与通信协议。哪些决策由哪个Agent负责、Agent之间如何协商（合同网协议、拍卖机制还是中心协调）、冲突如何仲裁。实践中我们通常采用”中心协调+局部自治”的混合模式：关键资源（船坞、龙门吊）由中心协调，车间内部细节由局部Agent自治。

二是求解算法选型。造船排程属于典型的资源约束项目调度问题（RCPSP）及其变体，通常是NP-hard。工程上一般采用”约束规划+启发式+局部搜索”的组合：用约束规划保证可行性，用启发式快速生成初始解，用局部搜索（模拟退火、禁忌搜索或大邻域搜索）持续改进。对于大规模场景，还会引入分解策略，按船、按阶段分块求解再协调。

三是对赌指标口径。这是造船项目最容易扯皮的地方，必须写清：计划达成率的分母是什么（按分段数还是按工序数）、统计窗口多长（周、月还是节点）、哪些延误属于免责（天气、船东变更、重大设备故障）、基线数据取自哪几个历史船型。口径不清，后期必然争议。

3.3驻场开发：在船坞旁写代码

驻场开发期一般12-20周，团队包括调度算法工程师、数据工程师、船体工艺顾问与实施顾问。工作地点通常在船厂生产管理部门旁边。

造船场景必须驻场的原因很具体：船厂的业务规则有大量”例外”。例如某个分段因为超宽只能在夜间转运，某台龙门吊在大风天气必须停机，某个外包队只在特定码头作业。这些规则不会写进任何文档，只有天天泡在现场才能收集完整。远程开发出来的排程系统，往往因为忽略这些例外而得出”理论上很优、实际不可执行”的方案。

开发节奏：数据接入与清洗（3-4周）→Agent与算法开发（5-8周）→断点续跑与容错机制（2-3周）→现场试点与调优（3-4周）→培训与移交（2周）。

3.4效果对赌：把付款绑在生产指标上

造船项目的对赌通常分三层：

第一层是功能验收款，对应系统上线、数据打通、试点分段跑通；
第二层是指标达成款，与计划达成率、分段平均制造周期、等工率、坞期利用率等挂钩，按季度或按船考核；
第三层是增量分成，系统带来的坞期压缩与产能提升，按约定的方式分享收益。

对赌设计上要注意两点：一是设置免责条款，把天气、船东变更、供应链不可抗力造成的延误排除在外，否则供应商会承担无法控制的风险，报价必然畸高；二是设置阶梯，达成80%结算多少、达成100%结算多少、超额达成如何奖励，让双方利益一致。

3.5源码交付：把调度能力移交到生产部门手中

交付内容包括：Agent框架与全部业务Agent源码、算法实现与调参说明、数据接口与ETL脚本、断点续跑的配置与运维手册、以及对赌指标的自动化统计脚本（这份脚本必须交付给客户，否则供应商既是运动员又是裁判员）。

能力转移方面，为客户培养2-3名”生产协同数据工程师”，使其能独立完成新船型的数据结构配置、规则调整与指标统计。撤场标准：客户团队能独立完成一个新船型的完整上线配置，并在连续两个月的对赌统计中维持指标不下降。

四、行业落地案例

4.1案例一：某中型船厂的多船并行分段排程优化

该船厂同时建造4艘散货船与2艘集装箱船，两条船坞、三个平台，年交付能力在10艘左右。痛点集中在分段制造：分段平均制造周期波动大，经常出现”前道工序等图纸、后道工序等场地”的交替等待，堆场周转率持续偏低，坞期安排频繁调整。

FDE团队进场后，第一步是建立分段级任务网络：把每个分段拆解为下料、加工、部件装配、分段装配、焊接、探伤、舾装、冲砂、涂装、转运等标准工序，明确每道工序的资源需求与前置条件。第二步是接入齐套数据，让齐套Agent能实时回答”这个分段现在能不能开工”。第三步才是排程优化。

关键突破在于场地的时空二维排布。场地Agent把堆场划分为网格，按分段的尺寸、重量、出坞顺序与转运路径做布局优化，目标是让”即将使用的分段”尽可能靠近转运通道。这一项优化就把堆场的翻垛次数降低了约三成，直接减少了平板车与龙门吊的无效作业。

结果：上线8个月后，分段平均制造周期缩短约13%，计划达成率（按分段节点）从约72%提升到88%，坞期利用率提升约6个百分点。更值得注意的是断点续跑机制的实际表现：在台风停工、网络改造、系统升级等多次中断后，全局重排任务均能从断点恢复，最长一次中断后的恢复耗时不到原来的15%，生产部门对系统的信任因此建立起来。

4.2案例二：某船厂的设计变更影响传播与重排

这家船厂的痛点不是排程，而是变更。船东在建造过程中提出舱室布局调整，涉及约200份图纸升版、上千个托盘的物料变更与多个分段的返工。过去评估这类变更的影响，需要计划、设计、物资、生产四个部门开三四次会，耗时两周，且结论常常不完整。

变更Agent的实现方式是：维护一张覆盖”图纸—托盘—物料—工序—分段—坞期”的全链路关系图。当变更指令进入系统后，Agent沿图做双向遍历：正向查找受影响的下游工序，反向查找已完成的工作（判断是否需要返工）。遍历过程输出受影响清单、影响的严重程度分级与建议的调整方案。

在这个案例中，系统在20分钟内完成了第一轮影响分析，识别出受影响的47个分段、1300余个托盘与6个关键节点，并给出了三套重排方案（最小返工方案、最小周期方案、折中方案）供管理层选择。管理层选择了折中方案，最终的节点影响比最初预估减少了一半以上。评估时间从两周压缩到一天，这是该项目最被生产部门认可的价值。

4.3案例三：某船厂的劳务与设备协同平衡

第三个案例聚焦于劳务与设备。该船厂大量使用外包队伍，劳务波动大，常常出现”某工种人手不足导致分段停工、另一工种却闲置”的结构性失衡，同时龙门吊的争抢也很严重。

设备Agent与劳务Agent采用协商机制：设备Agent按吊车的起重量、跨度与可用时段分配作业窗口，劳务Agent按工种技能矩阵与出勤预测分配人力，两者通过轻量级的协商协议解决冲突——当吊车窗口与人手窗口不匹配时，由计划Agent按优先级（关键路径优先）仲裁。

实施后，等工率（因等待资源导致的停工时占总工时比例）下降了约8个百分点，龙门吊的无效等待时间下降明显。这一项目也验证了断点续跑在移动端场景的价值：现场报工在信号盲区先落地缓存，恢复后自动同步，报工及时率从原来的不足70%提升到95%以上，反过来又提升了排程的输入质量——数据质量与算法效果形成了正循环。

五、船舶制造多智能体生产协同方案对比

船厂在推进生产协同时，通常有四条路径。下表从成本、周期、风险、效果保障与知识沉淀五个维度对比。

5.1四种方案的真实优缺点

FDE驻场外包。 优点是对赌机制把风险真正共担，驻场保证业务规则收集完整，断点续跑等容错能力是内建的，交付后客户具备自主运维与配置能力。缺点是要求船厂开放生产数据并投入业务人员配合，且对赌需要清晰的基线数据。适合多船并行、调度压力真实存在、且内部IT力量有限的船厂。

传统人力外包。 优点是灵活、可快速调整范围。缺点是外包团队对造船业务的理解有限，做出来往往是”通用项目管理的壳子”，装不进船厂的真实规则；而且按人月计费的机制天然不利于快速结项。适合数据录入、报表开发这类确定性工作。

企业自建团队。 优点是能力完全内化，长远看成本最优，且Know-how不外流。缺点是复合型人才稀缺（既懂造船工艺又懂优化算法），且自建容易陷入平台建设的长周期，一年半载看不到业务效果，容易失去管理层支持。适合大型造船集团，且建议采用”自建+外部顾问”的混合模式。

通用MES/APS套件。 优点是成熟稳定、有行业模板、实施风险表面可控。缺点是绝大多数APS产品面向重复型制造设计，其排产模型假设”产品固定、工艺固定、批量重复”，与造船的”单件项目型、设计生产并行、变更频繁”严重不匹配。常见结果是套件只能管到报工与记录，排程部分最终还是Excel。适合作为数据底座与执行层，协同优化层需另行建设。

5.2为什么断点续跑机制应该写进合同技术条款

这一条值得单独提出来。很多船厂在招标时关注的是算法多先进、界面多漂亮，却忽略了一个朴素问题：这套系统在船厂这种环境里，能不能稳定地连续运行一年？

建议把断点续跑的要求具体化为可验证的条款：

• 全局重排任务在任意时点被强制中断后，恢复时间不超过完整重跑时间的20%；
• 恢复后的结果与未中断情况下的结果一致（可通过对拍验证）；
• 移动端断网状态下的报工数据不丢失，恢复后自动同步且无重复；
• 所有对外系统的写操作具备幂等键与补偿机制，重复执行不产生脏数据；
• 系统不可用期间的人工决策，在恢复后可被系统读取并继续推演。

这几条都可以通过压力测试验证：在测试环境中人为制造网络中断、进程重启、数据库闪断，观察系统表现。能在这种测试里活下来的系统，才配得上船厂的生产节奏。

六、常见落地误区

6.1误区一：把系统当成”自动排产机”，期待一键出计划

造船排程的输入极其复杂，任何系统都不可能在数据不全、规则不清的情况下自动产出可用计划。正确的定位是”人机协同推演”：系统负责处理复杂度（几千个节点的约束求解、变更影响的全链路遍历、多方案对比），人负责处理不确定性（判断外包队的实际能力、预估天气影响、协调船东关系）。期待一键出计划的项目，通常会在试点阶段就失败，因为第一版计划必然不符合现场直觉。

6.2误区二：先建平台，后做业务

这是所有大型制造企业的通病：先花一年建数据中台、主数据平台、统一编码体系，等平台建好了，项目热情早已耗尽。造船场景尤其如此，因为编码体系（分段号、托盘号、工序码）本身就存在历史遗留问题，指望一次性理顺是不现实的。正确的做法是”以用促治”：先围绕一个具体的痛点（例如分段排程或齐套预警）打通必要的数据，见到效果后再逐步扩展治理范围。

6.3误区三：忽略报工数据的及时性与真实性

排程的质量上限由输入数据决定。如果现场报工滞后三天，或者为了好看而虚报完成比例，系统给出的排程必然失真。解决数据及时性要靠体验：让报工变得比不报更省事（移动端扫码、与门禁或吊车作业记录联动、批量确认），而不是靠考核惩罚。解决真实性则要靠交叉验证：用吊车作业记录、涂装进场记录等客观数据校验人工报工，发现异常及时提示。

6.4误区四：对赌指标只看平均值

计划达成率的平均值很容易被”操作”：把容易的分段排进统计窗口、把难的分段往后挪，平均值就好看了。因此对赌指标必须配套约束：统计口径要覆盖全部在制分段，不能选择性取样；要同时看均值与方差（波动性本身就是管理能力）；要绑定下游指标（坞期节点达成率），防止局部好看、全局恶化。

6.5误区五：把外包队伍排除在系统之外

很多船厂的系统只管到自有车间，外包队伍的进度靠电话与微信群。但造船的外包比例往往很高，外包队伍承担了相当比例的焊接、舾装与涂装作业。把他们排除在外，系统的输入就缺了一大块。正确做法是给外包队伍提供极简的报工入口（小程序扫码或班组长批量填报），并把报工及时性写进外包合同的考核条款。

6.6误区六：上线后停止规则维护

船厂的生产组织不是静态的：新设备投产、新船型引入、车间布局调整、管理流程变更，都会让系统里的规则过期。如果上线后无人维护，两年后系统给出的建议会越来越偏离现实，最终被弃用。必须在项目结束前明确规则的所有者与维护流程，最好把”规则季度评审”设为生产管理部门的固定动作。

七、常见问题FAQ

Q1：数据基础很差，还能做吗？

能做，但要先做数据治理。判断标准是：能否拿出一个完整船型的分段清单、工序清单与关键节点计划？如果能，哪怕数据分散在Excel里，也可以先做结构化导入；如果连这个都没有，建议先做一个为期两三个月的数据梳理专项。实践中，我们见过数据质量最差的船厂，也是从”三个Excel表”起步的，关键是先跑通一个痛点场景，用效果推动数据治理。

Q2：断点续跑机制会不会让结果不一致？

设计良好的断点续跑不会。核心在于”确定性重放”：只要输入数据、随机数种子与算法版本相同，从断点恢复的结果就应当与未中断的结果完全一致。为保证这一点，系统在恢复时会校验输入数据的版本号，若数据已变更则提示用户选择”按原输入续跑”还是”重新计算”。这种显式选择比静默处理更安全。

Q3：对赌指标如何避免被外部因素干扰？

三层防护：一是在合同中明确免责清单（台风、疫情、重大设备故障、船东重大变更、供应链不可抗力）；二是设置”条件达成”口径，即剔除免责因素后的达成率；三是对争议事件设置仲裁机制，由双方共同指定的第三方（如行业协会专家或监理）判定。免责清单不宜过长，否则对赌失去意义；一般控制在5-7类。

Q4：系统与现有MES、ERP如何共存？

推荐定位是”协同优化层”：MES负责执行与记录，ERP负责财务与物资，多智能体系统负责跨系统的计划编排、齐套判断与变更影响分析，通过接口读取两边的数据并把结果写回。这样既避免了推倒重来，又能发挥系统的全局优化能力。接口方式上，优先使用数据库只读视图或API，尽量避免直接写生产库。

Q5：算法给出的排程现场不认怎么办？

这是最常见的落地阻力，通常有三个原因：一是规则收集不全（遗漏了某类约束），二是目标函数与现场KPI不一致（系统优化周期，现场优化吊车利用率），三是结果不可解释（现场不知道系统为什么这么排）。对应的解法是：让调度员参与规则评审；把目标函数做成可配置、可加权的；为每个关键决策输出理由（”该分段后移是因为托盘B-217预计到货延迟6天”）。可解释性比最优性更能决定采纳率。

Q6：项目周期与费用大致是什么量级？

从诊断到可用闭环通常4-8个月，其中数据接入与规则收集占较大比重。费用结构通常是”固定开发费+指标对赌款+年度服务费”三部分。由于对赌与船厂的基线数据强相关，建议先做一次为期2-3周的诊断，把基线指标与免责清单谈清楚，再进入商务环节。可参考的行业模板与对赌条款设计，https://www.semkw.com/ 上有持续更新的资料。

Q7：能不能只做其中一个模块，例如只做齐套预警？

完全可以，而且我们通常建议这样做。齐套预警是投入产出比最高的切入点：数据要求相对低（物资系统+设计BOM即可），见效快（减少等工立竿见影），而且不需要改变现有的排程习惯。跑通之后再扩展到分段排程、场地优化与变更传播，风险更低。切忌一上来就做”全厂级的智能排产平台”。

Q8：系统会不会削弱调度部门的权威性？

恰恰相反。在成功的项目中，调度部门是最直接的受益者：他们从繁琐的信息收集与表格维护中解脱出来，把时间用于判断与协调；而且系统提供的推演能力，让他们在与船东、车间、物资部门谈判时有了量化依据，话语权反而增强。关键在于定位——系统是给调度员用的工具，不是替代调度员的角色。

八、效果衡量与验收指标

8.1四层指标体系

第一层：计划与执行指标。 分段节点计划达成率（核心指标，通常承诺较基线提升10-15个百分点）、坞期/船台节点达成率、分段平均制造周期、计划变更频次（反映计划的稳定性）、计划下达至现场的时间。

第二层：资源效率指标。 等工率（因等待图纸/物料/设备/场地导致的停工占比）、龙门吊等关键设备的有效作业率与无效等待时间、堆场周转率与翻垛次数、劳务工时利用率、分段转运平均次数。

第三层：协同与响应指标。 齐套预警提前期（从预警到实际缺料的天数）、设计变更影响评估耗时（从变更指令到完整影响清单的小时数）、异常事件闭环时长、报工及时率与准确率。

第四层：系统可靠性指标。 断点续跑恢复时间占比（恢复耗时/完整重跑耗时）、中断后结果一致性通过率、系统月度可用率、数据同步成功率、离线报工数据零丢失率。

8.2验收方式

建议分三步，并特别强调系统可靠性验收：

第一步是数据与功能验收。完成约定范围的数据接入，Agent能够正常运行并输出结果，移动端、离线同步、断点续跑等功能通过测试。可靠性测试应当在这一步完成：人为制造网络中断、进程重启、数据库闪断，验证恢复行为符合合同约定的条款。

第二步是指标验收。选取一个在制船型作为试点，系统运行满一个季度后，对比基线期的计划达成率、分段周期与等工率。注意统计口径必须与诊断阶段确定的一致，且要剔除免责事件。

第三步是业务验收。试点扩展到全部在制船型，连续两个季度指标稳定达标，且客户团队能够独立完成新船型的配置上线。这一步通常与对赌尾款与撤场条件挂钩。

8.3持续监控看板

上线后应部署面向不同角色的看板：给厂级领导的是坞期节点健康度与整体达成率；给生产管理部门的是分段进度热力图、资源冲突列表与风险预警清单；给车间的是本车间的任务清单与齐套状态；给信息部门的是系统可靠性与数据同步状态。

特别建议把”断点续跑事件日志”也做成看板的一部分——记录每一次中断的时间、原因、恢复耗时与一致性校验结果。这份日志既是系统健康度的体检报告，也是持续优化容错设计的依据。看板的结构设计与指标模板，https://www.semkw.com/ 提供了多套可参考的实现。

九、结语与行动建议

船舶制造多智能体生产协同的价值，最终要落在两个数字上：一艘船能不能按期交付，一个坞一年能多造多少船。前者关系船东信任与合同罚则，后者关系企业的产能天花板。当分段排程、齐套判断、场地调度与变更影响都能被计算，船厂就从”救火式管理”走向”预判式管理”。

对于准备启动这类项目的船厂，给出四条行动建议：

第一，从一个可量化、有痛感的场景切入。齐套预警、分段排程、变更影响分析，三者选其一。不要一开始就要”全厂智能排产平台”，那是最容易失败的路径。一个场景跑通、见到指标改善，后续扩展才有资源与信心。

第二，把基线数据先测准。在签合同之前，用过去两三个历史船型的实际数据，把计划达成率、分段周期、等工率这些基线算清楚，并让生产、物资、车间三方共同确认。基线是所有对赌的前提，也是项目价值的标尺。

第三，把断点续跑与容错能力写进技术条款，并做压力测试验收。造船现场的网络与终端环境不会因为上了系统就变好，系统在恶劣环境下的表现，决定了它能活多久。这一条成本不高，但价值极大。

第四，让调度员成为系统的共同设计者，而不是被动接受者。从规则收集、目标函数配置到结果评审，都让他们深度参与。系统上线后，他们应当是最积极的使用者，而不是最尖锐的批评者。

当效果对赌把供应商与船厂的利益绑在一起，当断点续跑让系统在真实的船厂环境里稳定运行，这套系统才真正从”信息化项目”变成”生产力工具”。船舶制造多智能体生产协同走到这一步，船厂买到的不是软件，而是按期交付的确定性。

船舶制造多智能体生产协同,AI智能体,FDE模式,效果对赌,断点续跑,分段排程,船厂生产管理,齐套预警,设计变更影响分析,造船数字化转型