这是什么
Chrome MV3 扩展 + Node native messaging host + HTTP API（0.0.0.0:4821）。 扩展挂在用户日常 Chrome 上、host 跑在本机背景里、HTTP 接口给 code agent 用。 Hermes / Claude Code / Cursor 一发请求，扩展通过 Chrome Debugger Protocol 真去点页面、读 DOM、截图，再把结果回给 agent。 整条链路：agent → HTTP → native host (IPC) → 扩展 → 页面，没有 WebDriver、没有浏览器冷启、没有云端中转。
解决什么问题
code agent 会写代码会推理，但看不见用户的浏览器 —— 看不到按钮长啥样、点不了登录后才出现的菜单、验证不了视觉 bug。 传统方案有 3 类：① Puppeteer / Playwright 要单独管 cookie、过 CI 反爬、维护无头浏览器实例，每次冷启 1-3 秒； ② 云端 browser API（如 Browserbase）网络绕一圈贵又慢，还不能用真实账号； ③ 纯 vision SDK 没法 hook 真实 Chrome，看到的是别人的截图。 Browser Agent 直接挂在用户已经登录的 Chrome 上，自带 cookie / session / 公司内网访问，agent 一发 HTTP 就能驱动 —— 这是不可复制的护城河。
架构三层
用最少的中间层把 code agent 接到真实 Chrome —— 网络只走一次（localhost），其余全是 IPC 或 in-process。
Sidepanel + Service Worker
Sidepanel 负责 UI 和操作分发，Service Worker 跟 Native Host 用 Native Messaging 双向通信。通过 Chrome Debugger Protocol 直接驱动页面 —— 跟 Chrome DevTools 自己用的是同一套协议。多 sidepanel 并行路由，per-task API key 覆盖，多个 agent 同时调互不干扰。
HTTP 服务 + IPC 桥
背景跑的 Node 进程。一边监听 0.0.0.0:4821 接 code agent 的 HTTP 请求，另一边用 Chrome Native Messaging（stdin/stdout 二进制 IPC）跟扩展通信。绑 0.0.0.0 意味着 LAN 上的其他 agent 也能调（爸爸内网另一台机的 Hermes 可以用本机的扩展）。
视觉定位 + AI 操作
6-04 之前是自研 a11y tree + 自家 LLM loop，复杂 UI 定位飘。改用 Midscene 后：视觉模型直接看截图打坐标，canvas / 自绘 / 没 aria 的烂前端也能点。aiAct / aiQuery / aiAssert / aiTap 四个原子能力对应 4 个 HTTP 路由。Anthropic adapter 让它能走自家 proxy。
近期重要变化
从业务视角看：发生了什么、对调用方意味着什么。
引擎大换血 · 自研全扔，切 Midscene 1.8.9
自研 agent（自家 a11y tree 抽 ref ID + 自家 LLM loop）跑了 2 个月一直定位不准 —— canvas、shadow DOM、没 aria 的页面全抓瞎。6-04 整套扔掉，全换 Midscene 视觉定位。代码从 5100 → 1440 行（-72%），定位精度大幅提升，从此 Figma / 在线表格这种以前点不准的 UI 也能驱动。
API 收口 · 只剩 /v1（Midscene 接口）
过渡期 /v1（旧 agent）和 /v2（新 Midscene）并行了一周，6-04 把 v2 改名 v1、删掉旧 agent，API 收成一套。现在外部就 5 个端点：/v1/{action, query, assert, tap, screenshot}，每个对应 Midscene 一个原子能力，加 /sessions 和 /v1/health 做发现。
Anthropic adapter · 接自家 proxy
Midscene 原生只对接 OpenAI 协议。写了一个 chat.completions.create-shaped 适配层，把请求翻译成 Anthropic Messages API，能直连自家 api.eagle.openclaws.co.uk proxy。不用为这个工具单独买 OpenAI 账号，复用现有 Anthropic 通道。
多 sidepanel 并行调度
之前一台机器只能开一个 sidepanel，多 agent 同时调会 dogpile 到同一个窗口。改造后多 sidepanel 并行路由，scan 所有 Chrome profile 实例、per-task API key / model 覆盖、跨 window 自动选可用 sidepanel —— 多个 agent 同时跑也互不打架。RTT 平均改善 26.1%。
真实生产场景跑通 · PackHorizon E2E
PackHorizon report-v2 报告页的端到端浏览器测试用它跑（场景 ① ② + 4 类盲区扫描）。不是 demo 站，是公司业务页面，证明这套能扛真实复杂前端 + 登录态 + 跨页跳转，强调"不要再自己写 puppeteer/playwright"。
Windows 装机脚本
本来只能 mac 上手装，4-24 加了 Windows installer / uninstaller，三平台都能装（mac / linux / win）。Native Messaging 在 Windows 上需要写注册表，installer 把这步自动化。
沉淀的洞察
不是技术 tips，是踩了坑之后想法上的变化。
agent → HTTP → 云/本地 server → WebDriver → 浏览器进程 → 页面。Browser Agent：agent → HTTP → Native Host (IPC) → 扩展 → 页面。少一层网络 + 浏览器不冷启，截图响应 ~50ms vs 传统 1-3s。这个差异让 agent 一秒钟能跑十几次浏览器操作，从工具升级成 fluent interface。关键里程碑
7 个对项目走向有方向性影响的节点，跳过日常 commit。
pnpm build 绿 / /v2/health 200。代码 5100 → 1440 行（-72%）。入口与资产
源码 + 接口 + 文档。