(接上篇)
四、工程总承包协议关注要点——构建平衡与可执行的契约
(一)重点关注工程承包范围及发包人要求
(二)关注价格商务条款设计
算力中心项目周期长,且存在核心设备成本占比高、价格波动剧烈的情况下,笔者遇到有些发包人在图纸出具后就坚持“转固”,要求采用完全固定总价合同的模式,但这种模式对承包商而言风险相对较高,易导致其偷工减料或陷入亏损;对于发包人而言,后续也还是不可避免会遇到承包商过分尺度的“二次经营”,进而引发纠纷。对此,笔者参考建议是对于价格商务条款的设计,本质是做好波动应对,明确调整与不调整的范围区间机制,使得承包人合理利润区间及发包人的投入成本可控。
1、条款设计建议
(1)合同价格与调整机制:锁定风险区间
首先,从成本管理角度,笔者建议商务层面可以从价格理解上做个拆解,明确其构成后进行分级造价控制,主要是在于人工和一些主材的波动控制。笔者遇到造价控制较好的企业,会把主材进一步进行A、B、C三类划分,明确可调整及不可调整的区间机制,对于变更内容对应进行分级管理的模式;措施费、管理费等这些组价费用,可以锁定一个计价模式及风险范围,例如措施费包干锁定,甚至进一步明确无论施工平面布置是否调整,费用锁定包干后不予调整;至于其他IT硬件设备等该类费用,其实波动受市场环境影响较大,建议是需要关注的,进而为调整机制奠定基础,在商务条款设计上,建议可提供明确的调价计算公式示例及不可调整的区间范围,并规定如涉及调价的范围,则规定要求承包商需在采购前提供价格波动证据,经发包人审核后调整合同价。
(2)支付节点:与里程碑和性能挂钩
支付不应仅与物理进度挂钩,而应与关键里程碑和技术验证点深度绑定。这点笔者相信项目中,商务层面都会考量,在此不用展开赘述。
(3)变更签证管理:实操明确与规范
算力中心项目技术方案可能在建设中途因外部市场或技术进步而调整,变更不可避免,但变更流程不规范、签证确认不及时、变更计价争议是导致项目“烂尾”或严重超概的常见原因。
条款设计要点:(1)明确变更的界定与程序。例如“变更的触发条件”明确列出构成变更的具体情形(如:发包人要求变更、设计错误、法律变更、不可抗力等);(2)明确变更指令的权限。例如发包人代表的权限是全权授权,还是根据不同情形分级授权,涉及经济、工期实质签证在什么区间内属于现场代表可确认的范畴;项目印鉴的使用限制范围等。(3)明确变更估价的原则。(4)明确现场签证的规范操作,需及时确认,例如对于隐蔽工程或事后难以计量的零星工作,必须在现场共同测量、签字确认,合同附件签证单格式应清晰记录工作内容、发生原因、具体工程量、发生日期、参与人员等信息,避免事后回忆不清。
2、实操建议例举
例如“进口某设备缺货”导致采购成本飙升或工期延误。承包商主张此为不可抗力或情势变更,要求调价和延期,发包人则认为承包商应预见供应链风险并已包含在风险费中。
对此笔者建议,就“关键设备市场供应短缺”情况,明确列为合同约定的可补偿事件,约定若发生此类情况,承包商有义务提供替代品牌/型号(需性能不低于原要求)的选项供发包人选择,若发包人同意变更,则按变更处理,价差按实结算;若发包人坚持原品牌型号,则合理延误由发包人承担。这样至少在客观困难情况下有一个可实操的路径,也尽量避免了关于是否可直接适用严苛的“不可抗力”或“情势变更”法律原则,而带来的争议讨论,进而影响项目进程。
(三)关注设备迭代和性能保障
算力中心该类项目总承包合同的技术条款是其灵魂所在,超越传统数据中心对空间、电力和制冷的简单要求,而强调保障算力输出能力、能效与可靠性。通常律师在技术条款层面不会发表具体细节修订意见,但就原则方向上会提供备注意见或基于发包人需求的条款描述供参考,例如:
1、供电与散热的风险分配建议
实践中,可能会因设计冗余不足或设备选型不当,在部分负载时运行正常,但在满载或局部热点情况下出现供电跳闸或过热降频。发包人主张设计缺陷,承包商则辩称发包人后期IT设备布局超出设计密度。对此建议,合同应极其详细地规定“设计负载”的定义,包括但不限于:单机柜最大功率密度(kW/柜)、机房区域最大平均功率密度、IT设备负载的功率因数特性等。同时,约定承包商有义务在设计中考虑一定的未来扩展余量,并将此作为设计评审的强制性要求。
另外, EPC合同通常将设计、设备质量、施工工艺导致的供电散热故障风险完全分配给承包商 ,但对于外部电网波动、极端气候等超出承包商合理控制范围的风险,可设定免责或共担机制。例如,约定因公共电网质量导致的设备损坏,若承包商已按规范安装保护装置,则可免除其责任。
2、技术与设备迭代的风险分配建议
AI与计算技术迭代迅猛,GPU等核心硬件性能每年大幅提升,价格也可能快速变化 。从项目设计到硬件采购、安装上电,存在明显的时间差,可能导致项目竣工时,部分设备已非市场最新型号,面临“技术性贬值”风险。对此建议, 在基础设计阶段,确定设备的技术规格、品牌短名单和核心性能指标,而非具体型号。允许承包商在采购时,在符合技术规格和品牌要求的前提下,选用届时市场上更具性价比或性能更优的同代或新一代产品。但此选择需经发包人书面批准。
另外,从成本管控角度,建议也可以针对迭代较快且预测价格会下行的设备设置动态条款,例如某项目竣工结算时,市场主流GPU的价格,相比签约时下降30%,发包人认为项目总价虚高,承包商利用信息不对称获利,同理,某设备因全球政治环境影响等因素导致的价格上涨或进口限制,发包人也又不同意调价或更换。在此情况下,条款设计上可通过约定明确上述市场浮动机制和价格调整公式,将硬件成本与公开市场价格指数或供应商官方价格挂钩,实现风险共担,对于建设周期长的情况下迭代快的设备,尽量避免采用完全型号及固定单价,可以优化成本控制及尽量避免结算争议。
(四)竣工验收节点挂钩因素多:建议以性能测试为核心
如前所述,传统建筑工程的“形象进度验收”和“资料核查”在算力中心项目中是远不够的,算力中心该类项目竣工交付的重点除了土建验收合格之外,性能是否达标非常重要,而性能测试的条件、方法、标准、持续时间是最大的争议点。例如近年来,PUE已成为数据中心行业的一项强制性合规指标,如果实测PUE值未能达到节能审查批复中承诺的指标,项目将无法通过节能验收,从而无法合法地投入正式商业运营。节能主管部门可能责令其限期整改,整改期间可能面临高额的惩罚性电价。在极端情况下,如果持续不达标,项目可能面临被关停的风险。因此,PUE不仅是技术指标,更是决定项目生死的法律合规红线。该类争议有时会在探讨PUE测试应该在什么季节、何种负载率下进行?算力性能测试是用标准软件还是模拟实际应用?
1、条款设计建议
如前述分析,笔者在条款设计层面建议:(1)建立分阶段、多层次的验收体系,以性能验收测试为最终验收合格前提的“大考”;(2)明确关键性能指标(KPI)的量化与测试方案,技术层面可明确《性能验收测试方案》将其作为合同附件,例如明确PUE测试目标值、测算周期、测算方式以及标定所有电量计的安装位置和精度要求等。除PUE外,发包人有其他性能验收要求,也可以进一步明确;(3)就测试未通过的法律后果上,可约定整改与重测,要求承包人有义务在规定时间内免费进行整改,并承担重测费用,同时约定性能违约金条款及与工期延误责任条款相衔接。该类条款设计有点类似于部分项目,既会约定五方联验备案迟延的违约金,也会约定违反交付验收标准迟延的违约金,对此可能有人会提出是否存在重复约定及违约金过高的质疑,但是笔者认为算力中心项目其实涉及后续运营环节及用电多方面因素,一旦验收迟延或性能不达标,影响及造成可能损失相对更大,故建议该类违约责任可以从严。
2、延误责任的分摊及整体风控逻辑建议
笔者认为,算力中心该类项目的平稳运作,配套设施及用电保障非常重要。在满足性能交付要求的前提下,最终交付运营的工期会与配套设施建设进度、政府审批进度等多项因素衔接挂钩。竣工验收标准、工程接口以及延期责任条款需在总承包合同、供电协议、配电设施建设合同(如有)等关联合同中明确,建议可对于延误责任进行关联挂钩,对于一方延误所导致的连锁后果,各套合同之间明确“谁延误,谁承担责任”的约定标准,进行整体合同管理风控,进而分摊延误责任风险,同时也为可能的延误损失举证做好前期准备。故,在项目前期设计阶段就可将关键建设节点统筹安排,并对工期延误、用电未达预期、供电迟延等各种情形下的责任承担机制,包括损失安排及违约金计算方式等,在各项关联协议中予以约定。
(五)关于“甲指分包”的风控
首先,分包甲指在我国合规层面是禁止的,甲方对于质量相关问题也会承担相应过错责任,但是在实践中,发包人(甲方)出于对核心技术(如特定品牌的AI芯片服务器、先进的液冷解决方案)的掌控、与战略供应商的合作延续,或利用自身议价能力降低采购成本等目的,往往会在EPC合同中指定部分关键设备供应商或专业工程分包商,即“甲指分包”。这种做法在算力中心项目中尤为普遍,因为它触及了项目中最核心、价值最高的算力硬件、软件服务和关键配套系统。在通常不会影响合同效力的情况下,很多发包人作为甲方仍旧存在指定的倾向,也接纳其存在的风险。在此情况下,从商务逻辑考虑,更多是需要尽量减少合规风险及保障支付路径。
1、存在本土化及基于管理需求个性化的必要
甲指分包模式将算力中心EPC项目置于一个法律责任模糊、管理权限交错的复杂境地。若无清晰、周密的合同约定,它将成为项目成功的巨大隐患。国际通行的FIDIC合同条件(如1999版银皮书)中存在“指定分包商”(Nominated Subcontractor)的制度,明确允许发包人指定分包商 。但FIDIC合同体系下,通常会配套授予总承包商对指定分包商的“合理反对权”,并对付款、工期延长等方面提供相应的保护机制,形成了一套相对成熟的权利义务平衡规则 。相比之下,国内EPC项目合同往往缺乏这种精细化的制度设计。总承包商在面对甲指分包时,常常处于被动地位,合同权利保护不足 。因此,在借鉴国际惯例以及进行条款架构设计时,我们也会充分了解委托人的实践需求,结合中国法律背景进行本土化的改造和完善。
2、条款架构设计建议
(1)总体框架与合同结构设计
建议尽量避免签订由发包人、总承包商、甲指分包商共同签署的“三方协议”。三方协议会直接建立发包人与甲指分包商之间的法律关系,可能进一步架空总承包商,并使法律关系更加混乱,例如实质关系穿透等,导致减免了总包管理义务。坚持“总包-分包”合同,即由总承包商与甲指分包商签订正式、完整的分包合同,这是总承包商行使管理权、追究其违约责任的法律基础。另外,如果总承包方从自身风险角度考虑,想要明确甲指的痕迹,则可以通过指定分包通知书或三方备忘录的形式进行明确,明确三方沟通机制,但非创设新的权利义务。
(2)关于责任划分及风险分配设计
站在发包人角度,建议首先明确总承包商的“管理与协调”责任条款,条款应明确对于甲指分包工程,总承包商的责任是基于其作为总承包商的地位,对甲指分包商进行“合理的、审慎的、专业的管理与协调”,而非完全不予承担甲指分包行为或其产品的管理责任,且其管理义务的费用建议包干处理。
同时,站在总承包商角度,如果能够去争取,也可以进一步明确,不对甲指分包商自身行为或其产品固有缺陷导致的责任负责,例如约定“如总承包商已履行上述审慎的管理与协调义务,则对于因指定分包商自身的设计错误、产品缺陷、履约迟延或任何其他违约行为造成的工程质量问题、工期延误或发包人损失,总承包商不承担责任”。
至于能否争取到总承包商的合理反对权进行条款约定,站在总承包方角度当然是更好,例如约定“发包人发出指定分包商的指令后,总承包商应在【】天内进行审查。总承包商有权基于以下理由,以书面形式向发包人提出合理反对:(a)有充分证据表明该指定分包商财务状况不佳、商业信誉不良或有重大不良履约记录;(b)该指定分包商的技术能力、生产能力或质量保证体系无法满足本项目的特殊要求;(c)该指定分包商拒绝或无法与总承包商就符合EPC合同原则的分包合同条款(包括但不限于责任、保险、付款、质保等)达成一致。若总承包商提出合理反对,发包人应撤销该项指定,并另行指定或与总承包商协商解决方案。若发包人坚持使用该指定分包商,则应向总承包商出具书面免责函,承担该分包商履约所产生的一切风险和责任。”
(3)对于指定分包支付路径的保障
从“三流一致”等合规角度考虑,我们是建议涉及分包款项应由总包支付,但很多甲方会担心总包收到款项后进行挪用,不予向其指定分包方支付。故对于支付路径保障方面, 也可以进行条款设计,例如约定“承包方应按分包合同约定按时足额将分包工程的预付款、形象进度款及工程结算款等款项拨付分包人,并将付款凭证作为承包人申请下一笔款项的附件一并上报。如发包人接到分包人投诉承包人未按时、足额支付分包款项且发包人核实属实的,自分包人向发包人投诉之日起,每天承包人按未支付款项的万分之四向发包人支付违约金,同时发包人有权采取以下措施:……”。
(六)其他
本章节主要是笔者基于算力中心该类项目角度考虑,对于建议需要关注的重点条款设计进行的分析例举,至于其他常规涉及工程总承包的变更条款、质量、安全、结算、违约责任、争议解决等同样重要的条款,限于篇幅也在此不予一一赘述。
五、结语
起草一份优秀的算力中心EPC工程总承包合同,本质上是完成一次精密的风险规划与分配。结合2026年的行业实践与法律环境,核心原则建议如下:
1、从“交钥匙”到“交算力”转变。合同所有条款必须服务于最终交付可验证、可运营的算力服务能力这一核心目标。性能指标、验收测试和违约责任是达成此目标的三大支柱。
2、风险与收益对等。将价格波动、供应链风险、技术迭代等现代算力项目特有的风险,通过动态调整机制(如价格联动、设备选型浮动)在双方间进行合理、透明的分配,避免将过多风险不合理地压给一方,导致合同基础失衡。
3、条款的明确性与可操作性。避免使用模糊语言。所有技术标准、测试流程、计算公式、时间期限都应尽可能量化、具体、可执行。争议往往源于模糊地带。
4、 过程管理与结果导向并重。合同不仅规定最终结果,也要设计良好的过程管理机制,如分阶段评审、里程碑付款、变更管理流程、及时通知义务等,以便在问题出现早期即能发现和纠偏。
5、引入专业第三方力量。在文本架构与细节商议起草、技术参数设定明确等环节,引入专业律所、咨询机构等第三方专业机构,以达到在项目启动前尽量明确细节,也使得在合同履行中避免陷入无依据处理的争议僵局。
综上,本章节对于关键条款设计与争议预判,旨在为算力中心项目的参与方提供一个坚实的合同基础。在数字经济高速发展的今天,一份前瞻、公平、严谨的工程总承包合同,不仅是项目成功的法律保障,更是发包人与承包商建立长期信任、合作共赢的基石。随着技术与法律的不断演进,合同条款也需持续更新,以应对未来新的挑战。




