LangChain AI 客服 Agent 项目学习笔记

1. 项目定位

这个项目是一个面向证件照在线制作小程序的 AI 客服 Agent demo。

小程序业务包括：

• 用户上传照片
• 选择证件照规格
• 系统自动制作证件照
• 普通电子证件照免费下载
• 美颜、高清处理、换装、冲印纸质照片等增值服务收费

当前项目不是完整生产系统，而是一个用来验证大模型应用流程的测试项目，核心目标是跑通：

用户问题
 -> Agent 理解意图
 -> 判断是否需要调用工具或检索知识库
 -> 获取业务信息或知识片段
 -> 大模型基于结果生成回复

一句话介绍：

这是一个基于 LangChain 的工具调用型客服 Agent demo，结合本地 RAG 知识库，用来处理证件照小程序中的订单、退款、照片下载、照片规格、VIP、冲印物流和投诉问题。

2. 大模型调用流程

当前项目主要有两个 Agent：

• AdminAIChat：管理员订单处理助手
• ComplaintAIChat：投诉处理助手

管理员助手流程：

用户输入
 -> AdminAIChat.reply()
 -> LangChain create_agent
 -> LLM 判断用户意图
 -> 如需业务数据，调用 query_order / query_order_stats / order_refund_request_page
 -> 如需知识规则，调用 search_customer_service_knowledge
 -> 工具结果返回给 LLM
 -> LLM 生成最终回复

投诉助手流程：

投诉内容
 -> ComplaintAIChat.handle_complaint()
 -> 拼接投诉 ID、平台、订单号、投诉原因、投诉内容
 -> LangChain create_agent
 -> LLM 判断投诉类型
 -> 必要时检索知识库
 -> 必要时调用回复用户、通知管理员、提交退款申请等工具
 -> 返回处理结果

核心思想：

大模型不直接相信自己的参数知识，而是通过工具获取业务数据，通过 RAG 获取业务规则，再基于这些外部结果回答。

3. Agent 是什么

Agent 可以理解为：

LLM + Tools + Memory + Decision

也就是：

• LLM：负责理解用户问题、规划下一步
• Tools：负责查询订单、提交退款、通知管理员、检索知识库
• Memory：负责保留多轮上下文
• Decision：负责判断什么时候调用哪个工具

本项目为什么算 Agent：

• 有明确角色：管理员订单助手、投诉处理助手
• 能根据用户问题决定是否调用工具
• 能把工具结果再交给模型继续生成回复
• 通过 thread_id 区分不同会话
• 通过 context_schema 把业务上下文传给工具

但它目前还是轻量 demo，不是复杂生产级 Agent。它没有复杂多节点规划、人工审核流、持久化状态和完整监控。

4. LangChain 和 LangGraph

LangChain

LangChain 更偏向组件化和快速搭建，例如：

• 调用模型
• 定义 tools
• 搭建 Agent
• 接入 retriever
• 构建简单 RAG 流程

当前项目使用：

create_agent(
    model=build_model(),
    tools=[...],
    system_prompt=...,
    context_schema=...,
    checkpointer=...
)

也就是说，当前项目主要使用 LangChain 快速搭建工具调用型 Agent。

LangGraph

LangGraph 更适合复杂状态流，例如：

投诉识别
 -> 查询订单
 -> 判断是否退款
 -> 判断是否通知管理员
 -> 回复用户
 -> 保存处理结果

如果后续把投诉处理做成显式流程，可以用 LangGraph 把每一步建成 node，用 state 控制分支。

面试表达：

简单工具调用和 RAG 问答用 LangChain 足够；如果任务有多步骤、多分支、循环、人工确认和状态恢复，我会用 LangGraph 显式建模流程。

Tool Calling 指大模型不直接回答，而是根据问题调用外部函数。

本项目中的工具包括：

• query_order：查询订单
• query_order_stats：查询订单统计
• order_refund_request_page：生成退款入口
• send_complaint_reply_to_user：回复用户投诉
• send_complaint_message_to_manager：通知管理员
• submit_order_refund_request：提交退款申请
• search_customer_service_knowledge：检索客服知识库

工具的价值：

模型负责理解和决策
工具负责真实业务动作

这样可以避免模型编造订单状态、退款结果、物流信息等。

6. RAG 是什么

RAG 全称是 Retrieval-Augmented Generation，中文通常叫检索增强生成。

核心流程：

用户问题
 -> 检索相关知识
 -> 把知识片段放进 prompt
 -> LLM 基于检索结果回答

RAG 不是 Markdown 本身，也不是向量数据库本身，而是一整套流程。

当前项目中的 RAG 流程：

knowledge_base/*.md
 -> src/rag.py 读取 Markdown
 -> 按 Markdown 二级标题切分 chunk
 -> 本地关键词、别名、中文 bigram 检索
 -> search_customer_service_knowledge 工具返回相关片段
 -> Agent 基于检索结果回答

当前是轻量本地检索版 RAG，没有接 FAISS、Chroma、Milvus 等向量数据库。

7. RAG 的知识来源

RAG 的知识来源可以是很多类型：

• Markdown
• PDF
• Word
• 网页
• MySQL
• MongoDB
• 帮助中心文章
• 历史客服案例
• 业务规则文档

本项目当前使用 Markdown 作为知识源：

knowledge_base/refund_policy.md
knowledge_base/download_and_order_help.md
knowledge_base/photo_quality_and_specs.md
knowledge_base/printing_and_shipping.md
knowledge_base/vip_policy.md
knowledge_base/complaint_sop.md
knowledge_base/service_scope_and_safety.md

适合进入 RAG 的内容：

• 退款规则
• 照片下载路径
• 照片 KB、尺寸、分辨率问题
• 冲印和物流规则
• VIP 常见问题
• 回执问题
• 投诉处理 SOP
• 客服话术和服务边界

不适合直接进入 RAG 的内容：

• 订单实时状态
• 支付状态
• 退款状态
• 物流最新状态
• 用户手机号
• 账户余额
• 权限判断

这些更适合通过工具或 API 查询。

8. 向量数据库是什么

向量数据库用于语义检索。

普通关键词检索关注：

用户问题里有没有出现“退款”“KB”“物流”这些词

向量检索关注：

用户问题和知识片段在语义上是否相似

例如知识库写的是：

文件 KB 值不对

用户问：

照片太大，上传不了，怎么压缩？

关键词可能不完全匹配，但向量检索更容易命中相关片段。

常见向量数据库或向量索引：

• FAISS
• Chroma
• Milvus
• Qdrant
• PostgreSQL + pgvector
• MongoDB Atlas Vector Search
• Elasticsearch dense_vector
• Redis Vector

当前项目暂时不需要向量数据库，因为知识库规模小、规则明确、本地检索足够跑通流程。

后续如果文档变多、用户表达更复杂，可以升级为：

Markdown / 数据库 / 网页
 -> 文本切分
 -> embedding
 -> FAISS / Chroma / Milvus
 -> top_k 召回
 -> rerank
 -> LLM 回答

9. MySQL、Mongo 和向量数据库的区别

MySQL / Mongo 可以作为 RAG 的原始知识来源，也可以存业务数据。

适合 MySQL / Mongo 存储：

• FAQ 原文
• 帮助文章
• 投诉案例
• 订单数据
• 用户数据
• 退款记录
• 物流记录

但普通 MySQL / Mongo 查询主要是：

字段匹配
关键词匹配
条件过滤

例如：

where order_id = 'xxx'
where status = 'paid'
where title like '%退款%'

向量数据库主要解决：

自然语言问题和知识片段之间的语义相似度匹配

所以更合理的架构是：

MySQL / Mongo 存原始数据和业务状态
向量库保存 chunk embedding
Tool 查询实时业务数据
RAG 检索稳定知识和历史案例

面试表达：

MySQL 和 Mongo 可以作为 RAG 的数据源，但普通查询不等于语义检索。如果要做语义召回，需要把文本抽取出来做 embedding，并存入向量索引。当然，如果使用 MongoDB Atlas Vector Search 或 pgvector 这类能力，也可以直接在数据库里做向量检索。

10. Prompt 工程

Prompt 工程不是简单写提示词，而是把模型的角色、边界、工具使用规则、输出要求约束清楚。

本项目 prompt 的关键约束：

• 查询订单、统计、退款入口必须调用工具
• 照片下载、退款规则、KB、尺寸、VIP、物流等知识问题必须先检索知识库
• 不要编造订单信息
• 投诉回复必须使用 send_complaint_reply_to_user
• 需要管理员介入必须使用 send_complaint_message_to_manager
• 不要告诉用户自己是 AI
• 无关问题不回答

Prompt 的作用：

降低幻觉
约束工具调用
统一客服语气
定义服务边界
提高回答稳定性

11. 短时记忆和长时记忆

短时记忆

短时记忆指当前会话内的上下文，例如：

• 最近几轮对话
• 上一次查询的订单号
• 工具调用结果
• 当前投诉处理状态

当前项目使用：

InMemorySaver()

并通过 thread_id 隔离会话：

admin:{manager_name}
complaint:{complaint_id}

含义：

同一个管理员 -> 同一个管理员会话
同一个投诉 ID -> 同一个投诉处理上下文

当前问题：

InMemorySaver 是进程内记忆，服务重启后会丢失

生产化可以替换为：

• Redis checkpointer
• Postgres checkpointer
• 数据库状态表

长时记忆

长时记忆指跨会话、跨时间长期保存的信息，例如：

• 用户历史投诉记录
• 用户历史订单偏好
• 历史处理结果
• 管理员处理习惯
• 历史客服案例总结

当前项目还没有真正实现用户级长时记忆。

当前的 knowledge_base/*.md 更像公共长期知识库，不是用户个人记忆。

后续可以这样设计：

MySQL / Mongo:
- 用户历史投诉
- 用户订单历史
- 退款申请记录
- 客服处理结果

向量库:
- 历史投诉案例摘要
- 典型问题处理方案
- 高质量客服回复样例

12. 结构化数据和非结构化知识

项目中要区分两类问题。

结构化实时数据

例如：

• 某个订单是否支付
• 某个订单是否有物流单号
• 某个用户 VIP 是否过期
• 某个订单是否已经退款

这些应该走工具或 API 查询。

非结构化知识

例如：

• 退款规则
• 照片 KB 不对怎么办
• 照片模糊怎么解释
• 冲印订单发货后能否退款
• VIP 不生效怎么办

这些应该走 RAG。

面试表达：

结构化强一致数据走工具，非结构化规则和 FAQ 走 RAG。这样既能保证业务数据准确，又能让模型基于知识库回答常见问题。

13. 问答边界

理想回答策略：

能用业务工具处理 -> 调工具
能从知识库找到依据 -> RAG 回答
两者都不行 -> 拒答或转人工

例如：

照片 KB 不对怎么办？
 -> RAG 检索知识库
 -> 命中“文件大小 KB 值不对”
 -> 基于规则回答

例如：

今天天气怎么样？
 -> 不属于订单、投诉、照片业务
 -> 没有天气工具
 -> 知识库也没有天气规则
 -> 拒答或提示服务范围

标准回复：

您好，我只能协助处理订单、投诉、照片制作和下载相关问题。

14. 常用优化方法

RAG 优化

• 文档按主题拆分，不要一篇文档塞所有内容
• 保留标题层级，方便 chunk 切分
• 每个 chunk 尽量包含完整语义
• 加 metadata，例如来源文件、标题、业务类型
• 小规模先用关键词检索，大规模再上向量检索
• 向量检索可以结合 BM25 做 hybrid search
• 召回后可以加 rerank
• 回答时要求基于召回内容，不允许编造

Tool Calling 优化

• 工具名称要清晰
• 工具 docstring 要写明什么时候调用
• 参数要少而明确
• 高风险工具要加人工审核
• 工具失败要有兜底
• 工具结果要结构化，方便模型理解

Prompt 优化

• 明确角色
• 明确服务范围
• 明确必须调用哪些工具
• 明确不能编造
• 明确找不到答案时怎么回复
• 明确输出语气
• 对高风险场景写清规则

记忆优化

• 短期记忆保存当前任务状态
• 长期记忆保存用户画像、历史案例、处理摘要
• 不要无限追加历史消息
• 长会话要做摘要
• 重要状态要结构化保存

15. 面试总结话术

可以这样介绍项目：

我做了一个面向证件照小程序的 LangChain AI 客服 Agent demo。它不是简单聊天机器人，而是结合了工具调用和 RAG。结构化实时数据，比如订单、退款、通知管理员，走 LangChain tools；非结构化知识，比如退款规则、照片下载、KB 调整、冲印物流、VIP 和投诉 SOP，走本地 Markdown 知识库检索。Agent 根据用户意图决定调用工具还是检索知识库，再基于返回结果生成客服回复。

进一步说明：

当前版本为了跑通流程，没有接真实数据库和向量数据库，而是用 mock tools 和本地 Markdown 检索实现。这样可以快速验证 Agent、Tool Calling、RAG、Prompt 约束和短时记忆。后续如果知识库规模扩大，可以升级为 embedding + FAISS/Chroma/Milvus，并结合 BM25 和 rerank 提升召回质量；如果要生产化，还会把 InMemorySaver 替换成 Redis/Postgres checkpointer，并增加日志、评估、人工审核和权限控制。

一句话总结：

这个项目的核心设计是：实时业务数据走工具，稳定业务知识走 RAG，无关问题拒答或转人工。