七月小站

在混合云协作和本地开发中，安全且稳定地访问远程私有 API 是一项常见需求。本文介绍一套基于 Go 语言实现的通用网络中继与 API 反代网关系统。该系统由中继服务（svc.go，服务端）与网关通道（main.go，客户端）两部分组成，支持 SSH 动态通道自愈、Windows 系统后台服务集成以及防超时长连接保活。 系统整体架构设计系统通过本地客户端拦截并分流流量，进行协议转换，随后通过 SSH 动态隧道进行加密中转： flowchart TD App["💻 本地应用 / 客户端 (IDE / 终端 / 浏览器)"] -->|HTTP CONNECT 代理握手| GW subgraph ClientGW["1. 客户端网关 (Clink Gateway)"] GW["分流决策引擎"] GW -->|API 专用路径| APIGW["API 反向代理网关 (长连接保活/请求头重写)"]...

前言在很多商业和工业场景中，“目标检测”往往只是第一步。比如在景区、商场或交通路口，仅仅知道“画面里有多少人和车”是不够的，客户通常需要更精确的数据： “今天有多少人进入了商场，多少人离开了？” “这个路口从左往右开过去了多少辆车？” 要实现这种统计，我们需要把 目标检测（Object Detection） 升级为 多目标跟踪（Multi-Object Tracking, MOT） ，并在帧与帧之间记住每一个目标的身份（ID）。 本文将带你使用 YOLO (v8/v11) 与当前最前沿的 ByteTrack 跟踪算法 ，配合巧妙的几何数学计算，从零实现一个 人流与车流双向越界实时计数系统 。 一、核心技术原理1. 为什么选择 ByteTrack？传统的跟踪算法（如 DEEPSORT）依赖昂贵的外观特征提取网络，不仅运行慢，而且在目标被遮挡时容易丢失 ID。 ByteTrack （发表于 ECCV 2022）的核心思想非常优雅： “不放弃低置信度的检测框” 。 第一步（Association 1） ：在高置信度检测框中与已有的跟踪轨迹进行匹配。 第二步（Assoc...

前言上一篇文章讲了怎么用预训练的 YOLO 模型做检测。如果你的检测对象不在 COCO 的 80 个类别里——比如你想检测 PCB 板上的焊点缺陷、仓库里的特定货品、或者工地上的安全帽佩戴——就需要自己训练模型。 这篇文章从头到尾走一遍流程：标注数据、训练模型、评估效果、导出部署。 一、场景定义在开始标注之前，先把问题定义清楚： 要检测哪些类别？（比如：安全帽、反光背心、安全鞋） 一个画面里通常有几个目标？（确定数据采集量） 有没有特殊情况？（遮挡、光线差、小目标） 精度要求多高？（实时场景 mAP50 > 0.9，辅助分析 0.7 可能就够用） 二、数据标注工具选择 工具 特点 适合 LabelImg 轻量，单机运行 个人、少量数据 Label Studio Web 界面，团队协作 团队标注 Roboflow 在线平台，含数据增强和版本管理 快速原型、小团队 CVAT 功能最全，支持视频标注 专业标注团队 推荐个人和小团队用 LabelImg 或 Roboflow。 标注流程（以 LabelImg 为例）12pip install lab...

前言YOLO（You Only Look Once）是目标检测领域最知名的模型系列。它能在一张图中同时检测出多个物体——人、车、猫、杯子——标出位置并给出类别名称。 这篇文章的目标是让你半小时内从零到跑通第一个 YOLO 检测程序。 一、YOLO 是什么与底层检测流水线YOLO 的核心思想很简单：只看一次（You Only Look Once）。传统检测方法需要对图片进行密集的滑动窗口扫描或候选区域生成（如 R-CNN），YOLO 把整张图一次性输入全卷积神经网络，直接端到端回归预测所有目标的坐标与类别： flowchart LR Input["输入原始图像 (640x640)"] --> Backbone["Backbone 骨干网络<br/>(卷积特征提取层)"] Backbone --> Neck["Neck 特征融合网络<br/>(PAN-FPN 多尺度特征金字塔)"] Neck --> Head["Hea...

前言在中国的安防视频监控和智慧城市建设中， GB/T 28181 协议 （全称《安全防范视频监控联网系统信息传输、交换、控制技术要求》）是唯一的统治级国家标准。无论是小区的监控摄像头，还是交警的违章抓拍系统，亦或是各级公安机关的“雪亮工程”视频平台，要实现跨厂家、跨区域的视频互联互通，都必须遵循 GB/T 28181 标准。 对于开发人员来说，GB/T 28181 几乎是国内“最难啃”的视频物联网标准之一。它融合了电信级信令协议 SIP（会话发起协议） ，并对多媒体流强制采用了特化的 MPEG-PS（节目流） 封装。 本文将从 GB/T 28181 的体系架构出发，以手把手的方式，深入底层报文和字节结构，并结合目前业界最火的主流开源框架，为你奉献一份全方位的国标接入与排错指南。 一、GB/T 28181 演进与两层分离架构1. 国标版本的演进史GB/T 28181 从诞生至今经历了几次重大修订： 2011 版 (GB/T 28181-2011) ：奠定基石，确立了 SIP 协议控制面 + RTP/...

前言随着两客一危（旅游客运、包车客运、三类以上班线客运和危险货物运输）安全监管力度的不断加大，单纯的位置汇报（JT/T 808 协议）已经无法满足行业监管和企业主动安全防范（如 ADAS 驾驶辅助、DSM 疲劳驾驶监测）的需求。如何在定位车辆的同时，实时调取车载摄像头画面、进行历史视频回放以及下发语音对讲？ 为此，交通运输部推出了 JT/T 1078 协议（全称《道路运输车辆卫星定位系统视频通信协议》）。它是 JT/T 808 协议的音视频扩展版。 对于车联网开发者来说，JT/T 1078 引入了全新的流媒体处理架构，比 808 协议更为复杂。本文将为你全面剖析 JT/T 1078 的双链架构、控制信令、1078 特化的 RTP 报文结构，以及如何从零设计一个高性能的 1078 流媒体分发网关。 一、JT/T 1078 的“信令+媒体”双链架构JT/T 1078 并不能脱离 JT/T 808 独立运行。它的核心思想是：“信令走 808 链路，媒体流走独立 1078 链路”。 flowcha...

前言在车联网与两客一危（旅游客运、班线客运、危险品运输）监管领域，JT/T 808 协议（全称《道路运输车辆卫星定位系统终端通讯协议及数据格式》）是绝对的行业基石。无论是公交车、出租车、网约车，还是重型货车，其车载定位终端（GPS/北斗定位仪）与省级/部级监管平台之间的所有数据交互，几乎都遵循这一标准。 作为物联网或车联网方向的开发者，深入理解 JT/T 808 协议的设计理念、数据结构及编解码细节，是开发高性能车辆监控系统的必备技能。本文将从协议基础、帧结构、核心业务交互以及实战开发编解码四个方面，带你彻底攻克 JT/T 808 协议。 一、协议背景与通信基础1. 协议定位JT/T 808 是交通运输部发布的推荐性行业标准。主要解决了不同厂商的车载终端如何接入统一的监控平台，并向平台上报位置、速度、报警状态等实时数据，同时接收平台的下发指令（如拍照、参数设置、单向监听等）。 2. 通信方式 网络层/传输层：协议支持 TCP 和 UDP 传输，在实际生产环境中，由于定位数据和报警数据的可靠性要求，绝大多数采用...

前言：从“拧螺丝的工人”到“全能外包项目经理”大语言模型（LLM）的发展经历了一次明显的范式转变：从“单次问答（Prompt Engineering）”，到“工具调用（Tool Calling）”，再到如今万众瞩目的“自主智能体（Autonomous Agent）”。 为了彻底搞清楚这三者的本质差别，让我们把开发场景比喻成一个工地的施工作业： 单次问答阶段（听天由命的参谋）：你问他：“墙上螺丝松了怎么办？”他会给你长篇大论列出 10 种拧螺丝的方法。但是他没有手，无法帮你拧，一切还是需要你亲自操刀。 工具调用阶段（按一下动一下的螺丝工）：大模型被装上了一只机械臂（Tool Calling 接口）。你对他说：“用 3 号螺丝刀，把那颗松了的螺丝拧紧（Action）。”他会抓起螺丝刀拧一下，然后立刻停下来盯着你，等待你输入下一道口令。如果你不发令，他就永远静止。 自主智能体阶段（全能外包项目经理）：你甚至不需要提“螺丝”这两个字。你只需要给他一个宏观的任务总目标：“去把 3 号房间的漏水和设备老化问题彻底修好（Goal）。”这个 Agent 不会马上盲目动手，而是会成为一个极其冷静...

前言Ollama 适合个人使用，但当你要在生产环境提供 API 服务时——高并发、低延迟、高吞吐——就需要专业的推理框架了。 目前开源社区主流的两个选择是 vLLM（GPU 推理）和 llama.cpp（CPU/GPU 通用推理）。这篇文章讲清楚它们分别怎么用，以及怎么选。 一、高并发推理架构与原理在单机或集群部署大模型服务时，最核心的诉求是高吞吐（Throughput）与低首字延迟（TTFT, Time To First Token）。 flowchart TD Client["高并发业务端 (Web / App / Agent)"] --> Nginx["Nginx / 负载均衡网关<br/>(HTTPS / 限流 / 鉴权)"] subgraph Cluster["vLLM 高性能推理引擎"] Nginx --> Engine["OpenAI 兼容 HTTP API ...

前言：当顶级“外包专家”遇到你的“屎山代码”想象一下，你的团队刚刚通过高薪招募了一位极度聪明的资深软件工程师。他精通几乎所有的现代编程语言，能在几秒钟内理解复杂的算法，并且写代码的速度比常人快上百倍。 但是，他有一个致命的弱点： 他对你们公司的业务细节、特殊的代码库规范、历史包袱以及部署流程一无所知。 如果你直接对他说：“去把我们的商品管理模块的 React 组件重构一下，然后顺便把数据库表更新了，搞完发布到测试环境。” 他可能会写出非常优秀的代码，但极大概率会发生以下灾难： 他用了团队早已废弃的第三方状态管理库； 他把全局组件的命名空间搞乱了，完全不符合团队的驼峰命名规范； 他在修改数据库表时，直接在主库上跑了 DDL 导致锁表，且完全没有准备回滚脚本； 部署测试环境时，由于不了解你们的 CI/CD 流程，漏掉了核心的环境变量校验。 这正是我们每天调教大模型（LLM）或使用 AI 编程助手（如 Cursor、Claude Code 等）时面临的尴尬现状。AI 的通用能力极强，但它缺乏 “局部约束与企业规范” 。 在传统的开发流程中，我们靠什么来约束新员工？答案是 ...