DECAS的核心，是如何串联起不同的动作来达成目标。放在之前提到的概念和动作组成的网络图里面说，其实就是找意图中概念结点到意图中目标结点的各种连通路径。（虽然Viv没有具体说，但目标结点应该也是一种概念结点。）Viv把一条路径称为一个 计划（Plan）。计划中使用到的动作可以跨应用，可以来自于不同开发者设定的动作。

　　下图中给出了达成跑鞋推荐目标的两个计划，其中计划1串联了

　　transform_occupation_to_price和rec_shoes_based_on_price这两个动作，而计划2则是串联了transform_occupation_to_type和 rec_shoes_based_on_type这两个动作。开发者可以为每个计划设定一个价值函数，DECAS则只需要选择价值最高的topN计划具体执行即可。当然，DECAS可能做得更复杂，比如依据用户反馈实时调整计划。

　　如果一个计划包含的动作所需的必须输入概念对象缺失，那么就需要与用户进行多次交互以收集缺失概念对象的值。

　　总结下，Viv是以动作为核心的网络系统。 它首先让开发者定义对应领域的概念对象和动作对象，然后自动生成计划（网络图中找两个结点间的路径），利用用户输入中的概念对象完成用户的目标。相对于Api.ai和一个AI只能使用开发者设定的意图来完成已知的需求，Viv在联合不同开发者定义的概念和动作对象后可以执行一些不在开发者设定范围内的意图。随着越来越多开发者接入Viv，它能做的事会指数增长。Viv在智能性/灵活性方面做得很好，但可控性会稍差，因为完成目标的计划都是由系统自动生成的，开发者难以介入。好的灵活性也会对开发者有更高的要求，开发者初期付出的管理成本可能不低。Viv开发了很多辅助工具帮助开发者管理自己的应用，但这些工具能把开发者的管理成本降到什么程度目前尚不清楚。

　　关于Viv的更多细节，可见我之前的文章《原Siri团队秘密研发的Viv能搅动bot市场吗？》。

　　四、在路上的Wit.ai

　　Wit.ai在2014年就被Facebook收购了，今年上半年做了很大的改版。之前它的模式和一个AI类似，开发者可以手动设置状态以衔接不同的场景。

　　改版后，它取消了之前一个场景控制一轮对话的逻辑，变为以 故事（Story）为对话单元。一个故事相当于完成用户某个需求的一条路径。所以一个故事通常包括多轮对话，或者说一个故事包括完成同一需求的多个（隐式）场景。故事是比场景更大的对话单元。下图给出了一个求约会故事的示例。

　　开发者可以为同一需求设定多个故事，代表完成此需求的多条路径，但也不需要为所有路径都创建一个故事。Wit.ai可以使用已创建的故事来自动生成新的路径以完成某个需求。如果把故事中的一轮对话看成一个AI里的一个场景，那wit.ai就能自动衔接不同故事中的各种场景，以便创建完成需求的新故事或者新路径。类似的能力在api.ai和一个AI里更多是依靠开发者通过状态进行维护。

　　以故事为对话单元的好处是，开发者不再需要手动设置场景和状态了，系统可以通过学习来拆解已有故事并重新拼装成新的故事。在相同场景数的情况下wit.ai能回答的用户提问会比api.ai和一个AI多。但这种灵活性带来的坏处就是可控性下降。开发者很难控制某些路径不被自动创建，出现问题时开发者如何调整故事也变得很朦胧。而这些问题在api.ai和一个AI里是不存在的。

　　Wit.ai正从api.ai和一个AI这端走向Viv那端。路是不是对的，只能走着瞧了。

　　关于wit.ai的更多细节，可见我之前的文章《低价制造chatbots的利器 Wit.ai》。

　　说了这么多，该说的终于说完了，简化一下就两条内容：

　　对话交互会在IoT万物互联时代爆发，这是追逐交互效率的必然结果。

　　不同的bot和bot平台的差别其实只是在可控性和智能性之间的权衡不同。技术的发展只是在不断拓展可控性和智能性的帕累托边界而已。我个人认为目前api.ai和一个AI的范式最适合国内小微企业。