瀏覽器自動化走過三代路線，每一代都解決了上一代的瓶頸，也把新的瓶頸推到別的地方。與其記住工具名稱，更重要的是看清每一代仍未解決的問題。
瀏覽器自動化已經發展了二十多年，路線也換過三代。有意思的是，每一代解決的都不是同一類問題，而問題解決之後，瓶頸又會被推到新的地方。
第一代：在作業系統層面假裝有人在移動滑鼠
最早的自動化根本不是在瀏覽器裡完成，而是在作業系統層面進行。腳本移動滑鼠、敲下按鍵，瀏覽器只是被動接收輸入的一方。
這種方式的好處是通用：螢幕上的東西都能操作，網頁、用戶端程式、老式桌面軟體都一樣，也不需要瀏覽器開放任何介面。代價也很直接。腳本認的是螢幕座標，只要解析度改變、系統縮放調整一次，或視窗移動位置，同一套動作就可能點偏。它也不知道頁面是否真的載入完成，只能依賴固定等待。更麻煩的是平行執行，一台機器只有一套滑鼠鍵盤，十個環境就得準備十台機器。
這一代留下的問題，說到底就是看不見頁面。
第二代：繞過螢幕，直接和瀏覽器對話
WebDriver 的出現，把自動化從像素層級提升到元素層級：找的是頁面裡的某個元素，而不是螢幕上第 800 像素的位置。同一套程式碼可以驅動不同瀏覽器，也能用不同語言撰寫，這也是它後來成為測試領域標準的原因。
再往後，基於瀏覽器除錯協定的方案把這條路做得更完整。Puppeteer、Playwright 這一系直接和核心通訊，可以取得頁面內部狀態：自動等待元素就緒、攔截與改寫請求、連線到一個已經開啟的瀏覽器實例、無頭執行，以及平行開啟多個 context。現在大家習以為常的許多能力，基本都是在這個階段補齊的。
它解決的是控制與穩定性，但留下另外兩個問題。第一，腳本仍然由人寫死，頁面結構一變、selector 一失效，就得回去修改程式碼，維護成本會隨著專案規模上升。第二個問題更根本：它管的是怎麼操作，不管看起來像誰。協定直連讓控制更精準，但自動化留下的痕跡不會因為換了通訊方式就消失。就算腳本跑得再穩，在別人眼裡仍可能像是腳本。
第三代：步驟不用人寫了，問題也換了地方
第三代的變化不在控制方式，而在決策方式。前兩代都需要人把每一步寫清楚：點哪個按鈕、填哪個欄位、按照什麼順序。到了模型驅動這一代，你給的是目標，路徑由模型自行規劃，頁面改版之後它還能重新找到入口。
於是過去那些瑣碎的麻煩，例如 selector 怎麼寫、等待多久，慢慢變得沒那麼致命。但新的麻煩立刻出現。
關鍵在於，模型自己不存取網頁。真正開啟頁面、載入資源、維持登入狀態的，仍然是瀏覽器。所以當任務開始跑得不穩，原因往往不是模型想錯了，而是它底下的執行環境：多個任務共用同一個瀏覽器，Cookie 和快取互相污染；fingerprint 特徵高度相似，在平台看來這些任務都來自同一台機器；帳號在任務之間交叉使用，一次異常就可能牽連一大片；環境需要臨時建立、用完回收，卻沒有統一的調度。模型解決了怎麼做的問題，卻把在哪裡做變成新的瓶頸。
架構上多出來的那一層
把三代放在一起看，差別不是誰比較先進，而是每一代都必須接住上一代沒有處理好的東西。前兩代裡，環境之所以不是問題，是因為操作的就是自己機器上的那個瀏覽器；到了 Agent 階段，任務是大量、並行、無人值守的，環境就必須被明確管理：每個任務跑在獨立環境裡，fingerprint 與 session 不互相混用；登入狀態跨任務保留，不必每次重新登入；IP、時區、語言成套匹配；環境像運算資源一樣按需建立和回收。
PurpleMark 做的事情就在這一層，把瀏覽器環境變成可以調度的資源，讓 Agent 專注在任務邏輯上。
選擇上也就更容易判斷。企業測試堆疊和既有的腳本資產，可以留在原本的路線；需要 request 層級控制的複雜 Web 應用，適合協定驅動這一代；任務由模型規劃、又要長期穩定執行時，前兩代的技術照樣能用，但環境這一層必須另外解決。如果你的情境需要看起來像是真實使用者在操作，那就不是自動化 framework 本身能單獨提供的能力，無論使用哪一代都是如此。
技術路線之外還有一條邊界：自動化操作必須遵守目標平台的規則與當地法律。技術上跑得通，不代表在業務上就一定合適。
