browser-harness：让 LLM 自己补写浏览器操作助手的自愈式方案

它解决的不是自动化问题，而是工具补全问题

它解决的不是自动化问题，而是工具补全问题。浏览器自动化并不新鲜，Selenium 和 Playwright 已经存在多年。browser-harness 的切入点不同：它假设 LLM 代理在完成任务时，会遇到现有工具集之外的操作，比如上传文件、下载视频、处理弹窗。传统做法是开发者预先写全所有可能用到的辅助函数，但任务千变万化，预写总有遗漏。browser-harness 让代理在运行过程中自己发现缺失的 helper，然后当场写出来，存到工作区的 agent_helpers.py 里。下一次遇到同样的操作，它直接调用已有 helper，不再重新摸索。README 里的示意图很直白：代理想上传文件，发现 agent_helpers.py 里没有对应函数，于是自己写一个，文件上传成功，这个 helper 从此留在工作区。这个循环越用越顺，正是项目自称“self-healing”的含义。

CDP 单连接与代理工作区的分工

项目通过一个可编辑的 CDP WebSocket 把 LLM 接进真实浏览器。CDP，即 Chrome DevTools Protocol，是浏览器暴露调试接口的标准协议。browser-harness 只开一条连接，代理通过这条通道发送命令、接收页面状态。关键设计在于工作区结构：src/browser_harness/ 目录保持受保护，代理不能随意改动核心代码；而 agent_helpers.py 位于代理自己的工作区，代理有完全写入权限。这种隔离把“框架代码”和“代理生成的技能”分开，前者稳定，后者可以野蛮生长。README 提到 SKILL.md 教代理浏览器工作流，install.md 负责连接，mcp_server.py 则把这些 helper 暴露成 MCP 工具，通过 stdio 供 Claude Code、Devin、Cursor 等客户端调用。这意味着同一套 helper 既能被命令行代理直接用，也能被 MCP 生态里的其他工具复用。

安装与连接：一条提示词搞定

安装过程不依赖手工步骤，而是通过一段 setup prompt 交给编码代理执行。README 给出的提示词是：用 uv 和 Python 3.12 安装或升级 browser-harness 到最新稳定版，注册 browser-harness skill，然后连接到浏览器。代理会打开 chrome://inspect/#remote-debugging，首次设置时需要勾选一个复选框，允许远程调试连接。这段提示词还要求代理询问是否启用本地浏览器录制，默认不启用，升级时保留用户已有偏好。这套流程把安装变成代理的一次任务，而非用户逐条敲命令。对于不熟悉 uv 或不想手动配置 CDP 的开发者，这降低了门槛。但反过来，它要求你信任代理能正确处理安装失败，README 也提示，如果安装或连接失败，代理应参考 install.md 的指引。实际使用中，你至少需要确认 Chrome 以远程调试模式启动，否则 chrome://inspect 里看不到目标。

自愈机制的真实边界

自愈听起来美好，但它的能力受限于代理的上下文长度和任务复杂度。README 给出的示例任务是打开 X 个人资料、找到最新 20 条视频并下载。这类任务涉及多个步骤，代理可能需要多次尝试，每次失败后要分析页面结构，决定是写新 helper 还是调整现有逻辑。如果页面结构复杂或登录态失效，代理可能陷入反复试错。另一个隐患是 helper 的质量。代理写出的代码没有经过人工审查，如果它生成的选择器过于脆弱，比如依赖特定 class 名，页面改版后 helper 会静默失效。项目没有提供测试机制来验证 helper 的正确性，所谓“自愈”更多体现在生成新 helper 上，而非修复已有 helper。README 也没有说明代理如何处理页面变化导致的旧 helper 失效，这是一个真实的空白。

与 Browser Use Cloud 的关系：本地与并行的分界

README 明确区分了两种使用场景：本地浏览器用于登录态和个人工作，Browser Use Cloud 用于大规模并行。本地方案的优势是直接使用你的真实浏览器，Cookie 和会话都在，适合处理需要登录的私人任务。但本地浏览器的资源有限，开多个实例会拖慢机器。Browser Use Cloud 提供 live previews、代理、stealth 和 CAPTCHA 解决能力，这些是本地方案不具备的。项目把 Cloud 作为扩展选项，而不是替代品。对于需要同时跑几十个浏览器实例的团队，Cloud 是自然选择；对于个人开发者，本地模式足够。这个分界很实际，但也意味着如果你需要 Cloud 的功能，你得额外付费，并且要处理 API key 的配置，README 只给出了链接，没有具体步骤。

MCP 服务器：把 helper 变成通用工具

mcp_server.py 的存在让 browser-harness 不局限于单一代理。它通过 stdio 暴露 MCP 工具，任何支持 MCP 的客户端都能调用。这意味着 Claude Code、Devin、Cursor 等工具可以共享同一套浏览器控制逻辑，而不必各自实现 CDP 层。README 强调“without writing a second CDP layer”，这直击痛点：如果每个代理都要自己写 CDP 通信，重复劳动且容易出错。通过 MCP，browser-harness 把浏览器控制抽象成标准化的工具接口。但 MCP 的配置需要参考 docs/MCP.md，README 没有给出具体配置示例，实际接入时你可能需要阅读额外文档。另外，MCP 工具暴露的是 helper 函数，如果 helper 本身有副作用，比如点击按钮或提交表单，客户端调用时需要有权限控制，否则任何 MCP 客户端都能操作你的浏览器。README 没有提及认证或授权机制。

维护成本与许可：MIT 下的自由与责任

项目采用 MIT 许可，这意味着你可以自由修改、分发甚至商用，只需保留版权声明。维护成本主要来自代理生成的 helper。这些 helper 存放在你的工作区，随着时间推移会积累。如果代理升级，旧 helper 可能不兼容新版本的 browser-harness，但 README 没有说明版本升级时如何处理已有 helper。另外，项目依赖 uv 和 Python 3.12，这意味着你的环境需要匹配这些版本，升级 Python 或 uv 可能带来兼容问题。活跃的发布节奏（v0.1.8 到 v0.1.10 间隔一个月左右）表明项目在快速迭代，但这也意味着接口可能变动，你需要跟进更新。对于个人项目，维护成本可控；对于团队，你需要制定策略来管理 agent_helpers.py 的代码审查，否则代理生成的代码可能成为技术债。

替代方案：Playwright 与 MCP 生态的对比

最直接的替代是 Playwright。Playwright 提供完整的浏览器自动化 API，支持同步和异步，有丰富的选择器机制和等待策略。browser-harness 的差异在于它不要求开发者预先编写脚本，而是让 LLM 代理在运行时动态生成操作。Playwright 适合确定性的自动化任务，比如回归测试，它的代码是人工编写、可维护的。browser-harness 适合探索性任务，比如“下载我最近的视频”，这类任务无法预先写死逻辑。另一个替代是微软的 Playwright MCP，它把 Playwright 封装成 MCP 服务器，让 LLM 通过自然语言控制浏览器。这与 browser-harness 的 MCP 服务器类似，但 Playwright MCP 不强调 helper 的持久化，它更注重会话内的操作。browser-harness 的独特之处在于跨会话的 helper 积累，这是 Playwright MCP 没有的。如果你需要稳定的自动化，Playwright 更可靠；如果你需要代理自主探索并积累技能，browser-harness 的设计更贴合。

编辑结论

browser-harness 适合那些已经用 Claude Code 或 Codex 这类编码代理、且愿意让代理直接操作真实浏览器来完成个人事务的开发者。它不适合需要大规模并行浏览器、强隔离或生产级稳定性的场景，也不适合对代理写入本地代码持谨慎态度的团队。采用前应先在隔离的浏览器配置文件中验证代理是否能正确打开 chrome://inspect 并勾选远程调试选项，同时确认你接受代理在工作区中生成并修改 agent_helpers.py 文件的行为。若你的任务涉及敏感账号或支付，建议先阅读 SKILL.md 中的工作流定义，明确代理在遇到登录或验证码时的默认行为。最终判断：这个项目把“写工具”这件事从开发者手里交还给代理本身，如果你信任这个循环，它值得一试；如果你需要可预测的浏览器自动化，它可能不是你的工具。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes