OpenClaw Zero Token 深度解析：浏览器自动化实现大模型免 Token 调用的原理与实战
快速摘要
OpenClaw Zero Token 是开源 AI 智能体框架 OpenClaw 的一个社区衍生版本，它的核心思路是：通过 Playwright 浏览器自动化技术，复用你在各大模型网页端的登录状态，从而绕过传统 API Token 调用的方式，实现对 DeepSeek、千问、Kimi、豆包等主流大模型的本地 Agent 调用。 整个方案采用 MIT 开源协议，项目在 GitHub 上已获得 1800+ Star。
从 OpenClaw 说起：为什么会出现 Zero Token 版本
2025 年底，奥地利开发者 Peter Steinberger 发布了一个名为 OpenClaw（早期叫 Clawdbot）的开源项目。这个项目迅速走红，不到三个月便登顶 GitHub Star 榜单，成为开源社区近年来最受关注的 AI Agent 框架之一。OpenClaw 的定位并不是一个简单的聊天机器人，而是一个可以拆解目标、调用工具、连续执行步骤的自主智能体——它能读写文件、运行脚本、对接外部应用，在获得目标后持续执行任务。很多开发者把使用 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 浏览器实例，捕获这些会话凭证，然后用程序模拟网页端发送消息的请求格式，直接与大模型平台进行交互。
从平台的角度看，这和你在网页上手动打字聊天没有区别——请求是从你的真实浏览器环境发出的，带着你的真实登录状态。
这里面有几个关键的技术环节值得深入了解：
Chrome DevTools Protocol（CDP） 是整个方案的底层基础。CDP 是 Chrome 浏览器内置的一套调试协议，允许外部程序通过 WebSocket 连接到浏览器，获取页面信息、操控页面行为、截取网络请求等。OpenClaw Zero Token 在启动时，会以调试模式（指定 --remote-debugging-port 参数）打开一个 Chrome 实例，然后通过 Playwright 的 connect_over_cdp 方法连接到这个实例。
具体的连接方式可以用一段伪代码来理解：
# 第一步：以调试模式启动 Chrome
chrome --remote-debugging-port=18892 --user-data-dir="你的数据目录"
# 此时 Chrome 在 18892 端口上暴露了 CDP 接口
# Playwright 可以通过这个端口连接并控制浏览器
// Playwright 连接已有的 Chrome 实例
const browser = await chromium.connectOverCDP('http://localhost:18892');
const context = browser.contexts()[0]; // 获取已有的浏览器上下文（包含登录状态）
会话凭证捕获 是第二个关键环节。当你在浏览器中登录各个大模型平台后，浏览器会保存 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 等），然后转发给下一层处理。
这种设计的好处在于，无论你是通过网页操作、命令行输入，还是通过 Telegram 机器人发消息，背后的处理逻辑都是统一的。
调度层（Scheduler Layer）
调度层是连接接入层和核心 Agent 层的中转站。它主要负责三件事：会话管理（维护对话上下文、记录模型类型和工具使用历史）、请求路由（根据用户选择的模型把请求分发给对应的大模型提供商适配器）、权限控制（限制可调用的工具类型和文件访问范围）。
比如你在 Web UI 上选择了 deepseek-web 模型，调度层就会把请求路由到 DeepSeek 的 Zero Token 提供商；如果你选择的是 openrouter 这样的传统 API 提供商，它则会走标准的 Token 调用链路。
核心 Agent 层（Core Agent Layer）
这是整个框架的"大脑"，负责 AI Agent 的核心能力——任务解析、工具调用和上下文管理。
当你向 Agent 发出一个自然语言指令（比如"帮我读取本地的 data.csv 文件并做一个统计分析"），任务解析器会结合系统提示词，引导大模型将这段话解析为结构化的工具调用指令。工具调用引擎随后执行对应的本地工具（如 read_file 读取文件），并将执行结果反馈给大模型。响应生成器再把大模型的回复和工具执行结果整合，返回给用户。
项目内置了多种本地工具：
exec—— 执行系统命令read_file/list_dir—— 文件读写和目录遍历browser—— 浏览器自动化操作apply_patch—— 代码补丁应用
值得注意的是，不同类型的模型提供商，工具调用的实现方式有所不同。对于国内的 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，仍然可以通过传统方式调用。
底层技术层（Infrastructure Layer）
底层技术层提供了整个框架运行所需的基础能力，包括：
浏览器自动化引擎，基于 Playwright + Chrome CDP 实现会话捕获和请求模拟。它会自动启动 Chrome 并开启调试模式，捕获用户登录后的全部认证信息，还可以模拟用户操作（如点击发送按钮、滚动对话框）。
凭证安全管理，将捕获的 Cookie、Token 等敏感信息加密存储在本地 .openclaw-zero-state 目录中，支持凭证过期后自动刷新。
反反爬适配，这是一个技术难点。很多大模型平台都有机器人检测机制，比如 Cloudflare 验证、动态参数校验等。Zero Token 通过 WASM SHA3 哈希计算来完成 PoW（Proof of Work）挑战，并动态生成各平台所需的反爬参数（如豆包的 a_bogus、fp 参数），从而模拟真实浏览器环境。
流式响应解析，基于 SSE（Server-Sent Events）协议，实时解析不同平台的流式数据格式，转换为标准化的文本流输出。
工具执行沙箱，为本地工具调用提供安全隔离，限制文件访问范围（仅限配置的工作目录）、系统命令权限（禁止高危命令），以及可选的网络请求限制。
目前支持的大模型平台
根据项目文档，以下平台已经过实际测试验证：
| 平台 | 标识 | 认证方式 | 备注 |
|---|---|---|---|
| DeepSeek | deepseek-web | 浏览器登录 | 需单独认证 |
| 千问（国际版） | qwen-web | 浏览器登录 | — |
| 千问（国内版） | qianwen-web | 浏览器登录 | 速度更快，支持深度搜索、代码助手 |
| Kimi | kimi-web | 浏览器登录 | — |
| 豆包 | doubao-web | 浏览器登录 | 深度适配，仅需两个 Cookie |
| ChatGPT | chatgpt-web | 浏览器登录 | — |
| Gemini | gemini-web | 浏览器登录 | — |
| Grok | grok-web | 浏览器登录 | — |
| 智谱清言 | glm-web | 浏览器登录 | — |
此外还兼容 OpenRouter 和 Ollama 等传统 API 调用方式。
关于豆包的适配值得多说几句。字节跳动的豆包平台在反爬机制上做得比较严格，需要处理 msToken、a_bogus、fp 等多个动态参数。Zero Token 项目对豆包做了深度优化：无需代理就能直接访问豆包官网，浏览器会自动生成这些动态参数，并且基于真实浏览器上下文发起请求，原生绕过 Cloudflare 验证。实际使用时，你只需要提供 sessionid 和 ttwid 两个 Cookie 就可以完成认证，流程非常简洁。
完整部署指南：从零开始搭建
环境准备
在开始之前，你需要确保本地环境满足以下条件：
- Node.js（建议 v22 或更高版本）
- pnpm 包管理器
- Chrome 浏览器（系统已安装）
- 操作系统支持 Linux、macOS 和 Windows（Windows 建议使用 WSL2）
可以在终端中快速检查：
node -v # 确认 Node.js 版本
pnpm -v # 确认 pnpm 已安装
如果你在国内网络环境下，建议先配置 npm 镜像源以加速依赖下载：
npm config set registry https://registry.npmmirror.com
第一步：克隆项目代码
git clone https://github.com/linuxhsj/openclaw-zero-token.git
cd openclaw-zero-token
第二步：安装依赖并构建
# 安装项目依赖
pnpm install
# 编译核心代码
pnpm build
# 构建 Web UI（如果需要通过浏览器操作）
pnpm ui:build
构建完成后，项目目录下会生成 dist 目录和 Web UI 产物。
第三步：启动浏览器调试模式
这一步至关重要。你需要运行项目提供的脚本，以调试模式启动一个 Chrome 实例：
./start-chrome-debug.sh
这个脚本实际上做的事情等价于：
chrome --remote-debugging-port=18892 --user-data-dir="项目指定的数据目录"
启动后，一个新的 Chrome 窗口会打开。请在这个窗口中手动登录你要使用的各个大模型平台。比如你要用千问、Kimi 和豆包，就分别在这个 Chrome 里打开对应网站并完成登录。
需要特别注意的是，DeepSeek 的认证流程与其他平台不同，需要在后续的 onboard 步骤中单独处理。
第四步：运行配置向导
登录完各平台后，运行配置向导：
./onboard.sh
配置向导会以交互式的方式引导你完成以下操作：
- 选择你要启用的平台提供商（如
doubao-web、kimi-web、qianwen-web等） - 自动从浏览器中捕获对应平台的登录凭证
- 将配置信息写入
.openclaw-zero-state/openclaw.json文件
对于 DeepSeek，你需要在 onboard 过程中选择 deepseek-web，向导会引导你在 Chrome 中登录 DeepSeek 并自动完成凭证捕获。DeepSeek 推荐使用自动登录模式（Automated Login），整个过程基本是全自动的。
第五步：检查配置文件
配置完成后，建议检查一下配置文件是否正确生成：
# 查看主配置文件
cat .openclaw-zero-state/openclaw.json
# 查看认证配置
cat .openclaw-zero-state/agents/main/agent/auth-profiles.json
特别需要确认 openclaw.json 中的 workspace 路径是否正确指向了你的工作目录：
{
"agents": {
"defaults": {
"workspace": "/home/你的用户名/Documents/openclaw-zero-token/.openclaw-zero-state/workspace"
}
}
}
第六步：启动服务
一切就绪后，启动 OpenClaw Zero Token 服务：
./server.sh start
服务启动后，你可以通过以下方式访问：
- Web UI 界面：浏览器访问 http://127.0.0.1:3001/
- CLI 命令行：直接在终端中与 Agent 交互
- Gateway API：通过 http://127.0.0.1:18789/ 发起兼容 OpenAI 格式的 API 请求
配置文件结构说明
项目的配置和状态信息集中存储在 .openclaw-zero-state 目录中：
.openclaw-zero-state/
├── openclaw.json # 主配置文件
└── agents/
└── main/
├── agent/
│ └── auth-profiles.json # 各平台认证凭证（敏感信息）
└── sessions/ # 会话记录
这个目录包含敏感信息，务必确保它已被添加到 .gitignore 中，不要提交到版本控制系统。项目默认会将该目录的权限设置为 700，仅限当前用户访问。
如果遇到配置问题，可以运行 Doctor 诊断命令：
# 诊断并自动修复常见问题
./server.sh doctor
Doctor 会检查 Sessions 目录是否存在、目录权限是否正确等常见问题，并自动修复。
实际使用中的注意事项
关于使用合规性
需要明确的是，OpenClaw Zero Token 的 Zero Token 模式本质上是在模拟浏览器操作，使用的是你自己账号的网页版额度。大多数大模型平台的网页版是有使用限制的（如每日对话次数上限），并且各平台的服务条款对自动化访问的态度不尽相同。在使用前，建议仔细阅读目标平台的服务协议，确保你的使用方式符合平台规则。
凭证有效期
浏览器会话凭证是有有效期的。如果你的 Cookie 过期了，Agent 的调用就会失败。遇到这种情况，只需要在调试模式的 Chrome 中重新登录对应平台，然后重新运行 ./onboard.sh 更新凭证即可。项目本身也支持凭证过期后的自动刷新机制，但具体效果取决于各平台的认证策略。
安全风险提醒
OpenClaw 作为一个能够执行系统命令、读写文件的 AI Agent 框架，天然存在一定的安全风险。项目虽然内置了工作目录隔离和命令权限限制，但仍然建议：
- 不要在生产环境或包含重要数据的机器上直接运行
- 仔细审查 Agent 生成的每一条系统命令再确认执行
- 限制 Agent 的文件访问范围到最小必要目录
- 不要安装来源不明的第三方 Skill（技能扩展）
之前有安全研究团队发现部分第三方 OpenClaw 技能存在数据窃取和提示词注入的风险，所以在技能安装这块需要格外谨慎。
网络环境
如果你在国内网络环境下，访问 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 回答同一个技术问题，然后对比它们的回答质量和角度差异。
这个功能在实际使用中有不少实用价值。举个例子，当你在做技术选型调研时，你可以用 AskOnce 向多个大模型同时提出相同的技术问题，快速获得多个视角的答案。不同模型的训练数据和推理风格有差异，交叉比对往往能发现单一模型容易遗漏的信息。
常见问题排查指南
在实际部署和使用过程中，你可能会遇到一些问题。这里总结了社区中出现频率较高的几类问题及其解决思路。
浏览器启动失败
如果运行 ./start-chrome-debug.sh 后 Chrome 没有正常启动，首先检查是否已有其他 Chrome 实例占用了调试端口。可以用以下命令确认：
# 检查 18892 端口是否已被占用
lsof -i :18892
# 或者在 Linux 上
netstat -tlnp | grep 18892
如果端口被占用，关闭占用的进程后重新启动即可。另外要确保你的 Chrome 浏览器路径是正确的，不同操作系统的 Chrome 可执行文件位置不同——macOS 通常在 /Applications/Google Chrome.app/Contents/MacOS/Google Chrome，Linux 通常在 /usr/bin/google-chrome 或 /usr/bin/chromium-browser。
凭证捕获失败
运行 ./onboard.sh 时如果提示认证失败，通常是因为你在 Chrome 调试实例中尚未完成对应平台的登录，或者登录状态已过期。解决方法很简单：切换到调试模式的 Chrome 窗口，确认你确实已经登录了目标平台，并且页面没有弹出重新登录的提示。登录成功后，重新执行 onboard 配置向导。
服务启动后模型列表为空
如果启动 ./server.sh start 后发现可用模型列表为空，很可能是 openclaw.json 配置文件没有正确生成。首先确认配置文件存在且不为空：
cat .openclaw-zero-state/openclaw.json
如果文件为空或不存在，可以手动从示例文件复制：
mkdir -p .openclaw-zero-state
cp .openclaw-state.example/openclaw.json .openclaw-zero-state/openclaw.json
然后重新运行 ./onboard.sh 完成平台配置。需要强调的是，只有在 onboard 中完成配置的平台才会出现在模型列表中。
对话过程中出现中断
如果在与 Agent 对话过程中突然出现请求失败或响应中断，常见的原因包括：平台的 Cookie 过期了、平台对请求频率进行了限制、或者平台的反爬策略发生了变更。遇到这种情况，可以依次尝试：重新登录平台并更新凭证、适当降低对话频率、检查项目的 GitHub Issues 页面看是否有相关的平台适配更新。
依赖安装问题
在国内网络环境下安装 npm 依赖可能会遇到超时或下载失败的问题。除了前面提到的配置 npmmirror 镜像源外，还可以尝试使用 cnpm 作为替代：
npm install -g cnpm --registry=https://registry.npmmirror.com
cnpm install
对于 Playwright 的浏览器驱动下载，可以设置专用的镜像地址：
PLAYWRIGHT_DOWNLOAD_HOST=https://npmmirror.com/mirrors/playwright npx playwright install chromium
技术原理补充：PoW 反爬挑战的实现
前面提到了 Zero Token 需要处理平台的反爬机制，这里展开说一下 PoW（Proof of Work）挑战的原理。
很多大模型平台（包括使用 Cloudflare 防护的平台）会在请求时要求客户端完成一个计算挑战，通常是找到一个满足特定条件的哈希值。比如要求你找到一个 nonce 值，使得 SHA3(challenge_string + nonce) 的结果以若干个零位开头。这类计算对浏览器来说只需要短暂的 CPU 时间，但可以有效区分真实浏览器和简单的脚本请求。
OpenClaw Zero Token 通过 WASM（WebAssembly）编译的 SHA3 算法来高效完成这些计算挑战。因为整个过程是在真实的浏览器环境中执行的，所以平台很难区分这是自动化程序还是人工操作。
从 Zero Token 看 OpenClaw 生态的演变
OpenClaw Zero Token 并不是 OpenClaw 生态中唯一的衍生项目。随着 OpenClaw 在 2026 年初的爆发式增长，社区围绕它衍生出了多个方向各异的框架和工具——有的追求功能极简、有的引入经济评估模型、有的将部署目标延伸到嵌入式设备。Zero Token 版本则聚焦于解决调用成本的问题，在保留原版 Agent 核心能力的同时，重构了大模型调用层。
值得关注的是，OpenClaw 的原作者 Peter Steinberger 已于 2026 年 2 月宣布加入 OpenAI，项目本身也计划转交给一个开源基金会维护。这意味着 OpenClaw 的未来发展将更多依赖社区力量。在中国，OpenClaw 的热度尤其高涨，从百度总部举办的"装虾"活动到腾讯推出的微信版集成方案，再到深圳龙岗区发布的产业支持政策征求意见稿，"养虾"已经从一个极客圈的玩法演变成了一个值得关注的技术趋势。
从技术视角来看，Zero Token 这种通过浏览器自动化复用网页登录态的方式，其实代表了一类更广泛的技术思路：在 API 化还不完善或成本较高的场景下，利用已有的 Web 端能力来构建自动化工作流。这种思路不仅适用于大模型调用，在很多需要与 Web 应用集成的自动化场景中都有参考价值。
写在最后
OpenClaw Zero Token 代表了一种有意思的技术方向：通过浏览器自动化桥接 AI Agent 框架和大模型网页端。它的核心价值不仅在于"免 Token"本身，更在于它展示了如何用 Playwright + CDP 这套技术栈来复用已有的网页登录状态，并将其整合进一个完整的 Agent 工作流中。
对于想要学习 AI Agent 架构设计、浏览器自动化技术，或者想在本地低成本跑起一套大模型驱动的智能体的开发者来说，这个项目很值得研究。它的五层架构设计、多平台适配机制、反爬对抗策略，都是实打实的工程实践。建议从阅读项目的 README 和 INSTALLATION.md 文档入手，然后动手跑通一个最简单的平台（比如千问国内版或 DeepSeek），在实际操作中加深对整体架构的理解。
当然，也要客观地看到，这种方案更适合学习研究和个人开发场景。对于生产环境下的高频稳定调用，传统的 API Token 方式仍然是更可靠的选择。同时也需要注意使用合规性，确保你的使用方式符合各平台的服务条款。
