核心定位
browser-harness 是一个高风险级浏览器自动化框架，核心价值在于打破传统 Playwright/Puppeteer 的隔离模式——它直接接管用户已登录、正在运行的真实 Chrome 实例，让 LLM Agent 能够操作用户的日常浏览器环境，包括已保存的登录态、Cookie 和 Session。
显著优点
1. 真实环境复用
不同于临时启动的无头浏览器，本 skill 通过 Chrome DevTools Protocol (CDP) WebSocket 连接用户现有 Chrome 进程。这意味着 Agent 可以自动继承用户的登录状态，无需重新认证即可操作 Gmail、Notion、企业内网等依赖会话的网站。
2. 双语言 Agent 协同
架构设计独特：Python 守护进程持有 CDP 长连接，通过 JSON-line IPC 暴露给多客户端。Python Agent 和 TypeScript Agent（通过 bhts CLI）可同时操作同一个标签页，实现跨语言工作流协同。
3. 多层安全防御体系
- 硬隔离模式 (
BH_PUBLIC_ONLY=1)：白名单机制，仅允许 GitHub、Wikipedia 等公开站点 - 敏感域默认拒绝：内置正则覆盖银行、支付、邮箱、内网、医疗系统等，写操作自动拦截
- 审计日志：仅记录 metadata（命令哈希、策略命中、退出码），绝不记录参数原文或响应内容
- 子进程隔离：
bhts始终作为独立子进程 spawn，避免第三方代码注入当前进程
4. 长期知识沉淀
通过 agent-workspace/domain-skills/<host>/*.md 机制，每个站点的稳定选择器、私有 API、框架特性可沉淀为可复用的"地图"而非一次性"日记"。上游已积累 76 个站点的 domain knowledge。
潜在缺点与局限性
1. 高门槛的配置依赖
用户必须手动：关闭 Chrome → 添加 --remote-debugging-port=9222 重启 → 在 chrome://inspect 中完成一次性握手。任何步骤失败都会导致"守护进程未运行"错误，对非技术用户友好度低。
2. 脆弱的状态管理
CDP 调用无自动重试机制。标签页关闭、页面刷新、Chrome 升级都会导致 sessionId 失效，需显式调用 bh.ensureRealTab() 重新附着。网络抖动直接抛错，Agent 需自行处理恢复逻辑。
3. 安全与便利的 tension
敏感操作需用户显式加 --i-understand-sensitive，Agent 被禁止自动添加此 flag。这在自动化场景（如定时任务）中形成阻断，本质上是把安全责任完全转移给终端用户。
4. 共享机器风险
CDP 端口默认监听 127.0.0.1，本机其他用户理论上可接管。虽然守护进程 socket 有 0600 权限，但 Chrome 层面的调试端口暴露无法完全规避。
5. JS 上下文隔离js / exec 命令序列化后在页面执行，无法闭包引用 Node 侧变量，传参需手动 JSON.stringify 拼接，复杂数据传递繁琐。
适合人群
- AI Agent 开发者：需要让 LLM 操作真实用户环境而非模拟环境的场景
- 自动化测试工程师：需复用已登录状态进行端到端测试
- 数据抓取从业者：针对需要登录态的站点进行合规、可控的信息提取
- 安全研究者：关注 browser automation 的 supply chain 安全与权限边界
常规风险
- 会话劫持风险：若 Agent 被 prompt 注入恶意指令，可能利用用户已登录状态执行非授权操作
- 数据泄露风险：
shot截图命令生成本地 PNG，若 Agent 后续将其上传至远程服务则形成泄露 - 供应链攻击：尽管版本被钉死且审计入口公开，但
browser-use/browser-harness上游的更新仍需人工 review - 策略绕过：用户可能为便利而设置
BH_ALLOW_SENSITIVE=1，导致银行/邮箱等敏感域完全暴露给 Agent - 审计盲区：metadata-only 日志虽保护隐私，但也导致事后追溯时无法还原具体操作内容