这两天检索 “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 快照中的部分结果，仅用于说明热度与生态线索，数据会随时间变化：

注意：这类 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 把“记忆”和“会话检索”分开：

会话检索基于 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 比。我的理解是：

所以 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；本文只做必要的短引用、结构化概括和来源链接，不搬运第三方受限图片或大段原文。