大家好，我是若风。
最近我看了一个挺有意思的开源项目：nousresearch/hermes-agent。
一开始我以为它只是又一个命令行 AI Agent。毕竟这两年类似项目太多了：能跑命令、能改文件、能接模型 API、能调用工具，听起来都差不多。
但把 README、官方文档、pyproject.toml、工具系统、网关代码和最新 release 放在一起看以后，我的感觉变了。Hermes Agent 不是在做一个"更聪明的 Chat CLI"，它更像是在做一个个人 AI 代理运行时：模型只是其中一层，真正复杂的地方在于工具、记忆、技能、跨平台入口、调度任务、子代理和运行环境。
这个方向很值得看，也有一点让人焦虑。
因为今天很多 AI Agent 项目都卡在同一个地方：第一次能跑，第二次失忆；本地能跑，手机上不行；一个任务能跑，长期任务没人管；模型能换，但工具和上下文跟着散架。Hermes Agent 想解决的，不是"让模型回答一句话"，而是"让一个代理长期活在你的工作流里"。
截至我调研时，仓库 main 分支最新提交在 2026 年 5 月 17 日，最新 release 文档是 v0.14.0，发布时间为 2026 年 5 月 16 日。这个版本的 release note 很夸张，里面提到 v0.13.0 以来合入了 633 个 PR、关闭了 545 个 issue，还把安装、Windows、性能、消息平台、模型路由和工具安全都扫了一遍。
所以这篇文章不写成安装教程。
我更想回答一个问题：
Hermes Agent 到底在重新定义什么？
先说结论
Hermes Agent 的核心价值，不是"它能调用很多工具"，而是它把 AI Agent 拆成了一个长期运行系统。
它有 5 个关键判断。
第一，Agent 不应该只活在终端里。 Hermes 支持 CLI，也支持 Telegram、Discord、Slack、WhatsApp、Signal、Email、Feishu、DingTalk、WeCom、Teams 等消息入口。换句话说，它希望你从任何聊天界面都能叫醒同一个代理，而不是每次回到一台固定电脑上开一个命令行。
第二，工具调用不是越多越好，而是要能被管理。 Hermes 用 toolset 把 Web、终端、文件、浏览器、记忆、技能、Cron、委托、消息发送等能力分组，再按 CLI、网关、API Server、ACP、不同消息平台组合出不同工具面。这个设计比"把所有工具塞给模型"更工程化。
第三，记忆不是聊天记录，而是可检索、可维护、可外接的系统。 仓库里的 hermes_state.py 使用 SQLite + FTS5 存会话和消息，官方文档还把 Memory、Session Search、外部 memory provider 分开讲。它不是简单保存几条偏好，而是在做跨会话召回和用户模型。
第四，技能是 Agent 的过程性记忆。 Hermes 的 skill 系统和 agentskills.io 标准兼容，Agent 可以浏览、加载、创建和维护技能。对我来说，这是它最有辨识度的地方：一次复杂任务做完，不应该只留下一段聊天记录，而应该沉淀成下次可复用的操作手册。
第五，它更像"Agent OS"，不是一个轻量库。 Hermes Agent 很全，也很重。它适合想要长期运行、跨平台接入、自己托管、深度定制的人；如果你只是想在项目里嵌一个简单 agent loop，它可能不是最轻的选择。
一句话概括：
Hermes Agent 把"和模型聊天"往前推了一步，推到了"给模型一个长期生活和工作的环境"。
它到底是什么
从官方 README 看，Hermes Agent 给自己的定位是 "self-improving AI agent"。这个词容易被营销化，所以我们先把它拆开。
不是一个模型。
也不是一个单纯的提示词框架。
它是一个 Python 写的 Agent 应用和运行时，入口包括：
hermes：交互式终端 UIhermes model：配置模型和 providerhermes tools：配置工具能力hermes gateway：启动消息平台网关hermes cron：管理定时任务hermes acp：给编辑器或 Agent Client Protocol 使用hermes proxy：在新版本里提供 OpenAI-compatible 本地代理
从 pyproject.toml 看，它要求 Python 3.11+，主包名是 hermes-agent，命令行入口包括 hermes、hermes-agent 和 hermes-acp。项目依赖里能看到几个重要选择：openai 作为基础客户端，prompt_toolkit 做 CLI 交互，croniter 做调度，pydantic 做结构化数据，rich 做终端输出，httpx 做网络层。
更有意思的是它对依赖的态度。
pyproject.toml 里把核心依赖锁成了精确版本，并且明确解释了原因：避免 PyPI 上游包突然发新版本时，被范围依赖自动拉进来。v0.14.0 还把很多重型后端移到了 lazy install，只有用户真正启用某个 provider、消息平台或工具时才安装对应依赖。
这个细节很工程，也让人有点释然。
很多 Agent 项目刚开始会疯狂加依赖，越做越像一个"包管理炸弹"。Hermes 反过来意识到：长期运行的代理，供应链风险和安装稳定性本身就是产品体验的一部分。
架构上，它分成几层
如果只看 README，Hermes Agent 的功能会显得特别散：模型、工具、技能、记忆、网关、Cron、TUI、浏览器、子代理、语音、图像、Computer Use。
但源码结构看下来，它其实可以分成 6 层。
第一层是交互入口层。
这里包括 CLI、TUI Gateway、Messaging Gateway、API Server、ACP Adapter。用户可以从终端进来，也可以从 Telegram、Discord、Slack、Email、Feishu、DingTalk、WeCom、Teams、Signal、WhatsApp 等平台进来，还可以让编辑器或 HTTP 客户端接进来。
第二层是Agent Loop 层。
这层负责把用户消息、系统提示词、记忆、技能、工具定义和模型响应串起来。它要处理流式输出、工具调用、上下文压缩、中断、重试、handoff、后台 review 等等。真正难的地方不是"调用一次模型"，而是长会话里所有边界条件都要能接住。
第三层是模型与 provider 层。
Hermes 的 README 明确强调"Use any model you want"，支持 Nous Portal、OpenRouter、NovitaAI、NVIDIA NIM、Xiaomi MiMo、z.ai/GLM、Kimi/Moonshot、MiniMax、Hugging Face、OpenAI，以及自定义 endpoint。v0.14.0 还新增了 xAI Grok OAuth、NovitaAI，并提供 OpenAI-compatible local proxy。
这意味着它不是押注某一个模型厂商，而是把模型当成可替换执行后端。
第四层是工具系统层。
toolsets.py 里能看到 Hermes 把工具拆成了 web、terminal、file、browser、skills、memory、session_search、cronjob、delegation、code_execution、messaging、homeassistant、kanban、computer_use 等 toolset，然后再组合成 hermes-cli、hermes-gateway、hermes-telegram、hermes-discord、hermes-acp 等平台工具集。
这个设计有个好处：不同入口能暴露不同能力。
比如 CLI 可以更自然地给终端和文件工具，消息平台需要 send_message，ACP 面向编辑器则更偏代码、文件、浏览器、会话搜索和委托。工具不是一个扁平清单，而是按场景组合。
第五层是状态与记忆层。
hermes_state.py 里有 SQLite session database，使用 WAL、FTS5 和 trigram FTS。默认数据库放在 ~/.hermes/state.db，里面有 sessions、messages、FTS 虚拟表、schema version、metadata 等结构。它还专门处理了 NFS、SMB、FUSE 这类文件系统上 WAL 可能失败的问题，失败时回退到 journal_mode=DELETE。
这个细节又很"真实世界"。
很多开源 demo 不会关心你的数据库是不是放在网络盘上，也不会管 gateway 多进程读写时会不会锁住。Hermes 这里明显已经被长期运行和多入口并发折磨过，所以把会话存储做成了基础设施。
第六层是长期任务层。
这里包括 Cron、delegation、kanban、batch trajectory、trajectory compression。它让 Agent 不只响应当前对话，还能跑定时任务、并行子任务、生成训练轨迹、压缩轨迹，甚至围绕长期目标做更复杂的调度。
所以它不是一个薄壳。
它是一个从入口、模型、工具、状态、记忆到任务调度都自己管的 Agent runtime。
最特别的地方：学习闭环
Hermes Agent 最值得单独讲的，是它的学习闭环。
很多 AI 工具也会说自己有 memory，但 memory 这个词太宽了。有的只是把用户偏好写进一个文件，有的是把聊天记录放进向量库，有的是把历史对话摘要塞回系统提示词。
Hermes 把这个问题拆成了几层：
- Memory：保存 agent 的个人笔记和用户画像
- Session Search：搜索过去会话
- Skills：保存可复用的操作过程
- Curator：维护和整理 skill
- External Memory Providers：接 Honcho、OpenViking、Mem0、Hindsight、RetainDB、ByteRover、Supermemory 等外部记忆系统
这里最关键的是 Skills。
如果一个 Agent 做完一次复杂任务，只是把结果发给你，那它其实没有成长。下次遇到类似任务，它还要重新摸索。真正的成长应该是：它能把"这次怎么做成的"沉淀为一套可复用程序，下次直接加载。
这也是 Hermes Agent 和普通聊天工具的区别。
普通聊天工具的记忆更像"我知道你喜欢什么"；Hermes 的技能更像"我知道这类工作怎么做"。
不是...而是...这句老话放在这里尤其合适：不是把聊天记录越存越多，而是把反复出现的工作过程变成可以复用的能力。
前者是偏好，后者是方法。
这件事特别重要。因为 Agent 的长期价值，不在于每次都从零推理，而在于它能把过去的成功经验变成默认动作。人类团队也是这样成长的：不是每次重新开会，而是把流程写成 runbook，把踩坑写进 checklist，把高频任务变成脚本。
Hermes Agent 其实是在把这个过程搬进 AI Agent。
工具系统：不是 40 个工具，而是工具治理
README 里说 Hermes 有 40+ tools。这个数字本身不稀奇，现在很多 Agent 框架都能堆工具。
真正值得看的是它怎么治理工具。
toolsets.py 里有一个共享核心工具列表 _HERMES_CORE_TOOLS，包括：
- web search / extract
- terminal / process
- read_file / write_file / patch / search_files
- browser navigate / click / type / console / CDP
- skills list / view / manage
- todo / memory / session_search
- execute_code / delegate_task
- cronjob
- send_message
- computer_use
- kanban
然后它把这些工具按平台组合。
这个设计背后的判断是：Agent 的能力边界应该是可配置的，不应该每次都把全部权限扔给模型。一个在 Telegram 里运行的代理、一个在本地 CLI 里运行的代理、一个在编辑器里运行的代理，它们需要的能力不同，风险也不同。
比如 terminal 是强能力，必须和安全策略、危险命令审批、运行后端一起考虑；browser 是网页执行能力，适合测试和网页操作；memory 和 session_search 是跨会话能力，影响隐私和召回；send_message 是外部通信能力，不能随便给所有场景。
这就是工具治理，而不是工具堆叠。
我觉得这个方向会越来越重要。未来 Agent 系统的竞争，不会只是"谁接了更多 API"，而是"谁能把工具权限、上下文成本、运行风险和任务目标放在同一套控制面里"。
网关：让 Agent 活在聊天软件里
Hermes Agent 的另一个大块是 Messaging Gateway。
很多人低估了这一层的价值。一个 Agent 如果只能在本地终端里用，它本质上还是一个开发工具；如果它能稳定接到 Telegram、Discord、Slack、Email、Feishu、DingTalk、WeCom、Teams、WhatsApp、Signal 这些入口，它就开始接近"个人工作流助手"。
README 里有一句话很关键：它不是绑在你的 laptop 上，可以在云 VM 上跑，然后你从 Telegram 和它对话。
这句话背后是使用场景的变化。
以前我们用 AI 工具，默认是"我坐到电脑前，打开某个应用"。Hermes 想要的是"Agent 在某个长期运行环境里，我从任何入口把任务丢给它"。它可以在 VPS、Docker、SSH、Modal、Daytona、Vercel Sandbox 里跑，也可以通过 gateway 接收消息。
这就带来了几个很实际的好处。
第一，移动端可用。你在路上也能发一条消息，让它查资料、跑脚本、写总结、做定时任务。
第二，会话可以连续。不是每个入口各自一套上下文，而是尽量围绕同一个 session 和 memory 系统运行。
第三，任务可以后台化。你不用盯着终端等输出，Agent 可以在云端执行，结果再发回消息平台。
当然，这也带来风险。
一个能在聊天软件里跑命令、读文件、发消息的 Agent，权限边界必须非常清楚。Hermes 在文档里单独有 Security、Command Approval、DM pairing、container isolation 等内容，v0.14.0 也继续修了 sudo 绕过、工具错误注入、危险命令检测这类问题。
说白了，网关能力越强，安全设计越不能当附属功能。
Cron 和子代理：从对话走向长期任务
Hermes Agent 还有两个能力很值得放在一起看：Cron 和 Delegation。
Cron 解决的是"以后再做"和"周期性做"。
官方文档里支持一次性任务、间隔任务、Cron 表达式、ISO 时间戳，也支持把结果送到消息平台。比如每天早上汇总新闻、每周审计仓库、夜里跑备份、定期检查网页变化。
这和普通 reminder 不一样。
Reminder 只是提醒你做事，Hermes 的 Cron 是让 Agent 到点自己执行任务。它还能带 skill、带 workdir、带 no-agent script-only 模式、带上下游 job context。v0.14.0 的 release note 里也提到 provider fallback 和 credential pool rotation 会被 Cron job 继承。
Delegation 解决的是"一个 Agent 不够用"。
文档里写得很直接：可以 spawn isolated subagents 做并行工作流，子代理可以继承 parent 的配置，也可以单独指定模型、provider、base_url。它还支持 batch mode、toolset selection、timeout、监控 /agents。
这其实是在往多代理调度走。
你让一个主代理同时做资料调研、代码 review、测试修复、文档整理，本质上很容易把上下文挤爆。Hermes 的思路是：主代理负责任务拆解和结果汇总，子代理在隔离上下文里做具体工作。这样做的价值不是"多几个模型更热闹"，而是把上下文成本和任务边界拆开。
我觉得这是 Agent 系统必须走的一步。
长期任务需要调度，并行任务需要隔离。只靠一个越来越长的 chat history，最后一定会失控。
模型中立：Hermes 不想被某家模型绑死
Hermes Agent 对模型 provider 的态度很明确：能换，最好随时换。
README 里列了一长串 provider：Nous Portal、OpenRouter、NovitaAI、NVIDIA NIM、Xiaomi MiMo、z.ai/GLM、Kimi/Moonshot、MiniMax、Hugging Face、OpenAI、自定义 endpoint。v0.14.0 又加入了 xAI Grok OAuth、OpenAI-compatible local proxy、OpenRouter Pareto Code router 等能力。
这背后有一个很现实的判断：
Agent 的长期价值不应该被某一个模型 API 锁死。
今天某个模型 coding 强，明天另一个模型长上下文便宜，后天本地模型隐私更好。对个人代理来说，模型是会变化的，工具、记忆、技能、任务和入口才是更长期的资产。
Hermes 的策略就是把模型变成可替换后端。
当然，模型中立不是没有代价。支持越多 provider，兼容性、错误处理、流式协议、工具调用格式、reasoning 字段、OAuth、计费来源、fallback 策略都会变复杂。v0.14.0 的 release note 里大量 provider 修复，本身就说明这块不是轻松活。
但这个方向是对的。
如果 Agent 真的要成为长期个人基础设施，它不能只是一家模型公司的壳。
它适合谁
我觉得 Hermes Agent 特别适合 4 类人。
第一类是重度 AI 工具用户。
如果你已经在用 Claude Code、Codex、Aider、Cline、ChatGPT、OpenRouter、本地模型，并且经常在不同工具之间切换，Hermes 的 provider、proxy、skill、memory 和 gateway 体系会很有吸引力。
第二类是想自托管个人 Agent 的人。
你可以把它放在 VPS 或云环境里，让它长期运行，再通过 Telegram、Discord、Slack、Email 等入口交互。这比"每次打开本地 CLI"更接近一个真正随叫随到的助手。
第三类是喜欢把经验沉淀成流程的人。
如果你做事习惯写 runbook、写脚本、整理 checklist，Hermes 的 Skills 系统会很对胃口。它不是只记录聊天内容，而是把可复用方法变成 Agent 下次能加载的能力。
第四类是 Agent 研究和数据生成场景。
README 里提到 batch trajectory generation 和 trajectory compression。对做 tool-calling 数据、Agent 行为轨迹、训练样本压缩的人来说，这部分比普通用户更重要。
它不适合谁
但我也不建议所有人都上来就用 Hermes Agent。
如果你只是想要一个极简命令行助手，它可能太重。
如果你只想在应用里嵌一个小型 agent loop，LangGraph、OpenAI Agents SDK、自写一层工具调用，可能更直接。
如果你对权限非常敏感，又不愿意花时间配置 command approval、容器、网关白名单、消息平台身份绑定，那 Hermes 的强能力反而会带来压力。
如果你希望所有东西都是"开箱即用且不需要理解架构"，那也要谨慎。Hermes 的功能面非常大，理解模型 provider、工具集、skills、memory、gateway、cron、terminal backend、profile、config 这些概念，需要一点耐心。
这不是一个"小而美"的工具。
它更像一个野心很大的个人 Agent 平台。
我最看重的设计取舍
调研完以后，我最看重 Hermes Agent 的 3 个设计取舍。
第一个取舍：把长期状态当成一等公民。
很多 Agent 项目最初都从 stateless chat 开始，再慢慢补 memory。Hermes 反过来把 session database、memory、session search、skill、curator、external memory provider 都放在核心叙事里。这说明它想解决的是"长期协作"，不是一次性对话。
第二个取舍：把入口和执行环境解耦。
用户可以从 CLI、Telegram、Discord、Slack、Email、Feishu 等入口发消息，Agent 可以在本机、Docker、SSH、Modal、Daytona、Vercel Sandbox 等环境执行。这种解耦很关键，因为真正好用的 Agent 不一定运行在你正在打字的设备上。
第三个取舍：把供应链和安全当产品问题。
精确 pin 依赖、lazy install、危险命令审批、sudo 绕过修复、工具错误 sanitization、WAL 回退、Windows beta、冷启动优化，这些都不是 demo 功能，但它们决定一个 Agent 能不能长期用。
很多项目会先追"更酷的能力"。
Hermes v0.14.0 给我的感觉是，它开始补"能不能稳稳运行"的债。
和 Claude Code / Codex 这类工具有什么不同
很多人可能会问：那它和 Claude Code、Codex 这类编码 Agent 有什么区别？
我的理解是，Claude Code / Codex 更像专门面向代码工程的强执行工具，而 Hermes Agent 更像一个通用个人代理运行时。
Claude Code / Codex 的核心场景是 repo 内开发：读代码、改文件、跑测试、提交 PR。它们的产品体验会围绕代码工作流打磨得更深。
Hermes Agent 的边界更宽：聊天入口、定时任务、技能沉淀、记忆系统、消息网关、多 provider、多终端后端、家庭自动化、语音、图像、浏览器、Computer Use、子代理、trajectory。
所以不要简单比较谁"更强"。
更准确的比较是：
- 如果你主要做代码开发，专业 coding agent 可能更顺手
- 如果你想搭一个长期存在、可跨平台交互、可自我沉淀技能的个人 Agent，Hermes 更接近这个方向
它们未来甚至可能互补。
v0.14.0 里的 OpenAI-compatible local proxy 和 ACP/Zed 集成本身就说明，Hermes 并不一定要取代所有开发工具，它也可以变成其他工具背后的 provider、代理入口或运行时。
最后说两句
Hermes Agent 最吸引我的地方，不是它功能多。
功能多很容易，难的是功能多以后还知道自己在做什么。
它真正有意思的地方在于：它把 Agent 当成一个会长期运行、会接入多个入口、会积累记忆、会沉淀技能、会执行定时任务、会委托子代理、会切换模型后端的系统来设计。
这和很多"ChatGPT + tools"的项目不太一样。
后者更像一次对话里的增强能力；Hermes 更像给 Agent 搭了一个家。
当然，这个家很大，也不轻。你要愿意配置、愿意理解、愿意接受它带来的复杂度。对普通用户来说，它可能不是最快上手的 AI 工具；但对想把 AI Agent 变成长期工作流基础设施的人来说，它很值得认真看。
我的判断是：
Hermes Agent 代表的是 Agent 工具从"临时会话"走向"长期运行环境"的一个方向。
这条路不一定只有它能走通，但这个项目已经把很多关键问题摆上了桌面：记忆怎么管、技能怎么沉淀、工具怎么治理、任务怎么调度、入口怎么统一、模型怎么替换、安全怎么兜底。
这些问题，比"又多接了一个模型"重要得多。