signal online Asaqe Lee --:--:-- UTC reading mode
02 Asaqe.
System Record / Infrastructure Stack 6 min read openclaw-telegram-mcp-super-assistant

我怎么把 OpenClaw 打造成“超级助手”：从 Telegram 到 MCP 的一套实战

Telegram 偶发失联多半是网络栈；把 MCP 和技能收进可控边界，助手才能长期维护。

我怎么把 OpenClaw 打造成“超级助手”：从 Telegram 到 MCP 的一套实战

我怎么把 OpenClaw 打造成“超级助手”：从 Telegram 到 MCP 的一套实战

这是一篇复盘文：从“为什么 Telegram 偶发失联”开始，一路排查到“如何把 MCP 接入、如何挑选技能并保持可控”，最后形成一套我自己能长期维护的个人 AI 助手工作流。

TL;DR

  • Telegram 偶发网络错误（`getUpdates/sendMessage Network request failed`）很多时候不是 token 配错，而是网络栈（IPv6/代理/TUN/长运行进程）叠加导致的“看起来像网络，实际是环境问题”。
  • MCP 不是为了酷：它解决的是“把外部能力变成稳定可复用工具”的问题，尤其适合像我这样需要长期迭代的个人助手。
  • 超级助手的关键不在技能数量：而在于“工作流 + 风险边界 + 可回滚”。

1. 我想要一个什么样的“超级助手”

我对个人助手的期待很朴素：

  • 能在 Telegram 里随时对话（移动端最顺手）
  • 能在本机执行真实操作（脚本、文件、浏览器、配置）
  • 能做研究/开发/事务三类高频工作
  • 出问题能快速定位，配置能回滚，不会越用越乱

OpenClaw 的好处是：它是“在我的机器上跑”的，不是一个远端黑盒。

2. 问题一：为什么 Telegram 会偶发失联？

2.1 现象

我遇到的现象很典型：

  • 有时候能正常发消息（日志里会出现 `sendMessage ok`）
  • 但过一会儿又会报错：
    • `getUpdates failed`
    • `setMyCommands/deleteMyCommands failed`
    • `sendMessage Network request failed`

这类错误非常迷惑：你会直觉认为“Telegram 或网络挂了”，但它往往 不稳定地时好时坏 。

2.2 第一层判断：不是 token 配错

如果 token 配错，通常会是清晰的 401/403。

但我这里是“偶发网络失败”，并且日志里既有失败也有成功，所以更像 环境 / 网络栈 问题。

2.3 第二层排查：DNS 同时返回 A 与 AAAA（IPv4 + IPv6）

我在本机跑了 DNS 检查（示例）：

#IPv4
dig +short api.telegram.org A
#IPv6
dig +short api.telegram.org AAAA

结果显示：A 和 AAAA 都存在。

这会引出一个常见坑：

  • 系统/Node 进程可能会优先走 IPv6
  • 但你的 IPv6 egress（出口）未必稳定，尤其在需要代理/TUN 的环境里
  • 最终表现就是：“偶发网络失败”

OpenClaw 的 Telegram 文档也明确提到：`api.telegram.org` 可能优先解析到 IPv6，如果你的主机 IPv6 出口不通，grmmY/ 请求栈会卡住或失败。

结论：在“代理 /TUN + IPv6”场景下，Telegram 的偶发失败经常不是 Telegram 的问题，而是“解析与出口”的组合问题。

2.4 第三层排查：为什么 curl 好用，但 gateway 里 fetch 会失败？

我还发现一个更“玄学”的现象：

  • 单独用 curl/短脚本调用 Telegram API 往往正常
  • 但 OpenClaw gateway 作为长运行进程，某些 fetch 会失败（undici 连接池、DNS 缓存、keep-alive、代理接管差异）

这在 OpenClaw 的 issue 里也有人遇到过：同样是 `Network request failed`，但 curl 正常。

结论：不要只看“能不能连通”，要区分“短进程测试”和“长运行服务”的网络行为差异。

2.5 我的最终策略（不强行“修网络”，而是“让系统稳定”）

我这台机器必须使用 sing-box（TUN），所以我的方向是：

  • 保持 TUN 接管稳定
  • 尽量让 Telegram API 走 IPv4（避免 AAAA/IPv6 抢路）
  • 不做过度自动化重启（我更偏向手动控制）

3. 问题二：为什么要上 MCP？

我当时的真实痛点是：

  • 我需要稳定的“搜索/抽取”能力
  • 但又不想每次都手工拼工具、拼 API
  • 更不想把所有逻辑写死在一个脚本里

MCP 的价值是：它把外部能力变成“像本地工具一样可以调用”的接口。

3.1 TavilyProxyManager：把多个 Key 汇聚成 Master Key

我用的是 TavilyProxyManager，它做了两件很对的事：

  • 用 Master Key 对外暴露统一鉴权（`Authorization: Bearer <MASTER_KEY>`）
  • 支持一个 MCP 端点（例如：`/mcp`）方便接入

3.2 鉴权坑：401 的真正原因

一开始我遇到 401：

  • 不是服务挂了
  • 不是地址错
  • 是因为 MCP 客户端需要把 Master Key 放在正确的 Header 里

最终确认可用的方式是：

  • MCP endpoint：`https://tavily.asaqe.site/mcp`
  • Header：`Authorization: Bearer <MASTER_KEY>`

3.3 我怎么把它接到日常工作流里

我选择用 `mcporter`（MCP 客户端）把 Tavily 变成稳定工具，然后在 workspace 里封装了一个脚本：

bin/research --help

bin/research "你的问题"

这一步很关键：

工具能用不算完，变成“随手就能用的入口”才算。

4. 问题三：技能怎么挑？怎么避免越装越乱？

我一开始也很自然地想“装多点技能更强”。但很快发现：

  • skills/插件属于“本机执行代码”，不是纯 prompt
  • 安全与稳定性成本会随数量上升

所以我最后形成了一个原则：

4.1 少装装精：先跑通工作流，再扩展

我挑技能的标准：

  1. 立刻能用（不需要复杂外部依赖）
  2. 风险可控（外发/上传必须二次确认）
  3. 能沉淀成流程（不是一次性玩具）

4.2 风险边界：默认不外发、不上传敏感内容

例如：

  • `buildlog` 这类“记录并上传”的能力，默认不启用自动上传
  • `cellcog` 这类多模态外部服务，默认不上传文件，除非我明确授权

5. 最终落地：我给“超级助手”定义的 3 条工作流

5.1 研究（research）

  • Tavily（MCP）先搜（basic）
  • 不够再加深（advanced/raw）
  • 仍不足：浏览器补证据
  • 输出固定结构：TL;DR / 证据链 / 结论 / 下一步

5.2 开发（dev）

  • 先明确验收标准
  • 拆任务、标风险、可回滚
  • 小改直接做，大改用子代理
  • 最终交付：变更摘要 + 验收方式

5.3 事务（tasks）

  • 把一句话拆成：待办 / 日程 / 笔记
  • 外部写入（发消息、写日历）必须先预览再确认

6. 给读者的复现 Checklist（不含任何密钥）

Telegram 排查

  • `dig +short api.telegram.org A` / `AAAA` 看是否有 IPv6
  • 检查代理是否接管 IPv6（或禁用 AAAA）
  • 观察长运行进程与短命令的差异（gateway vs curl）

MCP 接入

  • 确认 MCP 端点路径（例如 `/mcp`）
  • 鉴权 Header 是否正确（通常是 `Authorization: Bearer ...`）
  • 先 `list --schema` 再 `call` 验证工具可用

技能治理

  • 少装装精，先跑通工作流
  • 默认不外发、不上传敏感数据
  • 所有改动可回滚（建议用 git 管理 workspace）

如果你也在折腾个人 AI 助手，我的建议只有一句：

先把一个“能长期维护的工作流”跑通，再谈更强的模型 / 更多的技能。