关键词：CDP、BrowserContext、profile、动作网关
先把判断放前面：--remote-debugging-port 不是“方便调试的小开关”。在 Agent 场景里，它更像浏览器的远程驾驶舱。
本文涉及的本地验证来自专用 Windows 测试机 DESKTOP-HT6EO5E，系统为 Windows NT 10.0.19045.0 / build 19045。OpenClaw Node Sandbox 在这台机器上不可用，系统命令是 uncontained 执行；浏览器 profile/context 可以做隔离实验，但不要把这些命令结果理解为沙箱内执行结果。
从一个端口开始的权限扩大
Chrome DevTools Protocol 通过 WebSocket 暴露浏览器调试能力。调试器当然需要很强的权限：读 DOM、观察网络、执行 JavaScript、管理页面 target、截图、控制输入。问题是，Agent 也正是通过这些能力完成任务。
这就带来一个尴尬事实：自动化能力越完整，控制面越敏感。
Chrome 官方在 2025 年调整 remote debugging switches 的安全行为，背景之一就是远程调试端口被用于提取 Cookie。这个变化说明 CDP 风险已经不是“安全工程师想太多”，而是浏览器厂商正在处理的真实攻击面。
Profile 是资产，不是缓存目录
很多浏览器自动化事故不是 CDP 协议本身导致的，而是 profile 选错了。
用户主 profile 里通常有：
- Cookie 和登录态；
- LocalStorage / SessionStorage；
- 浏览历史和自动填充痕迹；
- 扩展状态；
- 下载目录偏好；
- 已授权的网站权限。
如果 Agent 继承这个 profile，它拿到的不是“一个浏览器窗口”，而是人的在线身份。网页内容再进入模型上下文，风险链路就连起来了：不可信页面影响模型，模型驱动 CDP，CDP 操作带登录态的浏览器。
BrowserContext 的价值：便宜的隔离
Playwright 文档把 BrowserContext 描述为隔离的 clean-slate environment，每个 context 有自己的 cookies、localStorage、sessionStorage，类似 incognito profile。对测试来说，这是可复现性；对 Agent 来说，这是 blast radius 控制。
推荐默认值很简单：临时 context 优先，持久 profile 例外。
// 默认：任务级临时 context，结束即销毁状态
const browser = await chromium.launch();
const context = await browser.newContext({
storageState: undefined,
permissions: [],
});
const page = await context.newPage();
// 例外：专用代理账号，专用持久 profile
const context = await chromium.launchPersistentContext('profiles/agent-docs-reader', {
headless: false,
});不要用用户日常 profile 做“省登录”的捷径。那是在拿安全边界换便利。
CDP 前面应该有动作网关
CDP 本身只回答“能不能执行这个浏览器动作”，不回答“这个动作是否被授权”。所以浏览器 Agent 需要动作网关。
browser_control_plane:
cdp_endpoint:
bind: 127.0.0.1
expose_to_network: false
profile:
default: ephemeral_context
persistent_profile: agent_account_only
inherit_user_profile: false
actions:
read_dom: allow_and_log
screenshot: allow_and_log
form_fill: require_diff_preview
submit_or_delete: require_human_approval
external_upload: deny_by_default
evidence:
capture_url_and_title: true
capture_screenshot_on_write: true
keep_action_trace: true这里的关键不是 YAML，而是授权模型：读页面、填表、提交、下载、外发数据不能放在同一个权限桶里。
在 Windows 测试机上能验证什么
当前 DESKTOP-HT6EO5E 已恢复 OpenClaw 全能力 Node。它是一台专用 Windows 测试机，系统为 Windows NT 10.0.19045.0 / build 19045；OpenClaw Node Sandbox unavailable，commands run uncontained。这个边界要先写清楚：浏览器 profile 可以做隔离实验，但系统命令仍是在宿主机上下文执行。
这台机器适合做三类验证：
- 浏览器自动化能否使用独立 profile；
- 高风险动作前能否产出截图和 URL/title 证据；
- CDP 控制面是否只在预期路由内可达。
边界再重复一次：浏览器自动化证据来自专用测试机，不代表沙箱隔离后的系统命令执行结果。
审计时我会追问这些问题
- CDP endpoint 绑定在哪里？是否可能被局域网或代理路径访问？
- Agent 用的是临时 context、专用 profile，还是用户主 profile？
- 页面读取与提交动作有没有分级？
- 关键动作有没有截图、URL、title、参数和结果？
- 下载文件写到了哪里？有没有扫描与清理？
如果这五个问题答不上来，浏览器 Agent 的“自动化成功”不值得庆祝。它只是把未定义权限跑通了。
留给实现者的一句话
CDP 是控制面，BrowserContext 是隔离单元，动作网关是授权边界。别把三者混成“启动一个浏览器”。
