OpenClaw Zero Token 深度解析：浏览器自动化实现大模型免 API 调用的完整技术指南

快速摘要
OpenClaw Zero Token 是开源 AI 智能体框架 OpenClaw 的一个社区分支版本，它通过 Playwright 浏览器自动化 + Chrome CDP 协议，捕获用户在网页端的登录凭证（Cookie、Session Token 等），从而模拟网页端请求格式向大模型平台发起对话——整个过程无需购买任何 API 密钥。 简单来说，只要你能在浏览器里正常登录使用 DeepSeek、Kimi、豆包、千问等平台，这套工具就能把你的"网页聊天体验"变成可编程的 AI Agent 调用接口。它目前支持十余个主流大模型平台，采用 MIT 开源协议，适合个人开发者和技术爱好者进行本地化 AI 智能体实验。往下看，莫潇羽@无忆研习社 将为你详细拆解它的技术原理、架构设计和完整部署流程。

一、先搞清楚背景：OpenClaw 是什么？

在正式聊 Zero Token 之前，我们需要先理解 OpenClaw 本身是个什么项目。

OpenClaw（曾用名 Clawdbot、Moltbot）是由奥地利开发者 Peter Steinberger（PSPDFKit 创始人）创建的开源个人 AI 智能体框架。它的核心定位不是一个大模型，而是一个"AI 网关"——负责连接你的聊天工具（飞书、Telegram、Discord、微信等）和各种大模型 API，让 AI 能力无缝融入日常工作流。

与传统的 AI 聊天机器人不同，OpenClaw 强调"动作导向"设计。它不只是回答问题，而是能真正帮你执行任务：运行 Shell 命令、读写本地文件、操控浏览器、管理日历和邮件等。用一句话概括，OpenClaw 就是给 AI 装上了"手"和"脚"，从"对话式交互"升级为"行动式交互"。

这个项目在 2026 年初引起了极大的关注。它在 GitHub 上的星标数一度飙升到 18 万以上，创下了 GitHub 历史上增长最快的开源项目之一的纪录，单日最高新增超过 17,000 颗星标。国内开发者社区亲切地称其为"龙虾"（因为其吉祥物是一只小龙虾 Molty），各大云厂商也纷纷跟进推出了一键部署方案——腾讯云上线了极速部署服务，阿里云提供了轻量应用服务器方案，甚至连地方政府都出台了支持政策。OpenClaw 的火爆甚至间接带动了苹果 Mac mini M4 的销量，因为这款设备被认为是性价比最高的本地 AI Agent 运行平台之一。

值得一提的是，OpenClaw 的命名经历了一段曲折的故事。项目最初叫 Clawdbot（Claw + bot，"爪子机器人"），但在 2026 年 1 月 27 日，Anthropic 公司发出律师函，认为"Clawd"与其 AI 产品"Claude"的名称过于相似。项目随即更名为 Moltbot（Molt 意为"蜕皮"，寓意龙虾蜕壳新生），三天后再次更名为 OpenClaw 并沿用至今。2026 年 2 月 15 日，创始人 Peter Steinberger 宣布加入 OpenAI，OpenClaw 项目则过渡为由开源基金会托管的社区项目，这一举措在一定程度上增强了项目的长期独立性和可持续性。

从技术实现上看，OpenClaw 的核心是一个基于 TypeScript 编写的命令行应用。它采用以网关为中心的分布式架构，将通信渠道（Telegram、飞书、Discord 等）、智能体逻辑（任务解析、工具调用）和大模型调用解耦成独立的模块。网关进程是一个基于 Node.js v22+ 构建的长运行守护进程，负责在不同终端之间同步消息、维护统一的会话上下文。这意味着你可以在飞书里开始一段对话，然后切换到 Telegram 继续——AI 能记得你之前说的所有内容，跨平台无缝衔接。

在生态方面，OpenClaw 拥有一个叫做 ClawHub 的技能市场，社区已经贡献了数千个技能插件，覆盖了邮件管理、日历调度、GitHub 工作流自动化、PDF 处理、智能家居控制等各种实用场景。技能的开发门槛很低——一个 SKILL.md 描述文件加上几个执行脚本就能创建一个完整的技能包，一条命令即可安装，不用修改核心代码就能扩展智能体的能力边界。这种插件化的设计是 OpenClaw 能迅速建立开发者生态的关键因素之一。

它的记忆系统也颇有看点：采用 BM25 全文搜索与向量嵌入的混合检索方案，所有记忆数据以 Markdown 格式存储在本地文件系统中。当对话接近上下文长度限制时，系统会自动将关键信息提取到长期记忆中，对会话历史进行分段摘要压缩，用摘要替换原始消息以释放上下文空间。这让 AI Agent 在长期使用中会"越来越了解你"，形成个性化的交互体验。

了解了这些背景之后，我们就能更好地理解 Zero Token 版本的意义了。原版 OpenClaw 有一个绕不开的问题：它需要你提供大模型的 API 密钥才能运行。无论是调用 Claude、GPT-4 还是 DeepSeek，你都得先去对应平台申请 API Key 并按 Token 量付费。对于频繁调用、长上下文交互的 Agent 场景来说，Token 消耗量是相当可观的。尤其是在 Agent 模式下，一次复杂任务可能涉及多轮对话加上工具调用的中间结果传递，实际 Token 用量远超简单的一问一答。

这就是 OpenClaw Zero Token 这个分支项目诞生的背景——它想解决的核心问题只有一个：能不能不买 API Key，直接复用网页端的免费登录状态来跑 AI Agent？

二、Zero Token 的核心原理：浏览器自动化 + 会话凭证捕获

要理解 OpenClaw Zero Token 的运作方式，我们需要先搞清楚"传统 API 调用"和"网页端调用"有什么本质区别。

2.1 传统 API 调用 vs. 网页端调用

当你在 DeepSeek 的网页上和 AI 聊天时，你的浏览器做了什么？本质上，浏览器向 DeepSeek 的后端服务器发送了一个 HTTP 请求，这个请求里携带着你登录后获得的 Cookie 和 Session Token 作为身份凭证。服务器验证凭证后，把 AI 的回复以流式数据（通常是 SSE 格式）推送回来。

而传统的 API 调用则是另一条路径：你用一个专门的 API Key（通常是一串很长的密钥字符串），通过标准化的 API 接口（比如 OpenAI 的 /v1/chat/completions）发送请求。服务器根据 API Key 识别你的身份和额度，然后返回结果。

两者的核心区别在于身份认证方式不同。网页端用的是 Cookie/Session，API 端用的是 API Key。而 Zero Token 的思路就是：既然网页端已经能免费聊天了，那我模拟一个"浏览器"来发送同样格式的请求不就行了？

这个思路用表格来对比会更清晰：

2.2 Playwright + Chrome CDP：技术实现的两个关键拼图

说到"模拟浏览器"，很多人的第一反应可能是 Selenium。但 OpenClaw Zero Token 选择了更现代的方案：Playwright + Chrome DevTools Protocol（CDP）。

Playwright 是微软开源的浏览器自动化框架。相比老牌的 Selenium，它有几个显著优势：底层通过 WebSocket 双向通信（而非 Selenium 的 HTTP 单向请求），每次操作不需要重新建立连接，所有命令通过单个 WebSocket 连接传输，因此速度更快、稳定性更高；原生支持 Chromium、Firefox 和 WebKit 三大浏览器引擎；内置自动等待机制（Auto-wait），交互操作会自动等待元素可见、可操作后才执行，大幅减少了因页面未加载完成导致的操作失败。此外，Playwright 的 Context（上下文）隔离机制可以在同一个浏览器实例中创建多个独立的会话环境，每个 Context 有独立的 Cookie、Storage 和权限配置，互不干扰。

Chrome DevTools Protocol（CDP） 则是 Chromium 浏览器暴露的远程调试和控制接口。它基于 WebSocket 的 JSON-RPC 协议实现，支持 DOM 操作、网络拦截、性能分析、截图等丰富功能。当你以调试模式启动 Chrome（指定一个调试端口，比如 --remote-debugging-port=9222），外部程序就可以通过这个端口与浏览器建立 WebSocket 连接。Playwright 在 Chromium 下正是通过 CDP 协议来驱动浏览器的（Firefox 和 WebKit 使用各自的专有协议）。

在 OpenClaw Zero Token 的场景中，Playwright 通过 connectOverCDP 方法连接到一个已经在运行并且用户已经登录的 Chrome 实例。这和 Playwright 自己启动一个全新的浏览器不同——连接到已有实例意味着可以直接复用用户手动登录后的所有会话状态，包括 Cookie、LocalStorage、IndexedDB 等。这是整个 Zero Token 方案能够成立的技术基石。

OpenClaw Zero Token 的凭证获取流程大致如下（以 DeepSeek 为例，莫潇羽@无忆研习社 整理）：

步骤 1：启动 Chrome 调试模式
   └── 程序调用 start-chrome-debug.sh 脚本
   └── Chrome 以 --remote-debugging-port=18892 参数启动
   └── 同时指定独立的 --user-data-dir（用户数据目录），隔离配置
   └── 这个独立数据目录确保不会污染你日常使用的 Chrome 配置

步骤 2：用户手动登录目标平台
   └── 在这个调试模式的 Chrome 中访问 https://chat.deepseek.com
   └── 正常完成登录（扫码登录或账号密码登录均可）
   └── 登录成功后，浏览器会自动保存 Cookie 和 Session 信息

步骤 3：程序通过 CDP 捕获会话凭证
   └── Playwright 通过 connect_over_cdp("http://localhost:18892") 连接到 Chrome 实例
   └── 获取浏览器的默认上下文（包含登录后的完整会话状态）
   └── 读取 chat.deepseek.com 域名下的所有 Cookie
   └── 提取 UserAgent、Authorization Bearer Token 等请求头信息
   └── 对于需要动态参数的平台，还会从页面执行环境中获取 JavaScript 运行时生成的参数

步骤 4：凭证加密存储
   └── 捕获的凭证被序列化为 JSON 格式
   └── 保存到本地 .openclaw-zero-state/agents/main/agent/auth-profiles.json
   └── 目录权限被收紧到 700（仅文件所有者可读写执行）
   └── 支持凭证过期检测和自动刷新机制

这种设计最巧妙的地方在于：你只需要在浏览器里正常登录一次，后续的所有 AI 请求都由程序自动完成。程序拿着你的凭证去模拟浏览器请求，对服务器来说，这和你在网页上正常聊天几乎没有区别。

我来用一段伪代码说明这个核心原理（莫潇羽@无忆研习社 整理，仅为帮助理解，非项目原始代码）：

// 伪代码：演示凭证捕获的核心逻辑
const { chromium } = require('playwright');

async function captureCredentials() {
  // 连接到已经以调试模式运行的 Chrome
  const browser = await chromium.connectOverCDP('http://localhost:18892');

  // 获取浏览器上下文（包含登录状态）
  const context = browser.contexts()[0];

  // 获取目标平台页面的 Cookie
  const cookies = await context.cookies('https://chat.deepseek.com');

  // 提取关键凭证
  const sessionToken = cookies.find(c => c.name === 'session_token');
  const userAgent = await context.pages()[0].evaluate(() => navigator.userAgent);

  // 加密存储到本地
  saveEncrypted('.openclaw-zero-state/auth-profiles.json', {
    cookies: cookies,
    userAgent: userAgent,
    // ... 其他必要的请求头参数
  });
}

2.3 反反爬：为什么需要 PoW 挑战？

现实没有理论那么美好。各大 AI 平台为了防止被滥用，都部署了不同程度的反爬虫机制。比如 Cloudflare 的 Bot 检测、字节跳动豆包的动态参数验证等。

OpenClaw Zero Token 针对这些反爬措施做了专门的适配：

Cloudflare 验证绕过：由于程序连接的是一个真实运行的 Chrome 浏览器实例（而非模拟的无头浏览器），它天然具备真实浏览器的所有指纹特征——JavaScript 执行环境、Canvas 指纹、WebGL 信息等都是真实的，这让 Cloudflare 的检测很难将其识别为机器人。

PoW（Proof of Work）挑战：部分平台（如 DeepSeek）会在请求时要求客户端完成一个计算密集型任务（通常是 SHA3 哈希计算），以此来提高自动化访问的成本。OpenClaw Zero Token 通过内置的 WASM（WebAssembly）模块来高效完成这些计算挑战。WASM 的执行效率接近原生代码，能快速生成满足条件的哈希值。

动态参数生成：像豆包这样的平台会在请求中附带 a_bogus、fp、msToken 等动态生成的验证参数。传统的爬虫方式需要逆向这些参数的生成算法，难度极高。而 Zero Token 的解决方案很直接——既然这些参数是浏览器环境生成的，那就直接从真实浏览器中获取，省去逆向的麻烦。

三、架构设计全解析：五层架构如何协同工作

OpenClaw Zero Token 的架构设计围绕两个核心目标展开：零 Token 调用大模型 + AI Agent 工具执行。整体采用分层解耦的设计思路，一共分为五层，我们从上到下逐层来看。

3.1 接入层（Access Layer）

接入层是用户与系统交互的入口。它提供了多种接入方式，让不同使用习惯的用户都能方便地使用系统。

Web UI 基于 Lit 3.x（一个轻量级的 Web 组件库）构建，提供了可视化的对话界面。你可以在浏览器中选择模型、发送消息、配置工具——体验和使用普通的 AI 聊天网站类似。默认运行在 http://127.0.0.1:3001。

CLI/TUI 是命令行交互界面，适合没有图形环境的服务器使用，也是很多开发者偏爱的交互方式。直接在终端里和 AI 对话、执行任务。

Gateway API 是一个 HTTP/WebSocket 网关，对外暴露标准化接口。它兼容 OpenAI API 的请求格式（/v1/chat/completions），这意味着你可以把它当作一个本地的"OpenAI 兼容 API 服务"来使用，方便接入各种第三方工具和自动化流程。举个具体的例子，如果你有一个之前写好的调用 OpenAI API 的 Python 脚本，只需要把 base_url 从 https://api.openai.com 改成 http://127.0.0.1:3001，再把 model 参数改成 deepseek-web 或 kimi-web，就可以无缝切换到 Zero Token 模式——代码几乎不用改。这种兼容性设计大大降低了迁移和集成的成本。

# 示例：通过 Gateway API 调用（兼容 OpenAI 格式）
import openai

client = openai.OpenAI(
    base_url="http://127.0.0.1:3001/v1",  # 指向本地 Gateway
    api_key="not-needed"                    # Zero Token 模式无需真实 API Key
)

response = client.chat.completions.create(
    model="deepseek-web",  # 使用 DeepSeek Web 端
    messages=[{"role": "user", "content": "你好，请介绍一下自己"}],
    stream=True
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")

第三方渠道 支持 Telegram Bot、微信机器人等即时通讯工具的接入。配置完成后，你可以直接在 Telegram 里给你的 AI Agent 发消息、布置任务。

所有这些入口最终都会将用户请求转化为统一的内部格式（包含用户输入、选择的模型、上下文 ID 等信息），然后传递给下一层处理。这种"统一入口、统一格式"的设计保证了后续层不需要关心请求是从哪个渠道进来的。

3.2 调度层（Scheduler Layer）

调度层是接入层和核心 Agent 层之间的桥梁，主要负责三件事：

会话管理：维护每个用户的对话上下文。AI Agent 需要记住之前说了什么才能进行连贯的多轮对话，会话管理器负责记录上下文 ID、模型类型、工具调用历史等信息，并支持将会话状态持久化到磁盘，避免重启后丢失。

请求路由：根据用户选择的模型（比如 doubao-web、kimi-web、deepseek-web），将请求路由到对应的大模型适配器。这是一个典型的策略模式应用——调度层只负责分发，不关心具体的调用细节。

权限控制：限制用户可以使用的工具范围。比如可以禁止普通用户执行 exec 系统命令（防止误操作），限制文件访问仅在配置的工作目录内（防止 AI 意外读写系统关键文件）。

3.3 核心 Agent 层（Core Agent Layer）

这一层是整个框架的"大脑"，实现了 AI 智能体的核心能力。

任务解析器 负责将用户的自然语言请求翻译成结构化的任务指令。比如用户说"帮我读取桌面上的 report.txt 文件"，解析器会结合系统提示词（System Prompt），引导大模型输出标准化的工具调用格式——比如 <tool_call>read_file</tool_call> 加上对应的参数。

工具调用引擎 是核心组件，负责实际执行各种工具操作。目前支持的本地工具包括：

• exec：执行系统 Shell 命令
• read_file / list_dir：文件读写和目录遍历
• browser：浏览器自动化操作
• apply_patch：代码补丁应用

不同类型的模型提供商，工具调用的实现方式有所不同。对于国内 Web 平台（DeepSeek、千问、Kimi、豆包等），工具调用基于 XML 格式的 <tool_call> 标签解析，系统提示词里会内置工具的使用说明；对于 OpenRouter 和 Ollama 这类原生支持 Function Calling 的平台，则直接使用 tools/tool_calls 标准 API，无需额外解析。

响应生成器 负责把大模型的回复和工具执行结果整合成用户可以理解的格式（流式文本或 JSON），然后返回给接入层展示。

3.4 大模型调用层（LLM Call Layer）

这一层是 Zero Token 项目改动最大的地方——它重构了原版 OpenClaw 的模型调用逻辑，新增了"零 Token 调用"的适配能力。

这一层定义了一个统一的 LLM Adapter 接口（标准化的 completions / chat/completions 接口），所有的模型提供商都必须实现这个接口。这样上层的 Agent 层就不需要关心底层到底是通过 API Key 还是通过浏览器凭证在调用——接口一致，实现透明。

在这个统一接口之下，有两类具体的提供商实现：

Zero Token 提供商（核心部分）：针对每个 Web 平台都有一个专属适配器。以豆包为例，它的适配器会做这些事：调用底层浏览器自动化组件获取 sessionid 和 ttwid 两个 Cookie 凭证；按照豆包网页端的请求格式组装 HTTP 请求；解析豆包特有的自定义 SSE 流式响应格式；把解析后的文本转换为标准化的响应格式返回。

传统 Token 提供商：保留了原版 OpenClaw 的 API Key 调用方式，兼容 OpenAI、Anthropic 等标准 API。这作为一个兜底方案存在，当某个平台的 Web 端调用出问题时，可以无缝切换到 API 调用方式。

3.5 底层技术层（Infrastructure Layer）

这一层提供了支撑整个系统运转的基础设施。

浏览器自动化模块 基于 Playwright + Chrome CDP 实现，核心功能包括：自动启动 Chrome 并开启调试模式（指定端口）、捕获用户登录后的各种凭证信息、在需要时模拟用户操作（如点击、滚动等）。

凭证管理模块 将敏感信息加密存储在本地的 .openclaw-zero-state 目录中。这个目录下有两个关键文件：openclaw.json（主配置文件，包含启用的平台、工作目录等设置）和 auth-profiles.json（认证凭证，包含各平台的 Cookie 和 Token）。项目的 .gitignore 中已经排除了这个目录，防止凭证被意外提交到版本控制系统。

流式解析模块 基于 SSE（Server-Sent Events）实现实时响应。不同平台的 SSE 数据格式各不相同——DeepSeek 可能用的是标准 JSON 流，豆包可能用的是自定义字段的 SSE，Kimi 可能又是另一种格式。这个模块负责统一解析这些差异，转换为标准化的文本流供上层使用。

工具执行沙箱 为 AI 的工具调用提供安全隔离。它会严格限制文件访问范围（只允许访问配置中指定的 workspace 目录）、过滤高危系统命令（比如 rm -rf /）、可选地限制网络请求权限。这是一层重要的安全防线——毕竟你不会希望 AI Agent 在执行任务时意外删除你的系统文件。

四、支持的大模型平台一览

截至 莫潇羽@无忆研习社 撰文时，OpenClaw Zero Token 已经验证支持以下大模型平台，均通过 Playwright 浏览器自动化实现认证和调用：

此外还兼容 OpenRouter（聚合多模型的 API 路由服务）和 Ollama（本地模型运行框架），这两者使用的是原生的 tools/tool_calls 标准 API 接口，无需浏览器自动化。

值得一提的是，千问国内版（qianwen.com）在功能上比国际版更加完善。如果你在国内使用，建议优先选择国内版，它的响应速度更快，还额外支持深度搜索、代码助手和图片生成等扩展能力。

4.1 AskOnce 功能：一次提问，多模型同时回答

OpenClaw Zero Token 还继承了一个很实用的特色功能——AskOnce（一次提问）。当你配置了多个大模型平台后，AskOnce 允许你同时向所有已配置的模型发起同一个查询，然后将各个模型的回复并排展示。这在以下场景中特别有用：

当你需要对比不同模型对同一个问题的理解和回答质量时，不再需要手动切换模型逐个提问。比如你问"如何用 Python 实现一个简单的 Web 服务器"，DeepSeek、Kimi 和豆包会同时给出各自的方案，你可以直观地对比哪个模型的回答更符合你的需求。

对于创意类任务（比如文案写作、方案策划），多模型的回答能提供不同视角的灵感碰撞。对于技术问题，多模型交叉验证也能帮助你快速发现某个模型可能存在的"幻觉"（编造不存在的信息）。

五、豆包（Doubao）专属适配：一个典型的深度优化案例

OpenClaw Zero Token 对字节跳动旗下的豆包平台做了特别深入的适配。作为一个国内平台适配的典型案例，了解它的实现细节有助于理解整个 Zero Token 方案的技术深度。

无需代理直连：豆包的服务器在国内，不像部分海外平台需要特殊网络环境。Zero Token 直接通过浏览器访问豆包官网 www.doubao.com，对国内用户来说开箱即用。

动态参数自动生成：豆包的反爬体系比较复杂，请求中需要携带 msToken、a_bogus、fp 等多个动态生成的参数。传统的爬虫方案需要逆向这些参数的生成算法（通常涉及混淆后的 JavaScript 代码分析），工程量大且容易失效。Zero Token 的做法是直接在真实浏览器环境中让这些参数自然生成——因为参数本来就是浏览器端的 JavaScript 计算出来的，真实浏览器环境下它们会被正常执行和附带。

极简认证流程：要完成豆包的认证，你只需要提供两个 Cookie 值：sessionid 和 ttwid。程序会自动从浏览器中提取这两个值并保存。整个流程非常简洁。

流式响应支持：豆包的流式响应格式是自定义的（不完全遵循标准 SSE 规范），Zero Token 为此做了专门的解析适配，确保对话过程中文字能实时流式输出，体验和在网页端直接使用一致。

5.1 深入理解 SSE 流式响应的适配难题

SSE（Server-Sent Events）是一种服务器向客户端推送数据的协议，广泛应用于大模型的流式输出场景。当你在网页端和 AI 对话时，回复不是一次性返回的，而是一个字一个字（或一个词一个词）地"蹦"出来——这就是 SSE 在起作用。

标准的 SSE 格式是这样的：

data: {"content": "你好"}

data: {"content": "，我是"}

data: {"content": " AI 助手"}

data: [DONE]

但在实际的各平台适配中，情况远没有这么简单。每个平台都有自己的"方言"：DeepSeek 的 SSE 数据中包含了思考过程（thinking）和正式回复两个部分，需要区分处理；Kimi 使用的是嵌套 JSON 格式，响应事件类型也和标准格式有差异；豆包的 SSE 字段名和数据结构更是完全自定义的。

OpenClaw Zero Token 的流式解析模块需要为每个平台编写独立的解析逻辑，将这些"方言"统一翻译成标准化的文本流，才能让上层的 Agent 层正常工作。这也是为什么项目中每个 Web 平台都有一个独立的"适配器"文件的原因——它们处理的不仅仅是认证差异，还包括请求格式和响应格式的全面适配。

六、从零开始的完整部署教程

下面是一份面向新手的完整部署指南。莫潇羽@无忆研习社 根据项目文档和实际操作经验整理，力求覆盖每一个可能遇到坑的地方。

6.1 环境准备

在开始之前，确保你的系统满足以下要求：

操作系统：Linux、macOS 或 Windows 均可（推荐 Linux 或 macOS，Shell 脚本兼容性更好）

Node.js：版本 22 或以上（这是硬性要求，低版本会报错）

pnpm：Node.js 的包管理器（比 npm 更快，项目依赖 pnpm 进行构建）

Chrome 浏览器：需要安装 Google Chrome（不是 Chr