手机上最顺手的运维入口，往往是 Telegram Bot：查节点、切后端、看流量条、收告警。AI 能力可以叠在同一入口上，但不必为此再部署一套重型编排平台。

Bot 的职责边界

适合交给 Bot 的：

  • 只读状态：/vps、流量摘要、健康检查结果；
  • 受控写操作：切换自动后端、刷新状态、选模型；
  • 告警投递：监控失败达到阈值后推送。

不适合裸奔给 Bot 的：

  • 任意 Shell 执行（必须鉴权与命令白名单）；
  • 高危密钥导出；
  • 无审计的批量删除。

状态数据从哪来

下线重型面板之后，Bot 与网页应共享 同一份状态 JSON（见第三篇）。避免：

  • 网页读 A 源、机器人读 B 源；
  • 文案里还留着已废弃面板链接。

轻量多轮 AI Agent

在小内存中枢上，可用 仅标准库的 HTTP Agent：

Telegram Bot
    │ POST /v1/chat { user_id, query }
    ▼
本机 Agent (:内网端口)
    │ 滑动窗口（例如最近 N 条消息）
    │ 系统提示 + 调用上游 Chat API
    ▼
回复 Bot → 用户

关键参数：

项建议
窗口大小按内存与模型上下文折中（如约 20 条消息）
会话 TTL空闲超时清理，防无限膨胀
监听地址仅 127.0.0.1
进程管理systemd，避免 nohup 与 unit 双开导致「双重回复」

告警链路

示例：某备用机存活探测

定时探测 TCP/HTTP
  → 连续失败 ≥ 阈值
  → Telegram 通知（可叠加邮件）
  → 状态文件记录，避免刷屏

阈值过大告警迟钝，过小则抖动骚扰；需要按线路质量调。

双进程问题

Bot 若同时被 systemd 与 手工 nohup 拉起，会出现同一条消息回两次。部署检查清单应包含：systemctl status 与进程列表是否只有一份。

小结

Bot 是运维 UI，Agent 是可选的对话层；两者都要 本机绑定 + 单一数据源 + 单一进程。下一篇（终章）写本地 AI 编程工具如何接到自建 OpenAI 兼容网关。

系列导航：上一篇 · 网盘 · 下一篇 · AI 网关