Hermes Agent 官宣上云了！两次点击 60 秒上线

#探寻人工智能，人与AI全新序章#

北京时间 7 月 8 日晚，Nous Research 发布了 Hermes 的新功能。

我第一反应是：这不是一个普通入口更新，而是 Hermes 用户门槛被明显往下压了一截。

注意需要有 10 美元的额度或订阅才能开启

以前很多人喜欢 Hermes，是因为它真的能干活：能跑任务、能接消息、能记忆、能学 Skill、能跑 Cron、能接 Webhook，还能通过 Gateway 挂在 Telegram、飞书、企业微信、微信这些入口上。

可问题也很现实。

Hermes 很强，但很多人卡在“让它稳定跑起来”。

本地跑吧，电脑会睡眠。Mac 一合盖，Gateway 可能失联。Windows 上还要关心终端、权限、服务、路径。放服务器吧，又要买 VPS、装环境、配端口、管进程、写 .env、处理模型 Key。团队一起用就更麻烦，谁能访问哪个 Agent，账单怎么算，生产 Key 谁能看，出了问题谁负责，都要自己想办法。

所以这次 Hermes Agent Cloud 的重点，不是“官方又做了一个网页入口”。

它真正解决的是：普通用户终于不用先学怎么养服务器，才能拥有一个常驻 Agent。

官方介绍的很直接：选一个模型，再选一个 server size（服务器规格），两次点击，约 60 秒后 Agent 就 live（上线）。如果是团队，还可以在 Nous Portal 里给组织成员开 Agent，配细粒度访问控制和统一账单。

这就意味着，Hermes 开始从“高手自建 Agent”走向“普通人也能开一个云端 Agent”。

这一步很关键。

这次到底变了什么？

官方宣传的 6 大功能

以前用 Hermes，大概有两条路。

第一条路，是本地跑。

你在自己的电脑上安装 Hermes，配置模型，开 Gateway，接 Telegram、飞书、微信，或者直接在 CLI 里用。这种方式最自由，成本也容易控制，但最大的问题是：它依赖你这台机器稳定在线。

第二条路，是自己上云。

你租一台 VPS 或者用其他云环境，把 Hermes 装进去，让它长期跑。这样解决了电脑睡眠问题，但你得会服务器运维。端口、防火墙、进程守护、日志、密钥、更新、备份、安全隔离，都要自己处理。

现在 Hermes Agent Cloud 出现以后，多了一条更简单的路：

你在 Nous Portal 里开 Agent。

模型自己选，服务器规格自己选。底层部署、常驻、资源管理，由云端平台来接住。

这个变化对新手特别重要。

很多读者其实并不是不想用 Hermes，而是不想先学一堆部署知识。尤其是 45 岁以上的普通 AI 工具用户，他们真正想要的是：我有一个 Agent，能长期在线，能定时做事，能收到外部消息，能在我睡觉时继续跑。

Cloud 版本正好把这个门槛往下拆。

你不需要先理解什么叫 systemd，不需要先研究 Docker，不需要先折腾 VPS。先开一个云端 Agent，让它活起来，再慢慢学习后面的高级配置。

这和以前“先部署，再使用”的顺序不一样。

它更像是：先让你用上，再让你慢慢变强。

为什么“两次点击、60 秒上线”很关键？

很多技术产品喜欢讲“能力很强”。

可对普通用户来说，真正决定他会不会试的，往往不是能力，而是第一步麻不麻烦。

Hermes 以前的第一步，对技术用户不算难，但对小白并不轻松。

你要打开终端，执行安装命令，确认路径，准备模型 Key，检查配置，启动 Gateway，再连消息平台。中间任何一步出问题，普通用户很容易就停住了。

现在官方把第一步压缩成两个动作：

选模型；

选服务器规格。

2 核CPU 0.32 美元/天

这件事的意义很大。

因为它把用户从“我先要搭好环境”，变成“我先开一个 Agent”。

比如你只是想测试 Hermes 能不能帮你每天整理 GitHub 热榜。以前你可能要在本地跑，电脑不能关，晚上不能断网。现在你可以先开云端 Agent，让它跑起来，再考虑要不要接飞书、Webhook 或 Cron。

比如你想让 Hermes 盯一个项目的 PR。以前你要先部署 Gateway，配 webhook 入口。现在至少有机会把入口和常驻能力都放在云端，少掉很多本地问题。

对真正做内容的人来说，这种变化也很重要。

以前你写“Hermes 很强”，读者可能会觉得离自己有点远；现在你可以写“60 秒开出一个云端 Agent”，读者的试用欲望会强很多。

技术圈喜欢能力，普通用户先看能不能上手。

Hermes Cloud 正好补的是这个口。

本地守 Gateway 的 4 个老麻烦

为什么我说“终于不用自己守 Gateway 了”？

因为长期用 Hermes 的人都知道，Gateway 是好东西，也是麻烦的来源。

第一个麻烦，是电脑睡眠。

你本地跑 Gateway，消息入口要靠它接收。电脑一睡，Agent 就像下线了。你让它晚上跑任务，结果第二天发现任务没动。之前写过 Mac 睡眠问题，就是这个逻辑。

第二个麻烦，是进程管理。

Gateway 不能只启动一次就不管。它可能因为配置错误、端口占用、网络断开、Key 失效而异常。你要会看日志，会重启，会判断到底是 Gateway 掉了，还是消息平台没连上。

第三个麻烦，是端口和网络。

Webhook、API Server、消息平台回调，经常涉及外部访问。你本地电脑在内网里，别人访问不到。要么你搞内网穿透，要么上 VPS。普通用户到这里就开始头大。

第四个麻烦，是密钥和权限。

Gateway 运行时要读模型 Key、消息平台 token、Webhook secret、工具凭据。你放在 .env 里也行，放在环境变量里也行，但时间一长，一定会乱。尤其是多个 Profile、多个 Agent、多个项目并行时，旧 Key、错 Key、串 Key 都会出现。

Cloud 版本不能神奇地消灭所有问题，但它至少把“进程常驻”和“运行环境”这两件事交给平台统一处理了。

这对普通用户来说，就是少踩一大半坑。

本地版适合折腾和深度控制，云端版适合先稳定跑起来。

最适合放到 Cloud 的 6 种场景

这篇最适合给读者讲清楚：什么任务值得上云？

我觉得先看 6 种场景。

第一种，夜间 Cron 自动化。

比如每天早上 6 点生成 AI 简报，晚上 11 点整理日报，凌晨跑一次资料归档。本地电脑关了就没法跑，云端 Agent 更适合这种长期定时任务。

第二种，Webhook 事件处理。

GitHub PR、监控告警、数据库变化、表单提交、支付回调，都可以通过 Webhook 主动打到 Hermes。如果 Webhook 入口放在云端，就不用折腾本地端口和内网穿透。

第三种，消息机器人常驻。

Telegram、飞书、企业微信、微信、Slack、Discord 这些入口，都需要 Agent 长期在线。云端常驻更符合这种使用方式。

第四种，团队成员各自一个 Agent。

团队里每个人都有不同任务。有的人做代码，有的人做运营，有的人做项目管理。Cloud 版本如果能在组织里统一开 Agent，再配访问控制和账单，就更像正式团队工具。

第五种，长任务后台跑。

比如资料整理、日志分析、项目扫描、批量生成报告、长时间搜索。你不想一直开着电脑等它跑完，放云端更自然。

第六种，隔离沙箱跑高风险任务。

本地电脑里有私人文件和主账号。很多任务不适合让 Agent 直接碰。云端如果有隔离环境，至少能把风险和本地机器分开。

这 6 种场景有一个共同点：它们都需要“Agent 长期在线，随时接任务”。

这正是 Cloud 的价值。

团队场景为什么更有感觉？

个人用户看重的是省事。

团队用户看重的是管理。

截图里提到两个关键词：granular access controls（细粒度访问控制）和 unified billing（统一账单）。这两个词非常重要，因为它们说明 Hermes 开始往团队可用方向走。

一个团队里，不可能所有人都共用一个 Agent。

也不应该所有人都能看所有会话、用所有工具、调所有 Key。

比如代码团队可以有代码 Agent，运营团队可以有数据 Agent，管理层可以有汇总 Agent。每个 Agent 能访问哪些数据，能调用哪些工具，能不能执行命令，能不能看生产环境，都应该分清楚。

统一账单也一样。

个人折腾时，模型费用花多花少自己承担。团队里如果每个人都拿自己的 Key 到处跑，很快就会乱。谁花了多少，哪个 Agent 消耗最高，哪个任务值得保留，都需要统一管理。

Hermes Cloud 如果把这些能力放进 Nous Portal，就说明它不再只服务个人玩家。

它开始有“公司里能不能用”的味道。

这也是为什么我觉得这次更新值得写。

因为一个 Agent 工具真正走向长期使用，迟早要过三关：

权限；

账单；

审计。

Cloud 版本就是在补这三关。

Cloud 不是本地版的替代，而是多了一种选择

这点要讲清楚。

Hermes 上云以后，不代表本地版就没价值了。

本地版仍然适合很多场景。

比如你处理特别私密的资料，不想放到云端；你要操作本地文件系统；你要连接内网服务；你要做高风险实验；你要深度自定义后端和工具链。那本地或自建服务器依然更合适。

云端版适合另一类任务。

比如常驻消息机器人、定时任务、团队协作、Webhook 入口、长时间后台处理、普通用户快速试用。

所以更准确的选择方式是：

本地 Hermes：适合私密、本地文件、高控制、高折腾自建 VPS：适合懂服务器、想省钱、想掌控环境Hermes Cloud：适合快速上线、长期常驻、团队协作、少折腾

我最建议的搭配是：

本地做调试和敏感任务；

Cloud 做常驻和自动化任务；

高风险任务放沙箱或隔离环境。

这样既不把所有东西都交给云端，也不把自己困在本地电脑上。

真正成熟的 Agent 工作流，往往不是只选一种部署方式，而是按任务风险和运行时长来拆。

别急着全迁：4 个坑先想清楚

云端很香，但不能一上来就把所有东西都搬过去。

第一，费用。

截图里提到选 server size。服务器规格越高，长期运行成本可能越高。模型调用也有费用。云端 Agent 最容易让人忘记的一点是：它一直在线，任务也可能一直跑。

所以要先想清楚：哪些任务值得常驻，哪些任务只适合临时开。

第二，密钥。

上云以后，Key 更不能乱放。模型 Key、GitHub Token、飞书机器人凭据、数据库连接字符串，都要分权限、分环境、分 Agent。最好接上前面写过的多 Vault / 密钥总管思路。

第三，数据。

不是所有数据都适合进云端。客户资料、公司代码、内部日志、财务信息，必须先判断能不能给云端 Agent 看。哪怕是官方平台，也要按自己的数据安全要求来。

第四，权限。

团队里每个人能做什么，要提前定。能不能执行命令？能不能访问生产 Key？能不能看其他人的 session？能不能启用高风险工具？这些问题不能等出事以后再补。

所以我对 Hermes Cloud 的态度是：值得试，但别盲目迁。

先从低风险、高频、常驻的任务开始。

比如 AI 简报、公开资料整理、GitHub 通知、Web 搜索、非敏感监控、日常提醒。等你跑顺了，再考虑更复杂的团队自动化。

我会怎么用 Hermes Cloud？

如果是我来用，我不会一上来把所有 Hermes 都搬到云端。

我会分三层。

第一层，云端常驻层。

放那些需要 24 小时在线的任务：Cron 简报、Webhook 通知、消息机器人、低风险资料整理、公开项目监控。这些任务不值得让本地电脑一直开着。

第二层，本地控制层。

放那些涉及本机文件、私密资料、本地账号、个人工作目录的任务。比如整理本地文档、操作本地代码仓库、处理私密笔记。这些留在本地更安心。

第三层，隔离实验层。

放那些可能乱跑、可能改文件、可能执行命令的任务。可以用 Docker、云沙箱或者临时环境，跑完就销毁，别让它碰长期环境。

这样拆开以后，Cloud 的价值就很清楚了：

它负责“稳定在线”；

本地负责“私密控制”；

沙箱负责“风险隔离”。

这比把 Hermes 当成一个固定工具更合理。

Hermes 越来越像一个 Agent 系统，不再只是一个聊天程序。不同任务需要不同运行位置，这才是长期用下去的思路。

干货提炼

这次 Hermes Agent Cloud 的重点，可以用一句话概括：

Hermes 终于不用只靠你自己守着 Gateway 了。

以前要长期跑 Hermes，你得处理电脑睡眠、Gateway 常驻、端口暴露、服务器部署、消息平台连接、Key 管理、权限隔离这些事。

现在云端版把第一步简化成：选模型，选服务器规格，快速开 Agent。

这对普通用户很重要，因为很多人不是不想用 Hermes，而是卡在部署和常驻。

最适合放到云端的，是这 6 类任务：

夜间 Cron 自动化Webhook 事件处理消息机器人常驻团队成员各自一个 Agent长任务后台运行隔离沙箱跑高风险任务

最需要注意的，是 4 个坑：

费用：云端常驻会产生成本密钥：Key 要分权限、分环境、分 Agent数据：敏感资料不要随便丢给云端权限：团队成员能做什么必须提前设清楚

我的判断是，Hermes Cloud 会明显降低新手门槛，也会让团队更容易试用 Hermes。

以前 Hermes 更像高手手里的强工具。

现在它开始变成普通人也能开出来的云端 Agent。

这一步走完以后，Hermes 的主线就更清楚了：本地负责自由和私密，云端负责常驻和协作，沙箱负责安全和隔离。

真正的 Agent 工作流，正在从“我电脑上跑一个助手”，变成“我在不同地方部署一组能长期工作的 Agent”。