前言

最近在做某个嵌入开发的外壳建模设计时，发现建模时需要测量各种零件和螺丝孔位等位置和尺寸的精确信息实在是麻烦，想着要是能有一个设备可以接入到 Agent 让 AI 借助外部工具完成这种繁琐的工作再结合目前的 blender mcp 进行自动化建模就好了。然后就发现了一个开源的机械臂项目（SO-101），其机械臂零件（除了舵机）都可以进行 3D 打印，而我手上正好有一台 3D 打印机（拓竹的 A1 mini），所以就想弄一个来验证自己的想法，毕竟具身智能是未来 AI 的下一个突破点（纯软件层面的 AI 模型可以说是趋近完美了，再加上目前如火如荼进行的 Harness 工程迭代，后续 AI 模型在软件工程方面取代人类已经可以预见；而具身智能则是 AI 介入物理世界的工具，打通具身智能的泛化应用则标志着 AI 在接管真实世界上具备了工程可行性）。

我的想法就是把机械臂接入到 Agent 中，由 Agent 来控制机械臂的运行，看看能不能借助 LLM 来实现具身智能的某种泛化能力（目前具身智能相关的专用模型——即世界模型的泛化能力有限，且我觉得收集数据进行模型训练是一个很枯燥的过程😂）。

前言

最近 OpenClaw^[1] 的热度很高，作为一个开源的 AI 私人助手，它能在本地运行、对接各种 IM 平台（飞书、钉钉、QQ 等），全天候帮你处理消息、管理任务。社区里大家把部署 OpenClaw 戏称为“养虾”——因为它的 logo 是只🦞。

“养虾”需要一台 24 小时运行的服务器，且听说对于内存的要求比较大，所以要部署搞不好还得去开个单独的云服务器。不过正好家里有一台闲置的红米 Note4X（骁龙 625、3GB 内存、4100mAh 电池），一直在吃灰。后来在 B 站上看到有人用PostmarketOS把旧安卓手机刷成了 Linux 服务器 ^[2]，骁龙 625 又恰好是 PostmarketOS 支持较好的芯片平台之一，于是我决定试试在这台旧手机上跑 Docker 来部署 OpenClaw。

TLDR

最终成功在红米 Note4X 上通过 PostmarketOS + Docker 部署了OpenClaw-Docker-CN-IM^[3] 服务。日常通过飞书等 IM 平台与 OpenClaw 交互，如果需要在外网访问管理界面可以额外配置 Tailscale。整个过程主要踩了这几个坑：

1. fastboot 版本不兼容，刷写 userdata 分区时报错 std::bad_alloc
2. Docker 的 containerd 可执行文件路径与 systemd 配置不匹配，导致 Docker 无法启动
3. 需要给 Docker 配置网络代理才能正常拉取镜像
4. OpenClaw Gateway 在非本地回环地址访问时需要配置 allowedOrigins

前言

由于我只有一台内存 2G 的云服务器，上面也部署了一些 Docker 服务，加上近期启用了 n8n 实例，导致内存频繁达到 90% 的告警线：

虽说我可以把告警上调至 95% 来避免这个问题，但是内存不足的问题并没有得到实际解决。于是稍微查了下服务器中哪些 Docker 服务比较占内存：

尽管 n8n 占用的内存是最多的，但是我在上面搭建了一些工作流和接口服务，所以是必要的，无法被替代。其它的服务要么也是不可替代，要么占用内存极低，所以最显眼的就是 uptime-kuma 了。尽管它占用的内存严格来说也不算特别多，但谁叫我服务器内存不够呢😂，而且 uptime-kuma 是一个网络服务健康检测的工具，功能不算很复杂，但内存也是轻松超过 100M（据说是 nodejs 的锅，因为我部署的一些其它自带前后端的 Docker 服务，采用 Go 写的，内存就只有不到 30M）。

虽然 Uptime Kuma 的界面简洁，用来检测服务和证书的状态也很方便，但是现在也只能说再见了

前言

ONLYOFFICE 是一个可以用于在线编辑和查看 office 文档的工具，有免费的社区版和付费版的，哪怕是免费的社区版其功能也比较完善了，且可以自行部署。

由于社区版的源码进行了开源，因此如果需要进行私有化的定制改动则可以基于源码进行编译。不过官方的社区版编译文档十分简陋，根本没办法按照其说明的编译步骤正常进行编译，很多坑。

前言

现在很多 OCR 模型实际上已经支持了一定程度内的旋转文本的识别，即图片中的非水平方向的文本可以正确识别其方向并按照正常的水平顺序返回该文本；但这仅限于每一个 Bounding Box 内的文本，因为 OCR 模型一般原始输出都是从图片中获取一个个单独的文本区域——即 Bounding Box，然后识别该区域的文本，并不会对这些 Bounding Box 进行拼接得到按正确顺序返回的完整文本，如：

从图中右侧不难发现哪怕图片中的文本有一些旋转，OCR 模型也可以识别出这些文本块的方向，并返回正确的文本顺序；但是如果要以正确的顺序（从左至右，从上至下）返回所有的文本行，就需要自己去处理了。

一般来说，我们可以假设图片中的文本旋转方向都是一样的（适用于常见的单页文本拍照或者扫描件），因此只需要得到一个整体的旋转方向，然后基于这个方向进行一个逆运算即可得到正常水平方向的 Bounding Box 位置，也就能拼接得到视觉层面上正常顺序的完整文本了。