Hermes Agent：一个会自己长出技能的 24/7 个人 AI
flowchart LR
A["Hermes Agent"]
A --> B["分类：智能体 (Agents)"]
A --> C["关键词：Hermes"]
A --> D["关键词：Skills"]
A --> E["关键词：Self-Improving"]
A --> F["关键词：MCP"]2026 年初 Nous Research 把 Hermes Agent 推到 GitHub。短时间内 stars 数从零冲到接近十万，已经超过了大多数 2024–2025 年里被反复提起的 Agent 框架。截至 2026-04-16 已发到 v0.10.0（Tool Gateway release）。它的有趣之处不在于又发明了一种 prompt 模板，而在于：它把「持续运行 + 自动长出技能 + 多平台接入 + 模型自由切换 + 一站式工具集成」第一次以一个开箱即用的形态做了出来。
延伸阅读：
这篇文章会讲什么
Agent 这两年最尴尬的事情是：研究侧不断推出新论文（ReAct、Reflexion、Voyager、CAMEL、Generative Agents），但工程侧大多数人手里跑的，仍然是「ChatGPT + Function Calling + 几行胶水代码」。中间有一道很真实的鸿沟：
- 论文里的 Agent 在 sandbox 里能跑 1000 步；
- 工程里的 Agent 只要超过 5 步，就开始幻觉、超时或崩。
Hermes Agent 这次在社区里激起的回响，不是因为它「更聪明」，而是因为它把工程化的几个老问题在同一个项目里同时解决得还不错：
- 谁在持续运行？——有 gateway 守着，连 Telegram、Slack、Discord、Matrix、Signal、Mattermost、飞书；
- 长任务怎么不被超时砍掉？——基于活动而非 wall-clock 的 inactivity timeout；
- 模型坏了怎么办？——
/model命令热切换 provider，OpenRouter / Nous Portal / 本地 Ollama 都行； - 危险操作怎么管？——Slack/Telegram 原生按钮做人工 approval；
- 长期记忆怎么落？——三层结构 + 一组可插拔 memory provider；
- 怎么让 Agent 一周后比一周前更强？——自动从执行轨迹里抽 skill，写到
~/.hermes/skills/，下次自动检索复用。
这篇文章不会逐行讲它的代码，而是回答一个更有用的问题：
作为一个想自己跑 Agent 的开发者或团队，Hermes Agent 给我们提供了哪些过去得自己造的能力，又在哪些地方仍然需要小心。
先给一个判断：Hermes Agent 是「Agent OS」方向上目前最完整的开源样本
先看定义：Hermes Agent 不是一个新的 Agent 推理算法，而是一个把 Agent 当成「需要长期跑的进程」来设计的运行时系统。
如果你把 2023–2024 的 Agent 框架划成两类：
- 一类是 库：LangChain、LlamaIndex、AutoGen、CrewAI、LangGraph，给你乐高块，你自己拼；
- 一类是 应用：AutoGPT、BabyAGI、Devin、Cursor，给你成品，你按它的方式用；
那 Hermes Agent 想填的是中间层：Agent 运行时（Agent Runtime / Agent OS）——你不需要从 prompt 一行行写，但它也不锁死你成某种特定产品形态，而是给你一个常驻进程 + 一组协议 + 一个技能库。
这种定位过去最接近的项目是 OpenClaw 这类「个人 AI 助手」，但 Hermes Agent 在三个点上明显走得更远：
| 维度 | 传统 Agent 库 | 传统 Agent 应用 | Hermes Agent |
|---|---|---|---|
| 运行形态 | 你自己起进程 | 通常是 Web 应用 | 常驻 daemon + 多 gateway |
| 模型层 | 由你接 | 多数锁死 1–2 家 | 跨 provider 热切换、aggregator-aware |
| 技能积累 | 看你怎么写 | 一般没有 | 自动从执行中抽 skill 文件 |
| 多平台 | 自己接 | 通常单平台 | Telegram/Discord/Slack/Matrix 等内置 |
| MCP 生态 | 看插件成熟度 | 多数是私有协议 | OAuth 2.1 PKCE + OSV 扫描 |
我的看法是：它是目前为止离「Agent OS」概念最近的开源实现。这并不是说它的代码已经完美，而是说它的设计假设是对的——把 Agent 当作一个长期生存的实体，而不是一次性的对话。
它解决的真问题：为什么 Function Calling + ChatGPT 不够
很多人会问，为什么我已经有一个能 function calling 的强模型，还需要 Hermes 这种东西？要回答这个问题，最直接的方法是把现实里跑过 Agent 的人都踩过的那些坑列出来：
坑 1：进程要么常住，要么每次冷启动
如果你的 Agent 是「一个 HTTP 接口，每次请求新建一个上下文」，它没办法做以下事情：
- 后台跑一个 30 分钟的爬虫，跑完通知你；
- 凌晨 3 点定时检查告警；
- 接收 Webhook 然后立刻响应；
- 在 Slack 一个 thread 里持续回复，几天后再回复仍然记得当时上下文。
Hermes Agent 把它定位成一个常驻服务，所有平台的消息进来都进入同一个 agent runtime。Release notes 里专门提到「inactivity-based agent timeouts 取代 wall-clock timeouts」，这是一个对长任务非常关键的小决定：只要 Agent 还在活跃地调用工具，它就不会被砍。
坑 2：模型质量在不同任务上差别巨大，但你不想为此重写代码
2026 年模型层早就不是「选一个最好的就够」的状态了：
- 视觉任务你可能更想走 Gemini 2.5；
- 长上下文工程改动你可能更想走 Claude Sonnet 4.6；
- 推理密集型 benchmark 你可能更想走 GPT-5.4 或 DeepSeek R1；
- 高频低成本辅助任务你可能更想走 MiMo v2 Pro 或 Kimi K2.5。
Hermes Agent 的 /model 命令支持在会话中间热切换 provider 和模型，CLI、Telegram、Discord、Slack 都能用。更细的一个点是「aggregator-aware resolution」：如果你登录的是 OpenRouter 或 Nous Portal，它会优先在同一个 aggregator 内解析模型，必要时再跨 provider fallback。这个设计意味着：你的会话上下文不会因为换模型而丢失。
坑 3：长期记忆是 Agent 的瓶颈，而不是亮点
绝大多数 Agent demo 都假设「上下文窗口够大就够了」。这件事在生产环境里经不起一个礼拜的考验。Hermes Agent 在 v0.8 里同时挂了 Supermemory、Honcho、mem0、Hindsight、RetainDB、OpenViking、ByteRover 等多种 memory provider，并且把 user_id、profile、tenant scoping 等纠结的工程问题做了基础抽象。
这里值得抽出来单独讲的，是它的 三层记忆结构：
| 层级 | 内容 | 实现方式 |
|---|---|---|
| 短期上下文 | 当前任务的 in-context memory | 标准 prompt 上下文 |
| Skills | 过往任务沉淀的可执行步骤 | Markdown 文件 + FTS5 全文检索 |
| 用户模型 | 跨会话的用户偏好、风格、关系 | Honcho 等专用 provider |
这种分层不是发明出来的，而是从大量 Agent 工程经验里逼出来的：纯向量 + 一锅 RAG 不够用，得分清「事实」「过程」「偏好」三种东西。
坑 4：危险操作和审批是个隐形大坑
Function Calling 让 LLM 调工具变得简单，但「让它执行 rm -rf 之前先问一下我」这件事，从来都不简单：
- 在 CLI 里你可以 prompt 用户输入 y/n；
- 在 Telegram 里你怎么办？发一段「请回复 /approve」？
Hermes Agent v0.8 直接给 Slack 和 Telegram 加了 原生按钮 approval，Telegram 还附带 emoji reactions 表示状态。Slack 则保留了 thread context。这听起来是小事，但从 demo 走到「家里 7×24 跑」之间，正是这种细节决定能不能落地。
自我学习闭环：把执行轨迹写回成可重用 skill
先看定义：Hermes Agent 的 self-improving 不是 RL 微调，也不是 vector memory recall，而是「把这次任务的有效流程写成一个 markdown 文件，下次自动检索出来」。
这是 Hermes Agent 最常被讨论、也最容易被误解的部分。我把它拆成四个部件：
1. Agent-Curated Memory（自我策展记忆）
定时（按某种间隔）给 agent 一段内部 prompt，让它评估「最近这段活动里有没有值得保存的东西」。这是 curated，不是 dump：
- 不是把每条对话都向量化进数据库；
- 不是把所有工具调用都记下来；
- 而是 agent 自己判断「这段过程将来可能有用」。
2. Autonomous Skill Creation（自动技能生成）
当任务满足某些触发条件——比如调用了 5 次以上工具、出现并解决了错误、走过了非显然的工作流——agent 会主动在 ~/.hermes/skills/ 下创建一个 skill 文件。这些文件遵循 agentskills.io 标准，是 markdown，结构化但人可读。
举个具体例子：你让它「帮我把这个 repo 的 PR 整理成周报发到飞书群」。它跑通之后，可能写出这样一个 skill：
# 整理 PR 周报到飞书
## 触发
- 用户说「整理周报」/「PR 总结」
- 用户在仓库目录里
## 流程
1. 用 gh pr list --state merged --search "merged:>=$(date -v-7d ...)"
2. 按 author 分组，统计每人合并数
3. 对每个 PR 抽 title 和首行 body
4. 用 markdown 表格输出
5. 发送到 feishu webhook（注意先 strip MEDIA: tag）
## 注意
- gh 命令在 macOS 上 date 参数和 Linux 不同
- 飞书 webhook 内容超过 30KB 会被拒下次类似任务来的时候，agent 不需要从零摸索，而是先 FTS5 检索到这个 skill，然后照着做。
3. Skill Self-Improvement
技能在使用过程中会被打磨。如果某一步老是出错，agent 会更新这个 skill 文件，标注新的注意事项。这并不需要训练，只是文档的迭代——但它的杠杆比想象的大：因为它是被 agent 在执行环境里真实验证过的步骤，而不是某个文档作者拍脑袋写的「最佳实践」。
4. Cross-Session Recall
跨会话回忆用 FTS5 + LLM summarization 配合。FTS5 是 SQLite 自带的全文检索，本地、低延迟、不需要外部向量库；LLM summarization 用来在召回多个候选 skill 时帮助挑选并合并。
这种架构和向量 memory 有什么不同
| 维度 | 传统向量 memory | Hermes Skills |
|---|---|---|
| 单元 | embedding chunk | 完整可执行 skill |
| 检索方式 | cosine 相似度 | FTS5 + 语义重排 |
| 内容形态 | 任意文本 | 结构化 markdown，强调流程 |
| 生成方式 | 由系统按规则切片 | 由 agent 自己判断写出 |
| 复用方式 | 拼回 prompt 当背景 | 当作执行模板被遵循 |
这背后有一个比较深的认知差异：很多任务的「记忆」并不是事实，而是流程。「我上次怎么把它搞定」往往比「上次发生了什么」更有复用价值。Hermes 把这点讲明白了。
多平台 Gateway：Agent 不应该锁在一个聊天框里
Hermes Agent 的 Gateway 层支持的平台（截至 v2026.4.16，即 v0.10.0）：
| 平台 | 关键能力 |
|---|---|
| CLI | 主交互入口，TUI 风格，支持 /model 等命令 |
| Telegram | 原生按钮、emoji 反应、群 topic 绑定 skill |
| Discord | Slash commands、ignored_channels、no_thread_channels |
| Slack | Thread engagement、按钮审批、mrkdwn 编辑 |
| Matrix | E2EE、reactions、read receipts、CJK 输入 |
| Signal | MEDIA: 标签全支持 |
| Mattermost | 文件附件 |
| 飞书 (Feishu) | 交互卡片审批按钮 |
| iMessage（v0.9.0, 2026-04-13） | 在 macOS 桥接为入口 |
| WeChat / 微信（v0.9.0, 2026-04-13） | 桥接 |
| Termux / Android（v0.9.0, 2026-04-13） | 在 Android 上跑 Hermes Agent，让”Agent 装在手机上”第一次现实 |
| Webhooks | {__raw__} 模板、thread_id 透传 |
实践启示：这套设计反映了一个判断：Agent 的入口应该跟着用户，而不是把用户拉到一个新地方来。如果你的团队主战场在 Slack，强迫它换到一个新的 Web 界面才能用 Agent，迁移成本就足以杀死大部分采用动机。
v0.9.0 / v0.10.0 两个 H1 末关键发布
- v0.9.0 (v2026.4.13)，“The everywhere release”：把入口推到 iMessage / WeChat / Termux Android、Fast Mode 加速 OpenAI / Anthropic、background process monitoring、本地 web dashboard。Agent 真正变成”日常带在身上”
- v0.10.0 (v2026.4.16)，“Tool Gateway release”：付费 Nous Portal 订阅可以直接通过 subscription 访问 web search / image generation / TTS / browser automation，无需另外申请 API key。这是开源 Agent 第一次给”普通用户”准备好”开箱即用一整套工具”的形态
MCP 与插件：把扩展性做对了一次
先看定义：Model Context Protocol（MCP）是 Anthropic 在 2024 年底推出的开放协议，让 LLM 客户端可以以统一方式接入外部工具与数据源；2025–2026 已经事实上成为 Agent 工具生态的通用接口。
Hermes Agent 在 MCP 上做了几个值得抽出来的事情：
1. OAuth 2.1 PKCE
Hermes 是少数明确支持 MCP OAuth 2.1 PKCE 的客户端。早期 MCP server 多数靠 API key 或 bearer token，到了你想接公开市场上的服务（GitHub、Notion、Slack 等），缺少标准化授权流程会让事情很痛苦。OAuth 2.1 + PKCE 是这一层的事实标准。
2. OSV 漏洞库扫描
MCP 扩展包安装时会自动通过 OSV vulnerability database 做 malware / vulnerability 扫描。这是一个非常工程化但很重要的设计：MCP 的开放性意味着安全风险，社区里已经出现过恶意 MCP server 的案例。把扫描放在安装环节，比在运行时被动出事好得多。
3. 插件系统
Hermes 自身的插件 API 比 MCP 更深入，能做：
- 注册 CLI subcommand；
- 接收 request-scoped API hooks（带 correlation IDs）；
- 安装时 prompt 用户输入必需 env vars；
- hook session lifecycle 事件（finalize、reset）。
这些能力意味着插件不是「外挂工具」，而是真正参与到 agent 生命周期里。
Skills、Plugins、MCP 的边界
| 概念 | 适合做的事 | 不适合做的事 |
|---|---|---|
| Skill | 流程沉淀、上下文模板、领域 prompt | 重 IO、外部系统鉴权、长期连接 |
| Plugin | 改 agent 行为、加 CLI、做 lifecycle hook | 暴露给其他 agent 复用 |
| MCP server | 把外部系统抽成标准化工具 | 自己做复杂决策逻辑 |
理解这三者的边界，比记住每个的名字重要得多。
Hermes 4 / 4.3 模型：和 Hermes Agent 是什么关系
这里要纠正一个常见误解：
- Hermes 4 / 4.3 是 LLM：Nous Research 的开源大模型，2025 年 8 月推出 405B/70B/14B；2025 年 12 月推出 36B 的 4.3，基于 Seed-OSS-36B-Base，512K 上下文。
- Hermes Agent 是 Agent 运行时：可以用 Hermes 4.3，也可以用 GPT-5.4、Claude Opus 4.6、Gemini 2.5 Pro、DeepSeek R1、Kimi K2.5、Grok、Qwen3 等任意 provider。
两者同名同源，但定位完全不同。一个是「脑子」，一个是「身体 + 操作系统」。
不过 Hermes 4.3 有几个细节值得提一下：
Psyche 分布式训练
Hermes 4.3 是 Nous 第一个完全在 Psyche network 上 post-train 出来的生产模型。Psyche 用 DisTrO optimizer 让训练节点跨数据中心协作，由 Solana 链做共识。结果显示在等量配置下吞吐和传统集中式训练相当。这件事的意义不在「区块链」，在「让开源社区第一次有可能合伙训前沿模型」。
RefusalBench SOTA
Hermes 4.3 在 RefusalBench 上 SOTA，意味着它在「按用户价值做事而不是过度拒答」上做得不错。这对 Agent 场景非常重要：一个动不动拒答或者过度警告的模型，会让 Agent 走不到下一步。
36B 的甜点位
36B + 512K 上下文意味着它能用消费级 GPU（VRAM 比较够的型号）本地跑。如果你想让 Hermes Agent 完全脱离云 API 跑，4.3 是目前比较合适的搭档。
安装与基本使用：怎么一句话起一个
详细官方文档以 hermes-agent.nousresearch.com/docs 为准，这里只给你一个最短路径：
# 1. 安装（macOS/Linux 推荐 brew，或者直接用 release 二进制）
brew install nousresearch/tap/hermes
# 或者：
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | sh
# 2. 配置 provider（以 OpenRouter 为例，等同于 Nous Portal / OpenAI / Anthropic）
hermes auth openrouter
# 3. 启动 chat
hermes chat
# 4. 在 chat 里随时切模型
/model claude-opus-4.6
/model gpt-5.4
/model deepseek-r1
# 5. 看长期记忆里有什么
hermes skills list
# 6. 跑一个后台任务，做完通知
hermes run --notify "把 ./logs 下最近 7 天的错误归类总结"如果想接 Telegram、Slack 这些，需要额外配 gateway，过程是 hermes gateway add telegram 然后跟着向导走。
我自己的实践启示：第一次别开 yolo（自动批准所有），先用按钮 approval 跑一周，把 agent 的真实操作模式摸熟，再考虑放权。
它解决了什么、没解决什么
把它放在 2026 年 Agent 生态里，给一个比较克制的判断：
它真的解决的
- Agent 进程的工程化基线：常驻、超时、审批、日志、配置校验、跨平台
- 模型层抽象：跨 provider 热切换 + aggregator-aware
- 技能积累的可操作路径：不是讲 self-improving 的愿景，而是给了一个非常具体的实现
- MCP 的安全消费：OAuth 2.1 + OSV 扫描，是当前少数把这一块认真做的客户端
它还没解决的
- 真正的策略级 self-improvement：skill 是流程级的复用，不是「reasoning policy 自己进化」
- 多 agent 协作：subagent sessions 已经做了基础（subagent 隐藏在 session list 等），但完整的多 agent 协调机制仍在演进
- 复杂规划：长 horizon 任务依然受底层模型推理能力限制，agent runtime 解决的是周边工程而非核心智能
- 企业级合规：审计 trail、PII 处理、SSO、租户隔离等做了一些（cross-session isolation、credential leakage guards），但还不到 SOC2 / ISO27001 默认就能过的成熟度
它带来的真正认知变化
如果让我用一句话总结 Hermes Agent 在生态里的意义：
它把「个人 Agent」从一个 demo 形态，推到了一个可以真的当成日常工具长期跑的形态。
这个跨越的关键不是某个炫技功能，而是把许多过去「自己造也能造」但绝大多数人懒得造的工程问题，一次性给了一个开源默认实现。这件事的杠杆，可能比再发一个「比 ReAct 准确率高 3 个点」的论文更大。
与同类项目的对比
| 项目 | 定位 | 适合 | 不适合 |
|---|---|---|---|
| Hermes Agent | 多平台常驻 Agent 运行时 + skills 学习 | 想长期养一个 Agent 当主力工具 | 只想一次性跑个脚本 |
| OpenClaw | 自托管个人 AI 助手 | 注重隐私、家居自动化、家庭场景 | 团队级协作 |
| Letta（前 MemGPT） | Agent 平台，重在长期记忆 | 把记忆当作核心能力的应用 | 多平台分发 |
| LangGraph | Agent 编排库 | 需要精细控制状态机的研究 / 产品 | 想开箱即用 |
| AutoGen | 多 agent 对话框架 | 多角色协作场景 | 单 agent 长期运行 |
| CrewAI | 角色分工 + 流程 | 业务流自动化 | 个人 24/7 助手 |
| Cursor / Claude Code | IDE 内编码 Agent | 写代码 | 跨平台、跨任务的通用 Agent |
它们彼此并不互斥。一个比较实际的组合是：Cursor 写代码 + Hermes Agent 当跨平台日常助手 + 自有 LangGraph 做特定业务流。
给不同角色的实践建议
个人开发者
- 用它替代「ChatGPT 桌面 + 几个 shell 脚本」的组合；
- 把你常做的几件事（写周报、查日志、管 dotfiles、整理稿件）让它跑几次，看看
~/.hermes/skills/里长出来什么； - 接 Telegram，让它在你不在电脑前的时候也能用。
小团队 / Indie Hacker
- 把它接进 Slack / Discord / 飞书，作为团队级 Agent；
- 用 approval 按钮控制危险操作；
- 把团队规范沉淀成 skill 文件并 commit 到一个共享 repo，团队成员都能用同一份「集体经验」。
企业内部平台团队
- 别直接面向终端用户上 Hermes，把它当成参考实现；
- 把它的 gateway / approval / MCP OAuth / OSV scan 这几个设计借鉴到你自己的内部 Agent 平台；
- 如果要直接用，至少得加一层企业账号、SSO、审计与租户隔离。
研究者
- 它是观察「skill 自动生成」在真实使用中是否真的收敛、是否会发散的好样本；
- 也是观察 MCP 生态在工程上如何被消费的实测环境；
- 注意它的 skill 生成不是从 RL 来的，所以不要把它和 reasoning policy improvement 混淆。
风险与注意
最后说几个不那么乐观但需要诚实面对的点：
1. 自动技能生成 ≠ 总是好
Skill 写错了，下次会被遵循。错误的过程会被「沉淀」。这意味着：
- 早期需要人工 review skill 文件；
- 推荐把 skills 目录纳入版本控制，定期 audit；
- 关键任务别纯靠 skill 推断，仍然要保留显式的 standard operating procedure。
2. 长期运行 = 长期暴露面
一个 7×24 跑的 Agent，权限边界一旦设计错，受害面比一次性脚本大得多：
- 严格用最小权限原则；
- 不要把生产凭据塞给 agent，能用 short-lived token 就别用 long-lived；
- 定期检查
~/.hermes/logs/里的 errors.log。
3. 模型成本控制
跨 provider 自由切换很爽，但意味着你需要一个清醒的成本模型。否则一段时间后你会发现某个 provider 账单飞起。建议：
- 对每个 provider 配 monthly budget 限制；
- 把高成本模型只绑定在你显式提供「请用 reasoning model」的指令上；
- 利用免费层（Nous Portal 提供的 MiMo v2 Pro 等）做辅助任务。
4. 它仍然是早期项目
- 版本号 v0.x，意味着 API 与配置仍可能有 breaking change；
- 209 个 PR / release 的迭代速度意味着 release notes 必须读；
- 大量 issue 仍在解决（v0.8 解决了 82 个 issue，但还有持续输入）。
一张图收束：它到底改变了什么
过去：每个团队各自造
┌──────────┬──────────┬──────────┬──────────┐
│ 多平台 │ 长期记忆 │ 审批治理 │ 模型路由 │
│ 自己接 │ 自己拼 │ 自己写 │ 自己写 │
└──────────┴──────────┴──────────┴──────────┘
│
│ Hermes Agent 把这一层
│ 做成了开源默认实现
▼
现在：你只需要做差异化的部分
┌────────────────────────────────────────────┐
│ 你的领域 prompt + skill + 业务流 + 数据接入 │
└────────────────────────────────────────────┘一句话收束：Hermes Agent 没有发明新的 Agent 智能，但它第一次把跑一个 24/7 个人 Agent 所需要的工程基础设施做成了开源默认值——这件事的影响，可能比绝大多数 benchmark 上多几个点的新模型更深远。