逛完IOTE 2026的展馆我最深的感受是AI终于不飘在云端了。前几年大家聊AI开口闭口都是参数规模、训练集群、算力调度离一线业务远得很。但这次在祥承科技的展台前我看到了一条完全不同的技术路线——把AI直接塞进工人手里的智能终端让算法在流水线旁边、配电房里、货运叉车上实时跑起来。这种“现场智能”的思路解决的不是“模型能答对多少题”而是“老师傅不在场时系统能不能替他把好关”。这篇文章我就结合这次展会的见闻聊聊现场智能到底是什么、技术方案怎么落地、部署时会踩哪些坑以及给正在做技术选型的朋友一些参考。不管你是做工业自动化的、搞物联网集成的还是负责企业数字化转型的这篇文章应该都能给你一些启发。1. 现场智能的本质把AI从机房搬到工位旁1.1 什么是现场智能它和传统AI方案有何不同现场智能这个概念字面上看是在生产现场部署AI能力但真正落地的时候它和传统的“云端AI手机/电脑访问”有本质区别。传统的AI应用数据要传到云端模型在服务器上推理结果通过网络回传。这种模式在网速够快、时延够低的环境下没问题但到了工厂车间、野外基站、仓库货架这些场景网络抖动、带宽不足、时延过高都是致命的。现场智能的核心思路是“数据不出场、推理在本地”。智能终端本身内置AI算力摄像头采集的画面、传感器读到的数据直接在设备端完成模型推理毫秒级输出结果。只有需要上传的日志和模型更新才走网络而且这些数据往往经过脱敏和压缩。这种架构带来的好处很直接断网也能用时延低到人感觉不到敏感数据不用出园区。我在展会上看祥承科技演示的智能巡检终端时有个细节印象很深。工作人员把设备对着配电柜拍了一下屏幕上立刻叠加显示温度读数、仪表盘数值和设备健康评分全程没有任何网络请求。这种体验和手机App里“转圈加载”的AI完全不是一回事。1.2 为什么是现在大模型、边缘算力与数据积累的三重共振现场智能不是新概念五年前就有人提“边缘AI”但一直雷声大雨点小。这次IOTE展会上能成规模落地背后是三股力量同时到位。第一是模型侧。AI大模型技术成熟之后小模型的能力也被带动起来了。以前做一个缺陷检测模型要收集几万张缺陷样本训练出来的模型换个产品线就废。现在用大模型做数据增强和知识蒸馏几百张样本就能训出一个能用的轻量模型工业场景的碎片化问题被大幅缓解。第二是芯片侧。端侧AI芯片的算力这几年涨得飞快功耗却没怎么涨。展会上一台手持终端里装的高通或瑞芯微方案INT8算力能做到10TOPS以上跑一个YOLO级别的检测模型绰绰有余。更关键的是这些芯片的成本已经降到了消费电子能接受的区间终端厂商不用再为算力支付高昂溢价。第三是数据侧。做了这么多年信息化工厂里的设备、流程、物料基本都数字化了数据湖里攒了大量的历史数据。这些数据以前是“死”的顶多做做报表现在正好拿来训练现场智能模型。缺的不是数据而是把数据变成决策能力的管道现场智能就是这个管道的最后一公里。2. 现场智能的核心技术与架构拆解2.1 端边云三层架构各司其职不抢戏一套完整的现场智能系统通常分端、边、云三层。端是工人手里的智能终端、设备上的传感器负责采集数据和本地推理边是车间里的边缘服务器或网关负责汇聚多个端设备的数据跑更大的模型做区域级的协同决策云是训练中心和运维后台负责模型迭代、全局监控和设备管理。这三层不是简单的数据上传下载关系而是按“实时性”和“资源消耗”做了分工。毫秒级响应的任务比如安全帽佩戴检测、仪表读数识别放在端侧秒级响应的任务比如多设备联动告警、产线节拍分析放在边侧小时级甚至天级的任务比如模型重训练、跨厂区数据挖掘才上云。祥承科技在这次展会主推的“现场智能终端边缘计算盒子云端管理平台”组合正是按这个逻辑搭的。现场终端负责执行边缘盒子负责协调云端负责进化。三个环节各有各的技术难点但最难的不是单个环节而是怎么把它们的接口对齐、任务分好工。2.2 模型轻量化让大模型屈尊于小芯片的三种手段现场智能最大的矛盾是模型越来越大和芯片越来越小之间的矛盾。AI大模型动辄几十亿参数但现场终端的内存可能只有8GB算力芯片还不到旗舰手机的水平。要让模型在终端上跑起来必须做轻量化处理。量化是最常用的手段。把模型权重从FP32压到INT8模型体积缩小四倍推理速度提升两到三倍精度损失控制在1%到2%以内。如果场景对精度要求不那么苛刻比如巡检目标的分类甚至可以压到INT4。我在实际项目中试过一个300MB的检测模型量化到INT8之后终端上推理延迟从80毫秒降到了25毫秒完全能满足实时检测需求。知识蒸馏是另一条路。用一个参数量巨大的教师模型通常是大模型去指导一个小学生模型学习让小学生模型在特定任务上逼近教师模型的能力。这种做法在工业场景特别实用因为工业缺陷样本本来就少直接训练小模型容易过拟合用大模型做“教练”能显著提升小模型的泛化能力。还有剪枝和结构搜索。剪枝是把模型中不重要的连接或通道删掉结构搜索是自动寻找更高效的网络结构。这两种方法对工程团队的要求比较高一般由算法工程师主导但效果很直接。祥承科技在展台放了一个对比数据经过轻量化处理的模型在同等精度下推理帧率从15FPS提升到了35FPS功耗反而降了40%。3. 一线场景的落地实操从选型到部署的完整路径3.1 硬件选型确定算力、功耗和防护等级的黄金三角做现场智能方案第一步不是选模型而是选硬件。硬件决定算力上限算力上限反过来制约模型复杂度。我的经验是先明确三个参数目标推理帧率、可接受的延迟、设备的工作环境。推理帧率决定了芯片的算力底线。以视觉检测为例如果产线节拍是每分钟60件那每秒至少要处理一次检测单帧处理时间不能超过1秒。考虑到摄像头采集和预处理的开销模型推理延迟最好控制在200毫秒以内这就要求芯片INT8算力至少5TOPS。如果是巡检机器人这类需要连续视频分析的场景帧率要求会高很多芯片算力最好上到20TOPS以上。功耗和散热决定了设备形态。手持终端受限于电池容量整机功耗一般控制在3W到5W芯片要选能效比高的。固定安装的智能网关没有电池约束可以选TDP更高的芯片用被动散热片就能解决散热问题。防护等级经常被忽略但往往是最致命的。产线上的设备要面对粉尘、油污、震动户外场景还要防水防尘。选型时至少要IP65起步工业级设备建议IP67。祥承科技展出的现场智能终端机身包了一圈厚厚的橡胶护套按键做了密封处理这种细节在极端环境下能省掉大量售后维护成本。3.2 软件部署容器化、OTA与离线优先的设计原则硬件定下来之后软件部署是决定项目能不能长期稳定运行的关键。我在多个项目里踩过坑之后总结出三条原则。第一应用必须容器化。现场终端的系统环境千差万别有安卓、有Linux、还有RTOS如果应用和系统强耦合每次适配都是噩梦。把AI推理引擎、业务逻辑、通信模块都打成容器镜像换设备就像换手机装App一样简单只是换个基础镜像就行。第二OTA升级是必需品不是奢侈品。现场的终端数量一多挨个升级固件能把人逼疯。更麻烦的是模型更新——工业场景的缺陷种类不断变化模型要持续迭代。OTA通道平时跑日志需要时下发新模型不用到现场就能完成更新。第三离线优先的设计原则。这个原则说起来简单做起来很难。所有的关键功能必须能在断网时正常工作云端只是增强项。我见过不少项目网络一抖整个系统就瘫了就是因为设计时把云端当成唯一的大脑没有考虑本地自洽。3.3 场景落地案例从数据采集到价值闭环的四步走现场智能的落地路径我按项目推进的顺序拆成四步。第一步是数据采集与标注。用现场的摄像头和终端按正常生产节拍采集图像和传感数据然后由工艺工程师和算法工程师共同标注。这一步最耗时但也最重要。我建议不要只采集“正确”的样本缺陷样本、模糊样本、不同光照下的样本都要覆盖模型才能学到真正的边界。第二步是模型训练与验证。训练阶段用云端GPU集群跑验证阶段一定要拿现场的测试集来测不要在实验室的数据集上自嗨。很多模型在实验室精度99%一到现场就掉到90%原因就是训练数据和现场数据的分布不一致。第三步是灰度发布。先在一条产线上试点跑一周看效果重点关注误报率和漏报率。工业场景最怕的是漏报漏一次就是一次质量事故。误报多虽然烦人但顶多是工人烦一点漏报是致命的会直接导致不良品流出。第四步是全面推广和持续迭代。模型上线之后不是终点要建立告警日志回流机制定期把现场的误报和漏报样本收回来重新标注、重新训练形成数据飞轮。祥承科技在展会上提到一个数据——他们的某个质检项目经过三轮迭代后误报率从初期的8%降到了1.5%靠的就是这个闭环。4. 现场智能实施中常见的“坑”与排查技巧4.1 光线变化导致识别率骤降视觉类的现场智能项目最常见的问题就是光线。车间里不同时段的光照差异很大早上和下午的色温不同阴天和晴天的亮度不同甚至某台设备正好在摄像头和光源之间移动都会导致识别率波动。排查思路是先看数据再看模型。第一步统计一天中不同时段的识别准确率找出准确率骤降的时间窗口第二步回放那个时段的原始图像确认是不是光线问题第三步如果是就在训练集里增加多光照条件的样本或者在前端加补光灯和偏振片。实测下来加一个恒定光源是最简单有效的方案能一下子把识别率拉回稳定区间。4.2 边缘设备算力跑不满也降不下来有些项目配置的芯片算力明明够但实际推理帧率就是上不去。这种问题多半出在数据管线上而不是模型本身。终端采集图像后要经过预处理解码、缩放、归一化如果这些步骤在CPU上跑GPU/NPU就得空等整体吞吐量自然上不来。排查方法是给每个环节单独计时。用性能剖析工具分别测采集、解码、预处理、推理、后处理五个环节的耗时找出瓶颈。常见的优化手段包括用硬件解码器替代软解、把预处理操作搬到GPU/NPU上、使用流水线方式让采集和推理并行。我遇到过最夸张的一个案例优化数据管线后整体吞吐量提升了3倍——算法一个字母没改。4.3 断网后系统“假死”的隐蔽原因离线优先的原则大家都认可但真正实现起来经常出问题。我在项目里遇到过一种情况网络断开后终端界面还能操作但AI功能全部失效点了没有任何反应。排查到最后发现是通信模块的锅。应用内部用了同步的HTTP请求请求超时时间设的是10秒网络断开后请求一直阻塞拖住了整个推理线程。解决方案是把网络请求全部改为异步或者设置更短的超时时间并加入本地缓存。这种事在文档里很难发现只有在实际部署中才会暴露。4.4 数据隐私与合规的隐性成本现场智能涉及大量生产数据和工人行为数据数据合规的坑往往在项目中期才暴露。有些工厂对数据出境有严格要求数据连园区都不能出有些行业对人员行为分析有合规限制不能采集生物识别信息。我的经验是项目启动前就要做一轮数据合规评估明确哪些数据可以上云、哪些必须留在本地、模型训练用哪部分数据。如果合规要求严格训练数据只能脱敏后在本地集群上训练这会影响模型迭代的效率需要在方案设计时提前想好。现场智能的优势本来就在于数据本地化处理只要架构设计得好大多数场景都能满足合规要求。4.5 常见问题速查表问题现象大概率原因排查与解决方向识别率随时间波动光照条件变化增加恒定光源训练集覆盖多时段样本推理帧率不达标数据管线存在瓶颈分环节计时优化预处理与推理流水线断网后AI功能失效网络请求阻塞了推理线程改异步通信设置合理超时增加缓存模型在实验室好、现场差训练数据与现场数据分布不一致增加现场样本进行数据增强与领域自适应设备频繁死机散热不足或电源不稳检查散热方案增加工业级稳压电源多人同时使用延迟高边缘节点并发能力不足增加边缘节点或优化模型提升推理效率5. 现场智能的选型建议与趋势判断5.1 自研还是采购中小团队的现实选择现场智能的落地路径要么自己从芯片到算法全部自研要么基于成熟的终端和平台做集成。我的判断是除非团队有非常强的算法和硬件背景否则采购成熟方案再二次开发是更务实的路线。原因很简单现场智能的链条太长了。硬件设计、散热结构、工业防护、模型轻量化、通信协议、设备管理平台每个环节都需要专门的积累。祥承科技这类厂商在展会上展示的不只是一个终端而是一整套经过验证的工程方案包括外壳模具、天线设计、功耗管理等细节。中小团队想完全自研光是把这些坑踩一遍就要好几年。更合理的分工是终端和平台选成熟厂商算法和业务逻辑自己迭代。终端的价值在于稳定可靠算法的价值在于业务理解。把专业的事交给专业的人自己聚焦在数据、场景和业务闭环上项目成功率会高很多。5.2 从工具到助理AI Agent正在改变现场智能的交互方式这届IOTE展会AI Agent是出现频率最高的词之一。放到现场智能的语境里AI Agent的意义不在于聊天而在于把“工具”变成“助理”。传统的现场智能终端工人需要主动操作打开App、选功能、拍照、看结果。AI Agent化的终端则不同它能理解工人的语音指令自动调用对应功能甚至根据上下文主动推送信息。比如巡检工人说一句“帮我看看这台设备的运行状态”终端会自动调起检测模型、读取传感器数据、结合历史趋势给出综合判断。整个过程不需要工人点选菜单交互成本降低了一截。更进一步的AI Agent应用是跨设备协同。单个终端只能看到局部数据Agent可以拉取周边设备的传感数据结合知识库里的维护手册给出更全面的操作建议。这种能力对新手工人特别有价值——他们缺的不是工具而是老师傅的经验和判断力。5.3 端侧大模型现场智能的下一步想象空间AI大模型能力往端侧迁移是现场智能最值得关注的技术趋势。过去现场智能跑的都是专用小模型每个场景单独训练通用性有限。端侧大模型如果成熟一个模型就能覆盖多个场景工人用自然语言就能和终端对话让终端理解复杂的业务指令。端侧大模型的挑战也很明显模型体积和算力需求比小模型高几个数量级。目前业界的方向是量化到4bit甚至更低精度同时配合端侧NPU的硬件加速。从我在展会上看到的情况手机旗舰芯片已经能勉强跑起10亿参数左右的模型工业级终端因为成本敏感还需要一两年才能普及。但方向是明确的。现场智能的终局不是一堆专用功能的堆叠而是一个能理解现场、能自主决策的“数字员工分身”。等到端侧大模型成熟这个终局就会变成现实。写在最后我在现场智能这条路上踩过不少坑最深的体会是技术只是起点真正的难点在工程化。一个能在展台上流畅演示的AI功能和一条能在生产线上稳定跑半年的AI系统之间隔着的是一大堆琐碎的细节——散热设计、断网容错、模型迭代机制、工人使用习惯。祥承科技这次在IOTE展会上展示的“现场智能”方向最让我认可的其实是他们把这些问题都当成了系统工程来处理而不是单纯秀算法。如果你正准备做现场智能项目我的建议是先找一个小而具体的场景跑通闭环比如一台关键设备的预测性维护、一条产线的视觉质检。别一上来就规划“全厂AI大脑”那种项目十有八九烂尾。从小处着手把一个场景做深、做透验证了价值之后再横向复制这条路虽然慢一点但每一步都走得扎实。最后再分享一个小技巧项目验收时一定要在断电、断网、弱光、高温这些极端条件下测试能在恶劣环境下不掉链子的系统平时用起来才真正让人放心。