万字图文拆解龙虾的技术架构：从 Gateway 到自进化

一、为什么你需要了解龙虾的"内脏"？

上期小编带大家选龙虾、避坑、配了四大进阶功能（子 Agent / Cron / Skills / 专家团队），评论区不少小伙伴追问更深的问题：

“子 Agent 到底怎么调度的？”
“记忆系统为什么有时候’失忆’？”
“Skills 和 Tools 到底啥区别？”

这些问题，不看架构真回答不了。

打个比方——你开了一年的车，发动机在哪、变速箱怎么工作完全不知道。平时没事，一旦出了毛病，只能"重启试试"。但如果你知道引擎的基本原理，至少能分辨"是不是该加油了"和"是不是该送修了"。

今天这篇就是龙虾的"维修手册"。看完之后：

• • 你能说清楚一条消息从发出到回复经过了哪些环节
• • 你知道为什么有些功能需要"解锁"才能用
• • 你能理解生态里那些 NanoClaw、PicoClaw 跟 OpenClaw 到底什么关系

准备好了？咱们开壳。

二、龙虾的骨架——总览架构

2.1 一只龙虾的"器官分布图"

先上一张全景图，让你心里有个数：

看着一堆方块头大？正常。小编第一次看也是这感觉。换成人话其实就一句：

💡一句话总结：OpenClaw = 一个永远在线的管家（Gateway） + 一个会思考的大脑（Agent Loop） +30 多只触手（Channels）去够你的各种聊天工具 + 一堆专业技能包（Tools/Skills/Memory 等）。

如果非要用一个类比——OpenClaw 就像一个章鱼型智能管家：

• • 身体中枢（Gateway）永远在家待命
• • 大脑（Agent Loop）负责思考和决策
• • 30 多只触手（Channels）同时伸进微信、Telegram、Slack 等聊天工具里
• • 身上的工具带（Tools/Skills）随时掏出需要的家伙事

2.2 Gateway：龙虾的"脊椎"

💡一句话定义：Gateway 是 OpenClaw 的常驻进程，相当于你家的智能家居中枢——始终开着，所有设备和服务都通过它连接和通信。

核心特征：一台机器只跑一个 Gateway。

为什么这么设计？想想你家的路由器——你不会在家里装三个路由器让它们打架吧？Gateway 就是龙虾的"路由器"：

Gateway 对外暴露两种接口：

① WebSocket 协议（主力通信）

连接建立 → 发送 connect 帧 → 开始收发消息

所有实时通信走 WebSocket：聊天消息、工具调用结果、Agent 状态变化——全部是实时推送，不需要轮询。

② HTTP API（兼容生态）

/v1/chat/completions ← OpenAI 兼容格式/v1/models ← 查看可用模型/v1/embeddings ← 向量化接口/tools/invoke ← 直接调用工具

小编第一次看到这个设计时就想："哦，原来龙虾把自己伪装成了一个 OpenAI API 服务。"这意味着任何支持 OpenAI 格式的客户端，都能直接对接龙虾。含机量爆表。

2.3 Gateway 的认证三板斧

安全问题不能马虎。Gateway 支持三种认证方式：

┌────────────────────────────────────────────────────┐│ 认证方式 │├─────────────────┬──────────────────┬───────────────┤│ 共享密钥 │ Tailscale 身份 │ 设备配对 ││ (token) │ (零配置VPN) │ (挑战-签名) │├─────────────────┼──────────────────┼───────────────┤│ 最简单 │ 最安全 │ 最灵活 ││ 本地开发用 │ 远程访问用 | 多设备用 │└─────────────────┴──────────────────┴───────────────┘

设备配对机制是 v3 版本新增的，原理类似蓝牙配对：第一次连接时双方交换公钥，之后用签名验证身份。一个设备配对后，换个 IP 地址也能认出来——这对远程办公的数字游民特别友好，在咖啡厅换了 WiFi 也不用重新登录。

小编自己的用法：本地开发用共享密钥（简单），手机远程连的时候走 Tailscale（安全不折腾）。设备配对留给那些"我有三台电脑一台手机都想连龙虾"的硬核用户。

三、大脑中枢——Agentic Loop 与上下文引擎

3.1 Agentic Loop：龙虾的"思维循环"

说白了，Agentic Loop 就是龙虾的"想-做-看-再想"循环。你给它一个任务，它不是一口气从头干到尾，而是一边干一边想——干完一步回头看看结果，再决定下一步怎么走。

每当你发一条消息给龙虾，以下流程就会启动：

举个具体例子，你就懂了：

步骤1：消息进入

你在微信里说了句"帮我查一下明天北京天气"。这条消息通过 Channel 到达 Gateway，Gateway 触发一次agentRPC 调用。

关键点：RPC 会立刻返回一个runId，不会等 AI 想完才回复。这就是为什么你发消息后龙虾会先显示"正在思考…"。

步骤2：上下文组装

这一步决定了 AI 能"看到"什么。系统会拼装出一个完整的 Prompt：

最终 Prompt = 基础系统提示 + Skills 提示（当前激活的技能） + Bootstrap 上下文（启动仪式信息） + 历史对话记录 + 本次用户消息

步骤3：模型推理

拼好的 Prompt 发给 LLM（Claude、GPT、Gemini……OpenClaw 支持 20+ 个 Provider）。模型决定：是直接回答，还是先调用工具？

步骤4：工具执行（如果需要）

假如模型说"我要调用 web_search 工具查天气"——系统就会在沙箱里执行这个工具，拿到结果后回到步骤2，把工具结果也塞进上下文，让模型再想一遍。

这个"想-做-再想"的循环可以重复多次，直到模型觉得"好了，我可以直接回答了"。

步骤5：流式输出

最终回复通过 WebSocket 实时推送给你——你能看到文字一个一个蹦出来，就是这个流式机制在起作用。

用伪代码看透 Agentic Loop

上面的步骤看着好像挺简单？但小编当时一直有个疑惑："循环"到底怎么知道该停？万一它死循环了呢？

后来看了源码才真正明白。来，小编把核心逻辑用伪代码摊开给你看——你一看就懂的那种：

async defagentic_loop(user_message, session): """ 龙虾的大脑循环——一条消息进来后的完整处理流程。 注意：这不是真实源码，是小编读完源码后"翻译"出来的伪代码。 """ # ───────────────────────────────────────── # 第一步：生成 runId，立刻返回给前端 # 这就是为什么你发完消息，龙虾瞬间就显示"思考中..." # ───────────────────────────────────────── run_id = generate_unique_id() notify_client(run_id, status="thinking") # ───────────────────────────────────────── # 第二步：组装上下文（决定 AI 这一轮"看到"什么） # ───────────────────────────────────────── context = assemble_context( system_prompt=load_system_prompt(), # 角色设定 skills=get_active_skills(session), # 当前激活的技能 history=session.get_recent_messages(), # 历史对话 user_msg=user_message # 本次消息 ) # ───────────────────────────────────────── # 第三步：核心循环——"想-做-再想" # 关键点：不是无限循环，有三重退出机制 # ───────────────────────────────────────── max_turns = 50 # 硬上限：最多循环 50 轮 timeout = 48 * 3600 # 超时：48 小时（没错，真有这么长） start_time = now() for turn inrange(max_turns): # 超时检查 if now() - start_time > timeout: break # 调用 LLM 推理 response = await call_llm( context=context, model=session.get_model(), # Claude/GPT/Gemini/... stream=True # 流式输出 ) # ─── 关键判断：看 stop_reason 决定下一步 ─── # Claude API 返回 stop_reason="tool_use" 表示要调工具 # 返回 stop_reason="end_turn" 表示想直接回复 # （OpenAI 用 finish_reason="tool_calls" vs "stop"，原理一样） if response.stop_reason == "tool_use": # 模型说"我要调工具"→ 执行工具，把结果塞回上下文 for tool_call in response.tool_calls: result = await execute_tool( tool=tool_call.name, params=tool_call.arguments, sandbox=session.sandbox # 在沙箱里执行 ) # 关键：工具结果以 tool_result 角色追加到对话 context.append({ "role": "tool_result", "tool_use_id": tool_call.id, "content": result }) # 工具执行完 → 回到循环顶部，让模型再想一遍 continue else: # stop_reason == "end_turn" # 模型说"我想好了，直接回复"→ 跳出循环 final_reply = response.text break # ───────────────────────────────────────── # 第四步：流式推送最终回复 # ───────────────────────────────────────── stream_to_client(run_id, final_reply) # ───────────────────────────────────────── # 第五步：善后工作（用户看不到的后台操作） # ───────────────────────────────────────── session.save_messages() # 持久化对话记录 session.update_memory() # 更新短期记忆 release_write_lock(session) # 释放写锁，允许下一条消息进来

看完这段伪代码，几个关键点小编帮你划重点：

① 为什么"立刻返回 runId"？

你发消息后龙虾瞬间就有反应（“思考中…”），不是因为它想得快，而是run_id在 LLM 还没开始推理时就返回了。前端拿到run_id就知道"收到了，正在处理"——用户体验拉满。

② 循环不会死循环——三重保险

说实话，小编一开始看到 48 小时超时时愣了一下——什么任务需要跑两天？后来想明白了：复杂的编程任务（比如让龙虾重构一整个项目），模型可能要反复调用几十次工具，每次工具执行也要时间。48 小时是"理论上限"，正常使用几分钟就结束了。

③stop_reason才是循环的"方向盘"

整个循环只看 LLM 返回的一个字段：stop_reason。

• •stop_reason == "tool_use"→ 模型想调工具 →continue（回去再想）
• •stop_reason == "end_turn"→ 模型想直接说话 →break（结束）

就这么简单。不是你的代码决定"该不该调工具"，是LLM 自己决定的。你只需要看它的stop_reason就知道下一步干嘛。

小编第一次理解这个设计时恍然大悟——所谓"Agentic"，核心不是什么复杂的状态机或调度器，就是一个 while 循环 + 模型自主判断。优雅到让人想鼓掌。

④tool_result怎么"喂"回去的？

这个细节很多教程不说，但其实很关键：工具执行完之后，结果不是随便塞进去的——它以一个特殊的tool_result角色追加到对话消息列表里，同时带上tool_use_id跟之前的工具调用对应。

为什么要这么麻烦？因为一轮推理里模型可能同时调多个工具（比如同时搜三个网站），你需要用id让模型知道"这个结果是哪个工具返回的"。

一个更真实的例子：多轮工具调用

光看伪代码可能还是抽象。小编再给你画一个"真实场景"的执行流程——你让龙虾"帮我查一下明天北京天气，顺便推荐穿什么衣服"：

你："帮我查明天北京天气，推荐穿什么"│├─ 【循环第 1 轮】│ ├─ LLM 推理："我需要先查天气"│ ├─ 工具调用：web_search("北京 明天 天气")│ ├─ 工具返回："明天北京，晴，28-35°C，紫外线强"│ └─ → continue（回去再想）│├─ 【循环第 2 轮】│ ├─ LLM 推理："知道天气了，我可以直接推荐穿搭"│ ├─ 无工具调用 → 直接生成回复│ └─ → break（结束循环）│└─ 最终回复："明天北京 28-35°C，建议穿短袖+防晒衫……"

只转了 2 轮。但如果你问的是"帮我对比三家机票价格"，可能要转 5-6 轮（每家航司搜一次）。循环次数取决于任务复杂度，不是固定的。

和普通 Chat API 的本质区别

你可能想：“这不就是多调几次 API 吗？我自己写个 for 循环也行啊。”

嗯……技术上确实可以。但 Agentic Loop 比"for 循环调 API"多了几个关键能力：

“Agentic 不是让你写循环，而是让 AI 自己决定’我还需要做什么’。这个’自主决策’才是核心价值。”

3.2 队列与并发控制：别让龙虾"精分"

这里有个很重要的设计：每个 Session 的 Agent 运行是串行的。

为什么？想象你同时对龙虾说了三句话：

你：帮我写封邮件你：顺便查下今天股票你：把昨天的会议纪要整理一下

如果三个请求同时跑，它们会抢着读写同一个对话历史——就像三个人同时在一张纸上写字，乱套了。

OpenClaw 的解法：Session 级队列 + 全局队列。

Session 队列：同一个对话的请求排队执行，保证上下文一致性全局队列： 可选的全局限流，防止 token 费用失控

队列还支持几种"插队模式"：

3.3 上下文引擎（Context Engine）：决定 AI "看到"什么

上下文引擎这东西……怎么说呢，平时你完全感受不到它的存在。但一旦出问题，你就知道它有多重要了。

RAG 80% 的问题出在信息检索那一步，而 Agent 80% 的问题出在上下文给错了——AI 不是不会答，是它根本没"看到"该看的东西。

上下文引擎有四个生命周期阶段：

┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐│ Ingest │ → │ Assemble │ → │ Compact │ → │AfterTurn ││ 存储索引 │ │ 组装上下文│ │ 压缩历史 │ │ 持久化 │└──────────┘ └──────────┘ └──────────┘ └──────────┘

Ingest：新消息来了，先存起来、建索引
Assemble：开始思考前，在 token 预算内组装最佳上下文
Compact：历史太长时，用 LLM 总结旧对话（省 token）
AfterTurn：一轮对话结束，持久化状态，触发后台压缩

这里有个彩蛋：上下文引擎是可插拔的。不满意默认的？自己写一个替上去。社区有人做了跨 Session 记忆召回插件——上周聊的内容，这周也能被"想起来"。

3.4 Session 管理：每段对话的"容器"

Session 就是一段对话的"容器"。你跟龙虾聊天时，所有消息都存在一个 Session 里——它决定了 AI 能记住多少"之前说过的话"。

路由规则挺直观的：

Session 的生命周期：

默认情况下，Session 每天凌晨 4 点自动重置。为什么？

说实话小编一开始也觉得奇怪——为什么要重置？后来想明白了：如果一个 Session 跑了一个月，对话历史会长到离谱，压缩再多也扛不住。每天重置就像"睡一觉起来"——龙虾醒来时记忆清爽，但长期记忆还在 Memory 里。

3.5 定时任务系统（Cron + Heartbeat）

Cron 没什么神秘的，就是龙虾的"闹钟"——你设个时间，它到点干活。

OpenClaw 有两种定时机制：

① Cron 定时任务

"每天早上 8 点总结我的邮件""每周五下午提醒我写周报""每隔 1 小时检查一次服务器状态"

Cron 任务在独立 Session 里执行，不会干扰你的日常对话。

② Heartbeat 心跳

这个更有意思——它不是你设定的闹钟，而是龙虾自己觉得需要检查的事情。

工作原理：Gateway 定期（默认每 15-30 分钟）"敲门"问一下 Agent："有什么需要跟进的吗？"Agent 会检查自己的 HEARTBEAT.md 清单，看看有没有到期的承诺或者需要主动推送的信息。

这就是为什么有时候你没说话，龙虾突然冒出来一句"嘿，你上午说的那个会议快开始了"——不是它在偷偷监控你，而是心跳机制触发了它去检查待办事项。

“不骗你，小编第一次被龙虾主动提醒时还吓了一跳。后来发现是自己设了个备忘录忘了。”

四、双手双脚——工具系统、渠道与子 Agent

4.1 工具系统（Tools）：龙虾的"瑞士军刀"

Tools 就是龙虾的"手"——光会想不行，得能动手干活。读文件、搜网页、执行代码、发消息，每一个具体动作就是一个 Tool。

OpenClaw 内置了几十个工具，小编给你按功能归了个类：

工具权限控制是分层的——这点很重要：

全局配置 → Agent 配置 → Channel 策略 → Provider 限制 → 沙箱规则 ↓ ↓ "这个 Agent 能用哪些工具" "这个工具在沙箱里能干啥"

举个例子：你可以配置"在群聊里，龙虾不能执行代码"（Channel 策略），同时"在私聊里什么都能用"（默认策略）。

小编自己用下来，最常用的工具组合是：web_search+read+write。基本上能覆盖 80% 的日常需求。

一个容易忽略的点：工具配置文件（Profiles）

OpenClaw 预设了几套工具组合模板：

你可以在不同的 Channel 里用不同的 Profile。比如群聊里只开messaging（防止龙虾在群里执行危险命令），私聊里给full。这比一个个关工具省事多了。

4.2 Channels：龙虾的 30+ 只触手

Channel 这个词听着高级，其实就是"连着哪个聊天软件"。

你品——大多数 AI 工具要你打开一个新网页、或者装一个新 App 才能用。但 OpenClaw 不是。它不要求你换地方聊天。你平时用微信就在微信里聊，用 Telegram 就在 Telegram 里聊。龙虾自己跑过来找你，而不是你去找它。

截至目前，OpenClaw 支持30+ 个 Channel：

30 多个渠道是什么概念？大多数 AI Agent 竞品能支持 3-5 个就不错了。OpenClaw 直接把能接的全接了——你日常用的聊天软件，大概率已经在列表里了。

每个 Channel 的底层实现用的是对应平台的 SDK/协议：

• • WhatsApp → Baileys 库（非官方 API）
• • Telegram → grammY 框架
• • Discord → Discord.js
• • Slack → Bolt 框架

4.3 SubAgent：龙虾的"分身术"

上期讲了子 Agent 怎么配、什么场景用——今天看看它底层是怎么转的。

简单说：SubAgent 就是主 Agent 派出去干活的"分身"——有自己的脑子，干完事回来汇报。

核心架构：

┌─────────────────────────────────────────┐│ 主 Agent (Session A) ││ ││ "我需要同时查三个竞品的信息" ││ ││ sessions_spawn → ┬→ SubAgent 1 (查竞品A) ││ ├→ SubAgent 2 (查竞品B) ││ └→ SubAgent 3 (查竞品C) ││ ││ ← 结果汇报 ←────────────────────────────┘│ ││ "综合三个结果，给你做个对比表……" │└─────────────────────────────────────────┘

两种上下文模式：

关键设计决策：子 Agent 没有 message 工具。

为什么？想想看——如果子 Agent 能直接发消息给用户，多个子 Agent 同时回复就乱套了。所以子 Agent 只能把结果"交还"给主 Agent，由主 Agent 统一汇报。

这就像项目经理开会，不是让每个组员都直接跟老板汇报，而是项目经理汇总后统一说。

嵌套深度可配置：子 Agent 还能再派子 Agent——形成"主管→组长→组员"的层级。但小编建议最多两层就够了，再深就是套娃了，调试起来头疼。

{ agents: { defaults: { subAgents: { maxNestingDepth: 2 // 最多嵌套两层 } } }}

4.4 Sandbox 沙箱系统：龙虾的"安全笼"

小编当初不太在意沙箱这个概念……直到有一次龙虾执行了一个rm -rf命令。

幸好是在 Docker 沙箱里。不然我的 Mac 就要"从从容容格式化，匆匆忙忙恢复数据"了。

所以沙箱是什么？就是一个"笼子"——龙虾干活时不是直接在你电脑上裸奔，而是被关在一个受控环境里。搞砸了也只是笼子里的事。

三种沙箱模式：

三种沙箱后端：

┌──────────────────────────────────────────────────────┐│ 沙箱后端选择 │├────────────┬────────────────┬────────────────────────┤│ Docker │ SSH │ OpenShell ││ (默认) │ (远程) │ (托管服务) │├────────────┼────────────────┼────────────────────────┤│ 本地容器 │ SSH 到远程机器 │ 云端托管沙箱 ││ 完全隔离 │ 把重活甩出去 │ 带文件同步 ││ 支持 GPU │ 灵活性最高 │ 无需管理 │└────────────┴────────────────┴────────────────────────┘

Docker 沙箱的亮点：

• • GPU 直通：需要跑 ML 模型时可以穿透 GPU
• • 网络隔离：默认不给网络，防止恶意外连
• • 自定义镜像：可以预装你需要的开发环境
• • Docker-out-of-Docker：沙箱里也能操作 Docker（套娃）

什么不会被沙箱？

• • Gateway 本身（它是宿主机进程）
• • 被标记为"elevated"的特权工具
• • 明确配置为免沙箱的操作

4.5 工作区与 Agent 路由：谁来接你的消息

当你有多个 Agent时（比如一个工作 Agent、一个生活 Agent），消息路由决定"谁来回答"。

路由优先级（从高到低）：

1. 精确匹配 peer（私聊对象）2. 父级 peer 匹配（线程继承）3. Guild + 角色匹配（Discord 场景）4. Team 匹配（Slack 场景）5. Account 匹配6. Channel 级匹配7. 默认 Agent（兜底）

小编的实践经验：大多数人只需要一个 Agent 就够了。多 Agent 适合组织/团队场景——比如公司的 HR 问题走 HR Agent，技术问题走 Tech Agent。

还有一种玩法叫Delegate（委托代理）：Agent 以你的身份去跟别人沟通。分三个等级：

Tier 3 目前只有极少数人敢开——毕竟让 AI 全权代表你发消息……想想就刺激。小编暂时停留在 Tier 1，让它帮我拟草稿已经够省心了。

五、进化之路——记忆、技能与自我升级

5.1 记忆管理：龙虾的"海马体"

聊到这里，终于到了小编个人最喜欢的模块。

你有没有跟 AI 聊了半小时，结果它突然忘了你叫什么的经历？大多数 AI 的"记忆"就是对话历史——上下文窗口一满，前面说的话就被挤掉了。就像金鱼，7 秒一个轮回。

龙虾不一样。它的记忆是独立存储的 Markdown 文件，跟对话历史彻底分开：

~/.openclaw/workspace/├── MEMORY.md ← 长期记忆（每次对话必加载）├── memory/│ ├── 2026-06-13.md ← 今天的笔记│ ├── 2026-06-12.md ← 昨天的笔记│ └── ...└── DREAMS.md ← 做梦日记（可选）

记忆的三层结构：

等等——龙虾还会"做梦"？

对，你没看错。Dreaming 系统，正儿八经的功能名。当然不是真做梦，而是一套凌晨自动运行的后台记忆巩固机制：

Deep 阶段的打分机制：

系统用 6 个加权信号来决定一条记忆是否"值得长期保留"：

“我用了大概一个月，有一天让它写代码，它自动用了我习惯的命名风格。那一刻感觉……有点诡异，又有点爽。”

记忆后端可插拔：

5.2 Skills 模块：龙虾的"技能树"

Skills 之前的文章已经详细聊过用法和推荐了，这里不重复概念，直接从架构角度说几个你可能不知道的细节。

（不记得的同学回顾一下：万字图文:从 Function Calling 到 MCP 再到 Skills：AI 工具调用的三次进化）

Skills 加载优先级（从高到低）：

1. 工作区 Skills ← <workspace>/skills/2. 项目 Agent Skills ← <workspace>/.agents/skills/3. 个人 Agent Skills ← ~/.agents/skills/4. 托管/本地 Skills ← ~/.openclaw/skills/5. 内置 Skills ← 随安装包自带6. 额外目录 Skills ← 配置指定的路径 + 插件提供

优先级高的覆盖低的。换句话说——你写的 Skill 能"压过"系统自带的。自己的规矩，自己说了算。

ClawHub：Skills 的"应用商店"

OpenClaw 有自己的 Skill 注册中心 clawhub.ai：

# 安装一个 Skillopenclaw skills install <slug># 从 Git 安装openclaw skills install git:owner/repo@ref# 更新所有 Skillsopenclaw skills update --all# 验证 Skill 安全性openclaw skills verify <slug>

每个 Skill 在发布前都会经过安全扫描（VirusTotal + ClawScan），防止恶意代码混入。

Skill Workshop：龙虾会"自学"

这个功能一开始小编没注意到，后来用了一段时间才发现——龙虾干活干多了，会自己总结规律，草拟一个 Skill 提案。但它不会偷偷生效，而是放在"Workshop"里等你审批。

龙虾发现规律 → 草拟 Skill 提案 → 放入 Workshop → 用户审核通过 → 正式生效

这就像一个实习生——做着做着总结了一套方法论，写成文档给你看，你觉得靠谱就留下。

5.3 自进化机制：龙虾越用越聪明

别误会——龙虾的"自进化"不是自己偷偷改代码（那就恐怖片了）。它的进化方式比你想象的温和：

① Dreaming（记忆进化）

前面讲过了——通过"做梦"巩固记忆，越用越了解你。

② Skill Workshop（行为进化）

发现新模式 → 草拟 Skill → 审核通过 → 永久获得新能力。

③ Commitments（短期跟进）

这是个隐藏机制：龙虾会在后台推断"我应该跟进什么"——

用户说："明天记得提醒我交报告"龙虾（后台）：创建一个 Commitment，明天早上心跳时检查并提醒

Commitment 是短期的、用后即弃的"便签"。跟长期记忆不同，它更像手机上的"提醒事项"。

三个机制组合起来，形成了一个闭环进化系统：

“代码跑通了，不代表你理解了。但龙虾跑通了，它真的在’理解’——而且会越来越理解。”

六、龙虾家族——OpenClaw 生态全景

6.1 为什么会有这么多"虾"？

OpenClaw 一开源，社区立刻炸了——但不是每个人都想用这么"重"的东西。TypeScript 写的，70+ 依赖，功能全但也肥。

学习的人嫌看不懂源码，搞安全的人嫌隔离不够狠，玩硬件的人一看内存占用——得，我那 10块钱 的板子根本跑不动。

于是大家各自动手，按自己的需求"重造轮子"。这不是分裂，这是开源生态的正常繁殖方式。统称：Claw 家族。

6.2 学 Agent 结构：轻量派

Nanobot（Python，44K Stars）

定位：超轻量、可读性极强的 Python Agent核心：~5000 行代码实现完整 Agent 循环语言：Python创建：2026-02（香港大学出品）

为什么小编推荐它来学习：

• • 核心 Agent Loop 只有 5000 行 Python，一下午能看完
• • 支持 WebUI、聊天渠道、Tools、Memory、MCP
• • 有模型路由，能切换不同 Provider
• • Python 写的，对国内开发者友好

适合人群：想看懂"一个 Agent 到底怎么跑起来"的人。

NanoClaw（TypeScript，30K Stars）

定位：安全隔离优先的轻量 Agent核心：每个 Agent 跑在自己的 Linux 容器里语言：TypeScript创建：2026-01口号："Small enough to understand. Secure by isolation."

跟 OpenClaw 的核心区别：

“如果 OpenClaw 是一个有保安的大楼，NanoClaw 就是给每个住户装了独立大门——保安失职了也没事。”

6.3 生产部署：企业派

IronClaw（Rust，12K Stars）

定位：安全第一的 Agent OS核心：Rust 重写，独立状态根语言：Rust创建：2026-02（NEAR AI 出品）口号："Agent OS focused on privacy, security and extensibility"

IronClaw 面向对安全性有极高要求的场景——企业级、金融级、政务级。用 Rust 写意味着内存安全有保障，不会出现 TypeScript 那种"原型链污染"之类的安全漏洞。

小编没有深度用过 IronClaw（毕竟个人用户用不到这么重的安全方案），但看了它的架构有一点很有意思：独立状态根。什么意思？OpenClaw 的所有数据都在~/.openclaw/一个目录里，而 IronClaw 给每个 Agent 完全独立的文件系统根——一个 Agent 被攻破了，不会波及其他 Agent 的数据。这在企业多租户场景里很重要。

Spacebot（Rust，2.3K Stars）

定位：面向团队和社区的 Agent 框架核心：结构化图存储替代 Markdown 记忆语言：Rust创建：2026-02（Spacedrive 团队出品）口号："State belongs in structured storage, not markdown files"

Spacebot 的独特设计：

OpenClaw 的记忆用 Markdown 文件——简单直接，但多人协作时就尴尬了。Spacebot 用SQLite 里的类型化图存储替代，适合团队场景。

它有五种进程类型：

6.4 硬件玩家：极客派

PicoClaw（Go，29K Stars）

定位：跑在 $10 硬件上的 AI Agent核心：<10MB 内存即可运行语言：Go创建：2026-02（Sipeed 矽速科技出品）口号："99% less memory than OpenClaw and 98% cheaper than a Mac mini"

一只"龙虾"需要 Mac 级硬件才能跑？

PicoClaw 说：不需要。

10 块钱的开发板就行。

就 10 块钱。

支持的硬件架构：RISC-V、ARM64、MIPS、LoongArch（龙芯）。

甚至出了专用硬件：LicheeRV-Claw——一块淘宝/AliExpress 能买到的开发板，插上就是一个硬件龙虾。

适合人群：IoT 开发者、智能家居 DIY 玩家、想让龙虾跑在树莓派上的极客。

ZeroClaw / zClaw（Rust，32K Stars）

定位：单二进制、全自主、极速部署核心：一个可执行文件搞定一切语言：Rust创建：2026-02口号："Deploy anywhere, swap anything"

核心特点：

• •单二进制部署：一个文件扔上去就跑，不用装依赖
• •硬件感知：直接操作 GPIO/I2C/SPI/USB
• •安全沙箱：Landlock/Bubblewrap/Seatbelt/Docker 四选一
• •工具签名：每次工具调用都有加密签名，审计追踪
• •YOLO 模式：开发时关掉所有限制，快速迭代

“zClaw 是 Claw 家族里最’硬核’的——Rust 写的，能操作硬件，还有加密审计。如果 OpenClaw 是智能手机，zClaw 就是瑞士手表。”

6.5 全景对比表

6.6 怎么选？小编的建议

别在选型上精神内耗了，直接看这个决策树：

七、写在最后

好了，万字看到这里，你对龙虾的内脏应该摸得差不多了。

小编写这篇文章的时候，自己也重新梳理了一遍——说实话有些模块我之前也是稀里糊涂在用，比如上下文引擎和 Dreaming 系统，真正看懂架构之后才明白"哦，原来它是这么工作的"。

如果让我用一句话总结 OpenClaw 的设计哲学，大概是：所有状态都是 Markdown 文件，所有模块都能换。

记忆是 Markdown，Skills 是 Markdown，连梦境日记都是 Markdown。你随时能打开看龙虾脑子里在想啥——不黑箱，不玄学。哪个模块不满意？换一个插件就行，上下文引擎、记忆后端、沙箱后端、模型 Provider，全部可插拔。

这种"透明+可控"的感觉，用久了会上瘾。

“会用工具的人和理解工具的人，差距会越来越大。但好消息是——你已经在理解了。”

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】