人工智能AI Agent多智能体MCP 服务工具调用浏览器控制【免费下载链接】hiveMulti-Agent Harness for Production AI项目地址https://gitcode.com/gh_mirrors/hive48/hive点击查看免费下载导读本文基于 Hive 仓库内部的架构设计文档 browser-architecture-design.md 展开深入剖析 Multi-Agent Harness for Production AI 项目如何驱动浏览器完成自动化任务既支持通过 MV3 扩展在用户本机 Chrome中以chrome.debuggerCDP 驱动浏览也支持在 Firecracker 沙箱 VM 中通过 noVNC 流式呈现远程桌面。文章将带你理解本地/云端统一体验这一目标如何被拆解为 UX 需求、技术需求与工程取舍以及浏览器 profile 版本锁定R6为何成为约束整份设计的关键事实。读完你将掌握 Hive 浏览器自动化的完整传输链路、二进制构建策略的阶梯式取舍A0/A/B/C、CDP 与 CLI 控制面的实测成本对比以及当前仍待决策的开放问题。说明本文涉及的hive-desktop-runtime、hive-desktopElectron 应用、hive-backendVM 编排与infra/sandbox-images/hive-novncVM 模板四个仓库中当前镜像仓库可核实的是浏览器扩展源码tools/browser-extension、Python 自动化层tools/src/gcu/browser及终端命令防护tools/src/terminal_tools/common/command_guard.py文中对桌面壳与 infra 的引用均以原设计文档为准并标注了可验证范围。1. 背景Hive 今天如何驱动浏览器Hive 目前通过两条完全不同的路径驱动浏览器二者架构不同、故障模式不同、用户体验也不统一本地路径Local一个 MV3 扩展通过chrome.debugger走 CDP运行在用户自己的Chrome/Brave/Edge 里使用用户的真实 profile 与已登录会话。VM 路径同一个扩展通过托管策略强制安装进 Firecracker 沙箱内的google-chrome-stable以 noVNC 桌面形式在独立 Electron 窗口中流式呈现给用户。设计目标是单一体验用户在 Hive 窗口内观看 Agent 浏览并可随时接管一次登录、处处保持用户看到的正是 Agent 能触达的范围用户不需要、也不关心工作发生在自己机器上还是云端 VM 里。由此推导出的核心结论需要一个由项目自带并纳入版本控制的浏览器二进制内嵌在应用中配有一个隔离的持久化 profile且该 profile 格式在本地与 VM 两种部署间兼容——因为profile 兼容性被版本锁定这一事实反过来约束了浏览器二进制、外层 shell 与迁移路径见第 4 节。本设计文档的定位是记录每个决策轴上的权衡、代码已验证与纯研究/假设之间的边界、以及过程中发现的两个线上缺陷它不锁定任何最终决策。2. 需求体系从用户体验倒推技术需求设计的组织原则是技术需求由用户体验需求派生而不是并列陈述——这样任何方案都可以被评判为它损害了哪个用户目标也让没有对应用户体验收益的技术需求暴露为一种选择而非约束。2.1 用户体验需求按优先级排序#用户应当能够说…备注UX1Agent 跑在我机器上还是云端对我来说都一样。原始目标——拉平体验。同样的界面、同样的控制用户无需知道运行位置UX2我能看着 Agent 干活并且随时接管。在 Hive 窗口内完成——不是独立应用也不是看起来像远程桌面的东西。点进去、介入、交还控制UX3我登录一次之后一直保持登录。跨重启并且跨本地↔云端。会话连续性才让 UX1 从表面文章变成真实体验UX4Agent 只能触达我给它的范围。不坐在用户的个人浏览器里那里有银行、健康和个人邮件。可见的范围、可撤销的授权UX5它不会拖垮我的机器也不和我的正常浏览打架。不耗尽内存、不碰用户的标签页、不与用户浏览器争抢资源UX6它响应迅速用起来像真正的应用。原生窗口操作即时生效用户自己的操作没有远程桌面延迟非目标通用消费级浏览器、日常主力浏览器、成为用户默认浏览器。2.2 派生技术需求#需求服务目标强制还是可选R1一个随应用打包并版本控制的浏览器二进制UX1, UX3, UX5强制—— profile 兼容性被版本锁定第 4 节R2运行时内存控制UX5VM 内强制2 GiB cgroup本地明显更弱第 5.4 节R3无调试器面板低开销自动化UX2, UX6分裂。无面板是强制的但一旦 R1 成立就免费获得原生 API 是选择而非强制——CDP 加 preload 批处理同样满足 UX6第 5.3 节R4应用内嵌渲染UX2, UX6强制R5隔离的持久化 profileUX3, UX4强制R6Profile 数据在本地与 VM 间兼容UX1, UX3强制—— 并且是驱动本设计文档大部分内容的约束第 4 节2.3 没有直接用户体验收益的工程选择这些是真实存在的决策但应当以成本、风险与可维护性来论证——而不是以用户价值且不得允许它们覆盖第 2.1 节的需求CLI 控制面而非 MCPAgent 侧易用性与上下文成本第 5.3 节。对用户不可见。浏览器阶梯的哪一级A0 flags / A 自建构建 / B patchset成本与风险第 5.1 节。R1 强制某个受控二进制但不规定它被定制到何种程度。Shape A vs Shape BElectron 外壳 vs Chromium 即外壳成本与重写暴露面第 5.2 节。两者都能满足 UX1-UX6差别在代价。一个被误当成用户需求的技术需求原生 API 替代 CDP最初被写成硬性需求。拆解后它的两个动机是可见的调试器面板UX2与往返开销UX6——而这两者在不放弃 CDP 的前提下都能被满足。若把它当作强制项将付出放弃 13,562 行自动化层的代价却得不到任何用户可见收益。3. 当前状态代码已验证3.1 本地路径方面细节传输链路gcu MCP → JSON-RPC/WS14831→bridge_host→ WS relay14829遗留 9229→ MV3 扩展 →chrome.debuggerCDP浏览器用户自己安装的Chrome/Brave/Edge使用真实 profile扩展分发Chrome Web Storeidjkpcegnbfimimjodblcemoheedidnppmv1.7.4。桌面应用从不自行安装——只深度链接到商店打包副本hive-desktop/vendor/hive/tools/browser-extension中的副本已过时v1.2.3351 行无 reaper自动化代码tools/src/gcu/browser/13,562 行其中bridge.py单文件 6,375 行、bridge_host.py483 行在当前镜像仓库中可以交叉验证的部分tools/src/gcu/browser目录下实测bridge.py为 6,442 行整个目录约 14,581 行 Python与文档记录的 13,562 行数量级一致文档行数口径为设计当日快照扩展manifest.json确认为1.7.4版本manifest.json声明的权限正是debugger、tabs、tabGroups、scripting、offscreen、storage、alarms、sidePanel主机权限覆盖127.0.0.1:14830、localhost:14830及遗留的9230端口与文档所述传输链路吻合。3.2 VM 路径方面细节模板infra/sandbox-images/hive-novnc/—— Debian bookworm2 vCPU / 4096 MB 内存 / 6144 MB 磁盘浏览器apt 安装的google-chrome-stable同一扩展经托管策略强制安装显示栈Xvfb1280x800x24无-randr→ x11vnc → websockify → noVNC且xfwm4 xfce4-panel xfdesktop 全部运行Chrome 窗口--window-size1100,720 --window-position80,40—— 即桌面上一个带 WM 装饰的窗口呈现方式noVNC 页面放在独立的 ElectronBrowserWindow1280×860中resizescale客户端缩放任何地方都没有 fps 调优内存围栏cgroup v2memory.max2 GiBmemory.high1.5 GiBVM 空转约 2.7 GiB / 4 GB已开放的端口--remote-debugging-port9222仅绑定 loopback当前未使用—— 原始 CDP 路径今天已存在显著 flags--password-storebasic、--js-flags--max-old-space-size384、--renderer-process-limit8、--disable-dev-shm-usageVM 中 reaper 的内存压力背景可以直接在扩展源码中读到background.js 的注释说明 Chrome 运行在 cgroup v2 切片chrome.slicememory.max2 GiB内超出上限时内核会在切片内挑选一个 renderer 执行 SIGKILL标签页显示 Aw, Snap! 闪屏——那是安全网而非目标目标是用chrome.tabs.discard()在触顶之前释放空闲标签页的 renderer。3.3 桌面外壳Electron33.4.11Chromium 130已 EOL。electron-builder → dmgmac arm64/ NSIS perMachinewin/ AppImagelinux。hardenedRuntime: true配置了公证teamN897NVV9VCWindows 接入 Azure Trusted Signing。没有自动更新器——手动向open-hive.com/api/version轮询版本并重新下载完整安装包。src/main10,593 行cloud.ts 3,622 · ipc.ts 1,420 · remote-runtime.ts 1,406 · runtime.ts 1,294 · vm-sync 575 · main 485 · sse 335 · translocation 268 · 其他。4. 驱动一切的约束R6Chrome 的 profile 格式与版本耦合且不支持降级——Chrome 会在 profile 中记录上次使用的版本遇到更老的构建会拒绝或重置。因此本地与 VM 之间 user data 兼容不是同步问题而是版本锁定问题它迫使两侧使用同一个二进制或严格锁定版本的二进制。两个直接后果(a) Electron 的WebContentsView被淘汰。Electron 33 是 Chromium 130而 VM 跑的是 ~151即便 Electron 43约 Chromium 150相对 VM stable 仍是降级。一个版本不受你控制的浏览器无法满足 R6。这否决了此前分析中推荐的内嵌 WebContentsView方案。(b) Cookie 加密后端必须一致。VM 已运行--password-storebasic硬编码密钥 → 可移植的 cookie 数据库。macOS 绑定 Keychain、Windows 绑定 DPAPI App-Bound Encryption——两者都机器绑定。本地改用basic使 profile 可移植代价是用户磁盘上 cookie 静态加密减弱。这是一个刻意的安全决策而非细节。尚不存在的先决条件VM 的 Chrome profile 完全不持久化。hive-userdata-snapshot.sh:15明确排除了/data/chrome——后续 RC 会为 chrome 状态增加第二个 tarball。持久化 NFS 挂载覆盖的是/root/.hive不包括浏览器 profile。5. 决策轴5.1 浏览器二进制 —— 阶梯级内容收益代价结论A0原版 Chrome 运行时 flags关闭站点隔离省 ~10-13% 内存、V8 上限、--in-process-gpu实测 −38 MiB、进程数限制。实测总计−7.6%PSS加--jitless达 −12.4%但 Speedometer 掉约 40%关闭站点隔离意味着被攻破的 renderer 能在浏览器内部读到其他站点的数据——仅对短期、按任务创建的 profile 可接受先做。免费、可回退A自建 gn-args 构建ungoogled 风格safe_browsing_mode0、enable_reportingfalse、无 API keys、server trims、is_official_build可复现的自研二进制、无电话回家服务、RSS 少几十 MB、是 B 级的基础、也是版本可控的二进制R1、R6约 50 CPU 小时/次干净构建个位数美元需要 CI 流水线必须跟进安全版本R1/R6 所需B薄补丁集30 个文件唯一能触达其他方式够不到的控制杆PSI/cgroup 压力接线Linux Chrome 不内置 MemoryPressureMonitor因此从不在 cgroup 压力下自我清理、CDP 标签页丢弃命令chrome.tabs.discard仅扩展可用、per-renderer 硬预算、平铺截图捕获Rebase 负担。跟踪 8 周周期的extended-stable通道每年约 6.5 个版本而非stable——后者在 2026-09-08 起于 Chrome 153 切换为两周一个里程碑仅在实测需要时Ccontent_shell / CEF / headless shell占用约减半Google禁止从内嵌框架登录CEF 类——对 R5/R6 致命无扩展运行时无有头 UI否决市场普查Browserbase 和 Anchor 补丁 ChromiumSteel、Kernel、browserless 用原版。BrowserOS 是 4 人 AI 工具在维护一个 366 文件的 fork但落后 stable 12 周。目前没有公开的量化证据证明 AI 能压缩 Chromium rebase 的工作量——应视为可能成立但未证实。5.2 内嵌方式 —— Shape A vs Shape B这是开放中的决策。Shape A—— Electron 外壳 捆绑的 Chromium 子进程Shape B—— Chromium 本身就是外壳内嵌难。没有廉价路径不是问题—— 单一进程树UI 是 WebUI 页面浏览是视图保留全部 10,593 行src/main、electron-builder、现有 UIUI 以 WebUI 存活主进程逻辑不保留内存本地两棵 Chromium 树Electron 外壳实测约 303 MiB PSS与 Chrome 自身固定成本相差 1.3% 以内→约 300 MiB删除重复的树打包保留 electron-builder仍需在afterPack手动签署嵌套的 Chromium helpers放弃 electron-builder改用 Chromium 自己的安装器流水线mini_installer、mac 打包——Brave 的模式原生感不变不变—— Electron 本来就是原生窗口里的 ChromiumChrome/Brave/Arc/Vivaldi/BrowserOS 看起来都像应用记录在案的修正Electron 33.4.11确实暴露webPreferences.offscreen.useSharedTexture但它只允许 Electron 从自己的webContents产出帧——没有任何 API 能导入外部进程的 IOSurface/D3D11 纹理。因此 Shape A 内嵌退化为通过 IPC 泵像素1280×800×30fps 下约 110 MB/s RGBA、原生窗口 reparenting脆弱、对 Wayland 不友好、或按平台写原生合成 addon6-12 工程师月级别Atlas 之所以能用私有 macOS API是因为 OpenAI 同时编译了两侧。R1 R4 在 Shape A 中直接冲突。正是这个冲突让每一个浏览器形态的产品——Arc、Brave、BrowserOS、Comet、Atlas——都选择了让浏览器成为应用。对 Shape B 成本的缓解src/main的很大一部分并不依赖 Electron。cloud.ts、remote-runtime.ts、sse.ts、vm-sync.ts 是 HTTP/API 编排它们待在那里只是因为那是 Node 所在之处它们可以迁入 Python runtime——后者本来就在每台安装的机器上本地运行。真正原生的表面窗口/生命周期、IPC 桥、协议处理器、translocation接近约 2k 行。这个抽取在每一条分支上都值得做且可回退——它把重写 10.6k 行变成写一个 2k 行的外壳。5.3 控制面 —— CLI vs MCPCDP vs 原生 API团队已决定CLI而非 MCP。证据支持这一选择——Vercel 的agent-browserRust CLI → Unix-socket daemon → 原始 CDPeN引用、环境变量会话和微软的playwright-cli独立收敛到同一形态实测相比 MCP 节省约 90% 上下文Playwright MCP 启动时约 13.7k tokens 的定义一个 10 步流程 CLI 约 7k tokens vs MCP 约 114kAnthropic 自己的用 MCP 做代码执行结果150k → 2k tokens也印证了这一点。关于用原生 API 替代 CDP面板是扩展产物不是 CDP 产物。它来自chrome.debugger.attach今天之所以显示是因为配置里任何地方都没有--silent-debugger-extension-api。走--remote-debugging-port的原始 CDP 不显示任何东西——VM 里同样没有--enable-automation因此完全没有自动化 infobar。自持二进制后无需更换协议就能移除面板。如果动机是往返成本今天一个 selector 点击要 8-12 次串行 CDP 往返修法是preload/注入式批处理层——一次调用完成整套 selector 流程——它依然跑在 CDP 之上。真正的原生 APICEFCefBrowserHost是合法选择但代价是丢掉全部以 CDP 动词表达的 13,562 行 Python 自动化层。CEF 还带着 Google 的内嵌框架登录封锁与 R5/R6 冲突。该轴上的建议自持二进制、保留 CDP 作为线上格式、用 preload 批处理。R3 的真实目标无需丢弃大脑即可达成。CDP 可移植性的现状AX 快照引擎、穿透 shadow DOM 的选择器、全部输入路径、evaluate、截图、等待与Page.handleJavaScriptDialog都是纯 CDP可原样迁移。与扩展耦合、需要重实现的部分标签页分组chrome.tabGroups专属概念、chrome.debuggerattach 记账、对话框事件 fan-in 中继、LRU reaper、以及喂给health.py的tab.audit健康探针。上述纯 CDP 能力可在当前仓库中直接印证bridge.py 中实现了Page.handleJavaScriptDialog约 3809-3836 行、Accessibility.getFullAXTree快照约 5422-5442 行、以及用分隔符穿透 shadow root 的_shadowQuery工具函数约 4641-4658 行示例#interop-outlet #ember37 phealth.py 是纯规则式的标签页健康分类器输入正是扩展的tab.audit快照。5.4 内存控制杆 —— 哪些需要自定义构建哪些不需要控制杆无自定义构建备注进程数 / 站点隔离✅ flags最大的单一控制杆约 10-13%有安全权衡V8 堆上限✅--js-flags按 renderer 生效把泄漏变成一个死掉的标签页消除 GPU 进程✅--in-process-gpu实测 −38 MiBXvfb 下反正也是 SwiftShadercgroup 硬上限 renderer 优先 OOM✅memory.maxoom_score_adj内核强制从构造上杜绝 18 GB 泄漏PSI 压力 → 自我清理❌需要补丁Linux Chrome 没有 MemoryPressureMonitor标签页丢弃❌目前仅扩展没有 CDP 动词过渡方案 Target.closeTarget reload丢失历史/滚动/表单状态或Memory.simulatePressureNotificationper-renderer 硬预算❌需要补丁仅进程内有效掌控生命周期按自己的策略创建/销毁✅ 一旦自持进程大部分实际收益所在容量现实没有人在 2 GiB 里流式跑有头浏览器。内核给有头模式定价 8 GB vs 无头 1 GBSteel 按每个会话 300-500 MB、至少 4 GB 做预算neko 要 3-4 GB。一个 6-8 GB 的 VM 档位比上面任何工程都便宜。5.5 分发 —— 在本地随包发布浏览器的真实成本分析中修正了一点公证不是问题。它是按次提交的应用包已经公证hardenedRuntimeteamN897NVV9VCElectron 本来就随包带一个同样嵌套 helper 结构的 ChromiumSmartScreen 发布者信誉会跨版本延续。真正存留下来的是更新通道 —— 真正的拦路虎。仅 Chrome 150 就带 382 个安全修复2026 年到 7 月已有 5 个零日被野外利用。一个渲染敌对内容的浏览器每年每平台需要 40-60 个发布。今天没有自动更新器。Omaha-4 商用约€12,000/每目标 OS外加授权与年费。一次性签名工作一个外来的Chromium.app需要其嵌套 helpers 由内向外逐个签署并带 per-helper entitlementsrenderer 需要 JIT其他 helper 不应获得。在afterPack/afterSignhook 里做需要数天到数周。Shape A 同样需要。体积安装包约 134 MB → 约 250-280 MB安装后 270-347 MB → 约 700-850 MB。构建矩阵gn args 和补丁集几乎原样可移植只有 PSI 补丁仅限 Linux——macOS 和 Windows 本来就有 MemoryPressureMonitor。Windows 可从 Linux 交叉构建Brave 自 2023 年起在生产中这样做。macOS 需要 Apple 硬件约 $2k 1-2 工程师周。对我们有利的反驳我们本来就在通过 Electron 33 分发 Chromium 130已 EOL落后 21 个里程碑。一个新构建的、跟踪 extended-stable 的自定义 Chromium 会比今天交付的更新。诚实的区分是暴露面而非过时——Electron 的 renderer 目前只渲染我们自己的 UI 和 noVNC 页面而浏览用 Chromium 会持续吞入敌对内容。不对称性VM 侧完全不需要这些——无需签名、无需公证、无需更新器、无需商店。按月重建加上针对活跃利用 CVE 的临时重建在 VM 侧完全站得住。自定义浏览器的 VM 半侧很便宜桌面半侧才是成本所在而且它卡在我们无论如何都必须有的更新器上。5.6 隐私与 profile 模型共享 profile 的访问既是资产也是负债这个前提是对的而且在早期分析中被低估了。让扩展有效的特性——与用户自己浏览无异、带着用户全部会话——恰恰也是它具有侵入性的原因。VM 路径已经实现了我们想要的模型运行在用户自己 profile 上的扩展才是那个离群值。市场证据2026-07-30 调研Brave 是唯一为 AI 浏览隔离 profile 的浏览器创建全新的浏览器 profile…cookies、登录态、缓存不会跨 profile 流动。2026 年 5 月全渠道发布仍然小众。Chrome auto browse目标 2 亿台设备刻意运行在用户已认证的会话上。真正发布并获胜的是凭据中介credential brokering而非 profile 隔离1Password for Claude2026 年 7 月注入限定于当前任务的凭据、任务结束即销毁、Agent 永远看不到密钥。Steel、Kernel、Browserbase 都做凭据作用域Steel 明确推荐 profile 持久化而非隔离。企业侧Five Eyes 指南2026 年 5 月要求 Agent 身份、最小权限和短时凭据。作用域化的 profile 满足这一点——凭据中介同样满足。该指南没有任何关于浏览器 profile 的措辞。执行比声明重要Anthropic 的 Claude-in-Chrome 拥有唯一真正的按站点授权表面而其权限存储可以被直接写 LevelDB 绕过。扩展存储的权限是 UXprofile/OS 边界才是执行。推论我们已经拥有可执行的那一半VM 是真正的边界。差异化不在边界本身——而在于为它配上低摩擦的凭据路径。Brave 发布了边界却没解决摩擦于是保持小众。未验证SOC 2 / ISO 27001 / 安全问卷是否真的会阻挡全 profile 的 Agent 访问。未经验证不要把它当作销售论据。5.7 呈现方式 —— 为什么当前 VM 体验很差与二进制无关UX 质量与浏览器所有权是正交的。自定义构建买来的是内存与控制它买不到任何 UX。今天用户看到的是Electron 窗口 → noVNC 网页 → 带任务栏和壁纸的 XFCE 桌面 → 带 WM 装饰的 Chrome 窗口 → 标签页。四层嵌套的 chrome因为 Xvfb 没有-randr而做客户端缩放放在独立窗口里且全程没有 fps 调优。按收益排序的修法——全部不需要自定义二进制别再流式传输桌面。从浏览器视图中去掉xfwm4/xfce4-panel/xfdesktopChrome 全尺寸无装饰地独占显示。产品决策VM 目前同时也是一个可用的桌面xfce4-terminal、默认浏览器链所以可能需要两种模式。把浏览器 chrome 渲染到我们自己的 UI 里—— 标签条、地址栏、前进/后退用 React 实现数据经由现有 8787 通道从 daemon 喂入流只承载视口。与--kiosk配合。加-randr让分辨率跟随窗格而不是缩放把窗格停靠进主窗口而非独立。传输以后 VNC → WebRTCSteel 实测 25 fps vs CDP screencast 的 4-12 fps。这是一个项目不是一次配置修改。天花板人机交互仍然要跨网络。但 Agent、daemon 和浏览器在VM 内同处一地自动化速度不受影响——只有观看与接管跨线传输。6. 已验证的陷阱分析过程中发现每个都会在天真迁移的第一周咬人Target.createBrowserContext创建的 context 是临时的。类似隐身模式cookies/localStorage 永不落盘dispose 或浏览器重启即销毁。因此按 Agent 创建的 context破坏登录持久化R5/R6。此外没有 CDP 动词能把 target 在 context 之间移动所以接管/交还的人机交接模型会失效。扩展 reaper 看不见原始 CDP 的 attach。hiveAttachedTabs只由扩展自己的cdp.attach分发填充background.js且是 reaper 的跳过检查同文件约 1015 行。任何 daemon 驱动 9222 端口的共存窗口里其标签页都会被丢弃并移除——复现 2026-07-01 的标签页创建后立即死亡特征。daemon 侧策略可被绕过只要 127.0.0.1:9222 开放且 Agent 有 bashcommand_guard只按名称阻止杀/启浏览器进程不阻止对 loopback 端口的curlcommand_guard.py 的正则确实只匹配进程名与pkill/killall/kill动词。修法--remote-debugging-pipe且仅由 daemon 持有或一条 iptables uid-owner 规则。把 reaper 改回 Hive-group 作用域会重新打开已知泄漏。那是 2026-07-05 之前的设计因为漏掉window.open逃逸者和 bridge 重启后的孤儿标签页而被移除。修法是能跨越 service-worker 重启存活的正向标签页所有权跟踪。其中第 2、3 条可以直接在仓库源码中验证hiveAttachedTabs的 Set 定义、touch/forget 逻辑与资格筛选都在 background.js命令防护的完整模式列表在 command_guard.py其对应测试在 test_command_guard.py例如阻止google-chrome --remote-debugging-port9222 ... --user-data-dir...的用例。7. 线上缺陷与任何决策无关7.1 扩展 reaper 作用于用户自己的标签页在 v1.7.4本地用户安装的 Web Store 版本中从 service-worker 启动起跑30 秒 alarmbackground.jskeepAlive 相关在 1441-1443 行没有任何对活跃 Hive 会话或已连接 bridge 的门控。可回收标签页 除活跃/有声/固定/CDP-attached 之外的所有存活标签页。用户自己的空闲标签页同样符合资格。代码内注释明确写着上限适用于所有 live-backed 标签页agent user orphan。无 Hive-group 作用域。上限是全局 3 个且上限路径没有空闲时长要求background.js。开了 10 个标签页 → 下一轮清扫丢弃 6 个。两次丢弃被拒后升级到chrome.tabs.remove()同文件 1078-1085 行。Chrome 会在beforeunload、表单输入和活跃下载时拒绝丢弃——所以升级路径偏偏偏向持有未保存工作的标签页。桌面端打包的副本是 v1.2.3、没有 reaper因此该缺陷不会从那个通道发出——但应用深度链接到商店商店里是 v1.7.4。请在真实 profile 上复现以确认爆炸半径。当前仓库中的扩展源码background.js就是 v1.7.4 形态关键常量可以直接读到HIVE_IDLE_MS 2 * 60 * 10002 分钟、HIVE_MAX_TABS_TOTAL 3、HIVE_DISCARD_FAIL_ESCALATION_THRESHOLD 2、REAP_PERIOD_MIN 0.5首轮在 SW 启动后 30 秒。注释还交代了数值调优背景IDLE_MS从 5 分钟缩到 2 分钟、上限从 2026-07-05 起从 Hive-group 作用域改为全局作用域——因为 2026-07-04 的调查在 14034 团队的 v73 沙箱发现 8 个活跃 renderer 却报告 0 个 Hive 分组。7.2 VM 的 Chrome profile 不持久化hive-userdata-snapshot.sh:15排除了/data/chrome。在修复之前R6 没有地基。8. 开放问题 / 先决条件#问题为什么阻塞成本Q1在 VM 里写入的 profile能否用同一二进制配--password-storebasic在本地加载整个统一体验需求都押在这上面。如果失败R6 不可达成方案要改1-2 天Q2Shape A 还是 Shape B决定 Electron 外壳是否存活在 Q3 之后决定Q3src/main有多少能迁入 Python runtime把 Shape B 从 10.6k 行重写变成约 2k 行外壳每条分支都有价值需要范围评估Q4本地是否接受--password-storebasic静态 cookie 加密弱安全决策R6 所需决策不是工作量Q5在 profile 已持有真实凭据的 VM 里是否接受关闭站点隔离A0 的最大控制杆与持久登录会话冲突决策Q6--disable-featuresAutomationControlledstart-chrome.sh:130是否无效真正有效的开关很可能是--disable-blink-featuresAutomationControlledB 级预算的 webdriver 清理可能已经免费1 小时Q7VM 容量维持 4 GB/2 GiB cgroup 还是升到 6-8 GB比第 5.1 节任何工程都便宜决策9. 分析当前的指向不是锁定决策——是当前的推理。按所服务的用户体验排序因为那才是这份工作的目的最快的可见 UX 提升完全不需要架构决策。第 5.7 节的呈现修法停止流式桌面、把浏览器 chrome 渲染进我们自己的 UI、加-randr、停靠窗格对UX2 和 UX6的提升超过任何二进制选择而且在原版 Chrome 上今天就能做。修 reaper第 7.1 节是单个最大的UX5收益且无论方向如何它都是线上缺陷。先做、每条分支都有价值第 5.7 节呈现修法修 reaper 作用域第 7.1 节让 VM profile 持久化并跑 Q1UX3 在它成立前没有地基从src/main抽取非 Electron 逻辑Q3A0 flags。基于原始 CDP 的 CLI 控制面是价值最高、风险最低的改动今天就能跑在原版 Chrome 上——9222 端口已经开放且未被使用。它还无需协议变更就移除了调试器面板R3。A 级自建构建是 R1/R6 所必需的——版本可控是 profile 保持兼容的唯一方式。VM 是自定义浏览器便宜且内存真正受限的地方。桌面半侧卡在我们无论如何都欠着的自动更新器上Electron 33 / Chromium 130 今天已 EOL。Shape B 符合规格Shape A 保护既有投资。R1R4 在 Shape A 中冲突这是支持 B 的真实证据——但决策应等到 Q3 告诉我们外壳到底要花多少钱。10. 溯源与证据边界本次分析中代码已验证全部第 3 节、第 4 节快照排除、第 5.2 节Electron 版本与 OSR API 表面、src/main行数、第 5.3 节缺少--enable-automation/--silent-debugger-extension-api、第 5.5 节签名配置、第 6.2 节、第 7 节。来自代码阅读 Agent传输链路细节、CDP 动词计数、扩展耦合 vs 可移植部分的划分。来自网络调研2026-07-30文内已标注第 5.1 节构建经济学与市场普查、第 5.3 节 CLI-vs-MCP 测量、第 5.4 节内存数据与厂商容量、第 5.5 节分发成本、第 5.6 节隐私/市场证据。第一方实测Chrome 149、headless、3 个标签页、PSS−7.6%/−12.4% 的 flag 差异与 −38 MiB 的--in-process-gpu是在一台 31.9 GB、带真实 GPU、已登出页面的台式机上测得的——不是在 2 vCPU / 2 GiB-cgroup 的 Xvfb VM 里。不要把它们当作 VM 数据引用。明确未验证SOC 2 / 问卷中关于 Agent profile 访问的措辞AI 能压缩 Chromium rebase 工作量企业浏览器厂商的定位2026 年 1Password 之外的作用域化 Agent 身份标准工作。对于希望深入源码的读者本镜像仓库提供了两条主要线索扩展侧从 manifest.json权限与主机声明与 background.jsWebSocket/命令分发 LRU reaper hiveAttachedTabs跟踪入手协议细节见 README.md自动化侧从 bridge.pyCDP 命令封装、shadow 穿透、AX 快照、对话框处理与 health.pytab.audit健康分类入手。该设计文档本身位于 docs/internal/browser-architecture-design.md可作为持续更新的决策基线。赞分享人工智能AI Agent多智能体MCP 服务工具调用浏览器控制【免费下载链接】hiveMulti-Agent Harness for Production AI项目地址https://gitcode.com/gh_mirrors/hive48/hive点击查看免费下载相关推荐Web-Dev-For-Beginners 浏览器扩展第一课从浏览器架构到碳排放追踪扩展的落地实战Web Dev For Beginners 浏览器扩展第一课从浏览器架构到碳排放追踪扩展的落地实战 本文基于 Web Dev For Beginners 仓库文档教程前端如何用本地AI浏览器扩展提升网页浏览体验从配置到精通指南如何用本地AI浏览器扩展提升网页浏览体验从配置到精通指南 想让AI助手时刻陪伴你的网页浏览又不想担心数据隐私Page Assist这款开源浏览器扩展让本地AI 应用人工智能本地部署RAG交互助手解密ES-Client让Elasticsearch数据探索变得简单的实战指南解密ES Client让Elasticsearch数据探索变得简单的实战指南 你是否曾在面对Elasticsearch复杂的管理界面时感到无从下手是否因为K数据库客户端开发者工具数据可视化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考