01 系统架构 - Ei-Ayw/smart-tea-garden GitHub Wiki

系统架构

画板

接口设计(按功能点【最小可行产品】)

接口规范

请求规范

采用 HTTP/HTTPS 协议,确保数据传输的安全性和稳定性,所有接口遵循 RESTful 架构,使用标准 HTTP 方法(GET、POST、PUT、DELETE)。非特殊说明,请求和响应使用 JSON 格式。Authorization请求头携带 JWT 令牌,格式为Bearer <token>。接口测试工具统一为Apipost。

{
    "Content-Type": "application/json",
    "Authorization": "Bearer <ACCESS_TOKEN>"
}

统一返回格式

{
  "code": 0, // 返回码、错误码
  "timestamp": "2025-07-03 14:30:00", // 时间戳
  "message": "success", // 状态描述
  "data": { // 数据内容,成功时返回具体数据,失败时为空
    // 具体数据结构根据接口类型而定
  }
}

示例代码

(1)成功
{
    "code": 200,
  	"timestamp": "2025-07-03 14:30:00",
    "message": "success",
    "data": {
        "temperature": 25.3,
        "humidity": 60.5,
        "light": 1500,
        "wind_speed": 3.2,
        "rainfall": 0
    }
}
(2)错误
{
    "code": 1001,
  	"timestamp": "2025-07-03 14:30:00",
    "message": "failed sql exception",
    "data": {},
}

错误码定义

错误码 描述
1001 参数缺失
1002 参数格式错误
1003 签名验证失败
2001 数据查询失败
2002 数据上传失败
3001 服务器内部错误

数据大屏推送与聊天室机制

轮询与SSE、WebSocket

在日常web开发中经常会遇到查看数据最新状态的业务场景,例如查看任务状态与日志内容等。比较场景的解决方案是轮循和SSE。Server-Sent Events (SSE) 是一种允许服务器通过单向通道向客户端推送更新的技术。它基于HTTP协议,客户端使用一个标准的HTTP请求来连接到服务器,并保持这个连接打开,服务器可以在这个连接上持续地发送数据。传统http轮询需要客户端不断向服务器发起请求,每一次都要建议新的http连接,而且如果数据并没有更新,这个操作毫无意义,耗费网络带宽与系统资源,SSE允许长时间保持http连接,除非用户自行中断,实时的将数据同步到客户端,适合单向推送的数据大屏应用。WebSocket与SSE功能相似,但实现更为复杂,体量较大,可以实现客户端和服务端之间的实时双向通信,适合聊天室、AI问答场景,

SSE 与 WebSocket 对比

  • SSE:适用于只需要服务器向客户端单向实时推送数据的场景,如数据大屏,实现简单,对服务器压力小,浏览器兼容性较好。SSE基于HTTP协议,使用HTTP/1.1HTTP/2,更适合需要基于现有HTTP/HTTPS基础设施的应用。SSE内置自动重连机制,如果连接断开,客户端会自动尝试重新连接。
  • WebSocket:适用于需要客户端和服务器之间实时双向通信的场景,如聊天室、实时协作应用,支持双向通信,但实现复杂,对服务器压力更大,浏览器兼容性相对较差。WebSocket 是独立协议,虽然也从HTTP握手开始,但连接升级为WebSocket协议后不再使用HTTP,适合需要低延迟、双向通信的应用。WebSocket需要额外的代码来处理断开后的重连机制。

AI问答流式响应

大模型服务平台(如 DeepSeek、OpenAI 等)通常采取流式响应(Streaming Response)方案,允许用户实时查看大模型已经生成的部分内容,而无需等模型生成完所有文本后一次性返回,实现“打字机”效果。用户可以“边生成边看”,大大提升了交互性和响应速度。

bilibili

参考:https://zhuanlan.zhihu.com/p/1901677757643077423

茶园系统开发实际

AI Agent 智能体策略

AI 概念详解

参考spring ai文档:https://springdoc.cn/spring-ai/concepts.html

文件资料写入向量化数据库

向量化 Embedding

嵌入是将文本、图像或视频转化为数值表示的技术,能够捕捉输入数据之间的关联性。

嵌入通过将文本、图像和视频转换为浮点数数组(称为向量)来工作。这些向量旨在捕捉文本、图像和视频的含义。嵌入数组的长度称为向量的维度。

通过计算两段文本向量表示之间的数值距离,应用程序即可判定原始对象在嵌入向量空间中的相似程度。

RAG 信息匹配检索

参考:https://zhuanlan.zhihu.com/p/1916069775718725324https://arthurchiao.art/blog/rag-basis-bge-zh/

RAG 的核心思想是动态地从外部知识库检索相关信息,并结合生成模型的能力,以产生更准确、可靠的回答。其工作流程通常分为两个阶段:

  • 检索(Retrieval):根据用户输入(query),从大规模知识库(如维基百科、专业数据库)中检索最相关的文档或段落。
  • 生成(Generation):将检索到的文档与原始输入一起输入生成模型(如GPT、T5),生成最终回答。

记忆持久化

在构建 AI 助手系统时,一个重要的设计考量便是如何存储和管理用户对话历史。无论你是希望实现短期缓存、完整聊天记录,还是打造长期的 AI 记忆体系,都需要根据具体业务场景、查询需求、存储结构以及成本等多维度因素做出合理选择。历史对话记忆持久化分为短时记忆和长时记忆,短时记忆比如存储到 localStorage(客户端本地存储)、绘画存储,长时记忆需要把对话记忆存储到服务端的数据库。

localStorage

参考:https://blog.csdn.net/sinat_25518349/article/details/148529493

使用localStorage存储历史ai对话,将历史对话内容写到客户端本地,减小服务器和数据库存储压力,提交问题时将历史对话一起发送给后端。

Mem0

参考:https://zhuanlan.zhihu.com/p/1917541819404755000

官网:https://mem0.ai/

Memobase

参考:https://zhuanlan.zhihu.com/p/29439492730

数据库存储

参考:https://zhuanlan.zhihu.com/p/29439492730

不同记忆方案的对比

参考:https://mem0.ai/blog/ai-agent-memory-benchmark/

视频流实时推送

参考:https://blog.csdn.net/neusoft2016/article/details/128989752

核心概念

视频流实时推送是指将视频数据以 “流” 的形式实时传输到客户端,实现 “边传边播” 的技术。与传统视频下载后播放的区别在于:实时性要求高(延迟通常需 < 1 秒),且需要持续应对网络波动、设备性能等挑战。****

典型应用场景

直播(电商直播、游戏直播、赛事直播)、视频会议(Zoom、腾讯会议)、实时监控(安防系统、远程设备监控)、互动社交(抖音、快手的实时连麦)

流媒体传输协议
协议类型 特点 适用场景 延迟表现
RTMP(Real-Time Messaging Protocol) Adobe 推出的经典协议,支持直播推流与播放,兼容性强,需 Flash 或专用播放器 传统直播平台(如虎牙、斗鱼) 500ms-1s
WebRTC(Web Real-Time Communication) 浏览器原生支持,无需插件,集成音视频采集、编码、传输全流程 网页端实时互动(视频会议) <300ms
HLS(HTTP Live Streaming) 将视频切片为 TS 文件,通过 HTTP 分段传输,苹果设备原生支持 移动端点播、弱网场景 1-3s
RTSP(Real-Time Streaming Protocol) 用于控制流媒体会话,常与 RTP/RTCP 配合传输数据 安防监控、IP 摄像头 中等
视频编码技术
  • H.264/AVC:最主流的编码格式,平衡压缩率与画质,兼容性强。
  • H.265/HEVC:压缩率比 H.264 高 50%,但编码复杂度更高,适合 4K/8K 场景。
  • VP9/AV1:开源编码,压缩效率更高,常用于 YouTube 等平台。
网络传输优化技术
  • FEC(前向纠错):通过冗余数据修复丢包,如在 10% 丢包率下仍可流畅播放。
  • ARQ(自动重传请求):发现丢包后请求重传,适合低延迟场景(如 WebRTC)。
  • 动态码率调整:根据网络状况自动切换高清 / 标清流,避免卡顿。
从推流到播放的全流程

[摄像头/采集设备] → [推流端(编码器)] → [流媒体服务器] → [CDN节点] → [客户端(解码器+播放器)]

  • 推流端(Sender)
    • 功能:采集视频(摄像头)、音频,编码为指定格式,通过协议推送到服务器。
    • 常用工具:OBS(开源推流软件)、FFmpeg(命令行推流)、各平台 SDK(如抖音直播 SDK)。
  • 流媒体服务器(Media Server)
    • 功能:接收推流数据,转发给多个客户端,支持协议转换(如 RTMP 转 HLS)。
    • 开源方案:
      • SRS(Simple Real-time Streaming Server):高性能、易扩展,支持 RTMP/WebRTC。
      • Nginx-RTMP 模块:基于 Nginx 的轻量级 RTMP 服务器。
      • Wowza:商业流媒体服务器,功能全面但收费。
  • 客户端(Player)
    • 功能:接收流数据,解码后播放,处理缓冲、交互操作。
    • 实现方式:
      • Web 端:HTML5 Video 标签(HLS)、WebRTC API(原生支持)、Flash(渐被淘汰)。
      • 移动端:Android/iOS 原生播放器(支持 HLS)、ExoPlayer(Android 开源)、Vitamio(商业)。

技术开发

茶园使用协议:RTSP

参考:https://blog.csdn.net/2201_75875170/article/details/134333016https://deepinout.com/django/django-questions/707_django_opencv_live_stream_from_camera_in_django_webpage.htmlhttps://geek-docs.com/django/django-questions/58_hk_1711156814.html

⚠️ **GitHub.com Fallback** ⚠️