智能体与传统App之间并非简单的替代关系。它既可能吸收工具类App的部分功能，也可能成为新的用户入口和服务分发层，使App逐步从直接面对用户的前台产品，转变为被调用、排序、比较和采购的后台能力提供者。由此产生的摩擦，本质上是入口流量、数据访问、交易机会、广告展示、系统权限和责任承担的重新分配。

从技术上看，智能体与App交互主要存在两条路径：一是协议化路径，由App、平台或服务方通过接口、能力声明或智能体协议主动开放功能；二是GUI路径，由智能体通过屏幕感知、视觉理解和模拟点击等方式操作App界面。前者更利于授权、审计和追责，后者覆盖面更广，但也更容易触及App授权、伴随性数据收集、页面流程、反自动化和交易安全等问题。

合规分析不能仅判断“用户是否同意”，而应同时审查用户授权、服务方授权、系统权限、数据处理边界、关键交易确认、入口公平及责任追溯。较可行的治理方案，是以协议化路径处理可标准化、高风险和强审计任务，以受限GUI路径补充低风险和长尾场景，并对高风险操作设置更严格的分层授权、人工确认、失败保护和日志审计。

一、从端侧AI到系统级智能体

（一）从功能增强到任务执行

端侧AI的早期形态，是把大模型能力拆分为写作、翻译、修图、会议纪要、搜索增强、相册问答和通话摘要等功能。用户仍需知道应打开哪个App、进入哪个页面、点击哪个按钮，AI主要扮演既有系统或App的“增强件”。

进入智能体阶段后，产品逻辑开始从“回答问题”转向“完成任务”。当用户提出“帮我订明天去上海的高铁并提醒我提前出发”“找一家附近能堂食的粤菜馆并订位”或“把这张发票提交到公司报销系统”时，智能体需要理解意图、补全条件、规划步骤、选择服务、调用接口或操作界面，并对执行结果进行校验和反馈。

因此，AI智能体（AI Agent，下称“智能体”）并不等同于大模型本身。除语言理解和内容生成外，它还需要任务规划、工具调用、环境感知、状态记忆、行动执行和结果校验等能力。终端智能化可大致表现为四个层级：问答与生成、工具调用、跨应用执行，以及能够自行拆解步骤并处理异常的自主规划与反馈。[1]

这四个层级对App生态的影响逐级加深。问答与生成主要替代信息型和内容型功能，对App入口影响相对有限；工具调用开始把搜索、地图、日历、邮件和支付等服务抽象为可调用能力；跨应用执行会重新分配App内流量、广告、推荐和交易机会；自主规划则意味着智能体可以根据用户目标选择服务商、处理异常并反馈结果，授权、责任和消费者确认机制因而成为产品能力的一部分，而不再只是后台合规要求。

华为围绕HarmonyOS、小艺和鸿蒙智能体框架（Harmony Agent Framework，HMAF）推进应用能力接入系统；荣耀通过YOYO智能体、MagicOS和MagicGUI探索界面理解与跨应用执行；其他手机厂商也在端云协同、系统级AI和个人智能体方向持续布局。域外的App Intents、Gemini及 Project Astra、Microsoft Copilot Agents等产品和开发框架，则显示出模型工具调用、系统调度和应用能力声明并行发展的趋势。[2]

需要强调的是，“端侧推理”和“端侧执行”并非同一概念。模型可以在云端完成推理，却在终端上读取设备状态并执行操作；也可以在本地完成理解，但仍调用云端App服务。不同架构决定了个人信息是否离开设备、由谁承担个人信息处理者责任、日志保存在哪里，以及出现错误时能否回滚。

系统级智能体更接近一种“行动中介”：它有时代表用户，有时也承载手机厂商、模型服务商或生态平台的商业目标。它既可能帮助App触达用户，也可能绕过App原有的展示、排序、广告和风控机制。正因为智能体具备主动选择和执行能力，App生态中的摩擦才会从功能相似上升为控制权、数据和责任的冲突。

（二）执行能力如何引发实践摩擦

实践中的冲突往往从具体体验开始：智能体打开App时是否跳过开屏广告；点外卖时是否默认选择某一平台或商家；订酒店时是否只调用特定在线旅游平台；进入社交、支付或内容App时，是否被识别为异常自动化访问；读屏过程中是否接触聊天记录、订单、地址、支付信息或商家经营数据。

豆包手机助手与nubia M153引发的公开讨论，是观察此类冲突的一个窗口。公开报道涉及微信登录异常、各方对安全和兼容问题的不同说明，以及智能体直接操作微信能力的调整。由于事件涉及多方表述，其事实边界仍需结合相关企业的最新公开说明审慎判断。[3]这一争议的法律意义不在于智能体“能否打开微信”，而在于用户授权、App的安全控制和系统级智能体的操作权限应如何衔接。

在银行、支付和证券App中，冲突会更加尖锐。智能体若直接触及登录认证、验证码、安全键盘、转账汇款、理财申购、风险测评或交易确认，就不再只是第三方工具兼容问题，还涉及客户身份识别、交易指令真实性、反欺诈风控、金融消费者保护和资金损失责任。

金融机构通常按照设备环境、操作轨迹、登录方式和交易行为识别欺诈风险。系统级智能体的点击和输入可能与自然人操作不同，也可能使机构无法判断指令究竟来自客户、模型还是第三方服务。即使用户原则上同意由智能体代办，也不意味着其可以绕过安全键盘、动态验证码、风险测评和本人确认等强制性或合同约定的控制措施。对智能体运营者而言，则需要在产品设计阶段明确哪些场景只能提供信息或辅助填写，哪些场景可以提交，哪些场景必须交还用户亲自完成。

同样值得关注的是智能体的“选择权”。用户提出“帮我订一家附近的酒店”时，智能体可能只调用一家在线旅游平台，也可能先比较多家平台后给出结果；用户提出“买一箱矿泉水”时，智能体可能优先进入手机厂商合作的电商平台。此类默认选择未必直接构成违法，但会影响其他经营者的交易机会和用户的价格认知。智能体是否披露候选范围、排序因素、商业合作和自营关系，将成为判断入口公平与消费者知情的重要事实。

二、智能体正在重构其与App之间的关系

（一）三种关系形态

智能体并不稳定地落在一个产品类别中。根据其功能和入口地位，它与App之间可能形成三种并存的关系形态。

第一，横向或相邻竞争关系。智能体作为超级App或系统功能，直接提供翻译、搜索、笔记、比价、行程规划和跨App操作等服务，对工具型、标准化和低黏性App形成部分替代。此时应关注功能替代是否伴随不当流量截取、未经授权的数据获取或对App正常运行的实质干扰。

越是功能单一、标准化程度高、缺乏独立内容和社交关系沉淀的App，越可能被系统能力吸收。天气、扫描、基础翻译、简单图片处理和笔记整理等功能，本身更接近通用工具；但旅行规划、网约车、购物和内容服务往往需要调用外部库存、履约、支付和售后能力，智能体更可能成为新的服务编排者，而非完全替代原有App。

第二，类平台与平台内经营者关系。智能体成为用户表达意图和获得服务的入口，App需要被智能体识别、调用、排序和推荐才能取得流量。若智能体运营者同时提供自营服务，就可能出现默认调用、自我优待、差别排序、排他合作、接入条件不透明和数据回流等问题。

在这种关系中，接口目录、技能市场或工具注册表可能承担与应用商店和搜索结果类似的分发功能。接入规则是否公开、能力描述能否被准确识别、排序是否受商业付费影响、调用失败是否会被降权，以及智能体能否利用第三方交易数据改进自营服务，都可能成为平台治理问题。

第三，采购与供应关系。随着“意图即服务”逐步成熟，部分App可能退居后台，为智能体提供库存、内容、支付、订单和售后能力。竞争重点将从争夺下载和打开，转变为争夺被智能体纳入候选、取得排序优势和获得交易归因的机会。由此会产生接口标准、调用费率、责任分担、拒绝接入和谈判力量失衡等问题。

当用户主要面对智能体而非具体App时，交易链条可能同时包含智能体运营者、操作系统提供者、模型服务商、接口平台、实际商品或服务提供者和支付机构。各方应在用户可理解的层面说明谁是交易相对方、谁负责履约和售后，不能让后台技术链条成为弱化前台责任的理由。

三种形态不是严格的时间阶段，也不会彼此取代。例如，同一个智能体可能在翻译场景中直接替代 App，在酒店预订场景中成为分发平台，在企业办公场景中又成为采购和编排后台服务的代理人。

（二）入口、数据与交易的重新分配

智能体首先改变入口和流量。过去用户直接打开App，App获得首页展示、推荐、广告、会员活动和交易转化机会；当用户只向系统助手表达目标时，智能体可能直接展示结果或完成交易。谁能进入候选、排序依据为何、是否优先调用自营服务，因而成为新的竞争焦点。

其次是数据和可见性。智能体为完成任务，可能读取屏幕、通知、剪贴板、位置、相册、联系人和订单，也可能接触App内的价格、库存、评价、商家信息和风控信号。分散在不同App中的数据由此可能被拼接为跨App的用户画像和完整任务链路。用户同意智能体完成任务，并不当然等于App同意其读取、解析或复用界面数据；反过来，App也不能仅凭平台规则当然否定用户委托工具实施的一切普通操作。

最后是交易和控制。当下单、支付、退订、改签和售后由智能体代为完成时，用户的真实意思表示、服务商选择、价格展示、优惠适用、取消规则和责任承担都会变得更复杂。越接近财产处分、身份认证或不可逆后果，越需要保留清晰的用户确认、失败保护、撤销申诉和操作日志。

入口、数据和交易并非彼此独立。智能体利用系统权限取得更丰富的用户数据，可能据此提高排序和推荐能力；排序又决定哪些服务商获得交易；交易结果继续形成新的用户画像和训练数据。因而，单纯从隐私、竞争或消费者保护中的某一个部门法出发，往往无法完整评价系统级智能体的影响。

三、两类交互技术路径

智能体与App之间的交互主要有两类基本模式：一类是App、平台或服务方主动开放能力，由智能体通过协议或接口调用；另一类是App并未主动开放能力，由智能体通过读屏、屏幕理解和模拟点击等方式进入App界面。前者更接近协作，后者更接近介入。

（一）协议化路径：调用被声明的能力

协议化路径的基本逻辑，是由App、平台或服务方主动开放可被调用的能力，智能体在用户授权、服务方授权和接口权限范围内完成任务。不同协议和框架所处层级并不相同，可以进一步区分为四类。

一是API和SDK等直接接口集成。服务方开放搜索、查询、库存、下单、支付、地图、日历、消息或客服等能力，并通过身份认证、权限范围、调用频次、日志审计和风控规则控制风险。

传统接口通常需要逐家谈判和适配，服务方可以较精确地限定字段、动作和调用频率，也便于确定合同关系和服务等级；但其覆盖范围取决于头部平台是否愿意开放，以及中小App是否有能力承担改造和运维成本。接口开放不足，正是GUI路径仍有现实需求的重要原因。

二是操作系统能力声明。Apple App Intents、华为HMAF等框架允许开发者将应用中的实体、动作或服务声明给系统，使系统助手在预设边界内发现和调度相关能力。

三是智能体与工具、数据源的标准连接。模型上下文协议（Model Context Protocol，MCP）允许AI应用通过客户端连接不同服务器，由服务器暴露工具、资源和提示等能力，从而降低逐一适配的成本。当前正式协议版本为2025-11-25，其安全资料重点提示混淆代理、令牌透传、服务器端请求伪造、会话劫持、权限范围过大以及本地服务器执行风险。[4]

四是智能体之间的互操作。Agent2Agent（A2A）主要解决独立智能体之间的能力发现、任务委派和结果交换；MCP主要处理智能体与工具、API和资源的连接。两者可以共同构成协议化生态，但不应混为同一种App接口。[5]

对用户而言，协议化调用的过程通常不可见：一个简单指令可能触发多个工具、服务器和远程智能体。产品因此需要提供足够透明度，让用户知道哪些主体参与任务、哪些数据被发送、哪些动作需要额外确认，并确保远程智能体不能仅凭上游传来的模糊授权获得超出任务需要的权限。

协议化路径准确、可控且便于审计，但也存在接入成本、覆盖不足、接口权限过宽、访问令牌泄露、数据二次复用、默认排序、自营服务优先和接入条件不公平等风险。

（二）GUI路径：像用户一样操作界面

GUI路径不依赖App主动开放接口，而是通过截图、窗口信息、无障碍事件或系统能力获取界面状态，再由视觉语言模型或GUI专用模型理解控件和文字，规划任务步骤，并通过点击、滑动和输入完成操作。AutoGLM、UI-TARS和MagicGUI等研究展示了移动GUI理解和执行能力的发展。[6]

其优势是覆盖面广：只要界面可见，理论上就可以识别和操作，即便App没有开放API，也能完成一定程度的跨应用执行。这使GUI路径在超级App相对封闭、标准化接口不足、长尾应用众多的移动互联网生态中仍具有现实空间。

其风险也更集中：智能体可能在App未主动授权的情况下进入内部流程，伴随性读取个人信息和经营数据，绕过广告、推荐、风控或反自动化规则，也可能因页面变化、弹窗干扰或模型误判而执行错误操作。在支付、金融、医疗和未成年人服务等场景中，这些风险会被进一步放大。

GUI执行通常包含四个连续环节：获取当前界面状态；把像素、控件、文字和布局转化为语义；根据用户目标规划下一步操作；执行点击、滑动或输入并再次读屏确认结果。任何一个环节都可能出错。界面被广告遮挡、按钮位置变化、同名商品混淆或网络加载延迟，都可能使智能体把“看起来完成”误判为“已经完成”。因此，关键操作不能仅依赖最终截图，而应通过可验证的状态反馈或接口回执确认。

（三）更可行的部署模式

协议化与GUI并非非此即彼。较可行的部署方式是：可标准化、风险较高或需要强审计的操作优先通过授权接口完成；接口覆盖不到、风险较低、临时性或长尾性的操作，再由受限GUI路径补充。

支付、转账、授权登录、金融交易、医疗预约、未成年人服务、订单提交、退订和改签等关键节点，原则上应设置可靠身份认证和显著的用户确认。页面跳转、低风险信息查询、表单辅助填写和无交易后果的导航操作，可以在满足必要性、透明性和可撤回要求的前提下由GUI路径完成。

混合模式还应避免“名为接口、实为读屏”的模糊设计。产品应向用户和合作方清楚标识每一步采用何种路径，分别记录接口调用日志与GUI操作日志；当接口不可用而准备自动切换到GUI时，应重新评估权限和风险，而不应默认沿用接口场景下的全部授权。

下篇预告：

在明确协议化路径与GUI路径的技术特征之后，合规分析应当从何展开？关于系统级入口的自我优待、跨App数据治理、代客交易中的责任分配，以及两条路径各自面临的特殊合规问题的讨论，敬请期待本文下篇。

[主要参考资料]

1. 电信终端产业协会：《终端智能化分级研究报告》；Levels of AGI for Operationalizing Progress on the Path to AGI； Personal LLM Agents；Levels of AI Agents。

2. 华为开发者联盟“天工计划·鸿蒙智能体开发者激励”及HarmonyOS AI资料；荣耀MagicOS、YOYO智能体官方资料；Apple Developer App Intents；Google DeepMind Project Astra；Microsoft Copilot官方资料。

3. 21世纪经济报道：《“豆包助手”手机用户使用微信异常？字节+中兴的AI故事怎么讲》；证券时报网转载深圳商报《豆包AI手机引发下一轮范式迁移？》。相关事件事实需结合企业最新公开说明审慎判断。

4. Model Context Protocol：2025-11-25 Specification、Authorization Specification、Security Best Practices及Versioning资料。

5. Agent2Agent Protocol官方说明及规范；Apple App Intents；华为鸿蒙智能体框架相关官方资料。

6. AutoGLM: Autonomous Foundation Agents for GUIs；UI-TARS；MagicGUI。