​现在主流的手机操作系统有Android、iOS和HarmonyOS（鸿蒙系统），为了减少同时维护三种客户端的工作量，一般采用APP内嵌H5页面的形式。由于H5不能直接调用客户端的原生能力，比如相机、麦克风，以及读取设备信息，因此需要在APP与H5之间搭建一种双向通信的桥梁机制。JSBridge（JavaScript Bridge）就是这种H5混合App的双向通信桥梁，它通过定义JS接口与Nati

​之前的文章《15天学会AI应用开发（十三）上下文与RAG的阶段性总结》概述了检索RAG知识库的主要步骤，现在采用LangChain将其改造为更智能的本地RAG系统。接下来基于LangChain框架与Chroma向量数据库，结合离线的文本嵌入模型和大语言模型，从零开始搭建本地的RAG检索系统。首先下载离线的大语言模型，比如在命令行窗口执行下面命令，即可下载国产大模型qwen2:1.5b：接着下载构

​上一篇文章介绍了如何使用InMemoryStore实现用户偏好的精确记忆功能，但记忆只保留在内存中，一旦AI应用重启，就会丢失上次在内存中的记忆数据。为了让AI应用持久记忆业务数据，就得引入文件或者数据库等存储介质，比如Python自带的轻量级数据库SQLite。接下来就介绍如何结合LangGraph与SQLite实现业务数据的持久记忆功能。安装Python时已经自带了SQLite包，在代码开头

时下各种AI聊天应用争奇斗艳，一个比一个智能，一个比一个贴心。早在2022年出版的《Android Studio开发实战：从零基础到App上线(第3版)》中，笔者就基于Android实现了一个具备初级智能的小小机器人APP，不仅支持简单的问答，还支持问询天气预报，还支持加减乘除四则运算，还支持背诵唐诗宋词名篇佳句，可谓小朋友的贴心玩伴。《鸿蒙HarmonyOS 6应用开发:从零基础到App上线》一

​上一篇文章介绍了如何使用LangGraph实现会话记忆功能，可是历史会话又多又杂，难以全部记忆，开发者更希望AI应用记住关键信息，比如用户喜欢什么、爱好什么等等。对于AI应用的精确记忆需求，LangChain支持在调用create_agent时输入store参数，以指定数据存储方式，接下来介绍如何通过store参数存取用户的偏好信息。上一篇文章调用create_agent时，仅用到了少数几个参数

​上一篇文章采用langchain_community包协助LangChain实现了对话记忆功能，但langchain_community属于早期链式架构的临时补丁，仅适配简单线性对话。LangChain官方推荐使用LangGraph实现复杂的会话记忆功能，LangGraph是从底层统一管理全流程状态、支持长短双记忆、原生持久化、适配复杂Agent的标准化记忆架构，常作为生产环境的首选方案。接下来

​模型本身是无状态的，也就是不具备记忆功能，单次对话无法留存上下文信息，多轮交互中会遗忘历史对话内容。用户之所以感觉AI工具拥有记忆，是因为AI工具给大模型封装了一层记忆。LangChain作为主流的大模型应用开发框架，内置完善的记忆模块（Memory模块），能够高效管理对话历史记录，让AI实现逻辑连贯的多轮对话，接下来就介绍如何使用LangChain实现对话记忆功能。LangChain实现对话记

​上一篇文章末尾给出了LangChain的简单调用例子，当然LangChain还支持更丰富的功能设置，接下来就介绍如何使用LangChain封装AI执行链，以实现更复杂的功能调用。在构造大模型实例之前，要先添加下面的导包语句，表示引入LangChain的大模型工具OllamaLLM：在OllamaLLM的构造方法中，model参数是必填的，要指定当前引用的大模型名称，如下：除了model参数以外，

​LangChain 是一套大语言模型 (LLM) 应用开发框架，主打链式编排、任务流程组装，可快速搭建智能对话机器人、智能助手、自动化流程、知识库问答、Agent 智能体。LangChain 支持对接各类在线大模型，包括OpenAI、文心、通义、讯飞等，也支持加载电脑本地的离线大模型。为避免在线大模型带来的大量Token消耗，接下来以离线大模型为例介绍如何搭建LangChain的开发环境。AI应

​之前的系列文章主要讲解上下文（提示词）和RAG（知识库），为了方便大家归纳，这里把前面的几个重要内容重新梳理总结。正所谓磨刀不误砍柴工，要想后续顺利进行AI应用编程，务必正确搭建电脑的Python开发环境，这样可以避免代码编译时出现奇奇怪怪的错误，才能心无旁骛地钻研AI应用技能。首先是安装哪个Python版本。AI开发环境的Python版本推荐Python 3.10.x，该版本兼容所有 AI 库

​上一篇文章介绍了如何从TXT文件读取文本信息，可是日常办公很少使用纯文本的TXT格式，而采用专业的PDF格式或者WORD格式，有时还需要通过网页抓取知识。接下来就介绍如何从PDF、WORD、HTML等文件中读取文本内容。PDF是一种常用的文档格式，常用于只读的通知文件，或者电子版书籍。Python提供了多种三方库用来解析PDF文件，其中pdfplumber较常用。使用Python代码读取PDF文

前面的文章在构建RAG并检索时，既使用了国外大模型，也使用了国内大模型；既运用了内存向量检索库FAISS，也运用了磁盘向量数据库Chroma。但知识库的原始来源却是knowledge数组，这与现实场合有所出入，因为实际资料都保存在TXT、PDF、WORD等格式的文档中，甚至来自互联网上的HTML网页，于是RAG的前置条件就成了如何从这些文档中提取文本信息。TXT文件是最简单的文本格式，读写TXT无

前面两篇文章在演示RAG功能时，做向量化的文本嵌入模型都用国外的all-MiniLM-L6-v2，该模型主要适用英文，对于中文总体也能用，但在细节上处理欠佳。本文就来介绍如何使用国产离线的文本嵌入模型替换国外模型，以及如何体现国产模型的比较优势。虽然all-MiniLM-L6-v2的优点很多，比如下列几点：1、体积极小：几十 MB，随便本地离线下载2、速度超快：CPU 就能跑，不用显卡3、通用好用

​上一篇文章通过all-MiniLM-L6-v2模型结合FAISS实现了简单的RAG检索功能，但FAISS运行于内存中，无法持久化保存向量数据，重启后又得重新对文本做向量化，比较浪费算力资源。本文就来介绍如何使用向量数据库来持久保存向量数据。Chroma是一个本地向量数据库，专门用来保存 RAG 知识库，并且快速检索相关内容。Chroma与FAISS之间的区别如下：1、只做检索，不做保存；Chro

上一篇文章采用字符串匹配的方式来查找知识，这种方式比较呆板不够智能，接下来引入向量数据库，通过向量化实现更精细的知识检索。向量化一段文本的时候，经常用到all-MiniLM-L6-v2，它是一个轻量级的文本嵌入Embedding模型，专门把文字转成数字向量，给RAG做语义检索用。命令行通过cd命令进入Python工程的所在目录，再执行下面的模型下载命令，可将all-MiniLM-L6-v2保存到本

​前面的文章依次介绍了如何截断历史会话的对话记录，包括按照记录数量截断、按照Token长度截断，以及浓缩为摘要截断等等，其中摘要操作又分为三大类：1、使用第三方的摘要库对文本摘要；2、使用在线大模型对文本摘要；3、使用离线大模型对文本摘要；以上对会话记录的各种处理操作，统称为AI应用的上下文管理，即让AI理解用户之前的意图。接下来将开启有关RAG部分的AI应用开发教程介绍。RAG的全称是Retri

​上一篇文章末尾使用了在线大模型压缩文本生成摘要，但该方式会消耗Token，不便初学者长期使用，更好的办法是采用离线大模型来生成文本摘要。国内常用的离线大模型有阿里Qwen、智谱GLM、深度求索DeepSeek、百度文心等等，以千问的文本大模型为例，又有Qwen1.5-1.8B-Chat和Qwen1.5-0.5B-Chat两种。Qwen1.5是一系列不同大小的解码器语言模型，包括基础语言模型及其对

​HarmonyOS 6.1.1 已于 2026 年 5 月下旬正式发布，该版本在 HarmonyOS 6.1 基础上增强了若干特性，让鸿蒙系统变得更流畅更好用，下面结合《鸿蒙HarmonyOS 6应用开发:从零基础到App上线》一书对 HarmonyOS 6.1.1 新特性中的常用部分逐一讲解。二维绘图场景支持临时开关文本抗锯齿功能。CanvasRenderingContext2D是在Canva

​前面两篇文章分别介绍了根据消息数量截断历史对话和根据Token长度截断历史对话，可是这两种方式有两个共同的问题：1、被删去的早期记录可能包含关键信息，直接截断会导致信息丢失。2、原始的对话记录可能存在重复、冗余、拖沓的文字内容。要知道，重复、冗余、拖沓的文字内容并不高效，因为它的信息密度很低，很啰嗦，同样的意思使用更少的文字即可表达，完全没必要照搬原始的对话记录。比如很多小说都有缩写本或者极简本

​上一篇文章说到按照消息数量来截断历史对话，这种方式有个问题，就是每次对话的内容可长可短，导致固定消息数量的对话内容忽长忽短。历史对话内容不光要存入数据库，还要作为初始提示词发给下次新会话的大模型。太长的提示词不仅冗余，还会消耗大量Token，让用户钱包快速缩水。太短的提示词容纳的信息量不足，难以起到充分记忆的功能。改进方式是按照文字长度来截断历史对话，不过字跟字又有所不同，不如“猪”是个单字词，