一条命令让 AI Agent 接管你的 VPS：用 daimon-mcp 告别 SSH 手动运维

买 VPS 这件事，现在越来越便宜，也越来越普及。但「买完之后怎么配置」这道坎，一直没什么变化：大多数人还是得自己 SSH 上去，一条条敲命令，或者去网上找现成的自动化脚本，再手动改改参数。

配置麻烦只是第一层。更头疼的是出了问题排查起来也麻烦——你记不清当时敲了哪几条命令、改了哪个配置文件，翻 .bash_history 和满屏的日志，比配环境还费劲。

这篇文章介绍一种新方案：买到新 VPS 后，先一条命令装好 processd 服务，然后通过 MCP 接入 Claude Code、Codex 等 Agent，让 AI 在本地电脑上直接操作这台远程 VPS。

传统做法为什么痛苦

先回顾一下现在主流的流程：

手动 SSH 配置：登录、改 SSH 端口、装 Docker、配防火墙、拉代码、起服务……每一步都要自己敲，容易漏、容易错。
找自动化脚本：一键脚本虽然快，但往往为了「通用」塞进一大堆你根本用不上的东西，出了岔子你都不知道脚本到底干了什么。

这两种方式的共同点是：配置过程和排查过程，都压在你自己头上。 而 AI Agent 恰恰擅长干「照着文档执行一串命令 + 报错时读日志排查」这种活，缺的只是一个能稳定、安全地把命令送进 VPS 的通道。

新方案：MCP 远程运维

processd（对外也叫 daimon-mcp）做了一件很直接的事：它在你的 VPS 上跑一个 MCP server，暴露的工具和 Claude Code 内置的一模一样——Bash、Read、Write、Edit、Glob、Grep、WebFetch，外加一个交互式 PTY。

于是 Claude Code、Codex、Cursor 这些 Agent，把 MCP 地址一配，就能像操作本地文件一样，去操作那台远程 VPS 的终端和文件系统。

最关键的体验差别在于：你不需要在远程 VPS 上再装一个 Codex。 你的 Agent 跑在本地电脑上，VPS 上只留一个轻量的 processd-mcp 服务，充当 Agent 的「手」伸进去干活。

配置时：你直接跟本地 Agent 说「帮我把这台 VPS 配好」，它自己 SSH 都不用，通过 MCP 一条条执行、随时读输出。
排查时：Agent 看得到完整的命令上下文和报错，能顺着日志往下查，而不是你从头再敲一遍。

一条命令安装 processd 服务

拿到新 VPS（Debian / Ubuntu，systemd）后，SSH 上去一次，执行这一条命令：

curl -fsSL https://github.com/daimon-hq/release/releases/latest/download/install-processd-kernel.sh | sudo bash -s -- install

它会：

写入二进制 /usr/local/bin/processd-mcp（静态 musl，amd64 / arm64 都有）；
生成 systemd 单元 processd-mcp.service；
创建配置文件 /etc/processd-mcp/processd-mcp.env，默认绑定 127.0.0.1:8080，并生成一个随机的 PROCESSD_TOKEN。

装完验证一下：

sudo systemctl status processd-mcp --no-pager
curl -i http://127.0.0.1:8080/health        # 返回 204
sudo awk -F= '/^PROCESSD_TOKEN=/{print $2}' /etc/processd-mcp/processd-mcp.env

最后一条命令输出的是访问令牌，后面接入 Agent 时会用到。

把监听地址改成你的电脑能连上的地址

这里有个容易漏掉的坑：安装脚本默认把 MCP_HOST 设为 127.0.0.1，也就是只监听 VPS 本机的回环地址。你本地电脑上的 Agent 是连不上远程 VPS 的 127.0.0.1 的。所以还得把监听地址改成你的电脑能访问到的地址（VPS 的局域网 IP，或 Tailscale IP），然后重启：

sudo sed -i 's/^MCP_HOST=.*/MCP_HOST=<你的电脑能连上的地址>/' /etc/processd-mcp/processd-mcp.env
sudo systemctl restart processd-mcp

把 <你的电脑能连上的地址> 换成 VPS 的局域网 IP 或 Tailscale IP。生产环境强烈建议用 Tailscale（见文末「安全提醒」），不要用 0.0.0.0 直接把端口暴露到公网。

接入 Claude Code / Codex

拿到令牌后，在本地的 Agent 配置里加上这段（Claude Code 是 .mcp.json，Codex 是它的 MCP 设置）：

{
  "mcpServers": {
    "daimon": {
      "type": "http",
      "url": "http://<VPS 地址>:8080/mcp",
      "headers": {
        "X-Access-Token": "<PROCESSD_TOKEN>"
      }
    }
  }
}

把 <VPS 地址> 换成你 VPS 的 IP（或 Tailscale IP，见下文），令牌填刚才查到的值。改完重载配置，Agent 的工具列表里就会出现 Bash、Read、Write、Edit、Glob、Grep 这一整套。

接下来就是自然语言干活了，比如：

「帮我把这台机器上装好 Docker，并启动一个 nginx 容器监听 80 端口。」

Agent 会通过 MCP 的 Bash 去执行，Read/Grep 去查日志和配置，出错了继续往下排查，直到搞定。

在本地用 Codex App GUI 操作远程 VPS

Codex 除了 CLI，还有桌面 GUI。你可以在本地电脑上启动 Codex App GUI，把 MCP 配好之后，直接在图形界面里下达指令，让它去操作远程 VPS——远程 VPS 上完全不用装 Codex，只留着那个轻量的 processd-mcp 服务即可。

本地 GUI 负责「思考 + 交互」，远程 processd-mcp 负责「执行」，两边通过 MCP 对接。对 VPS 来说，它只看到来自 processd-mcp 的本地命令，干净、可控。

高级策略配置：限制 MCP 能访问哪些文件夹

processd-mcp 不只是个「传声筒」，它还带一个内核级沙箱，可以通过策略文件精确限制 Agent 能读、能写哪些路径，以及能不能联网。这在把 Agent 交给一台生产 VPS 时特别重要——你总不希望它一个手滑，把 /etc 或 ~/.ssh 给动了。

开启策略

先下载一份示例策略，放到 /etc/processd-mcp/policy.yaml：

sudo curl -fsSL https://github.com/daimon-hq/release/releases/latest/download/sandbox-policy.example.yaml \
  -o /etc/processd-mcp/policy.yaml
sudo chmod 644 /etc/processd-mcp/policy.yaml
sudo $EDITOR /etc/processd-mcp/policy.yaml

然后在环境文件里指定它，并重启服务：

echo 'MCP_SANDBOX_POLICY_FILE=/etc/processd-mcp/policy.yaml' | \
  sudo tee -a /etc/processd-mcp/processd-mcp.env

sudo systemctl restart processd-mcp

策略文件长什么样

version: 2

filesystem_policy:
  include_workdir: true          # 把进程 cwd 自动加入可读写

  read_only:
    - /var/log                   # 只能读，不能改

  read_write:
    - /workspace                 # 替换成你真正的项目目录

network:
  mode: disabled                 # disabled | localhost_only | enabled

linux:
  landlock:
    compatibility: hard_requirement   # hard_requirement | best_effort
  process:
    run_as_user: user            # 必须存在，且不能是 root
    run_as_group: user

几个关键点：

文件系统：read_only 是只读、read_write 是可读写。Agent 碰不到列表之外的任何路径——比如你不想让它碰的 SSH 私钥，别写进去就行。
网络：disabled 直接断网（最严格，推荐默认）、localhost_only 只放行回环、enabled 完全放行。
身份：run_as_user / run_as_group 会在沙箱内降权到非 root 账户，配合 hard_requirement，Landlock 挂不上就拒绝启动，宁可起不来也不带病运行。

改完策略要重启服务才生效（策略只在启动时加载一次）。之后用 GetRuntimeContext 就能看到当前生效的策略。

FAQ

为什么不直接让本地 Codex SSH 连上去？

这是最常见的疑问，其实直接 SSH 有两个硬伤：

1. 每条命令都要带一段很长的 SSH 前缀，二次拼接容易出错。

直接 SSH 的用法，Agent 生成的是类似这样的东西：

ssh -i ~/.ssh/id_ed25519 -o StrictHostKeyChecking=no -p 22 user@1.2.3.4 "ls -la /var/www"

它真正想执行的 ls -la /var/www，被包在一长串 SSH 参数里。Agent 每生成一条命令，都得先拼前缀、再拼真实命令，两层拼接之下，引号转义、变量展开、换行处理，任何一处错位命令就废了。命令越复杂，出错概率越高。

而走 MCP，Agent 只生成 ls -la /var/www 这一条干净的命令，由 processd-mcp 在远端执行。没有前缀、没有转义地狱。

2. 每次 SSH 都相当于一个全新窗口，没有状态保存。

SSH 是「无状态」的：你 cd /workspace 进去了，下一条 SSH 又是一个全新的 shell，$PWD 又回到 home，刚才 export 的环境变量、激活的虚拟环境、后台起的进程，全都丢了。Agent 要么反复 cd，要么把所有状态塞进一条超长命令里。

processd-mcp 的 Bash 跑在同一个 shell 会话里，工作目录、环境变量、后台任务的状态都是持续保持的，Agent 可以自然地「先 cd、再 git pull、再 docker compose up」，一步步来，就像你本人在那个终端里一样。

这个方案和「远程 VPS 上装 Codex」比呢？

远程装 Codex 意味着要把一套完整的 Agent 运行时（模型、工具、依赖）塞进 VPS，资源占用、配置复杂度、出问题后的排查面都更大。而 processd-mcp 在 VPS 上只是一个静态单文件服务，Agent 留在你本地跑，VPS 干净得多，也更好维护。

安全提醒：流量不加密，生产请用 Tailscale

一个必须说清楚的限制：processd-mcp 的链路是明文 HTTP，没有 TLS。 那个 X-Access-Token 只是共享密钥，用来鉴权，不提供加密。所以千万不要把 MCP_HOST 设成 0.0.0.0 再把 8080 端口直接暴露到公网。

正确的做法是用 Tailscale 做内网穿透，把 VPS 和你的本地电脑拉进同一个 tailnet：

TS_IP=$(tailscale ip -4)
sudo sed -i "s/^MCP_HOST=.*/MCP_HOST=${TS_IP}/" /etc/processd-mcp/processd-mcp.env
sudo systemctl restart processd-mcp

然后把 Agent 配置里的 url 换成这个 Tailscale IP 即可。数据走在 Tailscale 的加密隧道里，端口也不用对公网开放。也可以保持回环绑定，用 tailscale serve 转发。总之：生产环境走 Tailscale，别裸奔。

总结

传统 VPS 运维：SSH 手动配置或一键脚本，配置麻烦、排查更麻烦。
新方案：一条命令装 processd-mcp，用 MCP 把远程终端暴露给 Claude Code / Codex 等 Agent。
体验升级：远程 VPS 不用装 Codex，本地跑 Agent（甚至 GUI）直接操作远程机器。
可控性：内核级策略文件能限制 Agent 能访问、修改哪些文件夹，以及能否联网。
安全底线：明文 HTTP，生产务必走 Tailscale。

更多细节（客户端接入、集群模式、SDK、策略完整字段）可以看官方文档：https://daimon-hq.github.io/ 。