1. 为什么需要 Browser Relay先聊聊浏览器的“手替”你让 OpenClaw 去知乎搜“人工智能”再总结热点它在内部并不是一次性吐出一份答案而是通过 Browser Relay 一步步执行openclaw browser open、type、click、snapshot。每执行一步大模型都要根据当前页面快照决定下一步做什么所以每一步都在消耗 Token。要保证这种长任务稳定跑完Key 用 TaoToken 是目前非常省事的方案打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 API Key然后在 OpenClaw 模型配置里把 Base URL 填成 https://taotoken.net/api剩下的浏览器控制指令就由它统一供给模型能力。过去的浏览器自动化基本靠脚本。写 Playwright 或 Puppeteer定位搜索框、按钮、列表项处理等待和重试再维护登录状态。页面结构一变选择器就失效遇到 JS 渲染、弹窗、验证码脚本基本要从头返工。更麻烦的是登录态。很多系统只认当前浏览器的 Cookie 和 Session脚本一旦脱离真实浏览器环境就要重新走一遍扫码、短信验证、企业 SSO 跳转。之前我维护过一批自动填写后台数据的脚本每个周三都要花半个多小时修选择器因为产品经理总喜欢在周一偷偷改按钮样式。Browser Relay 把这条链路换了个思路让 AI 自己看页面再决定操作。模型理解页面语义能处理很多结构变化不需要写死某个元素 ID。你只需要说“帮我去某某网站查个数据”“把这个表单填了”它会自己打开网站、识别输入框、点击提交、返回结果。从“写固定流程”变成“让模型看页面再判断”这是它能替代传统脚本的根本原因。1.1 传统浏览器自动化为什么脆弱传统自动化最大的问题不是“不会写”而是“写完了也撑不久”。页面上一个 class 名字变化选择器就挂了请求响应慢一点等待逻辑就超时页面从服务端渲染改成前端渲染整个脚本都要重写。再加上登录态这个隐形前提脚本换一台机器、换一个浏览器 profile 就全部失效。维护成本很快超过手工操作的耗时。AI 控制浏览器则绕开了这些细节。模型通过 ARIA 快照或截图理解页面它知道“搜索框大概在页面右上角”“这个蓝色按钮是提交”而不是依赖某个固定的 CSS 路径。页面改版后模型的判断仍然成立。这也是 OpenClaw 这类 Agent 工具更适合做临时性、轻量级自动化任务的原因它不需要为每个网站定制一套代码。但这里有一个容易被忽略的点AI 判断页面、决定点击哪里每一次都是真实的大模型调用。OpenClaw 属于多工具长会话 AgentBrowser Relay 是它连接浏览器扩展的 Harness。你说一句“去知乎查人工智能”内部实际会拆成很多步打开页面要调用一次模型分析页面结构输入关键词要再调用一次点击搜索后还要读取新页面快照继续分析。如果任务再复杂一点比如连续翻二十页、逐篇打开文章、提取正文再汇总Token 消耗会明显放大。1.2 长会话 Agent 的 Token 账本每一步浏览器操作都在调用模型很多人只看到 AI 操控浏览器很酷没留意它背后的成本结构。Browser Relay 的浏览器扩展本身不消耗 Token真正烧 Token 的是“决定下一步做什么”的推理过程。大模型需要把“帮我去知乎搜人工智能”这个自然语言目标实时转换成 open、type、click、snapshot 命令。每一条命令发出前模型都要结合任务上下文、当前 URL、页面快照做一次判断。长会话 Agent 会把整段对话历史一起送入模型上下文越积越长输入 Token 不断增长。这时候如果模型 Key 分散麻烦就来了。今天 A 供应商的额度不够明天 B 平台限流Browser Relay 可能刚好在“点击搜索”这一步停住任务就得中断重跑。统一接入的价值就在这里把一个长任务里所有浏览器操作背后的模型调用收口到一个 Key 下你不必在多个控制台之间来回切换。TaoToken 做的就是这种统一 API 兼容通道官网创建 Key、配置文件填 Base URL剩下的事交给通道去处理。2. 浏览器模式与扩展中继模式OpenClaw 怎么接管 Chrome2.1 三种模式一句话区分本文只讲 Extension RelayOpenClaw 的浏览器控制并不只有一种实现方式。不同模式的取舍点在于是启动一个全新的浏览器实例还是复用你正在用的 Chrome以及是否依赖桌面图形环境。官方一共提供了三种模式每一种对应不同的使用场景。这里不逐一展开重点写扩展中继模式Extension Relay因为它最贴近“我的 Chrome 里已经登录了知乎、飞书、企业后台想直接让 AI 接管”的真实需求。2.2 扩展中继的工作原理AI → 网关 → 扩展 → 浏览器扩展中继模式是让你现有的 Chrome 装一个扩展扩展通过 WebSocket 连到 OpenClaw 网关。完整链路是大模型先做出决策OpenClaw 把浏览器命令发给本地网关网关通过 WebSocket 转发给扩展扩展再调用 Chrome 的 API 打开页面、填写表单、点击按钮、读取快照。用户看到的是自然语言对话在 OpenClaw 日志里则是openclaw browser系列命令。这种方式最大的好处是复用当前浏览器的登录态、Cookie 和 Session。你不需要为自动化任务重新登录一遍也不用担心扫码验证、企业 SSO 跳转这些流程。浏览器里已有的代理设置、插件、企业内网访问权限也都跟着走这是独立浏览器实例做不到的。代价同样明显AI 理论上能访问你所有标签页所以这个模式适合本机自用不适合多人共享环境扩展一旦崩溃就需要重新加载截图、ARIA 快照这类高级能力还要额外配置。但对于“让 AI 去查资料、填表单、抓正文”这些日常操作它是体验最顺滑的一种模式。3. 配置 Browser Relay扩展、端口 18789 与模型 Key3.1 安装扩展并加载到 Chrome先安装扩展。OpenClaw 提供两条命令openclaw browser extension install openclaw browser extension path第一条命令把扩展生成到本机第二条命令输出扩展所在的目录。拿到路径后打开chrome://extensions在右上角打开“开发者模式”点击“加载已解压的扩展程序”选择第二条命令输出的目录。加载成功后Chrome 地址栏右侧会出现 OpenClaw 的扩展图标。这一步不涉及模型配置但它是后面所有浏览器操作的基础所以先确保扩展图标正常显示。3.2 配置扩展端口 18789 与配对 token点击扩展图标会看到端口和 token 两个输入项。端口默认是 18789没有改过就不用动。token 需要从 OpenClaw 本机配置里找执行cat ~/.openclaw/openclaw.json从输出中找到 pairingToken 或者类似名称的字段复制粘贴到扩展里。如果显示绿色提示说明扩展与网关已经连通如果显示感叹号说明还没配对成功。使用时先打开 Chrome随便开一个标签页再点地址栏右侧的扩展图标图标上出现on就表示浏览器已经就绪。这里要注意这个 token 是本地扩展与 OpenClaw 网关之间的配对凭证不是模型供应商发给你的 API Key。后面配置模型接入时用的 Key 是另一回事两个值不能填反。很多人在这里把~/.openclaw/openclaw.json里的配对 token 当成大模型 Key 填到页面里结果扩展显示已连接模型请求却一直失败。3.3 模型接入在 openclaw.json 里把模型指向 TaoToken扩展就绪后还要让 OpenClaw 知道用哪个模型来驱动这些浏览器操作。打开~/.openclaw/openclaw.json找到模型配置部分按下面的结构调整{ model: { provider: openai, name: YOUR_MODEL_ID, baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY } }其中YOUR_API_KEY在 TaoToken 创建YOUR_MODEL_ID以模型广场页面展示的模型 ID 为准不要随手抄一个网上流传的旧名字。关键的坑位在baseUrl这里只填 https://taotoken.net/api末尾不能加/v1也不需要拼任何路径。OpenClaw 发起浏览器操作时会把当前页面快照和任务上下文交给这个接口背后的模型模型返回的决策再由 Browser Relay 转成对浏览器的控制指令。如果你本机的openclaw.json里已经有模型配置不要整段替换只需要改model块里的baseUrl和apiKey以及确认name使用的是 TaoToken 模型广场里存在的 ID。保留原有的 provider 通道设置避免把 OpenClaw 其他功能也带崩。3.4 先用 taotoken cc 快速验证 Key 与模型 ID在写配置文件之前建议先花十秒验证 Key 是否有效。官方提供了一条命令行检查命令npm install -g taotoken/taotoken taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m YOUR_MODEL_ID执行后如果正常返回模型回复说明 Key、接口地址、模型 ID 三者能对上再把它填进openclaw.json。这样做能帮你把“配置写错”和“Key 本身有问题”两类原因分开。终端里跑通之后再去启动 OpenClaw 跑浏览器任务排障会轻松很多。4. 踩坑记录pairing required1008与配对机制4.1 报错现象与报错文本扩展配置完成后最常见的失败是网关连不上或者浏览器能打开但页面不受控制。执行openclaw gateway status会看到类似下面的文本gateway connect failed: pairing required Error: gateway closed (1008): pairing required Gateway target: ws://127.0.0.1:18789关键词是pairing required意思是“需要配对”。如果你在配好模型接入之后遇到这个错误先不要怀疑 Key 出了问题问题通常出在 OpenClaw 的本地设备授权状态上。浏览器打开正常、扩展也能加载但 OpenClaw 拒绝接受来自扩展的连接因为设备身份没有通过授权。4.2 为什么 OpenClaw 强制配对OpenClaw 采用类似蓝牙的配对机制。原因是浏览器里存着大量 Cookie、登录态和个人数据如果任何进程都能自由连接127.0.0.1:18789那么电脑上的恶意软件也能偷偷控制浏览器读取这些数据。为了堵住这条路OpenClaw 要求每个客户端在连接网关前必须经过一次显式配对授权。这也意味着一旦本机身份文件异常或被清理扩展就会立刻失去控制权限。这不是 TaoToken 或模型配置引起的而是 OpenClaw 自身的安全机制。4.3 重置配对gateway stop、删除 identity 与 devices、重新授权处理方式是按顺序重置本地配对状态openclaw gateway stop rm -rf ~/.openclaw/identity/ ~/.openclaw/devices/ openclaw gateway start openclaw browser --browser-profile chrome tabs第一行停掉网关第二行删除旧的设备身份和客户端授权记录第三行重启网关第四行执行一次真实浏览器操作触发重新配对。执行到最后一步时OpenClaw 会授予默认权限扩展图标会从感叹号变回on。注意删除identity和devices目录后所有已授权客户端都需要重新配对所以扩展里的 token 如果显示失效就重新从openclaw.json复制一次再粘贴进去。如果重置之后依然连不上再回头检查openclaw.json里baseUrl有没有被写成https://taotoken.net/api/v1。多一个/v1不影响扩展配对但会让模型请求返回 404 或路由错误而这类错误在gateway status里不会立刻暴露。5. 实战案例让 OpenClaw 去知乎查“人工智能”并总结5.1 需求描述与耗时变化假设现在要收集知乎上关于“人工智能”的热门观点。以前的做法是打开浏览器、进入搜索页、输入关键词、看结果列表、逐篇翻正文再手动整理整个过程 30 到 60 分钟属于正常。现在只需要对 OpenClaw 说一句“帮我去知乎搜索‘人工智能’总结一下热门文章的核心观点”。OpenClaw 会自己规划打开知乎、输入关键词、点击搜索、读取页面快照、提取正文、生成总结。整套流程通常能在两三分钟内完成。真正有价值的地方在于它不需要预先写任何选择器。页面结构变了模型会根据快照重新判断搜索框和按钮在哪里。登录状态也沿用当前 Chrome 的知乎 Cookie不需要重新扫码或输密码。对于一个长会话 Agent 来说这种临时性、轻量级的自动化任务正好是 Browser Relay 的主场。5.2 实际执行的命令流如果打开 OpenClaw 的命令日志你会看到类似下面这段内部执行流openclaw browser open https://www.zhihu.com openclaw browser type e5 人工智能 openclaw browser click e8 openclaw browser snapshot openclaw browser texte5和e8并不是写死的 ID而是 AI 从页面快照里识别出来的搜索框和搜索按钮引用。每次页面不同引用也可能不同。模型需要先理解快照内容再决定往哪个元素输入、点哪个按钮。这就是前面说的 Token 成本来源open之后要分析一次页面type之后要确认输入结果click之后还要再看快照判断是否跳转。整个链路跑下来浏览器控制指令由扩展执行模型能力则由统一接入的接口供给不再需要为 OpenClaw 单独准备多套供应商配置。5.3 跑完去 TaoToken 看这次任务的调用量任务结束后可以打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 查看本次 Browser Relay 任务的调用记录。重点看两件事一是 Token 消耗是否符合预期。长任务中频繁snapshot会放大输入 Token第一次跑完你就能直观感受到“让 AI 看一眼页面”到底要花多少钱。二是确认请求是否都打到了正确的模型上。如果某个步骤返回异常从调用记录里能看出是模型超时、参数问题还是接口地址写错不用一头扎进浏览器扩展的日志里找原因。如果你还没创建 Key现在就去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册创建一个新的 API Key再回到openclaw.json里核对baseUrl和model配置。全部就绪后把上面的知乎命令流跑一遍你会在 Chrome 地址栏右侧看到扩展亮起on然后看着 AI 自己完成搜索、翻页、总结。第一次跑完记得回 Taotoken 用量页看这次任务的实际 Token 消耗。到这里OpenClaw 跑 Browser Relay 任务的完整链路就通了浏览器归扩展管模型归统一接口管你只需要维护一个 Key。
OpenClaw 跑 Browser Relay 任务：Key 用 TaoToken
1. 为什么需要 Browser Relay先聊聊浏览器的“手替”你让 OpenClaw 去知乎搜“人工智能”再总结热点它在内部并不是一次性吐出一份答案而是通过 Browser Relay 一步步执行openclaw browser open、type、click、snapshot。每执行一步大模型都要根据当前页面快照决定下一步做什么所以每一步都在消耗 Token。要保证这种长任务稳定跑完Key 用 TaoToken 是目前非常省事的方案打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 API Key然后在 OpenClaw 模型配置里把 Base URL 填成 https://taotoken.net/api剩下的浏览器控制指令就由它统一供给模型能力。过去的浏览器自动化基本靠脚本。写 Playwright 或 Puppeteer定位搜索框、按钮、列表项处理等待和重试再维护登录状态。页面结构一变选择器就失效遇到 JS 渲染、弹窗、验证码脚本基本要从头返工。更麻烦的是登录态。很多系统只认当前浏览器的 Cookie 和 Session脚本一旦脱离真实浏览器环境就要重新走一遍扫码、短信验证、企业 SSO 跳转。之前我维护过一批自动填写后台数据的脚本每个周三都要花半个多小时修选择器因为产品经理总喜欢在周一偷偷改按钮样式。Browser Relay 把这条链路换了个思路让 AI 自己看页面再决定操作。模型理解页面语义能处理很多结构变化不需要写死某个元素 ID。你只需要说“帮我去某某网站查个数据”“把这个表单填了”它会自己打开网站、识别输入框、点击提交、返回结果。从“写固定流程”变成“让模型看页面再判断”这是它能替代传统脚本的根本原因。1.1 传统浏览器自动化为什么脆弱传统自动化最大的问题不是“不会写”而是“写完了也撑不久”。页面上一个 class 名字变化选择器就挂了请求响应慢一点等待逻辑就超时页面从服务端渲染改成前端渲染整个脚本都要重写。再加上登录态这个隐形前提脚本换一台机器、换一个浏览器 profile 就全部失效。维护成本很快超过手工操作的耗时。AI 控制浏览器则绕开了这些细节。模型通过 ARIA 快照或截图理解页面它知道“搜索框大概在页面右上角”“这个蓝色按钮是提交”而不是依赖某个固定的 CSS 路径。页面改版后模型的判断仍然成立。这也是 OpenClaw 这类 Agent 工具更适合做临时性、轻量级自动化任务的原因它不需要为每个网站定制一套代码。但这里有一个容易被忽略的点AI 判断页面、决定点击哪里每一次都是真实的大模型调用。OpenClaw 属于多工具长会话 AgentBrowser Relay 是它连接浏览器扩展的 Harness。你说一句“去知乎查人工智能”内部实际会拆成很多步打开页面要调用一次模型分析页面结构输入关键词要再调用一次点击搜索后还要读取新页面快照继续分析。如果任务再复杂一点比如连续翻二十页、逐篇打开文章、提取正文再汇总Token 消耗会明显放大。1.2 长会话 Agent 的 Token 账本每一步浏览器操作都在调用模型很多人只看到 AI 操控浏览器很酷没留意它背后的成本结构。Browser Relay 的浏览器扩展本身不消耗 Token真正烧 Token 的是“决定下一步做什么”的推理过程。大模型需要把“帮我去知乎搜人工智能”这个自然语言目标实时转换成 open、type、click、snapshot 命令。每一条命令发出前模型都要结合任务上下文、当前 URL、页面快照做一次判断。长会话 Agent 会把整段对话历史一起送入模型上下文越积越长输入 Token 不断增长。这时候如果模型 Key 分散麻烦就来了。今天 A 供应商的额度不够明天 B 平台限流Browser Relay 可能刚好在“点击搜索”这一步停住任务就得中断重跑。统一接入的价值就在这里把一个长任务里所有浏览器操作背后的模型调用收口到一个 Key 下你不必在多个控制台之间来回切换。TaoToken 做的就是这种统一 API 兼容通道官网创建 Key、配置文件填 Base URL剩下的事交给通道去处理。2. 浏览器模式与扩展中继模式OpenClaw 怎么接管 Chrome2.1 三种模式一句话区分本文只讲 Extension RelayOpenClaw 的浏览器控制并不只有一种实现方式。不同模式的取舍点在于是启动一个全新的浏览器实例还是复用你正在用的 Chrome以及是否依赖桌面图形环境。官方一共提供了三种模式每一种对应不同的使用场景。这里不逐一展开重点写扩展中继模式Extension Relay因为它最贴近“我的 Chrome 里已经登录了知乎、飞书、企业后台想直接让 AI 接管”的真实需求。2.2 扩展中继的工作原理AI → 网关 → 扩展 → 浏览器扩展中继模式是让你现有的 Chrome 装一个扩展扩展通过 WebSocket 连到 OpenClaw 网关。完整链路是大模型先做出决策OpenClaw 把浏览器命令发给本地网关网关通过 WebSocket 转发给扩展扩展再调用 Chrome 的 API 打开页面、填写表单、点击按钮、读取快照。用户看到的是自然语言对话在 OpenClaw 日志里则是openclaw browser系列命令。这种方式最大的好处是复用当前浏览器的登录态、Cookie 和 Session。你不需要为自动化任务重新登录一遍也不用担心扫码验证、企业 SSO 跳转这些流程。浏览器里已有的代理设置、插件、企业内网访问权限也都跟着走这是独立浏览器实例做不到的。代价同样明显AI 理论上能访问你所有标签页所以这个模式适合本机自用不适合多人共享环境扩展一旦崩溃就需要重新加载截图、ARIA 快照这类高级能力还要额外配置。但对于“让 AI 去查资料、填表单、抓正文”这些日常操作它是体验最顺滑的一种模式。3. 配置 Browser Relay扩展、端口 18789 与模型 Key3.1 安装扩展并加载到 Chrome先安装扩展。OpenClaw 提供两条命令openclaw browser extension install openclaw browser extension path第一条命令把扩展生成到本机第二条命令输出扩展所在的目录。拿到路径后打开chrome://extensions在右上角打开“开发者模式”点击“加载已解压的扩展程序”选择第二条命令输出的目录。加载成功后Chrome 地址栏右侧会出现 OpenClaw 的扩展图标。这一步不涉及模型配置但它是后面所有浏览器操作的基础所以先确保扩展图标正常显示。3.2 配置扩展端口 18789 与配对 token点击扩展图标会看到端口和 token 两个输入项。端口默认是 18789没有改过就不用动。token 需要从 OpenClaw 本机配置里找执行cat ~/.openclaw/openclaw.json从输出中找到 pairingToken 或者类似名称的字段复制粘贴到扩展里。如果显示绿色提示说明扩展与网关已经连通如果显示感叹号说明还没配对成功。使用时先打开 Chrome随便开一个标签页再点地址栏右侧的扩展图标图标上出现on就表示浏览器已经就绪。这里要注意这个 token 是本地扩展与 OpenClaw 网关之间的配对凭证不是模型供应商发给你的 API Key。后面配置模型接入时用的 Key 是另一回事两个值不能填反。很多人在这里把~/.openclaw/openclaw.json里的配对 token 当成大模型 Key 填到页面里结果扩展显示已连接模型请求却一直失败。3.3 模型接入在 openclaw.json 里把模型指向 TaoToken扩展就绪后还要让 OpenClaw 知道用哪个模型来驱动这些浏览器操作。打开~/.openclaw/openclaw.json找到模型配置部分按下面的结构调整{ model: { provider: openai, name: YOUR_MODEL_ID, baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY } }其中YOUR_API_KEY在 TaoToken 创建YOUR_MODEL_ID以模型广场页面展示的模型 ID 为准不要随手抄一个网上流传的旧名字。关键的坑位在baseUrl这里只填 https://taotoken.net/api末尾不能加/v1也不需要拼任何路径。OpenClaw 发起浏览器操作时会把当前页面快照和任务上下文交给这个接口背后的模型模型返回的决策再由 Browser Relay 转成对浏览器的控制指令。如果你本机的openclaw.json里已经有模型配置不要整段替换只需要改model块里的baseUrl和apiKey以及确认name使用的是 TaoToken 模型广场里存在的 ID。保留原有的 provider 通道设置避免把 OpenClaw 其他功能也带崩。3.4 先用 taotoken cc 快速验证 Key 与模型 ID在写配置文件之前建议先花十秒验证 Key 是否有效。官方提供了一条命令行检查命令npm install -g taotoken/taotoken taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m YOUR_MODEL_ID执行后如果正常返回模型回复说明 Key、接口地址、模型 ID 三者能对上再把它填进openclaw.json。这样做能帮你把“配置写错”和“Key 本身有问题”两类原因分开。终端里跑通之后再去启动 OpenClaw 跑浏览器任务排障会轻松很多。4. 踩坑记录pairing required1008与配对机制4.1 报错现象与报错文本扩展配置完成后最常见的失败是网关连不上或者浏览器能打开但页面不受控制。执行openclaw gateway status会看到类似下面的文本gateway connect failed: pairing required Error: gateway closed (1008): pairing required Gateway target: ws://127.0.0.1:18789关键词是pairing required意思是“需要配对”。如果你在配好模型接入之后遇到这个错误先不要怀疑 Key 出了问题问题通常出在 OpenClaw 的本地设备授权状态上。浏览器打开正常、扩展也能加载但 OpenClaw 拒绝接受来自扩展的连接因为设备身份没有通过授权。4.2 为什么 OpenClaw 强制配对OpenClaw 采用类似蓝牙的配对机制。原因是浏览器里存着大量 Cookie、登录态和个人数据如果任何进程都能自由连接127.0.0.1:18789那么电脑上的恶意软件也能偷偷控制浏览器读取这些数据。为了堵住这条路OpenClaw 要求每个客户端在连接网关前必须经过一次显式配对授权。这也意味着一旦本机身份文件异常或被清理扩展就会立刻失去控制权限。这不是 TaoToken 或模型配置引起的而是 OpenClaw 自身的安全机制。4.3 重置配对gateway stop、删除 identity 与 devices、重新授权处理方式是按顺序重置本地配对状态openclaw gateway stop rm -rf ~/.openclaw/identity/ ~/.openclaw/devices/ openclaw gateway start openclaw browser --browser-profile chrome tabs第一行停掉网关第二行删除旧的设备身份和客户端授权记录第三行重启网关第四行执行一次真实浏览器操作触发重新配对。执行到最后一步时OpenClaw 会授予默认权限扩展图标会从感叹号变回on。注意删除identity和devices目录后所有已授权客户端都需要重新配对所以扩展里的 token 如果显示失效就重新从openclaw.json复制一次再粘贴进去。如果重置之后依然连不上再回头检查openclaw.json里baseUrl有没有被写成https://taotoken.net/api/v1。多一个/v1不影响扩展配对但会让模型请求返回 404 或路由错误而这类错误在gateway status里不会立刻暴露。5. 实战案例让 OpenClaw 去知乎查“人工智能”并总结5.1 需求描述与耗时变化假设现在要收集知乎上关于“人工智能”的热门观点。以前的做法是打开浏览器、进入搜索页、输入关键词、看结果列表、逐篇翻正文再手动整理整个过程 30 到 60 分钟属于正常。现在只需要对 OpenClaw 说一句“帮我去知乎搜索‘人工智能’总结一下热门文章的核心观点”。OpenClaw 会自己规划打开知乎、输入关键词、点击搜索、读取页面快照、提取正文、生成总结。整套流程通常能在两三分钟内完成。真正有价值的地方在于它不需要预先写任何选择器。页面结构变了模型会根据快照重新判断搜索框和按钮在哪里。登录状态也沿用当前 Chrome 的知乎 Cookie不需要重新扫码或输密码。对于一个长会话 Agent 来说这种临时性、轻量级的自动化任务正好是 Browser Relay 的主场。5.2 实际执行的命令流如果打开 OpenClaw 的命令日志你会看到类似下面这段内部执行流openclaw browser open https://www.zhihu.com openclaw browser type e5 人工智能 openclaw browser click e8 openclaw browser snapshot openclaw browser texte5和e8并不是写死的 ID而是 AI 从页面快照里识别出来的搜索框和搜索按钮引用。每次页面不同引用也可能不同。模型需要先理解快照内容再决定往哪个元素输入、点哪个按钮。这就是前面说的 Token 成本来源open之后要分析一次页面type之后要确认输入结果click之后还要再看快照判断是否跳转。整个链路跑下来浏览器控制指令由扩展执行模型能力则由统一接入的接口供给不再需要为 OpenClaw 单独准备多套供应商配置。5.3 跑完去 TaoToken 看这次任务的调用量任务结束后可以打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 查看本次 Browser Relay 任务的调用记录。重点看两件事一是 Token 消耗是否符合预期。长任务中频繁snapshot会放大输入 Token第一次跑完你就能直观感受到“让 AI 看一眼页面”到底要花多少钱。二是确认请求是否都打到了正确的模型上。如果某个步骤返回异常从调用记录里能看出是模型超时、参数问题还是接口地址写错不用一头扎进浏览器扩展的日志里找原因。如果你还没创建 Key现在就去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册创建一个新的 API Key再回到openclaw.json里核对baseUrl和model配置。全部就绪后把上面的知乎命令流跑一遍你会在 Chrome 地址栏右侧看到扩展亮起on然后看着 AI 自己完成搜索、翻页、总结。第一次跑完记得回 Taotoken 用量页看这次任务的实际 Token 消耗。到这里OpenClaw 跑 Browser Relay 任务的完整链路就通了浏览器归扩展管模型归统一接口管你只需要维护一个 Key。
