从 OpenClaw 到 SmallClaw——为什么 Agent 比聊天式 AI 更消耗 Token

为了防止老年痴呆，也出于对新技术一直都有的好奇心，我最近从零开始手搓了一个“小龙虾”，暂时叫 SmallClaw。不是把 OpenClaw 装上以后慢慢养，而是自己从头做了一个原生的龙虾。虽然整个开发过程基本都发生在苹果的软件生态里，但我也花了不少时间研究 OpenClaw 的基本原理。现在这个“小龙虾”已经算是活了，至少能够跑起来，也能做一些事情，不过离真正变成一个可以发布、可以稳定使用的产品，还有很长一段路要走。开发过程中，我也花了不少时间去想一个很核心的技术点，就是怎样从基本架构上尽可能减少 token 消耗量。

很多人在讨论 OpenClaw 为什么比 ChatGPT app 或 Gemini app 更消耗 LLM token 时，第一反应往往是——底层大语言模型是 stateless 的，所以每次都要把上下文重新发一遍。这个判断当然不算错，但它只能解释一部分现象，解释不了为什么同样建立在无状态模型之上的产品，token 成本会差这么多。

真正的关键，不在于它是不是 stateless，而在于每一轮请求里，到底给模型重建了什么样的上下文。这里面有多少是语言内容，有多少是环境状态，又有多少本来可以在系统层被程序逻辑先处理掉，最后却直接暴露给了模型。

从这个角度看，ChatGPT app、Gemini app 和 OpenClaw 虽然都建立在 stateless LLM 之上，但它们的系统分工并不一样。前两者更像是平台先把信息压缩和整理一遍，再交给模型；OpenClaw 更接近一种显式的 agent runtime，它需要不断把任务现场、工具状态和执行过程重新组织之后再发给模型。所以 OpenClaw 更耗 token，并不是因为它比聊天产品“更无状态”，而是因为它在每一轮里，让模型承担了更多原本可以由系统层吸收掉的环境理解和流程控制工作。

先看聊天类产品通常是怎么工作的。用户在 ChatGPT 或 Gemini 里输入一句话，看上去就是一次普通的问答，但后台一般不会把所有原始状态不加筛选地直接扔给模型。系统通常会做不少用户看不见但其实很关键的处理，比如对前面几轮内容做摘要，把已经不重要的内容折叠掉，把一些固定流程硬编码进去，对工具返回结果再整理一遍，甚至有些路由和状态管理本身就在系统层做完了。结果就是，虽然底层模型仍然是 stateless 的，每次请求也确实还是要重新带上上下文，但真正送进去的内容，已经是处理过一轮之后的版本。

这种模式下，模型面对的主要还是语言上下文。它理解的是用户问了什么，前面说过什么，现在任务的目标是什么。即使对话变长，内容本质上也还是自然语言。这种上下文当然也会变重，但复杂性通常还比较可控，因为系统比较容易对它做裁剪和摘要。

OpenClaw 就不是这样了。它不是一个以聊天为主的界面，而是一个以执行任务为主的 agent 系统。它要处理的不只是用户语言，还包括浏览器页面状态、工具定义、操作结果、动作候选、当前步骤以及下一步规划这一整套执行现场。也就是说，模型每一轮面对的，不只是“刚才我们说了什么”，而是“外部世界现在是什么样，我刚才做了什么，现在有哪些工具可以用，下一步应该怎么走”。

这就带来第一个根本差异——上下文的性质变了。

在聊天产品里，上下文主要是连续的语义文本。到了 OpenClaw 这里，上下文里往往塞进了大量结构化的环境信息，尤其是在浏览器自动化场景下，页面快照本身就可能吃掉非常多 token。一个复杂网页不是一句“这里有个按钮”就能说清楚的，它可能包含成百上千个节点、属性、层级关系、可交互状态、文本片段，还有动态更新之后的引用关系。为了让模型判断该点哪里、该输什么、页面有没有变化，系统就得把这些环境信息描述给它。于是，大量 token 并不是花在最后生成回答上，而是花在让模型知道“现在这个世界长什么样”。

这里还有一个很重要、但经常被忽视的细节——网页操作不是静止的，而是不断变化的。很多时候，模型刚根据当前快照选中了一个元素并执行点击，这个点击本身就会触发页面变化。轻一点，可能只是弹出一个窗口，展开一个区域，或者让按钮状态发生变化。重一点，可能就是整页重新渲染、路由跳转、表单刷新、异步数据重新加载，甚至连原来的 DOM 结构和元素引用都失效了。这样一来，系统就不能继续依赖前一份快照，只能重新抓取当前页面状态，再生成一份新的结构化快照，然后把这份新快照交给 LLM，让它判断下一步该做什么。

这意味着，一个看起来很简单的点击，在 agent runtime 里并不是一个孤立动作，它后面往往会连带出新一轮观察、理解和决策。旧快照用来定位动作，新快照用来确认结果并决定下一步。如果页面变化比较大，前一轮里很多上下文很快就过期了，系统只能把新的页面状态、最新的操作结果和当前目标重新送入模型，让它再建立一遍对现场的理解。所以网页交互里的 token 消耗，往往不是简单线性增加，而更像是页面每动一次，现场就要重建一次；快照一更新，上下文又得重发一遍。在复杂网站上，这种循环本身就是 token 消耗迅速上升的直接原因。

第二个差异在于调用模式。

ChatGPT 或 Gemini 的常规对话，大多数时候还是一轮输入对应一轮输出。即使后台也有额外编排，通常也是比较克制、比较受控的，用户看到的交互密度并不高。OpenClaw 则不同，一个表面上很简单的任务，往往会被展开成多轮 agent 循环。模型先观察页面，再判断当前状态，再决定调用哪个工具，然后读取工具返回，再判断这一步有没有成功，再生成下一步动作。只要网页在执行某个动作后发生了变化，这个循环通常就不会停下来，而是继续进入下一轮抓取快照、提交给模型、选择动作、执行动作、再观察结果。

这样一个循环，在一次用户请求里可能会重复很多次。用户表面上只说了一句“帮我登录并进入设置页面”，但系统内部可能已经经历了打开页面、识别登录入口、点击、等待跳转、重新抓取新页面快照、识别输入框、输入账号、输入密码、点击提交、检测错误或者验证码、再抓一次快照、再做下一步判断等一连串阶段。每一个阶段都可能对应一次新的 LLM 调用，而每一次调用又往往要带上新的页面状态和前面的操作结果。

所以 OpenClaw 的 token 成本，不只是单轮重，轮数也多。如果每一轮都要附带页面快照、工具说明、历史步骤和中间结果，那么即使单轮没有夸张到失控，多轮叠加之后成本也会迅速放大。真正贵的，很多时候不是某一次调用，而是整个执行链条里不断重复发生的上下文重建。

第三个差异在于流程逻辑到底放在哪里。

很多人喜欢把这个问题概括成一句话——ChatGPT 和 Gemini 的逻辑主要在 LLM 里，OpenClaw 的逻辑有相当一部分在 OpenClaw 自己的流程逻辑里。这个说法有一定道理，但还不够准确。更准确一点说，ChatGPT 和 Gemini 并不是纯靠 LLM 自己思考，而是把大量状态管理、流程控制、上下文压缩和系统协调工作放在平台层完成了。OpenClaw 虽然也有自己的运行时逻辑，但它更经常把未经充分压缩的任务现场直接交给 LLM 去理解和决策。

所以问题并不在于 OpenClaw“外部逻辑更多”，恰恰相反，它之所以更耗 token，很多时候正是因为还有不少本来可以由程序逻辑先处理掉的事情，没有被足够彻底地收住，结果还是交给模型反复去看、去想、去判断。

网页操作就是最典型的例子。程序完全可以先在系统层做一轮很强的筛选，识别当前页面最相关的区域，过滤掉大量无关节点，稳定元素引用，合并重复文本，把模型真正需要面对的候选对象压缩到一个比较小的集合里。如果这一步做得好，模型看到的就不是整个页面，而只是一个已经预处理过的可操作摘要。这样一来，token 消耗会明显下降，推理也会更稳定。

但如果系统只是比较原始地把大面积页面快照扔给模型，再让模型自己判断哪个元素重要、哪个按钮该点、哪些内容可以忽略，那成本自然就会上去。更麻烦的是，网页本来就不是静止的。点击之后页面可能跳转，局部 DOM 可能重绘，原来的 ref 可能失效，新的元素层级可能出现，甚至只是加载一段异步内容，都足以让旧快照不再可靠。于是系统又得重新观察页面、重新生成快照、再调一次 LLM。这样一来，很多 token 其实并不是花在新的业务逻辑上，而是花在重新理解同一个任务现场的最新状态上。

从工程上看，这里有一个很重要的分界线。聊天产品优化的重点，通常是对话压缩、记忆摘要、系统路由和回答生成效率。Agent 产品优化的重点则更偏向 context engineering，说白了，就是怎样让模型只看到完成当前动作所必需的信息，而不是让它背着整个现场往前走。前者主要解决的是语言历史越来越长，后者主要解决的是环境状态太重。

所以，OpenClaw 的高 token 消耗，不能简单归因于它是一个无状态系统，也不能简单理解成“因为它调用模型次数多”。更完整一点的说法应该是——OpenClaw 在多轮 agent 循环里，不断把体积很大的环境状态、执行历史和工具上下文重新暴露给模型，而聊天产品通常会先在平台层把这些复杂性压缩、过滤和隐藏掉。两者都依赖 stateless LLM，但一个主要在重建语言上下文，另一个主要在重建任务现场，这才是成本差异真正的来源。

如果把这个判断放回产品设计上，结论其实也很清楚。降低 OpenClaw 这类系统的 token 成本，最有效的办法往往不是单纯换一个更便宜的模型，而是重新划分系统层和模型层之间的职责边界。凡是可以通过确定性程序逻辑解决的，就不要交给 LLM 反复感知和推理。凡是可以做本地筛选、本地摘要、本地状态管理的，就不要每一轮都完整塞进上下文。凡是可以模板化、约束化、结构化表达的，也不必继续保留成松散的自然语言现场描述。(顺便透露一下，这也是SmallClaw做成macOS桌面应用的原因之一）

归根到底，决定 token 成本的，不只是模型价格，也不只是上下文窗口大小，更重要的是系统有没有先把现实世界的复杂性消化掉。ChatGPT 和 Gemini 更擅长把复杂性留在产品系统内部，OpenClaw 则让更多复杂性直接进入 prompt。

所以对 SmallClaw 这类系统来说，关键就是尽量减少模型必须直接面对的信息量。观察越收敛，状态越稳定，动作空间越受控，成本、速度和稳定性就越容易做上去。

再往前看，这件事其实已经不只是 OpenClaw、SmallClaw 或某一种产品路线的问题了，更像是整个人机关系正在慢慢换一种结构。AI 的发展速度非常快，而且这种快已经不是夸张的说法，而是每天都能感觉到的现实。现在这种还带着实验色彩、发展很猛的 Claw 形态，以后很可能不会只停留在少数人的工具箱里，而会逐渐进入操作系统本身，最后变成一种默认存在的能力，就像今天的浏览器、文件系统或者输入法一样。

如果真是这样，那么浏览器这个统治互联网几十年的人机交互入口，接下来大概率也会发生很深的变化。它未必会消失，但它服务的对象，可能不会再主要是屏幕前那个点击、输入、阅读的人，而会越来越多地转向另一类使用者，也就是 agent。到那个时候，很多网页和在线服务在设计之初，可能就要默认来访问它们的不只是人，还有持续工作的智能体。

这样一来，很多今天看起来理所当然的东西，后面都可能被改写。网页不一定还要把“给人看”放在最前面，很多交互也不一定还要围绕可视界面来组织。浏览器本身也许还会继续存在，但它的内部结构、前端框架关注的重点，甚至整个 Web 的交互思路，都可能慢慢转向一种更适合机器理解和接管的方向。所谓无界面，或者专门面向 agent 的界面，到那时也许就不再只是边缘尝试，而会越来越接近现实。