Retriever AI：免费浏览器智能体，自动找客户、投简历

在 Product Hunt 上，一款名为 Retriever AI 的浏览器智能体拿到了 121 票，跻身当日第 3 名。它的定位很直接：用一个免费的 AI 浏览器代理，替你在网页之间完成重复性工作——找销售线索并发起外联、筛选 TikTok 和 Instagram 创作者、批量投递简历。

它到底是什么

Retriever 是一款运行在浏览器里的 AI 智能体（browser agent）。和传统自动化脚本不同，它不需要你为每个网站单独写规则，而是用自然语言下达任务，由 AI 理解页面并执行操作。

官方给出的使用场景集中在三类：

• 线索挖掘与外联：让它搜索潜在客户、整理联系方式，并发送触达消息。
• 创作者筛选：为下一次营销活动，从 TikTok、Instagram 上挑选合适的创作者。
• 求职投递：自动完成找工作、填表、投简历的流程。

用户可以选择在自己的 Chrome 浏览器里本地运行，也可以使用 rtrvr 托管的云浏览器执行任务。后者对需要长时间、批量运行的场景更友好。

Browser Agent（浏览器智能体） 与 Browser Use、Claude Computer Use、OpenAI Operator 属于同一类产品形态：把大语言模型作为决策核心，通过读取网页 DOM、可访问性树或截图来理解页面，再模拟点击、输入、滚动等操作完成多步任务。它与 Selenium、Playwright 等传统自动化框架的关键区别在于「泛化能力」——后者依赖开发者预先写死的选择器和流程，页面一改版即失效；而智能体可以在运行时根据自然语言目标动态判断下一步动作，因此更适合结构不固定、没有开放 API 的网站。代价是执行路径不完全可复现，稳定性依赖模型能力与工程侧的容错设计（如重试、状态回滚、异常上报）。

rtrvr 托管云浏览器 指服务商在云端按需拉起隔离的浏览器实例执行任务，用户无需本地保持页面常开。它的价值在于支持定时、批量、并发运行，并能复用已登录的会话；但同时也把账号凭证、Cookie 等敏感数据交给第三方，隐私与合规风险需要用户自行评估。

性能对比：精度、速度与成本

Retriever 官方声称，在准确率上超过 OpenAI、Anthropic 和 Muse，速度是它们的 5 倍，成本仅为 1/300。这组数据是产品团队自报的独立结论，目前没有看到第三方基准测试的交叉验证，因此更适合作为了解产品定位的参考，而非定论。

从产品逻辑看，浏览器智能体的成本优势并不意外。如果绝大多数任务可以在客户端本地浏览器完成，云端的模型调用量就会显著下降；而当任务需要云端托管时，成本结构又取决于具体实现。1/300 这样的数字，很可能对应的是特定任务类型和特定对照模型，读者需要结合自己的使用场景来判断是否成立。

速度上的“5 倍”同样值得拆解。浏览器操作的核心瓶颈往往不是模型推理，而是页面加载、等待渲染、处理弹窗这类工程问题。一个针对浏览器场景做过优化的智能体，确实可能在这类端到端任务里跑赢通用模型。这也是 Retriever 强调“在网站之间完成工作”而不是单纯“回答问题”的原因。

关于基准测试：评估浏览器智能体通常使用 WebArena、WebVoyager、Mind2Web、GAIA 等公开基准，它们用真实网站上的多步任务来测量端到端成功率（task success rate）和步数效率。厂商自报的「准确率超过 X」「速度是 X 倍」往往基于内部选定的一组任务，任务分布、重试策略、是否允许人工兜底都会显著影响结果。看到这类数字时，应先确认三件事：评测任务集是否公开、失败后是否允许重试、对照组使用的是哪一档模型与版本。缺少这些前提，跨产品比较的意义有限。

免费策略背后的意图

Retriever 主打“免费”，这在浏览器智能体赛道里是一个明确的获客手段。同类产品大多按任务量或订阅收费，免费意味着团队需要用别的方式变现——可能是云浏览器的付费额度、企业级功能，或是后续的数据与平台服务。

对用户来说，免费降低了试用门槛，但也意味着需要留意免费额度的边界：本地运行是否完全不限次数？云浏览器是否按任务计费？这些问题在决定是否长期使用前值得确认。

从 Makers 信息看，该项目由 Arjun Chintapalli 等人打造，官网挂在 Product Hunt 跳转链接下。分类标签覆盖了 Chrome 扩展、生产力工具和人工智能，说明它既有插件形态，也有平台化的野心。

浏览器智能体的成本结构通常由三部分组成：模型推理 token（多轮决策累积）、浏览器运行时资源（CPU、内存、带宽）、以及外部服务调用（如邮箱发送、代理 IP）。本地运行时，推理可走用户自带 API Key 或开源小模型，厂商成本趋近于零；云托管运行时，厂商需要为每个并发会话预留浏览器进程，边际成本更高。这解释了为什么大多数同类产品把免费额度绑在本地模式上，而把云执行和批量并发放入付费层。判断一个「免费」产品能否持续，关键是看它把成本转嫁给了谁：是用户自己的算力，还是厂商用来换增长的补贴。

浏览器智能体的现实挑战

浏览器自动化并非新概念，从早年的 Selenium 到后来的 RPA，行业一直在尝试让机器替代人工点击。LLM 带来的变化在于，智能体可以理解非结构化的页面内容，从而适应那些没有 API、页面经常改版的网站。

但这套方案也有天然短板。网页结构随时可能变化，登录态、验证码、反爬机制都会打断任务流；涉及外联和简历投递的场景，还牵涉账号安全与平台条款合规。一个“免费且全能”的浏览器代理，实际可用性往往取决于它在这些边界情况下的鲁棒性，而这正是官方宣传中最难被简单数字概括的部分。

Retriever 把场景选在找线索、选创作者、投简历，恰好都是高频、重复、对精度要求中等的任务，这是相对务实的切入点。能否长期留住用户，要看它在真实网站的复杂环境里，是否比手动操作省下足够多的时间。

登录态与反自动化检测是浏览器智能体绕不开的工程难题。多数需要操作的任务都发生在登录后，而网站的会话维持依赖 Cookie、Local Storage 和指纹信息；智能体若在无头模式或被识别为自动化工具（User-Agent、WebDriver 标志、Canvas 指纹异常）下运行，容易触发验证码或直接封禁。常见缓解手段包括使用带持久化 Profile 的真实浏览器、模拟人类操作节奏、接入打码或人工接管流程。此外，自动发送外联邮件和批量投递简历可能触犯目标平台的服务条款（如 LinkedIn、Indeed 的自动化禁止条款），在实践中需要用户自行判断合规边界。