NanoClaw Telegram 机器人停止响应时，第一步不是修复，而是判断入站消息是否根本到达了主机，因为已有两种分别报告过的 NanoClaw 故障会产生这一现象，但特征完全相反。 一种情况下，入站功能失效，而出站投递和计划任务仍在工作，因此操作员检查的每个界面看起来都很健康。另一种情况下，任何内容都无法发送，日志却将从未发送的消息标记为已投递。同样的现象，不同的原因，针对其中一种情况的修复对另一种情况毫无作用。
在其他操作之前先做一个区分，因为这个短语的搜索结果大多讲的是另一个产品。OpenClaw 是一个独立且规模大得多的项目——在 2026 年 9 月 21 日读取其仓库 API 记录时，它有 390,207 个 star，许可证为 NOASSERTION——而 NanoClaw 自己的主页也将其作为对比对象。NanoClaw 是 nanocoai/nanoclaw：采用 MIT 许可证，未归档，不是 fork，有 30,818 个 star、1,068 个未关闭 issue，最近一次推送于 2026 年 9 月 19 日（GitHub API，同一日期）。旧的 qwibitai/nanoclaw 地址会返回 301 并指向该地址，因此这是同一个项目改名后的地址，而不是第二个项目。这两个项目不共享任何 Telegram 代码路径——NanoClaw 通过从其 channels 分支复制源代码来安装自己的适配器（add-telegram skill）——因此 OpenClaw 的修复方案不能直接套用。完整差异请参见 NanoClaw 与 OpenClaw。
在动手之前先读取故障特征
下面每一行都是一个独立、分别报告过的故障，并有各自的确认检查。全部八项均于 2026 年 9 月 21 日从 NanoClaw 自己的 issue 跟踪器、已发布的 skill 和频道文档中读取。
| 你观察到的现象 | 最可能的原因 | 确认原因的检查 |
|---|---|---|
| 你发送的任何内容都没有回应，但回复、计划消息和出站投递仍然正常 | 轮询循环失败并无限重试——issue #3728，未关闭 | 一行带有较大 consecutiveFailures 值的 Telegram polling request failed；成功日志不会记录任何内容，因此日志安静并不能证明服务健康 |
任何内容都无法发送；主日志显示 Message delivered，其旁边有 platformMsgId=undefined 和 No adapter for channel type | 同时运行了两个主机实例——第二个轮询器从 Telegram 收到 409，并在适配器注册前中止初始化（/debug skill、PR #2225） | 没有出现针对 telegram 的 absence Channel adapter started 行，同时 ps aux 中存在第二个进程 |
| 私聊和群组消息正常；频道帖子完全不会到达 | 机器人令牌上的服务器端更新过滤器过时——issue #2989，未关闭 | 此令牌之前是否曾由 NanoClaw v1 或其他机器人库轮询？Telegram 自己的 Bot API 对 allowed_updates 的说明是：“如果未指定，将使用之前的设置。” |
| 机器人会回复私聊消息，但忽略普通群组文本 | 群组隐私已开启（add-telegram skill） | BotFather、/mybots、Bot Settings、Group Privacy——之后重新将机器人添加到群组 |
| 消息功能正常，但配对始终无法完成 | 启动时的 getMe 曾失败一次，并且进程整个生命周期内缓存了空的机器人用户名——issue #3162，未关闭 | 启动时出现一条 Telegram getMe failed 警告，几分钟后你才尝试配对；该 issue 报告称重启可以清除它 |
| 初始化因“Couldn't reach Telegram”中止，或启动卡住约一分钟半 | 已配置 IPv6，但没有可用路由——issue #2377，未关闭 | 对 Bot API 执行 curl -4 成功，而 curl -6 无法连接 |
| 大多数回复都能收到，但包含某些 URL 的回复永远收不到 | 这是出站格式问题，而不是接收问题：issue #3569 报告称，已固定的适配器会截断包含奇数个未转义标记的消息 | Telegram 拒绝发送；两个单下划线 URL 彼此抵消，因此看起来像是间歇性故障 |
| 你刚添加的第二个机器人始终无法上线 | 实例变量只在启动时读取，并且重复令牌会被跳过（频道文档） | logs/nanoclaw.error.log 中有一条警告（add-telegram skill）；Telegram 允许每个令牌只有一个轮询器，因此每个机器人都需要自己的 BotFather 令牌 |
NanoClaw 的官方一线诊断包括两个日志文件，以及 ncl sessions list、ncl dropped-messages list 和 ncl wirings list。没有任何已发布版本提供频道存活检查命令，因此下面的分诊主要依靠日志行。
# 1. Is inbound polling failing, and for how long?
# A rising consecutiveFailures count is the #3728 signature.
grep "Telegram polling request failed" logs/nanoclaw.error.log | tail -5
# 2. Did the Telegram adapter ever register this boot?
# Its ABSENCE is the duplicate-host signature, not an error line.
grep "Channel adapter started" logs/nanoclaw.log | tail -10
# 3. Is a second host holding the polling session?
ps aux | grep 'nanoclaw/dist/index.js' | grep -v grep
systemctl --user list-units 'nanoclaw*' --all # Linux systemd installs为什么入站失效时一切看起来仍然正常
这是架构层面的原因，也是最浪费时间的部分。NanoClaw 的 README 将路径描述为：消息应用到主机路由器，再到入站数据库，进入容器，进入出站数据库，然后通过投递返回。投递会独立轮询出站数据库，主机每 60 秒也会独立唤醒到期消息和周期性消息。只有入站阶段依赖 Telegram 轮询器——这正是 #3728 的报告者看到主机保持活动、出站投递继续工作、计划任务持续触发，而入站消息整整约四天没有任何响应的原因；期间记录了连续 11,178 次失败。
本应捕获该问题的健康检查钩子并没有做到这一点。NanoClaw 发布的 适配器接口参考说明，isConnected()“目前除测试外不会由主机调用”，并且“桥接器始终返回 true”。主分支后来发生了变化：一个报告每个适配器连接标志的 ncl status 命令于 2026 年 9 月 15 日在 main 上合入，晚于 v2.3.0 发布，因此该文档对所有已发布版本仍然准确，但对主分支已经过时。应将该命令视为尚未发布的内部功能，而不是使用建议——它以隐藏且仅限主机的方式注册，并未出现在任何文档中。对于 Telegram，这两条路径最终仍会汇合：适配器的 4.29.0 和 4.41.0 版本都完全没有实现 isConnected（本页已对两个 dist 构建进行 grep），因此无论如何探测都会回退到 true。
文档也存在对应的缺口。故障排除页面有一个标题为“Webhook channel is silent”的章节，却没有轮询对应章节；其“Agent never replies”排查流程从“Did the router accept it?”和 ncl dropped-messages list 开始——这一步已经假设消息到达主机。当轮询器停止工作时，不会有可查找的丢弃消息记录，因为路由器根本没有看到该消息。对于自身的原因，#2989 也记录了同样的死路：没有日志行、没有丢弃消息记录，什么都无法用于调试。
没有修复版本，因此请围绕缓解措施制定计划
#3728 仍未关闭，零条评论、零个标签、没有里程碑，其更新时间戳仍等于创建时间戳，即 2026 年 9 月 6 日。最新版本是 2026 年 8 月 24 日发布的 v2.3.0，而 channels 分支自 9 月 1 日以来唯一的提交是一个 Mattermost 修复。过时过滤器问题也是如此：本应固定显式更新列表的 pull request 自 2026 年 8 月 22 日起一直针对 channels 保持开放，而当前分支源代码中完全没有出现 allowedUpdates。本可防止重复主机问题的单实例主机锁在未合并的情况下被关闭。因此，诚实的表述应是缓解措施，而不是某个版本号。
在编写自己的补丁之前，有三件事值得了解。第一，对 src/channels/telegram.ts 的本地编辑不会保留：add-telegram skill 会从 channels 分支复制该文件，并指示覆盖，因为该分支是规范来源；update skill 会刷新所有已安装的频道——这正是 #3728 报告者每次更新都会丢失该修复的原因。第二，报告者的 watchdog 既是警告也是操作方案：仅计数器的第一版造成了更严重的三天中断，因为轮询器最终变成了停止状态而不是失败状态，所以之后不再记录失败，计数器也永远无法达到阈值。第二版使用两个独立信号，并且从未让轮询器保持停止状态。这些内容都未随产品发布、未获官方认可，也未经过独立验证。第三，无论你构建什么，都要双向测试恢复：出站成功不能证明入站正常，因此真正重要的检查是，从已配对的聊天中发送一条新消息，并产生一条新的入站记录。
Telegram 频道故障不是模型或 API 问题
有必要直说这一点，因为接下来的直觉搜索会把人引向错误方向。NanoClaw 的 凭据文档说明，TELEGRAM_BOT_TOKEN 这类频道令牌保存在 .env 中，并由主机进程使用，而不是由容器使用；模型凭据则保存在 vault 中，并在请求发送过程中注入出站请求。入站消息会在选择任何 provider 之前到达路由器和会话的入站数据库，因为 provider 会在容器生成时解析（agent providers documentation）。任何 base URL、密钥、网关或 provider 更换都无法修复停止的轮询循环、过时的更新过滤器、轮询器冲突、群组隐私设置或损坏的 IPv6 路由。
真正的交叉点反过来。NanoClaw 的 README 将 Claude Code 列为依赖项，专门用于 /customize、/debug 和每个 /add-channel skill，因此即使你的 agent 群组运行在其他平台上，修复频道仍需要在主机上安装它。主机要求是 macOS 或 Linux、通过 WSL2 使用 Windows、Node.js 22 或更高版本、pnpm 10 或更高版本，以及 Docker——请注意，nanoclaw.dev 仍宣传 Node.js 20 或更高版本，而 README 和 v2.3.0 更新日志将 22 设为硬性最低版本。应以更新日志为准，其中称该升级会破坏兼容性。
NanoClaw 及其 Telegram 频道的实际成本
| 项目 | 费用 | 来源 |
|---|---|---|
| NanoClaw 本身 | $0，采用 MIT 许可证，没有付费层，也不需要用户账户 | nanoclaw.dev：“NanoClaw 采用 MIT 许可证，是免费且开源的。” |
| 社区门户账户 | 免费且自愿；没有它也不影响其他功能 | 项目 README |
| Telegram 机器人令牌 | 在 BotFather 中创建的费用为 $0；对于一个已配对的聊天无需购买任何内容——Telegram 的可选 Paid Broadcasts 层级仅适用于每秒超过 30 条消息的情况 | Telegram Bot API；根据频道文档，轮询模式也意味着不需要公共 URL、webhook 或开放端口 |
| 模型用量 | 由所连接的 provider 收取相应费用；NanoClaw 本身不收取任何费用 | nanoclaw.dev FAQ：“你的 agent provider 可能会收取模型用量费用。” |
| Docker | 主机必需；超过 Docker 免费使用阈值后适用 Docker 自身的订阅条款 | 本页未核查——在进行预算规划前请阅读 Docker 的定价页面 |
没有付费层可以让你花钱摆脱无响应的机器人，这就是该表格告诉你的实用结论。只有频道恢复工作且 agent 开始响应后，才会产生费用。下面的数字是示例性的令牌算术，不是测得的任务成本，也不是账单上限：假设一个已配对的聊天每天 25 轮，每轮包含 20,000 个未缓存输入令牌和 900 个输出令牌，持续 30 天。费率采用实时的 Kunavo catalog 每百万令牌价格。
| 模型 | 每 1M 个令牌的输入 / 输出 | 预计每月费用 |
|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $12.86 |
| GPT-5.6 Terra | $0.70 / $4.20 | $13.34 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $38.59 |
| Claude Opus 5 | $3.50 / $17.50 | $64.31 |
在将其视为预算之前，请按你自己的流量进行缩放，并注意最起作用的假设：没有任何内容来自缓存。长期运行的 agent 会重新发送上下文，因此缓存行为对该数字的影响大于相邻两个模型之间的每令牌价格差异。Kunavo 的 catalog 金额是计费下限而不是上限——上游报告费用时，账单金额取 catalog 成本与上游成本乘以适用加价两者中的较大值。最低充值额为预付余额 $10，这是资金最低要求，不是任务费用或订阅费用；参见 billing details。
| agent 的模型路由 | 适用场景 | 它不能做什么 |
|---|---|---|
| 直接调用提供商 API | 你要继续使用某个供应商的旗舰模型，并希望使用该供应商自己的缓存和批处理条款 | 第二个供应商意味着第二个账户和第二个余额 |
| 兼容 OpenAI 或兼容 Anthropic 的网关 | 你要按 agent 群组切换模型，并希望使用一个密钥和一个余额 | NanoClaw 的原生 provider 是 Claude Agent SDK，因此自定义 base URL 必须使用该线路格式；OpenAI 格式的端点通过 OpenCode provider skill 访问，该 skill 会通过 OpenCode 自己的配置路由模型 |
| 订阅 | 相比按令牌计费，你更适合固定费率的高频日常使用 | NanoClaw 不销售自己的订阅；固定费率属于 provider |
| 本地模型 | 小规模或私密工作，且不产生托管模型账单 | NanoClaw 自己的 Ollama skill 被描述为面向较旧的配置路径，在当前主分支上并不是受支持的直接切换方案 |
这四种选择都不会触及 Telegram 路径。关于 provider 端的完整说明——setup 读取的两个环境变量、容器实际看到的内容，以及 OpenCode 和 Codex 所处的位置——请参见 NanoClaw API costs and providers。如果你要将默认 Claude runtime 连接到自定义端点，Claude Code integration guide 和 base URL reference 会介绍配置；准备为密钥充值时，可以创建 Kunavo 账户。Kunavo 尚未对 NanoClaw 进行运行时测试，已发布的设置指南是配置参考，而不是兼容性测试。
常见问题
为什么我的 NanoClaw Telegram 机器人停止响应？
先确认消息是否仍在离开主机。如果回复和计划消息仍能到达，但你发送的内容没有得到回答，那么应怀疑入站轮询：NanoClaw issue #3728 报告称，适配器的轮询循环会以 30 秒的退避上限无限重试 getUpdates，永不放弃，并且成功轮询时不记录日志，因此故障不可见。如果发送也完全停止，并且日志在“No adapter for channel type”警告旁显示带有 platformMsgId=undefined 的“Message delivered”条目，那么 NanoClaw 自己的 /debug skill 指出原因是同时运行了两个服务实例。这两种情况的处理方式相反，因此在更改任何内容前先识别日志特征。
NanoClaw Telegram 轮询漏洞有固定修复版本吗？
没有，截至 2026 年 9 月 21 日仍没有。Issue #3728 处于开放状态，评论数为 0、标签数为 0、没有里程碑，其更新时间仍等于提交日期 2026 年 9 月 6 日。NanoClaw 最新版本是 2026 年 8 月 24 日发布的 v2.3.0，因此报告之后没有任何版本发布；自 9 月 1 日以来 channels 分支唯一的提交是 Mattermost 修复。任何告诉你升级到某个特定 NanoClaw 版本即可解决该问题的人，所说的版本都不存在。
升级 @chat-adapter/telegram 能解决问题吗？
不能解决无声失效的路径。NanoClaw 将 @chat-adapter/telegram 精确固定为 4.29.0，该版本发布于 2026 年 5 月 18 日，而 npm 的最新 dist-tag 是 2026 年 9 月 18 日发布的 4.41.0。本页下载并比较了两个 tarball：两个构建中的 getUpdates 传输失败分支实质相同——相同的 consecutiveFailures 计数器、相同的 30 秒退避上限、相同的警告行，既不放弃重试，也不升级处理故障，成功轮询仍不记录任何日志。4.41.0 确实重写了循环的其他部分。本页将其作为代码事实陈述，并不建议提高固定版本号：NanoClaw 的 add-telegram skill 称供应链政策拒绝版本范围；本页查阅的两个升级拉取请求（#3460 和 #3570）仍处于开放且未合并状态；此处无人测试升级还会改变什么。
更换 API 提供商或基础 URL 能解决 Telegram 问题吗？
不能。NanoClaw 的凭据文档说明，TELEGRAM_BOT_TOKEN 等频道 token 保存在 .env 中，由主机进程而非容器使用；模型凭据则进入 vault，并注入容器流量。入站 Telegram 消息会先到达路由器和会话的入站数据库，然后才解析提供商，而提供商解析发生在容器启动时。因此，不同的端点、密钥或网关无法修复已停止的轮询循环、过时的服务器端更新过滤器、轮询器冲突、Group Privacy 或损坏的 IPv6 路由。唯一的反向交叉依赖是：NanoClaw README 将 Claude Code 列为 /debug 和所有 /add-channel skill 的要求，因此即使智能体运行在其他位置，修复频道也需要主机上有 Claude Code。
机器人能回复私信，却忽略群组。为什么？
这通常是 Telegram 的 Group Privacy 设置，而不是 NanoClaw 缺陷。NanoClaw 的 add-telegram skill 说明，启用 Group Privacy 后，机器人只能看到被点名的命令和回复，看不到普通文本；你需要在 BotFather 中依次进入 /mybots、你的机器人、Bot Settings、Group Privacy 将其关闭，然后移除并重新添加机器人到群组，使更改生效。另有一种情况看起来相似但原因不同：NanoClaw issue #2989 报告称，先前使用更窄 allowed_updates 过滤器轮询过的机器人会永久保留该服务器端过滤器，从而静默丢弃频道帖子，而私信和群组仍可正常工作。
配对始终无法完成，但机器人仍能工作。出了什么问题？
NanoClaw issue #3162 正好描述了这种情况：如果频道启动时的 getMe 调用失败一次，机器人用户名会在整个进程生命周期内被缓存为 null，你发送的每个配对代码都会被当作普通消息处理，没有任何尝试记录，安装程序会无限等待。唯一的痕迹是启动时的一条警告，出现在你尝试配对前几分钟；该 issue 称无需其他更改，只需重启即可修复。当前 channels 分支适配器仍只执行一次查找，不会重试，并会缓存结果。还要注意，NanoClaw 文档描述的是一次性 6 位代码，每次运行最多可重新生成 5 个代码，而 issue #3162 称其为 4 位代码；请以文档为准。
核查日期为 2026 年 9 月 21 日：nanocoai/nanoclaw 仓库记录和发布列表；issue #2377、#2989、#3162、#3569、#3728 以及 pull request #2225、#2697、#3449、#3460、#3570 的开放/关闭状态；channels 分支中的 Telegram 适配器源代码；npm 中固定的 4.29.0 版本和当前的 4.41.0 适配器构建；NanoClaw 的频道、凭据、故障排除和适配器接口文档；其 add-telegram 和 debug skill；以及 Telegram 的 Bot API 页面。本页没有任何内容在运行中的 NanoClaw 安装上执行过。Kunavo 令牌费率来自实时目录，美元金额是令牌用量算术计算的示例。