2026 年 8 月,HN 上连续两条 Show HN 把浏览器智能体(Computer Use)这条赛道的工程拐点摆到了台面上:一条是 8 月 18 日的 NeoBrowser,跨平台 Rust MCP,能驱动你已经登录的真 Chrome 跑会话;另一条是 8 月 23 日的 Hands-Rust,Windows 限定 MCP/CLI,看屏幕、动鼠标、点真实 Chrome 窗口。前者赌的是"会话复用 + 真实指纹",后者赌的是"无 CDP 标记 + OS 级输入",路径完全不同,但要回答的是同一个问题:模型怎么才能像一个真实用户在浏览器里干活,而不是每次都被登录墙、Cloudflare 挑战和反自动化指纹拦在门外。
这两个工程样本的背后,是一个过去半年反复验证的事实:把 Computer Use 当成"截图 + 点像素"的简单闭环,在生产场景里跑不动。登录态、Cookie、指纹、设备一致性、站点风控——每一项都是落地必须翻过的坎。本文把 NeoBrowser 当主线,对照 Hands-Rust、browser-use、Playwright MCP 这条线,拆解 MCP 浏览器智能体在 2026 年中真正能用的工程范式。
一、为什么"无头浏览器 + 空白 Cookie"这条路走不通
NeoBrowser 作者 pitiflautico 在 HN 自述里把这个问题讲得很直接:他尝试过的每一个浏览器 MCP 都掉进同一个坑——工具启动的是一个全新的、可被指纹识别的无头浏览器,没有 Cookie、没有历史、没有持久登录。结果就是模型永远在撞登录墙和反机器人检测。这个观察跟过去半年大量实际使用 browser-use、Playwright MCP 的反馈完全一致:在 SaaS 后台、电商平台、社交媒体后台、企业 ERP 这些真正有价值的目标上,模型每次都会卡在"请登录"或者"请通过人机验证"。
问题不在模型能力,而在浏览器实例的身份。新启动的无头 Chromium 有一个干净的指纹表:User-Agent 与 Client Hints 不匹配、navigator.webdriver=true、GPU WebGL 渲染特征是 Mesa llvmpipe、字体列表是 Chromium 默认那一套、没有历史 Cookie、没有 localStorage、没有 IndexedDB 里那个跟用户绑定的 UUID。这些信号单独看任何一个都不致命,但叠在一起就形成了一张"自动化"画像,被 Cloudflare、Akamai、DataDome 这类风控系统直接拦掉。
绕开它的方法只有两条:要么伪造一张足够像真实用户的指纹(这条路几乎每家都在做,但收效越来越差,因为风控也在用模型),要么干脆就用真实用户已经在用的那个浏览器实例。NeoBrowser 和 Hands-Rust 不约而同选了后者,但实现路径完全不同。
二、NeoBrowser 的工程选择:CDP 驱动 + 真 Profile 解密
NeoBrowser 走的是 Chrome DevTools Protocol(CDP)路线。它驱动的是真正的 Google Chrome 二进制,不是 Chromium、不是 headless shell、不是 Playwright 内嵌的浏览器。这个选择有几个直接收益:第一,真实 Chrome 的渲染引擎、字体栈、GPU 路径跟普通用户一模一样,WebGL 指纹、Canvas 指纹、字体枚举全部自然落在正常区间;第二,可以选择复用用户已有的 Chrome Profile 目录,把里面的 Cookie、localStorage、IndexedDB 全部继承过来,模型直接以"已登录用户"身份进入目标站点;第三,User-Agent 自动跟 Profile 所在操作系统的 Client Hints 对齐,不会出现"UA 说自己是 Win11,实际是 Linux 容器"这种典型指纹穿帮。
复用 Profile 涉及一个硬技术:Chrome 在 Windows 上用 DPAPI 加密 Cookie,在 macOS 上用 Keychain,在 Linux 上用 secret-service。NeoBrowser 用 Rust 写了对应平台的解密逻辑,把 Cookie 解出来注入到启动的实例里。这一步对模型使用体验的影响是决定性的——模型不再需要"先登录"才能干活,而是直接以用户身份进入已经登录好的会话。HN 评论里 Johnny_Bonk 直接说这就是他日常最缺的:每天让 Claude 或 ChatGPT 用他自己的已登录 profile 跑任务,他自己都专门搭了一套 skill 凑合用。
但作者也做了一个克制的设计:Profile 里的会话身份 Cookie(就是"记住我"那类用于维持长期登录态的 token)默认排除在外,不会被注入到 NeoBrowser 启动的实例里。这个细节非常关键——它意味着 NeoBrowser 不会把用户的真实长期登录态挤下线,模型拿到的只是当前会话级别的访问权,真实浏览器那边的登录态依然是稳定的。这种"借用身份但不挤占身份"的做法,反映出作者对真实用户场景的理解深度。
三、隐形不是伪装:真实指纹才是真隐形
NeoBrowser 文档里专门有一段讲"genuine stealth, not spoofing"。这个区分是浏览器智能体工程里非常重要的一个分水岭。早期各种 anti-detect 工具的做法是伪造指纹——用假的 Canvas 哈希、假的字体列表、假的 WebGL vendor、假的 hardware concurrency。这些伪造在 2024 年还能撑一阵,到 2026 年已经完全失效,主流风控系统都上了机器学习检测,模型能从"指纹看起来太干净"反向识别出伪造。
NeoBrowser 的策略是不伪造:它不主动设置任何 stealth flag,所有指纹特征都是真实 Chrome 在真实操作系统上自然产生的——UA 与 Client Hints 真实一致、GPU WebGL 渲染路径真实、navigator.webdriver 真实为 false(因为它走的是附加 CDP 通道而不是启动 --remote-debugging-port 那种会污染 navigator 的方式)。作者在 README 里直接说,这套指纹"passes bot.sannysoft live in CI"。这个反向验证在工程圈是被广泛引用的基准测试,能稳定通过就已经筛掉了 80% 的"伪无头"实现。
但作者也明确划了一条线:NeoBrowser 不假装能解决所有挑战。面对 reCAPTCHA、Turnstile 这种需要交互解题的人机验证,NeoBrowser 不做 OCR、不调打码平台、不接模型视觉——它只做一件事,把"我撞墙了"这件事检测出来,然后告诉模型"该走真实会话路径或者人工接入了"。这种诚实的工程取舍在 HN 评论里被专门拎出来点赞——nater5000 说"if you can't be bothered to clean up your vibecoded README, I'm going to assume I'd be better off just vibecoding my own version",反过来就是说,作者对自己能力的边界有清晰认识,这本身就是工程成熟的标志。
四、Human-like Input:鼠标轨迹的贝塞尔曲线与按键时序
另一个被多数浏览器 MCP 忽视的工程细节是输入行为的拟真度。NeoBrowser 在三个层面做了真实化处理:第一,鼠标点击不是瞬移到目标坐标,而是沿贝塞尔曲线带轻微抖动走过去,这跟人类手腕的物理动作分布吻合;第二,键盘输入支持逐键模式,每个键之间插入真实时序间隔,而不是直接把字符串塞给页面,这绕开了很多站点对"瞬时填入完整字段"的检测;第三,鼠标轨迹、点击停留时间、页面滚动节奏这些都能在配置层调整,适配不同站点的风控敏感度。
这个细节在测试环境里看不出来差异,但在生产场景里差别巨大。Cloudflare 的行为分析模块会统计"鼠标轨迹的曲率分布"、"点击落点的标准差"、"按键间隔的高斯拟合度",这些信号一旦偏离真实用户,就会被标记为可疑。NeoBrowser 在这一层做的不是花活,是把"看起来像真人"这件最基本的事做扎实。
五、43 个工具 + 5MB 单二进制:工程交付物的另一种思路
NeoBrowser 提供了 43 个 MCP 工具,覆盖多标签管理、表单填写、上传下载、搜索、结构化提取(playbook)。这个工具面不算小,但作者选择把所有能力打包成一个 ~5MB 的静态 Rust 二进制,零运行时依赖。这个交付物形态本身就是一种工程表态:不要 npm 依赖树、不要 Python 虚拟环境、不要 Docker 镜像——单个文件就能跑。这跟企业 IT 部署的现实非常贴近:很多公司的生产服务器不能装 Node.js、不让跑容器,但允许放一个静态二进制;安全审计也更容易——一个 5MB 的 Rust 二进制,扫描三遍就知道里面有什么。
43 个工具的设计逻辑也值得看。它不是按"页面操作原子"(click、type、scroll)切,而是按"用户场景"(upload、download、search、playbook)切。这反映出一个判断:模型调用 MCP 的心智模型应该是"我要做什么",而不是"我要执行什么 DOM 操作"。playbook 这个工具尤其有意思——它把一组操作打包成一个可复用的剧本,模型第一次摸索出来的填表路径,可以序列化成 playbook,下次直接调用,跳过重新规划的环节。这是浏览器智能体从"每次重新规划"走向"经验沉淀"的关键一步。
六、Hands-Rust 的对照路径:不走 CDP,直接动 OS 鼠标
Hands-Rust 给出了完全不同的答案。它的作者 Ryan-AI-Studios 在 HN 自述里说得很明确:Hands 不启动 Playwright、不启动 Puppeteer、不需要 --remote-debugging-port。它的 observe 工具是截屏加一个小型元素列表(UIA + 可选的 Chrome DOM id),click 工具是 Windows API 的 SendInput,在贝塞尔曲线上发送真实的鼠标事件。
这条路径的优势是:任何对 CDP / automation flag 的检测手段全部失效,因为根本没有用 CDP,Chrome 完全在日常模式下运行(没有附加任何启动参数,或者附加上去但不污染 navigator.webdriver)。Cloudflare、Akamai 这类基于"你的浏览器是不是在 automation 模式"的检测完全失效。Hands 自述里也直接说"Sites that key on CDP/automation flags mostly don't see that"。
但代价也很明确:Hands 是 Windows only,它的整个输入路径都依赖 Win32 SendInput 和 UIA,在 macOS 和 Linux 上没有等价实现;它不是沙箱,模型可以点屏幕上任何东西,包括 checkout 按钮和 Easy Apply——这是 Hands 作者在 README 里明确标注的"what it is not";它的 confirm-before-money 是 best-effort 分类,不是保证;prompt injection 从截图和 DOM 文本进来是真实风险,二进制把这些文本当不可信,但模型可能不这么判断。
两条路径放在一起看,工程取舍非常清晰:NeoBrowser 赌"会话身份 + 真实指纹 + CDP 跨平台",Hands-Rust 赌"OS 级真实输入 + 无自动化标记 + Windows 单一平台"。前者通用性更强,后者在 Windows 上的隐蔽性更极致。两者都没有解决 prompt injection 这个根本难题。
七、Prompt Injection:浏览器智能体还没跨过的真门槛
HN 评论里 dongkeren 给 NeoBrowser 列了一份安全清单:域名白名单、提交/删除前的人工审批、操作后的持久审计记录、之前授予权限如何撤销。这些 NeoBrowser 的 README 里只部分提到(opt-in、文件权限、SSRF),其余没有明确设计。更根本的问题是:复用真实用户登录会话等于把用户的全部授权委托给了智能体,如果模型被 prompt injection 诱导执行了写操作,后果会直接落到用户身份上。
npodbielski 在评论里贴了一张 README 里的 GIF,指出日志里出现了明文密码。nater5000 评论里说"if you can't be bothered to clean up your vibecoded README, I'm going to assume I'd be better off just vibecoding my own version",虽然语气尖刻,但指向的是同一个问题:把用户的真实登录会话借给模型跑,工具的工程严谨度门槛比传统 MCP 高一个数量级。
browser-use 的创始人 nateb2022 在评论里推荐了自己的项目,这是一个值得关注的对照:browser-use 这半年迭代速度非常快,在 GitHub 上已经积累了相当数量的 star 和实际用户,它的路径跟 NeoBrowser 不太一样——它抽象了一个 Browser Agent,把视觉理解和动作执行都封装在一个高阶接口里,模型调用的是"在这个页面上找到 X 然后点 Y",而不是"在坐标 (x,y) 模拟点击"。这个抽象层让 prompt injection 的影响面相对可控——模型不直接接触 DOM 文本和坐标,而是接触一个已经被结构化抽取过的语义层。但这条路径也牺牲了"借真实身份"的能力。
八、第三方 CDP 方案的现状:Claude Code 的 chrome-cdp-skill
andreidbr 在 HN 评论里提到了一个被广泛使用的对照方案:pasky/chrome-cdp-skill,这是 Claude Code 生态里用于测试自动化的 Chrome CDP skill,在移动端布局调试、locator 检测这些场景里被大量使用。它跟 NeoBrowser 的设计哲学有交叉但目标不同——chrome-cdp-skill 是给 Claude Code 自己用的测试工具,不强调会话复用和指纹隐身,强调的是"附加到正在运行的 Chrome 进程,跑开发者自己的测试任务"。
这个差异点很关键:chrome-cdp-skill 假设使用场景是开发者自己的开发环境,没有持久真实用户身份需要保护;NeoBrowser 假设使用场景是普通用户的日常浏览,需要尽可能保留真实身份的所有权。这种场景区分直接决定了工程实现的重心。
九、企业落地视角:Computer Use MCP 离生产还有多远
把 NeoBrowser、Hands-Rust、browser-use、chrome-cdp-skill 这四条线放在一起看,2026 年中的浏览器智能体工程现状可以归纳为几点。
第一,"借真实身份"已经可行但门槛高。NeoBrowser 证明了跨平台 Rust MCP + 真 Profile 解密 + CDP 驱动这条路在技术上是通的,但工程交付物本身就需要做大量加固——会话隔离、日志脱敏、权限分级、prompt injection 防护,这些每一项都是单独的项目,合在一起就是一个完整的浏览器安全产品。
第二,"无自动化标记"已经被 Hands-Rust 在 Windows 上证明可行,但跨平台版本至今没人做出来。这条路径的工程壁垒不在 CDP,而在 OS 级的输入模拟和窗口管理——每个平台的原生 API 都不一样,要做 macOS 和 Windows 两套完整的 OS 级鼠标/键盘实现,工作量是普通浏览器 MCP 的几倍。
第三,prompt injection 是浏览器智能体跨不过去的根本难题。模型必须读 DOM 文本、必须解析截图内容,这些内容里天然可能包含攻击者注入的指令。目前所有方案的应对都是"尽力而为",没有真正的银弹。这意味着浏览器智能体进入生产场景,必须配强审计、强审批、强回滚——不是技术问题,是治理问题。
第四,工具抽象正在从"DOM 操作原子"向"用户场景剧本"迁移。playbook 这种结构化操作集合的出现,意味着浏览器智能体开始具备经验沉淀能力——第一次摸索出来的路径,第二次可以直接复用。这个趋势对生产部署至关重要,因为它把每次跑的成本从"完整规划 + 执行"压到"调剧本 + 异常处理",把智能体的能力曲线从纯模型驱动推向模型 + 经验库混合驱动。
十、对企业落地 Computer Use 的工程建议
基于上面这些观察,对于正在评估浏览器智能体落地的团队,有几条工程层面的具体建议。
第一,把"会话复用"列为高优先级能力。模型每次从空白登录开始跑,是当前 Computer Use 不能落地的最大单一原因。能复用真实登录态的工具,在生产场景里会比不能复用的工具价值高一个数量级。
第二,接受 prompt injection 是不可消除的,围绕它做治理设计。所有浏览器智能体的关键操作(提交、删除、支付、对外发送)必须走人工二次确认,不能依赖模型自己判断"这是不是注入指令"。审计日志必须持久化、可回放、可追溯到具体截图和 DOM 快照。
第三,部署形态优先选静态二进制而非 npm/Python 包。NeoBrowser 这种 ~5MB Rust 二进制 + 零运行时依赖的形态,最容易通过企业 IT 的安全审查,也最容易做版本管理和回滚。
第四,把"用户场景剧本"作为长期资产沉淀。每一次成功的端到端操作都应该被结构化成 playbook,沉淀到团队的经验库里。这不是技术决策,是流程决策,但对生产效率的影响远大于技术选型。
第五,跨平台 vs 单平台要看场景。如果目标用户群体主要是 Windows 桌面用户,Hands-Rust 这类 OS 级真实输入方案值得认真评估;如果是 macOS/Linux 跨平台场景,NeoBrowser 这类 CDP + 真 Profile 方案是当前更成熟的选择。混用两条路径会让工程复杂度成倍上升,通常不划算。
结语
NeoBrowser 在 HN 上 8 月 18 日发出来,8 月底已经被反复引用为"借真实身份跑 Computer Use 的工程新样本"。Hands-Rust 在 5 天后补上了"无 CDP 标记"这条对照路径。两条工程样本合在一起,把浏览器智能体从"截图 + 点像素"的简单闭环,推进到了"会话身份 + 真实输入 + 拟真行为 + 工具剧本"的工程化阶段。剩下的 prompt injection 治理、跨平台一致性、生产级审计,都不是某一个项目能单独解决的——它们需要整个生态在 2026 年下半年继续往工程化方向走。
