你的 Agent 不必只停留在对话里。借助 AnySoul 的浏览器运行时，Agent 已经可以 打开标签页、读取页面、点击网页流程、填写表单、上传文件，并继续多步骤网页任务。

但现在有 两条不同的使用路径：

  • 网页端 + 浏览器扩展 —— 继续使用你当前浏览器和你现有的登录身份
  • 桌面端 —— 使用 AnySoul 桌面端浏览器运行时，获得当前最完整的浏览器能力面

真正重要的是：为你的任务选择正确的运行时。

这个用例在现实里是什么样

比如你让 Agent 帮你完成一个真实网页任务：

  • 打开某个网站
  • 搜索目标信息
  • 点进结果
  • 填写表单
  • 上传文件
  • 等待下一页
  • 提取最终结果

这已经不是概念，而是 AnySoul 目前真实支持的一类浏览器工作流。它依赖的是显式的结构化浏览器动作链。

两条运行时路径

运行时适合什么它实际使用什么
网页端 + 浏览器扩展在你平时使用的浏览器里继续操作你当前的浏览器标签页和当前浏览器身份
桌面端更强的浏览器工作流和当前最完整的能力面AnySoul 桌面端浏览器运行时

两条路径目前都能做什么

目前两条路径都支持这类显式浏览器工作流：

  • 打开和激活标签页
  • 导航、后退、前进、刷新
  • 读取页面并提取结构化数据
  • 滚动、聚焦、悬停、点击、双击、右键
  • 输入、粘贴、清空、复制文本
  • 设置勾选状态
  • 选择下拉框
  • 提交表单
  • 上传文件
  • 等待 selector、文本或 URL 变化

对于大量确定性的网页任务，这已经足够强大。

真正关键的差异在哪里

最大的差异在于 语义浏览动作。

浏览器扩展路径

扩展路径适合：

  • 你希望 Agent 在真实浏览器里继续操作
  • 你希望复用当前浏览器里已经登录的身份
  • 你的流程可以用显式结构化步骤表达

但扩展路径当前 不支持：

  • semantic_act
  • semantic_extract

所以它应该被理解成一个 显式动作优先的浏览器 Agent。

桌面端路径

桌面端路径适合：

  • 你想要当前最完整的浏览器能力面
  • 你想使用桌面端管理的浏览器运行时
  • 你的任务会受益于语义浏览动作

桌面端可以提供更强的语义浏览动作，但代价也很明确：

  • 它通常比显式动作更慢
  • 它通常消耗更多 token
  • 它在浏览器运行时之上又叠加了一层模型语义推理

所以即使在桌面端，最好的默认策略仍然是：

  • 先用显式动作
  • 只有当页面太难用 selector 表达时，再使用语义动作

一个实际例子

示例：填写真实网页表单

你让 Agent 帮你完成一个申请表、上传资料或提交网页内容。

在当前浏览器运行时下，Agent 可以：

  1. 打开目标页面
  2. 读取可见控件
  3. 聚焦正确的输入框
  4. 输入或粘贴内容
  5. 选择下拉选项
  6. 上传文件
  7. 提交表单
  8. 等待确认状态
  9. 提取最终结果

这正是 AnySoul 当前已经擅长的一类浏览器工作流。

该怎么选？

如果你符合这些情况，选 浏览器扩展：

  • 希望 Agent 在你当前浏览器里继续操作
  • 接受显式结构化网页流程
  • 不依赖语义浏览动作

如果你符合这些情况，选 桌面端：

  • 希望获得当前最完整的浏览器运行时
  • 想使用本地桌面浏览器运行时路径
  • 需要在可用时使用语义浏览动作

开始使用

相关内容