广交会
93.8M · 2026-04-01
这两周 AI Agent 圈里一个很明显的变化，是大家不再只盯着“模型能不能调工具”，而开始盯“这个 Agent 能不能长期跑、跨平台跑、带记忆跑、带安全边界跑”。Hermes Agent 正好踩中了这个窗口。它不是又一个聊天壳子，而是一套带学习闭环、消息网关、技能系统、MCP、Cron 和安全隔离的完整运行时。本文把它为什么会火、强在哪里、适合谁用、有哪些坑，一次讲透。
过去一年，很多开源 Agent 项目看上去很热闹，但真到工程落地时，往往会卡在几个老问题上：
Hermes Agent 这次被大量讨论，不是因为它又包装了一个“会调工具的模型”，而是因为它把 CLI、消息平台、技能、记忆、MCP、Cron、容器隔离和训练数据链路串成了一套系统。GitHub 当前公开数据已经到了 19.4k Star、2.3k Fork，最新版本 v0.6.0 也是 2026 年 3 月 30 日刚发。
Hermes Agent 的 README 里有一句很关键的话：它是一个 self-improving AI agent。这个说法不只是营销标签，它背后对应了几层真正有工程含义的设计：
这意味着它切的不是“聊天体验”这一层，而是 Agent Runtime 这一层。
官方最快安装方式是：
curl -fsSL | bash
source ~/.bashrc
hermes
几个最关键的入门命令也都很直白：
hermes # 启动交互式 CLI
hermes model # 选择 provider 和 model
hermes tools # 配置启用的工具
hermes setup # 跑完整初始化向导
hermes gateway # 启动消息网关
hermes doctor # 诊断环境问题
hermes update # 更新到最新版本
如果你是 Windows 用户，要注意一个硬约束：原生 Windows 目前不支持，官方推荐 WSL2。这一点不是小细节，而是第一类最容易踩的安装坑。
你可以直接从两件事验证它不是“又一个 demo agent”：
这已经不是简单的 prompt 工程项目规模了。
很多 Agent 项目最大的问题不是功能少，而是所有功能都堆在一个模糊的大循环里。结果就是：
Hermes 的架构文档把它拆得很明确。高层结构里至少有这些主要子系统：
这套拆法的价值在于，它已经不再把 Hermes 理解成“一条 OpenAI-compatible ch@t loop 加几个 tools”，官方架构文档也明确说，旧的 mental model 已经不够用了。
如果你要快速理解它的系统边界，建议按官方推荐顺序读：
这比直接翻 README 更有效，因为 README 负责告诉你它能做什么，架构文档才负责解释它为什么能长期跑。
有几个配置点特别值得留意：
其中最关键的是 approvals.mode。它直接决定你的 Agent 是更像实验环境，还是更像可控的生产系统。
官方对架构的定义非常克制，设计主题里反复强调几件事：
这套表述很工程，不像空泛愿景。它说明 Hermes 团队在意的不是“演示是否惊艳”，而是“跑久了会不会坏”。
很多人第一次看到 Hermes，会先被“多平台”“多工具”“很多命令”吸引，但这些其实不是最核心的差异。真正拉开差距的，是它把 Agent 的长期运行问题直接放进了主线能力里。
从官方 README、架构文档和安全文档综合看，Hermes 至少有 4 个特别能打的点。
第一，是闭环学习能力。
官方给出的描述包括：从经验中创建 skill、在使用过程中改进 skill、把知识往持久记忆里推、跨会话搜索历史、用 Honcho 做更深的用户建模。很多 Agent 也在说 memory，但 Hermes 更像是在做 procedural memory，不只是存聊天摘要。
第二，是统一入口，不是单点入口。
它不只是一套 CLI。官方已经明确支持 CLI 和 messaging gateway 两类入口，而且很多 slash command 是共享的。你在终端里用 /model、/compress、/skills，在消息平台里也能延续这套操作模型。
第三，是远程执行环境不是补丁，而是主路径。
它支持 local、Docker、SSH、Daytona、Singularity、Modal 六类后端。官方甚至直接写了：你可以把它跑在 5 美元 VPS、GPU 集群，或者空闲时几乎不花钱的 serverless 基础设施上。这一句的含义很大，说明它从一开始就没打算把 Agent 绑在开发者笔记本上。
第四，是研究链路已经接上了。
Hermes 不只做“调用模型+工具”，它还带 batch trajectory generation、RL environments、trajectory compression。这意味着它不只是给用户用，也在给下一代 tool-calling 模型准备训练数据和评测环境。
这四点都能从官方资料直接对上：
这不是功能堆砌，而是产品方向很清楚。
Agent 一旦接 terminal、browser、MCP、消息平台，最大的风险就不再是“回答得够不够聪明”，而是：
很多项目会在这里说一句“请自行注意安全”。Hermes 没这么处理。
官方安全文档给的是五层防线：
这五层里最关键的是第二层和第三层。
审批系统支持 manual、smart、off 三种模式；危险命令命中规则后，CLI 会要求 once、session、always、deny 四种确认方式。YOLO 模式也有，但官方写得非常直白：这会跳过所有危险命令审批，只适合可信环境。
如果你准备认真部署 Hermes，最少要做到下面这些：
approvals:
mode: manual
timeout: 60
terminal:
backend: docker
security:
tirith_enabled: true
然后再补几条生产环境动作：
GATEWAY_ALLOW_ALL_USERS=true 直接开到生产~/.hermes/.env 做 chmod 600Hermes 在安全细节上做得比多数 Agent 项目认真，至少有这些可验证点：
这一套做完，Hermes 才有资格往“长期在线 Agent”那个方向走。
看到 19k Star，很多人第一反应是“我要不要马上用它替掉现在的 Copilot/工作流”。这个判断如果太快，通常会出错。
Hermes 明显更适合下面三类人：
但它不太适合两类用户：
如果你想低成本判断 Hermes 适不适合自己，我建议按这个顺序试：
hermes doctor、hermes model、hermes tools不要一上来就把所有入口、所有工具、所有平台一起开，这会把排障复杂度拉满。
官方 release v0.6.0 已经说明它在快速扩张：Profile、MCP Server Mode、Docker、Feishu、WeCom、Slack 多工作区、Webhook、Provider Failover 都在短时间内上了。这说明它很强，也说明它变化很快。对普通用户来说，最稳的用法不是一步到位，而是分层启用。
原因：
解决：
wsl --install
curl -fsSL | bash
source ~/.bashrc
hermes
原因：
解决：
--yolo原因：
解决：
hermes pairing list
hermes pairing approve telegram ABC12DEF
或者在 ~/.hermes/.env 里配置平台 allowlist。
hermes doctor如果你真想判断 Hermes 是不是下一阶段该投入的 Agent 基座，不要先看它能不能“写一段惊艳代码”。今天就做三件事：
这样你一天之内就能看清，它到底是适合你当前工程阶段的生产工具，还是只适合继续观望的前沿项目。
Hermes Agent 这波热度，不只是因为功能多，而是因为它终于把 Agent 从“模型会不会调工具”推进到了“系统能不能长期跑”。这一步，比再出一个更聪明的 prompt 有价值。真正值得看的，不是它会不会再涨多少 Star，而是它已经把下一代 Agent 基础设施该长什么样，提前摆在了桌面上。
