最近用 OpenClaw 搭建 AI 助手很热门，国内也能顺畅使用。然而，一旦真正开始使用，关于难度、风险和长期成本的问题并不是简单一句“能跑起来”就能回答的。前面几篇文章已经从不同角度进行了分析，这一篇将专注于使用成本：硬件是否需要单独投入、如何选择 LLM，以及在实际使用过程中，token究竟花在了哪里。

1 是否需要专门买一台 mac mini？

OpenClaw 设计成常驻运行的服务——24/7 不间断，这样可以随时通过聊天发指令给它执行任务。另外，它可以做计划任务、检查更新、发送通知等，这就类似一个“个人服务器”，让它一直运行通常更稳妥。

若把它放在你主工作电脑上，可能影响日常使用或有冲突（比如频繁控制浏览器）。OpenClaw 在本地运行且可访问系统资源（终端、文件、浏览器等）。直接在日常电脑上给它较高权限，多少会有顾虑，也可能误操作影响系统或数据。不少人希望把它隔离出来，专门用一台机器能降低对主工作环境的风险。

Mac Mini（特别是 M 系列）性能不错且功耗低、噪音少，适合 24/7 运行；同时 macOS 生态很多工具兼容性也好。这导致社区里大量购买这类硬件来运行 OpenClaw。实际上并不只能在 Mac Mini 上运行，它可以部署在 Windows、Linux、树莓派、以及云服务器上。选择 Mac Mini 更多是因为社区热度、体验感和稳定性，而不是技术层面唯一的需求。它对硬件要求并不高，便宜的云服务器、家里闲置的旧机器都可以跑起来。

我的用法是在 Linux 上用 Docker 方式运行 OpenClaw，只暴露我想让它看到的文件夹，用另一个 Docker 提供浏览器功能。即便它把自己改乱了、不断重启（使用中确实遇到了这个问题），也不会影响我的宿主机正常使用。安装确实有点门槛，但一般愿意折腾 OpenClaw 的人，对系统多少都有点把控。

2 模型选择

在用 OpenClaw 之前，我觉得它比较烧钱。即使是买新的硬件，也是一次性投入。但 token 会持续消耗，而且这种工具一旦用顺手，就很难停下来，除非发现它没什么用。这还不包括有些问题多次解不出来，死循环什么的，意外烧掉不少 token（这个我确实遇到过）。所以现阶段它更像：“一个需要长期供养的数字管家”。不仅得买得起，还得养得起。

用了之后，我的感受是：

• kimi 也是 OpenClaw 作者推荐的模型，之前很少用 kimi，这次用 kimi coding，速度和效果都还不错，它的过程设计和执行也是很扎实。

• 从调用记录看，大多数行为都是在我触发交互时发生的，除了我手动设置的自动运行项。token 用量整体是可监控、可把握的。Kimi 4.9 元试用 7 天，对我来说每天的限量基本够用。

• 一开始什么都想试，用得多很正常。后面真当助手长期挂着，其实不会天天探索新花样。普通人一个月几十块钱大概率够用。这波泼天的富贵 kimi 算是接住了。

（取自：https://openrouter.ai/rankings 2026.02.13 排行搒）

至于模型选择，可以类比辅助编程的用法。我们大概会遇到三种问题：

• 第一种：简单问题。大多数模型都能处理，这类问题我感觉占一半以上，而且随着模型能力提升，占比还会增加。

• 第二种：有一定复杂度的问题。高级模型可能一两次解决（价格通常差 3–7 倍），简单模型可能反复尝试才能解决，这样造成时间和 token 的双重浪费，有时候还解决不了问题。

• 第三种：困难问题。需要反复与环境交互、尝试，本身就极具挑战性，用哪个模型都很难解决。

我们选择不同模型，主要差异体现在第二种情况。在我的日常使用场景里（非编程），这类问题占比并不高。所以（因情况而异）普通用户未必需要最贵的模型，deepseek、kimi、智谱基本都够用。当然如果是工作中高频使用，或者预算充足，那就另说。不差钱的时候，确实没必要纠结性价比。

以下网页中说明了具体每一档对应的权限：

https://www.kimi.com/user/agreement/membershipBenefits?version=v2

3 从对话内容看流量使用

使用时候真正消耗的地方和我以为的不太一样：我让它大量整理文档，并没有想像中消耗那么快。但会在一些不经意的地方，把 token 都花没了，有时一个需求会引发后台几十次交互。

好在新版本会明文记录每一次对话，不仅有界面上的内容，还有内部思考和工具调用过程。数据存储在 $HOME/.openclaw/agents/sessions/*.jsonl。相比之前存在 sqlite 里直观很多。

从记录里可以看到，openclaw 对模糊描述的理解，很大程度依赖反复尝试。用户描述得越模糊、细节越少，它迭代次数越多，token 消耗越高。我一个批量移动文件的需求，它可能来回折腾几十次。我原本以为用量主要耗在大量文本处理上，其实很多花在多轮交互上。如果我描述更清晰、少打错字，很多迭代本可以避免。

通过浏览器搜索时，也会产生大量数据。下载的 HTML 内容会传给模型处理，从界面看显示的字也不太，但实际的 html 可能非常大。如果在调用时加一些限制，比如只取前 n 条结果、限定时间范围，消耗会明显下降。

我买了一个 KIMI 4.9 元/7 天的试用包（限时限量），差不多用完时，jsonl 文件内容总和约 6.8M。粗略估算：1M UTF-8 纯文本大概 30 多万字（但 jsonl 里有大量结构字段和签名数据，并不等同纯文本字数），这量也不小。而且需要注意：文件大小只能反映交互规模，并不等于真实 token 消耗。不同模型计费方式也不同，有的按 token 计费，有的按调用次数计费，两者不能简单换算。

我 1M 以上的 session 大概有 4 个，包含：后台高频交互、涉及浏览器搜索、查看代码调用、反复调试、配置改乱定时器空跑等场景。相比之下，单纯整理几万字文本反而没有想像中那么夸张。

总体感受是：越灵活、越不在它现成知识路径里的任务，越容易消耗资源。

4 总结

所以说，钱花哪儿了？有人花在设备上，比如 Mac mini 或云服务器；更多会花在 token 上，这是长期支出。Token 又分为必要和不必要的。有时少写几个字、描述不清楚，就可能多花很多。有些问题过于复杂，任凭什么模型都很难解决，做这种事情性价比也很低。

购买 AI 助理，其实有点像公司多请一个员工。至少要付基本成本。至于找工资高的还是工资低的，取决于让他干什么。请高学历的人才来做一些杂活，或者人浮于事，就是浪费资源；如果公司处于攻坚阶段、不差钱，那自然要找最强的人。