为什么需要一个群

我平时同时用好几个 Muse 实例，各有分工：一个负责运维执行，一个负责链上监控，还有一个机动的。很快就撞上一堵墙：Muse 的会话是互相隔离的，AI 之间不能直接对话。想让它们协作、同步状态，只能靠我人肉传话——我说一遍，它做一步，效率全耗在转述上。

于是搭了个很像微信群的东西：一个跑在 VPS 上的轻量消息网关，几个 AI 各自轮询收发，我也在群里，拍板和 @ 人都在群里完成。

架构：一个网关 + 一套约定

服务端就是 VPS 上的一个 Python 小服务（几百行），只做三件事：

• POST /api/send：发消息，带 from（谁发的）和 text
• GET /api/msgs?since=<时间戳>：按时间拉取新消息，token 鉴权
• 静态托管一个极简的聊天 Web 页，手机也能看

客户端更简单：每个 AI 每 20 秒轮询一次，拉到 @ 自己的消息就回，没事就静默。没有 WebSocket，没有长连接，糙但稳。

身份是地基：在服务端卡死，不靠自觉

群聊里最危险的不是技术，是身份冒用——如果任何人都能以"我"的名义说话，群主的指令就一文不值。

做法：

• 我在群里的身份叫 ki，有一套独立密码。服务端收到我的密码发来的消息，强制把 from 写成 ki。
• 其他 token 想冒用 ki（包括大小写变体），直接 403 拒绝。
• 普通成员用共享 token，只能以自己的名字说话。

这条规则写在服务端代码里，不靠任何人的自觉。群聊的地基是身份，身份必须由网关强制执行。

轮询与水位线：吃过的亏

轮询最容易翻车的地方是水位线（上次拉到哪条消息的时间戳）。我们真翻过一次车：

有一次水位被写成了纳秒时间戳，而服务端的消息时间戳是秒级的。从此 since=纳秒 永远拉不到新消息——AI 们集体"失明"，但程序一切正常，静默无报错。

根治办法：水位文件只由拉取脚本自己管理，worker 只读输出、严禁以任何方式手写水位。规则很简单，违反一次就长一次记性。

群规：@ 谁就是找谁

技术搭好后，真正的效率来自一条群规，也是群主定的：

ki @ 了哪个 AI，就是单独找那个 AI 说话，没被 @ 的不插话；被 @ 才回；其他 AI 点名你时可以接话。

没有这条规则，三个 AI 会对每条消息都抢答，群直接变菜市场。有了这条规则，群里安静得像个值班室：监控告警自动同步进来，各 AI 按需响应，人只在需要拍板时被 @。

实战：一次真实的跨 AI 排障

这套东西上周经历了一次实战检验：给其中一个跑在受限沙盒里的 Muse 实例开通代理。

她的沙盒出口对 443 做 TLS 中间人劫持，VLESS+Reality 连握手都完不成；换 Hysteria2、换端口，全部被特征拦截。整个排查过程就在群里进行：

1. 她在群里贴报错和 curl -skv 的证书输出
2. 负责运维的 AI 在群里查服务端状态、核对参数（服务端的 uuid、私钥全部脱敏后传云盘对照）
3. 我只在两个节点拍了板：是否给她 Hysteria2 的密码、是否在 VPS 上加一条伪装线路
4. 最后加了一条"正常域名 + 真实证书 + nginx 反代 WS"的伪装通道，一次调通

全程我没转述过一句话。需求、日志、验证都在群里，过程在这篇有完整记录：为 Muse 开通代理通道。

成本与取舍

• 成本：一台 VPS（本就有的）+ 几百行 Python + 每 20 秒一次的轮询。token 消耗是群主精打细算过的，够用。
• 取舍：轮询有延迟（最坏 20 秒），不适合实时聊天；但对运维协作、告警同步这个场景，完全够用。
• 边界：网关只传文本和指令，不碰任何账号密码。真钱、支付、绑卡这些事，永远是人自己在自己设备上做，AI 只传话、不经手。

顺手推广：Muse 邀请码

如果你看完想试试 Muse（Meta 的个人 AI 助手），可以用我的邀请码：

邀请码：V7X799

• 注册加入：muse.ai/join
• 兑换方式：App 内「设置 → Redeem token」输入邀请码（新用户注册 48 小时内有效）
• 利益相关声明：通过邀请码注册，双方都可能获得 token 奖励，具体以邀请页显示为准。