1. 一个反直觉的观察越顺手的入口越难被Agent接管过去两年我一直在做AI Agent相关的落地项目从最早的浏览器自动化脚本到后来的多步任务编排再到最近尝试把Agent接入到真实的用户日常场景里。踩过的坑不算少但有一个感受越来越强烈中国互联网过去十几年最引以为傲的便利性恰恰是AI Agent落地时最头疼的障碍。这话听起来有点绕我换个说法。你在手机上点外卖打开App、选餐、下单、支付整个过程行云流水三分钟搞定。但如果你想让一个AI Agent替你做这件事你会发现它几乎无从下手——没有统一的接口没有标准化的操作协议每一步都藏在某个App的私有逻辑里甚至同一个功能在不同版本、不同机型上的表现都不一样。这不是技术不够强的问题而是整个生态的设计哲学和Agent的工作方式之间存在根本性的错位。中国互联网的产品逻辑是把用户留在我的App里而Agent的逻辑是跨应用完成任务。一个要筑墙一个要拆墙天然对立。这篇文章我想把这个问题拆开讲清楚为什么中国互联网的便利性反而成了Agent的麻烦这个麻烦具体体现在哪些层面作为开发者或者产品从业者我们能做些什么以及从技术架构的角度有没有可能绕过这些障碍2. 便利性的代价超级App把一切收进了一个黑盒2.1 从网页互联到App孤岛的转变早期的互联网是网页的世界。每个网站有自己的URL浏览器可以自由跳转搜索引擎可以抓取内容用户从一个页面到另一个页面只需要点一个链接。那个时代如果你要做一个自动化工具本质上就是模拟HTTP请求、解析HTML、提取数据技术门槛不高通用性也强。但移动互联网时代彻底改变了这个格局。微信、支付宝、美团、抖音这些超级App把用户的时间和数据都收进了自己的围墙里。你想点外卖打开美团App。你想打车打开滴滴App。你想买东西打开淘宝App。每个App都是一个独立的王国有自己的账号体系、自己的支付通道、自己的交互逻辑。这种模式对用户来说确实方便——一个App解决一类需求界面统一体验流畅。但对Agent来说这意味着每一个App都是一座需要单独攻克的堡垒。没有通用的操作协议Agent只能通过模拟点击、模拟输入的方式来完成任务也就是所谓的GUI自动化。2.2 微信小程序便利的极致也是封闭的极致微信小程序是这个趋势的典型代表。它把大量轻量级服务收进了微信生态用户不用下载安装扫码即用用完即走。从用户体验角度看这是天才的设计。但从Agent的角度看小程序是一个完全封闭的沙箱环境——它运行在微信的运行时里有自己的API体系外部程序几乎无法直接调用。我去年尝试过一个项目想让Agent自动完成微信小程序里的某些操作。结果发现小程序的页面结构是动态渲染的传统的DOM解析根本拿不到有效信息。而且微信对自动化工具的风控非常严格稍微频繁一点的操作就会触发验证。最后这个项目只能放弃改用人工辅助的半自动方案。这里有一个关键认知小程序的便利是建立在封闭之上的。它之所以能做到即用即走是因为微信控制了整个运行环境。而Agent需要的是开放、标准化的接口这两者在底层逻辑上是矛盾的。2.3 操作系统层面的碎片化再往下一层看操作系统本身也是一个障碍。Android和iOS的权限模型不同不同厂商的定制系统又有各自的限制。一个Agent要在手机上完成任务需要处理的通知权限、悬浮窗权限、无障碍服务权限、后台运行权限……每一项都可能成为拦路虎。更麻烦的是国内Android生态的碎片化程度远超想象。同一个App在不同品牌手机上的表现可能完全不同有的能正常自动化有的会被系统拦截有的甚至根本装不上。我见过一个案例某个自动化脚本在小米手机上跑得好好的换到华为手机上直接闪退排查了半天发现是系统级的后台限制策略不同。这种碎片化意味着Agent的适配成本不是线性的而是指数级的。每增加一个App、一个平台、一个系统版本需要处理的情况就多一层。3. Agent需要什么标准化接口与可预测的环境3.1 Agent的工作范式感知、规划、执行要理解为什么中国互联网生态对Agent不友好先得搞清楚Agent是怎么工作的。一个典型的AI Agent包含三个核心环节感知获取当前环境的状态信息比如屏幕上有哪些元素、当前在哪个页面、有哪些可操作的按钮规划根据任务目标和当前状态决定下一步做什么执行通过某种方式操作环境比如点击按钮、输入文字、调用接口在理想情况下这三个环节都应该有标准化的接口。感知可以通过结构化的API获取数据规划可以由大模型完成执行可以通过标准化的操作指令实现。但在现实中尤其是在移动端这三个环节都充满了不确定性。3.2 API经济与Agent的天然契合为什么国外的Agent生态看起来更成熟一些一个重要原因是API经济的普及。Stripe做支付有APIShopify做电商有APISlack做通讯有API甚至连传统的银行和航空公司都在提供API。这意味着Agent可以通过调用API来完成任务而不需要模拟人类操作界面。API方式的好处是显而易见的稳定、高效、可预测。Agent不需要关心界面怎么变只需要按照API文档传参数就行。而且API通常有明确的错误码和限流策略Agent可以根据这些信息做出合理的决策。但在中国互联网生态里面向消费者的API非常稀缺。大多数App不提供公开API即使有也是面向企业客户的需要复杂的商务流程才能接入。这就逼着Agent只能走GUI自动化这条路而GUI自动化的稳定性和效率都远不如API。3.3 一个具体的对比订机票这件事举个例子说明差距。在美国如果你想做一个订机票的Agent你可以接入Amadeus或Sabre的API直接查询航班、比价、下单。整个过程是结构化的Agent只需要处理JSON数据。但在国内你要订机票要么接入携程的企业API门槛很高要么模拟操作携程App。后者意味着Agent需要打开App、处理开屏广告、定位到机票入口、输入出发地和目的地、选择日期、等待搜索结果、解析航班列表、选择航班、填写乘机人信息、选择支付方式、完成支付。每一步都可能出问题——广告弹窗遮挡了按钮、搜索结果加载慢、乘机人信息需要从通讯录读取、支付需要指纹或密码验证。这就是差距。不是Agent不够聪明而是环境太复杂、太不可预测。4. 破局思路在封闭生态里找缝隙4.1 无障碍服务目前最可行的GUI自动化方案如果你现在就要做一个能在国内App上完成任务的Agent无障碍服务Accessibility Service可能是最现实的选择。Android系统提供的这个功能原本是为了帮助残障人士使用手机但它恰好也提供了读取屏幕内容和模拟操作的能力。我实测下来无障碍服务的几个关键能力包括读取当前屏幕上的所有控件信息包括文本、位置、可点击状态模拟点击、滑动、输入文字等操作监听页面变化事件实时感知界面更新但无障碍服务也有明显的局限。首先它只能拿到系统渲染后的控件树如果App用的是自绘引擎比如Flutter或游戏引擎控件信息可能完全拿不到。其次很多App会检测无障碍服务是否开启一旦发现就限制功能或直接退出。第三不同厂商对无障碍服务的限制策略不同有的会定期杀掉后台的无障碍进程。实操建议如果你要走无障碍服务这条路一定要做好异常处理和重试机制。我通常会在关键步骤加上等待控件出现的逻辑超时后截图保存现场方便后续排查。另外尽量模拟人类的操作节奏不要连续快速点击否则很容易触发风控。4.2 微信生态的特殊处理从协议层入手微信是国内Agent最难啃的骨头但也不是完全没有办法。目前常见的几种思路第一种是Hook方案通过注入代码来拦截和修改微信的内部调用。这种方案技术门槛高稳定性差而且随着微信版本更新很容易失效。更重要的是这种方案存在合规风险不建议在产品中使用。第二种是UI自动化方案也就是前面说的无障碍服务。微信对无障碍服务的检测比较严格但通过一些技巧比如随机化操作间隔、模拟真实用户行为模式可以降低被检测的概率。第三种是借助微信开放能力比如公众号、小程序、企业微信等提供的官方接口。这些接口虽然不能覆盖微信的所有功能但在特定场景下是合规且稳定的选择。比如你要做一个自动回复的Agent用公众号的客服接口就比Hook方案靠谱得多。4.3 操作系统层面的机会AI OS的想象空间最近AI操作系统这个概念很热我觉得这个方向值得关注。如果操作系统本身能够提供Agent友好的接口很多问题就迎刃而解了。想象一下如果手机系统提供一个任务执行框架App可以选择性地暴露一些标准化的操作接口给这个框架。Agent通过框架来调用这些接口而不是直接操作UI。这样既保证了安全性App可以控制暴露哪些能力又提高了稳定性接口比UI更稳定。当然这需要操作系统厂商、App开发者、Agent开发者三方达成共识短期内不太可能实现。但作为一个长期方向我认为这是解决根本问题的唯一路径。5. 开发者的现实选择在约束下做取舍5.1 场景选择优先做半自动而非全自动如果你现在要做一个Agent产品我的建议是不要追求全自动先做半自动。什么意思就是让Agent完成大部分工作但在关键节点让用户确认或补充信息。比如订机票的Agent可以自动查询航班、比价、推荐最优选项但最终的支付环节让用户手动完成。这样既降低了技术难度又规避了支付安全的风险。我做过一个对比测试全自动方案的成功率大概在60%左右而且失败后的恢复很麻烦半自动方案的成功率能到90%以上用户体验反而更好因为用户觉得自己在掌控局面。5.2 技术栈选择Rust与Python的取舍最近基于Rust语言的AI Agent是个热词我也尝试过用Rust写Agent的核心调度层。说说我的体会Rust的优势在于性能和资源占用。如果你要在手机上跑AgentRust编译出来的二进制文件比Python解释器小得多内存占用也低。而且Rust的并发模型更适合处理多个任务的并行调度。但Rust的生态在AI领域还不够成熟。大模型的SDK、数据处理库、快速原型工具Python都远远领先。所以我的做法是核心调度和性能敏感的部分用Rust模型调用和数据处理用Python两者通过进程间通信或FFI对接。对于大多数开发者来说如果只是做原型验证Python足够了。等到产品化阶段再考虑用Rust重写关键模块。5.3 大模型API的选择与成本控制Agent离不开大模型而大模型API的成本是绕不过去的问题。目前国内可用的选择不少DeepSeek、智谱、Kimi都有API服务价格差异也比较大。我的经验是不要所有任务都用最贵的模型。简单的意图识别、信息提取用便宜的小模型就够了只有复杂的规划和推理才需要调用大模型。通过合理的任务拆分成本可以降低一个数量级。另外一定要注意API的上下文长度限制。我之前遇到过一个报错maximum context length is 1048576 tokens原因是把整个页面的HTML都塞进了prompt里。后来改成只提取关键信息问题就解决了。6. 那些踩过的坑和总结出的经验6.1 风控对抗是一场没有终点的战争做GUI自动化的Agent风控是永恒的话题。我踩过的坑包括操作频率太快被限制、模拟点击的坐标偏移导致点错按钮、App更新后控件ID全变了导致脚本失效。应对策略无非是几条降低操作频率、增加随机性、做好版本适配、建立快速响应机制。但说实话这是一场消耗战你永远不知道对方什么时候会更新风控策略。所以如果要做产品一定要有备选方案不能把宝全押在GUI自动化上。6.2 不要低估最后一公里的复杂度很多Agent项目在Demo阶段看起来很美好但一到真实环境就各种问题。原因往往是低估了最后一公里的复杂度——网络不稳定、页面加载慢、弹窗干扰、权限不足、账号异常……我的建议是在项目规划阶段就把这些异常情况列出来逐一设计处理方案。不要等到上线后才发现问题那时候修复成本会高很多。6.3 合规是底线不是选项最后说一点可能不太中听但很重要的话做Agent一定要考虑合规问题。不要碰用户隐私数据不要绕过平台的安全机制不要做违反平台规则的事情。短期看可能觉得别人都在做但长期看合规才是可持续的。我见过太多项目因为合规问题被迫下架前期投入全部打水漂。与其事后补救不如一开始就把边界划清楚。7. 写在最后回到标题那句话人越方便AI越难。这不是一句悲观的话而是一个客观的现实。中国互联网的便利性是建立在高度封闭和定制化的基础上的这给Agent带来了巨大的挑战。但挑战也意味着机会——谁能在这个复杂的生态里找到突破口谁就能占据先机。我的判断是短期内GUI自动化仍将是主流方案但中长期看随着操作系统层面的开放和API经济的普及Agent的落地会越来越顺畅。作为开发者我们现在能做的就是在现有的约束下把产品打磨好把用户体验做好同时保持对新技术和新趋势的敏感。这个领域变化太快了今天的最佳实践可能明天就过时了。保持学习保持试错保持敬畏。 1. 一个反直觉的观察越顺手的入口越难被Agent接管过去两年我一直在做AI Agent相关的落地项目从最早的浏览器自动化脚本到后来的多步任务编排再到最近尝试把Agent接入到真实的用户日常场景里。踩过的坑不算少但有一个感受越来越强烈中国互联网过去十几年最引以为傲的便利性恰恰是AI Agent落地时最头疼的障碍。这话听起来有点绕我换个说法。你在手机上点外卖打开App、选餐、下单、支付整个过程行云流水三分钟搞定。但如果你想让一个AI Agent替你做这件事你会发现它几乎无从下手——没有统一的接口没有标准化的操作协议每一步都藏在某个App的私有逻辑里甚至同一个功能在不同版本、不同机型上的表现都不一样。这不是技术不够强的问题而是整个生态的设计哲学和Agent的工作方式之间存在根本性的错位。中国互联网的产品逻辑是把用户留在我的App里而Agent的逻辑是跨应用完成任务。一个要筑墙一个要拆墙天然对立。这篇文章我想把这个问题拆开讲清楚为什么中国互联网的便利性反而成了Agent的麻烦这个麻烦具体体现在哪些层面作为开发者或者产品从业者我们能做些什么以及从技术架构的角度有没有可能绕过这些障碍2. 便利性的代价超级App把一切收进了一个黑盒2.1 从网页互联到App孤岛的转变早期的互联网是网页的世界。每个网站有自己的URL浏览器可以自由跳转搜索引擎可以抓取内容用户从一个页面到另一个页面只需要点一个链接。那个时代如果你要做一个自动化工具本质上就是模拟HTTP请求、解析HTML、提取数据技术门槛不高通用性也强。但移动互联网时代彻底改变了这个格局。微信、支付宝、美团、抖音这些超级App把用户的时间和数据都收进了自己的围墙里。你想点外卖打开美团App。你想打车打开滴滴App。你想买东西打开淘宝App。每个App都是一个独立的王国有自己的账号体系、自己的支付通道、自己的交互逻辑。这种模式对用户来说确实方便——一个App解决一类需求界面统一体验流畅。但对Agent来说这意味着每一个App都是一座需要单独攻克的堡垒。没有通用的操作协议Agent只能通过模拟点击、模拟输入的方式来完成任务也就是所谓的GUI自动化。2.2 微信小程序便利的极致也是封闭的极致微信小程序是这个趋势的典型代表。它把大量轻量级服务收进了微信生态用户不用下载安装扫码即用用完即走。从用户体验角度看这是天才的设计。但从Agent的角度看小程序是一个完全封闭的沙箱环境——它运行在微信的运行时里有自己的API体系外部程序几乎无法直接调用。我去年尝试过一个项目想让Agent自动完成微信小程序里的某些操作。结果发现小程序的页面结构是动态渲染的传统的DOM解析根本拿不到有效信息。而且微信对自动化工具的风控非常严格稍微频繁一点的操作就会触发验证。最后这个项目只能放弃改用人工辅助的半自动方案。这里有一个关键认知小程序的便利是建立在封闭之上的。它之所以能做到即用即走是因为微信控制了整个运行环境。而Agent需要的是开放、标准化的接口这两者在底层逻辑上是矛盾的。2.3 操作系统层面的碎片化再往下一层看操作系统本身也是一个障碍。Android和iOS的权限模型不同不同厂商的定制系统又有各自的限制。一个Agent要在手机上完成任务需要处理的通知权限、悬浮窗权限、无障碍服务权限、后台运行权限……每一项都可能成为拦路虎。更麻烦的是国内Android生态的碎片化程度远超想象。同一个App在不同品牌手机上的表现可能完全不同有的能正常自动化有的会被系统拦截有的甚至根本装不上。我见过一个案例某个自动化脚本在小米手机上跑得好好的换到华为手机上直接闪退排查了半天发现是系统级的后台限制策略不同。这种碎片化意味着Agent的适配成本不是线性的而是指数级的。每增加一个App、一个平台、一个系统版本需要处理的情况就多一层。3. Agent需要什么标准化接口与可预测的环境3.1 Agent的工作范式感知、规划、执行要理解为什么中国互联网生态对Agent不友好先得搞清楚Agent是怎么工作的。一个典型的AI Agent包含三个核心环节感知获取当前环境的状态信息比如屏幕上有哪些元素、当前在哪个页面、有哪些可操作的按钮规划根据任务目标和当前状态决定下一步做什么执行通过某种方式操作环境比如点击按钮、输入文字、调用接口在理想情况下这三个环节都应该有标准化的接口。感知可以通过结构化的API获取数据规划可以由大模型完成执行可以通过标准化的操作指令实现。但在现实中尤其是在移动端这三个环节都充满了不确定性。3.2 API经济与Agent的天然契合为什么国外的Agent生态看起来更成熟一些一个重要原因是API经济的普及。Stripe做支付有APIShopify做电商有APISlack做通讯有API甚至连传统的银行和航空公司都在提供API。这意味着Agent可以通过调用API来完成任务而不需要模拟人类操作界面。API方式的好处是显而易见的稳定、高效、可预测。Agent不需要关心界面怎么变只需要按照API文档传参数就行。而且API通常有明确的错误码和限流策略Agent可以根据这些信息做出合理的决策。但在中国互联网生态里面向消费者的API非常稀缺。大多数App不提供公开API即使有也是面向企业客户的需要复杂的商务流程才能接入。这就逼着Agent只能走GUI自动化这条路而GUI自动化的稳定性和效率都远不如API。3.3 一个具体的对比订机票这件事举个例子说明差距。在美国如果你想做一个订机票的Agent你可以接入Amadeus或Sabre的API直接查询航班、比价、下单。整个过程是结构化的Agent只需要处理JSON数据。但在国内你要订机票要么接入携程的企业API门槛很高要么模拟操作携程App。后者意味着Agent需要打开App、处理开屏广告、定位到机票入口、输入出发地和目的地、选择日期、等待搜索结果、解析航班列表、选择航班、填写乘机人信息、选择支付方式、完成支付。每一步都可能出问题——广告弹窗遮挡了按钮、搜索结果加载慢、乘机人信息需要从通讯录读取、支付需要指纹或密码验证。这就是差距。不是Agent不够聪明而是环境太复杂、太不可预测。4. 破局思路在封闭生态里找缝隙4.1 无障碍服务目前最可行的GUI自动化方案如果你现在就要做一个能在国内App上完成任务的Agent无障碍服务Accessibility Service可能是最现实的选择。Android系统提供的这个功能原本是为了帮助残障人士使用手机但它恰好也提供了读取屏幕内容和模拟操作的能力。我实测下来无障碍服务的几个关键能力包括读取当前屏幕上的所有控件信息包括文本、位置、可点击状态模拟点击、滑动、输入文字等操作监听页面变化事件实时感知界面更新但无障碍服务也有明显的局限。首先它只能拿到系统渲染后的控件树如果App用的是自绘引擎比如Flutter或游戏引擎控件信息可能完全拿不到。其次很多App会检测无障碍服务是否开启一旦发现就限制功能或直接退出。第三不同厂商对无障碍服务的限制策略不同有的会定期杀掉后台的无障碍进程。实操建议如果你要走无障碍服务这条路一定要做好异常处理和重试机制。我通常会在关键步骤加上等待控件出现的逻辑超时后截图保存现场方便后续排查。另外尽量模拟人类的操作节奏不要连续快速点击否则很容易触发风控。4.2 微信生态的特殊处理从协议层入手微信是国内Agent最难啃的骨头但也不是完全没有办法。目前常见的几种思路第一种是Hook方案通过注入代码来拦截和修改微信的内部调用。这种方案技术门槛高稳定性差而且随着微信版本更新很容易失效。更重要的是这种方案存在合规风险不建议在产品中使用。第二种是UI自动化方案也就是前面说的无障碍服务。微信对无障碍服务的检测比较严格但通过一些技巧比如随机化操作间隔、模拟真实用户行为模式可以降低被检测的概率。第三种是借助微信开放能力比如公众号、小程序、企业微信等提供的官方接口。这些接口虽然不能覆盖微信的所有功能但在特定场景下是合规且稳定的选择。比如你要做一个自动回复的Agent用公众号的客服接口就比Hook方案靠谱得多。4.3 操作系统层面的机会AI OS的想象空间最近AI操作系统这个概念很热我觉得这个方向值得关注。如果操作系统本身能够提供Agent友好的接口很多问题就迎刃而解了。想象一下如果手机系统提供一个任务执行框架App可以选择性地暴露一些标准化的操作接口给这个框架。Agent通过框架来调用这些接口而不是直接操作UI。这样既保证了安全性App可以控制暴露哪些能力又提高了稳定性接口比UI更稳定。当然这需要操作系统厂商、App开发者、Agent开发者三方达成共识短期内不太可能实现。但作为一个长期方向我认为这是解决根本问题的唯一路径。5. 开发者的现实选择在约束下做取舍5.1 场景选择优先做半自动而非全自动如果你现在要做一个Agent产品我的建议是不要追求全自动先做半自动。什么意思就是让Agent完成大部分工作但在关键节点让用户确认或补充信息。比如订机票的Agent可以自动查询航班、比价、推荐最优选项但最终的支付环节让用户手动完成。这样既降低了技术难度又规避了支付安全的风险。我做过一个对比测试全自动方案的成功率大概在60%左右而且失败后的恢复很麻烦半自动方案的成功率能到90%以上用户体验反而更好因为用户觉得自己在掌控局面。5.2 技术栈选择Rust与Python的取舍最近基于Rust语言的AI Agent是个热词我也尝试过用Rust写Agent的核心调度层。说说我的体会Rust的优势在于性能和资源占用。如果你要在手机上跑AgentRust编译出来的二进制文件比Python解释器小得多内存占用也低。而且Rust的并发模型更适合处理多个任务的并行调度。但Rust的生态在AI领域还不够成熟。大模型的SDK、数据处理库、快速原型工具Python都远远领先。所以我的做法是核心调度和性能敏感的部分用Rust模型调用和数据处理用Python两者通过进程间通信或FFI对接。对于大多数开发者来说如果只是做原型验证Python足够了。等到产品化阶段再考虑用Rust重写关键模块。5.3 大模型API的选择与成本控制Agent离不开大模型而大模型API的成本是绕不过去的问题。目前国内可用的选择不少DeepSeek、智谱、Kimi都有API服务价格差异也比较大。我的经验是不要所有任务都用最贵的模型。简单的意图识别、信息提取用便宜的小模型就够了只有复杂的规划和推理才需要调用大模型。通过合理的任务拆分成本可以降低一个数量级。另外一定要注意API的上下文长度限制。我之前遇到过一个报错maximum context length is 1048576 tokens原因是把整个页面的HTML都塞进了prompt里。后来改成只提取关键信息问题就解决了。6. 那些踩过的坑和总结出的经验6.1 风控对抗是一场没有终点的战争做GUI自动化的Agent风控是永恒的话题。我踩过的坑包括操作频率太快被限制、模拟点击的坐标偏移导致点错按钮、App更新后控件ID全变了导致脚本失效。应对策略无非是几条降低操作频率、增加随机性、做好版本适配、建立快速响应机制。但说实话这是一场消耗战你永远不知道对方什么时候会更新风控策略。所以如果要做产品一定要有备选方案不能把宝全押在GUI自动化上。6.2 不要低估最后一公里的复杂度很多Agent项目在Demo阶段看起来很美好但一到真实环境就各种问题。原因往往是低估了最后一公里的复杂度——网络不稳定、页面加载慢、弹窗干扰、权限不足、账号异常……我的建议是在项目规划阶段就把这些异常情况列出来逐一设计处理方案。不要等到上线后才发现问题那时候修复成本会高很多。6.3 合规是底线不是选项最后说一点可能不太中听但很重要的话做Agent一定要考虑合规问题。不要碰用户隐私数据不要绕过平台的安全机制不要做违反平台规则的事情。短期看可能觉得别人都在做但长期看合规才是可持续的。我见过太多项目因为合规问题被迫下架前期投入全部打水漂。与其事后补救不如一开始就把边界划清楚。7. 写在最后回到标题那句话人越方便AI越难。这不是一句悲观的话而是一个客观的现实。中国互联网的便利性是建立在高度封闭和定制化的基础上的这给Agent带来了巨大的挑战。但挑战也意味着机会——谁能在这个复杂的生态里找到突破口谁就能占据先机。我的判断是短期内GUI自动化仍将是主流方案但中长期看随着操作系统层面的开放和API经济的普及Agent的落地会越来越顺畅。作为开发者我们现在能做的就是在现有的约束下把产品打磨好把用户体验做好同时保持对新技术和新趋势的敏感。这个领域变化太快了今天的最佳实践可能明天就过时了。保持学习保持试错保持敬畏。