微信AI，能避开豆包手机的窘境吗？

相比于技术路线上的争议，C端AI生态还有一个更加现实的难题：商业利益如何分配。

文｜游勇

编｜周路平

上周，微信AI开启了小范围内测，外界得以看到这款国民级应用在AI上的一些应用场景。这个叫小微的AI助手，可以帮你总结朋友圈和公众号文章，也可以直接给某位好友发消息和发红包。

除了这些基础能力，更让业内关注的是，微信也在通过AI与外部的服务打通，让AI助手具备执行、办事能力，比如给小微发送指令，实现了一句话打车、点外卖。当用户在AI对话界面直接说点一杯冰美式（默认语音输入），小微可以根据用户的偏好，自动调用瑞幸或者星巴克等的微信小程序，并且帮你选好商品，但会在小程序内让你确认订单并且手动支付。

眼下，包括字节、阿里、腾讯、蚂蚁在内的互联网大厂，都在推动AI从简单的对话，向具备执行和办事能力的Agent进化。然而，这种AI服务打通的背后，一方面在考验应用生态的号召力，另一方面，当用户主动打开变成AI主动调用，如何平衡开发者、用户与AI入口的关系，成了Agent服务能否闭环的关键。

01

微信与豆包，为何境遇不同

去年底，豆包手机面世，凭借在AI能力上的大胆尝试，一炮而红。当时，豆包手机助手找到了中兴手机合作，获得了操作系统级的大量权限，其中就包括了一个关键的INJECT_EVENTS权限，让AI助手得以通过GUI Agent去读取屏幕信息，模拟用户进行点击。尽管未大规模推广，但在面世之初，其效果令行业颇受震动，不少人将其称为Agent的一个里程碑事件。

但豆包手机在Agent上的尝试，很快遭到了很多大厂App的抵制，包括微信在内的应用都拒绝了豆包手机的访问。事实上，手机厂商自家的AI手机助手，也拥有类似的系统级权限，但拥有大量用户的手机厂商在实际操作中并没有像豆包手机如此激进。

微信AI则选择了对生态更加温和的做法，AI接入的服务需要用户和开发者双向同意。在小微发布内测版本前半个月，微信就专门发布了一份《关于开发者接入微信AI生态的指引》，包括京东、美团、携程、肯德基、得物等13家企业成为微信AI生态的首批内测团队。

在微信AI的开发文档里，提到微信小微的两种接入方式，其中自动模式，无需额外提交代码，只需在后台打开授权按钮，适合轻量工具以及功能简单的小程序。而开发模式则需要申请，可以结合业务特性做一些接口声明和改造，适合交易类、医疗、政务等对合规要求高、业务逻辑复杂的小程序。

不过，有开发者告诉数智前线，微信小微的这种模式并非依赖A2A协议，而是依托微信自有的小程序生态和开发者接口，实现服务调用和任务执行。

“其实还是把小程序做了MCP接口化改造，就是开放MCP的接口，它不是A2A的这套逻辑。”上述开发者告诉数智前线，MCP相当于把API包装成了一个AI可读的接口，可以传数据，也可以把一些工具封装在里面。

而应用方可以自己决定哪些能力暴露给MCP，哪些能力不对外暴露。而且，MCP server都会有一套权限控制体系，它遵循最小权限原则，确保大模型仅在安全边界内调用工具。这意味着，它对于用户而言，是一个安全可控的操作路径。

业内人士告诉数智前线，这两种技术路线上的差异并没有优劣之分。微信之所以在AI生态上的号召力更强，除了本身具备庞大的流量池，也与微信十年前开始建设的小程序生态密切相关。微信已经接入了数百万个小程序，覆盖了几乎衣食住行的方方面面，而这些小程序以微信的标准接口，只需要进行一些智能化改造，就能快速被Agent所调用。

而豆包因为缺乏应用生态，只能在最初选择了更激进的GUI路线。甚至在他看来，当初不少应用大厂打着安全旗号拒绝豆包手机的模拟点击，并非技术本身有多么可怕，也是担心用户流量被豆包手机掌控。事实上，像肯德基、京东、百度等厂商也并没有禁止豆包手机的接入。

不过，有消息称，字节与中兴手机合作的第二代豆包手机即将发布。而新一代的豆包手机除了“屏幕识别+模拟点击”的GUI路线，也在推动接口协议的互联互通。

而豆包App也已经在加强与外部应用的连接，接入了抖音电商和支付的能力，用户可以在豆包的对话中直接购买商品。另外，豆包在北京和杭州两地启动了一键打车的灰度测试，用户直接在聊天框里说出行需求，系统自动识别地点、人数、偏好，匹配路线和价格后一键确认下单。

02

多技术路线并行成为主流

尽管GUI Agent的做法当前存在一些争议。但这条技术路线本身的优劣势都比较明显，靠着图片识别+模拟点击这一套，它可以不用担心接口协议是否已经打通，甚至可以不用应用方的许可，快速连接大量的应用生态，尤其是大量长尾应用，用GUI Agent的思路是最快捷的方式。

但代价在于，这种具有一定侵入性的做法很容易引起应用方的警惕，它绕过了底层的协议对接。而且，GUI也存在技术上的短板。比如在遇到小字体、模糊、动态加载、复杂布局或相似控件时，识别准确率难以保证，且视觉模型推理成本较高。以及面对弹窗、网络异常、页面加载延迟等动态场景，GUI Agent 缺乏底层的系统感知能力，难以准确判断当前界面状态，导致操作失败或死循环。

携程在一篇技术文章里也提到，通过闭源模型在OTA场景进行GUI Agent任务的运行时，存在两类缺陷：一是不理解对 Trip.com 的UI组件的操作方法；二是对长程任务（比如 “从大首页进入国内酒店列表，选择一家可订酒店并进入预订填写页” ）的成功率较低。

另外，相比于直接调用API接口，GUI的处理方式，对Token消耗量也比较大。“GUI Agent是现在大家没有方法互联互通的情况下，一种不得已的方案。”IDC分析师孙振亚告诉数智前线，现在浏览器的调用基本不会依赖GUI去处理，可以通过CRI去完成大部分的浏览器操作，而且非常高效。

但这并不意味着GUI Agent的方案没有价值。在业内一场关于GUI Agent的讨论中，与会嘉宾认为Agent技术正趋向于API调用和视觉能力相结合的混合模式。这意味着Agent既能通过精确的API接口与成熟的系统（如订票、订酒店的App）高效交互，也能通过视觉理解和操作那些没有API的通用图形界面（GUI）。

比如订机票、听音乐等高频、标准化的任务，Agent可以通过API调用快速、稳定地完成。而大量非标准化的长尾任务，则需要依赖屏幕识别+模拟点击的方式来实现。

OPPO ColorOS 智慧产品研发总监姜昱辰的判断是，GUI Agent是中间过渡形态，未来将走向A2A。

智能体与智能体之间的互联被认为是未来比较理想的做法，它能够最大化兼顾数据安全性、保证用户留存、均摊Token 开销，能够比较好的兼顾各方利益。

但信通院也提到，智能体交互的问题在逐步显现，比如身份可信、授权边界、数据安全和责任追溯等问题。不同平台、不同主体开发的Agent进入同一交互网络后，需要明确“谁在发起请求、代表谁发起请求、是否具备相应权限”。而不同厂商若各自构建封闭协议体系，可能造成新的生态壁垒和重复建设，不利于智能体产业健康发展。

6月26日，市场总局在智能体互联标准化新闻发布会上明确提到，不同厂商智能体间接口、协议不统一，形成“智能体孤岛”，严重制约了规模化协同应用。而在去年，相关机构已经在国家标准层面推出了AIP智能体互联协议。

事实上，无论是互联网大厂还是手机等终端系统厂商，目前在AI服务的接入上普遍采用了多种技术路线并行的思路。Google I/O大会上演示的Gemini Spark，就同时支持OCR模拟点击、合作软件API接入和A2A三种方案。

而谷歌在去年发布的APP function框架，也是通过一套标准的接口规范，帮助第三方的App应用和AI模型进行对接。

比如三星Galaxy S26就通过这套框架引入了谷歌的Gemini智能体，三星手机应用商城排名前200的应用都能支持Gemini去调用。用户可以对Gemini下达指令，找出相册中的特定照片，并用短信发送给朋友。而整个过程中，Gemini不需要打开相册和短信App，而是通过AppFunctions，把对应入口抓取到Gemini之中执行操作，效率更高。

除了谷歌，苹果也有类似的框架App Intents。在苹果的构思中，用户可以使唤 Siri 来操作各种 App，而底层实现方式就是通过 App Intents。

荣耀手机的YOYO智能体平台也对不同开发者提供了三种接入方式：智能体A2A接入，MCP接入和插件接入。比如荣耀AI服务将卡片配置成通用模板，开发者无需经过设计、开发、配置、测试等复杂流程，只需根据对应的模板卡片提供内容，即可将智能体服务嵌入荣耀YOYO智能体对话流中。蚂蚁的AI助手阿福就是通过这种方式接入了荣耀YOYO智能体。

“通过Agent去调应用，未来肯定是一个趋势。”信通院分析师马铭洋告诉数智前线。

03

AI入口之争，考验利益的重新分配

当互联网大厂和手机等终端厂商都在积极抢占AI时代的入口时，相比于技术路线上的争议，C端AI生态还有一个更加现实的难题：商业利益如何分配。

业内人士告诉数智前线，企业内部的多Agent协同已经比较普遍，比如企业数据分析领域，背后调用了数据洞察Agent、数据融合Agent、归因分析Agent，每个Agent负责一个清晰的任务，最终交付一个完整的结果。但在ToC的应用上，与第三方App的智能体互联还比较少。

这背后除了多Agent系统本身还不成熟外，更核心原因在于，相比于在企业内部的多智能体应用，这些通用的AI助手要连接外部服务时，不可避免遇到新的商业分配的难题。无论是何种技术路线，都无法回避同一个问题：当用户主动打开变成AI主动调用，用户的意图和需求以及后续的服务选择又掌握在了AI助手的手里，甚至整个操作都可以不用跳转到第三方平台，App管道化的担忧一直存在。

即便是微信打造的小程序生态里，本质还是用户直接去搜索获得服务，应用方接入小程序相当于多了一个触达用户的渠道。但AI时代，则变成了AI主动理解需求、选择服务，小程序变成了被动响应。而用户属于谁，服务会如何编排调度，用户沉淀，成本如何分担目前都没有一个清晰的说法。

这种底层商业逻辑的变化也让一些开发者对AI助手的服务调用并不积极。

诗词App西窗烛在去年对Apple Intelligence和华为小艺做过适配，但选择的是成本最低的轻量级接入，仅做页面跳转、参数透传，AI助手并不能直接读写App内部数据或者自动操作。

“不跳App，没流量。”西窗烛创始人瞿章才告诉数智前线，这也是目前第三方应用的一个纠结之处，当AI作为统一的服务调度入口，App开始管道化，传统依赖广告变现的生存模式遭遇挑战。而且，即便不是A2A，只是给AI助手提供API接口，每次的API请求都会有对应的IT资源消耗，对于小团队也是一笔不小的开支。

另外，多智能体协同背后产生的Token成本谁来承担，现在还没有一个明确的说法，“整体形态很新，其实监管侧包括产业形态，我感觉都没有成熟。一般来说，反正那俩大厂也不缺钱，可能暂时Token由他们来付吧。”马铭洋说。

不过，也有不少应用方选择了深度接入。比如东方财富、国泰海通证券就通过封装了多个Skills，接入华为小艺，直接在小艺助手上完成选股、查行情，全程留在对话界面。

在业内人士看来，这些偏服务性以及需要强大线下履约能力的应用，更有动力与这些通用型的AI助手合作，因为最终服务的落地依赖这些厂商提供，反而能获得更多的精准流量，比如滴滴、高德、肯德基。另外，像金融、健康类的应用需要专业的知识体系支撑，往往也更愿意被AI助手调用，比如东方财富、蚂蚁阿福等。反而是需要靠广告变现和依赖竞价排名的应用，有着更多的顾虑，AI助手直接调用服务，在一定程度上减少了用户打开App的机会，也让用户关系难以在自己的池子里沉淀。

这场AI Agent的探索和博弈才刚刚开始，不管是技术、用户体验还是商业化都还在初期。但可以肯定的是，一个繁荣的生态必然是开发者、用户和AI入口都能从中受益。