使用场景
开发者或自动化流程搭建者在自己已登录的 Chrome 里,让 Claude Code、Codex、Cursor、Gemini CLI 等 agent 通过 MCP 与浏览器扩展接管页面,处理需要登录态的后台、表单填写或数据抓取,最终由 agent 直接完成页面动作。
旧做法是手工在浏览器里操作,或自建 Playwright/Selenium/Puppeteer 脚本并自行处理登录态与选择器;也有用无头浏览器加 cookie 注入的方案,但需要额外配置且易失效。
公开材料支持的痛点是:需要登录态的任务无法交给 agent——无头浏览器或新会话没有 cookie 与登录凭证,用户只能手工重复点击、复制粘贴,或自己写 Playwright/Selenium 脚本维护登录与选择器;不解决的后果是这类任务无法被 agent 闭环,只能人工兜底。
xOcto 的判断
需求有依据
趋势是 agent 正从沙箱浏览器转向用户真实登录态,登录墙后的重复操作第一次可以被自动化。切入可考虑电商后台、广告投放、跨境卖家运营这类每天在登录后台里点几十次的岗位,按可完成的流程或结果收费,而不是卖一个浏览器插件。
使用理由
为什么用户会选择它
推断:相较自建脚本,它通过复用用户本机 Chrome 的既有登录态,省去注入 cookie、维护登录会话和选择器这一步,agent 直接对真实页面执行动作,因此已在用 Claude Code/Cursor 等 agent 且任务落在需登录页面上的开发者,会在不想再写脚本时选择它。
还不能轻易下结论的地方
真正值得继续追问的矛盾
追踪该 公开代码仓库 仓库的 README、issue 与 discussion,确认支持站点范围、登录态权限边界与真实部署案例。