车公庙北街

在使用本地模型的时候，经常调用出现超时。我就多了几次测试：，单位是秒，配为1800时，就是30分钟。后台日志报的durationMs代表毫秒，即1/1000秒。为了更好的使用Ollama本地模型，减少超时，建议将超时时间改大写，我是设置为1800，即30分钟。当我改为1800之后，还时有很多超时，是因为有些Agent没有刷新配置，即使重启Gateway，也不会刷新，必须要新建Session，会通过对话让它刷新。

本文介绍了为OpenClaw增加语音识别功能的实现过程。作者通过部署FunASR语音识别服务，将飞书接收的ogg音频转换为wav格式后发送给FunASR进行识别。详细记录了环境搭建步骤，包括创建conda环境、安装依赖库、启动FunASR服务器等。同时开发了OpenClaw的语音处理技能和中间件脚本，实现了从接收语音消息到文本转换的完整流程。最终测试显示该功能在GLM-5和本地Ollama运行的qwen3.5:9b模型上都能正常工作，成功将语音消息转换为可处理的文本内容。

本文探讨了使用OpenClaw生成PPT的多种方法，介绍了OpenClaw通过Skill功能读取和编写pptx文件的操作流程，包括安装powerpoint-pptx技能、组建专业Agent团队进行内容分析，以及使用python-pptx生成基础PPT的过程。文章对比了不同技能生成的效果差异，指出当前方案在内容呈现和排版方面仍有优化空间，为后续探索不同技能生成效果提供了基础。

本文介绍了开发Android多重计时器App的曲折过程。作者先后尝试使用OpenClaw和Cursor两个AI工具进行开发，但首次OpenClaw开发的版本连基本倒计时功能都未实现，被迫重做。两个AI最终产出的App界面和功能差异明显：OpenClaw版本支持添加多个提醒节点，前几次弱提醒滴滴三声，最后一次强提醒；Cursor版本则呈现不同设计风格。作者特别指出AI开发的不可控性，同样的需求会产生截然不同的实现方案，但OpenClaw因具备记忆能力，在第二次开发时能主动调整方案。整个过程凸显了AI辅助开发的

第一次使用FunASR，对于它的原理、用法还不熟，借用AI，只是提高效率，对于我不熟、AI也不熟的地方，实在没有好的方法，只能一步一个脚印、走一步踩一坑地走下去。维度WebSocket服务器本地直接调用正确率大部分一样，最后一段差优加载速度优，免加载差，耗时识别速度同同性能消耗差，不用也会消耗优，按需调用内存占用差，持续占用内存优，按需调用由于我是要在OpenClaw中使用飞书调用FunASR识别我发的语音，两种方案都差不多。我就暂时先按照WebSocket服务器来用。

本文介绍了使用Skill-Vetter进行技能安全审计的实践。首先通过Clawhub登录并获取API token以解决限流问题，然后安装Skill-Vetter工具。文章指出正确用法是在聊天窗口直接发送扫描指令，而非生成Python脚本执行。作者通过错误示例展示了不当操作导致的扫描失败情况，强调应让大模型直接处理扫描请求。扫描结果展示了工具的基本检查功能，但需要注意正确使用方式以避免无效操作。

本文介绍了在WSL Ubuntu中取消自动挂载宿主机磁盘的方法。通过修改/etc/wsl.conf配置文件，关闭automount功能并启用fstab加载，然后编辑/etc/fstab文件手动指定需要挂载的磁盘路径（如D:盘挂载到/mnt/d）。重启验证后，只有指定磁盘被挂载，其他磁盘目录为空。文中还提供了备选的手动挂载命令方案。该方法解决了WSL默认自动挂载所有宿主磁盘的安全顾虑，同时保留了必要的磁盘访问功能。为OpenClaw安装Skills座准备

本文介绍了OpenClaw Dashboard的安装和使用方法。通过conda激活环境后，可通过一行命令快速安装。主要配置包括修改服务器端口(8080)、开启AI聊天功能(需配置gateway和auth_token)。常见问题解决方案：遇到405错误需启用chatCompletions端点；401错误需设置OPENCLAW_GATEWAY_TOKEN环境变量。更新时只需重新执行安装命令。该工具主要用于监控Agent运行状态，提供可视化管理和AI聊天功能。

前面尝试过用OpenClaw开发一款App，实际最后没有成功。于是我就想用Claude Code来开发。做一次对比。又遇到GLM Prompt不够用，只好先慢慢跑着。目标：同样的项目目标，尽量用相同的提示词，看看他们能干到什么程度。

摘要：作者使用OpenClaw模拟开发团队开发语音识别Android App时遇到诸多问题。虽然AI反馈项目"高质量、高效率"，但实际未完成交付。主要问题包括：Agent不遵守公共工作目录要求，BandCoder重复创建相同项目，导致token浪费。AI似乎忘记了项目产出应放在公共目录的原则，暴露出团队协作和指令执行方面的缺陷。

OpenClaw官方对于Windows的态度很明显，强烈建议在WSL上部署。但是WSL有些问题，踩坑分享出来大家了解。OpenClaw对Linux/MacOS的支持，感觉更好一些。好在OpenClaw社区特别活跃，版本更新也非常快，很多问题/Bug估计能很快解决。

摘要：OpenClaw 2026.3.1版本更新后，Node无法连接Gateway，报错显示当tailscale.mode=serve时需将gateway.bind设为loopback。解决方案是修改配置文件openclaw.json，将gateway.bind值改为"loopback"，可通过手动编辑文件或执行openclaw config set命令完成修改，最后重启服务即可。

本文记录了在本地部署通义实验室Fun-ASR语音识别服务的完整过程。使用Anaconda创建Python 3.12环境，从源码安装FunASR，并下载Fun-ASR-Nano模型。通过示例代码验证了中文语音识别功能，支持31种语言识别。部署过程中遇到官方文档不够详细的问题，作者详细记录了每个步骤供后续参考。最后反思了技术实践的重要性，认为亲自部署虽然困难但能加深理解，如同取经之路需要亲身经历才能真正掌握工具使用。整个部署涉及环境配置、模型下载和功能验证三个主要环节。

OpenClaw 2026.3.1版本更新，与飞书相关的新增功能包括文档表格操作、文件上传、消息反应感知等，并修复了媒体附件发送、群组会话路由等多项Bug。更新后需注意处理旧插件路径，通过npm update -g openclaw升级后，飞书功能恢复正常运行。解决插件重复的问题。

本文分享了使用GLM-5模型遇到调用限制后的解决方案。安装本地Ollama模型GLM-4.7-flash作为备用，并详细说明了在Windows主机与WSL Ubuntu环境下配置OpenClaw调用Ollama模型的过程。通过OpenClaw提供的解决方案成功完成配置，同时指出该工具能简化环境问题处理，但对复杂任务（如组建开发团队）仍需更多探索。

OpenClaw Gateway+Node 健康检查方案：通过定时任务检查连接状态，断开时自动重建 SSH 隧道并发飞书通知。遇到四个问题：1）脚本只检查 TCP 端口导致误报；2）SSH 需手动输密码，通过密钥对解决；3）Node 挂了无法通知，需 Gateway 主动检查；4）飞书机器人不能主动发消息，通过加入群聊解决。

本文探讨了OpenClaw多Agent系统在飞书群组协作开发语音识别App时遇到的问题及解决方案。主要挑战包括：1）Agent任务状态不透明，采用定期扫描机制监控状态；2）Agent职责越界问题，需规范调用流程避免上下文错乱；3）跨Agent文件访问障碍，通过符号链接解决工作目录共享问题。这些实践经验为多Agent协作系统的稳定性与可控性提供了实用改进方案，对类似开发场景具有参考价值。

OpenClaw升级导致飞书插件异常问题及解决方案。升级后由于飞书插件未自动更新，导致配置项不匹配（appId和appSecret位置变更），出现消息接收失败。解决方法：1）删除旧插件目录~/.openclaw/extensions/feishu；2）重新安装插件或整体重装OpenClaw。

用6个AI Agent组建虚拟软件公司，实现飞书协作开发，通过飞书群组实现需求→开发全流程。Agent分工形成完整开发链路。关键配置：AgentId用小写、群组ID加白名单、allowAgents添加调用权限、@触发回复。踩坑：大小写导致调用失败、API限流、Agent越界工作。成果：完成需求/设计/开发扩展：思考帽、头脑风暴、咨询群组

OpenClaw配置能力边界探索：通过实践验证其配置指导能力，发现能覆盖大部分配置需求但存在局限。测试显示OpenClaw能提供完整配置结构，但对特定细节解释不足。在自动更新方面，发现Node节点和飞书插件存在更新限制，提出脚本化解决方案。未来计划扩展安全检查功能。整体验证了OpenClaw在配置维护方面的实用价值，同时明确了其能力边界。

分享了春节期间部署OpenClaw一周的实践总结。使用3台电脑4个操作系统，通过Tailscale组网实现远程访问，并分享了详细的部署教程链接。已完成基础环境搭建、本地模型调用等任务，未来计划开发实用软件、增强协作能力等。作者认为OpenClaw作为工具存在局限性，建议降低预期、专注具体需求，让AI处理简单任务。实测发现OpenClaw能解决部分问题如创建Memory文件，但也存在更新失败、插件冲突等技术问题。使用过程中还面临协同工作、安全性、API调用限制等挑战，需结合实际场景灵活应用。

为解决单机器人多任务切换不便的问题，采用多智能体路由方案，实现每个飞书机器人对应一个独立Agent。主要步骤：1) 飞书创建新机器人；2) 控制台创建新智能体；3) 手动配置多账号。遇到的问题：向导会重复安装飞书插件、覆盖单账号配置。解决方案是将多个机器人配置放在 `channels.feishu.accounts` 下，并通过 `bindings` 将 `accountId` 与 `agentId` 对应绑定。最终实现Gateway聊天窗口可切换不同机器人对话。

OpenClaw的安全配置，通过openclaw security audit 检查并修复了5项安全问题，包括飞书群组策略、敏感目录权限、插件白名单等。核心配置包括：groupPolicy: allowlist、tools.deny 禁用危险工具、session.dmScope: per-channel-peer 会话隔离、以及在系统提示词中加入安全规则防止注入攻击。原则：不装不信任的 Skills，不让 OpenClaw 接触金融/主账号。

通过一主一从OpenClaw，完成旅游计划制定配置Windows上的Chrome插件，能够打开网页安装Python-docx，生成正确的docx文件创建飞书文档，方便分享，在手机上查看。

2台OpenClaw，1主1从，使用Tailscale组建局域网，实现互联

OpenClaw与Tailscale结合，组建局域网，并实现在局域网内其他设备能访问主Gateway。需要正确配置openclaw.json，并用tailscale命令暴露服务和端口。还要批准设备访问权限。最终实现跨设备访问，为多个OpenClaw组建集群做好准备。

在Windows 11系统上原生安装和更新OpenClaw（2026.2.19-2版本）的过程及遇到的问题。详细描述了飞书插件安装时出现的报错情况，提供了通过npm全局安装@m1heng-clawd/feishu插件并手动配置的解决方案。分享了更新后插件路径冲突的处理方法，包括修改package.json文件和重新安装依赖项。整个安装配置过程耗时约3小时，为Windows环境下OpenClaw的安装提供了实用参考。

本文介绍了在Windows 11基于WSL2运行OpenClaw时解决Memory设置为local不生效问题的方法。通过修改openclaw.json配置，安装CUDA和cuDNN，编译支持CUDA的llama.cpp，并安装node-llama-cpp，最终实现了本地(local)模式的Memory配置。文章详细记录了配置过程中的关键步骤，包括环境变量设置、模型路径指定、CUDA安装验证等，为遇到类似问题的开发者提供了实用参考。

OpenClaw 基于Windows11 WSL2部署，使用GLM5大模型，并完成飞书对接。