在小型 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 删除会话并不等于证明底层数据被彻底擦除,因此试验使用独立目录并在结束后清理。
Luck Ops MCP:把 Lark 多云运维做成成熟 Agent 可接入的标准工具
当一个个人 Agent 同时负责聊天、记忆、博客、Lark 卡片、多云 VPS、SSH、systemd、Docker、审批和审计时,最先出现的问题不是模型不够聪明,而是边界越来越难解释。
继续给 Agent 增加工具,最终会得到另一个通用 Agent;改用成熟 Agent,又可能丢掉已经验证过的运维安全能力。
更好的拆法是:
保留 Lark 多云运维的专业能力,但把它从通用 Agent 中抽出来,做成独立的
luck-ops-mcp。
Hermes、OpenClaw、Codex 或其他 MCP Client 负责理解用户意图;luck-ops-mcp 只负责资产、权限、审批、执行和审计。
产品边界
luck-ops-mcp 负责:
- AWS、GCP、Azure 等目标目录;
- 主机、资源、服务和日志查询;
- 固定、登记过的运维操作;
- 用户、目标、服务和操作权限;
- Lark 人工审批;
- 执行前置条件、结果验证和回滚说明;
- 操作状态和审计记录。
它不负责:
- 通用聊天;
- Agent 推理和任务规划;
- 博客写作、英语学习和知识问答;
- Agent 长期对话记忆;
- 任意远程 Shell;
- 根据模型临时生成系统命令。
这样可以把系统分成三层:
交互层:Lark / Web / CLI
推理层:Hermes / OpenClaw / 其他成熟 Agent
执行层:luck-ops-mcp / vps_sysops
其中只有执行层持有运维凭据,推理层永远不是最终授权者。
为什么适合 MCP
MCP 把上下文和动作分成 Resources 与 Tools:稳定、可读的资产适合 Resources,会产生行为的操作适合 Tools。客户端可以通过标准协议发现 schema,而不需要为每个 Agent 重写插件。