摘要
近期，基于GUI（图形用户界面）的AI智能体，如豆包手机助手，因模拟用户操作绕过平台接口，遭到微信、支付宝、亚马逊等多家应用封禁。与此同时，一种名为MCP（模型上下文协议）的AI互联协议正成为行业共识。该协议由Anthropic发起并已捐赠给Linux基金会，获得了OpenAI、Google、阿里、字节等公司的广泛采用，旨在为AI智能体建立一套标准、安全的跨平台交互规则。中国信通院也发布安全指引，强调智能体需获得用户与应用双重授权，这进一步凸显了从GUI模式向MCP等协议化模式转变的必要性与紧迫性。
线索
投资机会与风险并存。核心机会在于围绕MCP协议构建的新生态系统。随着该协议成为AI智能体互联的行业标准，提供MCP服务器、开发工具及集成服务的平台（如阿里云百炼、Google云端服务）将迎来增长。这类似于为AI时代铺设“信息高速公路”，投资底层协议和基础设施具备长期价值。风险方面，依赖GUI模拟技术的AI应用面临被主流平台集体封禁的巨大政策与商业风险，其商业模式可持续性存疑，Anthropic自身已转向MCP路线。此外，MCP协议的全面落地需要整个互联网生态进行漫长改造，短期内推广速度可能不及预期，相关投资回报周期较长。同时，需警惕科技巨头通过自建MCP服务器形成新的生态壁垒，将开放协议变为变相的“围墙花园”。
正文
AI版「互联网协议」面世，豆包手机们再也不怕被「封禁」了？
近期，封禁“豆包手机”的应用列表正在扩大。除微信、支付宝外，拼多多、淘宝等电商平台及多家银行类应用，也已开始限制用户在豆包手机上的登录与使用。
这不是简单的产品之争。一句“帮我比价下单”，手机页面可自动跳转、识别界面、点击按钮、领券、结算，全程不依赖任何官方接口。豆包手机助手采用的是典型的GUI Agent路线——让AI看懂手机界面，直接模拟用户在GUI（图形用户界面）上进行操作。
类似的还有被亚马逊警告的Comet AI（知名AI搜索初创公司Perplexity旗下），其操作主要在相对开放的Web世界，而豆包手机助手面对的则是App生态。
关键在于，整个互联网生态尚未准备好承接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制定的“统一工具接入规范”，旨在解决大模型调用外部工具、读取本地数据时需反复编写适配代码的问题。开发者遵循这套JSON-RPC协议，就能用统一方式将文件系统、数据库、业务工具接入Claude。
简单、直接、可复用，是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基金会，意味着它不再属于某家公司，而是像Linux、Kubernetes、OpenAPI等开源项目一样，进入更中立的治理体系。AI的世界需要一套不依赖任何巨头、可被所有模型与平台共同遵循的底层协议。
另一方面，Agentic AI基金会的初始项目不止MCP，还有OpenAI捐赠的AGNTS.md（网站和应用给Agent写“使用说明”的标准），以及Google捐赠的Block（构建智能体和工作流的框架）。
此外，Google推出了自家完全托管的远程MCP服务器，可将智能体AI更轻松地接入Google及其云端服务（如地图、BigQuery等）。今年早些时候，阿里云百炼平台也已推出了全生命周期的MCP服务。
当前并非某一家公司押注MCP，而是整个AI行业在“底层连接方式”上形成了普遍共识：未来的AI体验不会只依赖某个模型，而是依赖一种可互操作、可治理、可跨平台流动的语言。从这个角度，MCP是那个被选中的协议。
理想情况下，未来智能体AI无需伪装成人类点击网页，而可以直接、合法地“帮用户比价下单”，平台也能保留监管与服务能力。不过，基于GUI的Agent是否会作为过渡手段走入历史？也未必。
GUI走不通的路，只能交给MCP
上月初，有报道指出Comet 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之后基本放弃了这条路线的对外更新。
与GUI试图“模拟用户”不同，MCP试图为智能体AI建立一条“正式入口”，让平台可以把与智能体AI互动的边界显性化：哪些能力可读、哪些操作必须二次确认、哪些业务永远不开放，都可以在协议层直接定义。
更重要的是，MCP将智能体与系统之间的关系，从“依赖UI”提升为“依赖能力”。例如，GUI路线下的“查订单”需要打开App、读取界面、解析文本、定位按钮，经过多次操作才能完成；但在MCP模式下，可能只是一次明确的能力请求：查询、返回、处理。
当然，MCP意味着整个互联网生态需要经历“一场漫长的改造”，也意味着基于GUI路线的智能体AI的体验不可能完全放弃。
写在最后
接下来很可能不会是二者的简单取舍。
GUI会继续作为“兜底”方案，让智能体在未改造完的旧世界里继续前行；MCP则会成为跨系统、跨平台的底层互联方式，为智能体建立清晰的权限、边界与秩序。
在这两者之上，终端设备上新的系统级智能体能理解用户的目标，协调设备、平台与服务，并在平台规则之内完成跨生态、跨智能体任务。
简言之：OS提供统一智能体入口和权限管理，MCP等协议负责和各家服务沟通，Qwen、Gemini、GPT等模型可以被插拔，变成“换大脑但不拆线管”的状态。
这可能才是智能体AI的终局。
发布时间
2025-12-12 16:35:35
评论 ( 0 )