browser-use/browser-harness 是一个面向 AI Agent 的浏览器控制工具。它的目标不是再做一层复杂的自动化框架，而是把大模型直接连到真实 Chrome，通过 CDP 完成浏览、点击、截图、下载、上传和表单操作。
项目 README 对自己的定位很明确：用一层很薄、可编辑的 CDP harness，让 LLM 直接连接真实浏览器；当任务中缺少 helper 时，Agent 可以在执行过程中补上代码，并把可复用经验沉淀成 domain skills。
这类工具值得关注，是因为浏览器仍然是很多真实工作的入口：后台系统、SaaS 面板、电商页面、招聘网站、CRM、报销系统、云控制台、文档平台，往往没有稳定 API，或者 API 权限比网页权限更难拿到。让 Agent 能可靠地操作浏览器，本质上是在补齐“最后一公里”的自动化能力。
browser-harness 是什么
从结构看，browser-harness 更像一个给 Agent 用的浏览器运行时，而不是普通用户手动点击的浏览器插件。
它的核心思路有几个：
- 直接连接 Chrome 或 Chromium 浏览器。
- 通过 CDP WebSocket 操作页面。
- 让 Agent 用截图、坐标点击、DOM、网络请求和原始 CDP 组合完成任务。
- 把任务相关 helper 放在
agent-workspace/agent_helpers.py。 - 把站点相关经验沉淀到
agent-workspace/domain-skills/。 - 保持核心很薄，避免做成庞大的自动化平台。
README 中提到，项目核心架构大约是 4 个核心文件、约 1000 行代码，主要包括 install.md、SKILL.md、src/browser_harness/、agent-workspace/agent_helpers.py 和 agent-workspace/domain-skills/。
这种设计的重点不是“内置所有网站能力”，而是给 Agent 一个足够贴近真实浏览器的操作层，让它在具体任务里补齐缺失能力。
它和传统浏览器自动化有什么不同
传统浏览器自动化通常围绕测试框架展开，例如 Playwright、Selenium 或 Puppeteer。它们适合写确定性的测试脚本：打开页面、定位元素、点击、断言结果。
browser-harness 面向的是另一类任务：用户说一句目标，Agent 自己探索页面、判断状态、处理弹窗、补 helper、复用站点经验。它强调的是交互过程中的适应性。
差异可以这样理解：
- Playwright 更适合人写脚本，Agent 执行脚本。
- browser-harness 更适合 Agent 边看页面边行动。
- 传统自动化偏固定流程。
- browser-harness 偏开放任务。
- 传统脚本常依赖选择器。
- browser-harness 鼓励先截图、再按可见界面行动，必要时再退回 DOM 或 CDP。
这并不意味着它要替代 Playwright。对稳定测试来说，Playwright 仍然更成熟。browser-harness 的价值在于把真实网页变成 Agent 可操作的环境，尤其适合那些页面结构复杂、步骤不固定、需要临场判断的任务。
为什么强调真实 Chrome
很多浏览器 Agent 工具会使用隔离的无头浏览器。这样部署简单，也适合批量任务，但它有一个现实问题：用户真实工作里的登录态、扩展、历史记录、书签和日常浏览器环境并不一定能直接复用。
browser-harness 支持连接本机 Chrome，也支持 Browser Use cloud browser。对本机浏览器，它提供两种方式：
- 通过
chrome://inspect/#remote-debugging允许当前 Chrome 实例被连接。 - 用
--remote-debugging-port=9222 --user-data-dir=...启动一个隔离 profile。
如果要让 Agent 帮你处理真实账号里的任务，项目文档更倾向于第一种方式，因为它能复用日常 Chrome 的登录态、扩展和书签。如果要做无人值守自动化，或者不希望被弹窗打断，则更适合使用隔离 profile 或云浏览器。
这里的取舍很清楚：真实浏览器更贴近用户工作流，但安全边界也更敏感；隔离浏览器更适合自动化，但需要重新处理登录和环境。
可编辑 helper 和 domain skills
browser-harness 最有意思的地方，是它把“Agent 会学到什么”设计进了项目结构。
agent-workspace/agent_helpers.py 用来放任务中临时补出来的 helper。比如 Agent 做文件上传时发现现有能力不够，可以补一个稳定的上传函数；下次再遇到类似页面，就不用从零开始。
agent-workspace/domain-skills/ 则用来放站点级经验。README 里举的方向包括 LinkedIn outreach、Amazon 下单、报销系统等。项目建议不要手写这些 skill，而是让 Agent 在真实任务中发现可复用流程后再生成，这样更贴近实际页面行为。
这个思路很适合浏览器自动化。因为网页自动化的难点往往不是“怎么点击按钮”，而是：
- 某个网站的登录后页面怎么跳转。
- 哪些弹窗会挡住主流程。
- 哪些 selector 稳定，哪些只是临时样式名。
- 上传、下载、iframe、shadow DOM、跨域组件怎么处理。
- 某个后台系统有哪些隐藏等待和异步状态。
这些知识如果只留在一次运行日志里，很快就会丢掉。把它们沉淀成 domain skills，才可能让 Agent 越用越顺。
适合哪些场景
browser-harness 更适合以下任务：
- 帮用户操作真实网页后台。
- 在没有 API 的系统里完成重复流程。
- 登录态依赖强的个人或企业网页任务。
- 需要截图判断页面状态的复杂交互。
- Agent 需要在执行中补工具、补站点经验。
- 多个子 Agent 各自使用独立浏览器执行任务。
- 研究浏览器 Agent 的运行时设计。
具体例子包括：整理网页表格、提交内部系统表单、下载账单、上传文件、处理报销流程、检查订单状态、在 SaaS 控制台里配置资源、从登录后的网页提取信息。
如果任务只是抓取静态网页，未必需要浏览器。项目自己的 SKILL.md 也提到，静态页面可以直接用 HTTP 批量获取；浏览器应该留给真正需要页面状态、登录态和交互的场景。
需要注意的风险
让 AI Agent 接管真实 Chrome，很强，也很危险。
第一，权限边界要清楚。真实 Chrome 里可能有邮箱、支付后台、云控制台、公司系统和个人账号。Agent 一旦能操作浏览器，就等于获得了这些网页权限的一部分。
第二，不要把凭据交给模型。遇到登录页、支付验证、二次确认等敏感步骤，应该让用户自己处理。Agent 可以等待登录完成，但不应该从截图里读取或输入密码、验证码、支付信息。
第三，自动化不等于可托管。很多网页任务看似简单，但中间可能出现风控、误点击、数据删除、批量提交、不可逆操作。适合先从只读、低风险、可回滚的流程开始。
第四，domain skills 需要避免泄露隐私。站点经验可以公开，但不要把账号、内部 URL、客户数据、坐标流水账或一次性任务细节写进去。
第五，真实浏览器连接方式要谨慎选择。如果要复用日常登录态，使用当前 Chrome 很方便；如果要跑长时间自动化，隔离 profile 或云浏览器更可控。
对 AI Agent 工具的意义
browser-harness 代表了一种很务实的 Agent 工具路线：少做平台，多给模型一个可以直接触达真实环境的接口。
过去很多 Agent 失败在两端。一端是模型会推理，但摸不到真实页面；另一端是自动化框架很强，但需要人先把流程写死。browser-harness 试图把这两端接起来：浏览器负责真实世界的状态，Agent 负责观察、判断和补工具。
这也是“自我改进 harness”的意义。它不是说 Agent 会神奇地变聪明，而是把可复用的操作经验放到项目结构里，让下一次任务少走弯路。
对开发者来说，browser-harness 的价值主要在三个层面：
- 作为个人 Agent 的浏览器控制层。
- 作为研究浏览器自动化和 Agent 工作流的样本。
- 作为把网页流程变成可复用技能的实验框架。
它不是所有浏览器自动化问题的答案，但它给出了一个清晰方向：当 Agent 真正要帮人做事时，工具层不只要能调用 API，也要能理解和操作人类每天使用的网页界面。
简单结论
browser-use/browser-harness 值得关注，不是因为它包装了多少高级功能，而是因为它把浏览器 Agent 的几个关键问题摆在了台面上：真实 Chrome、CDP、截图驱动、可编辑 helper、站点技能沉淀，以及用户权限边界。
如果你只是写稳定端到端测试，继续用 Playwright 或 Selenium 就很好。如果你想让 Codex、Claude Code 这类 Agent 直接帮你处理真实网页任务，browser-harness 提供了一个更贴近 Agent 工作方式的入口。
真正使用时，建议从低风险任务开始：先让它读页面、截图、提取信息，再逐步尝试点击和提交。等你确认它能稳定识别页面状态，再考虑让它接管更长的流程。
参考资料：