具备基于上下文的对话能力 (contextual conversation)
具备理解口语中的逻辑 (logic understanding)
所有能理解的需求，都要有能力履行（full-fulfillment）
1、基于上下文的对话能力(contextual conversation)
在当前，做助理的产品的底层技术基本都是围绕NLU（自然语言理解）打造的，很多还没有涉及到NLP。可是无论是大公司还是小公司的NLU都是让人失望的。举个简单的例子，在大公司的几个产品上提出需求：我下周五要去北京，帮我查一下航班。
需要识别意图：查机票
需要识别entities：时间（下周五），目的地（北京），出发地（无/当前地理位置）
我们看看结果，首先看三家的回复，从左到右分别是苹果的SIRI, 微软的CORTANA, Google的ALLO。
没有一个能识别出来意图，全部做为用关键词来检索网页(SERP)。没有识别出意图，继而也就没有可能识别entity所在的场景。对于C端用户而言，这可能算是最基础的服务之一，而三大巨头提供的产品完全不能用。
不过当我们看到国内的创业公司，却能按照需求识别出意图，并且识别出对应的entity，组合查询出结果，看上去比几个巨头更强大。
我们继续测试上下文的对话。比如，我是国航的会员，agent给出上面的结果里没有国航的航班，我自然会问：”有没有国航的？“
结果并没有如期望那样，在给出的列表里找到国航的航班。而是开始了重新的一次查询。
换一句话来说，没有结合上下文的对话。我并不是为了黑，事实上这个产品在国内的创业公司中也算不错的技术了。但是不会结合上下文的对话，会造成的最严重的问题就是这个agent基本不能独立完成服务。因为用户不会在一个句子里把所有的条件都列出来。
以上是基本要素，就当前的产品形态来看，只有非常少的产品能真正做到第一点。大部分号称能做到的，都是滥竽充数，连续问问题而已。
不能真正理解上下文的对话（机票查询）：
AGENT： 从哪里出发？
用户：上海虹桥机场
AGENT：到哪里？
用户：还是从浦东走吧
AGENT：好的，从虹桥出发到浦东的航班是......
在上面的对话，AI Agent在问第二个问题的时候，不能理解用户对前一个回答的修改（出发地从“虹桥”改为“浦东”），只是按照预先设计对话的顺序，填上命名实体识别得来的entity。继而查询不到结果，给用户的感觉就是笨。
真正理解上下文的对话（机票查询）：
AGENT：从哪里出发？
用户：上海虹桥机场
AGENT：到哪里？
用户：算了，从浦东走吧
AGENT：好的，出发改为浦东。那到达城市呢？
用户：北京
AGENT：好的，从浦东到北京的航班是...（给出正确的结果）
而具备真正上下文理解的对话，agent可以正确理解用户第二个回答的内容（从浦东走），其实是在修改上一问题的回答（出发机场），而不是真的在回答第二个问题（到达地在哪里）。
这只是上下文的例子，而对于服务类agent而言，所有后续的NLP功能都基于上下文对话为前提。这些看上去其实都是非常简单的需求，但是当前没有任何一个2C的agent可以做到。
可能有人会问，大部分用户都应该在第一时间把需求表达出来吧，为什么还需要对话？实际上，真正操作过大量案例的同学就会发现，用户不可能如此”贴心“地按照开发者的设计来提出需求。