电商智能客服智能体——基于LangChain的电商智能客服 Agent 架构设计与实现（二）

基于LangChain的电商智能客服 Agent 架构设计与实现

1 引言

1.1 研究背景

随着大语言模型在智能问答、任务规划与工具使用等方向上的能力持续增强，AI Agent 正从"单轮生成式回答"逐步演化为"可推理、可调用外部能力、可维护上下文"的复杂智能体系统。在电商客服场景中，用户问题通常不是一次静态检索即可解决的，而是涉及商品查询、优惠解释、价格计算、多轮补充提问等连续推理过程。

传统基于规则模板或单次检索的客服系统，往往只能处理固定问法，难以在"商品价格 + 优惠规则 + 数值计算 + 对话上下文"这一组合问题上保持稳定表现。例如，用户提出"篮球多少钱"，系统需要先查询商品价格；当用户继续追问"买两件多少钱"时，系统还需要结合上一轮上下文、识别促销规则、完成价格计算，并给出符合业务语义的最终答复。

为解决此类问题，本文在 v1 ReAct 架构基础上，进一步构建了 基于 LangChain的电商智能客服 Agent。该版本将工具编排、消息组织与模型交互统一纳入 LangChain 运行时，减少了手写推理循环与输出解析逻辑，使系统在工程实现上更加模块化，也更贴近当前主流 Agent 框架的开发方式。

1.2 问题定义

电商客服场景中的典型咨询具有如下特点：

多源信息联合推理：需要联合商品数据库与优惠文本规则进行回答。
显式工具调用需求：模型自身并不直接掌握实时商品与库存信息，必须借助外部工具。
数值计算安全要求：价格、折扣与满减逻辑必须通过受控计算模块执行。
多轮上下文依赖：后续问题经常省略商品名称，需要依赖对话记忆完成补全。
业务规则约束性强：如"满 300 元半价"等规则若被语言模型误解，会直接导致答复错误。

因此，v2 版本的核心目标不是简单"接入 LangChain"，而是构建一个 具备工具感知、上下文保持、业务规则约束与安全计算能力 的电商客服 Agent。

2 系统架构与推理流程

2.1 LangChain Agent 推理流程

v2 版本不再像 v1 一样手写 Thought / Action / Observation 的文本解析逻辑，而是将"问题理解---工具选择---结果整合---最终回复"的执行链交给 LangChain Agent Runtime 处理。其本质仍然遵循 ReAct 的核心思想：基于推理选择行动，并依据观察结果继续决策。

图 1 LangChain v2 Agent 推理流程图

如图 1 所示，v2 版本的推理流程具有以下特点：

阶段一：消息组织

系统首先将用户输入追加到消息历史中，并保留一条系统级提示词，作为整个会话的全局行为约束。与 v1 侧重"输出格式约束"不同，v2 更强调"消息语义约束"。

阶段二：工具决策

LangChain Agent 根据当前消息上下文判断是否需要调用工具。当用户询问商品价格、库存、优惠或最终付款金额时，Agent 会自动在已注册工具中进行选择。

阶段三：外部执行

工具层分别完成商品数据库检索、优惠文本检索与价格计算，并将结果返回给 Agent。此处外部环境即 ReAct 语境中的"Observation"来源。

阶段四：规则约束推理

Agent 在得到工具结果后，并非直接生成自然语言，而是继续受系统提示词约束，尤其在优惠解释场景中，需要严格遵循"先查价格、再查优惠、最后计算"的规则链。

阶段五：多轮记忆闭环

最终答复在返回用户前会被写回消息历史，使下一轮问题能够共享上下文。例如，用户先问"有哪些篮球"，再问"买两件多少钱"，系统能够依据历史消息补全商品语义。

因此，v2 的关键变化不是放弃 ReAct，而是将 ReAct 的执行机制从"应用层手写循环"迁移为"框架层 Agent 调度"。

2.2 系统总体架构

v2 版本延续分层设计思想，但架构重心由"自研 Agent 主控循环"转向"LangChain Agent Runtime + 工具系统 + 规则约束消息"。整体架构如图 2 所示。

图 2 LangChain 电商智能客服系统架构图

各层职责如下：

交互层 ：由 main.py 提供命令行交互入口，负责输入输出控制与异常处理。
Agent 运行层 ：由 langchain_agent.py 中的 LangChainCustomerAgent 负责维护消息历史、初始化模型、创建 Agent、执行调用流程。
模型层 ：基于 langchain_openai.ChatOpenAI 接入通义千问的 OpenAI 兼容接口。
工具层 ：在 tools/langchain_tools.py 中以 @tool 装饰器注册三个核心工具。
数据层 ：包括 SQLite 商品数据库 SportsEquipment.db 与优惠规则文本 store_promotions.txt。
规则层：通过系统提示词显式注入价格与优惠处理规则，约束模型的业务解释行为。

与 v1 相比，v2 版本的结构调整主要体现在三点：

删除自研解析器：不再手写正则去解析 Thought / Action / Observation。
统一工具注册方式：通过 LangChain 工具机制管理外部能力。
引入系统规则约束：将业务逻辑中的关键解释规则提升为系统消息的一部分。

2.3 v1 与 v2 的架构差异

为突出本次升级的工程价值，表 1 对两代系统进行对比。

维度	v1 自研 ReAct	v2 LangChain 版
Agent 执行方式	手写推理循环	LangChain `create_agent`
工具调用	字典映射 + 手动调度	`@tool` 注册 + 框架调度
输出控制	正则解析 Thought / Action / Answer	消息驱动与工具调用结果整合
对话记忆	自行维护消息列表	在消息历史中叠加 system / user / assistant
规则约束	提示词模板 + 手写流程	系统提示词直接约束业务规则
工程复杂度	逻辑可解释但实现耦合较高	实现更简洁、框架依赖更强

从系统演化角度看，v2 的价值在于：将低层编排交给框架，把精力集中在业务规则、工具设计和数据组织上。

3 核心技术设计

3.1 基于 LangChain 的 Agent 构建

v2 版本的 Agent 初始化逻辑集中在 langchain_agent.py 中，其核心思想是：先实例化模型，再注册工具，最后由 LangChain 创建 Agent 对象。

python 复制代码

self.llm = ChatOpenAI(
    model="qwen-max",
    api_key=self.api_key,
    base_url=self.base_url,
    temperature=0.7,
)

self.tools = [
    query_product,
    query_promotion,
    calculate_price,
]

self.agent = create_agent(
    model=self.llm,
    tools=self.tools,
)

该设计的优势在于：

模型与工具解耦：模型实例只负责推理，工具列表负责能力边界定义。
框架统一调度：避免手写工具分发与中间状态拼接。
迁移成本较低：后续新增工具时，仅需遵循 LangChain 的工具注册约定。

需要强调的是，当前版本虽然使用的是 create_agent 接口，而非旧版 create_react_agent，但其运行机制仍然保留了 ReAct 的"推理---行动---观察"内核，只是实现入口发生了框架层升级。

3.2 系统提示词中的业务规则注入

在电商场景中，语言模型最容易出错的环节并非数据库查询，而是对优惠政策的自然语言解释。因此，v2 将关键业务逻辑从"隐含常识"提升为"显式系统规则"。

python 复制代码

self.messages: List[dict] = [
    {
        "role": "system",
        "content": (
            "你是电商平台的专业客服助手，负责解答用户关于商品和优惠的咨询。\n"
            "1. 先用 query_product 获取商品单价\n"
            "2. 再用 query_promotion 获取该商品的优惠原文\n"
            "3. 严格按照优惠原文计算，不能增加任何额外条件\n"
            "4. 最后用 calculate_price 计算最终价格"
        )
    }
]

这种设计体现了两项关键思想：

规则显式化：将"满 300 元半价"的凑单逻辑直接写入系统提示词，避免模型自由发挥。
步骤顺序化：明确规定必须先查商品、再查优惠、最后计算，降低工具使用遗漏概率。

这意味着 v2 的正确性不再完全依赖模型"自己理解"，而是通过系统规则对推理路径进行前置约束。

3.3 工具系统设计

v2 的工具层位于 tools/langchain_tools.py，通过 @tool 装饰器暴露给 Agent。系统当前提供三类核心工具。

3.3.1 商品查询工具

python 复制代码

@tool
def query_product(product_name: str) -> str:
    cursor.execute(
        "SELECT * FROM products WHERE product_name LIKE ?",
        (f'%{product_name}%',)
    )

该工具基于 SQLite 进行模糊检索，可返回商品名称、品牌、价格、库存与规格等结构化信息，是后续优惠判断与价格计算的前提。

3.3.2 优惠查询工具

python 复制代码

@tool
def query_promotion(product_name: str) -> str:
    with open(PROMOTIONS_FILE, 'r', encoding='utf-8') as file:
        lines = file.readlines()
    matching_lines = [line.strip() for line in lines if product_name in line]

该工具基于文本文件进行关键词匹配。虽然当前仍属于轻量级规则检索，但在电商客服场景中已足以支持确定性优惠说明。更重要的是，它保留了后续升级为 RAG 检索的接口位置。

3.3.3 安全价格计算工具

python 复制代码

ALLOWED_OPERATORS = {
    ast.Add: operator.add,
    ast.Sub: operator.sub,
    ast.Mult: operator.mul,
    ast.Div: operator.truediv,
    ast.Pow: operator.pow,
    ast.USub: operator.neg,
}

价格计算工具不直接使用 eval()，而是采用 AST 白名单机制解析表达式，仅允许有限数学运算。这一设计对 Agent 系统尤为重要，因为工具入参来自模型生成，若缺乏安全限制，极易引入代码注入风险。

3.4 多轮对话记忆机制

v2 版本通过消息列表维护对话上下文：

python 复制代码

self.messages.append({"role": "user", "content": query})
result = self.agent.invoke({"messages": self.messages})
self.messages.append({"role": "assistant", "content": response})

该机制的价值体现在：

省略信息补全：用户后续问题无需重复商品名称。
对话连贯保持：前文已提及的商品、优惠和购买意图可以在后续轮次复用。
规则持续生效：系统提示词始终位于消息起点，对整个会话保持一致约束。

因此，v2 的记忆并非独立的 Memory 模块，而是一种更轻量、更贴近 LangChain 消息范式的上下文保持机制。

4 系统运行流程

v2 版本的实际运行流程如下：

环境初始化 ：加载 .env 中的 API 密钥与基础地址，初始化 ChatOpenAI。
Agent 创建 ：注册 query_product、query_promotion、calculate_price 三个工具，并构建 Agent。
消息预置：注入系统提示词，建立业务规则约束。
用户输入接收：命令行读取用户问题并写入消息历史。
LangChain 调用：Agent 根据上下文自动决定是否调用工具。
工具执行与整合：查询商品、检索优惠、计算结果，并组织自然语言回复。
历史写回：将最终答复继续写回消息列表，支持下一轮问答。

一个典型示例如下：

用户提问"篮球多少钱"
Agent 调用 query_product
Agent 再调用 query_promotion
当用户追问"我买两件多少钱"
Agent 结合历史语境识别商品仍为"篮球"
依据"单笔订单满 300 元，篮球半价"规则调用 calculate_price
最终返回"两件篮球价格为 200 元"

这一过程表明，v2 已经能够将 结构化检索、业务规则和上下文记忆 统一纳入同一轮 Agent 决策链中。

5 总结与展望

本文在 v1 自研 ReAct Agent 的基础上，完成了面向 LangChain v2 的架构升级。与上一版本相比，v2 不再关注底层推理文本的手工解析，而是将工程重点转移到 工具建模、系统规则约束、对话记忆维护与业务正确性保障 上。这种演进使系统在实现复杂度、可扩展性与框架适配性方面获得了明显提升。

从当前实现来看，v2 已具备以下核心能力：

商品信息查询能力：可基于 SQLite 返回价格、品牌、库存与规格。
优惠规则检索能力：可从促销文本中抽取目标商品的优惠原文。
安全价格计算能力：可在受控算子范围内完成折扣与满减计算。
多轮对话记忆能力：能够根据历史上下文补全省略信息。
规则一致性控制能力：能够通过系统提示词减少业务解释错误。

未来可进一步从以下方向演进：

优惠检索 RAG 化：将纯关键词匹配升级为向量检索与语义召回。
记忆机制增强：加入长期记忆、摘要压缩与用户画像。
服务化部署：基于 FastAPI 或 Web 服务提供标准接口。
Agent 可观测性增强：接入 tracing、日志和工具调用监控。
多 Agent 协作：扩展为商品咨询、营销推荐、售后解释等协同角色体系。

总的来看，v2 版本代表了该项目从"可运行的 ReAct 原型"走向"面向框架生态的工程化 Agent 系统"的关键一步。