浏览器自动化走过三代路线，每一代都解决了上一代的瓶颈，又把瓶颈推到新的地方。看清每代留下的问题，比记住工具名字更有用。
浏览器自动化做了二十多年，路线换过三代。有意思的地方在于，每一代解决的都不是同一类问题，解决完之后，瓶颈又被推到了新的地方。
第一代：在操作系统层面假装有人在动鼠标
最早的自动化根本不在浏览器里做，而是在操作系统上做。脚本移动鼠标、敲下按键，浏览器只是被动接收输入的那一方。
这么做的好处是通用：屏幕上的东西它都能碰到，网页、客户端、老式桌面软件都一样，也不需要浏览器开放任何接口。代价也很直接。脚本认的是屏幕坐标，分辨率一变、系统缩放调一次、窗口挪个位置，同一套动作就点偏了。它也不知道页面到底加载好没有，只能靠固定等待硬撑。更麻烦的是并行，一台机器只有一套鼠标键盘，十个环境就得十台机器。
这一代留下的问题，说白了就是看不见页面。
第二代：绕开屏幕，直接和浏览器对话
WebDriver 的出现把自动化从像素层面提到了元素层面：找的是页面里的某个元素，而不是屏幕上第 800 像素那个位置。同一套代码能驱动不同浏览器、用不同语言写，这也是它后来成为测试领域标准的原因。
再往后，基于浏览器调试协议的方案把这条路的细节做透了。Puppeteer、Playwright 这一系直接和内核通信，能拿到页面内部状态：自动等待元素就绪、拦截和改写请求、连接到一个已经开着的浏览器实例、无头运行、并行开多个上下文。现在大家习以为常的这些能力，基本都是在这个阶段补齐的。
它解决的是控制和稳定性，留下的是另外两个问题。一个是脚本仍然由人写死，页面结构一变、选择器一失效，就得回去改代码，维护成本随项目规模上涨。另一个更根本：它管的是怎么操作，不管看起来像谁。协议直连让控制更精确，但自动化留下的痕迹不会因为换了通信方式就消失。一个跑得再稳的脚本，在别人眼里依然可能是脚本。
第三代：步骤不用人写了，问题也换了地方
第三代的变化不在控制方式，而在决策方式。前两代都要人把每一步写清楚：点哪个按钮、填哪个字段、按什么顺序。到了模型驱动这一代，你给的是目标，路径由模型自己规划，页面改版了它还能重新找入口。
于是过去那些琐碎的麻烦，选择器怎么写、等待加多少，慢慢不那么要命了。但新的麻烦立刻冒出来。
关键在于，模型自己不访问网页。真正打开页面、加载资源、维持登录态的，还是浏览器。所以当任务开始跑不稳，原因往往不是模型想错了，而在它脚下的执行环境：多个任务共用一个浏览器，Cookie 和缓存互相污染；指纹特征高度雷同，在平台看来这些任务都来自同一台机器；账号在任务之间串用，一次异常牵连一片；环境要临时创建、用完回收，却没有统一的调度。模型解决了怎么做的问题，把在哪做变成了瓶颈。
架构上多出来的那一层
把三代摆在一起看，差别不是谁更先进，而是每一代都要接住上一代没接住的东西。前两代里环境之所以不是问题，是因为操作的就是自己机器上那个浏览器；到了 Agent 阶段，任务是批量、并发、无人值守的，环境就必须被显式管理起来：每个任务跑在独立的环境里，指纹与会话互不串用；登录状态跨任务保留，不用每次重登；IP、时区、语言成套匹配；环境像计算资源一样按需创建和回收。
PurpleMark 做的事就在这一层，把浏览器环境变成可以调度的资源，让 Agent 专注在任务逻辑上。
选择上也就好判断了。企业测试栈和已有的脚本资产，留在原来的路线就行；需要请求级控制的复杂 Web 应用，走协议驱动这一代；任务由模型规划、还要长期稳定跑的，前两代的技术照样能用，但环境这一层得单独解决。如果你的场景需要看起来像一个真实用户在操作，那就不是自动化框架自己能给的东西了，无论用哪一代。
技术路线之外还有一条边界：自动化操作要遵守目标平台的规则和当地法律，技术上跑得通，不等于业务上合适。
