Posts

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 重写插件。

read more
Posts

极简 Agent 实用测试基准：别再只看能不能跑起来

很多项目把“轻量”写在 README 里，但这个词经常只代表安装命令短、核心代码少，或者演示时能在一台小机器上启动。

对一个需要 24 小时在线的个人助理来说，这些都不够。真正的问题是：它空闲时占多少资源？连续调用工具后会不会涨内存？断网、重启、模型限额和审批暂停之后还能不能回来？

因此我给“极简 Agent”定义了一套实用测试基准。它不评模型知识，也不追求实验室里的漂亮分数，只回答一个工程问题：

这个 Agent 能不能在低资源 VPS 上，长期、稳定、安全地替一个人处理真实任务？

极简不是一个内存数字

一个个人 Agent 至少包含四层：

消息入口 → Agent Runtime → 外部模型 → 工具与状态

只统计 Agent 主进程的 RSS，会漏掉浏览器、Node bridge、MCP 子进程、后台 worker 和模型代理。只统计空闲内存，也会漏掉长上下文、文件解析和工具输出带来的峰值。

所以“轻量”应该同时满足：

  • 常驻资源低；
  • 任务峰值有上限；
  • 空闲后能够回落；
  • 不产生孤儿进程；
  • 重启后能恢复必要状态；
  • 失败不会演变成无限重试；
  • 高风险动作不会绕过审批。

测试环境必须先固定

不同机器、Python/Node 版本和模型端点会显著影响结果。每次测试至少记录：

host:
  cpu: 2 vCPU
  memory: 1 GiB
  swap: 1 GiB
  os: Ubuntu 24.04
runtime:
  version: git commit / release tag
  language: Python 3.12 / Node 26 / Go 1.x
model:
  endpoint: remote OpenAI-compatible
  model: fixed model id
  context_window: fixed
features:
  channel: Lark WebSocket
  memory: SQLite or files
  mcp_servers: [luck-ops]
  browser: disabled

不要一边测 Agent A 的最小配置，一边给 Agent B 打开浏览器、语音和十个插件。功能集合必须一致，模型也必须一致。

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