周末被一个 rasa 控制硬件设备的功能所困扰，连做梦都在梳理对话流程。当然是没有搞定。周一早上刷牙的时候，大脑又不自觉地思考起来，我觉得这不是个办法。于是，转而一想，抛开这是个必须完成的任务的角度，如果从我独立开发的角度去看呢？🤔 目前的实现方案为何如此烧脑，是否有更简洁清晰的解决方案。
⚡️ 功能描述
在 rasa 对话流程中， 由 rasa 后端下发一个硬件设备的运行指令 然后客户端软件收到指令后，检测本地设备状态，将数据发给 rasa，rasa 再透传给三方服务器接口，存储数据 rasa 将三方服务接口的调用结果返回给客户端 客户端再控制硬件设备开始运行 运行结束，客户端再将运行结果发给 rasa，再又 rasa 透传给三方服务 这里还有额外的逻辑，真的运行成功或失败，需要调用不同的三方接口。同时判断是否要控制硬件设备重试，或跳过。 这是概要的功能逻辑，还有一些细节逻辑分支没有罗列出来。
❓ 难在哪里
初看，整个逻辑，还算清晰，似乎并没有那么难，以至于周末两天都搞不定的程度。但是，这个实现的前提是，之前已经实现了一版，要将之前的版本重构掉。rasa 开发最令人烦躁的就是，需要逐级梳理现有的逻辑，才能动手修改。而且，这个流程中，还会有更进一步的逻辑分支，例如调用接口失败的处理等等。而且，我感觉这个流程，一旦出现第三次改版，我可能会原地爆炸💥。因为心智成本太高。
为什么不能够更简单一点呢？
让本属于客户端和三方服务直接交互的部分，直接绕过 Rasa 服务即可。不必拘泥于非得让 Rasa 做一个透传。尝试了一下，确实心智负担暴降。所以。。。
❓哪些功能不适合用 Rasa 实现
从我的经验角度来看，这些功能不适合在 Rasa 中去实现：
- 上传图片，文件。例如，对图片 OCR 文字识别
- 本地设备控制。特别是需要处理 N 种状态的情况
- 涉及大量计算、数据处理
- 复杂的界面交互。
回归 NLP，上下文感知的对话逻辑才是 Rasa 的领地。
记录于清晨等车的站点 。。。
查看合集
微信关注我哦 👍
我是来自山东烟台的一名开发者，有敢兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊， 查看更多联系方式