AI 托管服务器：将 Claude Code、ChatGPT 等 AI 智能体安全接入自己的服务器

直到不久之前，“管理服务器”还意味着：打开 SSH、阅读日志、敲命令、翻文档，然后再敲命令。自从 Claude Code、OpenAI Codex 和 Gemini CLI 作为命令行工具推出以来，AI 智能体就可以接手这些工作：它读取错误信息、查找原因、修改配置、重启服务，并说明自己做了什么。这种方式如今被称为 AI 托管服务器（AI Managed Server）。本文介绍其背后的原理、哪些架构经过了实践检验、哪些安全规则不可妥协，以及为什么每一台 KernelHost KVM 根服务器无需任何调整即可胜任。

什么是 AI 托管服务器（以及它不是什么）

AI 托管服务器既不是新产品，也不是特殊硬件。它是一台普通的根服务器，AI 智能体可以在上面以专用用户账户执行命令。人用日常语言描述任务（“为什么 nginx 从今天早上开始一直返回 502？”），智能体检查系统、提出修改建议、在获得批准后执行修改，并记录结果。

与只能让您照抄命令的聊天机器人相比，区别在于：智能体拥有 Shell。它可以自己调用 journalctl、读取配置文件、试运行一条命令、解读输出，并据此推导出下一步。原本来回复制粘贴要折腾半小时的事，现在两分钟就能搞定。

AI 托管服务器不是什么？它不是一台会自己管理自己的服务器。智能体按指令行事，在会话的上下文中工作，并且需要经过批准。如果放手让它们随意操作，您得到的不是一位自主的管理员，而是一件速度很快却没有刹车的工具。下文的规则就是为了确保刹车始终有效。

AI 托管服务器与传统托管服务器对比

在传统托管服务器模式下，由主机商或运维服务商负责维护，并按月收取固定费用。在 AI 托管服务器模式下，控制权留在您手中，繁琐的手工操作则由智能体代劳。

工具：Claude Code、ChatGPT Codex、Gemini CLI 和 MCP

三大服务商如今都推出了各自的命令行工具，可以在 Linux 服务器上运行、读写文件并执行 Shell 命令。它们在细节上有所差异，但基本原理完全一致。

三者都基于 Node.js 运行，不需要 GPU，真正的推理工作都交给服务商的模型完成。服务器上只保留工具本身，大小只有几兆字节。因此，即使是最小的 KVM 根服务器也完全够用。

MCP 还能带来什么

此外还有 Model Context Protocol（MCP）：这是一个开放接口，智能体可以通过它获得额外的工具，例如访问数据库、监控系统、工单系统或 Docker 环境，而无需为此使用 Shell。入门阶段并不需要 MCP。当您想有针对性地限制访问权限时，它才真正派上用场：一个只允许只读数据库查询的 MCP 服务器，比一个在 Shell 里掌握数据库密码的智能体更安全。

哪款工具适合您？

就服务器管理而言，这三款工具不分高下：它们都会读取规则文件，在执行会改动系统的命令前先征询确认，也都可以在无人值守的情况下启动。因此，选择哪一款通常取决于您已有的账户。如果您使用 ChatGPT，就从 Codex CLI 开始；如果您有 Claude 订阅，就从 Claude Code 开始；如果您在 Google 生态中工作，就从 Gemini CLI 开始。同时运行多款工具也没有问题，因为每款工具读取的都是各自的规则文件。

将智能体接入服务器的三种方式

1. 智能体在您的电脑上运行，通过 SSH 工作

Claude Code 或 Codex 在笔记本电脑上运行，每条服务器命令都通过 ssh 发出。优点：服务器上无需安装任何东西，智能体可以同时照管多台服务器，AI 服务商的登录信息也留在您自己的设备上。缺点：智能体只能透过单条命令这个“钥匙孔”观察服务器，长时间的会话还要依赖您的网络连接。对于偶尔的维护和多台小型服务器，这是最简单的方案。我们自己也是这样工作的，使用专用密钥、主机别名和固定的部署流程，详见实践报告 将 AI 接入服务器。

2. 智能体直接在服务器上运行

工具安装在服务器上，通过 SSH 启动。这样，智能体可以直接访问文件、实时跟踪日志，即使您没有保持连接，也能完成较长的任务，例如在每天早上汇总日志的 cron 任务中。在实践中，人们谈到 AI 托管服务器时，指的大多就是这种方案。具体步骤见 在服务器上安装 Claude Code 和 Codex 的指南。

3. 智能体在堡垒机虚拟机上运行

如果要管理多套生产系统，值得单独准备一台小型服务器，让智能体常驻其上，并从这里通过 SSH 访问各个目标系统。目标系统只获得一个权限受限的 SSH 密钥，堡垒机则保存 AI 服务商的登录信息、会话记录和规则。熟悉数据中心运维的人会认出这个原理：这就是跳板机，只不过坐在它前面的是智能体，而不是人。一台 2 vCPU 的 KVM 根服务器就足够了。

三种方式对比

不可妥协的安全规则

一个拥有 Shell 访问权限的智能体，就像一位拿到 root 密码却没有经过入职培训的新同事一样危险。以下规则来自每天都在遭受攻击的服务器的运维实践，无论使用哪家服务商都同样适用：

• 专用用户，绝不用 root。智能体拥有自己的账户。需要 root 权限的命令通过 sudo 白名单执行，白名单中只包含它确实需要的命令：软件包更新、服务重启、日志访问。其他一律禁止。
• 保持审批模式开启。这三款工具在执行会改动系统的操作前都会先征询确认。--dangerously-skip-permissions 或 danger-full-access 之类的开关只该出现在用完即弃的虚拟机上，绝不能用于生产系统。
• 每次会话前先做备份或快照。一个“修复”配置的智能体，也可能把配置彻底弄坏。有快照或经过测试的备份，这只是个小麻烦；没有的话，就是一场紧急事故。
• 提示词里不放任何机密。密码、API 密钥和客户数据一律不写进任务。智能体从文件中读取的内容都会发送给服务商；因此，含有机密的文件要么放在它的访问范围之外，要么事先做脱敏处理。
• 先测试环境，再生产环境。新的任务模式先在测试虚拟机上试运行。只有流程多次顺利跑通之后，才允许用于生产系统。
• 保持变更可追溯。把 /etc 纳入 Git 管理（etckeeper），保留会话记录，让智能体总结每一次变更。无法追溯的变更，也就无法回滚。
• 设置费用上限。在服务商处为 API 密钥设定月度预算。否则，一个陷入死循环的智能体会比任何一台服务器都贵。
• 网络访问保持最小化。智能体只需要通往服务商的出站 HTTPS。入站方向无需任何改动，服务器仍然处于防火墙和 DDoS 防护之后。

为什么专用用户如此重要

语言模型会犯错，而且犯错时往往信心十足。一个搞混了路径的智能体，如果拥有 root 权限，就会删掉错误的目录；如果使用专用用户，同一条命令会因权限不足而失败。因此，真正的安全边界是 sudo 白名单，而不是模型的谨慎。此外还有一个实际的好处：在日志中随时都能分辨出哪些操作来自智能体，哪些来自人。如何创建这样的用户，请参阅文章 在 Linux 下创建 sudo 用户。

AI 服务商能看到什么

智能体读到的一切，都会发送给服务商的语言模型处理：日志行、配置文件、命令输出。服务器上的工具只是个信使。由此得出两条规则。第一，含有访问凭据的文件不应进入智能体的视野；脚本照样可以使用这些文件，而无需智能体将其内容显示出来。第二，客户的个人数据不应出现在任务中。如果您需要对客户数据进行统计分析，可以让智能体编写一条只返回数字或匿名化结果的查询，然后由您自己执行。

智能体擅长什么，哪些事最好由您亲自动手

实践经验表明：智能体在阅读量大、风险低的任务上表现出色。典型的例子包括：汇总过去 24 小时的日志、找出一条错误信息的原因、检查 nginx 配置是否有错、编写 systemd 单元文件、调整 Docker Compose 文件、创建带日志轮转的备份脚本、解释一条防火墙规则。流程明确的例行维护同样很适合，例如安装更新，随后检查服务并撰写报告。

适合入门的任务

• “汇总过去 24 小时的错误和警告，按服务分组。”
• “哪些服务运行失败了？每个服务最后一条错误信息分别是什么？”
• “哪些软件包有待安装的安全更新？”
• “检查 nginx 配置，并解释 nginx -t 给出的每一条警告。”
• “哪些目录占用的空间最多？其中哪些可以安全删除？”

应由人来完成的任务

不太适合的是后果不可逆、要求又不明确的任务：迁移数据库、修改分区、删除用户、清理生产数据。在这些场景中，智能体是一位能写出方案的好顾问，但执行必须由人来完成。还有一点：看不懂输出的智能体会去猜。如果您自己无法判断某个输出，就不应批准它。

日常典型流程

每日日志报告

无人值守任务中的经典用例：每天早上由 cron 任务用一条固定指令启动智能体，例如“汇总过去 24 小时的错误和警告”，并通过电子邮件发送结果。在此过程中，智能体只能读取，可用的工具仅限于 journalctl。cron 任务的具体写法见安装指南。

更新与报告

遇到安全更新时，智能体会先检查哪些软件包受到影响，以及更新后需要重启哪些服务。获得您的批准后，它会安装更新、重启服务、检查服务状态，并撰写一份简短报告。如果您想让更新全面自动化，可以将其与 unattended-upgrades 结合使用，只让智能体负责检查。

出现故障时的排查

发生故障时，您只需描述症状，例如“网站返回 502”。智能体会读取 Web 服务器和应用程序的日志，检查后端服务是否在运行，提出一个假设，并用日志行加以佐证。解决方案由它提出，但只有在您批准后才会实施。常见原因及其解决方法，请参阅文章 解决 nginx 502 Bad Gateway 错误。

与 KernelHost 服务器完全兼容

每一台 KernelHost 服务器开箱即满足 AI 工具的全部要求，无需任何特殊配置：

• 完整的 Root 权限，适用于 KVM 根服务器和独立服务器，让您可以自行设置用户、sudo 规则和 Node.js。
• 自由选择操作系统：Debian、Ubuntu、AlmaLinux、Rocky Linux 以及其他发行版，Claude Code、Codex CLI 和 Gemini CLI 均官方支持在这些系统上运行。在 Windows 服务器上，这些工具可以原生运行，也可以通过 WSL 运行。
• 出站连接不受限制：智能体通过 HTTPS 与 api.anthropic.com、api.openai.com 以及 Google 的 API 通信。DDoS 防护只过滤入站攻击流量，不会拖慢智能体。
• 不限流量：API 请求的数据量很小，但一个分析日志的智能体在一个月里仍会产生一定的数据流量。在 KernelHost，这一点无关紧要。
• Node.js 可从软件源或 NodeSource 安装，具体方法见 在 Debian 上安装 Node.js 的指南。
• 法兰克福机房：到各服务商欧洲 API 端点的网络路径很短，数据存放在位于德国的数据中心。

简而言之：在 KernelHost，您不需要额外订购或开通任何东西。一台 KVM 根服务器、一个用户、一款工具，仅此而已。

KernelHost API：为智能体自动开通服务器

智能体不仅可以在服务器上工作，还可以通过 KernelHost API 开通和控制服务器：查询产品、订购服务器、读取状态、启动、停止和重启服务器，以及提交和撤回退订申请。这样一来，“帮我为这次更新准备一台测试服务器”就变成了一项单独的任务，从下单到安装完成都由智能体一手包办。API 密钥可以限定在所需的权限范围内；当智能体重复发送请求时，Idempotency-Key（幂等键）可以防止重复下单；每次调取访问凭据都会触发一封电子邮件通知。计费采用 PrePaid 预付费模式，没有最低合约期，因此一台只用几天的测试服务器不会让您受到任何约束。

成本：订阅还是 API

运行时会产生两类费用：服务器和语言模型。服务器就是一台本来就在运行的普通根服务器。模型方面有两种方式。订阅（Claude Pro 或 Max、ChatGPT Plus 或 Pro）在额度范围内包含相应命令行工具的使用，如果每天都用，通常更划算。API 密钥按 Token 计费，无需订阅，并且可以通过预算设定上限；如果只是偶尔维护，每月费用往往只有几欧元。对于无人在场的自动化任务，例如每日日志报告，使用 API 密钥是更规范的做法，因为订阅登录绑定在一台设备和一个人身上。

入门时的常见错误

• 智能体以 root 身份运行。第一天很方便，从第二天起就很危险。解决方法：使用带 sudo 白名单的专用用户。
• 关闭了所有确认提示。解决方法：只允许只读命令免确认执行，所有会改动系统的操作都需确认。
• 没有规则文件。没有 CLAUDE.md、AGENTS.md 或 GEMINI.md，智能体既不了解您的服务，也不知道您设定的边界。解决方法：把规则写下来，每次纠正后都加以补充。
• 会话前没有备份。解决方法：在智能体做任何改动之前，先做快照或经过测试的备份，具体见备份策略一文。
• 任务中包含机密。解决方法：访问凭据只存放在智能体无需显示的文件中，一旦不慎泄露，立即重新生成。
• 未经核实就采纳结果。解决方法：要求提供依据，例如支持某个推测的日志行，并让智能体在实际系统上验证结果。

下一步

如果您想亲自试一试：准备一台装有 Debian 或 Ubuntu 的 KVM 根服务器，先按照新根服务器检查清单完成基础加固，然后按照 Claude Code 和 Codex CLI 分步指南操作。一小时后，您的服务器就能回答关于它自己日志的问题了。

从 SSH 接入到在生产系统上部署，这一切在日常工作中是什么样子，请看我们的实践报告 将 AI 接入服务器：AI 智能体如何部署和管理您的服务器。

要点总结

• AI 托管服务器是一台普通的根服务器，Claude Code、Codex CLI 或 Gemini CLI 之类的 AI 智能体以专用用户身份在上面工作。
• 智能体负责读取、分析和提出建议，会改动系统的操作只在获得批准后执行。
• 有三种经过实践检验的方式：智能体在工作电脑上通过 SSH 操作、直接在服务器上运行，或在堡垒机虚拟机上运行。
• 专用用户、审批模式、每次会话前备份以及提示词里不放机密，这几条不可妥协。
• 不需要 GPU，因为语言模型运行在服务商那里。
• 每一台 KernelHost 服务器开箱即满足这些要求，智能体甚至可以通过 KernelHost API 自行开通服务器。