Hark预览浏览器Agent：AI替你点网页

Hark 把 AI 从“给答案”推向“做事情”

Hark 在 2026 年 8 月 5 日预览了一款浏览器操作 Agent，目标是让 AI 直接进入网页，替用户完成搜索、点击、填写和提交等多步骤任务。据 TechCrunch 当日报道，Hark 宣称这款产品比同类方案速度更快、成本更低，但截至目前，报道中没有给出足以横向复现的完整价格表、任务成功率或标准化延迟数据。

**浏览器操作 Agent 是一种能够理解网页状态、规划操作步骤，并通过点击、输入、滚动等动作完成任务的 AI 系统。**它与普通聊天机器人最直接的区别是：前者不只告诉你“该怎么做”，还会尝试真的把事情做完。

这类产品瞄准的是互联网服务里最顽固的一层摩擦。大量网站没有开放接口，即便提供接口，也未必覆盖用户真正需要的操作；企业内部系统则经常由老旧后台、复杂表单和多级审批组成。浏览器是人类访问这些服务的通用入口，如果 Agent 能稳定控制浏览器，它理论上也能触达几乎所有现存软件。

Hark 此次预览了什么

Hark 此次释放的核心信号不是“AI 能点击网页”，而是它试图把网页任务执行包装成速度和成本均可接受的产品。网页控制早已不是新能力，真正稀缺的是在复杂页面、长流程和动态环境中持续执行，而不是完成一次精心挑选的演示。

Hark 对外强调的两个卖点分别是更快和更便宜。速度决定用户是否愿意把 Agent 当作日常工具：如果一个人两分钟能完成的任务，Agent 要运行十分钟，它就很难进入高频场景；成本决定企业是否能批量部署：单次任务即使只多消耗几毛钱，扩展到每天数万次操作，也会成为明显负担。

Hark 目前更准确的产品状态仍是“预览”，而不是已经经过大规模生产验证的成熟服务。“预览”意味着产品方向和基本能力已经公开，但它的可用范围、稳定性、计费方式、权限边界以及失败后的处理机制，仍需要更多信息才能判断。

现阶段也不应把“更快、更便宜”直接理解成已经获胜。Hark 尚未公开统一测试集下的任务成功率、端到端完成时间、模型调用次数、Token 消耗、浏览器运行费用和人工接管比例，因此这一说法目前属于厂商主张，而不是可独立验证的行业结论。

浏览器 Agent 为什么容易又慢又贵

浏览器 Agent 的主要成本来自“观察—推理—操作—验证”的循环，而不是一次简单的模型问答。一个看似普通的购票任务，可能涉及识别搜索框、输入地点、选择日期、过滤班次、比较价格、登录账户、填写乘客信息和确认订单，每推进一步，Agent 都要重新判断页面发生了什么变化。

**决策循环是 Agent 在获取页面状态后选择动作、执行动作并检查结果的重复过程。**传统聊天通常只需要生成一次回复，浏览器任务却可能触发十几次甚至数十次循环；任何一步判断错误，都可能让后续操作建立在错误页面上。

页面状态的表达方式会直接决定模型开销。把完整 DOM、无障碍树或整张截图反复交给模型，会带来大量冗余上下文；只给模型少量元素摘要，又可能遗漏弹窗、错误提示、选中状态和页面布局等关键信息。系统需要在“看得全”和“看得便宜”之间做取舍。

**DOM 是浏览器用来表示网页结构、内容和元素关系的对象模型。**它对程序很精确，却不天然适合大模型阅读，因为真实网站的 DOM 往往夹杂样式容器、埋点节点、隐藏组件和自动生成的元素标识，原始内容可能比用户实际看到的页面复杂得多。

视觉理解同样不是免费的。截图路线更接近人类使用网页的方式，也能处理 Canvas、图片按钮和视觉化组件，但高分辨率图像会增加视觉模型的推理成本；页面滚动后还要重新截图，并判断新旧画面之间的关系。对于需要数十步的长任务，单步增加几秒延迟，最终都可能累积成分钟级等待。

Hark 如果确实能实现明显的速度和成本优势，最可能的突破点并不只是“换了一个更强的模型”。更现实的工程路线包括压缩页面状态、减少无效模型调用、用小模型处理简单动作、缓存稳定页面结构、并行完成部分信息提取，以及在确定性步骤中用规则替代开放式推理。不过，Hark 尚未完整披露底层技术方案，上述路径只能视为浏览器 Agent 的通用优化方向，不能当作其已经确认的实现细节。

它与传统自动化不是同一种产品

传统浏览器自动化依靠开发者提前写好操作脚本，而浏览器 Agent 依靠模型在运行时理解目标和页面。Playwright、Selenium 等工具擅长执行明确流程，例如打开固定地址、定位指定按钮、填写已知字段；Agent 则更适合页面结构未知、操作路径会变化，或只能用自然语言描述目标的任务。

**浏览器自动化框架是通过程序化指令控制浏览器导航、点击、输入和读取页面内容的工具。**这类框架的优势是确定、快速、容易测试，缺点是页面结构一变，选择器和脚本可能立即失效。

浏览器 Agent 并不会取代 Playwright 或 Selenium，反而通常需要建立在这些执行层之上。大模型负责决定“下一步做什么”，浏览器自动化框架负责可靠地执行点击和输入；前者是决策层，后者是执行层。把两者混为一谈，会高估模型本身对稳定性的贡献。

| 方案 | 核心定位 | 任务描述方式 | 速度与成本特征 | 主要优势 | 主要短板 | |---|---|---|---|---|---| | Hark 浏览器 Agent | 面向终端任务的网页执行产品 | 自然语言目标 | 官方宣称更快、更便宜，暂缺统一公开数字 | 强调端到端完成任务 | 公开基准、定价和权限细节仍不足 | | Browser Use | 开源通用浏览器 Agent 框架 | 自然语言目标与可扩展动作 | 取决于所选模型、浏览器环境和任务步数 | 开源、可定制、支持多模型 | 部署与稳定性治理需要开发者承担 | | Playwright / Selenium | 确定性浏览器自动化 | 预先编写脚本 | 固定流程通常更快、更可控 | 成熟、可测试、行为确定 | 页面变化后需要维护脚本 | | Nova Act 类方案 | 将复杂任务拆成较明确的操作步骤 | 分步指令或工作流 | 通过限制开放式决策提高可预测性 | 更适合受控企业流程 | 通用自主性相对有限 |

开源项目 Browser Use 展示了这一技术路线的典型形态：大模型负责规划，浏览器运行时负责执行，并通过工具动作扩展表单填写、信息提取和数据保存等能力。其官方 GitHub 仓库公开了框架代码和使用方式，这也给 Hark 之类闭源产品设定了一条清晰的比较线——闭源产品必须在成功率、速度、部署便利性或安全治理上提供足够明显的增量，才值得用户放弃自行组合开源组件。

真正的门槛是成功率，而不是会不会点击

浏览器 Agent 最容易制造误解的指标是单步操作准确率。假设一个 Agent 每一步操作的正确率达到 95%，看起来已经很高；但如果一个任务需要连续完成 20 个彼此依赖的步骤，在简单独立假设下，全部步骤一次成功的概率约为 35.8%，计算方式是 0.95 的 20 次方。

长任务会把微小错误放大成明显失败。一次错误点击可能只是打开了错误商品，也可能导致错误日期、错误收货地址或错误金额被带入最终确认页面。对用户而言，“完成了 19 步、最后一步出错”和“完全没完成”往往没有区别。

可靠的浏览器 Agent 因此必须具备验证和恢复能力。它需要检查页面标题、URL、按钮状态、表单回显和关键金额，确认动作确实生效；遇到加载失败、元素移动或登录过期时，还要判断是重试、回退、重新规划，还是请求用户接管。

**任务成功率是 Agent 在满足全部目标与约束的前提下完整完成任务的比例。**这个指标比“点击准确率”更接近真实体验，但仍需说明测试网站、任务长度、是否允许重试、是否人工纠错以及失败判定标准，否则不同厂商的数字无法直接比较。

Hark 接下来最需要公开的是一组可复现的端到端结果。一个有参考价值的测试至少应包含不同网站、登录态任务、动态页面、弹窗干扰、表单校验、跨标签页操作和失败恢复，并同时报告中位数与长尾延迟，而不是只展示最快的一次运行。

“更便宜”必须把整条成本链算进去

浏览器 Agent 的单次任务成本不等于模型生成价格。完整成本还包括浏览器实例、页面截图与视觉推理、模型多轮调用、代理运行时间、日志存储、验证码或身份验证处理，以及失败后重试和人工接管。

一个低价模型未必能带来更低的总成本。如果模型判断能力较弱，导致操作步数从 12 步增加到 25 步，并触发两次重试，最终费用和耗时都可能高于一次使用更强模型完成任务。企业真正关心的应该是“每个成功任务的成本”，而不是“每百万 Token 的价格”。

**每成功任务成本是总运行费用除以最终成功完成的任务数量。**这一指标把模型价格、浏览器资源、重试和失败率统一纳入计算，更适合衡量浏览器 Agent 的商业可行性。

Hark 的成本主张只有在这一口径下才有意义。若它只是降低单步推理费用，却没有减少失败和人工干预，优势会被迅速抵消；若它能用更少的决策轮次完成同一任务，并保持相近或更高的成功率，才算真正改善了 Agent 的单位经济模型。

安全边界比聊天机器人更重要

浏览器 Agent 获得的是实际操作权，因此它的错误成本远高于普通对话模型。聊天机器人给出错误建议，用户还有机会检查；浏览器 Agent 一旦被允许提交表单、发送消息、删除内容或确认购买，错误就会从文字层进入现实系统。

**提示注入是网页内容通过恶意或误导性指令影响 Agent 决策的攻击方式。**例如，页面中的隐藏文本可能要求 Agent 忽略用户目标、上传页面数据或跳转到钓鱼网站；如果系统没有区分“网页内容”和“可信指令”，模型可能把攻击内容当成操作命令。

敏感动作必须设置明确的人工确认点。涉及付款、发布公开内容、修改账户权限、下载可执行文件、发送邮件和删除数据时，产品至少应展示即将执行的动作、对象和影响范围，并要求用户确认，而不是只给一个笼统的“允许操作浏览器”授权。

权限控制也应该细化到网站、会话和动作级别。理想状态不是把整个浏览器账户永久交给 Agent，而是允许它在指定时间内访问特定站点，只执行搜索、读取或填写等被授权动作；Cookie、密码和支付信息则应由隔离的凭据系统管理，避免直接暴露给模型上下文。

Hark 是否能建立可信的权限体系，将比它在演示中快几秒更重要。个人用户可能愿意容忍偶发失败，但企业不会允许一个无法审计、无法回滚、权限范围不清晰的 Agent 接触生产后台。

哪些场景会最先落地

结构相对稳定、结果容易校验、错误可逆的任务最适合浏览器 Agent 率先落地。典型场景包括跨网站收集公开信息、录入非敏感表格、检查后台状态、执行重复性测试、整理商品参数和处理内部低风险工作流。

企业测试是浏览器 Agent 很现实的切入口。传统端到端测试需要工程师编写和维护脚本，而 Agent 可以根据高层目标探索页面、提取商品信息、加入购物车并核对金额；它不一定取代确定性测试，但可以更快发现未知路径和界面变化。

高风险消费决策不会最先实现全自动化。机票、酒店、金融交易和医疗服务看似最能体现价值，却同时涉及金额、身份、合规和不可逆后果，更合理的形态是 Agent 完成搜索、比较和填写，用户在最终提交前确认。

Hark 如果想快速证明产品价值，应该优先选择“步骤多但后果轻”的任务。让 Agent 自动整理 50 个网页的信息，失败一项可以重试；让它未经确认购买 50 件商品，即使成功率很高，也可能制造严重问题。

Hark 值得关注，但现在还不能下结论

Hark 的方向是对的，因为 AI 产品正在从信息生成转向环境执行。模型能力继续提升后，用户不会满足于得到一份操作指南，而会期待系统直接打开网站、处理流程，并在需要决策时把关键选项交回来。

Hark 的差异化仍需要数字证明。行业已经拥有 Browser Use 等开源框架，也有各类浏览器自动化和计算机操作 Agent；“能操作网页”本身不再构成壁垒，壁垒将转移到端到端成功率、平均完成时间、每成功任务成本、网站覆盖率、失败恢复和安全审计。

现阶段对 Hark 最准确的评价是：它抓住了浏览器 Agent 商业化的两个核心变量，但尚未给出足够证据证明自己解决了它们。更快和更便宜当然重要，不过在网页任务里，只有“更快、更便宜，而且确实完成正确”才有产品意义。

浏览器 Agent 的竞争也不会只是一场模型跑分。最终胜出的产品更可能是一套完整系统：它既能压缩页面信息、选择合适模型和控制浏览器，又能在关键步骤验证结果、限制权限、抵抗网页提示注入，并在失败时把问题清楚地交还给用户。

Hark 此次预览标志着一个更明确的趋势：AI 正从浏览器里的对话框，变成浏览器本身的操作者。下一阶段的关键问题已经不是 Agent 会不会点击，而是用户敢不敢让它点击“确认”。

参考来源

• Browser Use 官方 GitHub 仓库：开源浏览器 Agent 框架，可用于了解大模型规划、浏览器执行与可扩展动作的典型实现。