OpenClaw Zero Token 深度解析:浏览器自动化实现大模型免 Token 调用的原理与实战
快速摘要
OpenClaw Zero Token 是开源 AI 智能体框架 OpenClaw 的一个社区衍生版本,它的核心思路是:通过 Playwright 浏览器自动化技术,复用你在各大模型网页端的登录状态,从而绕过传统 API Token 调用的方式,实现对 DeepSeek、千问、Kimi、豆包等主流大模型的本地 Agent 调用。 整个方案采用 MIT 开源协议,项目在 GitHub 上已获得 1800+ Star。如果你正在搭建本地 AI 智能体、或者对浏览器自动化与大模型结合的技术路线感兴趣,往下看有更详细的原理拆解和完整部署步骤。
从 OpenClaw 说起:为什么会出现 Zero Token 版本
2025 年底,奥地利开发者 Peter Steinberger 发布了一个名为 OpenClaw(早期叫 Clawdbot)的开源项目。这个项目迅速走红,不到三个月便登顶 GitHub Star 榜单,成为开源社区近年来最受关注的 AI Agent 框架之一。OpenClaw 的定位并不是一个简单的聊天机器人,而是一个可以拆解目标、调用工具、连续执行步骤的自主智能体——它能读写文件、运行脚本、对接外部应用,在获得目标后持续执行任务。
然而,原版 OpenClaw 在使用过程中有一个绕不开的问题:Token 消耗。AI 智能体的运行逻辑是不断地与大语言模型进行多轮对话,每一次任务拆解、工具调用、结果反馈都需要消耗 API Token。对于个人开发者和学习者来说,跑一个稍微复杂点的任务,API 调用费用就会快速累积。
OpenClaw Zero Token 正是为了解决这个痛点而诞生的。它是社区开发者基于 OpenClaw 的一个 Fork 版本,核心改动集中在大模型调用层——用浏览器自动化技术替代了传统的 API Token 调用,让你可以直接复用网页端的登录会话来与大模型交互。
技术原理深度拆解:Zero Token 到底怎么做到的
要理解 OpenClaw Zero Token 的工作原理,需要先搞清楚传统 API 调用和浏览器自动化调用之间的本质区别。
传统 API Token 调用的流程
当你通过 API 调用 DeepSeek 或 ChatGPT 时,流程大致是这样的:你的程序构造一个 HTTP 请求,带上 API Key 和对话内容,发送到模型提供商的服务器。服务器验证你的 API Key、扣除对应的 Token 额度,然后返回模型的回复。每一次请求都会计量 Token 数量并计费。
Zero Token 的浏览器自动化调用流程
而 Zero Token 方案的思路完全不同。它的核心逻辑是:你在浏览器里已经登录了 DeepSeek、千问这些平台的网页版,那么浏览器里已经保存了你的登录凭证(Cookie、Session Token 等)。OpenClaw Zero Token 通过 Playwright 浏览器自动化框架,连接到你已经登录的 Chrome 浏览器实例,捕获这些会话凭证,然后用程序模拟网页端发送消息的请求格式,直接与大模型平台进行交互。
会话凭证捕获 是第二个关键环节。当你在浏览器中登录各个大模型平台后,浏览器会保存 Cookie、Bearer Token、UserAgent 等认证信息。OpenClaw Zero Token 会自动从浏览器上下文中提取这些凭证,并加密保存在本地的 .openclaw-zero-state 目录中。后续的每次调用都会复用这些凭证,不需要重复登录。
请求格式模拟 是第三个关键环节。每个大模型平台的网页端 API 格式都不一样,比如 DeepSeek 的对话接口、千问的消息格式、豆包的自定义 SSE 字段,都需要单独适配。OpenClaw Zero Token 为每个平台编写了专属的"提供商适配器"(Provider),负责把统一的对话请求转换成对应平台的请求格式,并解析平台返回的流式响应。
五层架构设计:从接入到执行的完整链路
OpenClaw Zero Token 的架构设计分为五层,每一层的职责边界都很清晰。理解这个架构有助于你在实际使用和二次开发时快速定位问题。
接入层(Access Layer)
接入层负责提供用户与系统交互的入口。项目支持多种接入方式:基于 Lit 3.x 构建的 Web UI 可视化界面、CLI/TUI 命令行界面、兼容 OpenAI API 格式的 Gateway HTTP/WebSocket 网关,以及 Telegram 等第三方 IM 渠道。所有这些接入方式最终都会将用户输入转化为一个标准化的请求格式(包含用户输入内容、选择的模型标识、上下文 ID 等),然后转发给下一层处理。
值得注意的是,不同类型的模型提供商,工具调用的实现方式有所不同。对于国内的 Web 平台(DeepSeek、千问、Kimi、豆包等),工具调用是通过在系统提示词中内置工具描述,让大模型以 XML 格式的 <tool_call> 标签输出调用指令,然后由框架解析执行。而对于 OpenRouter、Ollama 这类原生支持 Function Calling 的平台,则直接使用其 tools/tool_calls API 接口。
大模型调用层(LLM Call Layer)
这是 Zero Token 版本改动最大的一层。它的核心职责是屏蔽不同大模型平台的调用差异,统一对外提供标准的 chat/completions 接口。
这一层有两类提供商:
Zero Token 提供商 是这个项目的核心创新点。每个 Web 平台都有一个专属的适配器,负责从浏览器自动化组件获取会话凭证、模拟平台 Web 端的请求格式发起对话、解析平台特有的流式响应格式。比如豆包的适配器需要处理 msToken、a_bogus 等动态反爬参数,Kimi 的适配器需要解析其独特的 JSON 流格式。
传统 Token 提供商 保留了原版 OpenClaw 的 API 调用能力,作为兜底方案。如果你有 OpenAI 或 Anthropic 的 API Key,仍然可以通过传统方式调用。
需要明确的是,OpenClaw Zero Token 的 Zero Token 模式本质上是在模拟浏览器操作,使用的是你自己账号的网页版额度。大多数大模型平台的网页版是有使用限制的(如每日对话次数上限),并且各平台的服务条款对自动化访问的态度不尽相同。在使用前,建议仔细阅读目标平台的服务协议,确保你的使用方式符合平台规则。
如果你在国内网络环境下,访问 ChatGPT、Gemini、Grok 等海外平台的网页版本身就需要特殊的网络配置。Zero Token 模式并不会帮你解决网络连通性的问题,它只是在网络可达的前提下,帮你免去 API Token 的使用。国内平台如 DeepSeek、千问国内版、Kimi、豆包、智谱清言等可以直接使用,无需额外网络配置。
与传统调用方式的对比
为了让你更直观地理解 Zero Token 模式与传统 API 调用的区别,这里做一个对比:
对比维度
传统 API Token 方式
Zero Token 浏览器自动化方式
认证方式
API Key + Token 计费
浏览器 Cookie / Session
调用入口
平台 API 接口
模拟网页端请求
是否需要付费密钥
是
否
使用限制
按 Token 计量
受网页版额度限制
响应速度
通常较快
取决于网页端响应
稳定性
较高
受平台反爬策略影响
Function Calling 支持
原生支持
需要 XML 标签模拟
适用场景
生产环境、高频调用
学习研究、本地开发
可以看到,Zero Token 模式在降低使用门槛方面有明显优势,但在稳定性和标准化程度上不如传统 API 方式。两种方式各有适用场景,项目也同时保留了对传统 API 调用的支持,你可以根据实际需求灵活切换。
AskOnce 功能:一次提问,多模型回答
OpenClaw Zero Token 还有一个有趣的功能叫 AskOnce。它允许你同时向多个已配置的 AI 模型发送同一个问题,一次输入就能获取各个模型的回复。这对于模型效果对比、答案交叉验证等场景非常实用。比如你可以同时让 DeepSeek、千问和 Kimi 回答同一个技术问题,然后对比它们的回答质量和角度差异。