AnySoul 现在已经可以让你的 Agent 打开标签页、读取网页、点击页面流程、填写表单、上传文件、等待页面变化，并从网页中提取结果。

但这里有一个关键点：这是同一个浏览器产品能力，但有两条运行路径。

  • 网页端 + 浏览器扩展：让 Agent 继续在你当前使用的真实浏览器里工作，并复用你当前的登录身份
  • 桌面端 App：提供当前能力最完整的本地浏览器运行时，并在可用时支持语义浏览动作

这个区别很重要，因为它会直接影响你应该期待怎样的浏览器工作流。

这个浏览器运行时现在已经能做什么

今天的 AnySoul 已经支持一套有实用价值的显式浏览器动作：

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

这已经足以覆盖一大类确定性的网页任务：

  • 在多个标签页中检索信息
  • 填写并提交真实表单
  • 在浏览器流程里上传文件
  • 从搜索结果、列表页或仪表盘中提取结构化结果

一个产品，两条运行路径

运行路径适合场景实际使用什么语义动作
网页端 + 浏览器扩展在你日常使用的浏览器里继续完成任务你当前的浏览器标签页和当前登录身份不支持
桌面端 App使用当前能力最完整的浏览器工作流AnySoul 本地浏览器运行时，以及 App 窗口里的托管标签页支持，但取决于当前桌面目标是否暴露该能力

这两条路径都支持同一套显式结构化浏览器动作。

真正的区别出现在：当页面已经复杂到很难只靠 selector 清晰表达下一步的时候。

为什么扩展路径是“显式动作优先”

浏览器扩展路径的设计目标是：

  • 让 Agent 直接在你每天都在用的浏览器里工作
  • 复用你当前已经登录的网站身份
  • 在不离开你原本浏览器环境的前提下继续完成网页任务

这让它很适合处理这样的实际流程：

  1. 打开一个网站
  2. 点进某个结果
  3. 填一个输入框
  4. 上传一个文件
  5. 等待下一页加载
  6. 提取最终结果

但是，扩展路径目前不支持：

  • semantic_act
  • semantic_extract

所以最正确的理解应该是：

扩展路径是一个“显式动作型”的浏览器 Agent，而不是“语义动作型”的浏览器 Agent。

为什么桌面端是更强的一层

桌面端路径支持同样的显式动作，同时还能通过 Stagehand 暴露更丰富的语义浏览动作。

这意味着桌面端更适合：

  • 页面很难用稳定 selector 精准表达
  • 下一步更适合用自然语言描述
  • 你希望拿到当前最完整的浏览器能力面

例如：

  • “打开通知标签页”
  • “从这个仪表盘里提取关键账户摘要”
  • “继续这个页面流程，虽然布局很难直接定位”

语义动作更强，但也更重

语义动作很有用，但它不应该被当成每个任务的默认路线。

和显式动作相比，它通常：

  • 更慢
  • 更耗 token
  • 更依赖模型介入推理这一层

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

  1. 优先用显式动作
  2. 只有在页面太复杂、太混乱，不适合用 selector 驱动时，再使用语义动作

这也是为什么我们把桌面端描述成更强的一层，而不是默认基线体验。

一个真实可行的工作流

假设你想让 Agent 帮你完成一个网页任务：

  1. 打开目标页面
  2. 读取当前可见控件
  3. 填多个字段
  4. 选择下拉菜单
  5. 上传一份文件
  6. 提交表单
  7. 等待确认状态出现
  8. 提取最终结果

这类流程，AnySoul 今天已经可以很好地支持。

如果页面比较规整，那么两条运行路径都能通过显式动作完成。

如果页面异常复杂，而且你更希望用自然语言描述浏览器动作，那就更适合选择桌面端路径。

你应该选哪一条？

选择 网页端 + 浏览器扩展，如果你希望：

  • Agent 就在你当前浏览器里继续工作
  • 复用你当前浏览器身份
  • 任务可以表达成明确的结构化浏览器步骤

选择 桌面端 App，如果你希望：

  • 拿到当前最完整的浏览器运行时
  • 在 App 内使用托管浏览器标签页
  • 在可用时使用语义浏览动作

开始使用

重点不是抽象地选择“最强”的运行时，而是选择最适合你实际网页任务的那条路径。