把摄像头、视觉大模型和告警闭环串起来：Vision Hub Platform 开源版上手

把摄像头、视觉大模型和告警闭环串起来：Vision Hub Platform 开源版上手

摘要：很多视觉 AI Demo 停留在“上传一张图片、调用一次模型”。真正进入园区、工厂或门店后，还要解决视频流接入、定时截帧、算法配置、结果结构化、告警留痕等问题。本文以开源项目 Vision Hub Platform 为例，跑通一条从模型接入到事件记录的完整链路，并聊聊它适合什么场景、当前有哪些边界。

推荐标签：视觉大模型、计算机视觉、Spring Boot、Vue 3、Docker、开源项目

项目地址：https://github.com/zj-unicom-ai/vision-hub-platform

先说为什么需要“视觉平台”

最近在做视觉 AI 场景时，一个感受越来越明显：模型能看懂图片，只是第一步。

如果只是验证模型能力，写几十行代码上传图片、调用接口就够了。但一旦接入真实摄像头，问题很快会变成：视频流谁来维护？多久截一帧？同一个模型怎样复用到多个检测场景？怎样确认算法效果？哪些结果应该形成告警？历史记录怎么查？

Vision Hub Platform 做的事情，就是把这些工程环节串起来。它不自带推理模型，也不强绑定某一家模型厂商，而是提供一套可部署的视觉任务底座：

• 接入视觉大模型和提示词算法；
• 管理 RTSP、HLS、FLV 等视频流设备；
• 给算法绑定设备和采样周期；
• 自动截帧、调用模型并解析结构化结果；
• 将命中的告警沉淀为可查询的事件记录。

所以我更愿意把它理解成“视觉 AI 的任务编排与运行平台”，而不是另一个模型展示页。

开源版包含什么

当前开源仓库把前端、后端、媒体服务和部署配置放在了同一个项目里：

vision-hub-platform/ ├── backend/ # Spring Boot 后端与独立媒体服务 ├── frontend/ # Vue 3 + Ant Design Vue 控制台 └── docker/ # Docker Compose 一键部署

核心模块包括大模型管理、算法管理、算法测试、设备接入、任务管理和事件记录。

模型被当作底层能力统一管理，算法不需要直接绑定某个项目。

一条任务真正运行时，数据大致这样流动：

摄像头 / 视频流 ↓ 独立媒体服务（连接、取帧、快照） ↓ MinIO 保存截图 ↓ 任务调度器按周期调用算法 ↓ OpenAI 兼容的视觉模型接口 ↓ 解析 isAlarm、confidence、coordinates 等结构化结果 ↓ Kafka 异步传递告警结果 ↓ 事件中心查询、查看详情和导出

这个拆分比较务实：媒体连接与 Web 管理服务分开，视频流抖动或重连不会把所有业务逻辑都塞进一个进程；模型结果通过统一结构进入后续流程，也方便继续接消息通知、工单或其他业务系统。

用 Docker Compose 跑起来

本地体验只需要准备 Docker 和 Docker Compose。

gitclone https://github.com/zj-unicom-ai/vision-hub-platform.gitcdvision-hub-platform/docker# Linux / macOScp.env.example .env# Windows 可使用：copy .env.example .envdockercompose up-d--build

第一次构建需要下载镜像和编译前后端，时间会比普通启动长一些。可以用下面的命令查看状态：

dockercomposepsdockercompose logs-fvision-hub-web-serverdockercompose logs-fvision-hub-media-server

默认访问地址是http://localhost，本地体验账号为：

用户名：unicom 密码：ZJ_Unicom

这套默认凭据只适合本地体验。准备部署到局域网或公网前，至少要修改.env中的数据库、Redis、MinIO、内部调用密钥和 JWT 密钥，并按需关闭 Swagger。

如果只是停止服务，使用：

dockercompose down

不要随手加-v。docker compose down -v会连同 MySQL、Redis、Kafka、MinIO 的数据卷一起删除。

从零跑通一次视觉检测

下面按实际使用顺序走一遍。

1. 先接入一个视觉大模型

进入“算法仓库 → 大模型管理”，新增模型，主要填写：

• 供应商和模型类型；
• 模型 ID；
• API 地址与 API Key；
• 上下文长度和最大输出 token。

这里有一个容易踩的细节：当前实现会在 API 地址后自动拼接chat/completions，因此地址应填写到兼容服务的基础路径，例如https://example.com/v1，不要重复填完整的/chat/completions。

项目当前内置 OpenAI、通义千问和联通元景的供应商适配。其他服务如果也遵循相同的 Chat Completions 多模态消息格式，可以沿用兼容思路；新增独立供应商枚举时需要补一层适配。

2. 把提示词配置成算法

进入“算法管理”，新建“大模型语义算法”，绑定刚才的模型，然后写检测提示词。

算法由名称、编码、底层模型和提示词组成，也可以从模板库快速复用。

例如，明火检测可以先从一段很短的提示词开始：

判断图像中是否存在真实明火。 打火机、蜡烛、火炬等可见火焰判定为告警； 排除灯光、反光、红色物体和屏幕中展示的火焰图片。 存在目标时，请给出数量、置信度、归一化坐标和简短说明。

平台会给大模型算法补上统一的输出约束，核心字段包括：

{"isAlarm":true,"count":1,"confidence":95,"coordinates":[[0.61,0.53,0.99,0.85]],"description":"图像右侧存在一处明火"}

这一步的意义不只是“少写代码”。更重要的是把检测标准从代码逻辑中抽出来，变成可以命名、测试、上下架和复用的算法资产。面对临时巡检、专项整治或小众长尾场景时，不一定要为每个需求重新训练和发布一个模型服务。

3. 上任务前，先做单图测试

算法创建后不要急着接摄像头。先进入“算法测试”，上传几组正样本和负样本，观察告警判断、数量、置信度、坐标和说明是否符合预期。

测试成功后，坐标结果可以直接画回原图，方便确认模型到底识别到了哪里。

这里的“测试”并不是只返回一句true或false。页面会同时呈现原始素材、画框后的结果图、告警判断、目标数量、置信度、归一化坐标和自然语言说明。业务人员能直接看到模型为什么这样判断，也能据此继续调整提示词，而不用在日志和接口响应之间来回切换。

从使用体验上看，它形成了一个很短的闭环：

自然语言定义检测标准 ↓ 上传样本立即测试 ↓ 查看结构化结果与目标框 ↓ 修改提示词后再次验证

实际调试时，我会至少准备三类图片：

1. 明确应该告警的正样本；
2. 外观相似但不应告警的负样本；
3. 低照度、遮挡、反光等边界样本。

如果模型经常把灯光或海报误判成火焰，优先把排除条件写进提示词，再重新测试。这个“配置 → 测试 → 调整”的小闭环，比把问题留到摄像头任务上线后再排查省事得多。

4. 接入摄像头或视频流

进入“设备接入”，填写设备名称、编码、接入协议和视频流地址。媒体服务会负责建立连接、维护帧缓冲并按需输出快照。

需要注意，浏览器不能直接播放原生 RTSP。前端页面可以直接预览适合浏览器播放的 HLS/FLV 流；RTSP 仍可交给媒体服务拉流和截帧。如果希望在浏览器中实时预览 RTSP，通常还需要在前面增加转码或流媒体网关。

5. 创建任务，把算法、设备和周期绑在一起

任务配置里选择算法，为每个算法设置采样周期和事件名称，再添加需要分析的设备点位。保存后可以直接启动任务。

图片来自完整版本演示界面；开源版保留算法、采样周期、事件名称和设备点位等主链路，图中的场景治理入口不在当前开源范围。

任务启动后，调度器会按固定间隔并行处理关联设备：从媒体服务取帧，将快照保存到 MinIO，调用算法；只有当结构化结果中的isAlarm为true时，才会向 Kafka 发送告警消息并生成事件记录。

这里把“算法测试”和“连续任务”分成两个入口很实用：前者解决算法有没有效果，后者解决算法如何长期、稳定地跑在多个点位上。

6. 在事件中心查看结果

事件中心不是简单的运行日志。它可以按事件名称、时间、任务、设备点位和算法等条件筛选，并用带截图的卡片呈现命中的事件。下面是老鼠检测产生的事件记录：

同类事件被集中沉淀，可以先通过截图快速浏览，再进入单条事件核查。

点进单条事件后，可以看到告警图片、任务、算法、推理耗时、置信度和自然语言说明。下面是一次老鼠检测的事件详情：

这一步让视觉识别不再是一段“模型返回的 JSON”，而是变成可查询、可复盘、可导出的业务记录。后续如果要对接短信、企业微信、工单或应急处置流程，也有了统一的事件入口。

核心能力为什么有“体感”：每一步都能验证

单看菜单，模型、算法、任务、事件似乎只是几个常见的管理模块。真正用起来后，差异在于每一步都有可以观察和验证的结果，而不是配置完成后只能等待后台运行。

1. 配置算法时，检测标准就是业务语言

业务人员可以直接描述检测目标、成立条件和排除条件，再绑定已经接入的视觉大模型。提示词可以从模板库复用，也可以继续调整，不需要为了修改一句判断标准重新开发和发布服务。

很多项目把 Prompt 散落在代码或配置文件里，时间一长就说不清哪个版本在线、改动有没有验证。这里把模型、提示词、算法编码、上下架状态和测试入口放在一起，提示词才真正变成了一项可以维护的算法资产。

2. 测试算法时，不只看结果，还能看判断依据

算法测试会把告警判断、数量、置信度、坐标和说明完整展示出来。坐标可以画回原图，说明文字则帮助确认模型是否真的理解了检测要求。

例如模型虽然给出了“存在明火”，但目标框落在屏幕或反光区域，问题就不一定是阈值，而可能是提示词缺少排除条件。看见框和说明之后，调优方向会比只看一个布尔值清楚得多。

3. 用检测区和屏蔽区减少无效告警

真实监控画面里，长期存在的屏幕、窗户反光、道路和固定设备都可能制造误报。完整版本因此增加了“检测区 + 屏蔽区”的场景治理能力。配置时可以直接在画面上绘制多边形：蓝色区域表示需要重点分析的检测区，红色区域表示需要忽略的屏蔽区，同一条规则可以同时包含两类区域。

在画面上圈选区域比手写坐标更直观，规则调整后也能马上回到原图核对。

配置完成后，两类区域各自承担不同作用：

• 检测区：标记需要重点关注的范围，命中后按配置的规则进行告警；
• 屏蔽区：排除无需关注或容易造成干扰的范围，识别结果落入其中时不生成最终告警。

下面这张图展示了区域规则的判断效果：检测结果没有落入红色屏蔽区域，因此仍然可以按正常规则处理。屏蔽针对的是指定范围，不会影响画面中其他区域的检测。

这种方式的价值在于，使用者只需要从业务角度划定“需要关注”和“无需关注”的范围，就能减少固定干扰区域带来的无效告警，不必改变原有算法。

需要明确说明：场景治理、组织机构和设备组织树目前不在开源版范围内。这一部分展示的是完整版本能力，也可以作为开源版二次开发的方向。开源版已经具备坐标输出、设备点位、任务和事件记录，增加区域规则时不需要重做整条数据链路。

4. 用左右点火对照，直接验证屏蔽规则

场景治理是否有效，不能只看配置页面。我们做了一个很直观的对照实验：先把画面右半边设为屏蔽区，再分别在左右两侧点火。

先在左侧非屏蔽区域点火。火焰出现在需要检测的范围内，模型识别结果通过区域复核，应当正常形成告警事件。

再保持算法和摄像头不变，改到右侧屏蔽区域点火。即使识别到火焰，也不会生成最终告警。

验证逻辑很简单：

1. 左侧属于非屏蔽区，出现明火后应正常产生告警；
2. 右侧属于屏蔽区，即使模型识别到火焰，也不应生成最终告警；
3. 最终只保留左侧事件，并在详情中记录图片、点位、任务、算法、耗时、置信度和文字说明。

这个对照比“误报率降低”更有体感：同样的火焰、同一个算法，只改变点位规则，就能看到最终事件是否产生。

5. 事件不是终点，而是下一轮优化的依据

事件中心保留任务、设备、算法、结果图、耗时、置信度和自然语言说明。运维人员可以据此区分模型误判、提示词不完整、点位不合适或区域规则不合理，再把复盘结果反馈到算法和任务配置中。

于是整条链路形成了真正的闭环：

配置算法 → 单图验证 → 绑定点位 → 连续分析 ↑ ↓ 调整提示词与规则 ← 复盘事件 ← 告警留痕

从工程角度看，三个值得复用的设计

模型、算法、任务三层解耦

模型回答“底层调用谁”，算法回答“检测什么、按什么格式输出”，任务回答“在哪些设备上、多久执行一次”。更换模型时不必重新建设任务，同一算法也可以复用到多个设备。

媒体服务单独拆分

视频流连接、重连、取帧和快照属于持续运行、容易受网络波动影响的工作。将它与 Web API 分开后，职责更清楚，后续扩容也更自然。

告警结果异步进入事件中心

任务执行与事件落库通过 Kafka 解耦。测试结果、任务执行日志、告警截图和事件记录组成连续链路，既方便排查“为什么没告警”，也为后续统计效果、优化提示词和接入通知系统提供数据基础。

当前版本的边界也要说清楚

这个项目适合拿来搭底座、做二次开发，但不是下载后就自带全部 AI 能力的成品盒子：

• 项目不包含视觉大模型、推理显卡或第三方 API Key，需要自行准备 OpenAI 兼容的多模态模型服务；
• 当前最完整的执行链路是大模型语义算法；vision小模型类型已经预留模型格式和推理地址，但真实推理调用仍是占位实现；
• 开源版没有场景治理、组织机构等企业治理模块；
• RTSP 可以由媒体服务接入和截帧，但浏览器直接预览需要额外转码；
• Docker Compose 更适合体验、测试和中小规模私有化部署，生产环境还需要结合监控、备份、网络和安全策略做调整。

把这些边界写在前面，反而更容易判断它是否适合自己的项目。

适合哪些人

如果你正在做下面几类事情，这个仓库会比较有参考价值：

• 想把视觉大模型从单图 Demo 做成持续运行的监控任务；
• 需要统一管理模型、提示词算法、摄像头和告警记录；
• 希望有一套 Spring Boot + Vue 3 的视觉平台脚手架；
• 需要私有化部署，并准备对接自己的模型或业务系统；
• 想研究如何把“模型识别”工程化成“任务与事件闭环”。

如果你的需求只是调用一次模型 API，直接写脚本会更轻；如果需要成熟的组织权限、复杂场景治理和大规模生产运维，则要在开源版基础上继续开发。

最后

Vision Hub Platform 最吸引我的地方，不是功能数量，而是它把一条容易散落在多个脚本和服务里的视觉 AI 链路放到了一起：模型可配置、算法可测试、设备可接入、任务可调度、结果可追溯。

对于想理解视觉大模型怎样进入真实业务流程的人，它是一个比“上传图片看结果”更进一步的开源样例。建议先用 Docker Compose 跑起来，再从一个简单场景开始：接一个模型、写一条提示词、测几张图片、绑定一路视频流。等这条最小链路跑通，再考虑区域治理、消息通知和行业模板，节奏会顺很多。

项目地址：https://github.com/zj-unicom-ai/vision-hub-platform