你的手机屏幕，正在成为 AI 的新战场。豆包手机助手的自动化协议公示期刚结束，腾讯、阿里、美团、快手，连同 Kimi、DeepSeek，155 款应用集体投下反对票。这不是一次普通的产品摩擦，而是一场关于「谁有权操作你的手机」的路线之争。
一件事：AI 想替你用手机，应用们说不
10 月 14 日，豆包手机助手《屏幕自动化操作声明协议》（SAEP）30 天公示期正式结束。官方公布的名单显示，已有 155 款第三方应用明确拒绝 AI 自动化操作。
这份拒绝名单的含金量极高：腾讯、阿里、美团、快手旗下多款产品悉数在列，就连同为 AI 棋手的 Kimi、DeepSeek 也加入了拒绝阵营。可以说，这是中国互联网头部厂商的一次集体表态——在 AI 自动化操作这件事上，没人愿意先开门。
SAEP 协议的核心逻辑其实并不复杂：把 AI 屏幕自动操作的选择权交还给应用开发者。开发者可以自主决定是否允许豆包助手执行屏幕识别、模拟点击等操作。规则设计上有几个关键点：
- 公示期内，应用默认不开放权限；
- 公示结束后，未明确拒绝的应用将按风险分级逐步开放；
- 已拒绝的应用，后续也可以随时调整声明；
- 该权限仅影响 AI 代操作，用户手动使用不受影响。
用一句话概括：豆包想借道「无障碍/屏幕读取」能力，让 AI 直接替用户点外卖、发消息、订票；而应用厂商们，正在审慎地把这道门关上一半。
为什么厂商们如此警惕？
理解这场博弈，需要看清两个层面的利益纠葛。
第一层：安全与责任边界。 AI 模拟点击意味着第三方 AI 可以读取屏幕内容、替用户做决策。一旦出现误操作、隐私泄露、资金损失，责任算谁的？是用户、豆包，还是被操作的应用？在责任界定模糊之前，拒绝是最理性的选择。 第二层：入口之争。 这才是更深层的原因。如果 AI 助手可以直接代替用户完成「打开 App → 搜索 → 下单」的全流程，那么传统 App 的首页、推荐流、广告位价值都将被绕过。AI 成了新的流量入口，App 沦为后台接口。对靠广告和分发变现的平台来说，这等于把命脉交到别人手里。我们不妨用一个简单的架构对比来看这两种交互范式的差异：
# 传统交互：用户在 App 内完成闭环
user → 打开App → 浏览推荐流 → 点击下单 → 应用获得完整行为数据
# AI 代操作：豆包接管 UI 层
user → 对豆包下达指令 → 豆包屏幕识别+模拟点击 → 应用只收到"一次点击"
↑ 应用失去用户注意力，入口价值被架空
技术上的攻与防
从技术视角看，这类「手机 Agent」的典型实现路径是：屏幕截图/无障碍接口读取 UI 树 → 多模态模型理解页面意图 → 生成点击坐标或控件操作 → 执行并循环校验。一个极简的示意：
class PhoneAgent:
def step(self, task: str):
ui_tree = self.capture_screen() # 屏幕识别
action = self.model.decide(task, ui_tree) # 模型决策
self.execute(action) # 模拟点击
if self.verify(task):
return "done"
return self.step(task) # 循环直到任务完成
而应用侧的防御同样在升级：检测无障碍服务的异常调用频率、对自动化点击做风控识别、动态打乱控件结构增加模型理解成本。攻防两端都在快速演化。
事实上，屏幕操作类 Agent 是当前 AI 行业的共识方向——OpenAI 的 Operator、Anthropic 的 Computer Use 走的都是这条路。但海外更多通过浏览器插件、官方 API 合作的方式推进，而豆包选择了直接接管手机屏幕这条更激进、也更触碰利益红线的路径。
这场博弈的终局是什么？
短期看，SAEP 提供了一个相对优雅的制度设计：默认关闭、分级开放、声明可撤回。这给了行业一个「渐进试水」的缓冲带——愿意的先合作，警惕的先观望。
长期看，解局的关键可能不在对抗，而在官方接口。如果应用厂商愿意开放标准化的 Agent API（类似 Function Calling），让 AI 通过结构化接口而非模拟点击完成任务，安全、责任、利益分配都有了谈判空间。用户要的是「任务被完成」，而不是「屏幕被点击」。
155 款应用的集体拒绝，不是 AI Agent 的失败，而是行业在为新的规则定价。真正的手机 Agent 时代，大概率不会以「绕过 App」的方式到来，而是以「App 主动拥抱 AI 接口」的方式到来——前提是，利益分配谈得拢。
