Marco LiuOpenClaw 最近在圈子里火得很，我也就是个普通玩家，花了一个周末把“人人养虾”这个有点无厘头但很上头的项目跑了起来，并且接进了飞书。整个过程中最让我头疼的不是 OpenClaw 安装，而是飞书事件订阅的坑，以及 OpenClaw 自带 Control UI 时不时罢工的问题。这篇东西就把我从零到跑通的完整过程记下来，包括架构思路、skill 编写、飞书机器人配置、排错记录，给后面想玩 OpenClaw 又想接办公 IM 的人一份可以直接抄的作业。
先说清楚，“人人养虾”并不是教你怎么用 OpenClaw 去养殖场喂虾。它本质上是拿 OpenClaw 做的一个电子虾塘智能体 demo：你在飞书群里 @ 机器人，问它“今天虾塘水温多少”“帮我喂 50 克饲料”“写一份昨晚的虾塘观察日报”，它真的会去调 skill、翻记忆、生成内容并回复你。这个玩法特别适合用来理解 OpenClaw 的 memory 和 skill 机制，也因为话题轻松，拿来在团队群里试水非常合适。
如果你已经在本地跑起来过 OpenClaw，或者刚装完正在纠结“这玩意到底能干啥”，这篇文章就是给你准备的。
1. 整体设计与思路：为什么是 OpenClaw + 电子虾塘 + 飞书
1.1 先搞清楚 OpenClaw 到底是个什么东西
OpenClaw 是一个开源的个人智能体运行时，跟普通聊天机器人最大的区别是：它不是一个“你问一句它答一句”的对话壳子，而是一个“接收输入—规划—调用技能—读写记忆—产出回复”的 agent loop。换句话说，你给它一个目标，它能自己决定用什么 skill、查什么记忆、调哪个模型，最后把结果整理成人话。
它在社区里流行的主要原因有三点。第一，它是本地优先的，数据都落在你的 ~/.openclaw 里，不强制上云。第二，它的 skill 机制很轻，写一个 JSON 加一段执行函数就能让 agent 获得一个新能力，不需要改框架源码。第三，它支持多模型配置，主力对话模型和辅助工具调用模型可以分开指定，甚至可以用本地模型兜底。
这一点是我选它做“养虾管家”而不是直接写个飞书 bot 的根本原因：普通 bot 的对话逻辑是死的人肉 if-else，而 OpenClaw 是一个可以自己“思考”的智能体，用户说“今天风大，虾会不会应激”，它不会只回复一句“不会”，而是会去调天气 API、查塘口记录、结合当前溶氧数据给你一段综合判断。这种体验完全是另一个层级。
1.2 “人人养虾”到底是个什么玩法
我管这个项目叫“人人养虾”，你可以把它理解成一个带养成属性的智能体应用。核心设定是：AI 在本地扮演一位虾塘管家，它知道自己管理的塘口编号、虾苗投放时间、当前水温、最近一次喂食记录。用户每天通过飞书群跟它互动，可以让它投喂、换水、记录观察、生成日报，甚至让它写一首关于虾的打油诗。
这个玩法能在社区火起来，其实是两个 OpenClaw 能力的具象化展示。一个是 long-term memory：虾塘管家会记得“上次换水是三天前”，不会每次都像失忆了一样问你是哪个塘。另一个是 skill 调用：用户说“喂虾”，agent 不会只回一句“好的”，而是真的去跑一条喂食记录写入函数，把饲料类型、数量、时间存进本地 JSON。
从这个角度说，“人人养虾”更像一个教学性质的项目。它用最轻松的场景，把 OpenClaw 最核心的能力全部串了起来。等玩明白这套电子虾塘以后，你再把它换成“日程管家”“文档助手”“群运维机器人”，逻辑是一模一样的。所以不要被“养虾”两个字迷惑，它的价值在于给你一个能反复折腾但不会出大事的沙盒环境。
1.3 为什么接入飞书，而不是直接用网页或命令行
其实 OpenClaw 原生带一个 Control UI，浏览器里就能聊天，也能看日志。但我用了一晚上之后就发现，这种形态只适合开发者自己调试，不适合“人人”玩。原因很简单：手机上没有舒服的入口，每次想测个功能都得开电脑开浏览器，根本没有那种“随手打开飞书 @ 一下”的畅快感。
接入飞书以后，体验完全变了。我在通勤路上掏出手机，打开飞书群，发一句“今天喂了多少克料”，秒回。而且飞书的企业自建应用天生适合团队场景，一个群里所有人都能 @ 机器人玩，甚至可以每个人都开一个自己的虾塘配置，互不干扰。
选飞书而不是微信，是因为飞书开放平台的机器人 API 极其规整，对个人开发者友好，没有个人号风控的问题。事件订阅支持长连接模式，不用公网 IP 和 HTTPS 回调，这一点对于部署在家里 NAS 或者 Mac mini 上的 OpenClaw 来说是决定性的。相比之下，微信公众号和个人微信的接入方式限制多、审核麻烦，根本不适合拿来做一个自己玩的 agent。
另外，飞书还有多维表格。我后来把虾塘的每日水质数据直接写进多维表格，再用 OpenClaw 去查表生成周报，整个数据闭环不需要额外开发。这一步做完之后，我就确定这套架构用来做正经的“养殖数据管家”也是完全成立的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 接入前必须搞懂的三个机制：skill、memory、多模型
2.1 skill：让 OpenClaw 真的会“喂虾”
很多人第一次接触 skill 会一头雾水，以为是什么高深插件系统。其实在 OpenClaw 里，一个 skill 就是一份描述文件加一段执行代码。描述文件告诉 agent 这个技能是干什么的、需要哪些参数、什么时候该调用；执行代码才是真正干活的部分。
我写了一个 feed_shrimp 技能作为示例。它的描述文件大概是这样的逻辑：
- 技能名称：feed_shrimp
- 使用场景：当用户要求喂虾、投喂、加饲料时，调用该技能
- 参数：feed_type（饲料类型，比如“对虾配合饲料”）、amount_g（投喂克数）
当用户在飞书群里说“给 1 号塘喂 50 克饲料”时，OpenClaw 的主模型会通过意图识别把这句话映射成一次 skill 调用，然后执行代码会往本地数据文件里追加一条记录，最后 agent 把执行结果组织成自然语言回复。
写 skill 最大的坑是描述文件写得太模糊。模型判断“要不要调用这个技能”完全靠描述文件里的 description，如果你写的是“这个技能可以用于投喂操作”，模型可能根本不知道该在什么时机调用。我后来参考社区里的写法，把 description 改成“当用户明确表达要对某个塘口进行饲料投喂、加料、喂食时调用，参数必须包含饲料类型和克数”，识别准确率立刻上去了。
还有一点需要注意：skill 执行函数不要写成同步阻塞的。OpenClaw 调用 skill 是在 agent loop 里进行的，如果函数里做一个耗时 30 秒的网络请求，整个回复会卡住，飞书那边表现为机器人一直不回复。所以我习惯把耗时的操作写进去就立刻返回“已记录，投喂任务已加入队列”，再通过后台任务处理。
2.2 active memory：让“虾塘管家”记住昨天的事
没有记忆的智能体，本质上就是个 API 壳子。OpenClaw 的 active memory 机制把记忆分成了短期和长期两层。短期的就是当前对话上下文，长期的则会把重要的记录向量化存储，等需要时通过语义检索找出来。
在“人人养虾”这个场景里，记忆机制的实际使用方式是这样的：我提前在记忆里塞了一条“1 号塘的虾苗是 2025 年 4 月 10 日投放的，预计 70 天后出塘”。当用户在飞书里问“虾还要养多久才能卖”，agent 不会凭空回答，而是先做一次记忆检索，找到刚才那条，然后结合当前日期计算剩余天数。
另一个记忆使用场景是投喂记录的累积。如果每次喂虾都只是写入文件但从不进记忆，那 agent 永远不知道“上次投喂是什么时候”。我在 feed_shrimp 的执行函数里额外调了一次记忆写入，把“刚刚给 1 号塘喂了 50 克料”这句话存成可检索的备忘。这样用户下一句问“昨天喂了几次”，agent 就能从记忆里捞出来。
实际操作里我遇到的问题是这个：默认情况下记忆写入太频繁会把向量库搞得很乱。比如用户随便闲聊一句“今天好热”，如果也被写进长期记忆，后面检索“水温情况”时反而会受到干扰。所以正确的做法是要控制写入条件，尽量只在执行完 skill 或者用户明确表达“记一下”时才写长期记忆。
从 OpenClaw 的日志里可以看到每一次记忆读写的过程，调试的时候特别有用。如果你发现 agent 回答显得“失忆”，先别急着怪模型，先去日志里看它到底有没有检索到记忆，大概率是检索条件没命中或者根本没有写入。
2.3 多模型配置：主力用 deepseek，本地模型兜底
OpenClaw 支持在配置里指定多个模型，分别用于对话、工具调用、记忆压缩等不同环节。我的搭配是：主力模型用 deepseek-chat，cost 低、中文理解好、写日报很自然；工具调用和意图识别这些对延迟敏感的场景，则用了本地部署的更快更小的模型做兜底。
这个配置里最容易踩的坑是模型名称写错。社区里大量出现的一个报错是 agent failed before reply: unknown model: deepseek，看日志就知道是 .env 里写的模型标识和实际 API 服务商支持的名称对不上。以 DeepSeek 官方 API 为例，正确的模型名是 deepseek-chat，不是 deepseek，更不是 deepseek-coder。
另外就是响应超时问题。飞书机器人事件回调有自己的超时限制，如果 OpenClaw 的模型推理时间太长，飞书那边会判定机器人无响应。解决办法有两个：一是给 OpenClaw 配一个低延迟的小模型处理首轮回复，主力模型只负责真正复杂的任务；二是把飞书事件订阅配置成异步模式，OpenClaw 收到消息后立刻返回“收到”，再慢慢生成内容后通过主动消息推送结果。
我的建议是刚上手不要贪多模型，先用一个 deepseek-chat 跑通全流程。跑通之后再逐渐把工具调用模型、记忆压缩模型拆出来。一上来就搞复杂配置，出了问题你根本分不清是环境问题还是配置问题，排错成本极高。
3. 完整实操记录：从飞书开放平台到 OpenClaw 跑通
3.1 飞书开放平台侧配置：创建应用、开启长连接、申请权限
这一小节带你走一遍飞书这边的全部配置。不懂飞书开放的接口也没关系，照着做就行。
第一步，打开飞书开放平台，进入开发者后台，点击“创建企业自建应用”。应用名称我填的是“人人养虾-虾塘管家”，头像随便选了个虾的图标。创建完以后，进入应用详情页。
第二步，在“应用能力”里开通机器人能力。这一步会在应用下自动生成一个机器人，之后你就能在飞书群里 @ 它了。
第三步，配置事件订阅。这是最容易出错的一步。在“事件与回调”页面里，订阅方式选择“使用长连接接收事件”，不要选“将事件发送至开发者服务器”。选长连接的好处前面说过，不需要公网 IP，不需要 HTTPS 证书，OpenClaw 从本机连出去就能收到事件。
事件订阅里要添加一个事件：im.message.receive_v1，也就是接收消息事件。只有订阅了这个事件，OpenClaw 才能收到群里的 @ 消息。订阅完以后，飞书会要求你填一个验证机制，但长连接模式下不需要处理 URL 验证，只需要等 OpenClaw 那边连上来就行。
第四步，权限管理。这一步非常容易被忽略，但漏掉了大概率机器人不回复。需要开启的权限至少包括：im:message（读取消息）、im:message:send_as_bot（以机器人身份发消息）、im:resource（读取图片等资源）。在权限管理页面里搜索这仨，一个个开通。如果后续想用飞书多维表格，还需要额外开 bitable:app 相关的权限。
第五步，创建版本并发布。权限配置完成以后，必须点击“创建版本”，填写版本号和可用范围，然后提交发布让应用生效。这一步不做，前面所有配置都是白搭，飞书 API 会一直返回权限不足。
第六步，在“凭证与基础信息”页面，把 App ID 和 App Secret 复制出来。这两个值是后面 OpenClaw 连接飞书的钥匙，App Secret 一定要保管好。
3.2 OpenClaw 侧配置：安装飞书适配器和启动验证
OpenClaw 接入飞书依赖于官方或社区提供的适配器包，我这边用的是社区维护的 @openclaw/adapter-feishu。安装方式很简单，在 OpenClaw 的项目目录下执行：
bash复制pnpm add @openclaw/adapter-feishu
安装完成后，需要把飞书应用的 App ID 和 App Secret 写进 OpenClaw 的环境变量或者配置文件里。我是在 ~/.openclaw/.env 里新增的：
bash复制FEISHU_APP_ID=cli_xxxxx
FEISHU_APP_SECRET=your_app_secret_here
FEISHU_EVENT_MODE=websocket
这里 FEISHU_EVENT_MODE=websocket 对应的就是飞书的长连接模式。设置好之后，启动 OpenClaw：
bash复制openclaw start
如果一切正常，你会看到日志里出现类似这么一行：
text复制[feishu] connected via long connection
看到这一行，说明飞书已经成功连上 OpenClaw 了。此时在飞书群里 @ 你的机器人，发一句“你好”，正常情况下它会在几秒内回复。如果没回复，大概率是事件订阅没配好或者权限没发布，回到 3.1 检查。
3.3 把“养虾管家”的完整流程跑起来
飞书连通之后，我做的第一件事不是直接测试养虾功能，而是先定义好虾塘的数据文件。我在 ~/.openclaw/data/shrimp_farm.json 里放了一份初始数据：
json复制{
"ponds": [
{
"id": "pond-1",
"tag": "1号塘",
"stock_date": "2025-04-10",
"temperature_c": 28,
"ph": 7.6,
"oxygen_mg_l": 6.2,
"last_feed": null
}
]
}
然后我写了一个 shrimp_status skill，核心执行函数就是读这个 JSON 文件，把塘口信息包装成一段可读文本返回给 agent。编写完成后，在飞书群里发了一句：
“今天 1 号塘的情况怎么样？”
OpenClaw 的日志显示它做了这么几件事：先从 active memory 检索有没有关于 1 号塘的近期记录，然后判定用户意图是查询塘口状态，调用了 shrimp_status skill，拿到 JSON 文件里的数据，最后结合记忆里“昨天刚换过水”的信息，生成了一段完整回复：
“1号塘当前水温28℃，pH 7.6，溶氧6.2，整体正常。根据记录，昨晚刚换过水，所以今天不建议再大量换水，可以少量补水或者直接观察。”
看到这条回复的时候，我大概明白了 OpenClaw 这种 agent 框架和普通飞书 bot 的本质区别。普通 bot 的回复是程序员写死的模板，而 OpenClaw 的回复是模型基于实时数据和记忆现场组织出来的，语气、详略甚至建议都得靠模型能力体现。
接着我又测了 feed_shrimp 的完整链路：在飞书里发“给1号塘喂30克饲料”。OpenClaw 识别意图、调用 skill、更新 JSON、写入记忆，一气呵成。最后回复：“已给1号塘投喂30克对虾配合饲料，投喂时间已记录。”
到这里，“人人养虾”的核心玩法就已经全部跑通了。后面我还在飞书群里做了个定时提醒，每天早上 9 点通过 OpenClaw 推送一条虾塘状态摘要。定时触发的机制很简单，在 OpenClaw 里注册一个 cron task 指向一个日报 skill，skill 里复用之前的查询逻辑，再把结果通过飞书主动消息推送到群里。
这一步做完，整个项目就不再是一个“你问它答”的被动工具，而是一个会主动汇报的智能管家。拿这个思路翻过来想，把日报内容换成服务器监控、店铺销售、项目进度，架构完全不用变。
4. 常见问题与排查技巧实录
这一块我把自己踩过的坑和社区里高频出现的问题整理成速查表，方便你对着查。先从 OpenClaw 自身的报错说起，再讲飞书那边的问题。
4.1 OpenClaw 常见启动与运行报错排查
第一类报错：openclaw control ui did not start
这个报错我遇到的时候一头雾水，因为功能上 OpenClaw 好像是能跑的，但 Control UI 一直打不开。后来查了日志发现是端口被占用，Control UI 默认监听某一个固定端口，跟本机其他服务冲突了。解决办法是换端口启动，或者干脆先不用 Control UI，直接命令行模式使用。
还有一个隐藏原因：Node 版本太低。OpenClaw 依赖新版 Node 的某些特性，版本太老会导致内嵌服务起不来。建议把 Node 升级到 18 以上的 LTS 版本，最好直接用当前最新的 LTS。
第二类报错：oneclaw node runtime not found
这个问题在 Windows 下很常见，大概率是 OpenClaw 在启动子进程时找不到 Node 可执行文件的路径。检查一下系统 PATH 环境变量里有没有 node 的安装目录，然后在终端执行 node -v 确认能正常输出版本号。如果命令能用但 OpenClaw 还报这个错，试试在启动 OpenClaw 之前，先显式设置一下 NODE_PATH 环境变量指向全局 node_modules 目录。
第三类报错：failed to remove ~/.openclaw: error: ebusy: resource busy or locked
这个是 Windows 专属的嫉妒问题。删除 ~/.openclaw 目录时，提示目录被占用。原因是日志文件被正在运行的 OpenClaw 进程锁住了，或者杀毒软件在后台扫文件。解决办法是先把 OpenClaw 完全退出，再关掉终端窗口，最后检查任务管理器里有没有残留的 node 进程，全部结束后再删。如果是杀毒软件锁定，可以临时把 .openclaw 目录加入白名单。
第四类报错：the agent run failed before producing a reply.
这是一个总括性报错，真正原因要看前面的详细日志。最常见的原因是模型配置错误，比如 API key 没填、余额不足、模型名称不对。我遇到的是 unknown model: deepseek，把模型名从 deepseek 改成 deepseek-chat 后解决。另一种可能是工具调用环节出错，skill 执行函数抛异常导致 agent loop 中断，这种情况会更容易在日志里捕获到，把 skill 的入参打出来看是什么值异常了。
4.2 飞书侧高频问题排查
报错 2700002
这个错误码在飞书开发者后台和日志里都很显眼，它一般表示事件订阅的签名校验失败。如果你用的是长连接模式，出现这个错误大概率是 App Secret 填错了，或者事件订阅配置里加密用的 Encrypt Key 和后端不匹配。OpenClaw 的飞书适配器默认不用 Encrypt Key，所以最简单的方法是确保飞书后台“事件与回调”里的 Encrypt Key 留空，两边保持一致。
机器人收不到消息，但日志显示已经连接
这在群里测试时很让人抓狂。我的排查顺序是：先确认是否在群里正确 @ 了机器人，OpenClaw 只处理被 @ 的消息。然后检查事件订阅里是否添加了 im.message.receive_v1。最后确认应用版本是否已经发布，未发布状态下机器人不会收到真实消息。
机器人有时回复有时不回
这种情况我猜大概率是模型响应太慢超时了。就像 2.3 里说的，飞书的事件回调有超时限制，如果长时间不响应，飞书会直接放弃。解决方案是给 OpenClaw 配一个更快的小模型处理飞书这边的即时响应，或者开启异步消息模式。
4.3 一条独家的排错心法
上面列的都是具体问题，但我想分享一个对所有场景都适用的排错思路：无论出什么错，第一件事去看 OpenClaw 的日志，第二件事去看飞书应用后台的“事件订阅”日志。
这两个地方会把真实错误原因写得明明白白。比如飞书后台会显示“事件投递失败”，你点进去能看到具体的错误码；OpenClaw 的终端日志则会打印出 agent loop 每一步执行了什么。绝大多数问题根本不用去翻源码，把这两份日志拉到一起对照着看，问题就解决了一大半。
我在调试飞书机器人链路时有个习惯：先发一条消息“ping”，然后看 OpenClaw 日志里有没有对应的消息接收记录。如果这一步通了，说明链路是通的；如果没通，说明是飞书事件订阅的问题，根本不用去折腾后面的 skill 和记忆。
最后再分享两个我自己实际折腾出来的小技巧
第一，如果你只是想在本地快速试玩“人人养虾”，不需要一上来就配飞书。先用 OpenClaw 自带的 Control UI 把 skill 和 memory 调顺，确认本地链路没问题，再花半小时接飞书。很多人上来就直奔飞书，结果模型和 skill 都没调好，日志里面全是报错，反而分不清是飞书的问题还是 OpenClaw 自身的问题。分步验证，永远比一步到位省时间。
第二，飞书接入后，一定把多维表格用起来。我开始只把飞书当一个聊天窗口，后来发现多维表格配合机器人 webhook 可以做很多事情。比如让 OpenClaw 每次执行完 feed_shrimp 之后，把投喂数据同时写进多维表格，再用仪表盘做可视化，就变成了一套非常简易的养殖管理系统。模型输出是即时对话，多维表格是沉淀数据，两者结合才是完整的 agent 应用形态。
这个项目我还会继续折腾下去，下一步准备把虾塘形态和真实养殖数据接进来，让机器人可以基于历史水质趋势做预警。OpenClaw 这套框架最吸引我的地方就是它给普通开发者留了很大的发挥空间，一个飞书群加一台小主机，就能跑出一个具备记忆、技能和主动汇报能力的数字角色。也许这就是“人人”这两个字的意义吧。