在Where is the data context in Dialog Flow (API.ai)中，我询问了如何保留用户特定的数据 . 例如，用户要求提供城市列表，并且webhook服务随机选择三个 . 如果您想稍后再参考此列表中的某个城市，则需要以某种方式存储它 . 问题的答案是它可以在上下文中来回传递 .
现在我阅读文档中的用户实体 . 这对我来说是一个未知的概念 . 我现在的问题是：我们是否也可以使用用户实体进行此类流程？例如：
-
用户要求3个城市 .
-
调用Webhook并选择3个随机城市 . 此时，webhook服务还通过REST API为正在进行的会话创建用户实体
@user-cities. 我们甚至可以将SQL标识符作为密钥，将城市名称作为可能的同义词 . -
在后面的意图中，我们引用
@user-cities作为参数 . 当基于其先前的城市列表的有效城市被提供给webhook服务时，将提供标识符 . 然后，webhook服务可以使用此标识符提供有关城市的其他信息 .
示例流程：
User: Please provide me some interesting cities.
Agent: What about New York, Berlin and Barcelona?
User: Please tell me more about Barcelona!
Agent: Sure, Barcelona is ...
我还没有尝试过，但我想知道这是否是用户实体的一个很好的应用？后续问题是：您何时使用用户实体？何时将数据保存在上下文中？
1 回答
虽然这可行...但有点......用户实体并不是一个很好的应用程序 . 最大的问题是，您现在正在进行API调用，以创建“this”或“that”或“first first”等术语的别名 . 而且您不断更改这些实体定义，包括删除旧别名和设置新别名 .
用户实体最适合您了解该用户与其他用户不同的内容 . 以您的城市为例，您可以使用用户实体存储一个人's favorite cities or any nicknames they have for those cities. Once the user logs in, you' d然后设置
@user_cities，他们的城市昵称现在可用 .Update 再次使用您的城市框架使用另一个示例 .
选择后，您可以更改特定城市的功能和别名的用户实体 . 因此，如果用户选择"Sydney"，您可以创建一个包含歌剧院或海滩的条目的
@feature用户实体，但不包括钟楼的任何内容 . 虽然对于"London"我们可能会添加关于塔和桥的实体，但不是海滩 .重点是您希望从用户那里听到的内容与您想要记住的关于会话的内容 .