这两天检索 “hermes-agent” 会发现一个很有意思的现象它已经不只是 Nous Research 的一个 agent 项目而是开始出现在一批周边工具、桌面壳、记忆系统、代码知识图谱和自托管平台的兼容列表里。截至 2026-07-28 15:22Asia/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-20Release 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-agent2215752026-07-28Hermes Agent 主仓farion1231/cc-switch1218412026-07-27多 agent CLI/桌面切换器描述中支持 Hermes Agentcolbymchenry/codegraph629462026-07-24本地代码知识图谱描述中支持 Hermes Agentscreenpipe/screenpipe205812026-07-28本地屏幕记录与 agent 上下文描述中支持 Hermes agentfathah/hermes-desktop136142026-07-24Hermes Agent 桌面伴侣EKKOLearnAI/hermes-studio95442026-07-28Hermes Agent Web dashboard注意这类 GitHub 快照适合判断“热度方向”不适合当作永久事实。文章写作时应注明抓取时间而不是把 star 数当成静态结论。入门你可以把 Hermes 当成什么用从用户视角看Hermes Agent 有两个最基础入口。第一是本地 CLI/TUIhermes hermes model hermes tools hermes setup hermes doctor第二是消息网关hermes gateway官方 README 写到它支持从 Telegram、Discord、Slack、WhatsApp、Signal、Email 等入口继续同一个 agent 工作流。这个设计很关键很多 agent 项目默认“人在电脑前”Hermes 更像“agent 在云端或工作机上长期跑你在任何入口给它发任务”。一个典型入门流程是安装 Hermes。用hermes setup或hermes model配置模型 provider。用hermes tools管理工具权限和工具集。在 CLI 里开始一次对话。如果要长期运行再配置 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。这样做有两个好处保持模型前缀稳定减少缓存失效。避免系统提示词在同一轮任务中不断变化降低不可预期行为。代价是新记忆要到下一次会话才真正进入提示词。这个取舍很工程化。它承认长期记忆不是“越实时越好”而是要在一致性、成本和可解释性之间找平衡。技术核心三记忆不是把所有聊天塞进上下文Hermes 的 memory 文档把长期记忆分成两类文件MEMORY.mdagent 自己的环境事实、流程经验、项目约定。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 到自动化 agentHermes 内置 Cron。它不是简单执行 shell而是把定时任务也当成 agent jobScheduler 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/终端工作流、模型原生体验LangGraphagent 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 的主要事故会发生在哪里。它的风险也同样明显系统很大官方 architecture 文档显示工具、gateway、插件、provider、cron、desktop、ACP、MCP 都在体系里学习成本不低。长期记忆需要治理agent 自动写 memory/skill 很强但错误记忆和错误 skill 也会长期污染行为所以审批、查看、回滚很重要。多端入口扩大攻击面Telegram/Slack/Email/Webhook 等入口越多身份校验和权限隔离越关键。MCP 与外部工具是双刃剑连接越多系统越要控制工具暴露面和凭据流动。GitHub 热度不等于生产成熟度Release 很频繁是活跃信号也是稳定性仍在快速变化的信号。新手应该怎么上手如果只是好奇建议按这个顺序先本地安装跑hermes完成一次普通对话。用hermes model配一个你已经熟悉的 provider。用hermes tools看当前暴露了哪些工具不要一开始全开高风险能力。试一次memory和session_search理解“短期上下文、长期记忆、历史检索”的差别。学一个简单 skill比如把你自己的项目发布流程写成可复用步骤。再接 MCP只暴露最小工具集。最后再碰 gateway 和 Cron因为它们会让 agent 变成长期在线系统安全要求更高。如果用于团队或生产环境我建议先问四个问题哪些工具有外部副作用哪些入口能触发 agentAPI 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-agentHermes Agent 官方文档https://hermes-agent.nousresearch.com/docs/Hermes Agent READMEhttps://github.com/NousResearch/hermes-agent/blob/main/README.mdHermes Agent v0.19.0 Releasehttps://github.com/NousResearch/hermes-agent/releases/tag/v2026.7.20Agent Loop Internalshttps://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/agent-loop.mdArchitecturehttps://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/architecture.mdTools Runtimehttps://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/tools-runtime.mdPrompt Assemblyhttps://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/prompt-assembly.mdPersistent Memoryhttps://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/memory.mdSkills Systemhttps://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/skills.mdMCP 文档https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/mcp.mdCron 文档https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/cron.mdSecurity 文档https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/security.mdAI Providers 文档https://github.com/NousResearch/hermes-agent/blob/main/website/docs/integrations/providers.mdGitHub API 快照本文仓库热度表抓取时间为 2026-07-28 15:22Asia/Shanghai原始检索记录保存在本地研究目录。许可说明本文为原创中文技术解读不是对官方文档或 README 的完整翻译。Hermes Agent 主仓采用 MIT License本文只做必要的短引用、结构化概括和来源链接不搬运第三方受限图片或大段原文。
)
