Android的瘦LTO构建绝非传统编译优化的简单升级，而是通过对符号依赖的精准画像与模块关联的动态重构，在保留代码逻辑完整性的前提下，实现编译产物的结构化精简—它不再对全量代码进行无差别优化，而是聚焦启动阶段的核心执行路径，筛选出必须即时加载的关键符号与依赖单元，剥离非必要的冗余代码与关联引用，让应用启动时的代码加载体积与解析耗时实现双重压缩。而Swift重写Apple集成层的核心价值，在于用原生语言的语义特性替代跨语言适配的中间桥接链路，让集成层与Apple系统底层API形成直接的能力对接，消除启动过程中因语言转换、接口适配带来的延迟损耗。这两项技术的联动优化，并非单端独立的性能修补，而是跨平台架构下编译逻辑与集成层设计的深度协同—Android端通过瘦LTO优化启动时的代码加载效率，减少CPU在初始化阶段的计算压力；Apple端借助Swift的运行时优势压缩集成层的初始化链路，降低内存分配与系统调用的延迟，双端形成互补的优化闭环，从编译产物到运行时执行的全流程破解启动性能与跨平台兼容性的核心矛盾。这种优化思路跳出了“单点调优”的传统框架，聚焦跨端启动的本质痛点，通过编译层与集成层的双向革新，让启动性能的提升具备可复制的方法论与规模化落地的可能，为复杂跨平台应用的性能升级提供了全新的技术路径。

瘦LTO构建的核心竞争力，在于其对编译优化的精准化与高效化革新，它摒弃了全量LTO模式下资源密集型的全局优化逻辑，转而采用分层处理与关键路径聚焦的优化策略，在保证启动性能提升的同时，规避了全量优化带来的编译周期延长问题。在实际优化实践中，瘦LTO的落地需要先完成启动链路的全景解构—通过对应用启动流程的逐环节分析，明确初始化阶段必须加载的核心模块、服务依赖与调用关系，建立启动关键路径的可视化图谱。在此基础上，针对性配置瘦LTO的优化粒度：对于启动时即时初始化的核心服务，如基础配置加载、权限校验、核心功能初始化等模块，进行深度优化处理，包括合并重复调用逻辑、消除无效依赖引用、优化函数执行链路，让代码执行更紧凑高效；对于启动后才按需加载的功能模块，如非核心业务组件、设置页面、辅助工具等，则保持基础编译状态，仅进行必要的符号精简，避免过度优化带来的资源消耗。这种差异化优化策略，既确保了启动关键路径的加载效率，又控制了整体编译开销。在复杂应用场景中，瘦LTO还能与编译缓存机制形成高效协同—通过缓存优化后的中间产物，在后续迭代构建中仅对变更模块进行增量优化，大幅缩短编译周期，同时确保每次构建的优化效果一致性，让启动性能的提升具备稳定可复现的特性。这种精准化的编译优化思路，打破了“优化效果与编译效率不可兼得”的固有认知，实现了编译产物精简、加载效率提升、编译周期可控的三重增益，成为Android端启动性能优化的核心支撑。

Swift重写Apple集成层的优化逻辑，本质是通过语言原生特性与系统生态的深度耦合，重构跨平台能力的适配链路，彻底替代传统依赖中间桥接层的实现模式，从根源上消除跨语言适配带来的启动损耗。传统跨平台应用的Apple集成层，往往为了兼容多语言调用逻辑，引入大量的接口转换代码、数据格式适配模块与中间调度层，这些冗余链路在启动阶段会产生显著的性能开销—数据在不同语言类型间的转换消耗内存与CPU资源，中间层的调度延迟拉长了初始化周期，同时增加了系统调用的不确定性。Swift作为Apple生态的原生语言，具备与系统底层API的天然适配优势，能够直接调用核心系统能力，省去中间转换环节，让集成层的初始化逻辑更贴合系统的运行时调度机制，实现更高效的能力衔接。实践过程中，重写工作需聚焦两个核心维度：一是集成层的语义对齐，在保持跨平台核心能力一致性的前提下，用Swift的原生语法重构适配逻辑，最大化利用语言的内存管理特性—例如通过值类型优化减少启动时的内存分配与释放操作，避免引用计数带来的额外开销；利用函数派发优化提升调用效率，让核心接口的响应速度更快捷。二是初始化流程的拆分与延迟加载，将集成层的功能模块按启动优先级进行划分，仅保留核心能力的即时初始化，如基础配置适配、系统权限对接等必须在启动阶段完成的逻辑，而将非核心的适配功能，如统计上报、第三方服务对接等，通过懒加载机制延迟到启动完成后执行，进一步压缩启动耗时。这种原生适配的思路，让集成层从启动流程中的“阻滞点”转变为“助推器”，在保证跨平台兼容性的同时，实现了启动性能的质的飞跃。

Android瘦LTO构建与Swift重写Apple集成层的协同优化，核心在于构建覆盖跨端启动全流程的性能优化闭环，让双端的优化策略形成互补效应，而非孤立的单端升级。Android端通过瘦LTO构建，削减了启动时的代码加载体积与解析耗时，减少了CPU在初始化阶段的计算压力，让核心服务能够更快完成启动准备；Apple端借助Swift重写的集成层，压缩了跨语言适配的中间链路，优化了内存分配效率与系统调用延迟，让集成层的初始化更高效。这种双端协同并非简单的功能叠加，而是基于跨平台应用启动共性逻辑的深度适配—无论是Android的代码加载流程，还是Apple的集成层初始化链路，本质上都是对启动资源的调度与利用，两项技术分别从编译端与运行端切入，形成覆盖“编译产物优化-代码加载加速-集成层初始化精简-系统能力对接高效”的全流程优化体系。实践中，协同优化的落地需要先统一双端的启动性能优化目标，明确核心指标的基准线，例如启动完成时间、初始化阶段的CPU占用、内存峰值等，再根据双端的技术特性制定差异化的优化策略：Android端侧重通过瘦LTO实现编译产物的精简化，缩短代码加载与解析路径，同时优化启动时的资源调度优先级；Apple端聚焦通过Swift的原生优势压缩集成层的初始化链路，减少中间环节的性能损耗，提升系统API的调用效率。通过这种协同设计，跨平台应用能够在双端同时获得启动性能的跃升，避免单端优化导致的用户体验失衡，让不同设备上的启动流程都能保持流畅高效，真正实现跨端启动体验的一致性与高性能。

启动性能的深度优化，离不开对技术细节的精准把控与场景化的动态适配，瘦LTO构建与Swift重写的落地过程，并非一成不变的标准化流程，而是需要根据应用的实际场景与架构特点进行灵活调整。对于瘦LTO构建而言，优化粒度的选择是关键—过粗的优化会导致启动关键路径的优化不充分，无法达到预期的性能提升效果；过细的优化则可能引入不必要的编译开销，延长构建周期，甚至影响代码的稳定性。因此，在实际操作中，需要借助启动链路分析工具，精准定位每个模块在启动阶段的加载耗时、依赖关系与资源占用情况，建立模块级别的性能画像，再针对性配置优化范围：对启动时首先加载的核心框架，如基础库、路由管理、核心服务等，进行最大程度的优化，合并重复符号，消除循环依赖，优化函数执行逻辑；对后续按需加载的功能模块，如非核心业务组件、多媒体处理、扩展功能等，则采用轻量级优化策略，仅保留必要的符号与依赖，避免过度优化带来的资源消耗。在Swift重写集成层的过程中，集成层的拆分逻辑同样需要贴合应用的启动流程，将必须在启动阶段完成的适配逻辑，如基础配置同步、系统权限申请、核心能力对接等，与可延迟的功能解耦，通过懒加载机制将非必要的适配逻辑延迟到启动完成后执行。同时，需充分利用Swift的编译优化特性，如模块间的接口精简、无用代码自动剔除、编译期常量折叠等，让集成层的产物体积更小巧，加载更快速。这种场景化的精准优化，避免了“一刀切”的优化模式带来的局限性，让每项技术的优势都能在关键场景中充分发挥，实现启动性能的最大化提升，体现了技术优化从“广谱适配”到“精准赋能”的进阶思维。

瘦LTO构建与Swift重写Apple集成层的优化实践，其长远价值远不止于启动性能的即时提升，更在于为跨平台应用构建了可扩展、可迭代的性能优化体系与技术底座。瘦LTO带来的编译链路优化思路，不仅适用于启动性能的提升，还能延伸到应用运行时的内存占用控制、CPU效率优化与功耗降低—通过持续优化编译产物的结构，让代码执行更高效，资源利用更合理，为应用全生命周期的性能表现奠定坚实基础。而Swift重写的集成层，凭借语言的原生优势与系统兼容性，大幅降低了后续功能迭代的适配成本与维护难度——Swift与Apple系统的深度耦合，让集成层能够快速响应系统版本的更新与API的迭代，无需频繁进行跨语言适配调整；同时，原生代码的可读性与可维护性更强，减少了后续迭代中的技术债务。

URP以轻量化、跨平台为核心诉求，在资源调度上追求极致精简，适配移动端、主机等多终端的硬件限制；而HDRP则聚焦高清渲染，在光照计算、材质表现上堆砌复杂逻辑，专为高端PC与次世代主机打造。这种定位差异导致两条管线在核心架构、资源管理、效果实现上形成难以逾越的壁垒，开发者往往需要为不同管线单独构建内容、适配逻辑，既增加了开发成本，也让跨平台体验的一致性大打折扣。共享Render Graph与统一光线追踪API的出现，并非简单的功能叠加或参数调优，而是对渲染逻辑的深层重构，其核心在于构建一套脱离管线专属限制的通用渲染语言。这种语言让HDRP的高品质光照计算不再依赖专属的管线架构，而是能通过Render Graph的资源适配与调度优化，以符合URP性能基线的方式落地；同时，URP的跨平台灵活性也不再局限于基础渲染能力，而是能通过统一光线追踪API，承载HDRP级别的复杂场景光照交互。在长期的技术探索中发现，管线间的差距本质上是资源管理逻辑与效果计算范式的割裂—URP为追求效率简化了资源依赖解析，HDRP为实现品质强化了专属计算模块，而共享Render Graph通过对渲染流程的节点化抽象，将资源分配、Pass调度、依赖解析等核心逻辑抽离为独立层，让两条管线能基于同一套底层规则管理资源；统一光线追踪API则打破了光照计算的管线专属限制，让实时光线追踪从HDRP的“高端配置”转变为可根据硬件能力动态适配的“通用功能”。这种转变要求开发者跳出“为URP添加高清功能”或“为HDRP做性能裁剪”的传统思维，转而从渲染本质出发，让两条管线基于同一套核心逻辑，按需组合渲染模块，实现从移动端到高端PC的无缝能力伸缩，最终达成“性能与品质并行不悖”的渲染目标。

共享Render Graph的核心价值，在于构建了一套标准化的渲染资源语义映射体系，让URP与HDRP能精准理解彼此的资源描述规则，从而实现跨管线的资源复用与流程互通，彻底改变了传统管线中资源壁垒林立的局面。在传统开发模式中，URP为适配移动端硬件，采用紧凑的纹理压缩格式与精简的缓冲布局，而HDRP为追求高清表现，使用高精度纹理与复杂的缓冲结构，这种差异导致同一材质资源在两条管线中需要重复构建适配逻辑，不仅增加了开发工作量，还容易出现资源不一致的问题。共享Render Graph通过抽象资源的核心属性描述与使用场景，将资源的具体实现细节与上层渲染逻辑解耦—无论管线对资源的精度要求、压缩格式有何差异，都能通过统一的资源接口进行调用，Render Graph则在底层自动完成适配转换。例如，在处理复杂场景的多Pass渲染时，HDRP为实现全局光照计算生成的高精度光照贴图，可通过Render Graph的资源适配层，自动转换为URP可高效采样的压缩格式，无需额外添加格式转换Pass，既减少了性能开销，又保证了光照效果的一致性；同样，URP针对移动端优化的纹理流式加载逻辑，也能被HDRP复用，在高清场景中根据硬件内存情况动态加载纹理资源，有效降低内存占用压力。更重要的是，Render Graph的节点化架构让渲染流程具备了模块化重组能力，HDRP中包含的环境光遮蔽、屏幕空间反射、体积雾等复杂后处理链路，可拆分为独立的功能节点，URP可根据自身性能预算，选择性启用核心节点，省略高精度计算步骤，无需重新设计整套后处理管线。这种模块化复用不仅大幅降低了两条管线的功能差距，还提升了开发效率—开发者只需维护一套核心渲染流程节点，即可通过Render Graph的适配逻辑，自动适配两条管线的性能与品质需求，让URP的渲染效果向HDRP靠拢，同时保持自身轻量化的核心优势。在实际技术探索中还发现，Render Graph的资源依赖解析能力，能有效解决跨管线渲染中的资源冲突问题，例如当两条管线同时调用同一材质资源时，Render Graph会根据当前管线的渲染上下文，自动分配对应的资源实例，避免出现资源竞争或格式不兼容的情况，进一步强化了管线间的协同能力。

统一光线追踪API的关键突破，在于实现了光照计算的范式归一，让URP与HDRP能基于同一套光线行为描述逻辑，达成光照效果的一致性与性能的差异化适配，彻底改变了此前两条管线光照表现泾渭分明的局面。在此之前，HDRP的光线追踪依赖专属的光照计算管线，支持复杂的光线反弹、材质交互与全局光照采样，能呈现出逼真的阴影、反射与折射效果，但计算开销巨大，仅能在高端硬件上运行；而URP受限于性能预算，无法承载完整的光线追踪计算，仅能通过屏幕空间近似算法模拟简单光照效果，导致两条管线的光照表现存在本质差距，同一场景在不同管线中呈现出截然不同的视觉质感。统一光线追踪API通过抽象光线的发射、相交、着色等核心行为，构建了一套与管线无关的光照计算模型，让光线追踪的核心逻辑脱离管线专属实现，成为一套可灵活适配的通用能力。在实际应用中，这套API会根据管线的性能目标与硬件能力，动态调整计算精度与采样策略：在HDRP中，光线可支持多轮反弹与复杂材质采样，充分发挥高端PC与次世代主机的计算潜能，呈现出电影级的光照质感；在URP中，则通过一系列智能化优化—如光线采样策略动态调整，优先采样对视觉影响显著的区域；反弹次数自适应控制，根据场景复杂度与硬件性能动态调整反弹轮次；加速结构简化，采用更紧凑的空间划分算法—在保证光照效果合理性的前提下，将计算开销控制在移动端与中端PC可承受的范围。这种适配并非简单的参数削减，而是基于硬件能力的智能决策，例如在移动设备上，API会自动将全局光线追踪转为局部关键区域的光线查询，结合屏幕空间信息补全光照细节，让URP的光照表现既符合性能要求，又能无限接近HDRP的视觉质感；在中端PC上，则可启用有限次数的光线反弹，平衡效果与性能。此外，统一API还实现了光照数据的跨管线互通，HDRP中烘焙的光线追踪加速结构，可通过API的适配层转换为URP可高效使用的简化版本，减少重复计算开销，让两条管线在光照计算上实现能力同源，进一步缩小了视觉差距。

场景描述体系的统一，是缩小URP与HDRP差距的重要支撑，共享Render Graph与统一光线追踪API共同构建了一套可跨管线解析的场景语义规范，让复杂场景的描述不再依赖特定管线的专属逻辑，实现了场景资源的一次创建、多管线复用。在传统开发流程中，HDRP的复杂场景通常包含大量高精度几何信息、分层材质属性与全局光照参数，这些信息往往针对HDRP的渲染架构进行优化，无法直接被URP解析，导致同一场景在两条管线中需要重新配置—URP需简化几何模型、削减材质层数、调整光照参数，不仅耗时耗力，还容易导致场景效果失真；而共享Render Graph通过对场景元素的结构化描述，将几何数据、材质属性、光照信息等拆分为独立的语义单元，每条管线可根据自身能力解析对应的语义层级，无需对场景资源进行破坏性修改。例如，HDRP中使用的多层材质，包含基础颜色、粗糙度、金属度、次表面散射等多个属性层，在URP中，Render Graph会通过语义适配，自动提取基础颜色、粗糙度等核心属性，忽略次表面散射等高精度细节，同时保留材质的核心视觉特征，让材质在URP中既符合性能要求，又能保持与HDRP一致的视觉风格；而URP中的简化几何模型，在HDRP中可通过API自动补充细节层次，如添加高模细节贴图、启用几何细分，满足高清渲染需求。统一光线追踪API则进一步强化了场景的光照交互一致性，无论是URP的轻量化场景还是HDRP的高精度场景，光线与物体的相交判定、材质反射计算都遵循同一套语义规则，确保在不同管线中，光照对场景氛围的影响保持一致—例如同一光源照射下，物体的阴影形状、反射强度、颜色衰减在两条管线中呈现出高度统一的效果，避免了跨管线体验的割裂感。这种场景语义的统一，让开发者无需为两条管线单独构建场景资源，只需维护一套核心场景描述，Render Graph与光线追踪API会自动完成适配转换，大幅降低了跨管线开发的复杂度；同时，场景资源的复用也让URP的场景表现力得到显著提升，原本只能在HDRP中呈现的复杂场景细节，如今可通过语义适配在URP中高效呈现，进一步缩小了两条管线的视觉差距。

着色器生态的协同演进，是弥合URP与HDRP差距的关键环节，共享Render Graph与统一光线追踪API为两条管线提供了可互通的着色器开发框架，让高品质着色逻辑能在两条管线中高效复用，彻底改变了此前着色器开发“管线专属”的局面。在此之前，HDRP的着色器支持复杂的次表面散射、屏幕空间反射、多层材质混合等高级效果，这些效果的实现依赖HDRP专属的光照计算管线与资源调度逻辑；而URP的着色器受限于性能预算，往往只能实现基础的PBR光照计算，导致同一材质在两条管线中视觉差异显著—HDRP中材质表现细腻、光影过渡自然，而URP中材质效果单薄、细节缺失，严重影响了跨管线体验的一致性。共享Render Graph通过模块化着色器设计，将着色逻辑拆分为独立的功能单元，每个单元可根据管线的性能与画质需求，动态调整计算复杂度，实现“一套逻辑、多端适配”。例如，HDRP中使用的PBR着色逻辑，可拆分为基础光照计算、高级材质交互、全局光照融合等模块：在HDRP中，可启用全部模块，实现复杂的材质表现；在URP中，则可选择性启用基础光照计算模块，同时通过统一光线追踪API补充关键光照细节（如高精度反射、软阴影），让URP的PBR表现兼具性能与质感，与HDRP的视觉差异大幅缩小；而HDRP也可复用URP中针对移动端优化的纹理采样模块，通过更高效的采样算法提升高清场景的纹理加载效率，减少性能开销。这种模块化设计不仅实现了着色逻辑的跨管线复用，更让着色器的扩展能力大幅提升—新的着色效果只需开发一次，即可通过Render Graph的适配层自动适配两条管线的渲染架构，无需针对每条管线重复开发。在实际技术实践中发现，这种着色器生态的协同，让URP的材质表现力得到了质的飞跃：原本只能在HDRP中实现的复杂材质交互，如布料的漫反射衰减、金属的镜面反射变化，如今可通过统一API与模块化着色逻辑，在URP中以适配性能的方式呈现；同时，HDRP的着色器也因复用了URP的优化模块，在保持高品质的同时，资源占用与计算开销显著降低，实现了“品质不打折、性能更出色”的目标。

技术融合的深层价值，在于构建了渲染管线的弹性演进体系，让URP与HDRP不再是相互割裂、各自为战的发展路线，而是基于同一技术底座的差异化表达，实现了两条管线的双向赋能与协同升级。在这套体系下，两条管线的核心能力不再局限于初始定位，而是能随着底层技术的迭代同步升级：URP能持续吸收HDRP的高品质渲染技术，通过Render Graph的资源优化与统一API的性能适配，将其转化为自身的轻量化实现，不断提升跨平台场景的视觉表现力；而HDRP也能借鉴URP的跨平台优化经验，将移动端的高效资源调度、轻量化计算逻辑迁移过来，提升高清场景的资源利用效率与硬件适配范围。

过去两年，能源矿产行业，正在从一个“以规模和资源驱动”为主的行业，进入一个以复杂运行与系统治理为核心约束的新阶段。一方面，全球能源博弈加剧、关键矿产战略属性抬升，安全、稳定与可控成为底线要求；另一方面，绿色低碳、双碳约束、成本透明化，正在把过去“被吸收”的不确定性，逐步转化为显性经营压力。与此同时，AI 对算力与能源的需求反向放大了能源系统的战略地位，使能源矿产不再只是“上游产业”，而是全球产业体系中的基础能力提供者。

这三股力量叠加，带来的并不是简单的业务增长或下行，而是一种更根本的变化：企业运行本身，正在变得前所未有地复杂。复杂性不再来自“业务更多”，而来自“变量更多、耦合更强”。

正是在这一判断之下，这本《能源矿产行业 Data+AI 数智化转型白皮书》试图回到一个更基础的问题：能源矿产企业，究竟需要怎样一套面向未来十年的数智化体系？

产业链拆解：矿山、冶炼、加工、集团企业，各有各的“卡点”从产业链整体看，能源矿产行业正同时承受来自安全、成本、效率与治理复杂度的多重压力，但不同环节的问题形态并不相同。矿山企业长期处在高风险、高耦合的运行环境中，生产、安全与成本高度依赖现场经验进行平衡判断，虽然系统与数据不断增加，但信息分散在采掘、通风、运输、安全监测等多个专业系统中，难以形成连续、稳定的运行态势认知，一旦出现异常，管理动作往往发生在结果之后，风险演化过程缺乏提前感知能力。

进入冶炼环节，问题逐步从“能不能稳住生产”转向“利润结构是否可被解释”，能耗、原料、工艺路线、排产节奏相互影响，加工费、能源价格与碳成本波动频繁，财务结果可以核算清楚，但利润变化背后的驱动因素难以被拆解，生产侧与经营侧之间长期缺乏贯通分析视角。

加工企业表面上资产更轻、流程更灵活，但项目数量多、订单碎片化、区域分散，使成本、进度、交付与质量高度交织，管理层往往只能看到阶段性结果，对项目运行节奏与关键偏差缺乏整体把控能力。

到了集团层面，上述问题进一步叠加放大，数据持续上行但语义口径不统一，指标体系不断扩充却难以横向对比、纵向追溯，分析结果更多停留在展示层面，难以真正嵌入资源配置、考核机制与管理动作之中。这种状态下，企业对外部不确定性的感知能力持续增强，对内部运行复杂性的掌控能力却并未同步提升，成为当前能源矿产行业普遍面临的系统性挑战。

统一底层逻辑：一体两翼架构如何支撑能源矿产企业数智化转型在具体展开矿山、冶炼、加工与集团四类企业实践之前，有必要先回答一个更基础的问题：这些看似差异巨大的场景，是否存在一套可复用的数智化底层逻辑？

从大量项目实践来看，答案是肯定的。能源矿产行业面临的问题虽然分布在不同环节，但在数据形态、管理诉求与运行机制上，呈现出高度一致的结构特征——数据来源复杂、业务耦合度高、风险容忍度低、管理链条长。这决定了数智化建设需要一套能够长期运行、持续演进的通用架构作为基础。

一体两翼方案架构基于这一认识，白皮书提出了“一体两翼”的整体方案框架。“一体”指向统一的数据底座，核心目标是解决数据在跨系统、跨层级、跨业务域流动过程中的可解释性问题。通过多模态数据智能中台与治理体系建设，将组织、资产、项目、装置、人员、合同、物料等关键对象纳入统一的数据模型与语义体系，明确主数据口径、指标计算逻辑与责任归属，使不同系统产生的数据能够在同一语境下被理解、被对比、被追溯。这一层解决的是“数据能不能支撑管理”的问题，是所有后续分析与应用的前提。

在统一数据底座之上，“两翼”分别对应数据智能能力与空间智能能力。数据智能侧重于把治理后的数据转化为可用的分析与判断能力，包括主题域分析、指标体系运行、异常识别、趋势判断以及智能问数与辅助分析等能力形态，其价值在于降低分析门槛、提升判断效率，使管理层能够从数据中快速获得“发生了什么、为什么发生、接下来可能会怎样”的连续认知。

空间智能则承担另一类关键任务——将复杂业务运行状态放入空间语境中表达，通过数字孪生把生产现场、工程项目、管网资产、园区设施等实体对象转化为可感知、可联动、可推演的运行载体，让风险、进度、资源与规则以更直观的方式支撑监管、指挥与协同。

图：车辆及驾驶员精准定位及状态监控

“一体两翼”框架并不追求一次性覆盖所有场景，而是为不同类型企业提供了一套可按需展开的通用底盘。矿山企业更多把能力落在空间智能与实时监管上，解决高风险场景下的运行感知与风险前移；冶炼企业重点强化数据治理与主题域分析，打通生产、能耗与经营之间的分析链路；加工与工程型企业围绕项目主线展开数据中台与经营分析，提升对经营节奏与风险暴露的掌控能力；集团企业则在统一底座之上，通过经营分析、统管机制与空间化承载，实现对子公司的可比、可控与可调度管理。差异体现在应用重点，而非底层逻辑本身。

也正因为有这样一套通用方案作为支撑，后续不同企业类型的实践，才能在保持行业差异的同时，呈现出清晰一致的建设路径与演进逻辑。

矿山、冶炼、加工、集团企业的不同落地路径：一体两翼走向行业实践要把矿山、冶炼、加工与集团统管这四类问题真正解决到位，方案需要同时回答三件事：数据怎么汇、口径怎么统一、场景怎么持续运行。

矿山环节优先建设“矿山实景数字孪生实时监管平台”，它的关键在于把巷道/采场/硐室等空间对象变成可承载业务规则的“运行容器”。在平台底座上，矿山空间模型持续随采掘推进更新，人员定位、车辆轨迹、作业票证、岗位资质、环境越限、重点风险源等数据按空间对象绑定与联动，形成“谁在何处、在做什么、是否具备资质、环境是否越限、风险是否可控”的连续态势。

监管能力通过两类机制落地：一类是空间化的风险分级与联动处置，例如越界、越限、禁入、临边与关键设备区的规则触发，自动生成预警清单与处置闭环；另一类是面向应急的路径推演与指挥协同，将人员分布、撤离路线、应急物资点位、救援力量调度纳入同一空间语境，支持从“态势掌握”进入“指挥动作”。这类平台真正解决的是深部开采条件下的“运行可见性”和“风险前移”，让安全管理从事后统计转向过程监管。

图：采矿车辆空间运行状态监控概览

进入冶炼环节，解决方案落点是建设“智慧运行平台”，建设重点围绕数据中台、治理体系与主题域分析同步展开。冶炼业务天然具有强耦合特征：原料结构、工艺参数、能耗水平、产量节奏与质量指标相互牵引，财务结果虽能核算，利润变化的形成过程长期缺少可解释链路。智慧运行平台首先把 DCS/MES/ERP、计量、能源与质量等系统数据纳入统一治理框架，建立主数据（组织、装置、物料、工序、计量点、能源介质等）与指标口径映射关系，确保“同一指标在不同装置、不同基地、不同时间粒度下可对比、可追溯”。在此基础上，以既定的主题域框架沉淀分析体系，将经营、财务、合同、人资、采购、合规等管理视角与生产过程数据打通，形成从“工艺—能耗—成本—利润”的贯通分析路径，使管理动作能够落在可解释的数据链路上：哪里波动、为什么波动、影响到哪个利润环节、该由哪个责任单元承接改进。冶炼方案的价值锚点在于把“算得出结果”升级为“看得见机制”，为排产优化、能效对标、成本拆解与风险预警提供稳定底盘。

图：冶炼行业多模态数据智能中台架构

加工型企业的方案，以全厂级实景建模为基础，构建覆盖厂区、车间与关键装置的数字空间底座，将设备、工艺、人员与环境等要素统一承载，为现场管理与分析提供稳定语境。在此之上，通过人员定位与风险感知能力建设，形成覆盖全厂的实时态势感知，使作业行为、风险区域与异常状态能够被持续识别与管控。围绕运行保障与生产组织，数字孪生进一步用于支撑应急演练、处置推演与跨车间态势协同，帮助管理层在同一视角下理解不同工序与车间的运行关系。随着现场数据持续沉淀，经营分析能力逐步与生产过程耦合，通过将产量、能耗、设备状态与成本、收率等指标关联，管理层能够在空间化视角下理解经营结果的形成路径，实现从结果统计向过程解释的转变，并在指挥大厅与接待场景中形成可操作、可表达的整体能力。

图：企业作战驾驶舱现场实景

集团层面的方案要回答“怎么统管子公司、怎么横向对比、怎么把分析转成抓手”。集团数据中台承担统一标准、统一口径、统一组织维度的工作，把成员企业数据上行与集团管理下行打通；经营分析体系则围绕集团既定主题域框架运行，将财务经营、人力资源、工程运营、客户服务等关键场景沉淀为集团级可对比的管理视图，支撑跨区域、跨业态的态势判断与资源配置。数据门户体系负责把集团分析、预警与任务清单组织成统一入口，形成“会前看态势、会中抓异常、会后盯整改”的运行机制。空间化能力在集团中更多承担“资产与运行态势的承载方式”，将管网、场站、工程项目与重点风险点的空间分布与经营分析结果关联呈现，降低跨层级沟通成本，让集团层的统管动作更容易落到区域与项目公司。

主题域规划

运营平台（原型测试数据）

四类企业的真实落地：一体两翼架构在复杂场景中的实践验证在地下矿山场景中，十五冶的实践验证了数字孪生作为运行级基础能力的价值。通过构建地下矿山实景数字孪生实时监管平台，企业将人员、设备、环境与作业活动统一纳入空间化运行视角，矿山管理从分系统监控转向整体态势感知。安全管理由事后复盘逐步演进为事前预判与过程干预，调度与应急指挥建立在实时状态之上，为深部开采条件下的安全治理与稳定运行提供了可持续支撑。

在工程型、项目型企业场景中，相关实践围绕数据中台重构了经营认知方式。通过以项目为核心对象，贯通合同、预算、采购、结算与财务数据，企业逐步摆脱了阶段性报表驱动的管理模式，建立起对项目收支、成本偏差与风险敞口的连续判断能力。经营管理从“看结果”转向“盯过程”，为项目统筹、资源配置与风险控制提供了更具前瞻性的决策基础。

在铜业加工场景中，实践重点落在生产现场与经营分析的协同。通过全厂级实景建模、人员定位与风险感知能力建设，企业构建了覆盖多车间、多工序的实时运行视角；在此基础上，将产量、能耗、设备状态与关键经营指标关联分析，使管理层能够在空间语境中理解经营结果的形成过程。数字孪生演进为支撑生产协同、应急处置与经营分析的综合载体。

在集团层面，中国燃气的实践展现了数据中台与经营分析在超大规模组织统管中的价值。通过统一数据治理与分析体系，集团将分散在多业态、多区域、多层级的经营与运行数据重新组织，形成可对比、可追溯、可下钻的集团级分析视角。经营、工程、人力与客户服务等关键领域逐步纳入统一认知框架，集团管理由“看得到数据”转向“推得动管理动作”，为规模化发展背景下的稳健运行与治理升级提供支撑。向左滑动查看更多

图：财务经营分析场景建设框架

图：组织绩效分析场景建设框架

图：干部画像分析场景建设框架

图：抄收＆保修场景分析建设框架

图：工程运营场景建设框架

实践共性路径及方法论总结

在矿山、冶炼、加工与集团四类企业的实践中，可以看到一个高度一致的结论：能源矿产行业的数智化挑战，来自业务复杂性、风险密度与治理半径的持续放大。当生产环境高度不确定、经营链条高度耦合、组织层级不断拉长，仅靠零散系统叠加或局部智能化，很难形成稳定、可持续的管理能力。真正起作用的，是一套能够长期运行、持续演进的体系化路径。“一体两翼”的价值，正体现在这种体系能力之上。

一方面，通过统一的数据底座与指标体系，把分散在现场、系统与组织中的信息，转化为可被理解、可被比较、可被追溯的经营与运行认知；

另一方面，通过空间化能力与智能分析能力，将这些认知嵌入到真实业务场景中，服务于安全监管、生产协同、经营分析与集团统筹等关键决策动作。

这使得数智化逐步参与到企业运行方式本身。从地下矿山的实景监管，到冶炼企业对生产—能耗—经营链路的穿透分析；从加工企业在复杂现场中构建整体态势感知，到集团层面对跨区域、跨业态运行与经营的统一统筹，这些实践并未追求“一步到位”的智能化目标，而是围绕各自最核心的业务矛盾，选择合适的切入点持续推进。也正是在这种渐进式、可复用的建设过程中，数智化能力开始真正沉淀为企业的治理能力。这或许是能源矿产行业在不确定性时代的一条现实路径：以能否降低风险暴露、提升经营透明度、增强组织协同为最终检验。Data+AI数智化转型的意义，不在于让企业“看起来更先进”，而在于让企业在复杂环境中运行得更稳、更清楚，也更有韧性。回到这本白皮书所呈现的，不是一套标准答案，而是一组来自真实实践的路径参考。无论是矿山、冶炼、加工企业，还是集团型组织，只有尊重行业特性、正视业务矛盾，在统一底座之上持续积累认知与能力，数智化才可能从“项目建设”走向“长期能力”。在能源博弈加剧、产业周期波动加深的时代背景下，这种能力本身，正逐渐成为企业最重要的竞争壁垒。我们也希望，这些实践与方法，能够为更多行业参与者提供启发——不是为了追逐概念，而是为了在不确定的时代，找到一条更稳健、更可持续的前行路径。

1.需求场景

在智能驾驶等复杂业务场景中，模型往往具备​多任务分支结构​，例如在同一个网络中同时包含​​ BEV 动态任务​（如目标检测、跟踪、运动预测）与​​ BEV 静态任务​（如地图构建、车道线提取、可行驶区域预测），这些任务对推理频率（Frames Per Second， FPS）的要求通常并不相同。也就是有不同任务分支 推理不同帧率的需求，例如 BEV 动态任务 20 帧，静态任务 10 帧这种情况，BEV 模型结构简单示例如下所示。

2.技术分析

以 BEV 动静态任务为例，实现不同任务分支推理不同帧率（动态 20 帧，静态 10 帧），很容易想到两种方案：

​方案 1-​拆分为三个子模型：模型 1-公共部分（backbone+neck）、模型 2-动态 head、模型 3-静态 head

1. 模型 1 推理 20 次，输出分别送给模型 2 推理 20 次，模型 3 推理 10 次。
2. 优点：应用层可灵活调度 3 个子模型的推理；模型 1-公共部分 只需要推理 20 次；
3. 缺点：模型 1-公共部分的输出内存需要额外存储，增加 load/store 带宽消耗；拆分次数多，影响编译时的全图优化，可能会增加 latency；

​方案 2-​拆分为两个子模型：模型 1-公共动态（backbone+neck+ 动态 head）、模型 2-公共静态（backbone+neck+ 静态 head）：

1. 模型 1-公共动态推理 20 次，模型 2-公共静态推理 10 次。
2. 优点：应用层可灵活调度 2 个子模型的推理；只需准备整个模型输入/出内存，无需准备公共部分输出的内存；拆分次数少，编译时可全图优化，减小 latency；
3. 缺点：公共部分（backbone+neck）需要推理 30 次，造成 latency 增加与 BPU 资源浪费；公共部分需要存储两份；

为了兼顾方案 1 与方案 2 的优点，同时实现不同任务分支推理不同帧率，工具链提供了 link 打包功能，具体打包方式如下：

工具链提供的 link 功能，能够 复用 不同 模型/任务 的公共部分 constant 常量（包括权重等），即不会存储多份，在模型加载时，公共部分只会占用一份静态内存，需要注意推理时动态内存不会复用（​作为不同模型处理​），关于内存占用相关介绍可见文章《<u>【地平线 J6 工具链入门教程】板端部署 UCP 使用指南-内存占用</u>》。

上图中将模型 1 与模型 2 link 打包生成的模型 3，相比于模型 1 体积不会大多少，同时具备推理模型 1 与模型 2 的功能。根据需求，调整模型 1 与模型 2 的推理次数，即可实现不同任务采用不同帧率部署。

如下图所示：推理一次模型 1，可实现动态任务 head 与静态任务 head 各推理一次，推理模型 2 可实现仅推理一次动态任务 head，当模型 1 推理 10 次、模型 2 推理 10 次时，即可实现动态推理 20 次，静态推理 10 次的效果。（公共部分 backbone+neck 仅推理 20 次）

3.方案实现

3.1 模型 link 打包

根据需求场景，先将多任务模型拆分导出为不同子任务的 qat.bc，然后分别将他们编译成 hbo 文件，最后将多个 hbo 文件 link 打包为一个 hbm 模型。

在工具链用户手册《<u>HBDK Tool API Reference</u>》章节中详细介绍了 compile 与 link API，可以看到：

• compile 输出同时支持 hbm 与 hbo 两种文件格式，可通过配置文件后缀名为"。hbm" or ".hbo"来区分。
• link 支持将多个 hbo 文件打包生成一个 hbm 文件。

将两个 hbo 文件通过 link 打包生成一个 hbm 模型，示例代码如下：

from horizon_plugin_pytorch.quantization.hbdk4 import export
from hbdk4.compiler import load, convert, compile, link
# export 阶段记得配置 name
qat_bcA = export(qat_model_A, example_input, name="1_backbone_head1_head2")
quantized_modelA = convert(qat_bcA, "nash-m")
# 注意：此时compile生成的模型后缀名为.hbo
hbo_nameA = "nameA_compiled.hbo"
hboA = compile(quantized_modelA, path=hbo_nameA, march="nash-m", opt=2, progress_bar=True, jobs=48)

qat_bcB = export(qat_model_B, example_input, name="2_backbone_head1")
quantized_modelB = convert(qat_bcB, "nash-m")
hbo_nameB = "nameB_compiled.hbo"
hboB = compile(quantized_modelB, path=hbo_nameB, march="nash-m", opt=2, progress_bar=True, jobs=48)

# link生成打包模型，后缀名为.hbm
hbm_name = "compiled.hbm"
hbm = link([hboA, hboB], hbm_name)
# 如果在其他地方已经生成了hbo
# 可以通过 hbo = Hbo(hbo_name) 进行加载 所需头文件： from hbdk4.compiler.hbm import Hbo

3.2 打包模型推理

3.2.1 hrt\_model\_exec 工具推理

通过 hrt_model_exec model_info --model_file compiled.hbm 可查看打包模型的数量，输入输出等信息，示例如下

This model file has 2 model:
[2_backbone_head1]      [1_backbone_head1_head2]
---------------------------------------------------------------------
[model name]: 2_backbone_head1

input[0]:
name: ...

output[0]:
name: ...

---------------------------------------------------------------------

---------------------------------------------------------------------
[model name]: 1_backbone_head1_head2

input[0]:
name: ...

output[0]:
name: ...

output[1]:
name: ...

结合--model\_file 与--model\_name 即可实现对打包 compiled.hbm 模型中的某一个模型进行推理。

以 perf 评测打包 compiled.hbm 模型 中 2\_backbone\_head1 的性能为例，参考命令如下：

hrt_model_exec perf --model_file compiled.hbm --model_name 2_backbone_head1

3.2.2 UCP API 推理

在工具链用户手册《<u>统一计算平台 UCP - 模型推理开发 - 模型推理 API 手册 - 功能接口</u>》中，详细介绍了加载打包模型 hbDNNInitializeFromFiles 与 获取单个模型句柄 hbDNNGetModelHandle 的使用方式，截图如下：

在工具链开发包路径：OE/samples/ucp\_tutorial/dnn/basic\_samples 下方的示例中有用到这两个接口，可参考使用。

3.3 多任务不同帧率推理

根据需求，调整打包模型 compiled.hbm 中的 模型 1 backbone\_head1\_head2 与模型 2 backbone\_head1 的推理次数，即可实现不同任务采用不同帧率部署。

3.4 性能数据示例

下表中，backbone\_head1 是公共部分，​注意​：公共部分权重是一样的

可以看到，compiled.hbm 体积相比于 1\_backbone\_head1\_head2.hbm 并没有增加多少。

模型加载推理时，ION 内存差异如下：

加载 1\_backbone\_head1\_head2.hbm，直接推理：

加载 compiled.hbm，推理 1\_backbone\_head1\_head2：

可以看到，compiled.hbm 占用的内存相比于 1\_backbone\_head1\_head2.hbm 并没有增加多少。

前言

最近 AI 圈有个“红色胖龙虾”火得离谱。

它原来叫 Clawdbot，因为太火被 AI 巨头 Anthropic 盯上，直接一份<span style="color: red;font-size: 16px">“友好通知”</span>说你侵权。于是连夜改名 Moltbot，最后成了现在的 openClaw。

最魔幻的是，因为这玩意的爆火，全球的 Mac Mini 居然被这帮极客买涨价了。

大家都在传：只要 1 分钟，你就能在手机上远程白嫖一个 24 小时待命的“数字员工”。

作为一名不折腾会死星人，我也在本地部署折腾了几天。体验下来发现：

<span style="color: red;font-size: 16px">它确实很不错，是一个称得上“住”在你电脑并且拥有管理员权限的管理员，当然，如果姿势不对，它就是你硬盘的“拆迁办”。</span>

核心拆解：为什么是 openClaw？

很多兄弟会问：我用网页版 Claude/Gpt 不香吗？非要折腾这个？

这就是 openClaw 设计聪明的地方。它内置了非常丰富的 function calling 功能，并且拥有终端系统权限。

简单来说，以前的 AI 是关在笼子里的，只能跟你聊聊天。而现在的 openClaw 相当于给 AI 做成一个智能终端。它不再只是“建议你删掉多余文件”，而是会有可能直接一句“好的老板”，然后顺手在你的某个目录敲下<span style="color: red;font-size: 16px">rm -rf。</span>

这种从“问答”到“执行”的范式转变，才是让极客们高潮的根本原因。

技能树：全能战神 or 电子垃圾？

打开 openClaw 的 Skill 列表，多达 7 个分类，49 个默认 skill 可供配置。说实话，这地方最能体现“卖家秀”和“买家秀”的区别。

不过在我看来，绝大部分都是“洋垃圾”，大陆用户用不上。

那些会让你觉得“神了”的功能

亲身体验下来有几个组合功能比较值得推荐。

• TG+群聊机器人：将 openClaw 接入 Telegram，由于默认就有“长期记忆”功能，所以它能记住你们绝大部分对话，从而实现体验良好的私人或群聊机器人（也可以配置到飞书/企微）。
• 浏览器自动化：openClaw 原生具备控制浏览器的能力，能帮你在不方便打开电脑时操控电脑网页，并生成截图，对网页进行总结等等，效果不错。（浏览器万岁！）
• 定时提醒到手机：<span style="color: red;font-size: 16px">极其有用的一个功能</span>，并且因为可以连通到手机，这让 Agent 有望成为低配版本的“贾维斯”，比方说，你可以让它定时每天推送 GitHub Trending 并加以总结给你；又或者把你经常逛的新闻网站让 openClaw 爬取然后每天推送给你；更有甚者，可以尝试把日程安排全做成定时任务，让 openClaw 变成你的“个人助理”。
  
• 本地文件管理： 由于拥有终端权限，你可以让 openClaw 化身 C 盘清理专家，帮你清理本地垃圾文件或查询需要的文件等。
  

我们再来看下部分知乎用户对其的讨论

劝退指南？谁在给这只“龙虾”交税？

当然，作为一个还在“长身体”的开源项目，openClaw 远没到小白上手即用的程度。在折腾了一周后，我搜集了各大平台的反馈，基本可以总结为三个字：<span style="color: red;font-size: 16px">坑挺大</span>。

Windows 用户：“后妈”生的

目前来看，这款产品的评价呈现极端两极分化：Mac 用户直呼真香，Windows 用户直呼退钱。
大概率是因为作者和核心贡献者都是基于 Mac 环境开发的，导致 Windows 版的 Bug 密集成灾：路径识别错误、依赖冲突、环境变量玄学报错。如果你不是一个习惯折腾环境的开发者，<span style="color: red;font-size: 16px">千万别在 Windows 上挑战自己的血压</span>。
实在想玩，可以去买云厂商搞好的 9.9 元月付套餐，花杯奶茶钱买个清静。

手机写代码：“赛博行为艺术”？

有人吹嘘 openClaw 能让你在手机上远程撸代码。但听小弟一句劝，在手机上改 Bug 绝对是伪命题。
我做手机上尝试让它在帮我修复一个 JS 逻辑，结果......完全没有反馈，我就已经开始 瑟瑟发抖了，我对“盲写”并没有兴趣。你可以用它来紧急重启个服务，或者跑个自动化脚本，但真要拿它写代码？<span style="color: red;font-size: 16px">那你很牛。</span>

致命伤：“死循环”偷钱可能性

虽然发生概率很少，但这是 Agent 架构目前比较无解的痛点。

笔者之前有幸在 cursor 上体验过几次，由于提示词或大模型本身的判断逻辑出现异常，AI 有时会陷入一种“鬼打墙”的状态。

比如：你让它找一个文件，它找不着，然后触发“重试”技能；重试又找不着，再触发“搜索”技能……在这个过程中，它每动一下都在疯狂调用 API。

当你发现它还没干完活时，它可能已经在短短几分钟内烧掉了你一顿饭钱。如果不设 Token 熔断，可能会让你有亿点点肉疼。

最后

虽然有不少毛病，并且未必有啥提高产能的能力，但我依然对 openClaw 保持高关注，为什么？

因为这个项目的 Agent 具备了<span style="color: red;font-size: 16px">“权限”</span>。以前我们用 AI，是“一问一动”；现在是“一问多动”，甚至你设置好定时任务，它是“不问也动”。

<span style="color: red;font-size: 16px">这个项目开始，实现了从“对话”到“接管”。</span>

尽管它现在还会“拆家”，还会“乱花钱”，但这种架构值得我们共同关注。

本文由mdnice多平台发布

作者：王博涵 小步外勤产品总监，外勤管理数字化专家

在外勤人员占比较高的企业中，管理难点往往并不在于制度本身，而在于执行过程是否真实可控。

员工每天在外奔波，管理层却很难持续判断行程是否合理，现场是否到位，费用是否按实际发生。

过去数年里，定位打卡曾一度成为外勤管理的常用手段。但随着业务规模扩大，这种以点位记录为主的方式，很难支撑过程管理。定位无法连成轨迹，停留无法量化，外勤行为仍然处在不可验证的状态。

故而近几年越来，越多的企业开始将人员定位管理系统引入到外勤管理体系中，用更连续、更真实的数据，支撑人效管理和费用管控。

从实际应用情况来看，目前人员定位管理系统主要呈现出三种不同的发展方向。

当前人员定位管理系统的三种常见形态

第一类 偏基础的定位考勤系统

这一类系统多是从行政考勤延伸而来的，常见于通用办公平台中。其主要功能便是记录上下班位置，配合简单的地理围栏，解决是否到岗的问题。

这类系统在人员规模较小、外勤占比不高的企业中有一定的实用价值。但在实际外勤场景中，它们往往只能记录零散的定位点，无法形成完整轨迹，也无法判断员工在客户现场的真实停留情况。

同时，防作弊能力相对有限，对虚拟定位、位置修改等行为缺乏有效识别手段。

因此，这类产品更适合作为基础考勤工具，而不是完整意义上的人员定位管理系统。

第二类 面向业务过程的人员定位管理系统

随着外勤管理要求的不断提高，越来越多企业开始关注过程真实性和执行质量。而这正是管控型人员定位管理系统的核心价值所在。

这一类系统不再只是关注员工有没有到达，而是重点解决几个关键问题：是否真实到场，是否按要求完成拜访或巡检动作，路线是否合理，费用是否真实发生。

围绕这些真实的管理需求，人员定位管理系统也在不断演进，从单一记录位置，逐步走向对过程真实性和执行质量的管理：

• 在定位层面：通过低功耗持续定位，还原员工全天的外勤轨迹，形成清晰的时间线。系统会自动分析每个点位的停留时长，帮助管理者识别异常拜访和形式化执行。
• 在防作弊层面：通过对手机运行状态和定位行为的综合判断，识别虚拟定位、模拟轨迹、异常失联等情况，并形成异常记录，避免外勤过程成为管理盲区。
• 在取证层面：现场拍照会自动生成包含时间、地点、人员信息的水印内容，便于后台快速核验，减少人工反复确认的成本。
• 在费用管理方面：基于真实轨迹自动核算里程，为油补和差旅报销提供可靠依据，减少人为填报带来的误差和风险。

这一类人员定位管理系统，已经成为快消巡店、医药代表拜访、物业巡检、自备车销售等场景中的主流选择。

第三类 面向安全场景的增强型定位系统

在部分高风险行业，人员定位管理的核心目标并不在于效率，而在于安全。

这类系统通常结合室内高精度定位、传感设备或卫星通信技术，实现更高精度的人员定位和状态监测。例如在矿井、化工园区、电力施工等场景中，用于实时掌握人员位置，并在发生异常时及时预警。

由于其建设成本和部署复杂度较高，这类系统通常只适用于特定行业，并不适合大多数日常外勤管理场景。

如何判断人员定位管理系统是否真正适合企业

在选型过程中，企业很容易被各种功能描述吸引，但真正决定系统价值的，往往是其是否贴合实际管理逻辑：

首先是定位数据是否连续可信，只有能够还原完整轨迹，定位数据才具备管理意义。

其次看系统是否围绕真实业务流程设计，是否支持巡店、巡检、拜访等标准动作的顺序执行，是否能够通过定位约束避免走形式。

然后看费用数据是否基于真实行为产生，如果里程和补贴仍然依赖人工填写，那么人员定位管理系统的价值就会大打折扣。

最后还要看系统是否具备长期落地能力，外勤管理不是一次性全部上线，而是需要持续优化制度和流程的，这对服务能力提出了更高要求。

人员定位管理系统选型建议

从实际使用情况来看，不同企业的需求差异明显：

• 如果企业主要解决考勤问题，外勤比例较低，基础定位功能即可满足需求。
• 如果企业希望提升外勤执行力，确保过程真实，同时优化人效和费用结构，那么以过程管理为核心的人员定位管理系统，如小步外勤更为合适。
• 如果企业处于高危或特殊作业环境，应优先考虑以安全为目标的深度定位方案。

最后，需要清楚的是人员定位管理系统的价值，从来不只是记录位置本身，而在于通过真实数据，让外勤管理从经验判断走向客观决策。

OpenClaw对接聊天APP及AI助手工具

1、对接飞书聊天APP

openclaw配置

此处以飞书为例，输入插件下载安装命令：

openclaw plugins install @m1heng-clawd/feishu  
cd /root/.openclaw/extensions/feishu/ 
npm install --verbose  #此步骤安装时间较强长，请耐心等待。

等下载安装完成后。在命令行下运行openclaw图形配置界面。

open channels add

回车

回车后，根据提示输入飞书App ID和App Secret。

在飞书开放平台应用凭证获取，打开飞书（https://open.feishu.cn/app/），点击左边凭证基础信息，在页面中找到 “App ID” 和 “App Secret” 两个数据，分别点击右侧 “复制” 按钮，将其复制到openclaw配置界面。飞书配置参考下一章节。

输入应用凭证后，回车完成配置。

openclaw gateway restart ，重启网关服务。

运行openclaw status，查看状态是否正常。

验证飞书接入

1. 打开手机或电脑端飞书 APP，登录与飞书开发者平台相同的账号；
2. 在飞书首页，找到 “工作台” 入口，点击进入，在工作台列表中找到已发布的 openclaw 应用（如 “openclaw 助手”），点击进入；
3. 系统将自动启动私聊窗口，发送任意消息（如 “你好”“查询今日日程”）；
4. 验证结果：如果收到 openclaw 的回复，即为飞书接入成功

以上配置完成后，即可上手使用。快上京东云开启一键部署，让 openclaw 成为你专属的 24 小时数字员工！

飞书机器人配置

创建飞书企业自建应用

1. 访问飞书开发者平台（https://open.feishu.cn/app?lang=zh-CN）；
2. 登录后，点击 “创建企业自建应用”；
3. 填写应用基础信息：应用名称（如 “openclaw 助手”），选择应用图标，点击 “创建” 按钮，进入应用管理页面。

1. 添加机器人能力：在应用管理页左侧导航栏，找到并点击 “添加应用能力”，在弹出的列表中选择 “机器人”，点击 “添加”。

1. 点击上方的创建版本并发布。

飞书应用权限与事件配置

此步骤分为「事件配置」「权限配置」「应用发布」三部分，全程在飞书开发者平台操作，按顺序执行：

（1）事件配置

1. 在飞书应用管理页，左侧导航栏找到 “事件与回调” 栏目，点击进入；
2. 事件配置：在页面中选择 “长连接”，点击 “保存”；

⚠️如果这一步提示 “未建立长连接”， 请检查自己的APP ID和APP Secret是否已正确配置。

（操作见上一步：添加飞书channel配置-配置APP ID与APP Secret）

1. 添加事件：点击页面中的 “添加事件”，在弹出的事件列表中，选择 “消息与群组” 分类，勾选 “接收消息”，点击 “确定”，完成事件订阅。

!

1. 回调配置：订阅方式选择 “使用长连接”，无需填写其他地址，配置自动生效。

（2）权限配置

1. 在飞书应用管理页，左侧导航栏找到 “权限管理” 栏目，点击进入；
2. 点击页面中的 “批量导入权限” 按钮，弹出权限导入窗口；

3.复制以下 JSON 代码，粘贴到导入窗口的输入框中，点击 “导入” 按钮，等待权限导入完成：

代码语言：txt

AI代码解释

{  
 "scopes": {     "tenant": [       
 "contact:user.base:readonly",    
    "im:chat",       
    "im:chat:read",     
    "im:chat:update",      
    "im:message",       
    "im:message.group_at_msg:readonly",       
    "im:message.p2p_msg:readonly",       
    "im:message:send_as_bot",       
    "im:resource"     ],     
    "user": []   } }

4.导入验证：页面显示 “导入成功”，且权限列表中出现上述导入的权限，即为配置完成。

（3）发布应用

1. 在飞书应用管理页，左侧导航栏找到 “版本管理与发布” 栏目，点击进入；
2. 点击右上角的新建版本；

填写版本号与描述后，保存并发布；

2、更换模型

openclaw onboard

按键盘上左右方向键，选择到“Yes”后，按回车键开始配置。

Onboarding mode 选 QuickStart。

选择Qwen等模型。

回车确认。

复制地址在浏览器中打开，后登录账号确认通过。（需要先注册账号https://chat.qwen.ai/）。

选择默认模型后，回车确认。选择选择重启网关服务后即生效。

技能包（Skill）配置

新手暂时无需添加额外技能包，选中 “No” 跳过，按回车键确认；

Hooks 配置

选中 “session-memory”（启用记忆功能，支持多轮对话上下文关联，避免每次聊天都需要重复说明需求），其他两项可根据需求选择。按回车键确认；

3、常用命令汇总

OpenClaw是少数真正具备系统级操作能力的个人智能助理：

• 本地长期记忆（对话数据自主可控）
• 跨平台推送（支持对接通讯类软件）
• 真实任务执行（文件整理、表单提交、代码生成）

这样一个强大又敏感的 AI 助手，该运行在哪里？更安全、更稳定的方式，是将其部署在独立、隔离的云端环境中。

京东云全面上线 openclaw(Clawbot)！京东云轻量云主机现已预置 openclaw 应用镜像，无需手动配置环境，2步即可完成部署，让你的 AI 助手秒级上线、全天候待命。

第一步：一键创建实例

在京东云控制台创建轻量云主机，选择：

镜像名称：openclaw（Clawdbot）

规格建议：2 核 2G 起 （推荐 2 核 4G 以获得更佳体验）

创建成功后，进入云主机列表页，点击右边操作列的【查看】，打开18789端口。

点击【防火墙】，打开后点击【添加规则】。

在目标端口中输入18789，源IP输入0.0.0.0/0，点击【保存】。

再次转到轻量云主机列表，记录下公网IP地址，点击【登录】。

通过WebTerminal登录云主机。

进入配置界面。

第二步：配置openclaw

通过webTerminal登录系统后，执行下面的命令。

bash init-openclaw.sh 18789 pk-03bf0b76-8326-4ad7-91bf-293c5dd35c8d 公网IP    

\#红色部分替换成你的API-KEY，API-KEY获取步骤参考下方【获取API-KEY】章节。

回车后，生成可以直接访问的地址【http://公网IP:18789?tokan=字符串】。复制在Web浏览器中回车打开。

出现openclaw的web交互网站，可以直接和AI助手对话了。

获取API-KEY

登录京东云JoyBuilder 模型开发平台 2.0，进入API-KEY 管理页面：

（https://joybuilder-console.jdcloud.com/system/api-key/list）

1、点击【创建】按钮，生成新的 API-Key；

2、选择长期有效，点击【确定】。

3、生成长期的API-KEY，点击右边复制图标复制API-KEY。

4、在“修改 API-KEY”页面中，为该 Key 配置可访问的模型服务，必须包含以下模型：DeepSeek-V3-0324、DeepSeek-V3.2、DeepSeek-v3、Qwen3-235B-A22B、Kimi-K2-0905-jcloud

5、选择需要的模型，或者全部选上。点击【确定】完成模型绑定。

6、为了保证模型正常工作，需要至少保证账户中有金额。点击充值完成京东云账号充值。