过去一段时间，我把「博客、状态页、网盘、订阅面板、Telegram 运维机器人、轻量 AI Agent、本地 AI 工具网关」逐步接到同一套个人云基建上。本地有一个工作目录用来放脚本、补丁与配置草稿，线上则以一台小规格 控制中枢 VPS 为默认入口。

这组文章会按模块拆开写技术路线，只谈架构与取舍，不写真实 IP、密钥、账号凭据和内部路径。

目标

  1. 一个控制中枢：面板、机器人、定时任务、状态汇总尽量收敛到一台机器。
  2. 443 既要节点又要网页：代理入站与 HTTPS 站点共存，而不是互相抢死端口。
  3. 可观测但不重：小内存机器上不跑沉重监控全家桶，优先 SSH/端口探测 + 轻量 JSON 看板。
  4. 订阅可自动切换：多后端时用 DNS 域名当「虚拟入口」，客户端少改配置。
  5. 大文件与控制面分离：网盘传文件尽量少走隧道；API/状态页可以走 Tunnel。

逻辑分层（概念图）

[ 你的设备 ]
    │
    ├─ 浏览器 ──► 状态页 / 博客 / 面板 / 网盘
    ├─ 代理客户端 ──► 各区域节点（含自动切换域名）
    └─ 本地 AI 工具 ──► 自建 OpenAI 兼容网关 ──► 上游模型

[ 控制中枢 VPS ]
    ├─ 反代与 SNI 分流（网页 vs 代理入站）
    ├─ 订阅面板 + 自动切换任务
    ├─ 状态采集与 JSON 发布
    ├─ Telegram Bot + 轻量 AI Agent
    └─ 可选：Cloudflare Tunnel（适合控制面，不适合大文件）

[ 边缘与对象存储 ]
    ├─ Cloudflare DNS / Pages /（可选）R2
    └─ 博客静态站、文件站等

模块地图

模块解决什么问题对应篇章
总览与原则分层、取舍、安全边界本篇
443 / SNI / Reality网页与代理同端口共存第二篇
状态看板多机 CPU/内存/磁盘/在线第三篇
订阅与自动切换多后端 DNS 调度第四篇
网盘 OpenList隧道 vs 直连、大文件路径第五篇
Bot + AI Agent运维入口与多轮对话第六篇
AI API 网关本地工具接自建兼容接口第七篇

设计原则（实践中验证过的）

1. 控制面与数据面分开

  • 控制面：拉订阅、看状态、改开关、调模型列表 → 可接受 Tunnel / 反代。
  • 数据面：大文件上传下载、代理流量本身 → 应尽量直连节点或对象存储，避免「浏览器 → CDN 边缘 → 隧道 → 小机器 → 磁盘」整条长链。

2. 小内存优先「组合现成组件」

控制中枢若是 ~1GB 内存档，适合：

  • Caddy / HAProxy 做入口
  • 轻量 Python 定时任务
  • 本机 OpenList / 面板类服务

不适合再堆一套重型监控 + 重型 AI 编排平台。

3. 配置「可重建」比「神秘脚本」重要

本地 vps 目录里会有大量 patch_*.py、tmp_*.py——这是迭代痕迹。长期应收敛为：

  • 一份服务清单（systemd unit）
  • 几份入口配置（Caddy / HAProxy / Tunnel）
  • 明确的数据目录与备份点

博客系列写的是收敛后的逻辑，而不是每一个临时补丁文件名。

4. 脱敏发布

对外文档只保留：

  • 组件名称与职责
  • 流量走向
  • 失败案例与改法

不公开：SSH 私钥路径、API Token、租户/订阅 ID、真实主机地址、面板管理员口令。

本地目录 vs 线上真相

位置角色
本机工作目录草稿、补丁、实验脚本、页面模板
控制中枢真正跑服务的地方（systemd / 容器）
GitHub + Pages博客与部分静态前端
DNS自动切换与对外域名

排查问题时，优先相信 线上正在运行的 unit 与配置，本地脚本只是变更来源之一。

下一篇预告

第二篇会聚焦一个具体问题：公网 443 已经被代理入站占用时，如何还能安全地提供 HTTPS 面板与站点？ 核心是 TCP SNI 分流，而不是「再开一个乱七八糟的高位端口给用户记」。