CN
EN
AI代理（如Claude Code）与传统脚本最大的区别在于：它拥有极高的权限。它可以直接执行Shell命令、修改文件系统、甚至发起网络请求。如果你在一台同时部署了数据库、后台服务或多人共享的VPS上直接以`root`身份运行Claude Code，相当于在家里放了一个随时可能失控的机器人。
一旦Agent因为幻觉执行了`rm-rf/`，或者因为Prompt注入攻击读取了服务器上的敏感密钥（如`~/.ssh/id_rsa`、`.env`文件），后果是灾难性的。
要在共享VPS上安全运行AI代理，并不需要极其复杂的架构，但必须守住以下几条最低隔离配置的底线。
配置一：用户隔离——永远不要用root跑AI
这是最核心、最便宜的安全防线。
1.创建专属的系统用户
为AI代理创建一个专门的非特权用户，它只能访问自己的家目录，没有`sudo`权限。
sudo adduser claude-agent禁用其shell登录（如果不需要手动登录的话）
sudo usermod-s/usr/sbin/nologin claude-agent2.限制目录权限
将你的代码项目克隆到`/home/claude-agent/workspace`，并将所有者改为该用户。绝对不要把`/etc`、`/var`或其他用户的目录暴露给它。
sudo chown-R claude-agent:claude-agent/home/claude-agent/workspace3.以该用户身份运行
如果你用tmux，在切换用户后启动；如果你用systemd（如第一篇文章所述），一定要在服务文件中写明`User=claude-agent`。
配置二：容器隔离——最彻底的沙盒
如果有多个项目或者多人共享，最简单的“防污染”方案是使用Docker容器。
1.使用官方或定制的镜像
不要直接在宿主机上跑。构建一个包含Claude Code运行环境的Dockerfile：
```dockerfile
FROM node:18-alpine
WORKDIR/app
RUN npm install-g@anthropic-ai/claude-code创建一个非root用户
RUN addgroup-S agent&&adduser-S agent-G agent
USER agent构建并运行：
docker build-t claude-sandbox.将本地代码目录挂载进容器
docker run-it--rm-v/home/claude-agent/workspace:/app-w/app claude-sandbox这种方式将Agent的文件修改和网络活动严格限制在容器内部，它无法触及宿主机的系统文件。
配置三：资源限制——防止Agent拖垮整台服务器
如前文所述，Claude Code可能存在内存泄露或异常占用。在共享环境里，如果它把内存吃光，会导致其他业务被OOM Killer杀掉。
1.使用systemd的cgroups限制
在你的`claude.service`文件中加入：
```ini
[Service]限制最大内存为4GB
MemoryMax=4G限制CPU使用率为200%(2个核)
CPUQuota=200%一旦Claude Code的内存开销超过这个阈值，系统会自动终止该进程，保护宿主机。
2.在Docker中限制
启动容器时加上限制参数：
docker run-it--rm--memory="4g"--cpus="2.0"-v...claude-sandbox配置四：网络与密钥隔离
1.保护宿主机的私钥
如果Agent运行的用户是`claude-agent`，它默认无法读取`root`或其他用户的`.ssh`目录。如果在容器中运行，宿主机上的私钥也不会被映射进去。
2.最小化API权限
在Anthropic控制台，尽量为不同的Agent生成不同的API Key，并设置较低的消费额度上限，避免代码失控导致API账单爆炸。
为什么独立、纯净的VPS是最佳起点？
无论你在系统内部做了多完善的隔离，最底层的基础设施隔离永远是第一道防线。将AI代理与核心业务部署在同一台机器上，本身就是一种风险。
如果你想为AI代理留出一个隔离的“自留地”，Jtti香港轻量云1核1G、200M独享带宽非常适合作为专属的Agent沙盒——它资源独立、不与其他用户争抢带宽，且续费同价，长期挂机的成本极其透明。对于企业级多Agent运行，Jtti的2核4G或4核8G配置支持你进一步在容器层面做多维度的资源切分。
隔离的核心逻辑是：假设Agent一定会犯错，并通过层层降权来限制它犯错后的破坏半径。从操作系统的用户隔离开始，到容器的沙盒，再到Jtti VPS的底层虚拟化隔离，每一层都在为你的数据安全提供保障。
