Posts

在小型 GCP VPS 上尝试用 OpenCode 接管个人助理

我希望把日常对话、QPC 知识库与日历逐步放进一个个人助理，同时控制小型 VPS 的资源占用。已有 Hermes 网关正在使用另一只 Lark 机器人。这个实验的目标是暂停 Hermes，在同一台共享小机上尝试运行 OpenCode，并使用 personal-assistant 的机器人验证接管链路。

**同日补充：**第一次窗口结束前的消息被中断；经再次授权，重开受保护的短时窗口后，真实 Lark 两轮私聊均收到回复，第二轮正确使用了前文。模型任务期间的内存峰值和压力依然偏高，尚不能据此判断适合在这台小机上长期常驻。

这次实验的边界很窄：测试短时对话、资源和回退；QPC 与日历不是这次已经实现的能力。两只机器人独立，暂停 Hermes 会暂时影响原机器人，不会自动把它的会话和权限迁移到新机器人。

为什么不能只比较一个 RSS

在决定切换前，观察到 Hermes 主进程的一次 RSS 约 341 MiB，另有进程数据进入 swap。本机 WSL 中 OpenCode 空闲服务的主进程 RSS 大约 224–262 MiB。但 Hermes 当时正在承担实际网关工作，OpenCode 的本机测试没有接真实 Lark 或模型。不同机器、不同负载和不同统计口径不能直接得出完整替代方案的节省量。

共享实例约有 952 MiB 可见内存，Hermes 运行时多次采样的可用内存只有一百多 MiB，还有明显 swap 使用。相比直接叠加一个服务，先暂停旧网关、在相同机器上测量完整链路，更接近实际问题。

把切换做成可回退试验

方案是由已有的轻量 Lark 入口负责本人身份检查、消息去重与回复状态，OpenCode 仅在本机回环地址提供模型对话接口。服务使用非特权用户、单独工作目录、内存和 CPU 限额；OpenCode 工具权限默认拒绝，试验不开放文件修改、Shell 或其他外部动作。模型凭证和机器人凭证分开提供，不放入仓库或文章。

切换前设置了十分钟自动回退，并持续观察内存余量、内存压力和关键服务状态。试验失败或达到时限时，停止试验服务，恢复 Hermes gateway 和 A2A bridge。两个服务独立恢复，是因为 bridge 没有声明会自动跟随 gateway 的依赖关系。

对话适配器每轮创建独立 OpenCode 会话，只加入已确认送达的有限历史；调用超时不自动重试。模型回答和 Lark 成功投递分开记录。OpenCode 自身会在状态目录写入会话数据，尝试调用 API 删除会话并不等于证明底层数据被彻底擦除，因此试验使用独立目录并在结束后清理。

read more
Posts

VPS 安全加固：从 0 到三层防御实战记录

一台裸奔的海外 VPS，跑着 new-api、x-ui、Hermes Agent 三个服务，端口审计发现 3000 + 50404 公网监听——我是怎么一步步把它变成铁桶的。

背景：一台裸奔的 VPS

上个月整理 GCP 免费赠金 VPS，发现上面跑着：

  • new-api（端口 3000）— AI API 代理网关
  • x-ui（端口 50404）— 代理面板
  • Hermes Agent（内部端口）— 个人 AI 助理

三个服务全部 0.0.0.0 绑定，直接暴露在公网。用 nmap 扫了一下自己的 IP：

$ nmap -Pn <my-ip>
PORT      STATE SERVICE
3000/tcp  open  ppp
50404/tcp open  unknown

更要命的是，new-api 后台后来审计发现了 7 个陌生 bot 账号，说明已经被扫到了。ROOT_PASSWORD 还是默认的弱密码。

这篇文章记录我从"裸奔"到"三层防御"的完整过程，每一步都是真实踩坑后的总结。

第一层：GCP Firewall — 在流量进主机前挡住

核心思路：在 GCP 层面直接拒绝，流量根本不到你的主机。

GCP Firewall 支持按 instance tag 匹配规则。我先创建了一个 tag secure-server，然后写规则：

# 拒绝所有入站，只允许特定端口
gcloud compute firewall-rules create deny-all-ingress \
  --direction=INGRESS \
  --priority=65534 \
  --network=default \
  --action=DENY \
  --rules=all \
  --target-tags=secure-server \
  --source-ranges=0.0.0.0/0

踩坑：规则创建后测试 nc -zv <ip> 3000，发现还是通的。排查半小时发现——instance 没打 tag。规则存在但没 target，等于没配。

read more
Posts

Hermes-lite 裁剪指南：在 1GB VPS 上跑轻量 AI Agent

为什么要裁剪

完整版 Hermes Agent（Nous Research）功能丰富：多平台网关、浏览器自动化、语音 TTS/STT、多 Agent 协作、Kanban 看板等。但这些功能对资源要求不低——在我的测试里，完整配置更适合至少 2GB 内存的机器。

我有一台 GCP e2-micro（2 vCPU / 954MB RAM），想用它跑一个 24/7 在线的 AI Agent 接入飞书。完整版装不下，于是有了这个裁剪实践。

三阶段渐进式裁剪

裁剪不是一步完成的，而是三阶段递进：

第一阶段：本地 Codex 完成初期核心裁剪

在本地电脑上，利用 Codex（OpenAI） 作为辅助分析工具，对完整版 Hermes 进行全面"解剖"：

  • 逐一扫描 ~/.hermes/ 目录结构，识别每个模块的职责
  • 分析 67 个技能的依赖关系，标记哪些是核心链路的、哪些是边缘功能
  • 梳理 config.yaml 中每个配置项的实际作用，搞清楚"关掉会怎样"
  • 输出一份裁剪清单：哪些 toolset 可以禁、哪些 skill 可以删、哪些配置可以收紧

这一阶段的核心价值：把"能不能关"这个判断做对。Codex 帮助理解了代码间的依赖关系，避免直接关某个功能导致连锁崩溃。

第二阶段：大 VPS 上跑完整版 + 压测验证

在一台大内存 VPS 上安装完整版 Hermes，作为"对照基准"：

  • 记录完整版的实际内存占用（idle / 高负载两种状态）
  • 逐个关闭非核心功能，观察内存变化和稳定性
  • 跑压测：模拟长时间运行、多轮对话、工具调用密集场景
  • 确认裁剪后系统在资源充足环境下依然稳定

这一阶段的目的：建立性能基线 + 验证裁剪组合的安全性。在大 VPS 上翻车无所谓，在小 VPS 上翻车就是服务宕机。

read more