阿丹：
其实在整个rasa中的关键元素和关键的核心在前面多多少少也涉及到了很多，这里就是开始涉及到了rasa的训练核心core。
Rasa Core:
Rasa Core 是Rasa框架中的一个组件，它负责处理对话管理部分，即决定对话流程中机器人的下一步行动。Rasa Core使开发者能够根据用户的输入、对话历史以及定义好的业务逻辑来设计和实现复杂的多轮对话。它利用机器学习策略来决定最佳的响应动作，同时也支持手工编写的规则。Rasa Core现已与Rasa NLU合并为统一的Rasa框架，但在旧版本中，它是独立存在的。
在Rasa中，管理和配置主要通过以下几个核心的YAML配置文件来完成：
-
config.yml: 这个文件主要用于配置Rasa的NLU（自然语言理解）和Core（对话管理）部分。它定义了NLU处理流程（例如，使用哪些组件进行文本预处理、实体提取、意图识别等）以及对话策略（如选择哪种算法来决定对话的下一步行动，如MemoizationPolicy、KerasPolicy等）。
-
domain.yml: Domain文件描述了机器人的“领域”，包括所有可能的意图、实体、槽位（slots）、回应模板以及机器人的行动空间。它定义了对话的上下文结构和机器人可以执行的操作。
-
stories.yml: Stories用于定义对话流程的故事脚本，描述了用户和机器人之间可能的交互序列。每个故事是一系列的用户意图和对应的机器人行动，帮助Rasa学习和模拟实际对话场景。
-
endpoints.yml: 此文件配置了与Rasa系统交互的各种外部服务的端点，如数据库、API、消息队列等。这对于连接到自定义的动作服务器、训练数据源或日志记录服务尤为重要。
随着Rasa框架的更新迭代，配置文件的结构和命名约定可能会有所变化，特别是从Rasa 2.x迁移到Rasa 3.x的过程中，部分配置方式和文件结构进行了调整和优化。因此，在使用特定版本的Rasa时，建议参考该版本的官方文档来获取最准确的配置信息。
Introduction to Rasa Open Source & Rasa Pro
其实整个rasa Core就是这个下面这两步的合成。
会根据很多状态来获取以及拿到推理出具体的任务和行为
流程图示
具体流程，在这里的模型rasa是可以提供自己选择的。
具体的行动，在这里的行动rasa是可以支持去调用api的
在去设计意图的时候，要在前期要涉及到当机器人识别到了意图之后要进行什么样子的活动。
一般来说这里是产品经理来预设好的。
整个action分为了四种：
responses:回应
default actions:默认的回应
forms：表单、一般是用来做任务的
custom actions:是我们用来做一些复杂的逻辑、知识库、知识图谱（高级）
配置文件中的domain.yml组成了解
在使用rasa init初始化的时候就会自动生成一个domain.yml
整个项目中的intents（意图）都有哪些，这里要列举出来。
这里就是responses回复
如何理解responses:
当识别到意图之后将下面的text返回。
整个response识别触发顺序为：
子意图-触发回应检索：
在前面增加前缀的方式来完成
使用变量的反应（高级使用-根据实体）-模板：
使用大括号{}的方式来获取变量，这里使用的实体就是我们在之前在nlu中标记出来的实体。
当在模板中有多个的模板的时候会给随机的模板回复。
特殊的渠道相应配置文件为：credentials.yml：
动作:通道特定响应
在domain.yml中设置渠道的回复，在 credentials中标记和创建通道
行动：丰富的相应方式！Rich Response
针对返回比如果是一个表单，一个数据等
这个方式要支持交互（前端）
点击buttons触发一个另外一个意图。
回复一个图片
使用这个custom output payloads可以指定返回值，这里需要前端去解析等这些
Custom Output Payloads
responses优先级会更高一些。
Forms
在做任务的时候需要填写一个表单，所以需要我们去定义一个form
在domain文件中定义一个表单
要构建表单来收集信息。
注意：如果想使用form的action就要在config.yml中的policies中添加对应的配置才可以。要给RulePolicy添加到配置文件中去才可以。
因为默认是不支持这个特性的。
使用stories来完成这个form的激活。
这里很人性的是需要用户填完所有的表单才可以进入下一个action。
但是提供了一个取消循环的操作（见文档）。
https://rasa.com/docs/rasa/forms
Story像是一个规则
会遵循规则对话！
是通过intent和action来讲一个故事
Rules
规则。
注意！：在基础的模型中是不支持的。
需要在config.yml中的policies中添加配置
-name: RulePolicy
就可以支持了
注意：在rules中的顺序为钉死的。
它和story的区别是story有一定的泛化能力，但是rules是没有的是严格执行的。
要明确rule使用的业务点，不然会耽误story的能力。
Rules with Conditions
在规定情况下的规则
在一些条件下面触发role
用例为在用户的名字被填充的时候才触发这个规则
Story
官方介绍：
总结：
在Rasa中，rules, stories, responses, 和 actions 是构建复杂对话系统的四个关键组成部分，它们之间有着紧密的联系，共同定义了机器人如何理解和响应用户的消息。下面是这些组件的基本概念及其相互之间的关系：
-
Stories: Stories描述了用户与机器人之间的一系列对话交互，从用户的初始意图开始，一直到对话结束。每个story代表一个具体的对话流程，由多个用户消息（intent和entities）和机器人响应（通常通过actions触发）组成。Stories帮助Rasa学习对话流程并预测接下来的最佳行动。
-
Rules: Rules在Rasa中是一种更直接的方式来定义特定条件下的自动化行为，通常用于简单且明确的逻辑，比如直接基于某个intent或实体的响应。Rules可以看作是Stories的简化版本，适用于那些不需要复杂决策树的场景。当满足规则条件时，机器人会执行指定的操作，比如发送一条消息或调用一个action。
-
Responses: Responses是机器人用于回复用户的预定义消息。它们可以包含简单的文本、富媒体内容或其他动态生成的信息。在Stories和Rules中，通过引用response的名称，Rasa会在相应的对话节点触发这些预定义的回复。Custom Actions也能动态生成responses。
-
Actions: Actions是Rasa中定义的函数，用于执行特定任务，比如检索信息、更新对话状态、发送复杂响应等。Actions可以是默认内置的（如
utter_<response_name>用于发送预定义的responses），也可以是自定义的（通过Python代码实现）。在Stories和Rules中，通过触发特定的action来控制对话的流程和内容。
关系总结:
- Stories和Rules描述了对话的流程，其中Stories更加灵活和复杂，适合多路径对话；而Rules适用于简单直接的逻辑处理。
- Responses作为机器人的回复内容，被Actions（特别是
utter_开头的actions）所引用，以实现消息的发送。 - Actions是执行具体任务的单位，既可以是简单的消息发送（通过responses），也可以涉及复杂的业务逻辑处理，是连接用户输入、对话管理与输出响应的核心桥梁。
综上，这些组件协同工作，共同构建了一个能够理解用户意图、管理对话状态并做出适当反应的对话系统。
