这两天检索 “hermes-agent” 会发现一个很有意思的现象：它已经不只是 Nous Research 的一个 agent 项目，而是开始出现在一批周边工具、桌面壳、记忆系统、代码知识图谱和自托管平台的兼容列表里。

截至 2026-07-28 15:22（Asia/Shanghai）通过 GitHub API 抓取的快照，NousResearch/hermes-agent 显示为 MIT License，主语言 Python，仓库描述是 “The agent that grows with you”，当天仍有 push；同一搜索结果里，cc-switch、codegraph、screenpipe 等项目也把 Hermes Agent 放进了支持对象。这说明它的热度不只来自 star 数字，也来自一个更实际的趋势：开发者正在把 “agent” 从一次性聊天工具，推向长期运行、可记忆、可调度、可接入多端和多工具的个人/团队自动化运行时。

本文不是 README 翻译，而是一篇基于官方仓库、官方文档、Release notes 和 GitHub 检索快照的原创技术解读。先讲入门概念，再拆它背后的 agent loop、记忆、技能、工具运行时、MCP、Cron 和安全边界。

先说结论：Hermes Agent 到底是什么

如果用一句话概括：Hermes Agent 是一个以长期运行和自我改进为目标的开源 AI agent 运行时。

普通聊天机器人解决的是：

用户输入 -> 模型回答

普通工具调用 agent 解决的是：

用户目标 -> 模型选择工具 -> 工具返回结果 -> 模型继续推理

Hermes Agent 试图再往前走一步：

用户目标
  -> agent loop 执行任务
  -> 记录会话与工具结果
  -> 把关键经验沉淀成 memory
  -> 把可复用流程沉淀成 skill
  -> 下次会话、消息平台、Cron 任务或子 agent 再复用这些经验

这就是它 README 里反复强调的 “grows with you” 的技术含义：agent 不只是会调用工具，还要能把过去任务里学到的东西压缩成长期资产。

为什么最近会火

从全网和 GitHub 检索看，Hermes Agent 的火点主要有三层。

第一层是显性热度。GitHub API 快照里，NousResearch/hermes-agent 排在 “hermes-agent” 相关搜索结果前列，仓库显示 2025-07-22 创建、2026-07-28 仍在频繁提交，许可证为 MIT。最近的 v2026.7.20 / v0.19.0 Release 发布于 2026-07-20，Release notes 里提到从 v0.18.0 以来约 2,245 次提交、约 1,065 个合并 PR、约 3,300 个 issue 关闭，以及首 token 延迟显著下降、桌面端和 TUI 性能优化、智能审批、子 agent 可视化、持久投递账本等改动。

第二层是产品方向。它押中的不是“再做一个聊天框”，而是长期 agent 需要的几件基础设施：持久记忆、技能系统、跨平台消息网关、Cron 自动化、多模型 provider、多终端后端、MCP 接入、安全审批和会话检索。

第三层是生态扩散。GitHub 搜索结果中，许多项目并不是 Hermes 本身，却在描述里写明支持 Hermes Agent，例如 agent CLI 切换器、代码知识图谱、屏幕记录/上下文系统、桌面管理工具等。这类兼容信号很重要：只有当一个工具被别的工具适配时，它才开始从“项目”变成“生态接口”。

下面这张表是 2026-07-28 GitHub API 快照中的部分结果，仅用于说明热度与生态线索，数据会随时间变化：

仓库	快照 star	最近 push	相关性
NousResearch/hermes-agent	221575	2026-07-28	Hermes Agent 主仓
farion1231/cc-switch	121841	2026-07-27	多 agent CLI/桌面切换器，描述中支持 Hermes Agent
colbymchenry/codegraph	62946	2026-07-24	本地代码知识图谱，描述中支持 Hermes Agent
screenpipe/screenpipe	20581	2026-07-28	本地屏幕记录与 agent 上下文，描述中支持 Hermes agent
fathah/hermes-desktop	13614	2026-07-24	Hermes Agent 桌面伴侣
EKKOLearnAI/hermes-studio	9544	2026-07-28	Hermes Agent Web dashboard

注意：这类 GitHub 快照适合判断“热度方向”，不适合当作永久事实。文章写作时应注明抓取时间，而不是把 star 数当成静态结论。

入门：你可以把 Hermes 当成什么用

从用户视角看，Hermes Agent 有两个最基础入口。

第一是本地 CLI/TUI：

hermes
hermes model
hermes tools
hermes setup
hermes doctor

第二是消息网关：

hermes gateway

官方 README 写到它支持从 Telegram、Discord、Slack、WhatsApp、Signal、Email 等入口继续同一个 agent 工作流。这个设计很关键：很多 agent 项目默认“人在电脑前”；Hermes 更像“agent 在云端或工作机上长期跑，你在任何入口给它发任务”。

一个典型入门流程是：

1. 安装 Hermes。
2. 用 hermes setup 或 hermes model 配置模型 provider。
3. 用 hermes tools 管理工具权限和工具集。
4. 在 CLI 里开始一次对话。
5. 如果要长期运行，再配置 gateway、Cron、MCP 或远程终端后端。

它的模型侧并不绑定单一厂商。官方文档的 provider 页面列出 Nous Portal、OpenRouter、OpenAI 兼容接口、Anthropic、GitHub Copilot、Qwen、MiniMax、xAI、Bedrock、Vertex AI、Ollama Cloud、NVIDIA NIM、自托管 vLLM 等路线。技术上，它把 provider 解析成内部运行模式，再统一进入同一个 agent loop。

技术核心一：Agent Loop 不是一句口号

Hermes 官方开发文档把核心类放在 AIAgent 上。它负责系统提示词组装、provider/API mode 选择、可中断模型调用、工具执行、会话历史维护、压缩、重试、fallback、迭代预算和持久记忆刷新。

简化后的执行流可以写成：

run_conversation()
  -> 追加用户消息
  -> 构建或复用 system prompt
  -> 判断是否需要上下文压缩
  -> 转成目标 provider 所需消息格式
  -> 调用模型
  -> 如果模型返回 tool_calls：执行工具，把结果写回历史，继续循环
  -> 如果模型返回文本：保存会话，刷新记忆，返回结果

这和普通 ReAct 类 agent 的相似点是“模型决定下一步动作”。不同点在于 Hermes 把很多工程问题显式做成子系统：

• API mode：内部支持 OpenAI Chat Completions、OpenAI Responses/Codex 格式、Anthropic Messages 三类调用模式，再收敛为统一消息格式。
• 可中断调用：模型请求跑在后台线程里，用户 /stop 或新消息可以打断当前回合，避免长任务把交互卡死。
• 并发工具执行：多个 tool call 可以通过线程池并发执行，并按原始 tool call 顺序回填结果。
• 迭代预算：默认有最大迭代数，子 agent 也有独立预算，防止任务无限循环。
• fallback provider：主模型遇到限流、服务端错误或鉴权问题时，可以按配置尝试备用 provider。

所以 Hermes 的 agent loop 更像一个“生产化控制回路”，而不是一个简单 while 循环。

技术核心二：Prompt Assembly 是真正的隐形工程

长期 agent 难做，不只因为模型会犯错，还因为上下文会变乱。Hermes 的 prompt assembly 文档把 system prompt 拆成多层：身份/行为指导、工具使用规则、Honcho 用户建模块、外部系统消息、memory 快照、user profile 快照、skills 索引、项目上下文文件、时间戳、平台提示等。

一个很重要的设计是“冻结快照”：memory 和 user profile 在会话开始时注入 system prompt，之后即使 agent 在本轮里写入了新记忆，也不会立刻改动当前 system prompt。这样做有两个好处：

1. 保持模型前缀稳定，减少缓存失效。
2. 避免系统提示词在同一轮任务中不断变化，降低不可预期行为。

代价是：新记忆要到下一次会话才真正进入提示词。这个取舍很工程化。它承认长期记忆不是“越实时越好”，而是要在一致性、成本和可解释性之间找平衡。

技术核心三：记忆不是把所有聊天塞进上下文

Hermes 的 memory 文档把长期记忆分成两类文件：

• MEMORY.md：agent 自己的环境事实、流程经验、项目约定。
• USER.md：用户偏好、沟通风格、稳定期望。

它们都有严格字符限制。官方文档解释得很直白：memory 要保持短、准、可行动；不能把大段日志、临时代码、一次性上下文都塞进去。

更有意思的是，Hermes 把“记忆”和“会话检索”分开：

能力	适合保存什么
Persistent Memory	每次都应该知道的关键事实
Session Search	过去某次对话里的具体细节

会话检索基于 SQLite + FTS5。也就是说，它不是把所有历史永久塞进 prompt，而是在需要时搜索过去对话。这比“无限上下文”更务实：关键偏好进 memory，长尾细节走检索。

这也是 Hermes 的一个重要判断：长期 agent 的记忆系统不应该只有向量库，还应该有可编辑、可审计、低 token 成本的结构化记忆层。

技术核心四：Skills 是程序化记忆

如果 memory 记的是“事实”，skills 记的就是“怎么做”。

Hermes 的 Skills System 支持从本地文档、在线文档、当前对话里的流程、用户粘贴的操作步骤中学习技能。技能通常是一个 SKILL.md，里面包含何时使用、步骤、坑点、验证方法等。官方文档也强调 progressive disclosure：不要一上来把所有技能全文塞给模型，而是先给索引，需要时再展开。

这点非常关键。很多 agent 系统的问题是“会工具，但不会积累流程”。比如你带它走完一次内部发布流程，普通 agent 下次可能还要重新教；Hermes 的思路是把这个流程变成 skill，下次通过技能索引唤起。

可以把 Hermes 的学习闭环粗略理解为：

一次复杂任务
  -> agent 执行工具与推理
  -> 用户纠正或任务成功
  -> 后台 review 抽取可复用经验
  -> 写入 memory 或 patch/create skill
  -> 后续任务复用

这不是“模型权重自我训练”，而是更现实的外部记忆与程序化工作流沉淀。

技术核心五：工具运行时决定 agent 的上限

Hermes 的 architecture 文档列出 70+ registered tools 和约 28 个 toolsets。工具并不是硬编码进一个巨大 switch，而是每个工具模块通过 registry 注册 schema、handler、可用性检查函数和所属 toolset。

模型真正看到的是过滤后的工具 schema。过滤逻辑会考虑：

• 当前平台启用了哪些 toolset。
• 工具依赖的 API key、二进制、外部服务是否可用。
• MCP 动态工具是否已经发现。
• plugin 是否注册额外工具。

工具执行时，典型链路是：

模型返回 tool_call
  -> agent loop 识别工具
  -> pre_tool_call hook
  -> 危险命令检测与审批
  -> registry.dispatch 执行 handler
  -> post_tool_call hook
  -> 工具结果回填给模型

这套设计的价值在于三点。

第一，工具发现和工具执行分离。模型只看到当前可用工具，减少 hallucination。

第二，工具可以按平台裁剪。CLI、Telegram、Cron、ACP/IDE 场景不一定暴露同一组能力。

第三，工具出错被包装成结构化 JSON，而不是直接炸掉 agent loop。生产系统里，这种“把错误也变成可继续推理的观察结果”很重要。

MCP：让工具层从项目内能力变成协议能力

Hermes 支持 MCP。官方 MCP 文档中，Hermes 可以连接 stdio server、HTTP server、OAuth HTTP server，也支持 per-server 工具过滤、白名单、黑名单、glob 规则和动态工具发现。

这意味着 Hermes 的工具层可以分成两类：

内置工具：terminal / file / web / browser / vision / delegate 等
外部协议工具：GitHub MCP / filesystem MCP / Stripe MCP / 内部系统 MCP 等

真正值得注意的是安全模型。Hermes 文档强调 MCP stdio subprocess 默认拿到的是过滤后的环境变量；MCP 工具错误信息会做 credential redaction；对高风险 server 可以只暴露少数工具。例如连接 Stripe 时，保留查询能力，过滤掉退款或创建付款这类危险动作。

这说明 Hermes 对 MCP 的理解不是“接得越多越好”，而是“接入要可裁剪、可审计、可限制”。

Cron：从聊天 agent 到自动化 agent

Hermes 内置 Cron。它不是简单执行 shell，而是把定时任务也当成 agent job：

Scheduler tick
  -> 找到到期任务
  -> 创建 fresh AIAgent
  -> 注入关联 skill / prompt / script context
  -> 执行任务
  -> 把结果投递到目标平台
  -> 更新 next_run 和执行历史

这让 Hermes 很适合做“每天早上自动巡检”“每周生成报告”“夜间备份检查”“GitHub PR 审查提醒”这类任务。它甚至支持 job chaining：前一个任务产出的上下文可以交给下一个任务继续处理。

但 Cron 也带来风险：无人值守任务不能随便执行危险命令。官方文档里，Cron 的危险命令默认策略可以设置成 deny 或 approve；生产环境显然应该偏保守，把高风险动作留给人工确认。

安全边界：Hermes 不是让 agent 裸跑

Hermes 的安全文档非常长，这反而是好信号。长期运行 agent 最大的风险，不是模型答错一句话，而是它连着工具、文件系统、消息平台、MCP server、远程终端后端和自动化任务。

它的安全边界主要包括：

• 危险命令审批：对 rm -rf、格式化磁盘、危险 SQL、覆盖系统配置、服务操作、远程脚本执行等模式触发审批。
• Smart approval：可用辅助模型判断某些误报命令是否低风险，但不确定时仍升级给人。
• 文件写保护：对关键路径硬拦截，也可配置写入安全根目录。
• Gateway 用户授权：消息平台不是谁发消息都能控制 agent，可以用 allowlist 和 DM pairing。
• 容器隔离：Docker/Singularity/Modal 等后端可以把执行环境和宿主隔开。
• MCP 凭据过滤：避免把宿主环境里的敏感变量无意传给外部 MCP server。
• 上下文文件注入扫描：对 AGENTS.md、SOUL.md 等上下文文件做 prompt injection 检查。
• SSRF 防护：避免 web/browser/media 下载误打内网和云元数据地址。

最重要的判断是：Hermes 的审批、过滤和隔离主要防“诚实但会犯错的 agent”，不是一个能抵御恶意本地进程的完美沙箱。真正生产部署仍然应该使用隔离机器、最小权限 API key、网络限制和审计日志。

和 Claude Code、Codex、LangGraph 的区别

Hermes Agent 容易被拿来和 Claude Code、Codex、OpenCode、LangGraph 比。我的理解是：

工具	更像什么	优势
Claude Code / Codex	代码任务 agent	深度代码编辑、IDE/终端工作流、模型原生体验
LangGraph	agent workflow 编排框架	状态图、可控流程、应用内 agent 开发
OpenCode / OpenClaw	开源 coding agent / agent runtime	开放、可自托管、面向开发者自动化
Hermes Agent	长期运行的个人/团队 agent runtime	记忆、技能、消息网关、Cron、MCP、多 provider、多后端

所以 Hermes 不一定是“某个单点能力最强”的工具。它真正的野心是把 agent 变成一个能长期住在你工作流里的系统：你可以在终端里用它，也可以从消息平台给它派活；可以让它在本地工作，也可以让它在 VPS、Docker、SSH、Modal、Daytona 这类环境里跑；可以让它现在做一件事，也可以让它明天早上自动醒来做一件事。

我怎么看 Hermes Agent 的技术路线

Hermes Agent 最值得关注的地方不是“又一个开源 agent”，而是它把很多 agent 工程里的灰色地带产品化了。

比如记忆。很多项目说自己有 memory，但实际只是把历史塞进向量库。Hermes 同时保留短小可编辑 memory、用户画像、SQLite/FTS5 会话搜索和外部 memory provider 插件，层次更清晰。

比如技能。很多 agent 可以生成代码，却不会把一次成功工作流沉淀成下次可复用的 procedure。Hermes 把 skill 当成程序化记忆，并且支持技能索引、Hub、审批和安全扫描。

比如多入口。很多 agent 只能在本机聊天框里跑。Hermes 把 CLI、gateway、Cron、ACP、API server 和 Python library 都接到同一个 AIAgent 核心上，这种“平台无关核心 + 多入口适配”的架构更适合长期演进。

比如安全。很多演示项目默认给 agent 全权限。Hermes 至少把危险命令审批、授权、MCP 环境过滤、写保护、容器隔离和 SSRF 防护放在正式文档里，这说明它知道长期 agent 的主要事故会发生在哪里。

它的风险也同样明显：

1. 系统很大：官方 architecture 文档显示工具、gateway、插件、provider、cron、desktop、ACP、MCP 都在体系里，学习成本不低。
2. 长期记忆需要治理：agent 自动写 memory/skill 很强，但错误记忆和错误 skill 也会长期污染行为，所以审批、查看、回滚很重要。
3. 多端入口扩大攻击面：Telegram/Slack/Email/Webhook 等入口越多，身份校验和权限隔离越关键。
4. MCP 与外部工具是双刃剑：连接越多系统，越要控制工具暴露面和凭据流动。
5. GitHub 热度不等于生产成熟度：Release 很频繁是活跃信号，也是稳定性仍在快速变化的信号。

新手应该怎么上手

如果只是好奇，建议按这个顺序：

1. 先本地安装，跑 hermes，完成一次普通对话。
2. 用 hermes model 配一个你已经熟悉的 provider。
3. 用 hermes tools 看当前暴露了哪些工具，不要一开始全开高风险能力。
4. 试一次 memory 和 session_search，理解“短期上下文、长期记忆、历史检索”的差别。
5. 学一个简单 skill，比如把你自己的项目发布流程写成可复用步骤。
6. 再接 MCP，只暴露最小工具集。
7. 最后再碰 gateway 和 Cron，因为它们会让 agent 变成长期在线系统，安全要求更高。

如果用于团队或生产环境，我建议先问四个问题：

• 哪些工具有外部副作用？
• 哪些入口能触发 agent？
• API key、OAuth token、MCP env 会不会被不该看到的子进程拿到？
• 出错后能不能查到是哪次会话、哪次工具调用、哪条记忆或哪个 skill 导致的？

能答清楚这些问题，再谈自动化规模化。

最后的判断

Hermes Agent 代表了 2026 年 agent 工程的一个明显趋势：大家不再满足于“模型会调用工具”，而是开始追求“agent 能长期运行、能记住、能学习流程、能跨入口协作、能被审计和限制”。

它不是最轻的框架，也不是最适合拿来写十行 demo 的工具。它更像一个正在成型的 agent runtime：模型只是其中一部分，真正的价值在记忆、技能、工具、调度、权限、会话和协议层的组合。

如果说上一代 agent demo 的关键词是 autonomous，那么 Hermes Agent 这一类项目的关键词应该是 durable：可持续、可恢复、可治理、可复用。长期来看，真正有用的 agent 不会只是“很会说”，而是能在你的工作系统里留下正确的痕迹，并且在出错时让你知道该从哪里修。

参考来源

• NousResearch/hermes-agent GitHub 主仓：https://github.com/NousResearch/hermes-agent
• Hermes Agent 官方文档：https://hermes-agent.nousresearch.com/docs/
• Hermes Agent README：https://github.com/NousResearch/hermes-agent/blob/main/README.md
• Hermes Agent v0.19.0 Release：https://github.com/NousResearch/hermes-agent/releases/tag/v2026.7.20
• Agent Loop Internals：https://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/agent-loop.md
• Architecture：https://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/architecture.md
• Tools Runtime：https://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/tools-runtime.md
• Prompt Assembly：https://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/prompt-assembly.md
• Persistent Memory：https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/memory.md
• Skills System：https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/skills.md
• MCP 文档：https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/mcp.md
• Cron 文档：https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/cron.md
• Security 文档：https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/security.md
• AI Providers 文档：https://github.com/NousResearch/hermes-agent/blob/main/website/docs/integrations/providers.md
• GitHub API 快照：本文仓库热度表抓取时间为 2026-07-28 15:22（Asia/Shanghai），原始检索记录保存在本地研究目录。

许可说明

本文为原创中文技术解读，不是对官方文档或 README 的完整翻译。Hermes Agent 主仓采用 MIT License；本文只做必要的短引用、结构化概括和来源链接，不搬运第三方受限图片或大段原文。