把摄像头、视觉大模型和告警闭环串起来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. 先接入一个视觉大模型进入“算法仓库 → 大模型管理”新增模型主要填写供应商和模型类型模型 IDAPI 地址与 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。页面会同时呈现原始素材、画框后的结果图、告警判断、目标数量、置信度、归一化坐标和自然语言说明。业务人员能直接看到模型为什么这样判断也能据此继续调整提示词而不用在日志和接口响应之间来回切换。从使用体验上看它形成了一个很短的闭环自然语言定义检测标准 ↓ 上传样本立即测试 ↓ 查看结构化结果与目标框 ↓ 修改提示词后再次验证实际调试时我会至少准备三类图片明确应该告警的正样本外观相似但不应告警的负样本低照度、遮挡、反光等边界样本。如果模型经常把灯光或海报误判成火焰优先把排除条件写进提示词再重新测试。这个“配置 → 测试 → 调整”的小闭环比把问题留到摄像头任务上线后再排查省事得多。4. 接入摄像头或视频流进入“设备接入”填写设备名称、编码、接入协议和视频流地址。媒体服务会负责建立连接、维护帧缓冲并按需输出快照。需要注意浏览器不能直接播放原生 RTSP。前端页面可以直接预览适合浏览器播放的 HLS/FLV 流RTSP 仍可交给媒体服务拉流和截帧。如果希望在浏览器中实时预览 RTSP通常还需要在前面增加转码或流媒体网关。5. 创建任务把算法、设备和周期绑在一起任务配置里选择算法为每个算法设置采样周期和事件名称再添加需要分析的设备点位。保存后可以直接启动任务。图片来自完整版本演示界面开源版保留算法、采样周期、事件名称和设备点位等主链路图中的场景治理入口不在当前开源范围。任务启动后调度器会按固定间隔并行处理关联设备从媒体服务取帧将快照保存到 MinIO调用算法只有当结构化结果中的isAlarm为true时才会向 Kafka 发送告警消息并生成事件记录。这里把“算法测试”和“连续任务”分成两个入口很实用前者解决算法有没有效果后者解决算法如何长期、稳定地跑在多个点位上。6. 在事件中心查看结果事件中心不是简单的运行日志。它可以按事件名称、时间、任务、设备点位和算法等条件筛选并用带截图的卡片呈现命中的事件。下面是老鼠检测产生的事件记录同类事件被集中沉淀可以先通过截图快速浏览再进入单条事件核查。点进单条事件后可以看到告警图片、任务、算法、推理耗时、置信度和自然语言说明。下面是一次老鼠检测的事件详情这一步让视觉识别不再是一段“模型返回的 JSON”而是变成可查询、可复盘、可导出的业务记录。后续如果要对接短信、企业微信、工单或应急处置流程也有了统一的事件入口。核心能力为什么有“体感”每一步都能验证单看菜单模型、算法、任务、事件似乎只是几个常见的管理模块。真正用起来后差异在于每一步都有可以观察和验证的结果而不是配置完成后只能等待后台运行。1. 配置算法时检测标准就是业务语言业务人员可以直接描述检测目标、成立条件和排除条件再绑定已经接入的视觉大模型。提示词可以从模板库复用也可以继续调整不需要为了修改一句判断标准重新开发和发布服务。很多项目把 Prompt 散落在代码或配置文件里时间一长就说不清哪个版本在线、改动有没有验证。这里把模型、提示词、算法编码、上下架状态和测试入口放在一起提示词才真正变成了一项可以维护的算法资产。2. 测试算法时不只看结果还能看判断依据算法测试会把告警判断、数量、置信度、坐标和说明完整展示出来。坐标可以画回原图说明文字则帮助确认模型是否真的理解了检测要求。例如模型虽然给出了“存在明火”但目标框落在屏幕或反光区域问题就不一定是阈值而可能是提示词缺少排除条件。看见框和说明之后调优方向会比只看一个布尔值清楚得多。3. 用检测区和屏蔽区减少无效告警真实监控画面里长期存在的屏幕、窗户反光、道路和固定设备都可能制造误报。完整版本因此增加了“检测区 屏蔽区”的场景治理能力。配置时可以直接在画面上绘制多边形蓝色区域表示需要重点分析的检测区红色区域表示需要忽略的屏蔽区同一条规则可以同时包含两类区域。在画面上圈选区域比手写坐标更直观规则调整后也能马上回到原图核对。配置完成后两类区域各自承担不同作用检测区标记需要重点关注的范围命中后按配置的规则进行告警屏蔽区排除无需关注或容易造成干扰的范围识别结果落入其中时不生成最终告警。下面这张图展示了区域规则的判断效果检测结果没有落入红色屏蔽区域因此仍然可以按正常规则处理。屏蔽针对的是指定范围不会影响画面中其他区域的检测。这种方式的价值在于使用者只需要从业务角度划定“需要关注”和“无需关注”的范围就能减少固定干扰区域带来的无效告警不必改变原有算法。需要明确说明场景治理、组织机构和设备组织树目前不在开源版范围内。这一部分展示的是完整版本能力也可以作为开源版二次开发的方向。开源版已经具备坐标输出、设备点位、任务和事件记录增加区域规则时不需要重做整条数据链路。4. 用左右点火对照直接验证屏蔽规则场景治理是否有效不能只看配置页面。我们做了一个很直观的对照实验先把画面右半边设为屏蔽区再分别在左右两侧点火。先在左侧非屏蔽区域点火。火焰出现在需要检测的范围内模型识别结果通过区域复核应当正常形成告警事件。再保持算法和摄像头不变改到右侧屏蔽区域点火。即使识别到火焰也不会生成最终告警。验证逻辑很简单左侧属于非屏蔽区出现明火后应正常产生告警右侧属于屏蔽区即使模型识别到火焰也不应生成最终告警最终只保留左侧事件并在详情中记录图片、点位、任务、算法、耗时、置信度和文字说明。这个对照比“误报率降低”更有体感同样的火焰、同一个算法只改变点位规则就能看到最终事件是否产生。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 把摄像头、视觉大模型和告警闭环串起来：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. 先接入一个视觉大模型进入“算法仓库 → 大模型管理”新增模型主要填写供应商和模型类型模型 IDAPI 地址与 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。页面会同时呈现原始素材、画框后的结果图、告警判断、目标数量、置信度、归一化坐标和自然语言说明。业务人员能直接看到模型为什么这样判断也能据此继续调整提示词而不用在日志和接口响应之间来回切换。从使用体验上看它形成了一个很短的闭环自然语言定义检测标准 ↓ 上传样本立即测试 ↓ 查看结构化结果与目标框 ↓ 修改提示词后再次验证实际调试时我会至少准备三类图片明确应该告警的正样本外观相似但不应告警的负样本低照度、遮挡、反光等边界样本。如果模型经常把灯光或海报误判成火焰优先把排除条件写进提示词再重新测试。这个“配置 → 测试 → 调整”的小闭环比把问题留到摄像头任务上线后再排查省事得多。4. 接入摄像头或视频流进入“设备接入”填写设备名称、编码、接入协议和视频流地址。媒体服务会负责建立连接、维护帧缓冲并按需输出快照。需要注意浏览器不能直接播放原生 RTSP。前端页面可以直接预览适合浏览器播放的 HLS/FLV 流RTSP 仍可交给媒体服务拉流和截帧。如果希望在浏览器中实时预览 RTSP通常还需要在前面增加转码或流媒体网关。5. 创建任务把算法、设备和周期绑在一起任务配置里选择算法为每个算法设置采样周期和事件名称再添加需要分析的设备点位。保存后可以直接启动任务。图片来自完整版本演示界面开源版保留算法、采样周期、事件名称和设备点位等主链路图中的场景治理入口不在当前开源范围。任务启动后调度器会按固定间隔并行处理关联设备从媒体服务取帧将快照保存到 MinIO调用算法只有当结构化结果中的isAlarm为true时才会向 Kafka 发送告警消息并生成事件记录。这里把“算法测试”和“连续任务”分成两个入口很实用前者解决算法有没有效果后者解决算法如何长期、稳定地跑在多个点位上。6. 在事件中心查看结果事件中心不是简单的运行日志。它可以按事件名称、时间、任务、设备点位和算法等条件筛选并用带截图的卡片呈现命中的事件。下面是老鼠检测产生的事件记录同类事件被集中沉淀可以先通过截图快速浏览再进入单条事件核查。点进单条事件后可以看到告警图片、任务、算法、推理耗时、置信度和自然语言说明。下面是一次老鼠检测的事件详情这一步让视觉识别不再是一段“模型返回的 JSON”而是变成可查询、可复盘、可导出的业务记录。后续如果要对接短信、企业微信、工单或应急处置流程也有了统一的事件入口。核心能力为什么有“体感”每一步都能验证单看菜单模型、算法、任务、事件似乎只是几个常见的管理模块。真正用起来后差异在于每一步都有可以观察和验证的结果而不是配置完成后只能等待后台运行。1. 配置算法时检测标准就是业务语言业务人员可以直接描述检测目标、成立条件和排除条件再绑定已经接入的视觉大模型。提示词可以从模板库复用也可以继续调整不需要为了修改一句判断标准重新开发和发布服务。很多项目把 Prompt 散落在代码或配置文件里时间一长就说不清哪个版本在线、改动有没有验证。这里把模型、提示词、算法编码、上下架状态和测试入口放在一起提示词才真正变成了一项可以维护的算法资产。2. 测试算法时不只看结果还能看判断依据算法测试会把告警判断、数量、置信度、坐标和说明完整展示出来。坐标可以画回原图说明文字则帮助确认模型是否真的理解了检测要求。例如模型虽然给出了“存在明火”但目标框落在屏幕或反光区域问题就不一定是阈值而可能是提示词缺少排除条件。看见框和说明之后调优方向会比只看一个布尔值清楚得多。3. 用检测区和屏蔽区减少无效告警真实监控画面里长期存在的屏幕、窗户反光、道路和固定设备都可能制造误报。完整版本因此增加了“检测区 屏蔽区”的场景治理能力。配置时可以直接在画面上绘制多边形蓝色区域表示需要重点分析的检测区红色区域表示需要忽略的屏蔽区同一条规则可以同时包含两类区域。在画面上圈选区域比手写坐标更直观规则调整后也能马上回到原图核对。配置完成后两类区域各自承担不同作用检测区标记需要重点关注的范围命中后按配置的规则进行告警屏蔽区排除无需关注或容易造成干扰的范围识别结果落入其中时不生成最终告警。下面这张图展示了区域规则的判断效果检测结果没有落入红色屏蔽区域因此仍然可以按正常规则处理。屏蔽针对的是指定范围不会影响画面中其他区域的检测。这种方式的价值在于使用者只需要从业务角度划定“需要关注”和“无需关注”的范围就能减少固定干扰区域带来的无效告警不必改变原有算法。需要明确说明场景治理、组织机构和设备组织树目前不在开源版范围内。这一部分展示的是完整版本能力也可以作为开源版二次开发的方向。开源版已经具备坐标输出、设备点位、任务和事件记录增加区域规则时不需要重做整条数据链路。4. 用左右点火对照直接验证屏蔽规则场景治理是否有效不能只看配置页面。我们做了一个很直观的对照实验先把画面右半边设为屏蔽区再分别在左右两侧点火。先在左侧非屏蔽区域点火。火焰出现在需要检测的范围内模型识别结果通过区域复核应当正常形成告警事件。再保持算法和摄像头不变改到右侧屏蔽区域点火。即使识别到火焰也不会生成最终告警。验证逻辑很简单左侧属于非屏蔽区出现明火后应正常产生告警右侧属于屏蔽区即使模型识别到火焰也不应生成最终告警最终只保留左侧事件并在详情中记录图片、点位、任务、算法、耗时、置信度和文字说明。这个对照比“误报率降低”更有体感同样的火焰、同一个算法只改变点位规则就能看到最终事件是否产生。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