OpenClaw 插件开发，先说几句心里话

嗨，老铁们，今天咱们聊聊 OpenClaw 插件里那些让人抓狂的坑。

说实话，我刚上手的时候，真是把头给掀翻了。

哈哈，别慌，咱慢慢拆解。

OpenClaw 本身Yi经带了 openclaw、typescript。

结果我在 package.json 里又装了一遍。

不对不对，这就像把同一只鸡肉又炸了两遍——油炸味儿全跑了。

解决办法？把这些内置包移到 peerDependencies，别真的去 npm install。

deliver 是用户主动找你的入口。

sendText 是系统自己推送的渠道。

我以前把两者写在同一个函数里结果消息跑错路，用户投诉不停。

现在我在回调里先判断 info.kind 再分流，代码清晰多了。

console.log 在插件的子进程里根本kan不到。

我曾经天天盯着终端，以为插件卡住了。

后来改成写文件日志，一行一行打开kan，问题立马浮现。

一个项目往往有好几个 AI 账号。

我把每个账号dou当成独立的服务来跑鉴权和 WebSocket 连接。

结果服务器瞬间宕机，CPU 飙到天际。

Zui靠谱的Zuo法是共享连接池，只在第一次创建连接，其余复用，同步省资源又省心。

openclaw.json 的日志路径、agent 开关Ru果写错，会导致根本kan不到任何输出。

建议先在本地跑一遍，用 cat kan一下是否真的生效，再推到生产环境。

顺带回答一下常见的 SEO 疑问：

为什么百度不收录我的技术博客？

- 检查 robots.txt 是否误封了整个站点；

- 然后确认页面有没有有效的 title 和 meta description；

- 再者内容要原创、结构化，适当加入 H 标签和关键词密度；

- Zui后提交 sitemap 给百度站长平台，让爬虫主动抓取。

每次进入 deliver 前，把 messageId、userId、payload 全部写进日志文件。这样回溯时Neng精准定位是哪一次调用出错。

Painful 的错误信息往往被吞掉。加上 catch 后把 err.message 和 stack 同样记录下来你会感谢自己的细心。

"agents.verboseDefault": "full" 这行配置打开后你Nengkan到每一次 tool 调用的输入输出。别小kan它，对调试超级有帮助。

误以为插件Ke以随意引用外部 npm 包——安全风险大增，供应链攻击随时敲门；

A/B 测试直接在生产环境改代码——容易导致业务中断；

I’m sorry—typo—请勿在生产环境直接执行未经审计的脚本；

I’m back—不要忘记给插件加上Zui小化权限，否则一旦被攻破，全局资源dou会泄露。

Coding 本来就是件乐事，不要因为几个坑就失去热情。

COPILOT 我们一起玩转 OpenClaw，就像玩游戏一样，有怪物就打，有宝藏就抢。

If you found this guide useful, 点个赞 👍 支持一下也欢迎在评论区分享你的踩坑经历！