1. 项目缘起与整体设计思路1.1 为什么要把 Hermes 塞进一台免费服务器手里有台常年吃灰的云主机是很多人共同的经历。Oracle Cloud 的永久免费额度里包含 ARM 架构的 Ampere A1 实例配置给得相当大方但大多数人开完机器、跑个测试脚本之后就再也没登录过。我这次做的事情就是把这台闲置机器改造成一个 7×24 小时在线的 AI 助手节点核心跑的是 Hermes 这套智能体框架。先说清楚 Hermes 在这里扮演什么角色。它不是一个大语言模型本身而是一个智能体编排层——你可以把它理解成一个“调度中枢”负责接收消息、管理会话上下文、调用后端模型、执行工具函数、维护技能库。真正干推理活儿的可以是本地跑的模型也可以是远程 API。这种分层设计的好处是模型可以随时换但助手的行为逻辑、技能配置、对话记忆都留在 Hermes 这一层迁移成本极低。那为什么偏偏选 Oracle Cloud Free三个理由。第一成本为零永久免费额度不像某些厂商的试用期到期就收费它是真的一直免费。第二ARM 实例的性价比A1 实例最高可以给到 4 核 24GB 内存这个配置跑一个轻量智能体框架加一个小参数量本地模型完全够用。第三公网 IP 固定机器重启后地址不变省去了动态域名解析的麻烦。适合谁来参考这套方案我觉得有三类人。一是手里有闲置云资源、想物尽其用的开发者二是想搭一个私人 AI 助手但不想每月掏订阅费的个人用户三是对智能体框架感兴趣、想找个真实场景练手的技术爱好者。不需要你是运维专家但基本的 Linux 命令行操作得会SSH 登录、编辑配置文件、看日志这些是绕不开的。1.2 整体架构怎么搭分层解耦是核心原则在动手之前我先把整个架构想清楚了。很多人部署 AI 助手容易犯一个错误把所有东西揉在一起模型、框架、前端、数据库全塞在一个进程里结果一出问题就抓瞎。我的做法是分层解耦每一层职责单一出问题能快速定位。整个系统分成四层。最底层是基础设施层就是 Oracle Cloud 的那台 ARM 实例负责提供计算、存储和网络。往上是运行时层包括容器运行时和进程管理工具我用的是 Docker 加 systemd 的组合Docker 负责隔离各个服务systemd 负责开机自启和崩溃重启。再往上是服务层Hermes 主进程、模型推理服务、向量数据库各跑各的容器通过内部网络通信。最上面是接入层负责对外暴露接口可以是 HTTP API也可以是消息平台的 webhook。这么分层的好处我在后面实操中体会特别深。有一次模型服务因为内存不足被系统杀掉了但 Hermes 主进程毫发无损只是调用模型时报错。我只需要重启模型容器就行不用把整个助手推倒重来。如果当初全揉在一起那就是整个服务挂掉排查起来至少多花半小时。提示分层解耦不是让你过度设计。如果你只是跑一个纯 API 调用的助手本地不跑模型那服务层可以简化成 Hermes 加一个轻量数据库就够了。架构要匹配你的实际需求别为了分层而分层。1.3 选型背后的取舍为什么是这套组合工具选型这块我纠结了挺久这里把思考过程摊开讲方便你根据自己的情况调整。容器运行时选 Docker 而不是 Podman。两者功能上差不多但 Docker 的生态更成熟文档多遇到问题搜一下基本都有答案。Podman 虽然 rootless 更安全但在 ARM 架构上偶尔会有兼容性小毛病我不想在环境问题上浪费时间。进程管理用 systemd 而不是 supervisor。systemd 是系统自带的不用额外装东西而且和 Docker 配合得很好——用systemctl enable docker就能保证容器运行时开机自启再用 restart policy 控制容器本身的重启策略两层保险。模型后端留了可切换的接口。我一开始想直接跑本地模型但实测下来 ARM 架构上跑 7B 以上的模型推理速度不太理想。所以最终方案是默认走远程 API本地模型作为备选。Hermes 的配置里把模型端点做成可配置项想换随时改不用动代码。数据库选 SQLite 而不是 PostgreSQL。对于个人助手这种单用户、低并发的场景SQLite 完全够用而且零配置、单文件、备份就是复制一个文件省心。等哪天真的多用户高并发了再迁移也不迟Hermes 的存储层抽象做得不错换数据库不用重写业务逻辑。2. 环境准备与核心细节解析2.1 Oracle Cloud 实例开通与基础配置开通实例这一步看似简单但有几个坑我踩过提前说清楚能帮你省时间。登录 Oracle Cloud 控制台后创建实例时镜像一定要选对架构。ARM 实例VM.Standard.A1.Flex只能用 aarch64 架构的镜像如果你手滑选了 x86 的 Ubuntu 镜像创建会直接失败。我推荐选 Ubuntu 22.04 的 aarch64 版本长期支持软件源里的包也全。配置规格时免费额度允许你分配最多 4 个 OCPU 和 24GB 内存。我的建议是别一次性拉满。先给 2 核 12GB跑起来看看资源占用不够再加。因为 Oracle 的免费额度是账户级别的你如果同时开多台机器总额度是共享的。留点余量以后想开第二台测试机也方便。网络配置这块安全列表Security List和网络安全组NSG要放行你需要的端口。默认只开了 22 端口给 SSH如果你要通过 HTTP 访问助手得手动加一条入站规则放行 80 或 443。我一开始忘了这茬服务明明跑起来了外网就是访问不了排查了半天才发现是安全列表没放行。SSH 登录后第一件事是更新系统并安装基础工具sudo apt update sudo apt upgrade -y sudo apt install -y curl wget git vim htop net-toolshtop和net-tools是我必装的前者看资源占用直观后者排查网络问题方便。别小看这些基础工具真出问题时能帮你快速定位。注意Oracle Cloud 的 ARM 实例默认没有 swap 分区。如果你打算跑本地模型内存吃紧时容易触发 OOM Killer 把进程杀掉。建议手动创建一个 4GB 的 swap 文件作为缓冲具体命令后面实操部分会讲。2.2 Docker 与容器运行时的安装要点在 ARM 架构上装 Docker一定要用官方源而不是系统自带的版本。Ubuntu 仓库里的 Docker 版本往往偏旧而且 ARM 支持不一定完整。官方源安装步骤如下# 安装依赖 sudo apt install -y ca-certificates curl gnupg lsb-release # 添加 Docker 官方 GPG 密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加软件源 echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 Docker sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin装完之后把当前用户加入 docker 组这样就不用每次敲命令都加 sudosudo usermod -aG docker $USER newgrp dockernewgrp这步很多人会漏导致当前会话里权限还没生效得退出重登才行。加上这行就省事了。验证安装是否成功跑一个 ARM 架构的测试容器docker run --rm hello-world如果能看到欢迎信息说明 Docker 在 ARM 上工作正常。这里有个细节拉取镜像时要注意架构匹配。有些镜像只有 x86 版本在 ARM 上跑会报exec format error。遇到这种情况要么找 ARM 版本的镜像要么用--platform linux/amd64强制模拟运行性能会打折不推荐长期用。2.3 Hermes 框架的获取与依赖梳理Hermes 的获取方式取决于你用的具体发行版本。我这边用的是社区维护的智能体框架通过 Git 克隆到本地cd /opt sudo git clone https://github.com/your-org/hermes-agent.git sudo chown -R $USER:$USER /opt/hermes-agent cd /opt/hermes-agent克隆下来之后先别急着跑花十分钟读一遍 README 和 requirements 文件。这一步很多人跳过结果后面报错一堆。重点看三样东西Python 版本要求、系统级依赖、环境变量清单。Python 版本这块Hermes 一般要求 3.10 以上。Ubuntu 22.04 自带的 Python 是 3.10刚好够用。但如果你需要更新的版本建议用pyenv管理别直接替换系统 Python否则系统工具可能出问题。系统级依赖通常包括编译工具和某些库的开发头文件sudo apt install -y python3-pip python3-venv build-essential libssl-dev libffi-dev python3-dev创建虚拟环境是必须的别把依赖装到系统 Python 里python3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install -r requirements.txt在 ARM 上装依赖时某些包可能需要从源码编译耗时会比较长。如果卡在某个包上超过五分钟大概率是在编译耐心等等。实在等不及可以看看有没有预编译的 wheel 包用pip install --only-binary :all: 包名试试。提示如果 requirements 里有torch这类大包ARM 版本的 wheel 可能不在默认源里。需要去 PyTorch 官网找对应的 aarch64 安装命令别直接 pip install会下一堆源码编译到天荒地老。3. 实操过程与核心环节实现3.1 模型后端的接入与配置Hermes 本身不带模型得给它接一个推理后端。我分两种情况讲走远程 API 和跑本地模型。远程 API 方式最简单适合快速跑通。在 Hermes 的配置文件里找到模型配置段填入 API 地址和密钥model: provider: openai_compatible base_url: https://api.example.com/v1 api_key: your-api-key-here model_name: your-model-name max_tokens: 2048 temperature: 0.7这里provider填openai_compatible是因为大多数模型服务都兼容 OpenAI 的接口格式Hermes 用统一的适配层去调换服务商只需要改base_url和model_name。本地模型方式稍微复杂点。我在 ARM 实例上试过用 Ollama 跑小模型步骤如下# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取一个适合 ARM 的小模型 ollama pull qwen2.5:3b # 验证服务 curl http://localhost:11434/api/generate -d {model:qwen2.5:3b,prompt:你好}然后在 Hermes 配置里把base_url改成http://localhost:11434/v1model_name填qwen2.5:3b。实测下来3B 参数量的模型在 2 核 ARM 上推理速度大概每秒 5-8 个 token日常对话够用但复杂任务会有点慢。如果你分配到 4 核速度能提升到 10-15 token/秒。模型选择上参数量不是越大越好得在效果和速度之间找平衡。我的经验是3B 用于简单问答和意图识别7B 用于需要一定推理能力的场景再大就不建议在免费 ARM 实例上跑了。注意本地跑模型时一定要限制并发数。Hermes 默认可能允许多个请求同时进来ARM 实例的 CPU 核心少并发一高就卡死。在配置里把max_concurrent设成 1 或 2宁可排队也别把机器拖垮。3.2 用 Docker Compose 编排多服务手动一个个起容器太麻烦我用 Docker Compose 把整个栈编排起来。在项目根目录建一个docker-compose.ymlversion: 3.8 services: hermes: build: . container_name: hermes-agent restart: unless-stopped ports: - 8080:8080 volumes: - ./data:/app/data - ./config:/app/config environment: - MODEL_BASE_URLhttp://ollama:11434/v1 - MODEL_NAMEqwen2.5:3b - DB_PATH/app/data/hermes.db depends_on: - ollama networks: - hermes-net ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped volumes: - ./ollama-data:/root/.ollama networks: - hermes-net networks: hermes-net: driver: bridge几个关键点解释一下。restart: unless-stopped保证容器崩溃后自动重启除非你手动停了它。volumes把数据和配置挂载到宿主机这样容器重建时数据不丢。depends_on控制启动顺序让 Ollama 先起来再起 Hermes。networks让两个容器在同一个内部网络里Hermes 可以直接用服务名ollama访问不用管 IP。启动整个栈docker compose up -d查看状态docker compose ps docker compose logs -f hermeslogs -f是实时跟踪日志调试阶段特别有用。看到 Hermes 打印出 “listening on port 8080” 之类的信息就说明起来了。3.3 配置 systemd 实现开机自启与崩溃恢复Docker Compose 本身不保证开机自启得靠 systemd 兜底。创建一个服务单元文件sudo vim /etc/systemd/system/hermes.service内容如下[Unit] DescriptionHermes AI Agent Stack Requiresdocker.service Afterdocker.service network-online.target Wantsnetwork-online.target [Service] Typeoneshot RemainAfterExityes WorkingDirectory/opt/hermes-agent ExecStart/usr/bin/docker compose up -d ExecStop/usr/bin/docker compose down TimeoutStartSec300 [Install] WantedBymulti-user.targetTypeoneshot配合RemainAfterExityes是标准做法因为docker compose up -d执行完就退出了但服务状态要保持“活跃”。TimeoutStartSec300给足启动时间ARM 上拉镜像和启动服务可能比较慢。启用并启动sudo systemctl daemon-reload sudo systemctl enable hermes.service sudo systemctl start hermes.service验证状态sudo systemctl status hermes.service看到active (exited)就对了。这时候你重启机器服务也会自动起来。提示systemd 的日志用journalctl -u hermes.service -f查看比 docker logs 更全能看到服务启动阶段的报错。排查开机自启失败的问题时这个命令是首选。3.4 反向代理与 HTTPS 接入直接暴露 8080 端口不太优雅也不安全。我用 Nginx 做反向代理顺便配上 HTTPS。安装 Nginxsudo apt install -y nginx配置站点sudo vim /etc/nginx/sites-available/hermes内容server { listen 80; server_name your-domain.com; location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 300s; } }proxy_read_timeout 300s这行很重要。AI 助手的响应时间可能比较长默认 60 秒容易超时断开。设成 300 秒给足余量。启用站点并重载sudo ln -s /etc/nginx/sites-available/hermes /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginxHTTPS 证书我用的是 Lets Encrypt 的 certbot自动签发和续期sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d your-domain.comcertbot 会自动改 Nginx 配置加上 443 监听和证书路径。续期也是自动的systemd 里有个 timer 会定期跑。验证一下sudo certbot renew --dry-run看到 “Congratulations” 就说明续期配置没问题。4. 常见问题与排查技巧实录4.1 服务起不来按这个顺序排查服务起不来是最常见的问题我整理了一套排查顺序照着走基本能定位。第一步看 systemd 状态sudo systemctl status hermes.service如果显示failed看下面的错误信息。常见的是WorkingDirectory路径不对或者docker compose命令找不到。第二步看容器状态docker compose ps -a-a会显示已退出的容器。如果某个容器状态是Exited (1)说明它启动后崩溃了。第三步看容器日志docker compose logs --tail100 服务名--tail100只看最后 100 行避免日志太多刷屏。重点找Error、Exception、Traceback这些关键词。第四步进容器手动跑docker compose run --rm 服务名 /bin/bash进去之后手动执行启动命令看报什么错。这一步能排除掉环境变量、配置文件路径之类的问题。我把常见错误和对应解法整理成表错误现象可能原因解决方法exec format error镜像架构不匹配换 ARM 镜像或加--platformConnection refused依赖服务没起来检查depends_on和启动顺序Permission denied挂载目录权限不对chown改属主或调容器用户OOMKilled内存不足加 swap 或限制容器内存port already in use端口被占用netstat -tlnp查占用进程4.2 内存不够用怎么办swap 与资源限制ARM 免费实例的内存虽然给得多但跑模型时还是容易吃紧。我遇到过 Ollama 加载模型时被 OOM Killer 杀掉的情况日志里能看到Killed字样。加 swap 是最直接的缓解办法sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstabfallocate比dd快得多推荐用这个。加到/etc/fstab里保证重启后自动挂载。调整 swappiness让系统更愿意用 swapsudo sysctl vm.swappiness60 echo vm.swappiness60 | sudo tee -a /etc/sysctl.conf默认值 60 其实就够用如果你内存特别紧张可以调到 80但太高会影响性能因为 swap 在磁盘上读写比内存慢几个数量级。给容器加内存限制防止单个服务吃光所有内存services: ollama: deploy: resources: limits: memory: 8G这样 Ollama 最多用 8GB超了会被限制而不是拖垮整台机器。注意swap 只是缓冲不是解决方案。如果你发现系统频繁使用 swap说明内存是真的不够了该考虑升级实例规格或者换更小的模型。长期依赖 swap 跑服务性能会差到没法用。4.3 网络访问不通的排查思路服务在本地跑得好好的外网就是访问不了这种问题我遇到过好几次原因各不相同。先确认服务本身在监听curl http://localhost:8080如果本地能通说明服务没问题问题出在网络层。检查防火墙sudo ufw status sudo iptables -L -nUbuntu 默认 ufw 是关闭的但如果你开过得放行对应端口sudo ufw allow 80/tcp sudo ufw allow 443/tcp检查 Oracle Cloud 的安全列表。这是最容易漏的一步。登录控制台找到实例对应的子网在安全列表里加入站规则。源 CIDR 填0.0.0.0/0表示允许所有来源端口填 80 和 443。检查 Nginx 配置sudo nginx -t sudo tail -f /var/log/nginx/error.lognginx -t检查语法error.log 看具体报错。常见的是proxy_pass地址写错或者 upstream 服务没起来。用外部工具验证。我常用的是在另一台机器上curl -v或者用在线端口检测工具确认端口从外部是否可达。如果外部不通但本地通基本就是防火墙或安全列表的问题。4.4 模型响应慢的优化经验本地模型响应慢是 ARM 实例的固有短板但通过一些调整能明显改善。限制上下文长度。Hermes 默认可能保留很长的对话历史每次请求都把全部历史发给模型token 数一多推理就慢。在配置里设max_context_tokens: 2048超出部分自动截断或摘要。启用流式输出。让模型生成一个 token 就返回一个用户感知上会快很多虽然总时间没变。Hermes 配置里找stream: true打开。模型量化。如果用的是 Ollama它默认拉取的模型已经是量化过的通常是 Q4。如果你想进一步压缩可以找 Q3 或 Q2 的版本速度更快但效果会打折扣。我的建议是 Q4 起步效果和速度平衡得比较好。减少工具调用轮次。Hermes 的智能体模式可能会多次调用工具再生成最终回答每一轮都是一次模型推理。如果发现响应特别慢看看日志里是不是工具调用太频繁。可以在配置里限制最大工具调用轮次比如max_tool_rounds: 3。把不常用的技能禁用。Hermes 启动时会加载所有技能定义技能多了会占用上下文。在配置里只启用你真正需要的技能减少 prompt 长度。4.5 数据备份与迁移的实操建议跑了一段时间积累的对话数据、配置、技能库这些都是有价值的得做好备份。SQLite 数据库备份最简单直接复制文件cp /opt/hermes-agent/data/hermes.db /backup/hermes-$(date %Y%m%d).db但注意复制前最好先停服务或者用 SQLite 的在线备份命令避免复制到写入一半的文件sqlite3 /opt/hermes-agent/data/hermes.db .backup /backup/hermes-$(date %Y%m%d).db配置文件备份把config目录整个打包tar -czf /backup/hermes-config-$(date %Y%m%d).tar.gz /opt/hermes-agent/config设置定时任务自动备份crontab -e加入0 3 * * * /opt/hermes-agent/scripts/backup.sh每天凌晨 3 点跑一次备份脚本。脚本里记得加上清理旧备份的逻辑别让磁盘被备份文件塞满。迁移到新机器时把备份文件拷过去解压到对应目录然后docker compose up -d就行。因为所有状态都在挂载的卷里容器本身是无状态的迁移很干净。提示Oracle Cloud 的免费实例如果长期不用可能会被回收。虽然官方说永久免费但实际有闲置回收策略。我的做法是让助手每天定时给自己发一条消息保持活跃。具体实现可以在 Hermes 里配一个定时任务每天触发一次自检。5. 技能扩展与日常维护心得5.1 给助手加技能的正确姿势Hermes 的技能系统是它比较有意思的地方。一个技能本质上就是一段可被调用的函数加上描述和参数定义。模型根据用户输入决定调用哪个技能。加技能有两种方式。一种是写代码在skills目录下建 Python 文件按框架的接口规范实现。这种方式灵活能做的事情多但需要写代码和测试。另一种是用配置文件声明适合简单的 HTTP 调用类技能填个 URL、方法、参数映射就行。我建议新手从配置式技能开始跑通了再尝试写代码。比如加一个“查天气”的技能配置里写清楚 API 地址和参数怎么从用户输入里提取Hermes 会自动处理调用和结果回传。写代码技能时有个坑要注意函数签名和文档字符串很重要。模型是根据文档字符串来判断什么时候调用这个技能的描述写得含糊模型就不知道该不该用。我的经验是描述里写清楚“什么时候用”和“什么时候不用”比只写“这个技能做什么”效果好得多。技能测试建议单独写测试用例别每次都通过对话去试。Hermes 一般提供了技能调用的测试接口直接传参数看返回结果比走完整对话流程快得多。5.2 日志监控与异常告警7×24 小时跑的服务不能靠人盯着。我配了一套简单的监控告警。日志轮转用 logrotate防止日志文件无限增长sudo vim /etc/logrotate.d/hermes内容/opt/hermes-agent/logs/*.log { daily rotate 7 compress delaycompress missingok notifempty create 0640 $USER $USER }每天轮转一次保留 7 天自动压缩旧日志。异常告警我用的是一个简单的脚本定期检查服务状态异常时发通知#!/bin/bash if ! curl -sf http://localhost:8080/health /dev/null; then echo Hermes 服务异常 $(date) | mail -s 告警 your-emailexample.com fi加到 crontab 里每 5 分钟跑一次。curl -sf的-f参数让 HTTP 错误码也返回非零退出码这样 4xx、5xx 都能被捕获。资源监控用htop手动看就行或者装个netdata做可视化。不过 netdata 本身也吃资源在免费实例上要权衡。我的做法是只在排查问题时临时开平时关掉。5.3 长期运行的经验教训跑了几个月踩过的坑总结几条。别频繁重启服务。每次重启 Hermes 都要重新加载模型和技能ARM 上这个过程可能要一两分钟。如果不是必须让它一直跑着。配置改了用热重载别动不动就 restart。定期清理对话历史。SQLite 数据库会越来越大查询变慢。我写了个脚本每月清理一次超过 30 天的对话记录保留最近的就行。清理前记得备份。关注磁盘空间。免费实例的磁盘通常只有几十 GB模型文件、日志、数据库加起来容易占满。设个阈值超过 80% 就告警。清理时优先删旧日志和旧备份模型文件如果不用了也及时删。模型更新要谨慎。Ollama 拉新模型会占额外空间而且新版本不一定比旧版本好。我一般先在测试环境验证确认没问题再更新生产。更新前备份配置万一新模型不兼容可以快速回滚。网络波动是常态。免费实例的网络质量不能跟付费的比偶尔会有延迟抖动。Hermes 调用远程 API 时如果超时配置里设好重试次数和退避策略别一次失败就报错给用户。这套方案跑下来一台闲置的 Oracle Cloud 免费实例确实能变成一个可用的 7×24 小时 AI 助手。成本是零维护工作量也不大每天花几分钟看看日志就行。如果你手里也有吃灰的云资源不妨试试这个思路把闲置算力利用起来。