项目周期#
- 2人团队，总计约6个月。
- 需求分析与技术选型1周
- 环境搭建与系统开发8周
- 测试与部署1周
- 基础任务流开发与集成2周
- GraphRAG流程开发1周
- 集成与调试1周
- LLM微调数据准备2周
- LLM微调与评估1周
- 模型部署与测试2周
- 更多任务流扩展4周
技术栈#
- 后端框架：FastAPI+Uvicorn
- 数据库：MySQL（业务数据）
- 图数据库：neo4j
- ORM：SQLAlchemy
- 向量检索：Sentence-transformers
- CLI配置：Click
- LLM集成：LangChain
- 实时双向通信：WebSocket
- Agent框架：LangGraph（状态图编排）
功能介绍#
基于LLM驱动的多轮对话系统和知识图谱构建的智能电商客服系统，主要有以下功能：
提供任务型对话，根据预设流程进行对话，通过多轮对话交互帮助用户完成特定任务，如物流、订单、售后相关业务流程等。
提供知识库问答对话，基于知识图谱和GraphRAG，支持售前产品咨询的复杂问题和多跳推理。
支持话题切换和闲聊，接入LLM支持用户的非业务对话，并对回复内容做出严肃限制，避免涉及敏感内容的回复。
项目架构#
Q总体架构#
Q生成“命令生成模型”的微调数据#
准备覆盖重要对话流程的端到端测试数据，准备命令生成微调数据集。
Q命令生成模型微调与部署#
数据集#
覆盖高频步骤路径与边界场景（如模糊意图、多意图、口语化表达等）。
共计约1万条样本，按8：2划分训练集和验证集。
训练集：8000条左右。
验证集：2000条左右。
模型训练#
Q信息型对话（GraphRAG）#
LLM根据Prompt从用户输入中提取入口节点实体和其对应的类型。
获取入口节点实体和标签之后，使用混合检索从Neo4j中检索出若干候选入口节点。
LLM根据用户输入、候选入口节点、Neo4j的schema信息，生成Cypher查询语句。
将生成的Cypher语句交给LLM进行验证，返回Cypher中的存在的语法与逻辑错误。
LLM根据验证出的错误信息对Cypher进行修正，得到最终的Cypher语句。
执行查询语句，将查询结果返回LLM作为上下文参考。
LLM根据用户输入和上下文参考生成回复。
项目串讲#
这个智能客服项目，本质上是一个基于大语言模型的多轮对话系统，支持任务型对话、知识型对话、闲聊型对话。
它的核心能力是：把复杂的客服业务流程，通过配置文件定义好，然后让大模型理解用户意图，自动执行这些流程。
整个系统最关键的设计思想是：不让大模型直接生成回复，而是让它生成"命令"，由系统来执行这些命令。
这样做的好处是，既能利用大模型强大的理解能力，又能保证业务流程的可控性。
但问题是：
怎么让大模型知道该生成什么命令？
怎么管理复杂的多轮对话状态？
怎么在对话过程中灵活切换不同的业务流程？
这个项目真正的难点其实是：
如何设计一套机制，让系统既能处理结构化的业务流程（比如订单查询、物流跟踪），又能灵活应对开放式的问答和闲聊。
下面我重点讲一下这个系统是怎么解决这些问题的。
一是核心设计：LangGraph 图式编排#
整个对话处理流程，是用 LangGraph 编排成一个图。
图里有 5 个核心节点：understand（理解）、policy（决策）、action（执行）、guard（守护）、response（响应）。
当用户发来一条消息，系统会：
understand 节点：把用户的话交给大模型，让它生成结构化命令#
policy 节点：根据命令决定下一步要执行什么动作#
action 节点：执行具体的动作（比如查数据库、调API）#
guard 节点：检查是否还有命令没执行完，如果有就跳回 policy 继续#
response 节点：把所有执行结果整理成消息，返回给用户#
这个图的精妙之处在于：policy 和 action 之间可以循环多次。
比如用户说"我要查物流，订单号是12345，顺便帮我改个地址"，大模型会一次生成 3 条命令，系统会依次执行这 3 条命令，直到全部完成。
二是 Tracker：对话的记忆体#
Tracker 是整个系统的状态管理核心。
每个用户都有一个会话级别独立的 Tracker，里面记录了：
- 槽位值（比如 order_id=12345、receiver_name=张三）
- 对话历史（用户说了什么、系统回了什么）
- 对话栈（当前在执行哪个流程、执行到哪一步了）
为什么需要对话栈？#
因为对话是会中断和嵌套的。
举个例子：#
用户在查物流（Flow A），中途突然问"你们客服电话是多少"（知识检索），回答完之后要继续查物流。
这时候系统会先把 Flow A 压栈，然后处理知识检索，检索完了弹栈，回到 Flow A 继续。
对话栈让系统能够自然地处理对话中断、嵌套、回退，这是传统状态机很难做到的。
三是Flow：把对话流程配置化#
Flow 是这个系统最核心的机制。
一个 Flow 就是一个业务流程，用 YAML 文件定义，包含多个步骤。
比如订单查询的 Flow，会定义像如下的步骤：
收集订单号（如果用户没说，就问他要）#
查询订单（调用自定义的 action_query_order）#
根据订单状态，决定是显示物流信息还是显示订单状态#
Flow 支持很多高级特性：
- 条件分支：根据槽位值决定走哪个分支
- 嵌套调用：一个 Flow 可以调用另一个 Flow（比如售后流程里调用地址修改流程）
- 动态跳转：根据业务逻辑动态决定下一步
关键是，这些都是通过配置文件定义的，不需要写代码。
要新增一个业务流程，只需要写一个 YAML 文件就行了。
四是命令生成：怎么让大模型知道该干什么#
这是最核心的部分。
系统会给大模型构建一个超级详细的 Prompt，里面包含：
- 当前对话状态（有哪些槽位、活跃的 Flow 是什么、对话历史）
- 可用的 Flow 列表（每个 Flow 能干什么）
- 可用的命令类型（StartFlow、SetSlot、Answer、CancelFlow 等）
- 决策规则（什么情况下用什么命令）
大模型根据这个 Prompt，生成结构化的命令。
比如：
StartFlow(flow_order)
SetSlot(order_id, "12345")
然后系统会解析这些命令，依次执行。
这里有个很巧妙的设计：Prompt 里会动态裁剪内容。
因为 Flow 可能有很多个，槽位也可能有很多个，全部塞进 Prompt 会超长。
所以系统会根据当前上下文，只保留最相关的 Flow 和槽位。
这样既能给大模型足够的信息，又不会超出 token 限制。
五是策略决策：FlowPolicy 和 EnterpriseSearchPolicy#
系统有两个核心策略：#
- FlowPolicy：如果当前有活跃的 Flow，就执行 Flow 的下一个步骤。
这个策略优先级最高，因为 Flow 是明确定义的业务流程，必须优先保证执行。
- EnterpriseSearchPolicy：如果没有活跃的 Flow，就从知识库检索答案，这个策略处理知识和型问答。
两个策略是互补的：#
- 结构化的任务用 Flow 处理，保证业务逻辑的准确性
- 知识型的问答用检索处理，灵活应对各种问题
策略集成器会按优先级选择最合适的策略，如果都不行，就返回"我没听懂"。
六是Action：怎么对接外部系统#
Action 是系统与外部世界交互的桥梁。
当需要查数据库、调 API、执行业务逻辑时，就需要写一个自定义 Action。
比如查询订单的 Action：
可以定义一个Action ，继承抽象基类，实现run函数：
- 读取 Tracker 里的槽位值
- 调用数据库或 API
- 修改槽位值
- 返回响应消息
系统启动时会自动扫描 `actions/` 目录，把所有 Action 注册进来，不需要手动配置。
七是多通道接入：REST、WebSocket、控制台#
系统支持多种接入方式：
REST API：提供标准的 HTTP 接口，可以集成到任何前端
WebSocket：实时双向通信，适合需要即时反馈的场景。比如客服系统，需要实时推送订单状态变化。
Inspect 调试页面：Web 可视化界面，可以：
- 查看对话栈的变化
- 查看每一步生成的命令
- 手动修改槽位值
- 重放历史对话
这个调试页面对开发非常有用，能直观地看到系统内部是怎么运行的。
八是CLI 工具：从初始化到部署#
系统提供了一套完整的命令行工具：
- init：初始化项目，生成目录结构和配置文件
- train：训练模型，把 Flow 定义、对话样本打包成模型文件
- run：启动服务，提供 REST API 和 WebSocket 接口
- inspect：启动调试页面，可视化查看对话流程
整个流程非常顺畅：init 创建项目 → 编写 Flow 和 Action → train 打包模型 → run 启动服务 → inspect 测试调试 → run正式启动。
这个系统的核心设计思想就三点：
命令驱动：大模型生成命令，系统执行命令，既灵活又可控#
Flow 配置化：业务流程用 YAML 定义，不用写代码，易维护易扩展#
对话栈管理：用栈结构管理对话上下文，自然处理中断和嵌套#
技术亮点：#
- LangGraph 图式编排，让流程清晰可控
- Tracker 统一状态管理，避免状态不一致
- 多策略融合决策，灵活应对不同场景
- 自动发现和注册机制，开发体验友好
- 完整的工具链支持，从开发到部署一站式
对于开发者来说，这个框架提供了一个强大的基础设施，可以快速构建各种对话应用。
无论是客服机器人、任务助手、还是知识问答系统，都能轻松实现。