4个月前，我在《移动互联网，百度终于想清楚了》中提到，从传统互联网到移动互联网，百度面临最大的挑战并不是所谓的“由浏览器、桌面、应用、终端等产品份额重构带来的入口之争”，也并非从键盘扩展到语音、扫一扫等输入形态多样化产生的威胁，而是来自移动Apps筑建的围墙——不同于网页，移动互联网时代下，越来越多的内容和数据都被包裹于一个个独立的应用之内，无法被搜索引擎触及，所以，百度需要找到一种办法，去连接这些信息孤岛。

百度从移动互联网的红海中看到了机会——移动应用数量爆发，基础领域完全被挤占，加上巨头进驻、同质化严重，大部分移动应用创业者都成为了李彦宏和李明远数次提到的“中长尾开发者”，用李彦宏的话说：“应用商店有根本性的缺陷，首先，它们的应用排序方式不利于长尾应用的分发，其次，用户需要知道应用的名称，才能方便检索相关的应用。”所以，长尾开发者们缺乏渠道能力又需要控制推广成本，如果能利用百度搜索强大的渠道能力去帮他们高效的分发应用，将是个不错的生意。

当然，首先这门生意得和百度自身的产品定位联系起来：从最初的单纯的“网页索引”，到百度知道、百度百科出现后的“知识索引”，以及百度地图这类产品扩展出的“地理位置索引“和”本地生活索引”，搜索引擎的本质实际就是“为人们找到问题解决方案“的工具。只不过，由于技术的制约，在十多年来，搜索引擎最擅长的还是通过关键词，为用户索引和排序出合适的网页内容。

但如今，随着机器学习、数据挖掘等技术的发展，搜索引擎能够更聪明的去理解人们的查询意图，把搜索技术从单纯的关键词匹配网页提升为通过判断用户的查询需求来为用户推送立体化的多形态解决方案（我在《未来搜索》一文中对此进行过详细的阐述）。

在移动互联网时代，移动App当然属于“解决方案”中最重要的一环——地图应用能够帮你解决线路安排问题，打车应用能够帮你在最短的时间内找到交通工具，美食应用能够帮你找到和评价周边的餐馆，酒店应用能够帮你找到和预定住所……

所以，从用户需求、技术和开发者需求上，百度找到了自己的移动化路径：让搜索引擎去学习和理解用户的需求，为他们推荐合适的移动应用去解决问题，这样，百度就从一个传统互联网上的网页搜索引擎，转身成为移动互联网的网页搜索引擎和应用分发渠道，其本质是一脉相承的。

要做好应用分发，百度首先需要找到在移动平台上的链条式产品，改变曾经一堆产品、缺乏主次和杂乱无章的状态。幸好我们看到，从今年起，李彦宏看到了百度搜索和百度手机助手这两个产品在应用分发上的重要性，这两个重心产品的成长速度也符合百度的期待，如今，百度移动搜索的流量增幅超过了16倍，而在不久前，百度又收购了91无线，直接大幅提升了其本地应用的分发能力。

但与本地应用的分发相比，李彦宏似乎更看重在线应用的分发，即用户能够在搜索后直接调用应用的功能去解决问题。李彦宏说，要实现这一目标，首先要实现“开发者的理想”：能够方便、快速的开发出具有本地应用能力的在线应用。这便是百度移动云平台的工作了——通过百度云平台提供的开发环境BAE、WebApp在线生成服务平台SiteApp和移动云测试中心MTC以及陆续开放出来的百度地图引擎、LBS商户数据、流媒体转码工具等功能，开发者可以快速集成基础应用功能、调用手机本地传感器实现应用开发和测试，同时，百度还提供了免费的订阅推送功能去帮助开发者沉淀用户。

在这一切工作之后，百度终于在今天的2013百度世界大会上带来了他们的在线应用分发方案——轻应用。轻应用被集成在新版的百度应用中，一方面，在主页面的功能栏内，用户可以点击功能键查看已经被集成的轻应用并添加一些已有的轻应用，直接点击调用这些功能；另一方面，如我前文所说，百度会根据用户的搜索意图来为他们直接调用合适的轻应用，例如，我在百度应用中搜索“从望京到鼎好”后，页面中会先显示百度地图的路径规划方案，如果我选择的是“打车”作为出行选择，那么它会直接调用嘀嘀打车的轻应用；或是我搜索“在望京租房”，那么搜索页面上就直接调用58同城的轻应用来帮我解决这一问题。

如今，百度移动搜索应用上集成的应用还比较少，李明远说，他们会尽快将汽车、音乐、医疗、美食等服务型轻应用集成在他们的轻应用平台上，满足用户的需求。

今天这一步后，百度算是完成了本地应用和在线应用分发形态的建立，接下来，如何与开发者提供更全面的开发支持？如何催生出高质的轻应用集群？如何评估和选择被分发的应用？如何设立具体的货币化和分成方案？ 将是百度需要尽快给出的答案。