一個 Agent 一個視窗只適合示範。真正進入業務後，數十個任務同時執行時需要彼此獨立的環境，否則登入狀態會互相污染、分頁會爭搶控制權，失敗後也很難定位原因。
示範一個 AI Agent 能做什麼，一個瀏覽器視窗就夠了。真正放進業務裡，需求會立刻變成數十個視窗，而且必須互不干擾。原因不在 Agent 本身，而在它腳下的瀏覽器。
共用一個環境會出現哪些問題
最直觀的是 Cookie 和登入狀態互相污染。在同一套瀏覽器資料目錄裡，兩個任務輪流登入不同帳號，後一個會把前一個的工作階段覆蓋掉；一個任務清除快取，另一個任務的頁面狀態也可能跟著消失。
接著是資源爭搶。在一個瀏覽器執行個體裡，分頁、焦點、下載目錄、彈出視窗都是共用資源。兩個任務同時開啟新分頁時，誰在操作哪個頁面會變得不確定；一個任務跳出對話框，另一個任務的腳本就可能卡住。登入狀態衝突、資料覆蓋、操作互相干擾，這幾類問題幾乎都是並行執行的必然結果。
第三個問題出現在事後。任務失敗時，很難判斷是腳本邏輯錯了，還是環境在某一步被其他任務干擾。多個任務共用一個程序和一份日誌，失敗現象還可能不一致，排查成本會成倍增加。
還有一層不太直觀的風險：多個身分長期跑在同一套環境上，會留下可被關聯的線索。裝置參數、儲存狀態、網路出口都一樣，平台很容易把它們視為同一台裝置在批次操作。一個帳號被判定異常時，其他帳號也可能跟著受影響。
開多個視窗不等於隔離
很多人的第一反應是手動多開幾個視窗，看起來分開了，實際上這些視窗共用同一個瀏覽器設定檔：同一份 Cookie、同一份本機儲存空間、同一套裝置資訊。視窗之間能互相看到對方的登入狀態，一個視窗的操作也可能影響另一個。
真正的隔離要落到資料目錄和參數上。每個環境要有自己的儲存目錄、自己的裝置參數（解析度、語言、時區、字型、Canvas、WebGL 等），以及自己的網路出口。三者缺一，隔離都不完整；環境分開但共用同一個出口，關聯判定仍然可能生效。
隔離要付出的代價，以及能換回什麼
隔離不是免費的。每個環境背後都是一個獨立的瀏覽器程序和一份獨立的資料目錄。環境數量增加後，記憶體和 CPU 會最先感受到壓力。數十個環境放在同一台機器上，通常應該先算清楚單機還有多少餘裕，而不是等到當機後再補救。
可以權衡的地方有幾個：回收不常使用的環境，需要時再啟動；把任務依照輕重分散到幾台機器，而不是全部堆在同一台；替環境設定明確的生命週期，不要讓數百個環境一直掛著。任務本身的結構也有差別，同一個帳號下的序列任務沒有必要拆成多個環境，拆了只是浪費資源。
另一頭是收益。隔離做對之後，失敗現象會變得穩定：問題就是來自這個環境，而不是難以解釋的偶發狀況。規模化之後，這一點的價值遠比共用環境省下來的那點資源更大。
規模化之後需要落在環境層的三件事
第一件是批次排程。環境要能像運算資源一樣被申請和釋放，支援按需建立、批次啟動、並行控制、失敗重試、自動回收，而不是在腳本裡一個個建立、一個個收尾。
第二件是獨立出口。每個環境綁定自己的網路出口，而且出口地區要和環境的地理參數保持一致。這一項最容易被忽略，但它是整體隔離成立的前提。
第三件是狀態可查詢。隨時都能知道哪些環境正在執行、哪些閒置、哪些異常。Agent 是無人值守執行的，狀態查不到，出問題就只能靠猜。
這三件事放在腳本裡做都很彆扭，它們需要環境層級的儲存、設定和排程。有些多環境管理工具就落在這一層，PurpleMark 是其中之一，把瀏覽器環境做成可隔離、可批次排程、可透過介面呼叫的資源。
什麼時候不需要多環境
如果 Agent 只跑一個帳號、頻率很低，一般瀏覽器確實就夠用，額外隔離只是替自己增加維護負擔。但只要出現下面任一種情況，環境層就應該獨立出來：任務需要並行執行，需要以多個身分存取同一平台，需要長期維持登入狀態，或者並行規模還會持續上升。
這些情況的共同點都一樣：問題不在 Agent 夠不夠聰明，而在它腳下的環境夠不夠乾淨。
邊界
不論方案怎麼選，規則層面的邊界都沒有改變：遵守各平台服務條款與 robots 規則，不使用虛假身分資訊，不繞過技術保護措施，控制請求頻率，不影響對方服務的正常運作。
