在Where is the data context in Dialog Flow (API.ai)中，我询问了如何保留用户特定的数据。例如，用户要求提供城市列表，并且webhook服务随机选择三个。如果您想稍后再参考此列表中的某个城市，则需要以某种方式存储它。问题的答案是它可以在上下文中来回传递。
现在我阅读文档中的用户实体。这对我来说是一个未知的概念。我现在的问题是：我们是否也可以使用用户实体进行此类流程？例如：
@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 ...
我还没有尝试过，但我想知道这是否是用户实体的一个很好的应用？后续问题将是：您何时使用用户实体以及何时将数据保留在上下文中？
答案 0 :(得分：3)
虽然这可行...但有点......它并不是用户实体的良好应用。最大的问题是，您现在正在进行API调用，以便为＆＃34;这个＆＃34;等条款创建一个别名。或＆＃34;那＆＃34;或者＆＃34;第一个＆＃34;。并且您不断更改这些实体定义，包括删除旧别名和设置新别名。
用户实体最适合您了解该用户与其他用户不同的内容。以您的城市为例，您可以使用用户实体存储一个人最喜欢的城市或他们为这些城市拥有的任何昵称。用户登录后，您就会设置@user_cities，并且现在可以使用他们的城市昵称。
<强>更新 要使用另一个示例，请再次使用您的城市框架。
一旦选定了特定城市的特征和别名，您就可以更改用户实体。因此，如果用户选择＆＃34;悉尼＆＃34;，您可以创建一个@feature用户实体，其中包含歌剧院或海滩的条目，但不包括钟楼的任何内容。而对于＆＃34;伦敦＆＃34;我们可能会添加有关塔楼和桥梁的实体，但不能添加海滩。
重点是您希望从用户听到的内容与您想要记住关于对话的内容。