最近封禁“豆包手机”（nubiaM53）的App名单越拉越长了。不只是微信、支付宝，拼多多、淘宝等电商平台以及更多银行类应用，也都开始不同程度禁止用户在豆包手机上登录和使用。
这不是简单的产品之争。
一句“帮我比价下单”，手机页面开始自动跳转、识别界面、点击按钮、领券、结算，全程不依赖任何官方接口。豆包手机助手走的是典型的GUIAgent路线——让AI看懂手机界面，直接模拟用户在GUI（图形用户界面）上进行操作。
类似的还有被亚马逊严正警告的CometAI（知名AI搜索初创公司Perplexity旗下），尚且还是在相对开放的Web世界，而豆包手机助手面对的则是巨头林立的App世界。
Perplexity对亚马逊的回应，图片来源：Perplexity
关键在于，整个互联网生态都还没有准备好承接GUIAgent对系统权限、平台秩序和安全边界的“野蛮冲击”。
相较之下，基于MCP（ModelContextProtocol，大模型上下文协议）的Agent模式，虽然也不可能从解决AI时代的所有平台矛盾，却给出了一条“通往共赢之路”。
就在12月10日，Anthropic（开发了Claude）宣布将MCP正式捐赠给新成立AgenticAI（智能体AI）基金会，由Linux基金会统一托管。如果说GUIAgent依旧沿用的是“AI模仿人类点手机”的旧逻辑，那么MCP尝试回答的是：
智能体时代的互联网，必须拥有一套属于AI的开放互联协议。
从小众到共识，“真·AI互联网协议”来了
MCP协议不是一个新的概念。今年4月接受财联社采访时，阿里云智能集团资深副总裁刘伟光就表示，MCP是今天公认的业界标准：
“在MCP之前有很多人尝试过函数调用、提示词工程、插件等方式，今天MCP通过统一标准接口，类似于今天电脑手机当中看到USB-C接口，这样一种标准接口降低大模型和外部系统的集成门槛。”
毫无疑问的是，在Anthropic正式捐赠之前，MCP协议其实就初步成为了一种“事实标准”。
最开始，MCP只是Anthropic工程师为Claude做的一个“统一工具接入规范”。为了解决大模型在调用外部工具、读取本地数据时必须反复编写适配代码的问题。开发者只要遵循MCP这一套JSON-RPC协议，就能用一个统一方式把文件系统、数据库、业务工具接入Claude。
一种形象的解释，图片来源：NorahSakal
简单、直接、可复用，是MCP在早期被工程师口口相传的原因。可从2024年中开始，这套规范开始在行业内迅速蔓延：
-VSCode、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捐赠发出的一个强烈信号。
另一方面，AgenticAI基金会的“开山项目”其实不只是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，智能体与互联网平台终于一战？》，CometAI通过爬取商品页、解析页面，把“购买建议”“价格趋势”“商品筛选”直接呈现给用户，绕过了在线购物平台的推荐体系和广告链路，也引起了亚马逊的强烈反对。
本月初，雷科技也报道了《豆包手机助手调整权限！AI手机是洪水，但不是猛兽？》，豆包手机助手在GUI层执行的App操作引发了更大程度的争议。
事实上，这种矛盾也不是这两个月才有的。微信很早就旗帜鲜明地反对GUI路线，早在3月就有网友发现荣耀YOYO智能体无法再“操作”微信，华为、vivo、魅族等其他手机厂商的“智能体AI”也不例外。
在宣传时还有微信，图片来源：荣耀
要理解这种冲突，首先必须理解从智谱AutoGLM到Comet、豆包手机助手，为什么都要基于GUI路线？
核心不难理解：互联网并没有准备好拥抱智能体AI。
MCP虽然已经初步获得了各大AI公司的认可，但整个互联网生态还有太多功课要补，而基于GUI的通用方案则是早期阶段唯一能大规模跑起来的方式——不依赖平台配合，不等待改造，只要有用户界面就能“操作”。
但正因为它“无所不通”，现实中的矛盾也来得同样迅速。基于GUI交互的智能体AI跳过了产品逻辑、商业链路和风控体系，让平台无法控制智能体AI在什么场景、以什么方式与用户数据和关键操作发生关系，一旦出现误操作，责任边界立刻模糊。
就在豆包手机助手引发争议的同时，工信部下属中国信通院也牵头发布了《端云协同智能体交互双重授权安全指引》，重点提到了“构建由用户和应用双重授权的安全机制”，明确智能体AI“需同时获得应用授权与用户授权，才能合法访问第三方应用”。
图片来源：中国互联网协会
不是豆包手机助手“太激进”，而是GUI路线与平台生态天然难以长期共存。一个耐人寻味的例子是，去年10月最早基于Claude推出“ComputerUse”（同样基于GUI路线）的Anthropic，在MCP之后基本放弃了这条路线的对外更新。
图片来源：Youtube
而与GUI试图“模拟用户”不同，MCP试图为智能体AI建立一条“正式入口”，让平台第一次可以把与智能体AI互动的边界显性化：哪些能力可读、哪些操作必须二次确认、哪些业务永远不开放，都可以在协议层直接写清楚。
更重要的是，MCP将智能体与系统之间的关系，从“依赖UI”提升为“依赖能力”。比如GUI路线下“查订单”，需要打开App读取界面、解析文本、定位按钮，再经过多次操作才能知道；但在MCP模式下，可能只是一次明确的能力请求：查询、返回、处理。
当然，MCP意味着整个互联网生态需要经历“一场漫长的改造”，也意味着基于GUI路线的智能体AI的体验不可能完全放弃。
写在最后
接下来很可能不会是二者的简单取舍。
GUI会继续作为“兜底”，让智能体在未改造完的旧世界里继续前行；MCP则会成为跨系统、跨平台的底层互联方式，为智能体建立清晰的权限、边界与秩序。
而在这两者之上，终端设备上新的系统级智能体能理解用户的目标，协调设备、平台与服务，并在平台规则之内完成跨生态、跨智能体任务。简言之：
OS提供统一智能体入口和权限管理，MCP等协议负责和各家服务沟通，Qwen、Gemini、GPT之类模型可以被插拔，变成“换大脑但不拆线管”的状态。
这可能才是智能体AI的终局。
相关文章
头条焦点
精彩导读
关注我们
【查看完整讨论话题】 | 【用户登录】 | 【用户注册】