共计 1469 个字符，预计需要花费 4 分钟才能阅读完成。
龙虾为啥越养越贵, 越用越蠢?
龙虾的核心问题不在于模型或 Bug, 而是设计与使用场景的严重错配。OpenClaw 的保活机制与全屏识别等功能, 本质是为开发者调试而生。当这种创新设计破圈到普通用户手中, 必然导 …
近期, 曾备受追捧的 AI 智能体 OpenClaw(俗称“龙虾”)陷入争议漩涡: 用户抱怨其使用成本越来越高,但智能表现却似乎越来越“蠢”。这背后究竟是何原因? 钛媒体深度体验后指出, 问题核心并非模型不够聪明或开源项目 Bug 太多, 而在于 设计与使用场景的严重错配。
📌 导语: 从“神器”到“吞金兽”的转变
OpenClaw 凭借其强大的端侧计算机视觉能力和无 API 软件接管功能,一度被开发者奉为调试神器。然而, 当这款为专业场景打造的工具破圈进入普通用户手中, 却暴露出一系列性能冗余和逻辑紊乱问题, 导致“越养越贵、越用越蠢”的现象。今天, 我们就来拆解这背后的三大关键症结。
🔍 一、心跳保活机制: 开发者的稳定器, 普通用户的 Token 黑洞
心跳保活机制是 OpenClaw 实现实时环境感知和长任务稳定的核心技术。其设计初衷是通过定期同步屏幕、剪贴板等数据, 确保大模型始终了解电脑状态, 避免任务中断。对开发者而言, 这解决了环境对齐和长周期任务稳定性两大难题, 类似微信文件的断点续传。
然而, 这一机制对普通用户却成了成本噩梦。由于 Transformer 架构的无状态特性 , 每次心跳都需要上传全量上下文数据, 包括屏幕 OCR 结果、会话摘要, 甚至捆绑数千字的固定配置文件(如 AGENT.md 和 SOUL.md)。这导致 闲置开销远超实际任务花费, 许多用户一觉醒来便发现欠费数百元。
优化方向:
- 调整频率: 拉长心跳间隔至数小时, 无任务时直接关闭。
- 分层运行: 用本地小模型处理心跳, 复杂任务再调用云端大模型。
- 技术演进 : 业界正探索上下文缓存、事件驱动模式(如视觉差分拦截) 以降低消耗。
💡 二、单模型全场景: 算力错配与执行效率下降
OpenClaw 默认使用同一大模型处理所有请求,这造成了严重的资源错配。用户若选择低成本套餐, 往往只能使用 10B 参数以下的小模型, 导致任务执行智商下降, 需要频繁人工纠错; 若接入高价深度思考模型, 却又用其处理大量机械性操作(如调度、触发固定流程), 造成大材小用。
这种单模型策略带来两个副作用:
- 执行准确率不升反降: 高端模型思维链长、发散性强, 面对简单操作易过度推理, 反复出错。
- Token 消耗猛涨: 深度模型生成大量无用推理内容, 占满上下文窗口, 拖慢任务速度。
行业共识是采用 大小模型分层协同: 机械执行类工作交给轻量化专用模型(如 Qwen2-VL-7B), 复杂场景才调用顶级模型。微软 AutoGen、阿里通义 AgentScope 等框架均已尝试此方向。
📊 三、全屏扫描: 视觉优势与成本陷阱并存
OpenClaw 的核心优势在于其全屏扫描与 OCR 识别能力,能像人类一样盯屏操作, 甚至接管无 API 的本地软件。但这也成了 Token 消耗的另一大黑洞。
问题在于,系统默认全量扫描屏幕, 无法区分有效信息与冗余内容(如广告、壁纸)。更关键的是, 大模型的图像计费逻辑与分辨率挂钩: 在 ViT 架构下, 高清截图需拆分为 512×512 像素区块逐一运算。4K 或带鱼屏单次消耗可达数千 Token, 大量算力浪费在无效像素上。
🚀 行业观察: 技术无原罪, 错配是根源
🧭 总结与展望
随着微软、阿里、百度等巨头在智能体框架领域的持续投入,更高效、更经济的 AI 助手解决方案值得期待。对于普通用户而言, 在拥抱新技术的同时, 也需理性评估自身需求与技术适配度, 避免陷入“越养越贵”的困境。
