企业官网建设流程全解析

闲置的 Oracle Cloud 免费机，能不能跑一个 7×24 小时在线的 Hermes Agent？

我先把结论放在最前面：能，而且能把这件事做得很稳。我最近把一台吃灰很久的 Oracle Cloud Always Free 实例翻出来试了一遍，跑的是 Hermes Agent 的常驻 bot 模式，连续在线了两周多，中途没有主动干预，进程也一直活着。Oracle Cloud 的免费 Arm 机器，4 核 OCPU 加 24GB 内存，拿来跑这种 AI Agent 框架，属于典型的“配置过剩”状态。这篇文章会从免费机选型、Hermes Agent 安装、bot mode 配置、Mem0 记忆接入、Obsidian 联动，最终到 systemd 保活与排障，把完整链路都捋一遍。如果你手里正好有台闲置的甲骨文免费机，想把它变成私人 AI 助理或自动化工作流节点，这篇可以直接照抄。

1. 项目起点：免费机跑 Agent 的可行性怎么看

1.1 Oracle Cloud Always Free 的硬件底子

Oracle Cloud 免费层里，最值得花心思的是 Ampere A1 实例。官方给出的 Always Free 配额是：最高 4 个 OCPU、24GB 内存，外加 200GB 块存储。这台机器的 CPU 是 ARM 架构，单核性能放在现在当然不算强，但跑常驻 Python 进程、HTTP 服务、向量数据库这些轻量负载，绰绰有余。真正会用到的性能高峰，也就是模型推理响应返回之后做文本处理那几十毫秒，平时 CPU 占用率基本趴在个位数。

对比一下同系列里那台 1GB 内存的 AMD 微型实例，你就明白为什么强烈建议用 Arm 机器。1GB 内存开机装完 Ubuntu，可用内存只剩 600MB 左右，而 Hermes Agent 要拉起 Python 运行时、第三方依赖库、模型驱动的工具链、记忆模块，实际占用轻松超过 1GB。真把 Agent 塞进 AMD 微实例，稍微跑一个浏览器自动化任务就会 OOM，连系统都可能卡死。Arm 实例的 24GB 内存才是能长期稳定运行 Agent 的底线配置。

磁盘上，免费额度给了 200GB 块存储，挂载之后用df -h能看到/分区有接近 200GB。对常驻 Agent 来说，代码和日志只占很小一部分，最占空间的是浏览器自动化产生的截图、临时文件，以及向量数据库的索引。只要做好日志和临时文件清理，这块存储三五年都用不完。

1.2 Hermes Agent 是什么，适合跑哪些任务

Hermes Agent 是一个开源的通用 AI Agent 框架，它的核心概念是把模型推理、工具调用、长期记忆、多代理协作和浏览器/计算机操作能力整合到一个统一入口里。你可以通过命令行直接和它对话，也可以让它跑在 bot mode 下，变成一个可以被 HTTP 请求调用的后台服务。v0.21 版本是 bot mode 比较成熟的一个节点，新版对常驻运行的支持明显更稳。

跑在 Oracle Cloud 免费机上，这个组合解决的是“个人 AI 助手长期在线”的真实需求。本地电脑不是不能跑 Agent，但你要保持开机、保持网络稳定、还得处理睡眠和休眠问题。免费云主机没有这些麻烦，它天然就是 7×24 在线，网络环境也相对稳定。实际能跑的任务包括：

• 定时抓取网页信息并整理成摘要，比如每天早上汇总几个技术站点的更新。
• 接收你从 Obsidian 笔记发来的任务指令，把回复写回笔记库。
• 作为团队共享的 AI 工具入口，通过 HTTP 接口被多个脚本调用。
• 用 CUA（Computer Use Agent）自动操作浏览器，完成登录、填表、巡检等流程。

这些任务里，定时信息采集和笔记联动是最好上手的两个场景，不需要额外硬件，也不需要 GPU，一台免费机就能全部消化。

1.3 可能踩坑的瓶颈点

“能跑”和“跑得好”之间，通常隔着三个实际问题。第一是模型从哪来。Hermes Agent 本身不带模型，它需要接入一个大模型后端来产生推理结果。如果你尝试在免费机上本地跑 7B/8B 模型，很快就会发现 CPU 推理慢到没法用，一个简单问题要十几秒甚至几十秒才返回，完全失去了 Agent 交互的流畅感。所以，比较合理的结构是：Agent 框架跑在免费机上，模型推理走云端 API，免费机只负责工具编排和流程控制。

第二是 API 费用。常驻 Agent 如果被频繁唤醒，token 消耗会悄悄涨起来。对策是调低空闲轮询的频率、给 Agent 设定精确的系统提示词，让它只在真正需要模型判断时才发起请求，避免无意义的闲聊式调用。

第三是进程保活。如果只是用 nohup 或 tmux 把 Hermes Agent 挂在后台，机器一旦重启或 SSH 会话断开，Agent 就再也起不来了。后面我会专门讲 systemd 守护方案，这才是 7×24 在线最核心的一环。

2. 从零部署：搭建一台可用的免费机环境

2.1 创建实例时容易被忽略的操作

在 Oracle Cloud 控制台创建实例，常规操作是导航到 Compute → Instances → Create instance，选择镜像 Ubuntu 22.04 或 24.04 LTS。SSH 密钥对要提前生成，私钥保存好，这是登录机器的唯一凭证。这里有两个细节很多人会忽略。

第一个是网络入站规则。Oracle Cloud 默认的安全列表往往只放行 22 端口，如果你打算让 Hermes bot 从公网访问，就得去 Networking → Virtual Cloud Networks 对应的 Security List 里，添加入站规则，允许 TCP 到 bot 服务端口（比如 8000）。来源地址可以填0.0.0.0/0，但更稳妥的是填你办公网或家庭网络的固定公网 IP。第二个是实例的引导卷大小，创建时默认给的可能是 50GB，记得调整到免費配额允许的更大容量，避免以后扩容麻烦。

创建完成之后，先确认 SSH 能通：

ssh -i ~/.ssh/oracle_key ubuntu@你的公网IP

登录成功后先做系统更新，这一步不要跳过。

2.2 系统基础与 Python 虚拟环境

SSH 登录后，依次执行：

sudo apt update && sudo apt upgrade -y sudo apt install -y git curl wget unzip python3-venv python3-pip

Ubuntu 24.04 默认 Python 版本是 3.12，Hermes Agent 当前版本对 3.10 到 3.12 都兼容，直接用系统 Python 建虚拟环境就行。我的习惯是把所有服务放在/opt/hermes目录下，方便管理：

sudo mkdir -p /opt/hermes sudo chown $USER:$USER /opt/hermes cd /opt/hermes python3 -m venv venv source venv/bin/activate

为什么要坚持用虚拟环境？因为 Hermes Agent 依赖的第三方库比较多，如果你后面又在同一台机器上部署别的 Python 项目，依赖版本冲突会让你头大。虚拟环境隔离之后，升级 Hermes Agent 或者装新工具都不会波及系统 Python。

2.3 安装 Hermes Agent 并验证模型链路

虚拟环境激活状态下，安装 Hermes Agent：

pip install --upgrade hermes-agent

装完先看版本：

hermes --version

如果输出类似Hermes Agent v0.21.x，安装就算成功了。接下来需要配置模型后端。我习惯用环境变量的方式管理配置，把模型提供方和密钥从命令行参数里剥离出来：

export HERMES_MODEL_PROVIDER=openai export HERMES_MODEL=qwen-plus export OPENAI_API_KEY=sk-xxxxx

这里HERMES_MODEL_PROVIDER=openai表示使用 OpenAI 兼容协议，实际的模型不一定非得是 OpenAI 官方模型。只要是兼容 OpenAI 接口的模型服务商，比如通义千问的开放平台、DeepSeek API，或者本地用 Ollama 起的 OpenAI 兼容端口，都可以这样接入。你只需要把HERMES_MODEL改成服务商对应的模型名，把 API Key 换成它家的 Key。

首次验证直接进入交互模式：

hermes -v

输入一句“你好，介绍一下你自己”。如果模型配置正确，Agent 会正常回复。到这里，最小闭环已经跑通：免费机 + Python 环境 + 云端模型 API，就是一个能对话的 AI Agent 了。

3. 把 Agent 变成常驻服务：配置、联动与实操

3.1 bot mode：让 Agent 变成 HTTP 服务

CLI 模式适合调试，但 7×24 小时在线必须靠 bot mode。Hermes Agent v0.21 的 bot mode 会将一个 HTTP 服务常驻在指定端口，其他程序可以通过 POST 请求向它发送任务。配置上，在/opt/hermes/config.yaml写入：

bot: enabled: true port: 8000 auth_token: 这里换成至少32位的随机字符串 model_provider: openai model: qwen-plus

auth_token 必须设置。常驻公网的服务如果不做认证，很快就会被互联网扫描器盯上，别人会往你的 Agent 里塞各种垃圾指令，白白消耗 API 额度。

启动 bot：

hermes --bot

看到类似HTTP server started on 0.0.0.0:8000的日志后，用 curl 验证：

curl -X POST http://127.0.0.1:8000/chat \ -H "Authorization: Bearer 你的token" \ -H "Content-Type: application/json" \ -d '{"text": "你好，请回答1+1"}'

能拿到回复，bot mode 就正常工作了。之后所有调用都走 HTTP 接口，这为外部系统集成打开了很大的想象空间。

3.2 长期记忆：让 Agent 真正“记得住事”

Agent 跑久了，最值钱的能力不是对话，而是记忆。Hermes Agent 的长期记忆模块底层依赖 Mem0 驱动的向量存储，它会把对话中值得保存的信息向量化，下次对话时自动召回。配置好之后，你可以先告诉它“记住我的工作目录是 /opt/hermes”，过几个小时再问“我的工作目录是什么”，它能答上来就说明记忆生效了。

免费机上跑记忆模块，需要注意存储选型。优先选轻量的本地向量存储（比如 ChromaDB），不要在 24GB 内存的机器上再堆一个沉重的数据库服务。本地存储占内存小，数据落盘后重启不丢，长期运行稳定性足够。如果你以后想做更复杂的跨 Agent 记忆共享，再考虑接入外部的向量数据库服务。

记忆模块让 Agent 从“每次对话都是新朋友”变成了“陪你合作很久的同事”，是免费机跑常驻 Agent 最值得投入时间的配置项之一。

3.3 CUA 与浏览器自动化：让 Agent 自己“动手做事”

CUA（Computer Use Agent）是 Hermes Agent 里比较有意思的一个特性，它能让 Agent 模拟鼠标键盘操作，驱动一个真实浏览器去完成登录、点击、填表、抓取数据这些动作。在免费机上，因为没有显示器，必须使用 headless 模式。

先安装 Playwright 依赖：

pip install playwright playwright install chromium playwright install-deps

最后一步install-deps很关键，它会把 Chrome 运行所需的系统库全部装齐，少了这步，之后启动浏览器大概率会报缺libnss3之类的问题。

配置好之后，你可以给 Agent 下达一个真实任务：“打开某个网站，提取页面标题和第一段正文”。它会自己拉起浏览器、访问页面、解析内容，再把结果整理回复给你。结合定时任务，这意味着免费机可以变成一个自动巡检工具，比如每天定时检查某个服务的状态页、抓取竞品价格变更、监测某个页面是否更新。

3.4 Obsidian 联动：笔记驱动 Agent 的实用玩法

在热搜词里，hermes agent obsidian 是很受关注的一个组合。本质上，Obsidian 联动并不是什么复杂魔法，就是让笔记软件往 Hermes 的 HTTP 接口发请求，再把回复写回笔记。

你可以利用 Obsidian 的 Templater 插件，写一个“发送到 Hermes 助手”模板。把选中文本作为任务内容发送到 bot，收到回复后自动插入当前笔记。这样你在记笔记时圈中一段文字，一键就能让 Agent 帮你总结、翻译或者扩展思路。常用的方式是写一个简易脚本做中转：

import requests HERMES_ENDPOINT = "http://你的公网IP:8000/chat" TOKEN = "你的token" resp = requests.post( HERMES_ENDPOINT, headers={"Authorization": f"Bearer {TOKEN}"}, json={"text": "请用中文总结这段内容: ..."} ) print(resp.json()["response"])

然后把这段逻辑封装进 Templater 的 JavaScript 或 QuickAdd 命令里。注意，很多人在这一步翻车是因为在本地 Obsidian 里写了 localhost:8000，请求打到了自己电脑上。正确做法是把地址换成 Oracle Cloud 实例的公网 IP，并确保安全列表和本地防火墙都放行了对应端口。

4. 7×24 稳定运行：运维、保活与安全

4.1 systemd 守护：不要再用 nohup 自欺欺人

这是整篇文章里我认为最重要的一节。很多人在免费机上用 nohup 或 tmux 挂 Agent，看着好像跑起来了，但机器一重启或者 SSH 会话断开，就再也找不到进程了。正确方案是把 Hermes Agent 托管给 systemd，让操作系统负责进程拉起、崩溃重启和日志收集。

创建服务文件/etc/systemd/system/hermes-agent.service：

[Unit] Description=Hermes Agent Service After=network-online.target Wants=network-online.target [Service] Type=simple WorkingDirectory=/opt/hermes EnvironmentFile=/opt/hermes/hermes.env ExecStart=/opt/hermes/venv/bin/hermes --bot Restart=always RestartSec=5 User=ubuntu [Install] WantedBy=multi-user.target

环境变量单独放在/opt/hermes/hermes.env：

HERMES_MODEL_PROVIDER=openai HERMES_MODEL=qwen-plus OPENAI_API_KEY=sk-xxxxx BOT_AUTH_TOKEN=你的token

启动并启用服务：

sudo systemctl daemon-reload sudo systemctl enable --now hermes-agent

以后进程因为任何原因退出，systemd 都会在 5 秒后自动拉起。查看运行状态和日志：

systemctl status hermes-agent journalctl -u hermes-agent -f

有了这层守护，才真正谈得上“7×24 小时在线”。

4.2 内存与磁盘的长期管理

24GB 内存看起来很充裕，但不能掉以轻心。常驻 Python 进程、Chromium 临时进程、向量数据库索引加在一起，内存占用会缓慢增长。特别是 Chromium 退出后，部分内存碎片并不会立刻归还给系统，日积月累可能逼近 OOM。

应对策略有两层。第一层是在 systemd 服务里加上内存约束：

MemoryMax=8G MemoryHigh=6G

第二层是配合系统监控，平时用free -h和htop观察趋势。磁盘方面，长时间开浏览器自动化会留下大量临时文件和日志，特别是 journald 的日志会默默涨大。定期清理：

sudo journalctl --vacuum-size=200M

同时调整 Hermes 配置，关闭自动截图保存，只保留最终结果输出，磁盘压力会小很多。

4.3 公网暴露与安全加固

常驻服务暴露在公网上，迟早会迎来扫描器的问候。如果你在 bot 配置里没有设置 auth_token，我几乎可以确定，第一晚就能看到来自陌生 IP 的垃圾请求。所以认证令牌一定要用足够长的随机字符串。

另外强烈建议关闭 SSH 密码登录。修改/etc/ssh/sshd_config：

PasswordAuthentication no

然后重启 SSH 服务：

sudo systemctl restart ssh

如果只是自己用，还可以在 VCN 安全列表里把 SSH 和 bot 端口的来源 IP 限制到你的固定公网 IP。这样即使扫描器看到端口，也无法建立连接。安全这件事不能靠运气，免费机因为零成本，反而更容易被攻击者当成批量扫描的目标。

5. 常见问题与排查速查

5.1 进程被 systemd 反复重启，日志里只有异常退出码

先看 journalctl 的详细输出：

journalctl -u hermes-agent -n 200

常见原因有三个：API Key 过期、依赖库与 Hermes 版本不兼容、配置文件里的模型名写错。逐个排查时，可以停掉 systemd 服务，在前台用 debug 模式启动：

systemctl stop hermes-agent /opt/hermes/venv/bin/hermes --bot -v

前台会直接打印详细报错，看到具体异常再对症处理。

5.2 对话响应越来越慢，一个请求要等十几秒

先判断瓶颈在模型 API 还是本机网络。连续请求同一个任务三次，如果每次都很慢且时间稳定，大概率是模型 API 本身的服务状态或限流问题。如果时快时慢，再检查免费机的网络延迟或是不是有多个进程在争抢资源。用htop看一下 CPU 占用，如果接近满载，再用journalctl确认是否有进程反复重启。

5.3 CUA 的 Chromium 启动失败，缺库报错

这个问题的根源几乎都是少了系统依赖。执行一次：

playwright install-deps

装完再试。如果还报缺某个具体库，再单独安装对应包。

5.4 Obsidian 和外部脚本请求超时

先确认三点：地址写的是公网 IP 而不是 localhost；Oracle Cloud 安全列表放行了对应端口；本地防火墙没有拦截出站请求。用 curl 从你的电脑请求一次 bot 的/health或/chat，能通就是配置正确，不通就用ss -tlnp从免费机上确认服务监听地址是不是0.0.0.0。

把常见问题整理成表格，方便对照：

6. 最后再说点心得体会

跑通这套免费机 + Hermes Agent 的方案之后，我自己的感受是，最大的门槛不是技术，而是愿不愿意把运维底子打扎实。systemd 守护、环境变量隔离、日志清理、密钥管理、网络放行，这些听起来不酷，但没有其中任何一项，你的“7×24 在线”都会变成“7×24 失联”。先把稳定运行的基础做牢，后面想扩展什么新玩法都顺理成章。

我还有一个个人小技巧：定期把 Hermes Agent 的配置文件和.env备份到本地仓库，这样即使免费机被回收或者误操作重装，也可以在半小时内重建整个服务，不会丢失长期积累的记忆数据和任务逻辑。

最后再分享一个我实测很舒服的场景：现在这台免费机每天早上 9 点自动整理前一日技术博客更新，中午接一次 Obsidian 发来的笔记任务，晚上把当天处理过的内容汇总写入日志库，全程不需要我打开电脑干预。如果你手里正好有闲置的 Oracle Cloud 免费机，建议今晚就动手试一次，先跑通最小闭环，再逐步加上记忆、自动化、浏览器操作这些进阶功能。