+
+
← 返回知识库
+
AI 核心技能原理说明
+
系统梳理大模型应用开发的关键技术原理，涵盖从基础模型到上层应用的完整技术栈。
+
+
+ LLM 基础Prompt EngineeringAgent 架构
+ Skills 编排RAG 知识库AI CodingYOLO 视觉
+
+
+
+
大语言模型（LLM）基础
+
+
核心原理
+
+ - Transformer 架构：所有现代 LLM 的基础。核心是 Self-Attention 机制——每个 token 计算与序列中所有其他 token 的相关性权重，并行处理，突破 RNN 的串行瓶颈，解决长距离依赖问题。
+
+
+
训练三阶段
+
+ - Pre-training（预训练）：海量语料上做 Next Token Prediction，学习语言的统计规律和世界知识
+ - SFT（监督微调）：用高质量指令-回答对训练，让模型学会"对话"
+ - RLHF（人类反馈强化学习）：用人类偏好数据训练奖励模型，再用 PPO 优化，对齐人类价值观。解决"模型能力强但不一定听话"的对齐问题
+
+
+
关键概念
+
+ | 概念 | 说明 |
|---|
+
+ | Token | 模型处理的最小文本单元，中文约 1.5-2 字符/token |
+ | Context Window | 模型一次能处理的 token 上限（如 128K、200K） |
+ | Temperature | 控制输出随机性，0 = 确定性，1 = 高随机 |
+ | Top-P / Top-K | 采样策略，限制候选 token 范围，平衡多样性与质量 |
+
+
+
+
主流模型对比
+
+ | 模型 | 特点 | 适用场景 |
|---|
+
+ | GPT-4o | 多模态，综合能力最强 | 复杂推理、多模态任务 |
+ | Claude 4 | 长上下文 200K，安全性高，代码能力强 | 长文档分析、代码生成 |
+ | DeepSeek-V3 | 开源，MoE 架构，性价比极高 | 国内部署、成本敏感场景 |
+ | 通义千问 | 中文优化，阿里云生态深度集成 | 政务、企业中文场景 |
+
+
+
+
+
Prompt Engineering
+
+
核心方法论
+
+ | 技术 | 原理 | 示例 |
|---|
+
+ | Zero-shot | 不给示例，直接提问 | "将以下文本分类为正面/负面：..." |
+ | Few-shot | 给 2-5 个示例，模型学习输入输出模式 | 示例 1 → 示例 2 → 新输入 |
+ | CoT（思维链） | 要求模型"一步步思考"，激活推理能力 | "让我们一步步分析：首先...其次..." |
+ | 结构化输出 | 约束输出格式（JSON / XML） | "请以 JSON 格式返回，包含 name、age 字段" |
+ | Self-Consistency | 多次采样 + 投票，提升推理准确率 | 同一问题跑 5 次，取多数答案 |
+
+
+
+
为什么 CoT 有效
+
+ - LLM 是自回归的——每个 token 基于前文生成
+ - 写出推理过程 = 给模型更多"思考空间"，中间步骤的 token 约束了后续输出的方向
+ - 复杂推理任务（数学、逻辑）中 CoT 可将准确率从 ~20% 提升到 ~80%
+
+
+
Function Calling 原理
+
+ - 定义函数的 JSON Schema（函数名、参数、描述）
+ - 模型判断用户意图 → 返回函数名 + 结构化参数（而非自然语言）
+ - 应用层执行函数 → 结果回传模型 → 模型生成最终回复
+ - 本质：让模型"学会"输出结构化指令，模型不直接调用函数，而是输出参数由应用层执行
+
+
+
+
Agent 智能体
+
+
核心架构：ReAct 循环
+
用户输入 → Agent Core（LLM）
+ │
+ ├─ 规划（Plan）
+ ├─ 调用工具（Tool Use）
+ ├─ 观察结果（Observation）
+ ├─ 反思调整（Reflection）
+ └─ 循环直到目标达成 → 输出
+
+
关键设计模式
+
+ | 模式 | 原理 | 适用场景 |
|---|
+
+ | ReAct | Reasoning + Acting 交替：思考一步 → 执行一步 → 观察 → 再思考 | 需要与外部交互的任务 |
+ | Plan-and-Execute | 先生成完整计划，再逐步执行 | 复杂多步任务 |
+ | Multi-Agent | 多个 Agent 分工协作，各司其职 | 跨领域复杂流程 |
+
+
+
+
多 Agent 协作
+
+ - 分工原则：每个 Agent 有明确角色和工具集，互不越界
+ - 通信方式：共享内存/消息队列（Agent A 输出 → Agent B 输入）、中央调度器（Orchestrator 统一分发任务、汇总结果）
+ - 冲突仲裁：定义优先级规则或由调度 Agent 决策
+
+
+
安全护栏（Guardrails）
+
+ - 输入护栏：敏感词过滤、注入攻击检测
+ - 输出护栏：内容合规校验、事实性核查
+ - 行为护栏：限制可调用的工具范围、设置最大循环次数防止死循环
+
+
+
+ Agent vs 普通 LLM 调用：Agent 的核心区别在于拥有自主规划 + 工具调用 + 循环决策能力，不是一次问答，而是多步自主完成任务。
+
+
+
+
Skills 编排系统
+
+
设计理念
+
将业务能力封装为标准化、可复用的 Skill 模块，由 LLM 根据用户意图自动选择并编排执行。
+
+
架构流程
+
用户输入
+ ↓
+意图识别（LLM）
+ ↓
+Skill 路由（语义匹配最相关的 Skill 组合）
+ ↓
+编排执行（串行 / 并行 / 条件分支）
+ ↓
+结果聚合 → 输出
+
+
Skill 定义规范
+
{
+ "name": "report_generator",
+ "description": "根据查询条件生成业务报表",
+ "parameters": {
+ "report_type": "销售报表 / 库存报表 / 财务报表",
+ "date_range": "起止日期",
+ "format": "PDF / Excel"
+ },
+ "auth_required": true
+}
+
+
关键机制
+
+ | 机制 | 说明 |
|---|
+
+ | 热加载 | Skill 注册/下线不重启系统，通过配置中心或数据库动态生效 |
+ | 自动路由 | LLM 用语义匹配（Embedding 相似度）找到最相关的 Skill |
+ | 依赖解析 | Skill A 的输出可能是 Skill B 的输入，编排引擎自动处理依赖顺序 |
+ | 降级策略 | 首选 Skill 不可用时，自动回退到备选方案或转人工 |
+
+
+
+
+ 与 Function Calling 的关系：Skills 编排是更高层的抽象，一个 Skill 可能包含多个 Function Call。类比：Skills 编排 ≈ 微服务 + API 网关 + 服务编排，只是"路由规则"由 LLM 动态决定。
+
+
+
+
知识库（RAG）系统
+
+
为什么需要 RAG
+
+ - LLM 训练数据有截止日期，无法回答最新问题
+ - LLM 可能产生幻觉（编造不存在的事实）
+ - 企业私有数据不能用于训练公共模型
+ - RAG = 检索（Retrieve）+ 增强（Augment）+ 生成（Generate）
+
+
+
核心流程
+
文档入库（离线）：
+ 原始文档 → 解析 → 分块 → Embedding → 存入向量数据库
+
+在线问答：
+ 用户提问 → Embedding → 向量检索（Top-K）→ 拼接 Prompt → LLM 生成 → 返回
+
+
分块策略（Chunking）
+
+ | 策略 | 适用场景 | 优缺点 |
|---|
+
+ | 固定长度 | 通用场景 | 实现简单但可能切断语义 |
+ | 语义分块 | 长文档 | 按段落/章节切分，语义完整 |
+ | 滑动窗口 | 需要上下文 | 相邻块有重叠，避免信息断裂 |
+
+
+
+
Embedding 模型选择
+
+ - 中文：bge-large-zh、text2vec-large-chinese、m3e
+ - 多语言：text-embedding-3-large（OpenAI）、bge-m3
+ - Embedding 本质：将文本映射到高维向量空间，语义相近的文本向量距离近
+
+
+
检索优化
+
+ | 技术 | 说明 |
|---|
+
+ | 混合检索 | 语义检索（向量）+ 关键词检索（BM25）加权融合，提升召回率 |
+ | Rerank | 粗召回后用精排模型重排序，提升 Top-N 精度 |
+ | 元数据过滤 | 按时间/分类/权限等结构化字段预过滤，缩小检索范围 |
+
+
+
+
+
AI Coding
+
+
主流工具原理
+
+ | 工具 | 底层原理 | 特点 |
|---|
+
+ | Claude Code | Claude 模型 + 工具调用（文件读写/Shell/搜索），Agent 模式自主执行 | 复杂任务拆解，长期上下文 |
+ | GitHub Copilot | Codex 模型，实时上下文（当前文件+相邻Tab+项目结构）补全 | IDE 深度集成，毫秒级响应 |
+ | Cursor | 多模型支持，全文件上下文编辑，Composer 模式 | 重构友好，Diff 预览 |
+ | Aider | CLI 工具，Git 集成，Map-Reduce 处理大代码库 | 终端场景，可脚本化 |
+
+
+
+
三种工作模式
+
+ - 补全模式：根据光标上下文，实时续写代码（Copilot 类）
+ - 对话模式：自然语言描述需求 → AI 生成/修改代码（Cursor / Claude Code）
+ - Agent 模式：AI 自主规划 → 读写文件 → 执行命令 → 检查结果 → 迭代修复（Claude Code）
+
+
+
工程化实践
+
+ - 小步提交：每次 AI 修改控制在 200 行 diff 以内，便于 Review 和回滚
+ - 测试驱动：先让 AI 写测试，再写实现——"测试是 AI 的 spec"
+ - 代码审查：AI 生成代码必须人工 Review，重点关注边界条件和安全问题
+ - 上下文质量：清晰的上下文（项目结构 + 技术栈 + 编码规范）大幅提升 AI 输出质量
+
+
+
+
AI 视觉（YOLO）
+
+
核心思想
+
+ - You Only Look Once：将目标检测转化为回归问题
+ - 输入图片 → 单次 CNN 前向传播 → 同时输出边界框 + 类别概率
+ - 相比 R-CNN 系列的两阶段方法（先提候选区 → 再分类），YOLO 更快，适合实时场景
+
+
+
演进路线
+
+ | 版本 | 关键改进 | 年份 |
|---|
+
+ | YOLOv5 | 工程化最成熟，社区生态好 | 2020 |
+ | YOLOv8 | 无锚框检测，多任务（检测/分割/姿态）统一框架 | 2023 |
+ | YOLOv10 | NMS-Free，端到端，效率进一步提升 | 2024 |
+
+
+
+
训练部署流程
+
数据采集 → 标注（LabelImg / LabelStudio）→ 数据集划分（训练/验证/测试）
+ → 数据增强（翻转/旋转/色彩抖动/Mosaic）
+ → 模型训练（预训练权重微调）
+ → 模型转换（ONNX / TensorRT）
+ → 边缘/服务端部署
+
+
网络架构：Backbone + Neck + Head
+
+ | 组件 | 作用 | YOLOv8 示例 |
|---|
+
+ | Backbone | 特征提取网络，从原始图像中提取多尺度特征图 | CSPDarknet + C2f 模块（跨阶段局部网络，提升梯度流动） |
+ | Neck | 特征融合层，将不同尺度的特征图进行融合，增强多尺度检测能力 | PAN-FPN（路径聚合网络 + 特征金字塔），自顶向下 + 自底向上双向融合 |
+ | Head | 检测头，输出最终的边界框坐标 + 类别概率 + 置信度 | 解耦头（Decoupled Head）：分类和回归分支分离，各自优化 |
+
+
+
+
关键技术原理
+
+
锚框（Anchor Box）
+
+ - 预定义的一组宽高比和尺度的候选框，模型预测的是相对于锚框的偏移量而非绝对坐标
+ - YOLOv5：基于训练集聚类（K-Means）自动生成锚框尺寸
+ - YOLOv8：引入 Anchor-Free 机制，直接预测目标中心点和宽高，消除锚框超参数调优
+
+
+
NMS（非极大值抑制）
+
+ - 同一目标可能产生多个重叠的检测框，NMS 用于去除冗余框
+ - 流程：按置信度排序 → 选取最高分框 → 计算与其他框的 IoU → 抑制 IoU > 阈值的框 → 重复
+ - YOLOv10：引入 NMS-Free 训练，通过一对一标签分配（One-to-One Assignment）在推理时不再需要 NMS 后处理
+
+
+
损失函数
+
+ | 损失类型 | 说明 | 常用函数 |
|---|
+
+ | 分类损失 | 衡量类别预测的准确性 | BCE Loss（二元交叉熵） |
+ | 定位损失 | 衡量边界框坐标的准确性 | CIoU Loss（考虑重叠面积 + 中心点距离 + 宽高比） |
+ | 置信度损失 | 衡量"该框包含目标"的置信度 | BCE Loss + Focal Loss（聚焦难分样本） |
+
+
+
+
核心评估指标
+
+ | 指标 | 定义 | 意义 |
|---|
+
+ | IoU | 预测框与真实框的交集 / 并集 | 衡量定位精度，> 0.5 通常认为检测正确 |
+ | mAP | 所有类别 AP 的平均值 | 综合衡量检测精度，最常用的整体指标 |
+ | mAP@0.5 | IoU 阈值 = 0.5 时的 mAP | 宽松标准，反映"找得到"的能力 |
+ | mAP@0.5:0.95 | IoU 从 0.5 到 0.95（步长 0.05）取平均 | 严格标准，反映"定位准"的能力（COCO 数据集主要指标） |
+ | FPS | 每秒处理帧数 | 衡量推理速度，实时场景通常需要 ≥ 25 FPS |
+
+
+
+
模型优化与加速
+
+ | 技术 | 原理 | 效果 |
|---|
+
+ | 模型量化（INT8） | 将 FP32 权重和激活值映射到 INT8，降低计算精度换取速度 | 推理速度 2-4x 提升，精度损失 < 1% |
+ | 模型剪枝 | 移除不重要的通道/层，减少参数量和计算量 | 模型体积缩减 30-50%，速度提升 |
+ | TensorRT 加速 | NVIDIA 推理优化引擎：层融合、显存优化、内核自动调优 | 推理速度 3-5x 提升，适合 GPU 部署 |
+ | ONNX 导出 | 将 PyTorch 模型导出为 ONNX 通用格式，跨框架/跨硬件部署 | 一次导出，多端部署（GPU / CPU / Edge TPU） |
+ | OpenVINO | Intel 推理引擎，针对 CPU / VPU / FPGA 优化 | x86 平台 CPU 推理加速，无需 GPU |
+
+
+
+
主流检测模型对比
+
+ | 模型 | 类型 | 精度 (mAP) | 速度 | 适用场景 |
|---|
+
+ | YOLOv8 | 单阶段 Anchor-Free | 高 | 快 | 实时检测、边缘部署 |
+ | YOLOv10 | 单阶段 NMS-Free | 更高 | 更快 | 端到端实时检测 |
+ | Faster R-CNN | 两阶段 | 最高 | 慢 | 高精度离线分析 |
+ | SSD | 单阶段 | 中等 | 快 | 轻量级移动端 |
+ | RT-DETR | 基于 Transformer | 高 | 较快 | 端到端 + 全局上下文建模 |
+
+
+
+
视频流推理 Pipeline（工程实践）
+
+┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
+│ RTSP │───→│ 解码 │───→│ 抽帧 │───→│ YOLO │───→│ 告警 │
+│ 取流 │ │ FFmpeg │ │ (1-N fps)│ │ 推理 │ │ 推送 │
+└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
+ │
+ ▼
+ ┌──────────┐
+ │ 目标跟踪 │
+ │ DeepSORT │
+ └──────────┘
+
+
+ - 取流：FFmpeg / GStreamer 拉取 RTSP 视频流，支持 H.264/H.265 硬解码
+ - 抽帧：按业务需求设置帧率（实时监控 5-10 fps，高精度场景 25 fps），跳帧策略节省算力
+ - 推理：预处理（Resize + Normalize）→ GPU 推理 → 后处理（NMS / 坐标映射）
+ - 目标跟踪：DeepSORT（卡尔曼滤波 + 匈牙利匹配 + ReID 特征），跨帧关联同一目标，实现轨迹追踪与计数
+ - 告警推送：检测到目标 → 截图存证 → 通过 MQTT / WebSocket / 钉钉机器人实时推送告警
+
+
+
常见应用场景与模型选型
+
+ | 场景 | 检测目标 | 推荐模型 | 部署方式 |
|---|
+
+ | 安全生产 | 安全帽、反光衣、烟火、区域入侵 | YOLOv8s | 边缘盒子（Jetson Orin） |
+ | 智慧交通 | 车牌、车型、车流统计、违停 | YOLOv8m + LPRNet | 边缘服务器（T4 GPU） |
+ | 农业物联网 | 病虫害识别、果实计数、生长阶段 | YOLOv8n | 边缘网关 / 云端 GPU |
+ | 工业质检 | 产品缺陷、尺寸偏差、装配完整性 | YOLOv8x | 工业相机 + GPU 工控机 |
+ | 安防监控 | 人脸、人体、异常行为、物品遗留 | YOLOv8l | NVR + 算力卡 / 中心服务器 |
+
+
+
+
实施场景注意事项（实战经验）
+
+
+ 以下基于实际项目踩坑经验总结——涉及 GB/T 28181 国标平台、海康/大华 SDK、开源方案（FastBee / WVP-GB28181 / FFmpeg + YOLO）在真实场景中的落地要点。
+
+
+
摄像头接入与取流
+
+ | 问题 | 常见坑 | 对策 |
|---|
+
+ | 协议兼容 | 不同品牌摄像头支持的协议不同——海康优先 ISUP / EHOME，大华有私有 SDK，ONVIF 各厂商实现程度不一 | 优先对接 GB/T 28181 国标（强制标准），兜底 RTSP；海康/大华单独适配 SDK 以获得完整 PTZ 控制和报警回调 |
+ | RTSP 稳定性 | RTSP 基于 UDP，网络抖动导致花屏、断流；长时间运行 TCP 会话可能被防火墙断开 | 使用 TCP 传输模式（?tcp 参数）；增加断线重连 + 指数退避策略；FFmpeg 设置 -rtsp_transport tcp -stimeout 5000000 |
+ | 多路并发 | 直接拉 50+ 路 RTSP 流导致带宽和连接数爆炸，单台服务器网卡成为瓶颈 | 分级架构：边缘网关（NVR / 工控机）本地拉流 + 推理，只上传告警事件到中心；或使用流媒体服务（ZLM / SRS）统一收流转发 |
+ | 视频编码 | H.265 摄像头越来越普及，但部分开源推理框架对 H.265 硬解支持不佳 | 确认 GPU 硬解能力（NVIDIA NVDEC / Intel QSV）；必要时在接入层统一转码为 H.264；优先选 H.264 流的摄像头子码流做推理 |
+
+
+
+
推理性能与资源规划
+
+ | 问题 | 常见坑 | 对策 |
|---|
+
+ | GPU 资源估算 | 低估了多路视频并发推理的显存和算力需求，上线后发现 GPU 跑不满或 OOM | 单路 YOLOv8s 约占用 1.5-2GB 显存；一张 T4（16GB）实际可跑 8-12 路（需留显存给解码 + 前后处理）；做好压测再承诺路数 |
+ | 抽帧策略 | 全部 25fps 逐帧推理，GPU 资源浪费且告警风暴（同一个目标连续告警几十次） | 按场景定抽帧率：周界入侵 5fps、烟火检测 2fps、车牌识别 10fps；配合跳帧 + 告警去重（同一目标同一区域 N 秒内只告警一次） |
+ | 子码流推理 | 用主码流（1080P/4K）做推理，分辨率远超模型输入尺寸（640×640），浪费解码 + 预处理算力 | 摄像头开启子码流（704×576 或 640×480），专门用于 AI 推理；主码流仅用于录像存储和人工调阅 |
+ | 批处理 vs 实时 | 为提升吞吐量攒批次推理，但引入几百毫秒延迟，告警不及时 | 安防场景优先低延迟：单帧推理、不攒批；离线分析（如事后检索）可以用大 batch 提升吞吐 |
+ | 模型选型误区 | 追求大模型高精度（YOLOv8x），忽略边缘设备算力限制 | 边缘设备用 YOLOv8n/s + TensorRT INT8 量化；中心服务器可用大模型做二次复核（小模型初筛 → 大模型确认） |
+
+
+
+
告警策略与误报控制
+
+ | 问题 | 常见坑 | 对策 |
|---|
+
+ | 误报泛滥 | 检测灵敏度设太高或未做区域过滤，一天几百条误报告警，客户直接关系统 | 多级过滤：置信度阈值（≥0.6）+ 检测区域 ROI 绘制（排除马路/绿化带等干扰区）+ 时间策略（工作时间告警、非工作时间静默） |
+ | 告警风暴 | 同一事件持续触发（如一个烟头在画面中 5 分钟，告警 300 次） | 告警去重窗口：同一摄像头 + 同一目标类别 + N 秒内合并为一条；告警升级机制：持续超过 M 分钟升级为严重告警 |
+ | 目标跟踪丢失 | DeepSORT 在遮挡、光照变化、密集场景下 ID Switch 严重，导致计数不准 | 结合 ROI 区域限定跟踪范围；遮挡后给 ReID 特征匹配设置合理的超时时间（如 30 帧）；密集场景考虑 ByteTrack（低分框也做匹配，抗遮挡更好） |
+ | 昼夜差异 | 白天训练模型用在夜间红外画面，检测率断崖下降 | 训练集必须包含红外/微光场景样本（至少 20%）；或分时段加载不同模型（白天模型 + 夜间模型） |
+ | 天气影响 | 雨雪雾天气导致画面模糊，检测失效 | 数据增强时加入高斯模糊、亮度抖动、模拟雨雪噪声；极端天气自动切换为移动侦测兜底方案 |
+
+
+
+
存储与回溯
+
+ | 问题 | 常见坑 | 对策 |
|---|
+
+ | 告警截图丢失 | 只存告警记录不存截图/短视频，事后追查无依据 | 告警触发时同时保存：告警时刻前后各 3 秒的短视频片段 + 关键帧截图 + 检测框标注图；存储策略：热数据 SSD（7 天）、冷数据 NAS/对象存储（90 天） |
+ | 录像回溯 | 告警记录和录像时间戳不对齐，事后查证时找不到对应录像片段 | 告警记录强制记录 NTP 时间戳（精确到毫秒）+ 摄像头编号 + 帧序号；对接 NVR 录像回放 API 实现一键跳转到告警时刻回放 |
+ | 存储成本 | 全量录像 7×24 存储，100 路 1080P 一个月几十 TB | 常态录像：低码率 + 移动侦测录像（只录有动静的）；告警录像：高清 + 完整片段；定期清理策略自动化 |
+
+
+
+
系统可靠性与运维
+
+ | 问题 | 常见坑 | 对策 |
|---|
+
+ | 单点故障 | AI 推理服务挂了，所有摄像头告警全部中断，且没有感知 | 服务健康检查 + 自动重启（systemd / k8s 探针）；关键通道双机热备；监控告警通道本身的心跳（超过 1 分钟无数据触发运维告警） |
+ | GPU 掉卡 | GPU 长时间运行温度过高掉卡或驱动崩溃，进程无感知卡死 | 定时检测 GPU 可用性（nvidia-smi + CUDA 可用性探针）；异常时自动重启推理服务；边缘设备注意散热和防尘 |
+ | 模型更新 | 模型迭代后直接全量替换，新模型在某个点位效果变差，缺乏回滚能力 | 灰度发布：先在 10% 通道上验证新模型，对比告警准确率；保留上一版本模型，支持一键回滚；记录模型版本 + 通道的告警效果基线 |
+ | 时钟同步 | 服务器、摄像头、NVR 时钟不同步，告警时序混乱，多路联动失败 | 全系统强制 NTP 对时；摄像头每天自动校时；告警时间以服务器收到帧的时间戳为准（而非摄像头 OSD 时间） |
+ | 日志与审计 | 出了事故查不到为什么没告警——是模型没检测到？还是告警规则过滤了？还是推送通道断了？ | 全链路埋点：取流状态 → 抽帧计数 → 推理耗时 → 检测结果 → 过滤规则命中 → 告警推送状态，每个环节都可追溯 |
+
+
+
+
国标 GB/T 28181 对接注意事项
+
+ - SIP 信令：国标基于 SIP 协议，摄像头/NVR 作为 SIP UA 注册到平台。注意 SIP 超时设置（默认 3600 秒），需定期发送心跳保持在线
+ - 目录推送：平台通过 Catalog 订阅获取设备列表。设备增删改后需触发目录同步，否则平台看不到新设备
+ - 流媒体分发：AI 推理不要直接从摄像头拉流（摄像头并发拉流能力有限，通常 3-5 路），应通过国标平台的流媒体服务（ZLM / SRS）统一分发
+ - PTZ 控制：球机预置位巡航 + AI 检测联动——检测到目标后自动调用预置位、变焦放大做二次确认
+ - 报警订阅：国标支持摄像头自带报警（移动侦测/IO 输入）的 SIP 订阅推送，可结合 AI 告警做交叉验证
+
+
+
+
技术全景总结
+
+ | 方向 | 核心原理 |
|---|
+
+ | LLM | Transformer + 三阶段训练，Self-Attention 是核心 |
+ | Prompt | 通过输入设计引导模型行为，CoT 通过中间推理 token 约束输出路径 |
+ | Agent | LLM + 规划 + 工具调用 + 循环决策 = 自主完成任务 |
+ | Skills 编排 | 业务能力模块化，LLM 语义匹配 + 动态路由，自动编排执行 |
+ | RAG | 检索外部知识增强 LLM，离线入库 + 在线问答双 Pipeline，解决幻觉与知识时效 |
+ | AI Coding | AI 辅助代码生成/审查/测试，Agent 模式实现自主开发闭环 |
+ | YOLO | 单阶段目标检测，Backbone+Neck+Head 架构，一次前向传播同时输出检测框与类别，适合实时视频流推理 |
+
+
+
+