2026 年 8 月底到 9 月初,HN 上集中出现了三个独立项目,指向同一个深水区:AI 智能体需要持久化的浏览器身份,才能跨任务断点恢复、避开反检测、跑出可信行为。第一手素材是 Ryan-AI-Studios 的 Hands(Rust 写的 MCP/CLI),目标直白:让 coding agent(Grok、Codex、Claude Code、OpenCode 等)用"日常 Chrome"操作
2026 年 8 月底到 9 月初,HN 上集中出现了三个独立项目,指向同一个深水区:AI 智能体需要持久化的浏览器身份,才能跨任务断点恢复、避开反检测、跑出可信行为。第一手素材是 Ryan-AI-Studios 的 Hands(Rust 写的 MCP/CLI),目标直白:让 coding agent(Grok、Codex、Claude Code、OpenCode 等)用"日常 Chrome"操作 Windows PC——不开启远程调试端口、不用 CDP、不用 Playwright/Puppeteer,只是让 agent 看着屏幕、移动真鼠标、点击、键入,像人一样。第二手素材是 Rindler(YC S26)的 Maxxwell,创始人在做浏览器 agent 时撞上了"登录态保留、绕过 bot 防御、凭证 + 2FA 处理"等硬问题后,转向做"跨多个 coding-agent session 的状态管理"。补充素材是 Jess 做的 Puppetflow——在浏览器自动化里把可观测性和调试体验顶到一等公民。这三条独立项目一起,把"持久化浏览器身份"这件事从"加个 cookie jar 就行"的工程直觉,升级成了 Agent 时代的真问题。把这件事放在一张图里看,可以落几条判断:第一,Agent 用浏览器和人类用浏览器不是同一件事——人类不在乎"这个浏览器实例是第几次启动",Agent 必须把"我是谁、我登录到哪、我跑过哪些步骤"持久化下来;第二,持久化不只是 cookie,还有完整的网络指纹、登录状态、可审计的运行轨迹;第三,"反检测"在 Agent 时代不再是爬虫的灰色问题,而是 Agent 在常规业务里"被当成正常用户对待"的基础设施问题。
一、Hands:让 agent 用"日常 Chrome",而不是"自动化浏览器"
Ryan 在 HN 上的自述把动机说得很直接:他想"让一个 coding agent 用 Windows PC 和真 Chrome profile 像自己一样:看屏幕、移动真鼠标、键入、点击,但不把 Chrome 变成自动化浏览器"。这是个非常精确的工程目标——不是"给 agent 一个无头浏览器",而是"让 agent 操作人日常用的那个 Chrome"。具体做法:Hands 是 Rust 写的 MCP/CLI。harness(Grok、Codex、Claude Code、OpenCode 等)调用 observe、click、type、scroll 这些工具。observe 返回截图路径加上一个小的元素列表(UIA + 可选 Chrome DOM id)。click 走 OS 的 SendInput 在贝塞尔曲线上模拟,而不是 Chrome DevTools 的 click。这意味着:没有 Playwright、没有 Puppeteer、没有 remote debugging port。每天的 Chrome 不带任何额外 flag 启动,或者直接 attach 到已经打开的 Chrome。大多数盯着 CDP / automation flag 的站点看不到这些信号——但它们仍然能看到注入的输入(LLMHF_INJECTED)。这条路线背后有一个 Chrome 扩展——一个解包的小扩展,把页面结构(chr: id、卡片列表)融合起来,这样模型不用从像素猜测。sideload 走手动流程。融合在 service worker 进入 inactive 时会失效,需要 reload 卡片。作者明确划定能做什么和不能做什么:适合的是个人桌面的研究类任务——在 cars.com 上找 Camry、读一个页面、填个 ZIP、关掉 cookie banner。不适合的是沙箱、money 操作、跨账户 2FA 验证——它能点屏幕上任何东西,包括 checkout 和 Easy Apply;"付款前确认"是二进制的尽力而为分类,不是硬保证;不是 CAPTCHA 求解器,在日常 Chrome 上两次尝试失败就让位;Windows only。最关键的一条是日志——日志放在 %LOCALAPPDATA%\hands\logs\ 下,扩展要求
二、Maxxwell:持久化不只是 cookie,是 session 跨任务的"上下文恢复"
Rindler(YC S26)的 Michael 在 HN 上的描述,把"持久化浏览器身份"的另一层意思展开了:他们最初做的是"用站点的缓存表示登录"的浏览器 agent,撞上了一堆硬问题——站点映射、过 bot 防御、凭证和 2FA 处理——维护面太大,被技术交付拖死。后来转向做 Maxxwell:管理 dozen 个 coding-agent session 的进度、上下文和障碍。有意思的是 Maxxwell 本身不是浏览器 agent,而是给 agent session 做"上下文持久化 + 多 session 协调"。每个 worker 都是未经修改的 Claude 或 Codex 进程,跑在真 PTY 里,可以随时 attach 到任一 session 做接口。orchestrator agent 负责对齐目标、过滤噪音、告诉用户"什么落地了、什么被代理决策了、什么需要你介入"。具体效果:用 Maxxwell 之后,每个 prompt 合并 PR 数从 0.9 涨到 5,revert 率从 0.56% 降到 0.20%。orchestrator 能管数小时的 agent session,过夜跑也很稳。BYOK 或订阅,免费且完全本地。这个故事和 Hands 合在一起,呈现的是"持久化浏览器身份"这件事的两层含义:第一层是"在单个 agent 里持久化 cookie/profile/HTTP 指纹",Hands 解决的是这一层;第二层是"跨多个 agent session 持久化上下文与状态",Maxxwell 解决的是这一层。两层合起来才是 Agent 时代真正的"持久化"。
三、为什么"持久化"在 Agent 时代是个新问题
浏览器一直都有 cookie、localStorage、profile 这些持久化机制,听起来不是新东西。但 Agent 用浏览器时,持久化的问题变得完全不同。第一,人类用浏览器,session 短,跨 session 不需要长期身份。Agent 用浏览器,session 长到小时甚至天,跨任务、跨天、跨实例必须保持"我是同一个用户"的连续性。Cookie jar 默认只活一两次请求,profile 是绑在 Chrome 实例上的,Agent 不能假设自己有持续运行的实例。第二,人类被反检测工具当成"可能是 bot",但大多数时候不会被拦;Agent 被反检测工具重点盯,因为"它就是 bot"。这就是为什么 Hands 选择不开启 remote debugging port、不挂 CDP——任何 CDP 痕迹都会让 Cloudflare 这类反爬系统提高风险评分。Ryan 在 HN 上承认"They can still see injected input (LLMHF_INJECTED)"——注入输入能被识别,所以这个方案在某些高敏感站点上仍然可能被打分。第三,人类不需要"可审计"——会话结束人就走了;Agent 必须"可审计"——所有动作要被记录、可回放、可被合规复盘。Hands 把日志放在 %LOCALAPPDATA%\hands\logs\,把所有动作的截图都留底,正是为了这个需求。Maxxwell 让 orchestrator 替用户记住"什么被决策了",也是同一个思路的不同切面。把这三个维度合在一起,"持久化浏览器身份"就升级成了一个三层问题:身份层(cookie/profile/HTTP 指纹)、会话层(session 跨任务恢复)、审计层(动作日志 + 可回放)。任何只解决一层的方案,在生产 Agent 落地上都会撞到另外两层的硬墙。
四、补充观察:Puppetflow 的可观测性视角
Jess 做的 Puppetflow 给出了第三个独立视角。她做了一年多,核心动机是"用 Puppeteer 做真实项目时,脚本写完容易,跑起来出问题才是真正痛的部分"。脚本在生产失败时,她要立刻知道:发生了什么、哪一步挂了、当时页面什么样、之前发生了什么、console 里有什么。围绕这个,Puppetflow 给了实时 live view、可交互(鼠标键盘模拟)、重放旧 run、看日志、保留执行历史。她明确做了两个早决策:一是 Blueprint——可复用的自动化,允许通过 PR 在 library 仓库贡献,目标是建立社区、避免每个人都在重造一样的轮子;二是"不做 AI-first"——AI 在有些地方确实有用,但不总是你需要的,而且贵、慢、不可预测。她更喜欢确定性方法,因为挂的时候好调试。但她也加了对模型的支持,可以直连模型或者让模型接管浏览器。这背后两个独立痛点:一是实时 live view 远比想象的难,UI 怎么在 run 进行中保持同步是个真问题;二是防止 flow 被反 bot 措施拦下,她准备实验 fingerprint-chromium 这类项目。"让浏览器自动化在越来越激进的 bot 检测下保持可靠"被她明确称为"一个我一个人处理不了的问题"。
五、对企业 Agent 落地的几条具体判断
把三条独立信息合起来,企业 Agent 落地可以落几条具体判断。第一,持久化浏览器身份要分三层来规划。身份层用真 Chrome profile 而非无头浏览器实例,降低指纹差异;会话层用 PTY/真 session 而非内存中的 session,允许 attach 和恢复;审计层用集中日志(本地或服务端)而不是进程内日志,确保事后可查。三层一起做,才能支撑生产 Agent 的运行要求。第二,"用日常 Chrome 而非 headless Chrome"是 Hands 给出的具体路径。这条路在反 bot 严格的站点上比 headless 更可靠,但代价是只能在桌面端跑、需要用户登录、不能完全无人值守。企业 Agent 平台如果选这条路,要明确"哪些任务是 agent 自主跑、哪些必须有人在桌面"——两条流不能混。第三,"跨 session 上下文持久化"是 Maxxwell 解决的问题。多个 agent session 同时跑,如果每个 session 各自维护自己的上下文,会迅速陷入"哪个 session 做了哪个决策"的混乱。把 orchestrator 抽象出来、把决策日志集中化,是一条已经被验证可行的工程路径。第四,可观测性是 Agent 落地的硬要求,不是加分项。Puppetflow 在 2026 年的产品形态里,把"实时 live view + 重放 + 执行历史"做成核心功能,这条线在企业落地时要提前规划——没有审计能力的 Agent 平台,即使技术上能跑,也过不了合规这一关。第五,"反检测"不是爬虫的灰色问题,而是 Agent 在正常业务里能不能被当成正常用户对待的基础设施问题。当 agent 去订机票、查账单、抓邮件时,如果每次都被 Cloudflare 卡住,业务就跑不下去。这意味着 agent 平台的设计者必须正面处理 HTTP 指纹、JS 指纹、注入输入特征这几件事,而不是默认"目标网站会放过我"。第六,持久化方案不要试图一个项目吃所有场景。Hands 适合个人桌面研究类;Maxxwell 适合多 session 跨任务协作;Puppetflow 适合需要重放和审计的自动化运行。三个项目并存说明这条赛道没有"银弹",企业 Agent 平台的设计要把浏览器身份持久化做成可插拔的层级,而不是绑死一个方案。Hands、Maxxwell、Puppetflow 在 2026 年 8 月底到 9 月初留下的最重要一条经验:Agent 时代的"持久化浏览器身份"不是简单的 cookie 持久化,而是身份、会话、审计三层叠加的工程问题。任何一个项目只解决一层都不够,三层一起做才能让 agent 在生产里跑得稳、跑得久、跑得可被信任。5 倍速度、80% 内存节省是上一轮浏览器栈重构的数字;身份持久化是这一轮浏览器栈重构的主题。
