AI

OpenClaw 远程聊天入口迁移记录：从 LINE 配额限制到 Telegram 通道

在本地运行 AI 代理时，远程聊天入口是一个非常实用的功能。平时可以通过本机终端或网页后台操作，外出时则可以通过手机聊天软件临时发送指令，让 AI 代理执行查询、检查服务状态、处理项目任务，甚至进行一定程度的自动化操作。 不过，聊天软件本身并不是完全透明的通道。不同平台对机器人消息、官方账号、Webhook、API 调用方式都有不同限制。一次 OpenClaw 更新后的排查，正好暴露了 LINE 通道和 Telegram 通道之间的差异。 一、现象：后台能看到回复，但手机 LINE 收不到 OpenClaw 更新后，LINE 聊天通道出现了一个看起来比较奇怪的现象： 用户从 LINE 发送消息后，OpenClaw 能收到消息；网页管理后台也能看到 OpenClaw 生成了回复；但是手机 LINE 端却看不到回复内容。 从表面上看，这很容易让人怀疑是 OpenClaw 更新导致 LINE 插件异常，或者 Gateway、Webhook、认证密钥、KWallet、systemd 服务出了问题。尤其是在更新软件之后出现问题，人会自然地把故障和更新动作联系起来。 但进一步排查后，情况并不是这样。 OpenClaw 的通道状态显示，LINE 通道仍然处于 enabled、configured、running、works 等状态，说明通道本身并没有完全离线。问题集中在外发投递队列中：最近几条外发消息卡在 delivery queue，状态为 pending 或 failed，错误类似 partial delivery failure。也就是说，OpenClaw 内部已经完成了消息处理，但真正发送到 LINE …

AI

OpenClaw 接入 Nextcloud Talk 与 Telegram 的通信机制对比

在给 OpenClaw 配置外部聊天通道时，一个很关键的问题是：消息到底是由 OpenClaw 主动拉取，还是由外部平台反向推送到 OpenClaw Gateway。这个区别会直接影响部署方式、网络要求、安全边界和维护复杂度。 本文以 Nextcloud Talk 与 Telegram 为例，整理两种典型通信模式的差异。 1. OpenClaw 是否支持 Nextcloud Talk OpenClaw 支持 Nextcloud Talk 通道。它属于官方集成的聊天通道之一，工作方式是通过 Nextcloud Talk bot 与 OpenClaw Gateway 之间的 webhook 通信完成消息收发。 也就是说，Nextcloud Talk 端收到用户消息后，会把消息通过 webhook 请求发送到 OpenClaw Gateway；OpenClaw 处理完成后，再把回复返回到对应的 Talk 会话中。 因此，Nextcloud Talk 的关键不只是“OpenClaw 能不能访问 Nextcloud”，还包括“Nextcloud 服务器能不能反向访问 OpenClaw Gateway …

AI

从 Codex 到 DeepSeek：AI 代理后端模型选择与本地自动化实验思路

一、AI 代理的重点已经不只是“聊天” 普通大语言模型更多是在对话框中回答问题，而 AI 代理的使用方式明显不同。代理不仅要理解自然语言，还要调用工具、读取文件、执行命令、操作浏览器、控制桌面环境，甚至连接本地服务或外部软件。 在这种场景下，后端模型的角色已经从“聊天模型”变成了“行动系统的大脑”。它需要完成的不只是解释问题，而是持续推进任务： 因此，选择 AI 代理后端模型时，不能只看聊天效果，也不能只看价格。真正重要的是：模型是否适合作为代理的大脑，是否能够稳定地与工具、终端、脚本、接口和真实系统配合。 二、Codex 的价值：强的不只是模型，而是一整套代理体验 Codex 类模型之所以适合 AI 代理，并不是因为它只会写代码，而是因为它比较适合真实操作环境。 在实际使用中，AI 代理经常会遇到这些情况： 普通聊天模型在这种场景中容易出现两个问题：一是给出看似合理、实际不可执行的建议；二是任务一长就丢失上下文，开始偏离目标。 Codex 类模型的优势在于，它更擅长在“边执行、边观察、边修正”的过程中工作。它不只是回答“应该怎么做”，而是更接近于真正帮助完成任务。 这也是为什么在 OpenClaw 这类代理工具中，Codex 往往能给人一种“真的能干活”的感觉。 三、为什么需要寻找 Codex 的替代或补充模型 虽然 Codex 类模型很好用，但 AI 代理的 Token 消耗非常大。 普通聊天中，一次问答可能只消耗少量上下文；但代理任务不同。代理需要不断读取环境信息、工具结果、命令输出、文件内容和错误日志。每一次观察、计划、执行和修正都会消耗 Token。 尤其是下面这些任务，消耗会非常明显： 因此，如果完全依赖高价或有限额度的模型，长期使用成本会比较高。这就引出了一个现实问题： 是否存在更便宜、可以接入 OpenClaw、又能在一定程度上接近 Codex 的模型？ 围绕这个问题，可以重点关注 DeepSeek、Qwen、GLM、MiniMax、Kimi 等模型或平台。 四、便宜模型和 Codex 级模型不是一回事 在选择模型时，需要先区分两个概念： 这两个概念不能混在一起。 …

Bio

从人类基因数据处理到 Web UI 上线：一个生物信息系统 Stage 1 的完整工程闭环

一个生物信息项目从“数据下载完成”到“真正可以访问”，中间隔着很长一段工程距离。 原始数据需要清洗、映射、索引、校验；查询逻辑需要从命令行走向可复用服务；服务器部署需要处理路径、权限和安全边界；Web UI 需要在不暴露原始数据库和序列文件的前提下，把复杂数据变成可以浏览、搜索和理解的信息页面。 Human_Genes_Functions 的 Stage 1，就是这样一个从数据工程到在线查询系统的初始闭环。它不是最终豪华版平台，但已经完成了一个很重要的阶段：从本地人类基因功能数据库，推进到可通过浏览器访问的 Web UI，并且通过了功能、安全、截图和文档归档验收。 一、项目目标：不是一个网页，而是一套人类基因知识底座 Human_Genes_Functions 的目标不是简单做一个基因搜索框，也不是把几个文件放到服务器上供下载。它更接近一个长期演进的人类基因功能信息系统。 Stage 1 的目标可以拆成两层。 第一层是数据底座： 第二层是 Web 入口： 这两个层次的关系非常重要： 数据库和 FASTA 是系统底座，Web UI 只是受控查询层。浏览器看到的是查询结果，不是原始数据文件。 二、数据基线：以 GRCh38.p14 与 GENCODE Release 50 为核心 项目的数据基线采用 GRCh38.p14 和 GENCODE Release 50。这个选择决定了后续所有基因、转录本、外显子、CDS、蛋白关系和坐标体系的基础。 GENCODE 层提供的是整个系统的主骨架： 这些信息进入 SQLite 后，构成最基础的结构表： 从数量上看，这不是一个玩具数据库。系统中整理了约 78,733 个基因、644,292 条转录本、5,078,384 条外显子记录和 3,210,731 …

Games

用自然语言控制 AI Agent，在 Minecraft 超平坦世界里建造一座小镇

这是一组关于 AI Agent 控制 Minecraft 服务端的实验记录。 实验目标不是手动一块一块放置方块，而是把 Minecraft 服务端交给本地 AI Agent 控制：通过自然语言描述建筑目标、风格、范围和限制，再由 AI Agent 通过 RCON 向服务端发送命令，自动完成规划、建造、保存和报告。 最终结果是在一块超平坦区域中完成了一座木石混合风格的小镇。小镇包含中心广场、南北主路、东西支路、住宅、工坊、谷仓、旅店、守卫小屋、礼拜堂、面包铺、马厩、农具棚、果园、市场、农田、入口门拱、道路灯光、庭院、树篱、货物堆和生活装饰。 最后会附上一张建成后的截图。 一、整体结构 这套流程的核心结构如下： AI Agent 并不是作为一个普通玩家进入游戏，也不是在客户端里手动操作，而是通过 RCON 作为服务端控制端执行 Minecraft 命令。 客户端的主要作用是进入服务器观察结果、确认效果，并为下一轮自然语言指令提供反馈。 二、服务器控制方式概念 本次使用的是本地 Minecraft Forge 服务端。公开记录中不保留实际 IP、端口、用户名、密码和本机路径，统一使用占位符表示。 服务端目录示例： RCON 调用方式示例： 例如： 服务端配置中比较关键的项目可以概括为： 这里最重要的原则是： 三、前置检查用自然语言指令 正式建造前，先让 AI Agent 检查服务端和客户端环境，确认 Forge 版本、启动方式、Java 版本、服务端配置、客户端连接方式和 RCON …

Games

使用 AI Agent 连接 Minecraft 服务端：一种本地自动化建造实践

AI Agent 不一定只能停留在浏览器、终端或文件系统里。只要目标软件提供可编程接口，Agent 就可以通过自然语言指令进一步控制外部程序。Minecraft 是一个很适合实验的对象：它既有可视化世界，又有服务端命令、RCON、模组和世界文件结构，可以把“自然语言 → 自动执行 → 可视化反馈”这条链路完整跑通。 本文整理一种本地实验方案：在 Linux 桌面环境中运行 Minecraft Forge 服务端和客户端，由 AI Agent 通过 RCON 控制服务端，玩家客户端负责观察和反馈。整个过程以本机测试为主，不暴露公网，不依赖多人联机环境。 一、基本思路 整体结构可以概括为： 在这种结构下，AI Agent 并不是一个“进入游戏的玩家”。它更像是服务端管理员控制台，可以执行命令、改变方块、保存世界、调整时间天气、传送玩家，甚至通过批量命令完成建筑和地形改造。 玩家客户端则承担观察者角色。玩家可以站在高处、使用创造模式或旁观模式，实时查看 AI Agent 对世界做出的修改。 二、为什么使用服务端，而不是直接改客户端单人世界 如果只是普通游玩，客户端单人世界已经足够。但如果目标是让 AI Agent 参与自动化建设，专用服务端更适合。 服务端具备几个优势： 在本地测试中，服务端和客户端可以运行在同一台电脑上。客户端连接地址通常使用本机回环地址，例如： 这样不需要开放公网，也不需要让局域网其他设备访问。 三、服务端与客户端的匹配检查 在连接之前，需要确认服务端和客户端基础环境一致。重点包括： 对于 Forge 1.19.4 一类环境，Java 17 通常是更合适的选择。如果系统默认 Java 版本更高，服务端启动脚本中最好显式指定 Java 17，避免因为默认版本变化导致启动异常。 模组方面，服务端模组必须能被客户端识别。客户端可以额外保留一些只影响本地操作或显示的模组，但不应把客户端的 …

AI

OpenClaw 升级后无法打开可见浏览器的排查与修复

问题现象 在一台 Arch Linux + KDE 桌面环境中，OpenClaw 升级后出现了一个问题：终端中的 OpenClaw TUI 可以正常连接 Gateway，Agent 状态也显示为 connected / idle，但执行“打开浏览器”之类的任务时失败。 报错大意如下： 这说明 OpenClaw Gateway 本身并没有崩溃，WebSocket 连接、Agent 会话和后端服务都还在运行。问题集中在一个地方：Gateway 进程无法访问当前 KDE 图形会话，因此不能启动可见浏览器窗口。 初步判断 Linux 桌面环境中，GUI 程序通常依赖一些图形会话环境变量，例如： 在 KDE 终端里执行检查时，当前 shell 环境是正常的： 可以看到类似结果： 但是进一步检查 OpenClaw Gateway 进程环境： 结果只包含： 缺少关键的： 这就确认了问题：OpenClaw Gateway 作为 systemd user service 启动时，没有继承 KDE …

AI

OpenClaw 配置文件明文密码迁移记录

背景 在一次 OpenClaw 日常检查中，执行了如下命令： 检查结果显示 OpenClaw 本体运行正常，Skills 与 Plugins 均无明显异常： Memory search 处于明确关闭状态： 这不是故障，而是配置选择。 真正需要关注的是 Security 部分的两个提醒： 其中第二项表示 Gateway 监听 0.0.0.0，允许局域网访问。对于需要从局域网其他设备访问 OpenClaw 的场景，这属于有意配置，不是错误。 第一项则更值得处理：gateway.auth.password 以明文形式保存在 openclaw.json 中。虽然这不代表密码已经泄露，但如果本地 agent、插件或 workspace 工具可以读取配置文件，就有机会看到该明文密码。因此，本次处理重点是将该字段迁移到 SecretRef，也就是改为从环境变量读取。 当前状态判断 初始检查结果说明： 因此，本次处理目标不是“修复坏掉的服务”，而是“收紧安全配置”。 修改前备份配置文件 在修改配置文件前，应先备份当前配置： 备份完成后，再进行 SecretRef 迁移操作。 配置 Secret Provider 执行： 进入交互式配置后，首先添加 Secret Provider。 界面提示： 选择： Provider source …

Food

スムージー是什么：从果昔到绿豆冰沙

スムージー 是日语里的外来语，来自英语 smoothie，一般可以理解为“果昔”或“冰沙”。 它通常是把水果、蔬菜、牛奶、豆奶、酸奶、冰块等材料放进搅拌机里打成浓稠饮料。和普通果汁不同，スムージー往往保留了果肉和纤维，所以口感更厚，也更有饱腹感。 比如日语里常见的说法有： バナナスムージー：香蕉果昔グリーンスムージー：绿色蔬果昔プロテインスムージー：蛋白质奶昔 如果是中文里常见的“绿豆冰沙”，在概念上也可以算是一种スムージー。日语可以说： 緑豆スムージー或者更偏台湾甜品风格地说：緑豆沙、緑豆ミルクスムージー 不过在日本，绿豆冰沙并不是特别常见。普通便利店或咖啡店里一般很少见，更可能出现在台湾甜品店、中华料理店、亚洲食品店或者夏季限定菜单里。 所以，简单来说： スムージー是浓稠型果昔/冰沙；绿豆冰沙也可以算スムージー的一种，但在日本属于比较偏台湾、中华甜品风格的饮品。

AI

从本地 AI Agent 到手机聊天入口：一次桌面端 OpenClaw 的远程访问与 LINE 接入实践

本地 AI Agent 的价值，不只在于能够回答问题，更在于它可以直接接触本机环境：读取工作目录、生成文件、调用本地工具、整理资料、执行批量操作。相比完全运行在云端的聊天机器人，本地 Agent 更像是桌面系统里的一个可控助手。 不过，本地运行也带来一个现实问题：如果只能在电脑前通过浏览器访问，它的使用范围仍然受到限制。为了让本地 Agent 能够在手机上随时使用，可以将本机服务通过安全的方式暴露到公网域名，并进一步接入聊天平台。这样一来，手机上的普通消息窗口就可以成为本地 Agent 的控制入口。 这次实践完成的目标，是将一套安装在 Linux 桌面环境中的 OpenClaw，从单机本地访问，扩展为可以通过 HTTPS 域名访问，并最终接入 LINE Messaging API，实现手机 LINE 与本机 OpenClaw 的直接对话。 一、本地服务从回环地址调整为局域网可访问 最初，OpenClaw Gateway 只面向本机访问。这种方式适合纯桌面使用，但反向代理服务器无法从局域网访问该服务。 因此第一步是调整 Gateway 的监听方式，让它从本机回环地址改为局域网可访问。调整后，OpenClaw Gateway 可以监听在所有网卡地址上，局域网内其他主机便能够访问该端口。 同时，Gateway 启用了内置的密码认证。这里没有把认证放在反向代理层，而是让 OpenClaw 自己负责登录与设备配对。这样做的好处是认证逻辑更集中，也更符合 OpenClaw 自身的设计。 整体思路是： 完成配置后，需要重启 OpenClaw Gateway，并确认服务已经监听在局域网地址上。随后还需要在本机防火墙中开放对应端口，使反向代理服务器可以正常连接。 二、通过反向代理提供 HTTPS 域名访问 本地 Gateway 可以被局域网访问后，下一步是在反向代理服务器上增加一个新的站点配置。 反向代理服务器负责处理公网 …