一个 Agent 一个窗口只能用来演示。业务里几十个任务同时跑，共享同一套环境会互相污染登录态、抢占标签页，出了问题还很难定位。
演示一个 AI Agent 能干什么，一个浏览器窗口就够了。真正放进业务里，需求会立刻变成几十个窗口，而且必须互不干扰。原因不在 Agent 本身，在它脚下的浏览器。
共享一个环境会出哪些问题
最直观的是 Cookie 和登录态互相污染。同一套浏览器数据目录里，两个任务轮流登录不同账号，后一个会把前一个的会话覆盖掉；一个任务清了缓存，另一个任务的页面状态也跟着没了。
然后是抢占。一个浏览器实例里，标签页、焦点、下载目录、弹窗都是共享资源。两个任务同时点开新标签，谁在操作哪个页面就变得不确定；一个弹出对话框，另一个的脚本可能就卡在那里。登录状态冲突、数据覆盖、操作互相干扰，这几类问题几乎是并发的必然结果。
第三个问题出在事后。任务失败的时候，很难判断是脚本逻辑错了，还是环境在某一步被别的任务干扰了。多个任务共用一个进程和一份日志，失败现象还不一致，排查成本会成倍上去。
还有一层不太直观的风险：多个身份长期跑在同一套环境上，会留下关联线索。设备参数、存储状态、出口地址都一样，平台很容易把它们看成同一台设备在批量操作，一个账号被判定异常，其他账号也跟着受影响。
开多个窗口不等于隔离
很多人第一反应是手动多开几个窗口，看着是分开了，实际上这些窗口共享同一个浏览器配置：同一份 Cookie、同一份本地存储、同一套设备信息。窗口之间能互相看到对方的登录状态，一个窗口的操作也可能影响另一个。
真正的隔离要落到数据目录和参数上。每个环境要有自己的存储目录，自己的设备参数（分辨率、语言、时区、字体、Canvas、WebGL 这些），以及自己的网络出口。三者缺一个，隔离都不完整；环境分开了但共用一个出口，关联判定照样生效。
隔离要花的代价，和它能换回什么
隔离不是免费的。每个环境背后都是一个独立的浏览器进程和一份独立的数据目录，环境数上去，内存和 CPU 会先感觉到压力。几十个环境放在一台机器上，通常要提前算清楚单机还剩多少余量，而不是等崩溃了再补。
可以权衡的地方有几个：把不常出镜的环境回收掉，需要时再拉起；把任务按轻重分到几台机器上，而不是全堆在一台；给环境设定明确的生命周期，别让几百个环境一直挂着。任务量本身也有讲究，同一个账号下的串行任务没必要拆成多个环境，拆了只是浪费。
另一头是收益。隔离做对之后，失败现象会变得稳定：是这个环境的问题，不是玄学。规模化之后，这一点的价值比省下来的那点资源大得多。
规模化之后需要落在环境层的三件事
第一件是批量调度。环境要能像计算资源一样被申请和释放，支持按需创建、批量启动、并发控制、失败重试、自动回收，而不是在脚本里一个个创建、一个个收尾。
第二件是独立出口。每个环境绑定自己的出口，出口地区和环境的地理参数保持一致。这一项最容易被忽略，但它是整个隔离成立的前提。
第三件是状态可查询。随时能知道哪些环境在跑、哪些空闲、哪些异常。Agent 是无人值守运行的，状态查不到，出问题只能靠猜。
这三件事放在脚本里做都很别扭，它们需要环境级别的存储、配置和调度。做多环境管理的工具有些就落在这一层，PurpleMark 是其中之一，把浏览器环境做成可隔离、可批量调度、可通过接口调用的资源。
什么时候不需要多环境
如果 Agent 只跑一个账号、频次很低，一个普通浏览器确实够用，额外的隔离只是给自己加维护负担。但只要出现下面任一种情况，环境层就该独立出来：任务需要并行执行，需要以多个身份访问同一平台，需要长期维持登录状态，或者并发规模还会继续往上涨。
这些情况的共同点是一样的：问题不在 Agent 够不够聪明，而在它脚下的环境够不够干净。
边界
方案怎么选，规则层面的边界都没有变：遵守各平台服务条款与 robots 协议，不使用虚假身份信息，不绕过技术保护措施，控制请求频率，不影响对方服务的正常运行。
