539 字
3 分钟
项目概览与技术栈
项目概览与技术栈
本篇是 项目索引 的开场笔记，先给出项目的输入输出边界、系统总览与关键设计决策。读完这篇后，再进入后续模块拆解会更容易建立全局视角。
1 项目目标
这个项目的目标很明确：构建一个支持文字、图片、语音三种输入方式的聊天机器人，并让这三类输入最终都汇入同一条 LangChain 对话链路。
核心能力包括：
- 文字消息直接进入对话上下文
- 图片在本地预处理后转成模型可接受的
image_url - 语音在前端阶段先转文字，再进入 LangChain
- 多轮会话历史通过 SQLite 持久化
2 系统总览
这个图里最关键的一点是：三种输入并不是分别走三套系统，而是在预处理之后统一汇入 LangChain 消息流。
3 技术栈
| 层次 | 技术 | 作用 |
|---|---|---|
| 前端 | Gradio | Web 聊天界面 |
| 编排 | LangChain | 链式调用、历史管理 |
| 存储 | SQLite | 多轮对话历史持久化 |
| 语音 | qwen3-asr-flash / sensevoice-v1 | 语音转文字 |
| 多模态 | 阿里云百炼 multiModal_llm | 文字+图片理解 |
| HTTP | httpx | 直接调用阿里云原生 API |
| 图像 | Pillow | 图片格式转换与编码 |
⚡ 关键设计决策
为什么音频在前端阶段就转文字？语音文件体积大，base64 后更大，不适合直接写入 SQLite 历史。在 add_message 阶段转成文字，既节省存储，又让历史可搜索。
为什么不用 OpenAI 兼容接口发音频？阿里云 compatible-mode 接口只支持公网 URL，不支持本地文件或 base64。必须改用 DashScope 原生多模态接口才能用 Data URI 传音频。
为什么用 RunnableWithMessageHistory？自动处理「读历史 → 注入 Prompt → 写历史」三步，不需要手动管理 SQLite，代码量减少约 60%。
📦 依赖安装
pip install gradio langchain langchain-community pillow httpx openai相关笔记