Rasa框架闲聊机器人Python毕业设计：从意图识别到完整部署

简介：这是一份基于Python开发的闲聊型AI机器人对话系统毕业设计源码，定位清晰，面向计算机相关专业学生的毕业设计、课程设计、期末大作业，也适合希望掌握完整Python项目结构的初学者。项目已通过高分验收，具备实际参考价值。压缩包共28个文件，主要包含10个YAML配置文件（用于管理对话流程与领域意图）、3个Python核心逻辑脚本（实现对话响应处理）、3个JavaScript前端交互文件（构建聊天界面）、2个JSON数据文件（存放对话样本或配置），以及HTML/CSS样式、项目说明、部署教程等，整体仅646KB，轻量且组织有序。平台显示已有306人学习下载，说明该资源在同类项目中具有一定热度与参考价值。系统功能完善，界面美观，操作简单，代码注释详细，新手也能读懂AI闲聊背后的意图识别与应答逻辑。资源内含数据库脚本、软件工具及分步部署教程，所有代码经严格调试可正常运行，可直接用于毕设答辩或课程设计提交。

1. 闲聊型AI机器人：一套能完整落地的Python毕业设计

做Python毕业设计最怕的不是功能复杂，而是做完之后导师问一句「它到底跑没跑通」。这套基于Rasa框架搭建的闲聊型对话系统，恰好踩中了大多数课程设计和毕业设计的需求点：有完整的NLP管道、有可自定义的意图识别、有Web聊天界面、有部署说明，并且已经通过了某高校的毕业答辩。上手之后最直观的感受是，它不是那种只有几个py文件拼凑的玩具，而是一个能支撑三层对话结构的系统化项目。

更难得的是，项目里包含了代码注释和部署教程，即使没系统学过Rasa，也能按步骤把机器人从训练到对话完整跑起来。适合三类人：准备做毕设但还没定方向的应届生、想拿Rasa做课程设计的在校生、以及想快速上手一个对话系统模板的Python开发者。闲聊类机器人看起来简单，但真要做得有「对话感」，反而比垂直领域的FAQ机器人更考验对意图、实体、上下文这些基础概念的把握，这套源码把整条链路都串起来了。

2. 拆开Rasa项目骨架：domain.yml、config.yml 与 actions 各自管什么

拿到源码包解压之后，根目录下是ai_chitchat-main文件夹，一眼扫过去就能看到config.yml、domain.yml、credentials.yml、endpoints.yml、actions、data这些Rasa项目的标准成员。很多人第一次接触Rasa会被它拆得七零八落的目录结构唬住，实际上这恰恰是它对工程化的坚持——对话系统本来就不该是一个脚本里塞满if-else的东西。

2.1 domain.yml：对话系统的「总纲」，先读它再读代码

domain.yml是整个项目最先要打开的文件。它定义了这台AI机器人能听懂什么、能输出什么、能执行什么。以这份闲聊源码为例，里面通常会有intents（用户意图）、responses（机器人的回复）、actions（可执行的自定义动作）三大块。理解它的关键在于，Rasa认为一段对话的本质是「意图 → 槽位 → 动作 → 回复」的循环，而domain.yml就是把这四样东西登记在案的清单。

intents: - greet - goodbye - ask_weather - ask_name - chitchat: triggers: action_chitchat entities: - city slots: city: type: text mappings: - type: from_entity entity: city responses: utter_greet: - text: "你好呀，我是闲聊机器人，随便聊点什么都行～" utter_goodbye: - text: "回头见，有空再来找我玩！" actions: - action_chitchat

这段配置的逻辑是：先声明机器人能接收哪些意图，其中ask_weather这类带实体的意图需要预留city槽位来接收地名；chitchat不是直接回复，而是触发action_chitchat去执行一段自定义Python逻辑。很多新手会漏掉actions这一块，结果训练时报「Action not found」——因为Rasa根本不知道你在说什么。

2.2 config.yml：决定训练效果的那几行参数

这个文件决定了模型用什么「学习方法」。源码里的配置会针对中文闲聊场景做调整，有几个参数值得仔细看：language指定语言代码，pipeline里有WhitespaceTokenizer、CountVectorsFeaturizer、DIETClassifier这组经典组合。中文不像英文天然按空格分词，所以WhitespaceTokenizer配合分词器是必须的。

language: zh pipeline: - name: WhitespaceTokenizer - name: CountVectorsFeaturizer - name: CountVectorsFeaturizer: analyzer: char_wb min_ngram: 1 max_ngram: 4 - name: DIETClassifier epochs: 100 constrain_similarities: true policies: - name: MemoizationPolicy - name: RulePolicy - name: TEDPolicy epochs: 100

DIETClassifier的epochs决定了训练迭代轮数，100轮是均衡速度和精度的常见做法。constrain_similarities: true能让向量空间分布更紧凑，减少意图误判。策略部分MemoizationPolicy负责精确匹配训练数据中的对话路径，RulePolicy执行rules.yml里写死的规则，TEDPolicy则用深度学习预测多轮对话走向。闲聊场景里RulePolicy尤其重要——凡是不希望机器人「自由发挥」的环节，都需要规则兜底。

2.3 actions 目录：机器人「动手」的地方，写逻辑而不是写死回复

打开actions目录，里面是真正的Python代码。闲聊型机器人如果只用utter_xxx回复，那跟.txt文件没区别。有了action_chitchat，你可以在里面接天气API、查数据库、调用外部服务，让机器人不止会「说」，还会「做」。

from typing import Any, Text, Dict, List from rasa_sdk import Action, Tracker from rasa_sdk.executor import CollectingDispatcher class ActionChitchat(Action): def name(self) -> Text: return "action_chitchat" def run(self, dispatcher: CollectingDispatcher, tracker: Tracker, domain: Dict[Text, Any]) -> List[Dict[Text, Any]]: # 取出用户当前输入 user_input = tracker.latest_message.get("text") # 这里可以接你自己的问答库，或第三方闲聊API # 演示逻辑：把用户说的话原样回显，加个emoji reply = f"你刚才说的是：「{user_input}」，听起来很有趣！" dispatcher.utter_message(text=reply) return []

tracker.latest_message.get("text")是拿用户上一条输入的标准姿势，这个tracker对象贯穿整段对话，可以用来跨轮次取历史消息。常见做法是先做个基于关键词匹配的本地闲聊库，跑通了再替换成外部API，这属于「先让它动起来」的工程思维。

2.4 credentials.yml 与 endpoints.yml：连接外部通道的关键

credentials.yml默认是空的，表示用命令行本地测试。当你要接入微信、钉钉或者自定义Web界面时，需要在这里填写对应平台的AppID和Secret。endpoints.yml则负责声明action_endpoint的地址，默认是http://localhost:5055/webhook。

action_endpoint: url: "http://localhost:5055/webhook" tracker_store: type: sql dialect: sqlite db: conversations.db

后半段tracker_store是容易被忽略的配置。默认Rasa把对话状态存在内存里，进程一重启就全忘了。加上这段SQLite存储后，每次对话记录都会落到conversations.db文件里，调试和答辩演示时能翻出历史记录，算是个不大不小的加分项。

3. 把它跑起来：从空环境到能在命令行跟机器人聊天

这部分是整套源码复现的重头戏。下载源码包之后，不要急着pip install rasa，先看清楚ReadMe.md里推荐的版本。Rasa各版本之间的差异能够直接让你从「本来跑得好好的」变成「突然全是红的」。

3.1 环境准备：Python版本和虚拟环境是第一道门槛

Rasa3.x 要求 Python 3.8~3.10，源码包里大概率是3.x版本。第一步先建独立虚拟环境，不要直接在全局环境里装，否则依赖冲突会烦死你——这是血泪经验。

python -m venv rasa_env source rasa_env/bin/activate # Windows 用 rasa_env\Scripts\activate pip install --upgrade pip pip install rasa==3.6.2

装完后用rasa --version检查安装情况。注意：如果项目里带了requirements.txt，直接用pip install -r requirements.txt更保险，版本是锁定好的，能少踩一半的坑。安装过程如果遇到microphone相关报错，那是缺少系统音频库，跟对话功能无关，可以直接忽略。

3.2 训练模型：让机器人先「开窍」

训练前需要确认data目录下面有nlu.yml、stories.yml、rules.yml三个文件。这是Rasa成长的「教材」，没有它们模型就是一张白纸。这三个文件的分工是：nlu.yml提供意图识别语料，stories.yml提供多轮对话样本，rules.yml提供不可动摇的固定规则。

rasa train

执行后控制台会输出模型训练的实时损失值。看到DIETClassifier的 loss 下降、准确率曲线上升，说明模型在学东西。训练完成后在models目录下会生成一个带时间戳的.tar.gz文件。如果训练中报ValueError: Training data is empty，那就是data目录里的yml格式写错了，用rasa data validate先检查一遍格式。

3.3 启动服务并验证：先重复用命令行会话测试

训练完成后，需要同时开两个终端。第一个终端启动Action Server，第二个终端启动对话测试。

# 终端一：启动action服务 rasa run actions # 终端二：启动对话模式 rasa shell

rasa shell启动后，会出现一个Your input ->的提示符。尝试输入「你好」，如果机器人返回了utter_greet里定义的回复，说明整条链路已经通了。测试时要故意输入一些不在nlu.yml训练数据里的句子，比如乱敲几个词，观察机器人会不会给出有礼貌的兜底回复，而不是报错。

3.4 修改闲聊内容：为什么你改了domain.yml却不生效

最常见的翻车场景是：在domain.yml的responses里改了文字，重新rasa train后机器人还是说旧话。原因在于Rasa的stories.yml里可能把旧的utter_xxx直接写进了对话样本，导致模型记住了旧路径。正确姿势是：

1. 修改domain.yml中responses的文本
2. 同步更新stories.yml里对应的对话路径
3. 重新执行rasa train

如果只是微调回复文字，不想重新训练整个模型，可以用增量训练命令，但这个操作对语料格式要求很高，新手不建议碰。改完记得跑一遍rasa test检查有没有断掉的对话路径，这个命令会自动评估模型在测试集上的表现。

4. 让界面不再是黑匣子：Web前端与Rasa后端的Socket.IO联通

命令行跑通只是第一步。毕设要演示效果，必须有个看得见的聊天界面。这套源码包里带了src、public、views、webpack.config.js、package.json，说明前端是一个成熟的构建工程，不是那种写死的静态HTML。

4.1 前端项目构建：npm install 的前后要做的事

先把前端的依赖装上。源码包里既然有package-lock.json，说明依赖版本已经锁定，直接用npm不会出现大的偏差。

npm install npm run serve

如果之前没装过Node.js，需要先装Node 14以上版本。npm install过程可能会比较慢，淘宝镜像能加速，但不要混用yarn和npm，否则package-lock.json会被改写，后续会出现诡异报错。首次启动后浏览器打开localhost:3000，此时看到的界面是「前端空壳」，后端还没有连接。

4.2 Socket.IO通道填坑：前端和后端各说各话

前端和Rasa之间的通信，常见做法是启动一个rasa run --enable-api --cors "*"的HTTP服务，然后前端通过WebSocket把消息转发过去。这套源码里用的是Socket.IO，好处是表情包、输入状态、打字动画这类「对话感」功能能更顺滑地实现。

rasa run --enable-api --cors "*" --port 5005

前端src目录里通常会有一个socket.js或类似的配置文件，负责建立Socket.IO连接。连不上时先检查后端是否开启了--cors "*"，因为浏览器安全策略会把没带跨域头的WebSocket请求拦截掉。这里有个细节：后端启了CORS，前端还要确保socket地址写的是http://localhost:5005而不是localhost:5005，别小看这个http://，省略后Socket.IO会默认走HTTPS，导致握手失败。

4.3 联调流程：从浏览器到Action Server的完整闭环

联调建议按下面这个顺序操作，每条链路验证过了再往前走：

1. 终端A：rasa run actions，确认5055端口在监听
2. 终端B：rasa run --enable-api --cors "*" --port 5005，确认5005端口在监听
3. 终端C：npm run serve，打开浏览器，进入聊天页面
4. 在聊天框输入「你好」，观察三个终端是否有请求日志

如果前端显示「Could not connect」，优先检查credentials.yml里socketio通道是否被注释掉了。Rasa默认不开启Socket.IO通道，需要在credentials.yml里加上下面这段配置：

socketio: user_message_evt: user_uttered bot_message_evt: bot_uttered session_persistence: true

加完后重启rasa run，前端才能正常收发消息。这一条不知道让多少人的毕设卡在「前端文本框发送没反应」的尴尬状态，踩坑次数极高。

5. 落地避坑记录：五个最容易翻车的点

5.1 现象：rasa train报错，提示版本号不匹配

做毕设时拿到这套源码，开了个新虚拟环境想直接用，结果rasa train一跑就报ModuleNotFoundError，有些包还提示版本不够新。

原因：本地pip install rasa默认装的是最新版Rasa，而源码是按3.x版本写的，新版Rasa改了不少API，尤其是domain.yml里slots的mappings写法，新旧之间存在不兼容。解决：严格按照源码包里ReadMe.md标注的版本号创建requirements，不要贪图新版。我一般会先读ReadMe.md里有没有rasa==这样的固版声明，没有的话再看actions目录源码里的import方式，能猜出大致版本范围。

5.2 现象：训练成功后，机器人对「你好」没有反应

模型训练没报错，但输入「你好」时机器人回复的是「我不知道你在说什么」之类的话，而不是预期的问候语。

原因：nlu.yml中的语料和domain.yml中的intents名称不一致，或config.yml里用了WhitespaceTokenizer但没有在语料里给中文分词，导致模型根本没学会「你好」属于greet意图。解决：用rasa data validate检查语料文件报错，然后把中文语料逐条改成分词格式，比如「你好」写成「你好」——Rasa3.x 对语言数据的处理方式已经内置了中文支持，但要确认config.yml里确实写了language: zh，并且每一条 nlu 样本都带正确的 intent 标记。

5.3 现象：Action Server 报错，Failed to execute custom action

对话测试时，只要触发action_chitchat，终端一就报错Could not find any action或The server has not started。

原因：endpoints.yml里没写action_endpoint，或写了但地址跟启动的端口不一致。常见做法是让Action Server跑在5055端口，而有人把它改成了5050，结果两边对不上。解决：先检查endpoints.yml的url是否为http://localhost:5055/webhook，再用rasa run actions --port 5055显式指定端口。还有一个隐藏坑：修改actions目录的代码后，必须重启Action Server进程，Rasa不会热加载自定义Action。

5.4 现象：前端能打开，但发消息没反应

Web界面打开了，输入框也能打字，但点了发送后气泡不出现，控制台还显示Connection refused。

原因：典型的credentials.yml里没配socketio。Rasa默认只启用HTTP API，不启用Socket.IO通道，前端连不上是正常的。解决：在credentials.yml里加上4.3节的那段配置，重启rasa run进程。检查完这个如果还不行，再看浏览器控制台的报错是不是Mixed Content——HTTPS页面请求HTTP接口会被浏览器直接拦掉，把页面从localhost改成127.0.0.1试试。

5.5 现象：多轮对话时机器人「失忆」，答非所问

聊了三轮之后，机器人突然记不住之前说过的地名，甚至把上一轮的意图当成当前轮次来处理。

原因：stories.yml里的对话路径不够，或者RulePolicy和TEDPolicy冲突了。当规则和模型预测产生矛盾时，光靠MemoizationPolicy兜不住变化超多的闲聊场景。解决：给关键槽位加上slot_was_set的事件约束，在stories.yml里显式写出带槽位的多轮路径。另外确认domain.yml里每个slot都有mappings，没有influence_conversation: false的槽位会持续参与下一轮预测，干扰意图识别。

6. 闲聊质量进阶：Fallback兜底、上下文记忆与回复多样性

模型跑通、界面联通只是及格线，要让答辩时导师觉得这系统「有点东西」，至少要在三个点上做文章。

第一个点是Fallback兜底策略。默认情况下，遇到nlu.yml里没见过的句子，Rasa会直接说「我不明白」。这很下头。更专业的方案是在config.yml里加一个FallbackClassifier，并设置一个阈值，当意图置信度低于某个值，比如0.7，就自动走action_default_fallback。我一般还会在这个action里做一个「梯度式回复」：第一次不确定就说「我没太听懂」，第二次再不确定就主动抛话题，比如「换个话题吧，聊聊天气怎么样？」。这样一来，机器人不会轻易「死机」。

第二个点是上下文记忆。当前源码的tracker_store配的是SQLite，数据是持久了，但对话逻辑里还没真正用到历史信息。可以扩展action_chitchat，从tracker.events里提取最近几轮的主题词，存进一个列表，下次用户提到「刚才那个」时，能精准指代到上一轮聊的内容。

# 在action中取最近5轮的用户输入，存进上下文列表 recent_messages = [] for event in tracker.events: if event.get("event") == "user": recent_messages.append(event.get("text")) # 用recent_messages[-5:] 参与回复生成

第三个点是回复多样性。有一个很常见的体验问题是：同一句「你好」，机器人每次的回答都一样，容易让评委觉得「这像查表」。在domain.yml的responses里，同一句话可以写多个变体，Rasa会随机选一条返回。

responses: utter_greet: - text: "你好呀，今天过得怎么样？" - text: "嗨，来聊点开心的事吧！" - text: "你好，有什么新鲜事想跟我说吗？"

答辩前我习惯把这三步走一遍，最后用rasa test跑一遍端到端测试，确保模型精度没被改动拖垮。这套源码最让我意外的就是它把工程化思维完整保留了，做完调优后回头再看，毕设的产出不只是一段对话脚本，而是一套能继续接API、换业务场景的架子。从那以后我每次拿到类似的开源对话项目，都会先强制走一遍「读domain → 验数据 → 全链路联调 → 加兜底与记忆」的流程，省下的时间远不止重新造轮子那点功夫。希望帮到你。

本文还有配套的精品资源，点击获取