Hermes Agent 指南：与你共同成长的开源 AI 智能体

Hermes 官方网站对该产品的描述非常犀利：它 不是 绑定到 IDE 的编程副驾驶，且 不是 围绕单一供应商构建的薄壳聊天机器人。其核心理念是一个安装在机器上的持久化智能体，你可以将其连接到首选的模型栈，并通过 CLI 或消息应用与之交流，而它会随着时间的推移在同一环境中持续工作。这比大多数开源智能体项目的定义更具野心。

1. 为什么它很重要

Hermes 之所以重要，是因为它直击智能体工具中最令人沮丧的痛点之一： 无状态性。大多数 AI 编程工具仅擅长处理单一会话、单一编辑器、单一提示词、单一供应商以及单一机器。Hermes 的构建基于一个不同的假设：真正有用的智能体应该是能够长期存在、积累工作知识，并能从多个界面访问的。

这就是为什么它的发布定位能引起共鸣。Nous Research's 在 X 上的公开公告将 Hermes 介绍为 “与你共同成长的开源智能体，” 官方文档也重申了同样的论点：持久化记忆、可重用技能、定时任务、远程执行和消息连续性是其核心价值主张，而非后期强加的额外功能。

2. Hermes 究竟是什么

根据 GitHub 仓库 以及 官方网站，Hermes 是由 Nous Research 开发的采用 MIT 许可证的智能体框架，可以运行在本地、VPS 或容器化及云端支持的执行环境中。

快速入门文档还提到了另一个重点：Hermes 是 模型无关的。文档中支持的供应商列表涵盖了 Nous Portal、OpenAI Codex、Anthropic、OpenRouter、DeepSeek、GitHub Copilot、通过 OAuth 接入的 Gemini、自定义 OpenAI 兼容端点等。切换供应商被视为一种配置，而不是产品的分支。

在架构上，它也表现出对大上下文模型的强烈偏好。快速入门警告称，Hermes 至少需要 64K 的上下文窗口，因为它专为多步工具调用工作流、持久化上下文以及比简单的自动补全式智能体更长的任务周期而设计。

这是核心心智模型的转变：Hermes 不仅仅是一个围绕工具构建的聊天 UI。它是一个 面向智能体的有状态运行时 只是恰好将聊天作为其交互界面。

3. 工作原理

官方架构文档在这里表现得异常透明。Hermes 将多个入口点路由到一个共享的 AIAgent 核心：CLI、网关、ACP、批量运行器和 API 服务器都汇入同一个编排循环。该循环负责协调 Prompt 构建、提供商解析、工具调度、压缩和持久化。

架构页面还展示了为什么 Hermes 比许多竞争对手感觉更宽泛。Prompt 组装不仅仅是一个系统 Prompt 字符串。它层叠了性格文件、记忆文件、技能、项目上下文文件，例如 AGENTS.md、特定于模型的指令以及工具使用指南。会话数据存储在带有 FTS5 的 SQLite 中，而网关会话和智能体状态则跨界面进行跟踪。

安全模型同样非常明确。文档描述了一种七层深度防御方法，包括危险命令审批、容器隔离、MCP 子进程的凭据过滤、针对提示词注入（prompt injection）的上下文文件扫描，以及经过验证的工作目录参数。这并不意味着 Hermes 是万无一失的，但它确实表明该项目认真考虑了操作员风险。

4. 技能系统（Skills System）是真正的差异化所在

如果说 Hermes 有一个功能让产品的其他部分变得有意义，那就是技能系统。官方文档将技能定义为通过渐进式披露模式加载的按需知识文档，以最大限度地减少 Token 消耗。通俗点说，就是 Hermes 尽力避免一次性将所有过程性知识塞进提示词中。

技能存储在 ~/.hermes/skills/，可以进行打包、从 Hub 安装或由智能体（agent）创建，并且每个安装的技能都会变成一个斜杠命令（slash command）。文档展示了如下示例： /github-pr-workflow, /plan，以及通过 CLI 进行的直接搜索/安装命令。

# Browse and install skills
hermes skills search kubernetes
hermes skills search react --source skills-sh
hermes skills install openai/skills/k8s

# Or use the slash command inside Hermes
/skills

渐进式披露模型使这一设计显得优雅而非臃肿。Hermes 首先仅加载轻量级的技能元数据，然后开启完整的 SKILL.md 仅在实际需要该技能时才加载，并且只有在任务需要时才加载更深层的参考文件。这种设计模式使得优秀的智能体工具链感觉非常迅速，而不是被提示词堆砌感所淹没。

Hermes 还将技能扩展到了单次调用之外。cron 文档展示了可以在提示词运行前附加一个或多个技能的任务，这意味着定时任务可以继承结构化的工作流，而不是依赖庞大的内联指令块。

# Conceptually, Hermes cron jobs can attach skills
hermes cron edit <job_id> --skill blogwatcher --skill find-nearby

# Or you can ask naturally:
"Every morning at 9am, check Hacker News for AI news and send me a summary on Telegram."

5. 记忆与搜索：强大的理念，有界的设计

Hermes' 的记忆系统比营销词汇 “memory” 通常所暗示的更加严谨。文档描述了两个有界文件， MEMORY.md 以及 USER.md，并带有明确的字符限制。它们在会话开始时作为冻结快照注入到提示词中，这样 Hermes 就可以保留持久的事实，而无需不断更改其自身的前缀。

这种设计至关重要，因为它将记忆视为 精选状态，而不是无限制的垃圾场。Hermes 会记住项目事实、用户偏好和有用的学习过程，但它仍然依赖独立的会话存储和会话搜索来进行更深层次的历史回溯。架构文档明确指出，会话持久化存储在带有 FTS5 和血缘追踪（lineage tracking）的 SQLite 中。

6. 如何开始

官方快速入门非常简单。安装 Hermes，选择提供商，启动 TUI 或 CLI，然后决定是需要本地执行还是更安全的远程/容器后端。对于大多数人来说，第一步应该是刻意保持简单：先让单个会话运行起来，然后再逐步添加 gateway、skills、MCP 和 cron。

# Install Hermes Agent
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

# Configure provider and tools
hermes setup

# Start Hermes
hermes --tui

如果你想将 Hermes 用于实际工作而非实验，下一步应该是更安全的终端执行：

# Safer execution backends from the docs
hermes config set terminal.backend docker
hermes config set terminal.backend ssh

# Optional: connect messaging platforms
hermes gateway setup

快速入门还包含一个最小的 MCP 示例，这正是让 Hermes 比封闭的工具孤岛更有用的原因：

mcp_servers:
  github:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_xxx"

有两个安装注意事项值得明确说明。首先，官方文档仍然引导 Windows 用户使用 WSL2。其次，问题追踪器显示安装和环境管理相关的 bug 仍在高频出现，因此请将安装程序视为快速迭代的基础设施，而非成熟的企业级封装。

7. 真实世界示例

示例 1：默认情况下不要在本地后端运行高风险任务

错误做法： 在本地安装 Hermes，保持终端后端开启 local，并开始让它在你的真实工作站上运行广泛的 shell 命令。

正确做法： 先切换到 Docker 或 SSH，保持危险命令审批开启，并将本地后端视为便捷选项而非生产环境选项。

示例 2：不要将每个工作流都编码进一个巨大的 prompt 中

错误做法： 不断追加长期指令，直到每个任务都以堆叠如山的上下文开始。

正确做法： install or create skills for recurring workflows, then let Hermes load them on demand or attach them to cron jobs. This is exactly what the skills system was designed to solve.

示例 3：不要混淆记忆与知识的完整性

错误做法： 假设 Hermes 的记忆意味着智能体现在永久理解你系统的每一个细节。

正确做法： 将记忆用于稳定的事实和偏好，将会话搜索用于历史记录，并使用 MCP 或外部工具进行更深层次的单一事实来源检索。这种分层模型更接近 Hermes 的实际构建方式。

8. 社区反应

社区对 Hermes 的广泛反应很有趣，因为它不仅仅是炒作。它融合了运维人员的真实兴奋、对自托管智能体技术栈的明显好奇，以及对该产品在实际工作负载下能否兑现承诺的理性怀疑。

积极的一面是，Nous Research 的公开发布信息极力强调 “grows with you” 的叙事，这种描述在文档和第三方帖子中也得到了呼应。Tenten 在 LinkedIn 上的一篇帖子几乎逐字重复了相同的内存与机器访问框架，这表明该产品的品牌故事已经成功地传播到了 GitHub 原生群体之外。

Reddit 更真实地捕捉到了这种分歧。在 LocalLLaMA 关于发布的第一个帖子中，一位评论者对“将通讯账号交给 Hermes”的想法给出了直截了当的回应：

“把它安装在机器上，给它你的通讯账号”……呵呵，行吧。

这种怀疑并非无理取闹。Hermes 要求用户在自动化、凭据、长期运行的进程以及工具执行方面给予信任。但同一帖子中的下一条评论则是务实的，而非不屑一顾：

“我计划在 Render + Supabase 上使用它。”

这或许是对 Hermes 现状最准确的总结：有些人听到宣传后立即担心安全问题；而另一些人听到同样的宣传后，已经开始规划部署目标了。

问题追踪器进一步证实了这是一个激进且快速发展的底层架构项目。最近的问题包括 一个智能体破坏了其自身的运行时 virtualenv、安装流程停滞以及 容器/systemd 的 gateway-install 不匹配。这些都没有否定 Hermes 的价值。它只是意味着该仓库在面临真实采用压力的同时，也存在着真实的运维风险（footguns）。

9. 结论：Hermes Agent 值得使用吗？

适用场景：

• 你希望智能体可以运行在 VPS、容器或远程机器上，而不仅仅局限于编辑器。
• 你关注由技能、MCP、cron 和可搜索的会话历史构建的持久化工作流。
• 你习惯于像操作者一样思考：后端、凭据、安全边界和故障模式。

暂不建议使用，如果：

• 你主要想要一个开箱即用、配置简单且组件较少的精致编程副驾驶。
• 你不想考虑网关、容器、配置或后端选择。
• 相比于广度和灵活性，你更需要成熟的封装和低摩擦的生产环境稳定性。

10. 更宏观的视角

Hermes 的意义超出了其代码库本身，因为它指向了一种不同的智能体软件模型。最终胜出的智能体可能不是那个拥有最华丽聊天界面的，而可能是那个表现得更像基础设施的：明确的状态、可重用的程序、可搜索的历史记录、多种执行环境，以及在上下文切换后依然能保持的接口。

这也是为什么 Hermes 能自然地融入关于开放技能、MCP 服务器和多智能体编排的讨论中。它将这些都视为可组合的构建块，而非孤立的功能。如果你一直关注我们关于 便携式技能、自定义 MCP 工具以及 多智能体编排，Hermes 看起来不再像是一个异类，而更像是一个密集的交汇点。

Hermes 本身是否会成为主流的开源 Agent 运行时仍是一个悬而未决的问题。但产品方向已经非常明确：人们真正愿意留下的 Agent，是那些拥有足够的记忆、能够充分授权、运行足够安全，并且在实际工作发生的各种场景中都能触手可及的智能体。

11. 常见问题解答

12. 所有来源与链接

主要来源

• Hermes Agent GitHub 仓库
• Hermes Agent 官方网站
• 官方文档首页
• 快速入门
• 架构
• 安全

文档

• 技能系统
• 持久化记忆
• 定时任务 (Cron)
• 工具与工具集 & Toolsets
• 配置

社区

• X 上的 Nous Research
• Reddit：r/LocalLLaMA 中的发布讨论帖
• LinkedIn：Tenten 的动态
• GitHub issues

引用的 Issue 讨论串

• Agent 可能会通过运行 `uv venv` 破坏其自身的运行时 venv
• 安装被拦截
• 在带有 systemd 的容器内安装 Gateway

网络资源

• Nous Research 产品页面
• BuildMVPFast 分析

内部链接

• 掌握 Agent 技能
• 构建你自己的 MCP 服务器
• Agent 编排指南
• Vibe Coding 指南