我的征尘是星辰大海。。。
The dirt and dust from my pilgrimage forms oceans of stars...
-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆
作者:黄教授
手机视频列表
我是在养龙虾吗我自己都不清楚
视频
音频
原始脚本
我是在养龙虾吗？我自己都分不清。 前几天和同学吃饭，对方看我长期让 AI 自主跑任务，批量写脚本，反复探索调试系统。 随口问我一句，是不是圈内常说的养龙虾。 等下我一时语塞，含糊回了一句好像不是。 事后静下心，完整梳理自己整套工作架构。 再对照市面上 OpenCloud 标准龙虾项目的运作模式，才算把这件事彻底理清，分清我这套方案和通用龙虾体系的异同。 也看懂如今大模型厂商靠自主智能体实现稳定商业化变现的底层逻辑。 先说基础问题，市面上大家口中的养龙虾到底是什么？圈内说的龙虾名字来自开源智能体框架 OpenClaw 工具图标是小龙虾。 玩家长期部署调度多自主 AI 代理。 持续投喂云端 API 算力，让 AI 全自动循环干活，这套行为就被戏称养龙虾。 标准龙虾的运行逻辑十分统一。 以 OpenClaw 作为调度外壳，代码编写、任务规划、报错复盘、批量试错全部交给云端付费大模型承担，程序直接获取本机全盘读写权限。 还会调用浏览器底层调试接口，全自动操控终端、网页、本地文件，全程几乎不需要人工介入。 这种模式有两个很突出的短板。 第一是 token 消耗极其夸张，AI自主多轮循环交互，消耗量是普通单次对话的几十倍。 第二是安全风险极高，它需要放开系统全域权限。 还要打通浏览器底层调试通道，自动化注入脚本操控页面的行为，和木马恶意程序操作逻辑几乎没有区别。 乌邦图 22.04环境下。 Firefox 自带极强安全防护，会主动限制这类底层接管操作。 强行打通会直接带来账号登录凭证、二次验证信息泄露的巨大隐患。 这也是我从最开始就完全拒绝使用 Open Cloud 的核心原因。 在回答核心疑问，我的这套自动化体系算不算养龙虾？分广义狭义两个维度看，结论完全不同。 从广义行业定义来讲，我确实属于养龙虾范畴。 我搭建了一套自研定时调度的多角色 Agent 的集群。 划分研究、迷宫探索、 QA 测试、 bug 修复、个人助理多个分工，依靠火山方舟 cloud coding 付费套餐提供云端算力。 让 AI 自主闭环完成编程、系统迭代、迷宫探索等重复性工作。 大量自主调用会持续消耗云端 token 额度，消耗速度很快。 即便开通两份 coding plan pro 包月套餐轮换使用，多 agent 并发运行时依旧会触达5小时滑动窗口限流，只能阶段性关停集群，压低消耗。 这种长期运行多 AI 代理。 持续消耗付费云端算力，自动执行任务的核心行为和养龙虾完全重合。 这也是同学一眼联想到龙虾项目的根本原因。 单从狭义标准 OpenCL 原版龙虾的角度区分，我的方案和市面主流做法存在多处本质区别，并不能算作传统意义上的养龙虾。 第一，调度底层完全独立。 主流养龙虾直接套用现成 OpenClaw 框架做任务分发，我全程自研 Timer 定时调度逻辑。 没有接入 OpenClaw 所有角色分配、回调执行规则都是自行设计搭建。 第二，算力采用高低分层分流设计，主动压低云端 token 消耗。 市面上绝大多数龙虾项目不分任务轻重，所有试错、探索、穷举工作全部丢给付费云端模型，算力损耗无法控制。 我做了硬性任务划分，高价值、高推理难度的工作交给火山 cloud 云端模型，包含架构设计、复杂 bug 修复。 整体战略规划、标准化脚本编写、项目经验沉淀，所有大批量、重复试错、迷宫探索类消耗型任务全部交给本地 llama 部署的 qwen 2.57B开源模型处理。 完全不占用火山引擎 token 依托笔记本 RTX 4050M6G 显卡离线推理，以此拉长云端套餐可用周期。 第三。 硬件采用两组独立物理设备充当隔离沙盒，权限边界清晰可控。 标准龙虾直接在单台主机运行，无隔离，全盘无限制读写文件。 我准备两台独立设备作为专用沙盒。 一台旧笔记本、一台8 g 内存树莓派5，均搭载 Ubuntu 22.04系统。 两台设备互相打通 SSH 密钥登录，可通过 IP 互通访问。 程序项目数据依靠 Git 同步共享，两台设备都部署运行 Cloud 的相关任务。 这两台沙盒设备可以放开权限，随意调试折腾。 即便出现漏洞异常，也不会影响核心设备。 而运行欧了吗，承载本地显卡算力的主力笔记本和两台沙盒物理隔绝。 沙盒无法反向访问主力机，从硬件层面最大化保障本机数据安全。 第四，浏览器交互放弃底层全自动接管，改用人工中转规避安全漏洞。 标准龙虾会打通浏览器调试接口，全自动操作页面，极易泄露账号密码、 ota 验证凭证。 我没有开放底层操控权限。 浏览器 F12调试面板的页面数据、接口内容全部手动复制，截图中转给到模型，由模型输出 JS 脚本后再手动落地执行。 虽然操作效率大幅下降，但彻底规避自动化接管浏览器带来的账号安全风险，也不用对抗 Firefox 原生的安全限制。 第五。 云端算力扩容存在硬性约束。 市面主流龙虾大多依托通用 APP 按量计费，理论上可以通过持续充值提升算力供给。 但火山方舟 Coding Plan 不存在临时扩容、增购额度的通道。 额度耗尽，只能等待周期自动刷新。 仅靠两份 PRO 套餐轮换，依旧难以支撑全天多 Agent 稳定运行。 最后聊聊这套模式带来的直观商业变化。 也是我近期最深的感受。 以往普通人使用大模型只是单次一问一答，Token 消耗量极低，依靠免费额度或是低价轻量套餐就能满足需求。 各大模型厂商很难拿到稳定现金流。 但养龙虾这类自主智能体模式普及后，AI 会自主循环发起调用，形成刚性持续的算力消费需求。 像我这样重度使用者，每月需要两份高价 PRO 套餐，额度依旧紧张。 厂商由此获得稳定高额的月度收入，相当于终于找到了可持续落地的规模化变现路径。 整体总结，抛开资源调度、硬件隔离、算力分层这些细节不谈，只看多 AI 代理长期自主运行，持续消耗付费云端算力，完成自动化任务这个核心行为。 我广义上确实算是在养龙虾。 但对比市面上通用 OpenCloud 的标准实现方案，我的架构做了大量安全隔离、算力分流的改良设计。 是一套高安全、轻量化、自主优化后的变体，和大众认知里原生的龙虾项目存在明显区分。 最关键的一点，我全程没有部署，体验过 OpenCloud 一开始就出于系统安全考量，排斥这套工具。 直到旁人点出养龙虾这个行业说法，结合自身整套架构复盘对比，才完整理清二者之间的关联与差异。
修正脚本
我是在养龙虾吗？我自己都分不清。 前几天和同学吃饭，对方看我长期让 AI 自主跑任务，批量写脚本，反复探索调试系统。 随口问我一句，是不是圈内常说的养龙虾。 当下我一时语塞，含糊回了一句好像不是。 事后静下心，完整梳理自己整套工作架构。 再对照市面上 OpenClaw 标准龙虾项目的运作模式，才算把这件事彻底理清，分清我这套方案和通用龙虾体系的异同。 也看懂如今大模型厂商靠自主智能体实现稳定商业化变现的底层逻辑。 先说基础问题，市面上大家口中的养龙虾到底是什么？圈内说的龙虾名字来自开源智能体框架 OpenClaw 工具图标是小龙虾。 玩家长期部署调度多自主 AI 代理。 持续投喂云端 API 算力，让 AI 全自动循环干活，这套行为就被戏称养龙虾。 标准龙虾的运行逻辑十分统一。 以 OpenClaw 作为调度外壳，代码编写、任务规划、报错复盘、批量试错全部交给云端付费大模型承担，程序直接获取本机全盘读写权限。 还会调用浏览器底层调试接口，全自动操控终端、网页、本地文件，全程几乎不需要人工介入。 这种模式有两个很突出的短板。 第一是 token 消耗极其夸张，AI自主多轮循环交互，消耗量是普通单次对话的几十倍。 第二是安全风险极高，它需要放开系统全域权限。 还要打通浏览器底层调试通道，自动化注入脚本操控页面的行为，和木马恶意程序操作逻辑几乎没有区别。 乌邦图 22.04环境下， Firefox 自带极强安全防护，会主动限制这类底层接管操作。 强行打通会直接带来账号登录凭证、二次验证信息泄露的巨大隐患。 这也是我从最开始就完全拒绝使用 OpenClaw 的核心原因。 再回答核心疑问，我的这套自动化体系算不算养龙虾？分广义狭义两个维度看，结论完全不同。 从广义行业定义来讲，我确实属于养龙虾范畴。 我搭建了一套自研定时调度的多角色 Agent 的集群。 划分研究、迷宫探索、 QA 测试、 bug 修复、个人助理多个分工，依靠火山方舟 cloud coding 付费套餐提供云端算力。 让 AI 自主闭环完成编程、系统迭代、迷宫探索等重复性工作。 大量自主调用会持续消耗云端 token 额度，消耗速度很快。 即便开通两份 coding plan pro 包月套餐轮换使用，多 agent 并发运行时依旧会触达5小时滑动窗口限流，只能阶段性关停集群，压低消耗。 这种长期运行多 AI 代理，持续消耗付费云端算力，自动执行任务的核心行为和养龙虾完全重合。 这也是同学一眼联想到龙虾项目的根本原因。 单从狭义标准 OpenClaw 原版龙虾的角度区分，我的方案和市面主流做法存在多处本质区别，并不能算作传统意义上的养龙虾。 第一，调度底层完全独立。 主流养龙虾直接套用现成 OpenClaw 框架做任务分发，我全程自研 Timer 定时调度逻辑。 没有接入 OpenClaw 所有角色分配、回调执行规则都是自行设计搭建。 第二，算力采用高低分层分流设计，主动压低云端 token 消耗。 市面上绝大多数龙虾项目不分任务轻重，所有试错、探索、穷举工作全部丢给付费云端模型，算力损耗无法控制。 我做了硬性任务划分，高价值、高推理难度的工作交给火山 cloud 云端模型，包含架构设计、复杂 bug 修复。 整体战略规划、标准化脚本编写、项目经验沉淀，所有大批量、重复试错、迷宫探索类消耗型任务全部交给本地 llama 部署的 qwen 2.5 7B开源模型处理。 完全不占用火山引擎 token，依托笔记本 RTX 4050M 6G 显卡离线推理，以此拉长云端套餐可用周期。 第三， 硬件采用两组独立物理设备充当隔离沙盒，权限边界清晰可控。 标准龙虾直接在单台主机运行，无隔离，全盘无限制读写文件。 我准备两台独立设备作为专用沙盒。 一台旧笔记本、一台8 g 内存树莓派5，均搭载 Ubuntu 22.04系统。 两台设备互相打通 SSH 密钥登录，可通过 IP 互通访问。 程序项目数据依靠 Git 同步共享，两台设备都部署运行 Cloud 的相关任务。 这两台沙盒设备可以放开权限，随意调试折腾。 即便出现漏洞异常，也不会影响核心设备。 而运行欧拉嘛，承载本地显卡算力的主力笔记本和两台沙盒物理隔绝。 沙盒无法反向访问主力机，从硬件层面最大化保障本机数据安全。 第四，浏览器交互放弃底层全自动接管，改用人工中转规避安全漏洞。 标准龙虾会打通浏览器调试接口，全自动操作页面，极易泄露账号密码、二次验证凭证。 我没有开放底层操控权限。 浏览器 F12调试面板的页面数据、接口内容全部手动复制，截图中转给到模型，由模型输出 JS 脚本后再手动落地执行。 虽然操作效率大幅下降，但彻底规避自动化接管浏览器带来的账号安全风险，也不用对抗 Firefox 原生的安全限制。 第五， 云端算力扩容存在硬性约束。 市面主流龙虾大多依托通用 APP 按量计费，理论上可以通过持续充值提升算力供给。 但火山方舟 Coding Plan 不存在临时扩容、增购额度的通道。 额度耗尽，只能等待周期自动刷新。 仅靠两份 PRO 套餐轮换，依旧难以支撑全天多 Agent 稳定运行。 最后聊聊这套模式带来的直观商业变化。 也是我近期最深的感受。 以往普通人使用大模型只是单次一问一答，Token 消耗量极低，依靠免费额度或是低价轻量套餐就能满足需求。 各大模型厂商很难拿到稳定现金流。 但养龙虾这类自主智能体模式普及后，AI 会自主循环发起调用，形成刚性持续的算力消费需求。 像我这样重度使用者，每月需要两份高价 PRO 套餐，额度依旧紧张。 厂商由此获得稳定高额的月度收入，相当于终于找到了可持续落地的规模化变现路径。 整体总结，抛开资源调度、硬件隔离、算力分层这些细节不谈，只看多 AI 代理长期自主运行，持续消耗付费云端算力，完成自动化任务这个核心行为。 我广义上确实算是在养龙虾。 但对比市面上通用 OpenClaw 的标准实现方案，我的架构做了大量安全隔离、算力分流的改良设计。 是一套高安全、轻量化、自主优化后的变体，和大众认知里原生的龙虾项目存在明显区分。 最关键的一点，我全程没有部署体验过 OpenClaw，一开始就出于系统安全考量，排斥这套工具。 直到旁人点出养龙虾这个行业说法，结合自身整套架构复盘对比，才完整理清二者之间的关联与差异。
英文翻译
back to top