把 AI 连接到服务器：AI 智能体如何部署和管理您的服务器

到目前为止，大多数人使用 AI 的方式，就像在电话里请教一位非常博学的同事：描述服务器问题，得到一条建议的命令，把它复制到控制台，再把错误信息复制回去，如此反复，直到一切正常。一旦您把 AI 连接到自己的服务器，这种绕弯子的做法就不再需要了。像 Claude Code、OpenAI Codex CLI 或 Gemini CLI 这样的 AI 智能体，会自己通过 SSH 登录服务器，读取日志，检查配置，部署变更，测试结果，并把自己做过的事记录下来。由您下达任务，并批准那些无法撤销的步骤。

本文是一篇实践报告。在 KernelHost，一个 AI 智能体几个月来每天都参与我们自有基础设施的工作：客户门户、监控、支付渠道、文档。我们将展示智能体与服务器之间的连接是如何搭建的，智能体在生产系统上按照什么流程部署，哪些规则能防止过程中出错或信息外泄，以及服务器需要具备什么条件，整套方案才能正常运转。工具和架构的基础知识见文章 AI 托管服务器：安全接入 AI 智能体，在服务器上的安装步骤见 Claude Code 和 Codex CLI 安装指南。

把 AI 连接到服务器：这意味着什么

把 AI 连接到服务器，就是为 AI 智能体开通一个专属且受控的服务器命令行访问权限，通常借助 SSH 密钥实现。从这一刻起，智能体不仅能建议命令，还能自己执行命令、读取输出，并据此推导出下一步。语言模型本身仍然运行在服务商那里（Anthropic、OpenAI 或 Google），您的电脑或服务器上只运行一个轻量的命令行工具，负责发出命令。

关键在于“受控”二字。拥有服务器访问权限的智能体不是自动驾驶仪，而是一位动作非常快、在每次干预性操作之前都会先询问的同事。它在不询问的情况下可以做多少事，由您自己决定：从纯只读访问，到按照固定流程自行部署更新。

聊天机器人还是智能体：一张表看懂区别

这样一来，原本半小时的来回沟通往往只需几分钟，“敲错命令”这一错误来源也彻底消失。

AI 智能体在服务器上能做什么：来自我们运维的实例

以下示例来自我们的日常工作。名称、地址和访问凭据我们都略去了，流程则是真实的。

带备份和回滚方案的部署

当我们修改客户门户或某个服务器脚本时，由智能体负责部署。它首先把服务器上的文件与最后已知的版本进行比较，以免覆盖别人做的修改。然后，它在 Web 目录之外创建一份带日期的备份，编写一个回滚脚本，检查新文件的语法，以与之前相同的所有者和权限部署新文件，随后测试受影响的功能。只有所有检查都通过，它才报告完成。具体流程见下文关于部署的章节。

故障排查：几分钟内从现象找到原因

“从我们办公室打不开网站，在外面却可以。”以前这意味着一番漫长的排查。智能体检查防火墙规则，在防护软件的日志中搜索办公室的 IP 地址，找到生效的那条规则，并解释是哪个请求触发了它。怎么处理仍由我们决定，侦查工作则交给了它。遇到 502 Bad Gateway 或磁盘已满这类典型的 Web 服务器故障，它的做法也一样：借助 journalctl 和应用日志展开分析，提出一个假设，并在做任何修改之前先用证据证实它。

由智能体自己搭建的监控

我们的监控有很大一部分是与智能体合作完成的：一些小型检测脚本，每隔几分钟通过 cron 任务对某项服务做一次端到端测试，一旦出错就向手机发送消息，例如通过 Telegram 机器人。智能体编写脚本，用故意触发的故障来测试它，设置 cron 任务，并记录如何让告警静音。这类监控的基本搭建方法，见文章 搭建服务器监控。

概览与清理

哪些服务器对应的合同已经退订，却仍在运行？哪些附加服务仍在付费，却已不再使用？智能体以只读方式查询数据库和接口，并把结果整理成表格，以此回答这类问题。只有获得批准后，它才可以清理；在此之前，它会先确认机器是否真的闲置，例如查看过去几天的数据流量。

随工作自动完善的文档

每次变更结束时，都会在变更日志中留下一条记录，必要时还会补充运维手册。这只花智能体几秒钟，却能在日后为我们节省数小时，因为“这里为什么是这样？”这个问题有了书面答案。

AI 直接在服务器上工作的好处

• 速度： 人需要几分钟才能读完的内容，智能体几秒钟就能读完；它会立即验证一个假设，而不是先把它描述一遍。
• 细致： 它读取完整的配置（包括被引入的文件）以及错误前后的日志行，而不只是某人认为相关的那一段。
• 流程始终如一： 备份、语法检查和结果检查每次都会执行，周五晚上如此，第二十个小改动也是如此。
• 文档不增加工作量： 每项变更都有说明，包括原因、备份位置和回滚方案。
• 无需钻研脚本也能自动化： 检测脚本、cron 任务和报告根据一段日常语言的描述生成，并在投入使用前经过测试。
• 顺带学习： 智能体会解释它在做什么以及为什么这样做。一直跟着看的人，几周后会明显更了解自己的服务器。

三种架构，以及我们采用的方案

把智能体连接到服务器，有三种经过验证的方式。它们的区别在于工具在哪里运行，以及访问凭据存放在哪里。

我们的选择：智能体在工作站上，服务器通过 SSH 连接

我们采用第一种方案。智能体运行在工作电脑上，每台服务器在 SSH 配置中都有一个条目，智能体使用自己专属的密钥进行连接。最重要的原因是：我们要维护很多系统，而正是用这种方式，一个智能体可以在一次会话中跨多台服务器追查一个原因，例如从 Web 服务器经过数据库一直追到防火墙。此外，AI 服务商的登录信息和密钥存放在一个我们本来就会保护的地方。如果您只有一台服务器，又希望夜间自动生成报告，第二种方案会很合适。关于各方案的优缺点，详见关于 AI 托管服务器 的文章。

指南：通过 SSH 将 AI 智能体连接到服务器

以下七个步骤对 Claude Code、Codex CLI 和 Gemini CLI 同样适用。示例使用文档专用 IP 地址 203.0.113.10 和用户名 deploy，请把两者替换为您自己的值。前提条件是一台已启用 SSH 密钥登录的服务器，具体做法见文章 加固 SSH 并设置密钥登录。

第 1 步：为智能体单独生成一个 SSH 密钥

智能体永远不会拿到您的个人密钥，而是使用自己专属的密钥。这样您可以随时撤销它的访问权限，而您自己的访问不受影响，并且在日志中可以看出哪次登录来自智能体。

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 密钥短小、速度快，并且被认为是安全的。注释 ki-agent 之后会出现在服务器的 authorized_keys 中，让人一眼就能认出这个密钥。

第 2 步：把公钥添加到服务器上

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

如果想进一步限制访问，可以在服务器上的 ~/.ssh/authorized_keys 文件中，在密钥前面加上选项。from= 只允许从某个特定地址登录，no-agent-forwarding 和 no-port-forwarding 可以防止这条连接被用作跳板：

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

如果服务器随后报错 Permission denied (publickey)，可参考文章 解决 SSH Permission denied (publickey) 错误。

第 3 步：在 SSH 配置中创建主机别名

有了别名，智能体只需要知道一个简短的名称，并且始终会使用正确的密钥：

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

之后只需执行 ssh web-prod "systemctl status nginx" 即可。IdentitiesOnly yes 可以防止 SSH 逐个尝试您密钥环中的其他密钥。每增加一台服务器，就单独创建一个配置块；测试系统和生产系统最好使用不同的名称，例如 web-test 和 web-prod，这样一旦弄混，从名称上就能看出来。

第 4 步：安装智能体并登录

Claude Code、Codex CLI 和 Gemini CLI 可在 Linux、macOS 和 Windows 上运行，使用服务商账户或 API 密钥登录。安装方法以及如何在没有浏览器的情况下登录，见 分步指南。如果采用工作站方案，请把工具安装在您的电脑上，而不是服务器上。

第 5 步：制定智能体必须遵守的规则

三个工具在启动时都会读取工作目录中的一个规则文件：Claude Code 读取 CLAUDE.md，Codex CLI 读取 AGENTS.md，Gemini CLI 读取 GEMINI.md。文件中写明在您的服务器上应该如何工作。一个经过验证的起点：

# 服务器操作规则

- 每次修改前，在 Web 目录之外创建一份带日期的备份。
- 部署前检查语法（nginx -t、php -l、apachectl configtest）。
- 部署后检查服务、日志和功能，并报告结果。
- 绝不输出密码、API 密钥和 Token，绝不把它们复制到文件中。
- 删除、数据库变更以及一切不可逆的操作，只能在明确批准后执行。
- 不直接修改由控制面板管理的文件。
- 测试结束后删除测试文件。

这些规则会随着时间不断充实。每当智能体的做法与您的期望不同，就把纠正写成一条规则加进这个文件。几周之后，它的工作方式就会和您自己的一样。

第 6 步：设置审批和白名单

默认情况下，这些工具在执行任何会做出改动的命令之前都会询问。刚开始时这样做是对的。对于您总是要确认的只读命令，可以直接放行。在 Claude Code 中，这通过文件 .claude/settings.json 完成：

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

凡是不在这个列表中的命令，仍然需要您的同意。关闭所有询问的开关，最多只能用在一次性的测试机器上。

第 7 步：第一个任务只读不写

先从不会改变任何东西的任务开始，并观察智能体如何着手处理：

检查 web-prod 上过去 24 小时的 nginx 错误，列出最常见的三个
原因，并为每个原因附上一条日志中的证据。不要做任何修改。

分析结果都准确无误之后，再进行一些小改动，例如新的日志轮转配置或一个 systemd 服务，然后才轮到生产系统上的部署。

智能体如何部署：我们对生产系统每次变更的流程

AI 智能体只能按照固定流程在生产系统上部署，这个流程要包含备份、事先准备好的回滚方案，以及部署前后的检查。我们的流程如下：

1. 检查当前状态。 将服务器上的文件与最后已知的版本进行比较。如果期间有其他人修改过它，智能体会中止并询问，而不是覆盖别人的修改。
2. 创建备份。 受影响的文件带上日期，存入 Web 目录之外的备份文件夹。放在 Web 目录内的备份，在某些情况下可能被公开访问。
3. 准备回滚方案。 一个只需一条命令就能恢复旧版本的小脚本，在修改之前就写好，而不是等到出了紧急情况才写。
4. 检查语法。 新文件在部署之前先经过检查，PHP 用 php -l，nginx 用 nginx -t。这样，语法错误根本不会进入生产系统。
5. 以正确的权限部署。 所有者、用户组和文件权限沿用旧版本。更新后出现故障，最常见的原因除了语法错误就是错误的权限。
6. 无副作用地测试。 测试采用只读方式、虚构的测试数据或隔离的环境，绝不使用真实订单或真实客户数据。
7. 线上验证。 部署之后检查 HTTP 状态码、错误日志以及被修改的功能。
8. 记录文档。 补充变更日志和运维手册，包括备份位置和回滚命令。

写成命令序列（用占位符代替真实路径），大致如下：

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

为什么回滚方案要在修改之前准备好

出了故障的时候，没有人还处在最佳状态，能从容地想出一个干净的回滚方案。如果脚本已经准备好，撤销只是几秒钟的事；当部署后的检查失败时，智能体也可以自己执行回滚。这正是一个“随手”改点东西的智能体，与一个可以托付生产系统的智能体之间最大的区别。

不会搞坏任何东西的测试

很多功能一旦测试，就难免真的触发某些事情：一笔订单、一次付款、一封邮件。这时有三种技巧可以帮忙。第一，使用工具本身提供的试运行（dry run）。第二，使用保证在任何地方都不存在的虚构标识符。第三，使用隔离环境：一个在没有网络的独立网络命名空间中运行的进程（unshare -n），既无法访问外部接口，也不会意外买下任何东西，但仍然可以通过 Unix 套接字访问本地数据库。测试结束后，所有测试文件都会被删除。

会花钱的操作需要加锁

如果一个流程会下单、计费或删除东西，它就绝不能同时运行两次，即使有人双击，或者智能体重复执行了一条命令也不行。在 Linux 上，最简单的解决方法是 flock：

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "已在运行"

在数据库应用中，命名锁（MySQL 和 MariaDB 中的 GET_LOCK）可以起到同样的作用；在接口中则是幂等键（Idempotency-Key），详见下文关于 KernelHost API 的部分。

安全：为智能体开放访问，同时不泄露任何信息

我们最常听到的顾虑是：“那我的数据怎么办？”坦白地说：智能体读取的一切内容，都会发送给服务商的语言模型进行处理。因此，您要通过以下规则来决定它究竟能看到什么。

机密信息不能出现在聊天中

密码、API 密钥和 Token 绝不写进任务，也绝不由智能体输出。脚本从权限为 600 的文件中读取它们，智能体无需显示这些文件的内容就能使用脚本。如果仍有密钥出现在聊天中，就立即在服务商处将其吊销并重新生成。密钥的片段同样不应出现在聊天中：密钥的前几个字符对排查问题毫无帮助，却会让攻击者省下不少功夫。

专属密钥、专属权限，随时可撤销

每个智能体都有自己专属的 SSH 密钥，每个密钥在 authorized_keys 中都可以通过注释识别出来。要撤销访问权限，只需删除那一行。只要能满足需要，智能体就使用自己的用户账户，并配合一条只允许必要命令的 sudo 规则 工作。API 使用各自独立的密钥，权限尽可能小，纯粹用于统计分析的密钥只给只读权限。

审批：哪些操作绝不会在无人确认时执行

在我们这里，未经明确同意，智能体不得删除任何东西，不得写入数据库，不得放宽防火墙或防护规则，不得停止机器，也不得订购任何东西。工具本身也支持这一点：Claude Code 会暂停干预性操作，还可以额外设置一个安全过滤器，识别有风险的命令并在批准之前一直拦截。来自我们日常工作的实例：这个过滤器不止一次拦下过技术上正确、但偏偏不可逆的操作。这些操作都是在有人明确批准之后才执行的。本来就应该这样。

可追溯性：日志、变更清单、备份

每次会话都会留下人可以阅读的痕迹：带日期的备份、回滚脚本、变更日志中的条目，以及系统日志中的登录记录。如果再用 etckeeper 把 /etc 纳入 Git 管理，每一次配置变更都能以 diff 的形式看到。无法追溯的东西，也无法回滚。基础仍然是一套行之有效的 备份策略，因为智能体不能取代备份。

哪种服务器适合 AI 智能体？

用于 AI 辅助管理的服务器需要完整的 Root 权限、SSH 密钥登录、不受限制的出站连接、持续有效的 DDoS 防护，最好还有一个可以自动订购和控制服务器的 API。它不需要 GPU，因为语言模型运行在服务商那里。

为什么选择 KernelHost 运行 AI 管理的服务器

原则上，只要能获得 Shell，AI 智能体就可以在任何服务器上工作。但在实践中，环境决定了您真正能把多少工作交给它。在 KernelHost 的 KVM Root 服务器 或 独立服务器 上，没有受限账户，到 AI 服务商的 HTTPS 连接没有任何障碍，也没有让试用变得昂贵的合约绑定。永久 DDoS 防护 在每台服务器上都免费启用；对于计算密集型任务，还有配备独享核心的 专业版 Root 服务器。计费方式为 PrePaid 预付费：无合约、无最低合约期、无开通费。想先试一试的话，可以从 免费测试服务器 开始。

KernelHost API：您的智能体自行订购和控制服务器

最大的杠杆位于单台服务器之上的那一层。通过 KernelHost API，智能体可以查询产品和价格、订购服务器、读取其服务的状态，启动、停止和重启服务器，以及提交和撤回退订。这样，“帮我搭一台测试服务器”就变成了一个单一任务：智能体订购机器，等待开通，通过 SSH 连接，安装应用，然后把地址报告回来。

考虑到由智能体调用，这个接口在设计上刻意保持谨慎。API 密钥只获得各自所需的权限，用于统计分析的密钥根本无法订购任何东西。幂等键确保智能体在超时错误后重复提交的订单不会被执行两次。请求按密钥、按账户和按 IP 地址分别限速，因此即使一个智能体陷入死循环，也不会引发雪崩。此外，每次读取访问凭据都会触发一封电子邮件通知，让您知道智能体是在什么时候读取了访问凭据。

一台 AI 管理的服务器要花多少钱？

费用分为两部分。第一是服务器本身：对于通过 SSH 工作的智能体，服务器不需要任何特殊配置，任何一台本来就运行着您应用的 Root 服务器都足够。如果智能体直接在服务器上运行，工具本身只需要几百兆字节的内存；如果服务器上没有运行太多其他东西，一台 2 vCPU、4 GB 内存的 Root 服务器就够用。第二是语言模型：要么是服务商的订阅，其中包含命令行工具的使用；要么是按用量计费的 API 密钥。每天高强度使用时，订阅通常更便宜；对于没有人在场的自动化任务，API 密钥是更干净的方式，因为它可以用月度预算设置上限。当前的服务器价格请见 Root 服务器租用 页面。

常见错误以及如何避免

• 智能体使用管理员的个人密钥工作。 这样它的访问权限就无法单独撤销，在日志中也无法区分。解决方法：使用带有独立注释的专属密钥。
• 关闭了所有询问。 这在第一天能省下一些点击，但迟早会赔上一台服务器。解决方法：只读命令加入白名单，所有干预性操作都需要审批。
• 修改前没有备份。 解决方法：在 CLAUDE.md 或 AGENTS.md 中把备份和回滚脚本写成固定规则。
• 备份放在 Web 目录中。 像 config.php.bak 这样位于 Web 根目录中的文件可能被公开访问，连同其中的数据库密码。解决方法：在 Web 目录之外建立权限为 700 的备份文件夹。
• 提示词中包含机密。 解决方法：访问凭据只存放在权限为 600、由脚本读取的文件中，一旦失误立即重新生成。
• 重复执行。 一次双击或一个重复的请求会下两次订单。解决方法：用 flock 加锁，或使用幂等键。
• 直接修改了由控制面板管理的文件。 面板会在下次更新时覆盖这些文件，或者因此而出错。解决方法：在规则中排除这类文件，通过面板或其接口进行修改。
• 未经核实就采纳输出。 看不懂输出的智能体会靠猜。解决方法：要求它提供证据（“把那行日志给我看”），并让它在线上验证结果。

简要总结

• 把 AI 连接到服务器，就是为 Claude Code、Codex CLI 或 Gemini CLI 这样的智能体提供专属的 SSH 密钥和明确的规则。
• 智能体读取日志、部署变更、检查结果并记录下来，干预性步骤只有在获得批准后才会执行。
• 每次部署都遵循固定流程：检查当前状态、备份、准备回滚方案、检查语法、部署、测试、线上验证、记录文档。
• 机密信息绝不应出现在聊天中，会花钱的操作需要加锁，防止重复执行。
• 服务器需要 Root 权限、SSH 密钥、畅通的出站连接和 DDoS 防护，但不需要 GPU。
• KernelHost 服务器开箱即满足所有要求，采用 PrePaid 预付费、无合约绑定，智能体甚至可以通过 KernelHost API 自行订购和控制服务器。