这个的需求”。比如当用户提出“推荐餐厅的需求”：

用户：“女朋友周日过生日，推荐一个餐厅，找有江景的，最好桌子旁边有一个大落地窗户，能看到外面的夜景。吃的不要太贵，环境好点，有现场音乐的最好是爵士，不要太吵的。”（btw，这是一个真实需求）

Agent：“菜系有偏好么？”

用户：“意大利餐和法餐都可以，对了不要离外滩太远了”

agent解析出以下选择餐厅的条件：

周日晚（营业）

适合女朋友过生日

有江景

有大落地窗

不要太贵

环境好

有现场音乐，爵士

不能太吵

意大利餐或者法餐

距离外滩不能太远

然后它去哪里找到这样的餐厅呢？在地图服务提供商，或者点评的API提供的信息里只有8，9，两项能找到数据。假设评论中有这样的数据，该用什么方式来传递呢？接口提供的都是结构化的数据，而“环境好”这样的非结构化数据，最多以标签的方式来做，但是这样的话，标签就会有无止境的多也不现实。

这就是我们所谓的“API困境”——当前基于API的数据传递方式，只能1）承载结构化数据；2）承载数量非常有限的结构化数据。当前基于GUI的产品，都是用API来传递结构化数据。但大量个性化数据往往是非结构化的，以当前API的方式很难被处理。这还是在使用场景或者服务比较简单的情况下。

在用户不熟悉的场景下，agent面对稍微专业一点的服务，就会遇到知识图谱的问题。简单来讲，agent要做推荐的前提是对推荐的内容得先有了解。好比，要向一位不懂酒的用户推荐一款威士忌，那就不能依赖这位用户自己提出的问题（很可能提不出要求），而得依赖“懂行”的自己对威士忌的理解的方方面面来引导用户做合适他的选择。一个助理显然无法拥有所有服务所需的知识图谱。

从知识图谱的结构来看，是相对可被结构化。一个服务可以以各种方式被拆解成很多个方面，但大量的方面在当前是没有结构化数据的（比如我们没有每家餐厅的“营业面积”的数据）；甚至很多方面无法用结构化数据来表达（比如每家餐厅有否“适合浪漫约会”的环境）。

因此，智能助理就算有了强大的NLP，还需要全面的知识图谱（结构化数据）和处理并传递非结构化数据的能力——而这两点，在目前是无解的。

-总结-

在"API困境"解决之前，再加上NLP本身还有很长的路要走，基于人工智能的多任务服务agent不大可能达到C端满意的水平。

创业团队各自最基础的认知计算的能力不会有太大的区别，都是踩在世界顶尖大牛的肩膀上——在这个领域创业团队想和大公司钢正面，不是很理性。

创业团队在垂直领域有些自己的技术突破可以创造一些阶段性的优势，但面对教育市场的大山而言，这点差异远不足以make a difference。

在各自领域，开发者对人工智能相关技术的理解和其带来的交互层面的有效应用，可能会在垂直商业应用上创造更大的差异——比较起“95% VS 98%的识别率”而言。