豆包受限与硅谷联盟:谁在影响中国万亿AIoT市场的未来?

2025-12-17
碎片化是AIoT规模化落地的最大阻碍,缺乏统一交互协议,AIoT产业的大规模应用便无从谈起。关键问题在于:这套协议应由谁来制定?

12月1日,豆包手机正式上线,字节跳动终于亮出了其AI硬件的底牌。然而,牌局刚开局,就被打乱了。



上线次日,用户尝试让豆包智能体操作微信时,腾讯后台立即发出警报:账号被判定为“登录环境异常”,强制下线,部分账号还遭到了短期冻结。阿里系也同步采取行动:在淘宝、闲鱼、大麦等APP中,豆包的自动化操作频繁触发人机验证,甚至导致闪退和强制登出。银行方面更为严格,农行、建行直接以“风险环境”为由,彻底禁止了智能体的登录和支付通道。这是中国互联网的一次集体“免疫排异”反应。


12月5日,豆包团队发布公告,宣布限制智能体在刷分、刷激励、金融支付及部分游戏场景中的操作权限。简单来说,就是主动退缩。从上线到妥协,仅用了不到五天时间。


四天后,大洋彼岸传来了一个截然不同的消息。


当地时间12月9日,Anthropic宣布将MCP(模型上下文协议)正式捐赠给Linux基金会旗下的AI智能体基金会。这意味着MCP不再是一家公司的私有资产,而成为了一个中立的开放标准。Anthropic做出了一个选择:放弃独占,以换取行业共识。


一边是围追堵截,一边是开放共建。将这两件事放在一起看,恰好揭示了当前AI发展最核心的矛盾。


豆包所代表的GUI智能体路线,实际上是一种未经授权的“数字寄生”。它绕过APP构建的壁垒,通过模拟人类点击来获取服务。短期来看,这条路似乎绕过了接口障碍;但从本质上讲,这是对平台数据主权的粗暴侵犯。在微信、淘宝等平台看来,这并非技术创新,而是流量劫持,是一场不宣而战的偷袭。


AI智能体想要的是数据的“最惠国待遇”,而平台看到的却是“破门而入”。


双方立场无法调和,冲突在所难免。


更严重的是,这种依赖“视觉识别+模拟点击”的路线本身就是一条死路。没有底层协议的支撑,AI智能体只能扮演“黑客”的角色,与APP的反爬虫、反外挂机制进行游击战。手机算力充足且更新频繁,或许还能通过OTA勉强维持兼容;但对于更广泛的AIoT设备,如智能眼镜、智能音箱、智能家电来说,这简直是一场灾难。


想象一下:你的智能冰箱依赖模拟点击来调用外卖APP,某天美团更新了一版用户界面UI,按钮位置移动了几个像素,冰箱就彻底“失明”了。这并非假设,而是GUI智能体路线的必然结局。如果AIoT生态建立在“破解”与“模拟”之上,那么它将脆弱得不堪一击。显然,这条路走不通。


硅谷联盟:用协议终结混乱


国内厂商还在为“模拟点击”的合规性头疼不已时,硅谷已经换了一种打法。


12月9日,Linux基金会宣布成立AI智能体基金会(AAIF)。成员名单值得仔细研究:AWS、谷歌、Meta这些老面孔并不意外,真正有意思的是OpenAI和Anthropic。这两家公司在大模型领域竞争激烈,如今却坐到了同一张桌子前。


这并非行业联盟的例行公事,而是一次利益格局的重新划分。


促成这次“握手”的并非理想主义情怀,而是一个冷酷的成本核算:在智能体时代,单一模型的智力优势正在达到顶峰,真正的瓶颈是互操作性。如果每个AI都要为成千上万个SaaS应用单独开发适配接口,或者像豆包那样暴力破解前端界面,整个行业的边际成本将高得无法承受。


巨头们算清楚了:互操作性释放的生态价值,远大于封闭系统带来的垄断红利。与其各自加固护城河,不如合力把蛋糕做大。


这个共识的第一个产物,就是Anthropic捐出的MCP(模型上下文协议)。


MCP解决的是一个极其基础的问题:大模型如何连接外部数据?过去,让模型接入本地文件、数据库或Slack,需要为每个数据源单独编写适配代码,开发繁琐、维护成本高且稳定性差。MCP的作用就是强行统一这套连接标准。一个接口,就能适配所有数据源。模型端和数据端从此实现解耦。



实际上,AI智能体基金会的“开山项目”不只是MCP,还有OpenAI捐赠的AGNTS.md以及Google捐赠的构建智能体和工作流的框架。


如果把MCP比作充电接口的USB-C标准,那么AGENTS.md就是写给AI看的用户手册。AGENTS.md明确告诉AI,这个网站或应用有哪些数据可读、哪些API可调、参数该如何传递。再配合Google开源的A2A(Agent-to-Agent)协议,即一套专为AI工程设计的通用执行框架,开发者就拥有了从连接、认知到执行的完整工具链。


这套组合拳的意图很明确:将智能体的交互模式从“打游击”升级为“正规军”。


豆包的GUI智能体依靠视觉识别和模拟点击,本质上是在应用的表面做文章,脆弱、低效且随时可能触犯法律红线。而基于MCP等协议的交互,则是通过API管道直达核心数据,路径清晰、权责分明。


硅谷正在制定的不只是一套技术规范,更是AI世界的基础通信协议。正如TCP/IP定义了互联网的数据传输规则,MCP试图定义AI理解和操作外部世界的通用语言。


70%普及率背后的死结


根据“人工智能+”行动意见,我国国家层面的时间表已经确定:2027年,新一代智能终端、智能体普及率超过70%,2030年突破90%。这不是愿景,而是硬指标。



但问题是:这70%如何实现?


如果小米的空调听不懂百度的指令,华为的手机无法调用阿里的服务,所谓的“普及”就只是一堆无法互联的孤岛。这不是普及,而是内耗。


目前的现实是:硬件厂商忙着建造围墙,想把用户锁进自家的设备全家桶;互联网巨头忙着挖掘护城河,死守数据不外流。每一方都在加固自己的堡垒,结果导致整个生态被分割成碎片。


碎片化是AIoT规模化落地的最大障碍。


更麻烦的是,这种内部割裂正遭遇外部挤压。美国已经通过AAIF确立了统一战线,如果中国迟迟拿不出对等的标准体系,将同时面临两个陷阱。


第一个陷阱:直接照搬MCP。


看起来省事,但在数据主权日益敏感、中美技术脱钩持续加深的背景下,将底层交互协议的定义权拱手让出,后患无穷。协议标准从来不是中立的技术文件,它决定了数据如何流动、谁能读取、谁被排斥。


第二个陷阱:各自为战。


如果拒绝通用协议,阿里搞一套,腾讯搞一套,华为再搞一套,开发者就只能疲于奔命,为每个平台重复开发基础功能。研发成本降不下来,产品迭代速度慢,最终拖慢整个行业的落地节奏。


一边是“被定义”的风险,一边是“自己乱”的风险。留给中国AIoT产业的选择空间正在缩小。


破局的窗口正在关闭


标准真空不会永远存在。要么中国自己定义规则,要么被别人的规则定义。


方向其实很明确:中国需要建立自己的智能体互联协议(姑且称之为CN-MCP)。但这件事最大的障碍不是技术,而是谁来牵头。百度主导,腾讯不会跟随;华为制定,小米未必认可。任何一家巨头主导的标准,都会被视为“私货”,难以获得全行业的信任。


唯一可行的路径,是由国家级产业联盟或中立的开源基金会出面,以公信力打破门户壁垒。


但即便解决了牵头问题,中国的CN-MCP也不能照搬美国模式。原因很简单:生态结构不同。


美国的互联网是以Web和SaaS为主导的开放生态,AI智能体可以通过API直接抓取网页数据,路径清晰。中国则不同,中国的服务高度集中在微信、抖音、美团这些超级APP里,被封装在小程序和原生应用的黑盒中,外部根本无法触及。


所以,CN-MCP要解决的不只是“连接”问题,更是“服务原子化”问题。也就是说,不能让AI继续依靠模拟点击来操作APP,那条路已经被证明走不通。真正要做的,是推动超级APP将内部功能拆解成可被外部调用的标准化接口。美团的订餐、携程的服务、微信的聊天、12306的购票……都应该变成AIoT设备可以直接调用的原子服务。


这需要各方都做出改变。


政府层面,应当将智能体互联标准提升到新基建的高度。这不是可选项,而是数字经济的底层管道。没有统一的交互协议,AIoT产业的规模化落地就是空谈。


互联网巨头也需要想清楚一件事:在移动互联网时代,封闭或许还能锁住流量;但在AI时代,封闭就是自我边缘化。如果你的服务无法被智能体读取和调用,在未来的物联网世界里,你就是隐形的。开放接口,让APP成为AIoT的底层基础设施,才是延续生命力的唯一选择。


在AI时代,封闭不是护城河,而是自掘坟墓。


写在最后


豆包手机的遭遇,不是产品的失败,而是路径的失败。


它撞上的那堵墙:巨头封锁、接口缺失、生态割裂,不是偶然事件,而是现行秩序的必然反应。在没有通用协议的世界里,任何试图跨越围墙的尝试,都会被当作入侵者处理。


但这堵墙本身,也在逐渐松动。


依靠摄像头“看”屏幕、模拟点击的GUI智能体,本质上是一种过渡方案——在旧接口体系尚未瓦解、新协议标准尚未建立的空窗期,它是唯一能运行的路径。但它不是最终的解决方案。真正的终局,是通用协议取代私有接口,是服务像水电一样通过标准管道流向终端。


那时的AIoT设备会是什么样?不再需要预装几十个APP来抢占算力和内存,只需要内置一套通用协议。硬件回归感知和交互功能,服务按需调用,即时抵达。


问题在于:这套协议由谁来定义?


互联网时代的核心是把人连接起来,智能体时代的核心是把万物和服务连接起来。谁掌握了连接的标准,谁就掌握了下一个十年的底层规则。这场标准之争,我们不应旁观。


本文来自微信公众号 “物联网智库”(ID:iot101),作者:彭昭,36氪经授权发布。


本文仅代表作者观点,版权归原创者所有,如需转载请在文中注明来源及作者名字。

免责声明:本文系转载编辑文章,仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布,请及时与我们联系进行审核处理或删除,您可以发送材料至邮箱:service@tojoy.com