设计一个小框架考虑的东西真不少，每一样都不容易：
1、既要解决当前技术的不足；
2、又要方便他人使用（主要的目的）；
3、同时又要设计得优雅，容易扩展；
sophia一开始设计用来支持智能回复（文本可以带参数的回复），后来又支持菜单，并统一了菜单和文本命令的处理逻辑，
再后来看到微信客户端的交互元素太少，又支持html页面操作和微信客户端的会话（即页面操作可以知道是哪个微信号操作的）
对于如何维系两个不同类型消息（命令）之间的关系？对sophia来说有点吃力。即，前面是一个文本（命令），后面是一个其他类型的消息。
比如，某街道办让我们开发一个居民登记公众平台，主要流程如下：
1、订阅者输入：登记
2、公众平台提示：请输入姓名：
3、订阅者输入：张三
4、公众平台提示：输入身份证号码：
5、订阅者输入:xxxxxxxxxxxxxxxxxx
6、公众平台提示：请上传免冠相片：
7、订阅者上传相片。
8、公众平台提示：登记成功！
订阅者经过多次文本输入和图片上传后，公众号如何保证前面的文本信息和最后的图片是同一个人的？
如果看了sophia的源代码和设计后（参阅我前面的文章）会发现sophia无法做到？因为我一开始就把sophia设计为处理文本消息的框架。
现在，如果要解决这个问题，那么：
1、首先把所有的消息（文本、视频、语音、图片、地理位置等，或者说每种交互）都认为是一种命令，让框架都有机会处理；
2、其次要修改会话管理逻辑；
插播：
消息的多样性：指同一种类型的消息，可以根据内容来解析出不同的命令，比如文本消息具有这个特性。
像图片无法解析出不同的内容，所以没有多样性（用图像识别、语音识别技术除外）。这个概念会影响我们的设计。
1、由于文本消息具有多样性，其对应的命令类就可以有不同的子类型。而非文本消息，只能有一个命令类，合适吗？
2、如果把非文本消息作为文本消息的特殊类型，又如何？
初步考虑扩展将文本命令类增加一个标记（支持后继是非文本消息继续处理），如果公众平台收到非文本命令时候要检查一下session中是否存在文本命令对象是否支持后继非文本消息处理，然后调用此对象继续处理。
