AI Agent 跑浏览器任务时，很多人会先优化提示词。
但在真实工程里，任务不稳定经常不是提示词问题，而是环境层问题。
如果 Profile、Session、Proxy 没有稳定绑定，Agent 每次看到的页面状态都可能不一样。
1. 环境层对象拆分
可以把浏览器自动化环境拆成四层：
Agent Task
-> Automation Interface
-> Profile Registry
-> Session Store
-> Proxy Policy
各层职责如下：
| 层级 | 作用 |
|---|---|
| Automation Interface | 承接 Playwright / CDP / Browser Use 调用 |
| Profile Registry | 管理 profile_id、owner、browser_version |
| Session Store | 管理 Cookie、LocalStorage、IndexedDB |
| Proxy Policy | 管理 proxy_id、region、timezone、language |
任务层不应该直接找浏览器实例，而应该先找受控的环境对象。
2. 为什么 Profile 是关键
Profile 不只是一个浏览器目录。
它承载了长期环境状态：
- 浏览器扩展配置
- Cookie 与缓存
- LocalStorage / IndexedDB
- 页面偏好设置
- 账号历史状态
- 自动化运行上下文
如果任务中途换了 Profile，就相当于换了现场。
脚本还能执行，不代表结果还能一致。
3. Session 与 Proxy 要一起看
很多登录态问题并不是单纯 Cookie 过期。
更常见的是 Session 和网络环境不一致：
| 问题现象 | 可能原因 |
|---|---|
| 反复要求重新登录 | Cookie 过期或 Profile 切换 |
| 页面设置恢复默认 | LocalStorage / IndexedDB 丢失 |
| 页面风控提示增加 | Proxy、时区、语言发生变化 |
| 同任务不同结果 | 环境对象没有稳定绑定 |
所以排查时不要只看 HTTP 或脚本日志，还要看环境快照。
4. 最小可观测字段
建议每次运行记录这些字段：
run_id: run-20260529-1400
job_id: job-daily-agent-browser
workspace_id: workspace-cn-01
profile_id: profile-cn-01
proxy_id: proxy-cn-stable
timezone: Asia/Shanghai
language: zh-CN
cookie_status: valid
local_storage_status: ready
indexeddb_status: ready
failure_type: null
review_required: false
有了这些字段，失败时才能回答：
- 跑的是哪个环境？
- 登录状态是否可用？
- 网络和浏览器信号是否一致？
- 是否需要人工复核？
5. 什么时候应该暂停
下面这些情况不建议自动继续：
| 场景 | 建议 |
|---|---|
| 出现安全验证 | 暂停任务，走官方验证入口 |
| Session 失效 | 检查 Cookie、LocalStorage、IndexedDB |
| 环境快照不一致 | 先查 Profile、Proxy 和变更记录 |
| Agent 判断不确定 | 保存截图和 reason，进入人工复核 |
| 页面结构变化 | 检查 DOM、选择器、页面版本 |
暂停不是降低自动化能力，而是保护任务结果。
6. 落地建议
一个更稳的运行流程可以是：
preflight check
-> resolve profile_id
-> validate session state
-> validate proxy policy
-> run browser task
-> save step evidence
-> classify failure
-> review if needed
如果团队需要把 Profile、代理和 Agent 任务放进统一工作台，可以参考 Agent-ready browser workspace 这种方向：环境对象先被管理，自动化任务再去消费它。
结论
AI Agent 浏览器自动化不是只靠模型推理。
工程稳定性来自可控环境：Profile 固定、Session 可用、Proxy 一致、任务入口可追溯。
环境层稳定之后，再谈提示词、选择器和任务编排，才更有意义。
