ARTICLE · 1023045
AI手机替你操作App,谁说了算?
AI手机替你操作App,谁说了算?提示词披露：今天看到豆包SEAP协议30天内未拒绝即默示同意相关的讨论，感觉非常有意思。 我个人认为，因为这个是B2B相关的合作，并不适用个人信息/隐私保护相关的告知同意规则，要类比的话其实更像是robot协议，并且如果一家一家去谈合作，获取同意其实太难了，所以某种程度上我也可以理解豆包。 当然，这还涉及到一些更复杂的问题，比如说超级APP肯定因为广告等原因会拒绝加入这个协议，豆包这些Agent依然没有办法自由访问相关的主流APP。最近亚马逊和perplexity在境外的纠纷也有一定的借鉴意义。 对于大的互联网公司，比如说字节、阿里、腾讯而言，如果他们的超级APP只能允许自己旗下的Agent访问，比如说微信只能被元宝访问，淘宝只能被千问访问，感觉这里面可能也有一些问题。 当然我相信在不久的未来，超级智能体他们掌握足够多的流量之后，还会有相反的问题，他们怎么分配流量，可能会成为新的一门广告生意。 于是我和ChatGPT进行了相关讨论，形成了本篇文章。 此前写《AI手机的殊途与同归：豆包与Gemini的合规迷思》时，我讨论过一个问题：当AI Agent获得系统权限，能够替用户打开App、点击按钮、填写信息甚至完成跨应用任务，传统“用户—App”的关系会发生什么变化？当时我猜测，手机厂商迟早需要建立某种“握手机制”，让第三方App表达哪些操作可以交给Agent，哪些需要保留给用户本人。现在，这种机制有了一个具体的版本。 9月14日，豆包手机助手推出“屏幕自动化操作声明协议”（SAEP，Screen Automation Execution Protocol），让第三方App以机器可读的方式声明自动操作边界。最引人注意的是默认规则：30天公示期内，App原则上不会被GUI Agent操作，除非主动声明接受；公示期满，未通过邮件告知且未通过SAEP声明拒绝的，豆包将开放相应操作能力。两种拒绝渠道长期有效，开发者可以随时提出。[1] 为什么采用“没有明确拒绝，就开放能力”，而不是等待每一家App主动加入？这既涉及一套技术规则的法律性质，也涉及一个更大的问题：当AI开始替用户使用互联网，谁有权决定用户能够使用什么工具、进入哪些服务？ SAEP很容易让人想到网站的Robots协议。网站通过robots.txt，向爬虫表达哪些路径可以访问、哪些应当避开；SAEP则让App表达哪些页面和操作可以接受自动化。二者的共同价值，是把经营者的限制要求转化为机器能够识别的规则，减少各说各话以及逐个协商的成本。 但二者有两个重要区别。Robots主要约束爬虫对资源路径的访问，SAEP则进一步涉及截图、输入、内容修改、最终发布、删除及奖励领取，可能直接改变账号、内容或交易状态。Robots文件本身不会阻止访问，实施访问控制仍需另外设置安全措施；按照SAEP的设计，系统会在截图、输入等关键能力入口执行限制，不能只依赖Agent自行遵守。因此，SAEP既提供一套声明语言，也试图把这些声明接入系统的执行机制。[2][3] 相似的技术形式，并不意味着相同的风险，也不意味着可以直接照搬法律结论。网站允许爬虫读取一个页面，与App允许Agent代为发布内容、领取权益，影响范围显然不同。把SAEP称为“Agent时代的Robots协议”有助于理解，但它实际触及的操作边界更深。 讨论默认规则，首先要分清这里的法律关系。App经营者是否接受另一经营者提供的自动操作工具，与自然人是否同意处理个人信息，是两个不同的问题。不能看到opt-out，就把个人信息处理的同意规则搬过来；也不能因为双方都是企业，就认定只要公示满30天，一方可以替另一方作出法律上的决定。 我更倾向于把SAEP理解为技术规范与经营者协作规则的结合。它规定App如何声明限制、系统如何识别并执行，也包含豆包对自身行为的公开安排：在什么条件下开放能力，收到拒绝后如何处理。从目前这些内容本身，不能直接推导出App经营者已向豆包授予访问许可，更不能推导出双方已经就数据使用、责任分配或风险承担达成合同。 Robots协议恰好提供了一个有用的参照。RFC 9309明确写道：“These rules are not a form of access authorization.”也就是说，这套规则本身不是访问授权机制。不过，这首先是技术标准对自身功能的限定，不能单凭这句话判断任何场景下是否成立合同或许可；它真正提醒我们的是，机器读到的“允许”与法律上的权利来源，需要分别判断。[3] SAEP自己的文档也作了类似区分：限制字段未设置时按false处理，但false表示“不由该字段限制”，并不保证系统最终允许执行。即使系统作出ALLOW决定，操作仍需通过App的业务鉴权。这里的默认值，解决的是某一层技术控制是否阻断，不能代替法律判断。[2，第2.5、4.3.2节] 因此，不需要把全文建立在“沉默是否构成意思表示”上，但也不宜说《民法典》完全无关。如果有人进一步主张“开发者不回复，就接受了合作条款或放弃了追责”，仍须回到第140条等规则说明依据，一方公示本身不能凭空制造这种效果。即便相关技术规则后来被纳入合作合同，其效力也应根据具体约定判断，不能扩张到从未加入的经营者。[4] 同样，未通过SAEP拒绝，也不能抹去其他渠道已经表达的限制。双方既有约定、App服务条款以及实际设置的技术措施，仍需分别审查。技术协议能够让边界更清楚，却不能单方面决定这些边界在法律上是否成立。 更根本的问题是：用户本来可以完成的操作，是否必须亲手完成？用户可以打开电商App搜索纸巾、比较价格、加入购物车，现在只是让Agent代劳。在这种情况下，要求Agent运营者另行取得平台许可，究竟是在保护平台已有的权利，还是给用户选择辅助工具增加一道门槛？ Amazon与Perplexity的纠纷已经把这个问题带进法院。Amazon认为，Comet的AI助手在其明确反对后继续进入用户账户，构成未经授权的访问；Perplexity则认为，Comet是用户选择的工具，相关操作由用户发起。双方争执的关键之一，正是谁在访问Amazon的计算机系统。[5] 2026年8月4日，美国第九巡回上诉法院撤销了初步禁令。根据当时提交的技术事实，法院认为，用户借助助手访问Amazon，Perplexity接收浏览器截图并向助手返回操作指令，本身不足以证明Perplexity“进入”了Amazon的服务器，因此Amazon在CFAA及相应加州法主张上的胜诉可能性不足。9月10日，法院又驳回了Amazon的全院复审申请。[5][6] 这个裁判支持区分“用户使用工具”与“工具提供者自行访问”，但没有赋予Agent普遍通行权。法院明确将判断限定于案卷中的技术事实和有关法律，也特别保留了Amazon通过用户服务条款管理访问的空间。换一种控制方式、增加新的事实，或者讨论合同及侵权责任，仍可能需要另外判断。[5，第14—17页及脚注5] 中国也有可以参照的裁判思路。最高法指导性案例263号涉及招聘企业用户通过关联账号服务，转移其已合法获取的简历数据。法院认可在用户授权、合理处理且未扰乱市场竞争秩序的条件下，第三方提供这种便利不构成不正当竞争；平台对数据的投入和经营利益，也不能当然排除用户的合理处理。[7] 关联账号服务与GUI Agent当然不同，但它提示了相近的判断方法：先查用户原本能够做什么，再查第三方实际增加了什么行为及风险。代用户完成一次正常查询，与借助大量账号持续抓取数据、绕过控制、另行经营数据产品，不能只凭“都有用户指令”就作相同评价。现行《反不正当竞争法》第13条也已经对不正当获取、使用其他经营者数据，以及妨碍、破坏网络服务正常运行作出规定，Agent仍须接受这些规则的检验。[8] 如果只看用户需求，让AI少点几十次按钮，似乎很难反对。但对超级App而言，用户从首页推荐、广告、搜索、浏览、比较到交易的整个过程，都可能产生商业价值。平台既提供最终服务，也经营用户抵达这项服务的路径。 Agent可能大幅压缩这条路径。用户说一句“找一家30分钟送到、40元以内的牛肉饭”，Agent就去不同平台比较，再给出结果。交易可能仍在原平台完成，但用户未必再浏览首页、观看推荐或接触交叉销售。平台保留了履约任务，却可能失去一部分注意力和流量分配权。 所以，我更愿意把这种冲突理解为入口控制权的争夺。过去平台希望用户先打开自己的App，未来则可能要争取进入Agent的候选范围。不过，也不宜写成所有App必然抗拒：依赖广告和用户停留的平台，与希望获得新增订单的商家或服务商，动机并不相同。安全风险是真实问题，商业利益同样是真实问题，二者需要在具体场景中分辨。 如果主要平台都只允许关联Agent操作，跨平台服务就很难发展。用户可能拥有许多AI助手，却仍要分别进入各家生态，完成本来希望一次交代的任务。所谓“通用”的价值，会被切割成一个个互不相通的服务范围。 这能够解释豆包为什么选择公示期后的opt-out。与逐个争取主动接入相比，这种安排可能降低协商成本，让没有明确反对、但暂时也没有动力投入适配资源的App，更容易成为可操作对象。这是一种值得讨论的生态建设思路，但其效果仍取决于开发者是否知悉规则、退出是否便利，以及具体操作是否可控。 opt-out只能减少“不表态”造成的障碍，解决不了大型平台“明确拒绝”的问题。如果主要平台都主动退出，默认值如何设置，仍然无法使它们自动开放。 因此，冷启动困难可以解释默认规则的商业动机，却不能单独证明所有访问行为正当，更不能成为忽略拒绝、突破既有权利边界的理由。 这里还有一种更值得讨论的情况：App选择只对特定Agent开放。假设未来微信只允许元宝代用户完成某些操作，淘宝只允许千问完成某些购物任务，其他Agent即使满足同等安全要求，也始终无法获得相应能力。这时需要追问的，就是平台是否借助对既有服务的控制，把用户使用自动化工具的需求导向自己指定的Agent。 这种安排可能改变Agent之间的竞争条件。如果用户难以迁移自己的社交关系或找到足够好的交易服务替代品，他为了继续使用原有App，就可能被迫另选平台指定的Agent。竞争Agent无法完成这些常用任务，又会因此更难吸引用户。原有App的市场力量便可能向Agent服务领域延伸，让后者的竞争越来越取决于谁掌握热门App的接入机会。这种风险值得在Agent市场形成稳定格局以前就加以审视。 法律判断首先要看App经营者在相关服务市场是否具有支配地位，以及限制是否产生排除、限制竞争的效果，不能直接用“超级App”代替市场分析，也不必以关联Agent已经在新市场取得支配地位为前提。拒绝向外部Agent提供接入服务，或者对可比较的交易相对人设置不同接入条件，可以分别沿拒绝交易、差别待遇的路径分析；如果进一步要求用户或商家只能使用指定Agent，还可能涉及限定交易。不过，企业内部的功能整合、向外部经营者提供接入服务、要求用户使用指定工具，是不同安排，需要分别识别交易关系与限制方式，不能把“自我优待”直接当成已经成立的违法类型。[10，第22、23条] 平台当然可以提出安全、责任承担、接入成本和技术适配方面的理由，关联Agent也可能确实在这些方面更成熟。但如果外部Agent已经满足相同的实质条件，平台仍仅因其属于竞争集团而拒绝，就很难只用“保护生态”解释这种差别。2026年《互联网平台反垄断合规指引》已将关闭接口、以歧视性算法设置障碍等列入拒绝交易风险场景，也列出了限定交易和差别待遇的分析路径。第16条承认必要的安全保护和合理经营模式维护，但指出“维持平台生态整体性”一般不属于正当理由。指引本身不具有强制性，最终认定仍须落回《反垄断法》的具体要件。[9，第12、13、15、16、37条] 因此，SAEP让App能够表达拒绝，并不意味着任何拒绝都可以免于竞争法审查。尤其是通过Agent身份识别实现“只放行自己人”时，技术规则也可能成为排斥竞争的执行手段。评价开放程度，除了看App是否允许自动化，还要看它按照什么条件选择Agent，以及这些条件如何影响用户的工具选择。 问题还会反过来。假如未来某个通用Agent成为用户购物、订餐、订票的主要入口，它就能够决定检索哪些平台、排除哪些服务、优先推荐谁。平台今天担心用户绕过自己的首页，未来可能需要担心自己根本没有进入Agent的比较范围。入口权力会随着用户习惯迁移，不会因为入口从App变成AI就消失。 因此，Agent推荐值得单独研究，但没有必要在这里转入《个保法》第24条。更贴近本文的问题是：推荐受到哪些商业关系影响，用户知道它实际比较了哪些对象吗？如果只检索三个合作平台，就不应让用户误以为已经完成全市场比较；如果佣金影响排序，也需要按照实际业务及适用规则处理商业推广的识别和披露问题。 这里所说的中立，也不应被理解为所有Agent必须无差别接入所有App，或者商业合作一律有问题。没有任何产品能够保证检索全部市场。需要警惕的是把有限比较包装成全面比较、把商业推广包装成独立判断，以及在具备相应市场力量时，通过排除竞争者或不合理优待关联服务限制竞争。这些问题即使不依赖用户画像，也同样存在。 再往下一层看，Agent能否操作App，可能在操作系统那里就已经被决定了。SAEP文档涉及Agent的注册身份、签名、类型和可信等级，也提供已注册Agent的查询机制。但这些内容主要说明如何识别已有Agent，并不能据此认定所有竞争Agent都可以通过相同程序获得相同能力。[2，第2.2、2.3、4.6节] 如果一个系统只让自己的合作Agent获得完整截图、输入和后台执行能力，其他Agent即使满足相近的安全要求，也没有明确的申请路径，那么App侧再开放，竞争仍可能被限制在系统入口。反过来，权限涉及真实的系统风险，也不能只凭“公平接入”四个字要求不加区分地开放。真正需要公开的是准入条件、风险标准、能力范围以及拒绝后的复核方式。 未来可能同时存在三层入口控制：操作系统决定哪些Agent获得能力，Agent决定哪些App进入用户的候选范围，App决定如何限制自动操作。因此，评价SAEP是否开放，既要看App能否方便地声明边界，也要看其他Agent是否有可预期的接入机会。技术文档公开，是一个起点，还不足以证明整个生态已经开放。 基于上述区分，我认为，“公示期后开放能力、开发者可以持续拒绝”具有一定合理性，不宜简单定性为“沉默视为授权”。但这种合理性首先是协作机制上的，而不是一份覆盖所有行为的合法性证明。需要继续检验的，至少有以下几个方面。 首先，默认开放不能改变原有权利边界。没有提交SAEP拒绝声明，不意味着App放弃既有合同权益，也不意味着Agent可以任意收集数据、绕开技术措施或改变业务流程。对相关限制是否成立、是否合理有争议，应当根据具体行为及适用法律解决。 其次，拒绝机制必须真正有效。豆包既然公开表示尊重开发者拒绝，就应当提供清楚的生效反馈，并在执行中兑现，不能收到拒绝后换一条通道继续操作。但遵守这项协作安排，也不等于承认App在法律上享有不受审查的绝对否决权；拒绝本身如果涉嫌不当限制竞争，仍可以通过协商、投诉或诉讼处理。 再次，技术控制需要验证实际效果。SAEP已经设计系统基线、页面限制及用户接管，但文档也说明，意图级限制是否具备完整的系统强制能力取决于目标版本。因此，不能把“文档写了限制”直接等同于“所有设备和操作都已受到有效约束”。对于支付、认证、发布、删除等不同动作，应当能够说明限制如何生效、失败后如何处理，并留下可核查的记录。[2，第2.3—2.6节] 最后，规则需要接受双向检验。豆包推动其他App接受自动化时，其合作系统是否也为竞争Agent提供合理机会？Agent要求平台不能无理由封锁自己时，又如何说明自己选择、排除和排序下游服务的依据？如果只要求别人开放，自己的准入和推荐规则却不透明，这套机制很难获得持续信任。 SAEP值得关注，因为它把一场原本隐藏在技术拦截、账号风控和产品适配背后的冲突，变成了可以公开讨论的规则问题。 用户希望更方便地使用服务，App希望控制风险并保护经营利益，Agent则希望建立新的入口。这三种诉求都不能只凭一句“我的手机”“我的平台”或者“为了创新”获得优先地位。 当AI不仅替用户点击，还替用户比较和选择，互联网入口的价值就会继续转移。需要约束的既包括平台如何限制外部工具，也包括Agent如何筛选下游服务，以及操作系统如何分配基础能力。下一阶段真正值得争取的，是让用户仍能选择自己的工具、理解工具的取舍，并有机会改变结果。 谁能替用户作决定，谁就需要解释自己为什么这样决定。 SAEP不失为是字节的一种身先士卒的尝试，后事如何，我们走着瞧。 原文出处 [1] 豆包手机助手开发者页面。包含9月14日起30天公示期、公示期内外默认规则及邮件、SAEP两种长期拒绝渠道。本文核对的是截至2026年9月16日的公开页面。 https://o.doubao.com/developer [2] 《屏幕自动化操作声明协议应用开发接入文档》。重点参见第2.2—2.6节、第4.3.2节、第4.6节。第4.3.2节位于PDF第13页；意图级强制执行的版本限制见第5页；已注册Agent与业务操作权限的区分见第19页。本文说明的是文档设计，未进行设备实测。 官网文档入口：https://o.doubao.com/SAEP_Protocol 官网入口实际加载的PDF：https://os.obriccloud.com/protocol/SAEP [3] IETF，RFC 9309，Robots Exclusion Protocol。参见第1节关于访问授权的说明、第2.2.2节关于路径规则、第3节关于安全措施的说明。 https://www.rfc-editor.org/rfc/rfc9309.html [4] 《中华人民共和国民法典》，第140条、第465条。第140条对沉默被视为意思表示规定了条件；第465条规定依法成立的合同原则上仅对当事人具有法律约束力。此处引用用于说明不能单凭一方公告推定另一方已接受合同、许可或权利放弃，不意味着SAEP当然构成合同。 https://www.moj.gov.cn/pub/sfbgw/zwgkztzl/2025nianzhuanti/2025mfdxcy/2025mfdxcy_mfdql/202505/t20250507_518708.html [5] Amazon.com Services, LLC v. Perplexity AI, Inc., No. 26-1444，第九巡回上诉法院2026年8月4日意见。参见第14—17页关于访问主体与裁判范围的分析，以及第21页脚注5关于用户服务条款的保留说明。本案为初步禁令上诉，不是对全部争议的终局判决。 https://cdn.ca9.uscourts.gov/datastore/opinions/2026/08/04/26-1444.pdf [6] 同案2026年9月10日驳回全院复审申请的裁定，DktEntry 71.1。以下为裁定原件的公开转载。 https://www.courthousenews.com/wp-content/uploads/2026/09/amazon-perplexity-no-rehearing.pdf [7] 最高人民法院指导性案例263号，某网络信息技术有限公司诉某信息科技有限公司不正当竞争纠纷案，2025年8月28日发布。本文仅作有限类比，不将关联账号服务裁判扩张为所有GUI自动操作均合法。 https://www.court.gov.cn/shenpan/xiangqing/474461.html [8] 《中华人民共和国反不正当竞争法》（2025年修订），第13条，特别是第2款关于妨碍、破坏网络服务正常运行的规定及第3款关于不正当获取、使用数据的规定。 https://www.cnipa.gov.cn/art/2026/5/20/art_104_206437.html [9] 市场监管总局《互联网平台反垄断合规指引》，国市监反执一发〔2026〕16号，2026年1月28日成文、2月13日发布。参见第9、12、13、15、16、37条。本文有关“中立性”的表述是治理建议，不主张现行法对所有Agent规定了普遍、无条件的平等接入或推荐义务。 https://www.samr.gov.cn/zw/zfxxgk/fdzdgknr/fldzfys/art/2026/art_ad10c5301fcb426cb839153ca9f5a274.html [10] 《中华人民共和国反垄断法》（2022年修正），第22条、第23条。第22条第1款第3、4、6项分别涉及拒绝交易、限定交易和差别待遇，第2款明确禁止利用数据、算法、技术及平台规则实施前款规定的滥用行为；第23条规定支配地位的认定因素。文中微信与元宝、淘宝与千问的选择性开放场景均为假设，不表示这些平台已经实施相关行为或已被认定违法。 https://www.samr.gov.cn/zw/zfxxgk/fdzdgknr/fgs/art/2023/art_f0fae9eb3a684fc39e84d89eabfc2caa.htm