维护消息网关,不另造一套聊天产品

OpenClawGateway

我希望从 Telegram 或飞书交办事情,电脑上的 OpenClaw Gateway(网关)默认交给已配置的本地模型,明确选择并允许时才使用远程模型,再把结果送回原渠道。这个项目让 AI 负责 Windows 上的运行检查、更新和备份恢复,我不需要长期打开终端盯着它。它不是第二个聊天机器人;页面保留的运行观察也不等于整条消息链已经实测完成。

项目状态
Gateway(网关)RPC(远程过程调用)与健康检查通过;Telegram已连接,飞书启动中;消息E2E(端到端收发)0/2
快照边界
现有证据中Telegram已连接、飞书仍启动中,真实入站到回复的闭环未验;这些是有日期的历史观察,不是本轮重新调用网关的结果。
观察时间
复制 AI 续作说明带着这个项目,交给 AI 接着做

写下接下来想做什么。这里会把你的目标、本页事实和来源整理在一起,复制给 Astra 或 Gemini 后,就不用重新介绍项目了。

整理续作说明

只在当前网页整理,不会发起 AI 任务。

用途与结果

最快了解这个项目

为什么需要它

网关端口还在,并不说明 Telegram 或飞书消息真的送达;默认选本地模型,也不说明所有会话都不会产生远程费用。这个项目把消息、模型、网关、备份和更新分别检查,让 AI 说明每一层的真实结果,再处理明确的问题。

举个实际例子

“OpenClaw现在为什么没回消息?先检查,不要发测试消息或重启。”工具分别查看网关、渠道、模型与任务,说明已知状态和仍缺哪段证据;只看到连接成功,不会说请求已处理或回复已送达。

最后我会得到什么

得到网关、消息渠道、模型选择、后台任务和恢复材料各自的结论,以及对应的下一步。需要更新或恢复时走原有明确流程,先保留现状;技术层完整保留已有观察日期、超时样本和未解决的消息验收缺口。

正常时

上次网关接口和健康检查通过;Telegram 当时显示已连接,但两条渠道的真实消息往返仍未验收。历史超时不因一次健康结果消失。

发现问题时

飞书仍在启动、旧网关请求曾超时,或备份任务有旧失败时,分别标出影响哪一层;不会把整个系统写成全好或全坏。

入口不可用或证据不足时

状态读不到、网关监听异常、恢复点损坏或版本关系不清时,停止相关修改,保留最后能证实的状态和恢复材料。

从哪里开始

在已接通本机 OpenClaw 管理入口的 AI 对话中先说明要查状态、交办、更新还是备份;真实聊天从已连接的 Telegram/飞书渠道发送。

需要准备什么

  • 想交办的事或遇到的故障
  • 要用 Telegram 还是飞书
  • 需要时明确选择模型或维护动作

从开始到拿到结果

  1. 1
    先查现役状态

    AI 只读核对 Gateway 配置、RPC、健康、模型目录与目标渠道;端口和任务存在不代表可用。

  2. 2
    从已连接渠道交办

    在 Telegram 或飞书发明确任务,再分别核对入站、执行和原渠道回信;渠道未接通时停在状态检查。

  3. 3
    变更先有恢复点

    更新或部署须有明确目标,预演或官方备份后执行;随后重新读版本、模型、渠道和任务结果。

  4. 4
    故障按真实层级恢复

    分清配置、渠道、模型认证、网关和备份问题;未验收或维护冻结范围保持原观察日期。

从这些需求了解功能

从一个实际问题看它怎样处理、交回什么;当前能做到哪一步和仍有哪些限制,也写在对应说明中。

01渠道交办帮我确认Telegram和飞书现在是不是真的能交办;先不要发测试消息。Telegram已连接、飞书仍启动中;最新网关RPC与健康检查通过,早先超时原因仍未查明。消息E2E(端到端验证)还是0/2,连接和健康不等于完成入站、执行和回发。查看使用步骤与完整说明02模型与成本默认是不是本地模型?还有没有可能花远程模型费用?默认 qwen3.8:27b 属于本地路线且没有自动远程回退;仍有 21 条可手选远程路线,已有会话和定时任务是否另有覆盖本轮未核对。查看使用步骤与完整说明03网关常驻先看 Gateway 健不健康;不要重启,除非真的需要修复。只读核对配置、远程调用、健康检查、唯一回环监听和任务状态;健康就不动,异常时先说明是哪一层,再决定是否修复。查看使用步骤与完整说明04受控更新看看稳定版有没有更新,但先不要安装。当前网关仍健康,但三次检查都没有取得稳定目标版本,所以现在无法判断是否有更新;不会因此停止或重启。查看使用步骤与完整说明05备份与恢复让 AI 核对今晚三条备份和 PUBLIC(公开) 自动归档;共享任务非零时定位 Claude 和 OpenClaw 两段,不要漏跑第二段。分别交回 3 个任务、4 个备份对象、本地/G/私人 Git 恢复点和公开远端结果;当前三项自然备份与修复后的公开归档实跑均成功,未来调度仍需各自回读。查看使用步骤与完整说明06部署与引导在一台全新 Windows 上预演安装,公开模板里的配置没填完就停。在任何安装或写入前先检查私人配置、未填项和数据结构;本轮仍没有完成全新 Windows 实机验收。查看使用步骤与完整说明07CodeG / Cline 接入把 OpenClaw 接给 CodeG 里的 Cline,别把密码写进配置。先写入不含明文密码的桥接配置并保留其他服务;只有 CodeG 真正完成连接、列出工具并成功做一次只读调用,才算接入完成。查看使用步骤与完整说明
项目指标与相关入口查看规模、覆盖范围和关联能力

当前项目指标

运行版 / 稳定目标
2026.8.1 / Unknown(未知)
自动远程 / 可选远程
0 / 21
消息 E2E(端到端验证)
0 / 2
脚本入口 / Pester(PowerShell 测试框架)
14 exit 0 / 30/30

它负责

  • 让 AI 分别查看 OpenClaw 的版本、配置、网关响应、模型、渠道和后台任务,不靠一个端口判断整体健康。
  • 沿用 OpenClaw 原有的 Telegram 与飞书渠道交办,并区分“已配置”“已连接”和“消息确实往返”。
  • 说明默认模型、自动备用路线、辅助与图像模型,以及可手选的远程模型可能带来的费用边界。
  • 用官方入口管理本机唯一的网关;日常先只读查看,明确要求修复时再动作。
  • 更新前核对版本与恢复点,更新后重新检查配置、网关、模型和任务;部分成功就如实报告。
  • 创建和核验官方恢复点,先在全新暂存位置演练,不把演练自动覆盖到现役配置。
  • 用公开模板说明安装结构;私人配置在正确位置准备并预演,可选连接 CodeG/Cline。
  • 分别查看 Codex、Gemini、Claude 和 OpenClaw 的私人备份结果;本地、独立副本和远端各自核对。
  • 公开仓库自动归档前检查别人的未提交工作和远端分支状态,有冲突就停止。

它不负责

  • 不另做聊天客户端、模型平台或密码仓库;消息、会话和模型仍由 OpenClaw 负责。
  • 网页建设不会发送真实消息、调用付费模型、更新网关或激活灾备。
  • 默认本地不等于所有会话免费,也不替本人删除远程模型凭据。
  • 公开页面不展示账号、消息正文、密钥、私人备份位置和完整恢复材料。
  • 脚本测试、端口在线或配置写好,不能当作真实聊天、模型调用或桥接工具已通过。
  • 公开归档遇到他人的暂存改动、禁止内容或远端分叉就停,不靠强行推送覆盖。

产品思想与设计核心

01

AI 先读再动

日常状态和故障定位由 AI 查看;发外部消息、选付费模型、更新与恢复现役状态,需要对应明确目标和授权。

02

不造第二个聊天产品

Telegram、飞书、会话、模型和工具仍交给 OpenClaw;这里负责本机运行、可读状态和恢复路径。

03

一个绿灯只说明一层

渠道连接、网关响应、模型能调用、消息往返和任务完成是不同结果。旧成功也不能自动证明今天仍可用。

04

状态查看不能偷偷变成修复

只读查询不会顺便重启、更新或改配置;这些动作各有明确入口和写后回读。

05

模型费用按实际路线说

只有目录确认的本地模型才称本地;远程模型仍可手选、会话和定时任务又可能有各自设置,未核的范围直接写未知。

06

公开说明与私人运行材料分开

公开仓库只留可读的脚本和结构;账号、消息、原始日志及恢复归档留在私人位置。

07

有异常就停在对应层

端口归属不明、版本关系未知、配置坏了或备份校验失败时,停止那一步并交回原因;不把一个故障推广成所有能力都不可用。

08

尽量用 OpenClaw 原有能力

启动、更新、模型、备份和恢复使用官方入口,避免另养一套内部数据库或凭据复制流程。

AI 从哪里看状态,结果回到哪里

OpenClaw 自己负责聊天和模型;本项目只汇总公开安全的运行结果。私人消息和账号不进入网页。

01
Telegram 与飞书

查看所选渠道是否配置和连接;真实消息由本人在原应用发送。

只有收到消息、执行任务并回到原渠道三段都通过,才叫交办完成。

02
模型目录与选择

查看默认、备用、辅助和图像模型,以及仍可手选的远程路线。

说明哪些可能使用远程费用;不知道某次会话实际选了什么就保留未知。

03
网关与 Windows 后台任务

分别看网关能否响应、是否健康,以及计划任务有没有运行和失败。

端口、任务状态和实际服务能力分别报告,避免一个绿灯掩盖另一个故障。

04
官方更新与恢复点

先比较当前版本与目标,再确认备份;恢复演练只写入新暂存位置。

知道更新有没有完成、哪些后验失败;暂存成功不等于现役灾备已激活。

05
Codex 的私人备份

只选适合恢复的小型可读配置,不把原始会话和认证材料混入。

本地、独立副本和远端各自核对;某层失败不抹掉已完成的那层。

06
Gemini 的私人备份

只保留适合恢复的轻量资料,排除原始会话和媒体。

分别确认本地、独立副本和远端状态。

07
Claude 项目资料备份

按已配置项目保存各自可读的资料。

逐项目确认恢复点,不把共享任务一个退出码当成全部结果。

08
OpenClaw 配置与工作区备份

保存需要恢复的配置和工作区,跳过可再生成或不应镜像的内容。

核对每一层副本,但仍需要另做实际应用恢复。

09
私人备份任务

读取各任务最近一次结果,并分清共享任务中的 Claude 与 OpenClaw。

指出哪一个备份消费者成功、失败或仍未验证。

10
公开仓库归档

先检查将提交什么、是否有他人的暂存改动以及远端是否分叉。

条件满足才提交并读回远端;有冲突时保留现场。

11
CodeG/Cline 可选桥接

先保存不含明文密码的工具连接配置。

真正刷新、列出工具并调用成功后才称客户端接通。

12
公开源码与隔离测试

检查实现和虚构测试的结果,不把测试当真实渠道消息。

说明代码具备什么、实际运行又验收到了哪一步。

公开页只给脱敏状态;所有渠道、模型、备份和更新结论都绑定各自观察时间。

项目怎样演化到现在

先把消息渠道与电脑模型接起来

形成Windows网关常驻、模型与消息渠道的运行方案,并留下备份与已有客户端接入路径。

阶段依据
  • 2026-06-19—2026-06-21 · 早期网关常驻与渠道方案;单文件开关和跨责任源写入是后来退出的旧做法。4e77f2f—e48a7fd

让产品回到官方工具各自的职责

模型、会话和认证交回OpenClaw官方入口;本项目保留状态、生命周期和部署恢复,退出用单一开关冒充全局成本控制的做法。

阶段依据
  • 2026-08-30—2026-08-31 · 生命周期、模型、会话和认证回归官方入口,不复制另一套内部数据库语义。65d5e07—f19f325

把运行、备份和交付分开证明

明确各备份消费者的独立结果,云端失败不抹去本地副本;公开归档去掉占满任务时间的长等待,恢复先到新暂存位置,真正激活另验。一次健康检查不抹掉超时历史,也不证明消息已收发。

阶段依据
  • 2026-09-03—2026-09-04 · 独立备份结果与公开归档分开;删除跨时间长退避,失败及时交回,历史自然运行成功不晋升为当前消息收发验收。f89fb14—aa4f9f1