当 AI 开始替人行动，谁有权说了算？

AI Agent 的发展正在进入一个微妙的阶段：一边是技术公司努力让 AI 获得更多权限，使其能够跨应用、跨系统完成任务；另一边是平台开始收紧权限，重新审视 AI 究竟可以访问什么、代表谁行动，以及能够在多大程度上替用户做出决定。

这不是技术发展的倒退，而是 AI 从回答问题走向执行任务之后，必然面对的一次权力重构。

过去，AI 的主要工作是理解和生成信息。即使回答错误，后果通常也停留在信息层面。Agent 不同，它能够调用工具、读取文件、发送消息、操作账户，甚至完成交易。当 AI 从信息系统变成行动系统，能力边界就不再只是模型的能力边界，而成为用户、应用、平台与 AI 之间的权力边界。

问题由此产生：用户授权一个 AI 帮自己完成任务，是否意味着 AI 可以使用用户拥有的全部权限？用户允许 AI 读取一条消息，是否意味着它可以读取整个通信记录？用户要求购买一件商品，是否意味着 Agent 可以绕过平台规则，以用户身份访问账户并完成交易？

这些问题，正在从技术讨论变成真实的产业冲突。

用户授权，不等于平台授权

2025 年，Amazon 向 Perplexity 发出律师函，随后提起诉讼，争议焦点之一是 Comet 浏览器中的 AI Agent 如何访问 Amazon 网站及用户的受保护账户。Amazon 认为，用户允许 Agent 替自己购物，并不等于 Amazon 必须允许第三方 Agent 以这种方式访问其系统；Perplexity 则强调用户有权选择自己的 AI 助手，反对平台借此限制竞争。双方的冲突，将一个此前容易被忽略的问题推到了台前：用户的意愿、Agent 的权限与平台的访问规则，并不是同一件事。

这场争议真正重要的地方，不在于哪一方已经取得了最终答案，而在于 Agent 开始让传统的用户身份、自动化身份和平台访问授权发生冲突。用户委托 AI 办事，并不能自动消除这三者之间的边界。

从传统软件的角度看，浏览器使用用户登录态访问网站，是一种常见的操作方式。但当浏览器中加入能够自主理解页面、规划任务并执行操作的 Agent，原本的访问行为就产生了新的含义：它不再只是展示用户请求的内容，而是在代表用户持续行动，并可能把账户信息和页面数据传回外部 AI 服务。

真正的分界线不是 AI 有没有使用用户的账号，而是它是否清楚地表明自己的自动化身份、是否获得了相应的访问许可，以及行动是否超出了用户与平台各自认可的范围。

这也是为什么，AI Agent 的权限不能简单继承用户权限。用户授权解决的是“我是否愿意让它帮我”，并没有自动解决“它可以怎样行动”。

权限越大，授权越不能含糊

类似的矛盾也发生在个人设备上。

Google Gemini 的应用连接机制揭示了另一个容易被忽略的问题：用户关闭 AI 活动记录，并不意味着 AI 停止调用手机上的通信应用。Google 官方说明显示，在 Android 上，部分电话、消息和 WhatsApp 功能仍可在 Keep Activity 关闭时使用，应用连接也需要通过独立的 Connected Apps 设置管理。这说明，用户理解的“关闭记录”，与系统实际执行的“关闭访问”，可能是两件不同的事。

争议的关键，正是用户能否清楚理解这些设置之间的区别，以及应用连接、数据使用和具体操作是否得到足够明确的告知与授权。当 AI 能够接触通信、联系人和其他个人数据时，笼统的功能开关很难让用户准确判断自己究竟开放了什么。

苹果近期收紧 macOS 完全磁盘访问（Full Disk Access）的安排，则从操作系统层面回应了同一问题。完全磁盘访问原本具有特定用途，但一旦被应用用于广泛读取文件、邮件、消息和浏览记录，就可能让一个看似普通的 AI 工具获得远超当前任务需要的数据访问能力。苹果因此表示，将增加控制措施，要求用户通过更明确的操作授予这种高等级权限。

这几个案例看似分别属于电商、移动应用和桌面操作系统，背后却指向同一种结构性矛盾：AI 的任务需要是局部的，传统权限却往往是整体的；AI 的行动是动态的，传统授权却经常是一次性的。

当 AI 只需要完成一个任务，系统却授予它长期、广泛、可跨场景使用的权限，风险便不再取决于用户最初的意图，还取决于模型如何理解任务、如何应对异常，以及是否会被恶意内容诱导。

从模拟操作走向声明式授权

解决这个问题，不能只靠提醒用户谨慎授权，也不能完全依赖模型自身的判断。更合理的方向，是改变 AI 获得能力的方式。

豆包手机探索的 SAEP（声明式自动化交互协议），试图让 GUI 自动化操作的边界变得明确；MCP 则为模型连接外部工具和服务提供标准化方式。两者解决的问题并不完全相同，但都体现出一个重要方向：让 AI 不必总是依靠模拟人的屏幕操作来完成任务，而能够通过更明确的接口理解自己可以调用哪些能力。

这意味着，系统不应只问 Agent 能否操作某个应用，还应进一步判断：它当前执行的是什么任务，需要哪些具体能力，能否读取这份数据，是否可以发送消息，以及在付款、授权、删除等高风险动作发生之前，是否必须再次取得用户确认。

当然，协议标准化并不等于安全问题自动解决。一个通过 MCP 暴露的工具，如果本身拥有过大的权限，仍然可能造成越权；一个遵循 SAEP 的自动化系统，如果无法识别恶意页面中的指令，也仍然可能被提示词注入利用。豆包探索的 SAEP，试图让 GUI 自动化交互的意图和边界更加明确；MCP 则为模型调用外部工具与服务提供标准化接口。它们并非同一种协议，但指向相近的工程方向：让 Agent 的能力不再只是隐含于一连串屏幕操作，而能够通过更明确的接口表达、调用和约束。

因此，真正需要建立的不是一套更复杂的授权弹窗，而是一种与任务相匹配的权限机制：任务结束，临时权限随之失效；读取权限不能自动升级为写入权限；能够查看数据不代表可以向外发送；涉及财务、身份和不可逆操作时，应当保留明确的人工确认。

AI Agent 的用户采用最终会落在信任上

从更长的产业周期看，AI Agent 正在推动软件从“向用户提供功能”转向“替用户完成目标”。这会改变应用接口的设计方式，也会改变操作系统、企业 IT 和平台服务商之间的责任划分。

过去，软件厂商争夺的是用户入口、功能体验和数据规模。Agent 时代，竞争还将增加一个维度：谁能够安全、可信地代表用户行动。

对企业而言，这意味着采购 Agent 不能只看模型能力和任务成功率，还要审查身份隔离、最小权限、数据流向、操作审计、权限撤销以及高风险操作的人工确认机制。对平台而言，开放接口与保护系统边界并不矛盾，真正重要的是让第三方 Agent 的身份、能力和访问行为可以被识别、授权与约束。

AI 越强大，越不能把“用户曾经授权”理解为一张可以无限透支的通行证，AI 从工具走向行动主体时，真正需要建立的信任基础，案例已让一个过去不太显眼的问题变得无法回避：用户授权 AI 替自己办事，究竟意味着什么？

用户拥有账户，不代表 AI 可以任意使用这个账户；用户提出目标，不代表 AI 可以自行决定所有执行方式；系统允许调用工具，也不代表每一次调用都符合用户的真实意图。

过去，软件竞争的是功能。现在，Agent 开始竞争行动权。

谁能代表用户行动，谁能访问平台，谁能决定一项操作是否需要再次确认，将逐渐成为 AI 基础设施竞争的核心问题。

未来的 Agent，不仅要证明自己能够完成任务，还要证明自己能安全可靠（有权、数据安全处理可靠、无越权）完成任务。

Agent 的成熟，不是它终于能够替用户做所有事情，而是它能够准确判断哪些事情可以做、哪些事情必须再问一次，以及哪些事情即使技术上能够完成，也不应该擅自完成。

AI Agent 的竞争，最终取决于信任