通信人家园

标题: AI版「互联网协议」面世，豆包手机们再也不怕被「封禁」了？ [查看完整版帖子] [打印本页]

时间: 2025-12-13 13:07

作者: ttxx 标题: AI版「互联网协议」面世，豆包手机们再也不怕被「封禁」了？

最近封禁「豆包手机」（nubia M53）的 App 名单越拉越长了。不只是微信、支付宝，拼多多、淘宝等电商平台以及更多银行类应用，也都开始不同程度禁止用户在豆包手机上登录和使用。

这不是简单的产品之争。

一句「帮我比价下单」，手机页面开始自动跳转、识别界面、点击按钮、领券、结算，全程不依赖任何官方接口。豆包手机助手走的是典型的 GUI Agent 路线——让 AI 看懂手机界面，直接模拟用户在 GUI（图形用户界面）上进行操作。

类似的还有被亚马逊严正警告的 Comet AI（知名 AI 搜索初创公司 Perplexity 旗下），尚且还是在相对开放的 Web 世界，而豆包手机助手面对的则是巨头林立的 App 世界。

Perplexity 对亚马逊的回应，图片来源：Perplexity

关键在于，整个互联网生态都还没有准备好承接 GUI Agent 对系统权限、平台秩序和安全边界的「野蛮冲击」。

相较之下，基于 MCP（Model Context Protocol，大模型上下文协议）的 Agent 模式，虽然也不可能从解决 AI 时代的所有平台矛盾，却给出了一条「通往共赢之路」。

就在 12 月 10 日，Anthropic（开发了 Claude）宣布将 MCP 正式捐赠给新成立 Agentic AI（智能体 AI）基金会，由 Linux 基金会统一托管。如果说 GUI Agent 依旧沿用的是「AI 模仿人类点手机」的旧逻辑，那么 MCP 尝试回答的是：

智能体时代的互联网，必须拥有一套属于 AI 的开放互联协议。

从小众到共识，「真·AI 互联网协议」来了

MCP 协议不是一个新的概念。今年 4 月接受财联社采访时，阿里云智能集团资深副总裁刘伟光就表示，MCP 是今天公认的业界标准：

「在 MCP 之前有很多人尝试过函数调用、提示词工程、插件等方式，今天 MCP 通过统一标准接口，类似于今天电脑手机当中看到 USB-C 接口，这样一种标准接口降低大模型和外部系统的集成门槛。」

毫无疑问的是，在 Anthropic 正式捐赠之前，MCP 协议其实就初步成为了一种「事实标准」。

最开始，MCP 只是 Anthropic 工程师为 Claude 做的一个「统一工具接入规范」。为了解决大模型在调用外部工具、读取本地数据时必须反复编写适配代码的问题。开发者只要遵循 MCP 这一套 JSON-RPC 协议，就能用一个统一方式把文件系统、数据库、业务工具接入 Claude。

一种形象的解释，图片来源：Norah Sakal

简单、直接、可复用，是 MCP 在早期被工程师口口相传的原因。可从 2024 年中开始，这套规范开始在行业内迅速蔓延：

- VS Code、Cursor、Windsurf 等新一代开发环境集成 MCP；

- OpenAI 在官方文档里将 MCP 视作首选扩展路径；

- Google 的部分内部 Agent 工具链也开始基于 MCP ；

- 阿里、字节、腾讯的工程团队也在项目中用 MCP 作为 AI 系统的互联方式；

- ……

到了 2025 年，「支持 MCP」已经成为 Agent 类产品的标配。事实标准，就是在这种群体无意识的默契中自然形成的。

过去二十年，互联网的运行依赖 HTTP、TCP/IP、OAuth 这些共识。而智能体要想在手机、PC、云服务乃至企业系统间自由地交换信息、调用工具，也必须拥有自己的「协议层」。今天来看，MCP 就是目前的最佳答案。

尽管 MCP 早已开源，但协议被捐赠给 Linux 基金会（目前全球最负盛名的开源基金会），更意味着 MCP 不再属于某家公司，而是像 Linux、Kubernetes、OpenAPI 等开源项目进入更中立的治理体系。

AI 的世界，需要一套不依赖任何巨头、可被所有模型与平台共同遵循的底层协议。这大概就是这次 MCP 捐赠发出的一个强烈信号。

另一方面，Agentic AI 基金会的「开山项目」其实不只是 MCP，还有 OpenAI 捐赠的 AGNTS.md ——网站和应用给 Agent 写「使用说明」的标准，以及 Google 捐赠的 Block——构建智能体和工作流的框架。

此外，Google 随后也推出了自家完全托管的远程 MCP 服务器，可以将智能体 AI 更轻松地接入 Google 及其云端服务（如地图、BigQuery 等），直接调用如 Google 地图的真实数据和工具。而今年更早时候，阿里云百炼平台其实就已经推出了全生命周期的 MCP 服务，包括 MCP 服务器。

比如高德 MCP 服务器，图片来源：高德地图

今天不是某一家押注 MCP，而是整个 AI 行业在「底层连接方式」上形成了普遍共识：未来的 AI 体验不会只依赖某个模型，而是依赖一种可互操作、可治理、可跨平台流动的语言。

从这个角度，MCP 则是那个「被选召的孩子」。

理想情况下，未来智能体 AI 不用伪装成人类点击网页，而可以直接、合法地「帮用户比价下单」，平台也能保留监管与服务能力。不过，基于 GUI 的 Agent 是不是作为一种过渡手段就要走入历史？恐怕也不然。

GUI 走不通的路，只能交给 MCP

上月初，雷科技报道了《亚马逊警告 Perplexity，智能体与互联网平台终于一战？》，Comet AI 通过爬取商品页、解析页面，把「购买建议」「价格趋势」「商品筛选」直接呈现给用户，绕过了在线购物平台的推荐体系和广告链路，也引起了亚马逊的强烈反对。

本月初，雷科技也报道了《豆包手机助手调整权限！AI 手机是洪水，但不是猛兽？》，豆包手机助手在 GUI 层执行的 App 操作引发了更大程度的争议。

事实上，这种矛盾也不是这两个月才有的。微信很早就旗帜鲜明地反对 GUI 路线，早在 3 月就有网友发现荣耀 YOYO 智能体无法再「操作」微信，华为、vivo、魅族等其他手机厂商的「智能体 AI」也不例外。

在宣传时还有微信，图片来源：荣耀

要理解这种冲突，首先必须理解从智谱 AutoGLM 到 Comet、豆包手机助手，为什么都要基于 GUI 路线？

核心不难理解：互联网并没有准备好拥抱智能体 AI。

MCP 虽然已经初步获得了各大 AI 公司的认可，但整个互联网生态还有太多功课要补，而基于 GUI 的通用方案则是早期阶段唯一能大规模跑起来的方式——不依赖平台配合，不等待改造，只要有用户界面就能「操作」。

但正因为它「无所不通」，现实中的矛盾也来得同样迅速。基于GUI 交互的智能体 AI 跳过了产品逻辑、商业链路和风控体系，让平台无法控制智能体 AI 在什么场景、以什么方式与用户数据和关键操作发生关系，一旦出现误操作，责任边界立刻模糊。

就在豆包手机助手引发争议的同时，工信部下属中国信通院也牵头发布了《端云协同智能体交互双重授权安全指引》，重点提到了「构建由用户和应用双重授权的安全机制」，明确智能体 AI「需同时获得应用授权与用户授权，才能合法访问第三方应用」。

图片来源：中国互联网协会

不是豆包手机助手「太激进」，而是 GUI 路线与平台生态天然难以长期共存。一个耐人寻味的例子是，去年 10 月最早基于 Claude 推出「Computer Use」（同样基于 GUI 路线）的 Anthropic，在 MCP 之后基本放弃了这条路线的对外更新。

图片来源：Youtube

而与 GUI 试图「模拟用户」不同，MCP 试图为智能体 AI 建立一条「正式入口」，让平台第一次可以把与智能体 AI 互动的边界显性化：哪些能力可读、哪些操作必须二次确认、哪些业务永远不开放，都可以在协议层直接写清楚。

更重要的是，MCP 将智能体与系统之间的关系，从「依赖 UI」提升为「依赖能力」。比如 GUI 路线下「查订单」，需要打开 App 读取界面、解析文本、定位按钮，再经过多次操作才能知道；但在 MCP 模式下，可能只是一次明确的能力请求：查询、返回、处理。

当然，MCP 意味着整个互联网生态需要经历「一场漫长的改造」，也意味着基于 GUI 路线的智能体 AI 的体验不可能完全放弃。

写在最后

接下来很可能不会是二者的简单取舍。

GUI 会继续作为「兜底」，让智能体在未改造完的旧世界里继续前行；MCP 则会成为跨系统、跨平台的底层互联方式，为智能体建立清晰的权限、边界与秩序。

而在这两者之上，终端设备上新的系统级智能体能理解用户的目标，协调设备、平台与服务，并在平台规则之内完成跨生态、跨智能体任务。简言之：

OS 提供统一智能体入口和权限管理，MCP 等协议负责和各家服务沟通，Qwen、Gemini、GPT 之类模型可以被插拔，变成「换大脑但不拆线管」的状态。

这可能才是智能体 AI 的终局。

来源：36kr

通信人家园 (https://www.txrjy.com/)