“小龙虾”这个代号我在项目里用了大半年，一开始纯属随手起的，因为团队里讨论OpenClaw的时候总容易跟另一个内部项目搞混，就叫顺口了。但没想到这个名字在社区里慢慢传开，经常有人问“小龙虾是不是你们给OpenClaw起的官方中文名”，我每次都解释一遍。今天干脆把这大半年的部署、使用、踩坑记录整理成一份完整文档，从零开始，把OpenClaw从安装到实战的全过程都写清楚，包括安卓端Termux部署、Ollama本地模型对接、ROS2环境集成、Skill技能开发这些大家问得最多的问题。
这套文档不挑基础，纯小白也能照着一步步操作，玩过智能体框架的可以跳过基础章节直接看3.2和第四章的排查记录。我先说结论：OpenClaw这个框架最大的优势不是功能多，而是它的接入层设计得非常干净，不管你是想用云端API还是本地模型，不管你想跑在PC上还是手机上，也不管你要对接聊天、电商还是机器人硬件，它都能用同一套核心逻辑跑起来。这也是我当初选它而不是自己造轮子的根本原因。
1. 项目整体设计与思路拆解
1.1 OpenClaw到底是什么
先给新朋友说清楚OpenClaw是什么。它是一个开源的个人智能体框架，核心做的事情是：把大模型（LLM）跟外部工具、技能、执行环境连接起来，让AI不只是一个聊天的窗口，而是一个能真正调工具、读文件、跑流程、操作系统的“代理”。你可以理解成给大模型装了一副手脚。
为什么叫“Claw”？因为钳子。这个名字挺有意思的，一只钳子夹住模型，一只钳子夹住工具，中间靠一套规则把两边做配对。OpenClaw的前身是另外一个个人助理项目，作者在跑通了本地模型和云端模型的混合调度之后，把整个框架重写开源了，所以我接触到的这个版本，天生就对“本地模型优先”这件事支持得特别到位。
再说“小龙虾”的来历。因为我第一次在内网部署OpenClaw的时候，给仓库起的别名就是crayfish，后来同事们叫习惯了。如果你在外面看到有人说“小龙虾部署”，基本就是指OpenClaw的部署，只是大家图方便起了个花名。
1.2 OpenClaw的架构分层
要理解OpenClaw，不要把它当成一个软件，要把它当成一套“中间层”。它分三层：
第一层是对接层（Adapter Layer）。这一层解决的是“模型从哪来”的问题。OpenClaw不自己训练模型，也不强迫你绑死某一家API，而是做了一套统一的模型接入抽象。你可以在配置里声明用OpenAI的API，也可以切换到本地的Ollama服务，甚至可以在同一个会话里让简单任务走本地小模型、复杂任务走云端大模型。很多人担心OpenClaw是不是只能通过接入API的方式使用算力，其实不是，用Ollama部署本地模型是完全可行的，后面3.2详细讲。
第二层是技能层（Skill Layer）。这一层解决的是“模型能干什么”的问题。OpenClaw把一系列可执行动作封装成“技能”，每个技能包含触发条件、参数定义、执行逻辑。比如“查询天气”“读取文件”“执行代码”“调用电商API下单”，都是一个个技能。模型根据用户意图选择合适的技能，然后把参数填进去，框架负责把技能真正跑起来。
第三层是运行层（Runtime Layer）。这一层解决的是“在哪里跑”的问题。OpenClaw的运行环境不挑食，x86服务器可以跑，ARM开发板可以跑，安卓手机通过Termux也能跑，而且支持跟ROS2机器人系统做集成，被动通过Gazebo仿真环境做联调。这背后的原因在于运行层是基于跨平台框架写的，依赖项不多，核心代码对资源占用控制得比较狠。
这三层各干各的活，互不干扰。我刚开始折腾的时候，一度想改技能层的东西，结果发现完全碰不到对接层的代码，这就是分层设计的好处。你不需要懂全部代码，只需要找到自己想改的那一层就够了。这也是OpenClaw最有价值的地方：它没有把“模型接入”“技能执行”“环境适配”搅成一锅粥，而是把这三件事牢牢拆开，插拔式使用。官方仓库里的文档叫OpenClaw Docs，我这份文档叫“小龙虾文档”，内容本质上是同一件事的两种记录方式。
1.3 方案选型：为什么选OpenClaw
我自己不是没写过智能体框架，早期用LangChain做过一个内部工具，做了一半就放弃了。核心原因是LangChain的抽象层次太多，出问题之后你想排查，需要从回调、链、代理、记忆这些概念里一层层翻，排查成本太高。我在OpenClaw上跑通第一个技能总共用了一个晚上，而这个时间在LangChain里可能还没把Agent的依赖理清楚。
选OpenClaw还有一个很现实的原因：它把“记忆”和“上下文管理”做得很轻。很多智能体框架会把对话历史、向量记忆、长短期存储这些东西做成必选项，还没干活就要先跑一个向量数据库，项目复杂度一下子拉爆。OpenClaw把记忆做成可选项，默认只做简单的会话上下文拼接，如果你确实需要长期记忆，再自己去接向量库。这个设计决策我非常认同，因为80%的智能体应用场景根本用不到长期记忆，硬加一个向量库纯粹是给自己找麻烦。
从资源占用角度来说，OpenClaw也占优势。我实测过，一个空载的OpenClaw常驻内存大概在150MB到300MB左右，这取决于你开了多少技能。对比其他主流智能体框架动不动上GB的常驻内存，这已经算轻量级了。而且在树莓派上跑起来的时候，OpenClaw不会像别的框架那样直接卡死，虽然推理速度还是受算力限制，但至少框架本身不会成为性能瓶颈。
2. 核心细节解析与实操要点
2.1 安装OpenClaw的两种主流方式
OpenClaw的安装方式一直在演进，从最早的源码手动编译，到现在有了相对成熟的包管理器支持，整体门槛已经降了很多。目前最推荐的方式有两个：Docker部署和源码本地部署。
Docker部署适合那些不想污染自己Python环境的人，也适合快速试玩。一条命令就能把整个框架拉起来，数据库、redis、主进程都封装在容器里。但这里有个注意点：你要是打算用Ollama做本地模型，不建议直接用Docker，因为容器内的网络和Ollama服务互联需要额外配置，容易踩坑。如果非要用Docker，可以参考这样的做法：先把Ollama安装在宿主机上，监听0.0.0.0:11434，然后Docker启动的时候加--network=host参数，这样容器直接共享宿主机网络，访问localhost:11434就能连上Ollama，避免Docker内网不通的尴尬。
源码本地部署是我个人最推荐的方式，尤其适合要写技能、改配置、深度定制的人。步骤很简单：拉取仓库源码，用Python 3.10以上的环境创建虚拟环境安装依赖。需要注意的一点是，OpenClaw有些依赖编译需要系统库支持，比如某些工具链需要libffi和libssl的dev版本，装依赖前先把这些系统包补齐。
部署这块没必要追求“看起来高级”，我见过有人非要去折腾K8s部署OpenClaw，用是能用，但纯属给自己加负担。单机部署完全够用，等真正有了多机或高可用需求再考虑容器编排，那个阶段已经是另一个话题了。
2.2 配置文件的正确打开方式
OpenClaw的配置文件采用YAML格式，核心配置集中在config目录下，主要就三个文件：一个是主配置config.yaml，一个是技能配置skills.yaml，还有一个是模型接入的models.yaml。新手上路最容易犯的错误是试图在一开始就理解所有字段，其实不需要。你只需要关注几个核心字段：
第一个是agent.name，这是给智能体取名字的，影响日志输出和会话标识。
第二个是model.default_provider和model.default_model，这两个字段决定了智能体默认使用哪家模型服务。
第三个是skill.enabled_skills列表，这里声明哪些技能处于激活状态，不在列表里的技能不会被加载。
改配置之后不需要重新编译，保存后重启服务即可生效。但有一个坑要提醒：OpenClaw的配置解析对缩进很敏感，YAML格式错一个空格，启动的时候直接报错，而且报错信息往往指向一个完全不相关的语法位置。如果你改了配置启动失败，第一件事不是去看代码，而是检查YAML缩进有没有对齐。
2.3 技能开发的核心逻辑
技能是OpenClaw最核心的扩展单元。一个技能本质上是一个Python模块，里面定义几个关键方法：定义技能元数据、接收参数并执行、返回执行结果。框架会把这个技能注册到能力列表里，模型在生成回复的时候会根据技能名称和描述决定是否调用。
写技能有个非常容易忽略的点：技能描述要写清楚“什么时候该用这个技能”和“什么时候不该用这个技能”。这个描述会直接影响模型的选择效果。比如你写一个查天气的技能，描述如果只写“查询天气”，模型在用户问天气的时候可能会调用，也可能不调用。但如果你把描述写成“当用户询问某个城市的当前天气或未来天气预报时使用，需要城市名参数”，模型命中率会明显提升。原因是LLM的工具选择很大程度依赖描述语义，描述写得越具体越准确，选错工具的概率就越低。
另一个实操心得是：技能的输入参数定义要尽量用类型注解，并写清楚每个参数的含义。OpenClaw的技能参数传递是基于JSON Schema的，模型会根据schema生成参数。如果你把一个参数定义为字符串类型，模型传数字进来也能转成字符串，不会报错。但如果你把一个参数定义为整型，模型传了“今天”这种非数字内容，框架会尝试转换失败然后报错。所以参数类型设置要跟实际业务相匹配，别为了省事全用字符串。
2.4 技能与上下文管理的协作细节
OpenClaw的上下文管理机制很有意思，它默认会把最近的N轮对话打包发送给模型，但有一个细节是，如果某个技能执行结果特别长，比如读了一个大文件返回了10万字符，框架会自动把这段结果压缩成摘要再放回对话上下文，避免把上下文撑爆。这个机制在长文档处理场景下特别好用，也解释了为什么OpenClaw在长文本场景下不容易出现约上下文长度报错，因为它在源头就做了取舍。
我一开始没搞清楚这个机制，在写日志分析技能的时候，日志文件有几万行，技能执行后直接返回了全部内容，模型立刻被撑爆，报错说超出token限制。后来翻源码才发现框架里有个large_return_summary_threshold参数，默认值是8000字符。超过了这个长度，框架会用摘要模型把执行结果压缩。你完全可以调整这个阈值，缩短到2000或者拉到50000，取决于你的模型上下文窗口有多大。这个参数在哪里配非常重要，我在3.3节配置实操里会有完整说明。
3. 实操过程与核心环节实现
3.1 源码部署OpenClaw的完整流程
我用Ubuntu 22.04虚拟机作为演示环境，Python版本3.11，这是目前最稳的组合。先把系统依赖补齐：
sudo apt update sudo apt install -y build-essential libssl-dev libffi-dev python3-dev git curl然后是拉取源码和创建虚拟环境：
git clone https://github.com/OpenClaw-project/openclaw.git cd openclaw python3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install -r requirements.txt这里有个关键提示：依赖安装时间可能比较久，因为里面有几个是源码编译安装的包，比如某些加密库和网络库，需要本地的编译器参与编译。在干净的机器上第一次装，我实测大概是15到20分钟。如果你是在国内网络环境安装，可能需要换pip源，否则大概率会在下载依赖的超时问题上反复挣扎。改成清华源或者阿里源之后，速度会明显提升。
依赖装好之后，先在源码目录下找到config目录里的config.example.yaml，复制一份为config.yaml。第一次启动之前不要急着改太多配置，先把默认配置启动一次，确认框架能跑通，再逐项调整。启动命令是：
python main.py第一次启动会创建日志目录和数据目录，并输出初始化信息。如果你看到输出里出现了类似Agent initialized successfully的内容，说明核心安装已经完成。这时你可以在命令行里跟它对话测试：输入“你好”，如果模型回你“你好，我是你的智能助理”，那就通了。
3.2 用Ollama部署本地模型，彻底摆脱API依赖
这是大家问得最多的问题之一。OpenClaw对Ollama的接入做得非常顺滑，完全不需要写复杂代码，配置两步就能搞定。第一步是确保本地已经跑起来了Ollama服务，并且已经拉取了你要用的模型，比如用qwen2.5的7B版本，或者llama3.1的8B版本，看你机器的显存和内存情况。第二步是修改OpenClaw配置里的models.yaml，把默认provider从openai改成ollama。
我实际的配置长这样：
model: default_provider: ollama providers: ollama: base_url: http://localhost:11434 model: qwen2.5:7b这里有个很容易踩的坑：OpenClaw要求Ollama的API路径base_url指向Ollama服务根地址，千万不要在末尾加上/v1或者/api，直接写http://localhost:11434就对了。因为OpenClaw自己会在内部拼接正确的API路径，你多写一层路径，就会导致请求404或者路由错误。
另外一个性能相关的建议：如果你用Ollama本地部署，建议在模型参数里开启num_ctx设置。因为OpenClaw默认会发送较长上下文给模型，而Ollama的默认上下文长度可能不够，会出现“对话稍微长一点就报错”的情况。在Ollama的配置里设置num_ctx: 8192（8K上下文）比较稳妥。这一步不做，你在对话超过几轮之后就会遇到上下文被截断或者报错的问题。
实际体验下来，用7B级别的量化模型在消费级显卡上，单轮响应时间大概在1到3秒，完全够用。如果是日常聊天和简单任务处理，本地模型跟API的差距并没有想象中那么大。只有在复杂推理、代码生成这些需要强模型能力的场景下，本地小模型的短板才会暴露出来。
3.3 核心配置实操：Ollama、上下文与多技能协同
配置实操不只是改YAML，关键在于理解参数之间的关系。先列一个我实际在用、经过压力测试的配置模板，你照着填可以直接跑起来：
agent: name: crayfish system_prompt: "你是小龙虾助手，一个乐于助人的智能体。当需要工具时请直接使用工具，不要回避。" model: default_provider: ollama providers: ollama: base_url: http://localhost:11434 model: qwen2.5:7b temperature: 0.7 max_tokens: 2048 context: max_rounds: 10 max_tokens: 8192 large_return_summary_threshold: 8000 skill: enabled_skills: - echo - file_reader - web_search - calculator auto_load: true这个模板里有几个参数值得展开讲。
温度设为0.7是目前比较均衡的取值。如果做代码生成和数据分析类任务，建议降到0.2以下，减少幻觉；如果做创意写作，可以调到0.9以上。
max_tokens是模型单次回复的最大输出长度，2048对大多数任务够用。如果你要让模型生成大段代码或者长文，调到4096以上会更从容。
max_rounds是保留最近多少轮对话历史，10轮是一个平衡点——既能让模型有足够上下文理解意图，又不至于每轮都发送过多消息导致模型处理变慢。
max_tokens和large_return_summary_threshold之间有关系，8K的上下文窗口建议把摘要阈值设在8000，这样即使技能返回了长篇内容，框架也能在塞进模型之前先做摘要处理。如果你把模型换成32K上下文的专属版本，可以把阈值调到20000以上，尽量保留原始信息。
多技能协同是OpenClaw的另一个亮点。当多个技能同时启用时，框架支持模型在单轮响应中连续调用多个技能。比如用户说“帮我查一下北京的天气，然后把结果存到文件里”，OpenClaw会依次调用查询天气技能，然后把结果写入文件技能。整个过程不需要人为干预。实测下来，这种多步调用在qwen2.5和llama3.1上都能稳定实现，前提是每个技能的描述写得足够清晰。
3.4 安卓端部署：Termux跑OpenClaw步骤详解
手机部署OpenClaw是很多人的刚需，毕竟不是所有人随时都能打开电脑。通过Termux，在安卓手机上跑OpenClaw是完全可行的，而且体验超出了很多人的预期。前提是你的手机内存至少6GB，推荐8GB以上，因为OpenClaw进程本身加系统占用，内存太小会频繁被杀后台。
Termux安装OpenClaw分几步。第一步准备Termux环境：从F-Droid下载Termux，不要用Google Play版本（Play版旧且缺少维护）。启动后先更新软件源。这里有个Termux特有的坑：新版Termux默认没有存储权限，需要先跑一次storage授权，否则后面建目录都操作不了。
然后安装必要依赖：
pkg update pkg install python python-pip git rust binutils为什么需要rust和binutils？因为OpenClaw的一部分依赖涉及Python加密库和网络库的编译，Termux环境下没有预编译轮子，只能本地编译，没有rust和C编译器直接失败。这一步是很多教程里没提的，我也是折腾了两天才搞清楚。
然后跟PC端一样，创建虚拟环境拉源码装依赖：
git clone https://github.com/OpenClaw-project/openclaw.git cd openclaw python -m venv venv source venv/bin/activate pip install -r requirements.txt在手机上编译依赖的时间会比PC长不少，实测大概40分钟到1小时，取决于手机性能。装完之后配置文件跟PC一样，只是模型接入这里有个特殊推荐：手机端部署不建议跑本地大模型，7B模型在手机上运行会非常吃力，推理速度能慢到没法用。更好的做法是配置远程Ollama服务，比如你家局域网里的PC，或者一台云主机。
手机端跑OpenClaw最大的价值在于：你可以随时通过手机的聊天界面控制家里的设备、查信息、执行脚本。这就相当于把智能体装进了口袋，而不是把大模型塞进手机。
3.5 进阶玩法：OpenClaw + ROS2 Humble + Gazebo环境集成
这个玩法是我做仿真机器人项目时候整理的。OpenClaw和ROS2集成后，可以让大模型控制机器人的行为，成为机器人任务的智能体大脑。需要准备ROS2 Humble环境加Gazebo仿真环境，然后把OpenClaw作为一个ROS2节点接入。
集成方案的核心思路是：OpenClaw作为决策节点，接收自然语言指令，输出对应的机器人控制指令，经过ROS2话题传递到机器人端执行。具体操作步骤不少，但核心只有三点：
一是用ros2的Python绑定库封装一个桥接层，把OpenClaw的技能执行结果发布到ROS2的话题上。
二是把OpenClaw的技能层注册到ROS2动作服务器，让机器人执行过程可以被追踪和反馈。
三是Gazebo仿真环境里设置好机器人的模型和传感器数据，让OpenClaw能通过ROS2话题获取环境信息。
这套集成的门槛比纯软件部署要高不少，适合有ROS2基础的人尝试。没接触过ROS的可以先把前几步部署搞定，这个进阶玩法不急。但如果你本身就在做机器人开发，OpenClaw可以帮你省掉大量写固定对话脚本的工作，直接让自然语言变成机器人动作序列。
3.6 电商场景实践：OpenClaw做智能客服与订单助手
OpenClaw在电商场景的落地是最近社区讨论较热的方向。它解决的一个核心痛点是：订单查询、物流跟踪、退换货处理这些重复性咨询，花费了客服大量时间。把OpenClaw接入电商系统后台，用技能去调用订单查询API、物流API、库存API，一个智能客服的雏形就出来了。
我做过一个最小可行版本：用OpenClaw对接一个模拟电商API。需要写三个技能，一个是查询订单状态，一个是查询物流信息，一个是生成订单摘要。每个技能内部调用对应的HTTP接口，返回JSON数据，再处理成自然语言回复。实际跑起来之后，用户问“我618买的那个红色外套发货了吗”，OpenClaw会调用订单查询技能，匹配订单号和商品信息，再调用物流API，最后整合成一句回复。
这个落地过程还有一个价值点：OpenClaw与Ollama本地部署结合，可以做到整个客服系统没有外部API调用，数据全部内部流转。对于重视数据合规的中小商家，这是很关键的卖点。不需要把客服对话内容传到第三方平台，所有推理都在本地完成，这对于涉及用户隐私和交易数据的场景是天然优势。
4. 常见问题与排查技巧实录
4.1 安装阶段五大典型报错与解法
我整理一下这段时间收集到的最高频安装报错，按出现频率排序。
问题一：pip安装依赖时编译报错。错误信息里往往含有gcc、error: command 'gcc' failed的字样。原因是系统缺少编译依赖。解法是提前安装build-essential、libssl-dev、libffi-dev这些包。如果你用的是CentOS系，对应包名是gcc-c++、openssl-devel、libffi-devel。
问题二：Ollama连接失败，报错Connection refused。这个90%是base_url写错或者Ollama服务没启动。先确认curl能访问你的base_url地址，确认能通再看配置。还有一种是改了配置但没重启OpenClaw，新配置根本没加载。
问题三：启动时提示YAML配置解析失败。几乎都是缩进问题。建议用带格式化校验的编辑器修改YAML，看到对齐红线就知道哪里错了，省掉脑内校验。
问题四：启动成功但对话无响应。这时候先看日志文件，在logs目录下。如果日志里显示模型调用超时，那十有八九是模型服务那边的问题。本地模型要确认显存占用是否已经打满；API服务要确认网络是不是正常，API key是不是过期。
问题五：Termux安装时报Python版本不支持。Termux官方源的Python版本可能较旧，OpenClaw依赖Python 3.10+，这种情况下需要先把Python升级，或者用proot-distro安装一个较新的Ubuntu环境再操作。proot-distro方案虽然慢一点，但兼容性更好，推荐遇到版本问题的朋友直接走这条路。
4.2 运行时性能优化和内存控制
跑OpenClaw最需要担心的不是功能问题，而是内存。默认配置下，OpenClaw空载内存占用不高，但一旦加载多个技能并开启多轮会话，内存会涨得很快。我在4GB内存的服务器上实测，空载170MB，开了4个技能之后到了260MB，对话上下文长了之后最高冲到600MB。虽然不算离谱，但如果你还想在同一个机器上跑Ollama的7B模型，那内存就会很紧张。
优化逻辑很明确。一是只启用你用得到的技能，别把所有技能全部开起来。二是调低max_rounds，减少历史消息堆积。三是控制大文件返回，把摘要阈值调低。这三步可以显著降低内存峰值。
另外有一个容易被忽视的内存问题：Ollama的模型是常驻内存的。7B量化模型大概占4-6GB内存，如果机器内存小于16GB，跑起来会比较吃力，系统会频繁使用swap导致卡顿。这种情况下强烈建议把模型量级别降低，改用3B或1.5B的模型，速度优先。
4.3 技能不触发或调用错误怎么排查
这是日常使用中出现频率最高的问题。技能不触发通常有两个原因。第一是技能描述跟用户意图的匹配度不够。描述太泛，模型判断不出来该用哪个技能。第二是技能确实被调用了，但模型生成的参数不符合要求，技能执行时报错，最终被框架当成“调用失败”处理。
我的经验是：先从日志里确认技能到底有没有被调用。OpenClaw会记录每次技能调用的日志，包括选择了哪个技能、传了什么参数。看日志就能定位是在“选择技能”环节出了问题，还是在“执行技能”环节出了问题。选择环节出问题就改描述；执行环节出问题就改参数定义和容错逻辑。
另外要养成一个习惯：新写的技能先在配置里单独启用，用一个简单任务测试通过，再混入多个技能一起跑。否则多个技能同时启用时，模型选错技能的概率会增加，排查起来也麻烦。
4.4 网络波动与模型响应异常的处理预案
OpenClaw在使用外部API时，最烦人的问题就是网络抖动导致的模型响应异常。我遇到过的情况主要有三类。第一类是请求超时，模型那边响应太慢，OpenClaw等不到结果，直接报错。第二类是请求成功但是响应内容为空，模型没有生成任何文本。第三类是模型服务偶发5xx错误，导致会话中断。
针对这三类问题，OpenClaw内部提供了一些容错机制，但默认参数不一定合理。建议手动调大请求超时时间，把默认的60秒改成120秒，给慢模型更多时间。同时开启自动重试机制的开关，让OpenClaw在遇到5xx或超时的时候自动重试一次。重试次数不要超过两次，否则真实故障场景下会反复卡住。
本地Ollama部署虽然不受网络波动影响，但也有自己的特殊问题：如果Ollama在推理过程中出现显存不足，进程会直接崩溃，OpenClaw会收到Ollama返回的错误信息。这种问题只能从Ollama端解决，要么换小模型，要么减少并发请求。
5. 避坑心得与扩展方向
前面写了很多操作细节，最后分享几个我在实际使用中总结的心得。
第一个心得是关于密码和密钥的管理。OpenClaw配置里会存API key这类敏感信息，如果你有把配置传到Git仓库的习惯，一定要小心。我见过不止一个人把带密钥的config.yaml直接提交到GitHub，结果过几天收到扫描机器人的告警邮件，密钥已经泄露了。建议把密钥相关的部分单独提取出来，用环境变量注入，不要写死在配置文件里。
第二个心得是日志的价值远超预期。OpenClaw的logs目录下有完整的运行日志，每一次技能调用、每一次模型请求、每一次异常捕获都有记录。遇到任何奇怪问题，先看日志而不是先猜原因。我在很长一段时间里都是“出问题看一眼日志”，排查效率比盲目改配置高十倍不止。
第三个心得是技能设计上要遵循单一职责原则。不要尝试写一个“超级技能”处理所有事情，那样只会让技能描述难以写清楚，模型也难以选择。宁可拆细一点，一个技能只做一件事，用多个技能编排完成复杂任务。这个思路不仅让模型选择更准确，也让代码更容易维护。
说到扩展方向，OpenClaw的可能性还很大。我最近在尝试的是把OpenClaw跟本地的语音识别服务串起来，做一个完全本地的语音助手。还有个思路是给OpenClaw加一个定时任务调度器，让它能周期性执行巡检类技能，把家庭智能化和办公自动化的能力进一步打通。这些方向都值得折腾，核心逻辑不变：OpenClaw做大脑，大模型做推理，技能做手脚，剩下的就是你对场景的想象力。
这套“小龙虾”文档可以说是把我这大半年跟OpenClaw的爱恨情仇都写下来了。从第一晚通宵部署成功时的兴奋，到在Termux上编译失败时的抓狂，再到ROS2环境跑通机器人仿真的成就感，这些经历都融在这些文字里了。希望它能让你少走我走过的弯路，尽快把OpenClaw跑起来，用起来，玩出你自己的花样。
