开源自托管 Agent 项目 Hermes Agent：四种形态怎么分工
本文基于 hermes-agent 仓库 commit 2d40494（2026-07-29）梳理，该项目仍在高频迭代，具体行为以仓库 https://github.com/NousResearch/hermes-agent 最新代码与文档为准。
这四个项目不在同一层上，所以「哪个更强」这个问题本身是问错的：真正要判断的是你手上这个需求应该落在哪一层。 本文说的 Hermes 是 Nous Research 开源的那个自托管 Agent 项目 NousResearch/hermes-agent（MIT 许可证），不是同一家的 Hermes 开源模型系列，也不是别的同名商标或同名库。它跟另外三个项目最直观的分别是：它自己就是一个要在机器上长期活着的进程，而不是一份装到别人程序里的配置或方法。
一、先把四个项目摆在各自的位置上
站内已经写过三篇同类横向对比：开源 Agent 项目三体对比 讲的是项目层面的取舍框架，Agent 技能机制三体对比 讲技能这个通用机制怎么设计，Agent 扩展与跨平台三体对比 讲扩展点怎么跨 harness 迁移。那三篇讲的是通用方法论或别的项目；本篇只做一件事——把 hermes-agent 这个具体仓库摊开，看它把「常驻自托管」这个取向落到了哪些文件、哪些机制上，代价又记在哪一笔账上。
先看四份 README 各自的第一句话在说什么，位置差异就出来了。
pi 的 README 标题写的是 Pi Agent Harness，「All Packages」那张表里列了四个 npm 包：@earendil-works/pi-ai（多家模型服务商的统一 API）、@earendil-works/pi-agent-core（带工具调用与状态管理的 agent 运行时）、@earendil-works/pi-coding-agent（交互式编码 agent CLI）、@earendil-works/pi-tui（差分渲染的终端 UI 库）。这是一套可以拆开取用的程序件：既能直接跑那个 CLI，也能只拿运行时嵌进自己的程序里。
ECC 的 README 说自己给 agent 提供一套协同的工程系统与工具箱，流程写成一行：plan -> test -> implement -> review -> verify -> remember -> improve。它的安装章节标题是「Pick one path only (per harness)」，install.sh 带 --target claude、--target cursor、--target codex，甚至有 --target hermes（附一份 docs/HERMES-SETUP.md）。它本身不跑模型循环，是装在别人的 harness 上的增强套件——包括装到本文主角上。
superpowers 的 README 第一句直接说它是一套完整的软件开发方法论，由一组可组合的技能加一点让 agent 真的去用这些技能的初始指令构成。它的安装矩阵覆盖 Claude Code、Codex、Cursor、Gemini CLI、Kimi Code、OpenCode 以及 pi（pi install git:github.com/obra/superpowers）。它连模型服务商都不管，管的是流程：brainstorming、writing-plans、test-driven-development、requesting-code-review、finishing-a-development-branch 这一串技能按顺序把人和 agent 的协作卡住。
hermes-agent 的 README 里两条描述最能说明取向：「Lives where you do」——一个 gateway 进程同时接 Telegram、Discord、Slack、WhatsApp、Signal 和 CLI；「Runs anywhere, not just your laptop」——列了七种终端后端：local、Docker、SSH、Singularity、Modal、Daytona、Vercel Sandbox。它的 AGENTS.md 里那句自我定义更直白：同一个 agent 内核跑在 CLI、消息网关、TUI 和 Electron 桌面端上，跨会话学习，派生工作 agent，跑定时作业，驱动真实终端和浏览器。
一个可嵌入的终端 agent 程序、一个装在别人 harness 上的增强套件、一个方法论技能包、一个常驻自托管 agent——四者的证据都能在各自仓库根目录的 README 里当场翻到，谁装到谁身上（ECC 有 --target hermes，superpowers 有 pi 安装路径）也写得很清楚。这种关系不是高下，是层级。
二、常驻这件事，在仓库里长什么样
「常驻」听起来只是一句部署方式的描述，但它会反向决定代码结构。跑完就退的 CLI 不需要考虑会话什么时候该忘掉、进程崩了之后那半句话怎么接上；长期活着、还从聊天软件收消息的进程必须考虑。docs/session-lifecycle.md 就是为这件事写的内部文档，里面能看到几层设计。
会话被抽象成三个数据结构——SessionSource（消息从哪来：平台、chat 类型、线程、用户）、SessionEntry（这条会话当前是哪个 session_id，累计 token 与各种状态标志）、SessionStore（内存字典加 sessions.json 持久化，规范存储在 SQLite）。会话键由 build_session_key() 生成，格式是 agent:main:{platform}:{chat_type} 后面按需拼 chat、线程、参与者标识。群里默认每个人一条独立会话（group_sessions_per_user 默认开），线程里默认所有人共用一条（thread_sessions_per_user 默认关）——这两个默认值不一样是有意的。
崩溃恢复那一节值得单独看。网关正常退出会写一个 .clean_shutdown 标记；下次启动如果没找到这个标记，就调 suspend_recently_active() 把刚才还活跃的会话标成 resume_pending，启动流程给这些会话合成一条消息事件，让 agent 自己把中断的活接上。resume_pending 这个标记不在恢复访问时清掉，要等下一轮成功完成才清（.clean_shutdown 则相反，启动时读完就删）；又被打断就留着下次再试。同时有一个 _suspend_stuck_loop_sessions() 数连续重启次数（记在 restart_counts.json），撞过 3 次的会话直接强制换新，免得一直在同一个坑里循环。
再往下是缓存：网关按会话键维护一个 AIAgent 实例的 LRU 缓存，命中就复用同一个实例。这不是为了省内存，是为了不破坏按会话的提示词缓存。AGENTS.md 把这件事写成了项目的头号约束：每一轮长会话都在复用一段缓存前缀，任何在会话中途改动历史上下文、切换工具集、重建系统提示词的行为都会让这段缓存失效并把成本翻上去，所以他们不做，唯一例外是上下文压缩。连带效应能在别处看到：技能的斜杠命令是以用户消息形式注入的（agent/skill_commands.py），不进系统提示词；会改动系统提示词状态的斜杠命令默认延迟生效，要立刻生效得显式加 --now。
常驻因此不是「换个地方跑」，是把会话生命周期、崩溃恢复、实例缓存、提示词稳定性一起变成必须处理的问题。这些问题在通用层面怎么拆，可以看检查点与常驻那篇。
| 组成部分 | 它负责什么 | 对应仓库位置 | 你什么时候会碰到它 |
|---|---|---|---|
| 对话主循环 | 工具调用迭代、迭代预算、中断检查 | run_agent.py（AIAgent.run_conversation()） | 想搞清一轮到底发了几次请求 |
| 工具注册与分发 | 工具发现、schema 汇总、调用分发 | model_tools.py + tools/registry.py | 自己加工具，或排查工具没出现 |
| 工具集编排 | 哪些工具对哪个平台可见 | toolsets.py（TOOLSETS、_HERMES_CORE_TOOLS） | 用 hermes tools 调完开关行为不对 |
| 终端后端 | 命令实际在哪执行 | tools/environments/ | 决定隔离姿态的时候 |
| 消息网关 | 平台适配、会话分道、消息排队 | gateway/（run.py、session.py、platforms/） | 接完 Telegram 或 Slack 之后 |
| 会话库与回溯 | SQLite 会话存储与 FTS5 全文检索 | hermes_state.py + tools/session_search_tool.py | 想让它翻几周前的旧账 |
| 技能维护 | agent 自造技能的使用统计与归档 | agent/curator.py + tools/skill_usage.py | 技能越攒越多、开始互相干扰 |
| 危险命令审批 | 模式识别、按会话的审批状态、永久允许清单 | tools/approval.py | 第一次被拦住的时候 |
| 定时作业 | 作业存储与 tick 循环 | cron/jobs.py + cron/scheduler.py | 让它每天自动跑一件事 |
三、它怎么把「学习」变成具体文件
四个项目都谈演进，但落点不同，这一点分歧比形态分歧更值得看。superpowers 的演进落在方法上——README 明说一般不接受新技能的贡献，且对技能的任何修改都必须在它支持的所有 agent 上都能工作，它的资产是技能文件本身的质量而非运行时状态；ECC 的演进落在可携带的上下文上——Memory Vault 用本地可读的 Markdown，项目记忆放 .ecc/memory/，用户记忆放 ~/.ecc/memory/，能在 harness 之间交接，同时明确声明记忆是未经审核的上下文而不是可执行的策略。hermes-agent 的演进落在自己的目录里，形式是文件和 SQLite。有几处能直接翻到：
技能有两套并列的表面。skills/ 是默认可加载的内置技能，14 个分类目录下一共 70 份 SKILL.md；optional-skills/ 是随仓库发布但默认不激活的重型或小众技能，21 个分类目录下 111 份 SKILL.md，要用 hermes skills install official/<category>/<skill> 显式装。AGENTS.md 里对技能写作定了一串硬规矩，最刺眼的一条是 description 不超过 60 个字符、一句话、以句号结尾，理由很实在：描述太长会撑大技能列表，在同时加载很多技能时稀释模型的注意力。
技能可以由 agent 自己写出来。/learn 背后是 agent/learn_prompt.py：不做单独的蒸馏引擎，也不新增模型工具，就是把用户指的素材和上面那套写作标准拼成一个提示词，交给 agent 用已有工具自己产出一份 SKILL.md，落盘走 skill_manage。好处在文件注释里写明了——不依赖额外机制，本机、Docker、远程终端后端上行为一致。
技能也不会无限膨胀。agent/curator.py 配合 tools/skill_usage.py 记录每个技能的使用、查看、修改次数和最近活跃时间，长期不用的自动归档进 ~/.hermes/skills/.archive/，可恢复。两条不变量写在 AGENTS.md 里：只处理带 agent 来源标记的技能，仓库自带和从 Hub 装的一律不碰；永远不删除，最重的动作就是归档。
记忆和回溯是两条路。前者由 memory 工具加 agent/memory_manager.py 组织，后端做成插件（plugins/memory/ 下有 honcho、mem0、supermemory 等内置实现，且这个集合已明确关闭，新后端要独立发布）。后者是 session_search：它的文档头写清了三种调用形态——给 query 走 FTS5 检索返回命中片段与上下文窗口、给会话 id 加锚点消息滚动前后文、什么都不给就按时间列最近会话，三种全都直接从 SQLite 返回真实消息，一次模型调用都不发。此外 agent/agent_init.py 里读了两个间隔配置，记忆和技能创建各一个：「该沉淀点东西了」不指望模型自觉，由运行时按间隔戳它一下。
四、边界与代价：它明确不管什么
这个项目会常驻在你的机器上、开终端执行命令、连着你的聊天软件账号、往磁盘写文件、访问外部服务。这些能力的代价，仓库自己写得比多数用户愿意承认的更狠。
SECURITY.md 第 2 节定义信任模型，2.2 小节的原话是：面对一个有敌意的模型，唯一的安全边界是操作系统。紧接着把话说完——agent 进程内部的任何东西都不构成隔离，审批门不是、输出脱敏不是、任何模式扫描器不是、任何工具允许清单也不是；任何在进程内筛查模型输出的组件，本质上都是在一个被攻击者影响过的字符串上做启发式判断。
于是审批机制的定位要看清楚。tools/approval.py 是危险命令这套系统的唯一出处，里面有模式识别、按会话键维护的审批状态、交互式与网关两种提问路径、用辅助模型自动放过低风险命令的通道，以及写进配置文件的永久允许清单。它能拦住不少事，但它不是牢笼。同一个文件里有处细节值得记住：那个绕过全部审批的环境变量在模块导入时就被冻结，注释写明了理由——否则进程内任何一个技能都能在运行中设置它、当场把审批全绕过去，那是一条提示注入的提权路径。
真正的隔离只有两种姿态，SECURITY.md 让操作者自己选：换一个非默认的终端后端，让模型发出的 shell 命令和文件工具都在容器、远程主机或云沙箱里跑；或者把整个进程包起来。前者的边界写得很老实——它管不住 agent 在自己 Python 进程里做的事，包括代码执行工具起的宿主子进程、MCP 子进程、插件加载、hook 分发和技能加载，这些全都进的是同一个解释器。另外 docs/security/network-egress-isolation.md 讨论 Docker 部署下 network_mode: host 带来的无限制外联，以及怎么用只放行允许清单的出口代理把它收窄，防的正是从工具生成的 shell 命令里用 curl、wget 往外倒数据。
这跟 pi 的取向刚好构成一组对照。pi 的 README 直接承认自己没有内置的权限系统去限制文件系统、进程、网络或凭据访问，默认就以启动它的用户和进程的权限运行；要更强的边界就去容器化或沙箱化，文档给了三种模式（凭据留在宿主、只把工具和 ! 命令路由进本地 Linux 微虚拟机；整个进程放进 Docker；整个进程放进策略受控的沙箱）。两个项目的结论其实一致：边界在进程外面。差别只在 hermes-agent 要常驻、要接聊天软件、要跑定时作业，暴露面天然更大，所以它把这套东西写成了篇幅可观的策略文档。
还有几件它明确不管或有意不做的事：
核心刻意做窄。AGENTS.md 里有一条叫「Footprint Ladder」的决策梯子，新能力要从最省的一级开始选：先看能不能扩现有代码，再看 CLI 子命令加一个技能，再看有前置条件才出现的门控工具（check_fn），再看插件，再看收进 MCP 目录清单的 MCP 服务器，最后才是新增核心工具。理由是每一个模型工具都会在每次 API 调用里被送出去。你想加东西，别指望核心给你开口子。
第三方产品不进主仓。可观测性后端、厂商 SaaS 连接器、分析看板这类「别人的产品」的插件不收进 plugins/，要以独立插件仓库形式发布，用户装到自己的插件目录或用 pip 入口点。理由写得很清楚：这是耦合与维护负担的决定，不是质量判断——插件可以很好，照样会被关掉。内置记忆后端集合也已按同样理由关闭。
非机密配置不给环境变量。.env 只放机密（API key、token、密码），所有行为设置都进配置文件；让用户「在 .env 里设一下 X」的贡献会被拒，除非 X 是凭据。
后台派生的工作 agent 虽然脱离了当前这一轮，但仍然是进程内的；要求跨进程重启还活着的活，得用定时作业或带完成通知的后台终端命令。
五、上手与避坑清单
每条都写清楚为什么会踩，以及怎么避。
别拿它跟 ECC、superpowers 二选一。 会踩是因为四个名字经常出现在同一个话题里，容易当成竞品。ECC 的安装表里有 --target hermes，superpowers 的安装表里有 pi——层级不同的东西可以叠。怎么避：先分清你缺的是模型循环、常驻能力，还是流程约束，再决定装哪一层。
接群聊之前先确认会话隔离的默认值。 会踩是因为两个默认值不一样：群和频道默认按人隔离，线程默认共用。猜错的后果是同事看到别人的上下文，或者反过来，本该共享的讨论各说各话。怎么避：读一遍 docs/session-lifecycle.md 的会话键规则，按实际场景显式设定。
别在会话中途改系统提示词状态然后指望立刻生效。 会踩是因为这在别的工具里往往是即时的，你会以为设置没保存。这里改动技能、工具、记忆这类命令默认延迟到下一个会话生效，为的是不让提示词缓存失效。怎么避：确实要立刻生效就显式加 --now，并接受这一轮的成本变化。
加能力之前先爬一遍那把梯子。 会踩是因为第一反应总是「加个工具最快」。这里新增核心工具是成本最高的一级，PR 也过不去。怎么避：照 AGENTS.md 的顺序自查，多数需求停在「CLI 子命令加一个技能」或「插件」这两级；本地私有的工具走插件目录，不要动核心。
默认终端后端就是你的宿主机。 会踩是因为装完就能直接聊天，太顺，容易忘了命令是在哪执行的。怎么避：在给它任何有价值的目录访问权之前先定隔离姿态——换终端后端还是包整个进程，两者管的范围不一样。相关的通用权衡见最小权限设计。
别把审批门当成安全边界。 会踩是因为它的交互体验太像一道闸门，用久了会产生「有人看着」的错觉。怎么避：把它当降低误操作概率的启发式，真正的隔离交给操作系统。
贡献代码前先验前提。 会踩是因为看起来像遗漏的限制常常是有意为之，AGENTS.md 专门有一节讲这个并举了真实的关闭案例。怎么避：动手前用 git log -p -S "<符号>" 把那行代码当初为什么这么写翻出来。
收束：接下来该读哪个文件
按这个顺序读，判断会比看功能列表快得多：先 AGENTS.md，看它自己承认的两条约束（提示词缓存不能破、核心要窄）以及那把梯子；再 SECURITY.md 第 2 节，把边界在哪弄清楚；再 docs/session-lifecycle.md，理解常驻到底要处理哪些问题；最后按需翻 run_agent.py、gateway/、tools/environments/。
三条自检：你要的是常驻能力还是流程约束，如果是后者，装个方法论技能包更省；你打算给它多大的权限半径，这个答案要在开机之前就定下来，而不是被拦一次之后再补；你团队里谁负责在它自己攒出一堆技能之后去看那份使用统计——这件事没人管，攒出来的东西迟早开始互相干扰。
顺带一句关于模型服务商：这个项目支持换任意服务商和模型，hermes model 就能切。各家的规则不同且会调整，以官方最新说明为准。
本篇属于一个把开源常驻自托管 Agent 项目 Hermes Agent逐层拆开讲的系列，整体地图见 开源自托管 Agent 项目 Hermes Agent 是什么；沿着这条线往下，还可以看 开源自托管 Agent 项目 Hermes Agent 的两套前端分工 和 开源自托管 Agent 项目 Hermes Agent 的仓库结构导读。