Project D
LLM Agent 多工具编排框架
2024.08 – 2025.01
痛点工厂一线要让 LLM 同时操控 30+ 异构系统(PLC / 传感器 / SCADA / Web API),LangChain 冷启动就吃 1.4GB RAM,单进程最多撑 12 路会话就 OOM,工具调用准确率不到 60%。
做法用 Python asyncio 自研五层 Loop:tool routing / state machine / memory / reflection / streaming 全部解耦;C++ 重写 token 解析与 protobuf 反序列化提速 4 倍;用 binary enum 约束 LLM 输出,零重试。
结果单进程稳定 50 路并发长会话,工具调用准确率 96%,冷启动 < 200ms;部署成本从 ¥50k/年降到 ¥8k/年。
PythonasyncioC++protobufgRPCPostgreSQL
50 路并发 · 工具调用 96% · 冷启动 < 200ms
Project E
工业多通道振动+温度同步采集网关
2022.06 – 2023.02
痛点客户要求 16 通道振动 + 4 路温度同步采样 1kHz,通道间相位抖动必须 < 50μs;Linux 默认调度 + Python 多线程实测抖动能冲到 800μs,丢帧率 3%,根本过不了验收。
做法STM32H7 裸机 C 主控,DMA + 定时器中断双缓冲采样,CMSIS-DSP 做滑动 FFT;C 端先跑卡尔曼滤波再 DMA 推送,FreeRTOS 任务优先级分层;下行用 LZ4 流式压缩,缓存 24h ringbuffer 走 SPI Flash。
结果实测 16 通道相位差 < 50μs,1 个月不掉一个点;下行带宽 6MB/min → 1.6MB/min(压缩 73%),断网后恢复零丢失。
CSTM32H7DMAFreeRTOSCMSIS-DSPLZ4卡尔曼滤波
16 通道 · 1kHz · 抖动 < 50μs · 压缩 73% · 24h 零丢失
Project F
工业设备 RAG 知识库与文档结构化抽取
2024.10 – 2025.04
痛点工程师查一份 200 页设备手册平均翻 18 分钟,新人占比高、离职率高,售后成本逐年涨;LlamaIndex 默认 pipeline 在 PDF 表格和扫描件上召回率掉到 0.5,根本用不起来。
做法自研 PDF 解析器(pdfplumber + Tesseract OCR + 表格重建三件套);混合检索 BM25 + BGE 向量,multi-hop query rewriting;抽取阶段用 Pydantic 强 schema 约束 + 反查锚点定位原文坐标。
结果2000 页手册 4 分钟建库,召回 0.91,复杂查询 top3 命中 87%;工程师平均查找耗时 18min → 2min,售后工单降 22%。
PythonLlamaIndexChromaBGEBM25TesseractPrompt
2000 页 · 召回 0.91 · top3 命中 87% · 查找 -89%
Project G
多 Agent 协作智能运维平台
2025.01 – 2025.08
痛点客户工厂夜班只有一个工程师盯 5 台关键设备,每天 ≥2 起告警,平均响应 28 分钟;等工程师上线、设备熟悉、调工具链,单故障处理就 1 小时起步,月均人工成本 ¥30w。
做法搭 3 个 Agent:Detector 抓 metric+log 异常、Diagnoser 走 RAG 查历史工单+设备手册、Executor 调 SSH / 设备 API 执行修复;Agent 间用 Redis Streams 事件总线,Python asyncio + custom dispatcher 串起来。
结果线上故障平均自愈 4m12s(人工 28m);月均自动闭环 60+ 起故障,年节省 ¥30w+ 加班费,工程师终于能睡整觉。
PythonMulti-AgentRAGFunction CallingFastAPIRedis Streams
自愈 4m12s vs 人工 28m · 月均 60+ 起 · 年省 30w+
Project H
边缘 AI 视觉检测(太阳能板缺陷)
2023.06 – 2023.12
痛点太阳能板表面缺陷检测,户外 -10°C 电池供电的盒子里跑(无 GPU),客户给 8s/帧 预算;PyTorch 原版 YOLOv8s 直接占 1.2GB 显存,Jetson Orin Nano 上根本起不来。
做法C++ 写 PyTorch→ONNX→TensorRT 全流程量化 pipeline,FP16 + INT8 混合校准,自定义 YOLOv8 neck 算子融合;GStreamer 多路摄像头并行解码 + ROI 预处理前置;模型大小从 44MB → 11MB。
结果检测 mAP 0.92,单帧推理 35ms(比预算快 228x),显存 4.2GB → 1.1GB;半年量产 200 台,部署现场零返修。
C++TensorRTCUDAYOLOv8ONNXGStreamer
mAP 0.92 · 35ms/帧 · 显存 -74% · 量产 200 台
Project I
工业设备预测性维护系统
2024.06 – 2025.02
痛点客户产线空压机轴承一旦坏了才停,每次检修 8 小时,全厂掉线赔 ¥50w;想加传感器但厂里只批 3 个振动点(多了就"碍事"),传统阈值法在低频段漏报率超 30%。
做法3 点振动 + 温度时序,FFT 提频域特征后喂给 LSTM 自回归;C++ 把模型走 ONNX Runtime 部署到边缘网关(RAM < 50MB);剩余寿命用 Weibull 分布 + 置信区间,输出 7/15/30 天三档预警。
结果轴承故障预测准确率 94%,平均提前 7 天预警;上线当年帮客户挽回 6 次非计划停机(> ¥300w 损失),模型在线持续漂移检测自动触发重训。
PythonPyTorchONNX RuntimeLSTMFFTWeibullC++
准确率 94% · 提前 7 天 · 当年挽回 6 次停机 · ¥300w+
Project J
BLE 设备管理微信小程序(工程部自用)
2022.10 – 2023.04
痛点工厂 200+ 台蓝牙传感器升级固件、改采样频率都得拆机+串口刷线,每次维护工程师跑现场 4h/台;微信小程序能直接在工程部手机操作,但 iOS BLE 反复断流、安卓 MTU 仅 20 字节,开源库根本扛不住生产。
做法自研 BLE 通信库统一 4.0~5.3 协议:分包序号 + 滑动窗 CRC + 自适应超时重传;OTA 用差分包 + 一键回滚 + SHA256 校验;后端 FastAPI + PostgreSQL + 阿里云 OSS,弱网走 MQTT QoS2。
结果扫码 → 配网 → 首次上报全流程 12 秒完成(业内平均 35s);弱网重连率 0.3%,稳定承载 5 万用户设备绑定。
BLE 5.0微信小程序CMQTTOTA 差分FastAPI
12s 全流程 · 弱网重连 0.3% · 5 万用户 · 售后 -70%
Project K
低功耗 BLE 多通道数据采集终端(ML307C)
2023.03 – 2024.02
痛点客户要给几万个监控点装倾角传感器,2400mAh 电池必须撑 1.5 年;ML307C OpenCPU 平台 RAM 仅 256KB,BLE MTU 死锁 20 字节,1KB 配置下发要拆 60 包;开源 Nordic 协议栈一开 BLE 就吃掉 80% 续航。
做法C 裸机 + FreeRTOS 任务分层,外设全部掉电休眠;自研分包协议:背靠背发 + 滑动窗口 CRC + 失败回退到分页请求;MCU 端先 FIR 滤波 + 阈值去抖才上报,连接间隔从 7.5ms 拉到 200ms 平衡功耗与时延。
结果实测待机 1.5 年零 1 天(电池实测 549 天),1KB 配置首包到达率 99.2%(同类开源 78%);客户验收一次过,连续稳定运行 > 12 个月零投诉。
CML307CFreeRTOSBLE 5.0MQTTCat.1OpenCPU
首包 99.2% · 待机 1.5 年 · 稳健运行 >12 月 · 客户零投诉
Project L
边缘 AI 推理网关(工业现场)
2023.09 – 2024.08
痛点客户要把云端 7B 模型能力"搬到"产线,但现场只能给一台 4 核 ARM + 32GB RAM + 无独显的工控机;llama.cpp 跑通就要 22GB,vLLM 干脆起不来;首 token 等 1.2s 客户就拒绝验收。
做法llama.cpp + GPTQ INT4 量化打底,自研 KV Cache 分页复用 + 滑动窗口分片预取;ARM NEON 重写矩阵乘算子,吞吐提 2.3x;Python 调 prompt 模板瘦身 + first-token prefill offloading。
结果7B 模型在 32GB 盒子稳定运行,首 token 380ms(同类 1.2s+),吞吐 28 tok/s;连续 72h 零 OOM 崩溃,已上线 12+ 站点。
C++llama.cppGPTQ INT4NEON SIMD边缘推理
首 token 380ms · 吞吐 28t/s · 72h 零崩溃 · 12+ 站点
Project M
工业设备云端管理平台(10 万级接入)
2024.03 – 2025.06
痛点10 万工业设备每 30s 上报 1 条指标 + 不定时告警,最早用 Celery 架构,2 台 worker 就把 Redis 打挂、QPS 卡 800,连客户第一次 PoC 都过不了;同类厂商方案单机就要 2GB+ 内存。
做法架构推翻重做:FastAPI + asyncio 全异步,砍掉 Celery/Redis worker(自己用 uvicorn + 信号量调度);PostgreSQL 按设备 ID 哈希分区 + 冷热分层 + pgbouncer 连接池;上传走 ZIP 批量 + 单条追加双模式,断点续传 100% 零丢失。
结果单机支撑 10 万设备稳定接入(活跃 5 万台),API P99 < 100ms,进程内存峰值 < 500MB;上线 9 个月 Redis 零抖动,运维成本砍掉 ¥18w/年。
FastAPIasyncioPostgreSQLDockerMinIO
10 万设备 · P99 < 100ms · 内存 < 500MB · 9 月零故障