Hermes Agent 架构详解：AI Agent 的神经系统——学习与进化

核心定位Hermes Agent 自我进化的 AI Agent 框架Self-Evolving Agent Framework一个给 AI 装上自我进化、持续学习神经系统的框架。它不追求确定性控制而是追求适应性、进化性和越用越聪明。文章目录一、设计哲学Agent 优先进化第一二、与 OpenClaw 的根本分野三、七层架构全景四、逐层详解4.1 交互层——多渠道统一接入4.2 网关层——轻量路由4.3 核心编排层——Agent LoopAgent Loop vs OpenClaw PipelineTurn Lifecycle每轮执行循环学习闭环的精确触发点迭代预算4.4 闭环学习层——Closed Learning Loop灵魂核心五步核心循环四大核心组件组件 1Agent-Curated MemoryAgent 自主管理的持久记忆组件 2Autonomous Skill Creation Self-Improvement自主技能创建与自改进组件 3FTS5 Cross-Session Recall跨会话全文检索 LLM 总结组件 4Honcho Dialectic User Modeling辩证用户建模四大组件如何闭合4.5 进化引擎层——GEPAGenetic-Pareto Prompt EvolutionGEPA 的学术来源为什么不走 RL 路线GEPA 三大底座底座 1反思性变异Reflective Mutation底座 2帕累托前沿选择Pareto Frontier Selection底座 3自然语言反馈作为变异信号GEPA 完整工作流GEPA 的性能数据4.6 持久化层——混合存储架构存储结构四层内存分离Token 控制核心设计上下文压缩前的保护4.7 执行沙箱层——六终端后端五、技能系统全拆解会生长的 SkillHermes Skill vs 传统 SkillSKILL.md 完整格式技能的完整生命周期六、记忆系统全拆解四层 vs 双文件与 OpenClaw 记忆对比谁决定什么值得记住——最关键的区别程序性记忆——Hermes 独有层七、Agent Loop 深度对比Hermes vs OpenClaw八、功能全景工具系统40 内置工具多平台消息网关LLM 提供商200 模型MCP 双向集成九、安全模型安全默认设置插件安全设计十、局限性与诚实说明十一、ima.copilot 中的映射十二、演进弧线从激进到克制十三、选型指南选择 Hermes如果你需要不选择 Hermes如果你需要十四、总结一、设计哲学Agent 优先进化第一Hermes 遵循两条底层信念信念含义Agent 优先Agent-First框架的编排层服务于 Agent 的自我改进循环而非约束它进化第一Evolution-First技能不是人写的是 Agent 从经验中长出来的记忆不是手动维护的是 Agent 自己管理的Hermes 问的是如何给 AI 装上一套自我进化、持续学习的神经系统答案是一个不断从实验中总结经验的研究实验室——你只管提需求技能匹配、记忆分类、上下文压缩全都在阴影里完成。它的野心不是让你觉得它好用而是让它在不知不觉中自己越变越好。二、与 OpenClaw 的根本分野OpenClaw骨架 Hermes神经系统 ┌──────────────────┐ ┌──────────────────┐ │ 网关优先 │ │ Agent 优先 │ │ 确定性编排 │ │ 自主性学习 │ │ 强调控制与可预测 │ │ 强调进化与适应性 │ │ │ │ │ │ 问如何套缰绳 │ │ 问如何装神经 │ │ │ │ │ │ 技能人工编写 │ │ 技能自动生长 │ │ 记忆结构化配置 │ │ 记忆Agent 自管 │ │ 进化无 │ │ 进化GEPA 引擎 │ │ │ │ │ │ → 7×24 稳定数字员工│ │ → 越用越聪明的同事│ └──────────────────┘ └──────────────────┘三、七层架构全景┌─────────────────────────────────────────────────────────┐ │ 交互层Channels │ │ Telegram / Discord / Slack / WhatsApp / Signal / CLI │ ├─────────────────────────────────────────────────────────┤ │ 网关层Gateway │ │ 消息路由 / 单进程多渠道 / 统一记忆 / 统一人格 │ ├─────────────────────────────────────────────────────────┤ │ 核心编排层Agent Loop │ │ 同步推理引擎 / 工具执行 / 技能创建 / 自我评估 / 反思 │ ├─────────────────────────────────────────────────────────┤ │ 闭环学习层Closed Learning Loop │ │ Agent-Curated Memory / Skill Auto-Create / FTS5 Recall │ │ Honcho User Modeling / Periodic Nudges / Curator │ ├─────────────────────────────────────────────────────────┤ │ 进化引擎层GEPA Engine │ │ 反思性变异 / 帕累托前沿选择 / 自然语言反馈 / 人类审查 │ ├─────────────────────────────────────────────────────────┤ │ 持久化层Persistence │ │ SQLite FTS5 / MEMORY.md / USER.md / sessions/ skills/ │ ├─────────────────────────────────────────────────────────┤ │ 执行沙箱层6 Terminal Backends │ │ local / docker / ssh / daytona / modal / singularity │ └─────────────────────────────────────────────────────────┘四、逐层详解4.1 交互层——多渠道统一接入与 OpenClaw 的关键区别Hermes 原生支持 Signal隐私优先OpenClaw 不支持。Telegram ──┐ Discord ──┤ Slack ──┤ WhatsApp ──┼──→ Gateway ──→ Agent Loop Signal ──┤ 单进程多渠道 CLI/TUI ──┘跨平台上下文保持在一个通道上开始对话在另一个通道上继续——Hermes 跨平台保持上下文。CLI 特色文本用户界面TUI支持多行编辑、自动补全、对话历史且能在 Agent 执行过程中中断或重定向。4.2 网关层——轻量路由Hermes 的 Gateway 比 OpenClaw 轻得多。OpenClaw 的 Gateway 是大脑和交通警察Hermes 的 Gateway 只做消息路由。OpenClaw Gateway Hermes Gateway ┌─────────────────────┐ ┌──────────────────┐ │ 会话管理 │ │ 消息路由 │ │ 实例发现 │ │ 单进程多渠道 │ │ IM 通道连接 │ │ 统一记忆 │ │ 沙盒接入 │ │ 统一人格 │ │ 策略引擎 │ │ │ │ 速率限制 │ │ 核心逻辑在 Agent │ │ 状态管理 │ │ Loop 中不在 Gateway│ │ 工具注入 │ │ │ │ │ │ │ │ → 重网关轻Agent │ │ → 轻网关重Agent │ └─────────────────────┘ └──────────────────┘4.3 核心编排层——Agent Loop这是 Hermes 架构的核心也是与 OpenClaw 最本质的区别。Agent Loop vs OpenClaw PipelineOpenClaw流水线式 Ingestion → Access Control → Context Assembly → Model → Tool → Response 6 阶段流水线Gateway 主导Agent 是执行器 Hermes循环式 用户消息 → Prompt 组装 → 上下文检查 → LLM 调用 → Tool 执行 → 结果注入 → 循环 ReAct 循环Agent 主导Gateway 只是信使Turn Lifecycle每轮执行循环1. 用户消息注入 ↓ 2. Prompt 组装 ├── 加载 MEMORY.md 冻结快照 ├── 加载 USER.md 冻结快照 ├── 加载 Skill 摘要渐进式先 Tier 0 └── 应用 prompt cache ↓ 3. 上下文检查 → 必要时预压缩 ↓ 4. LLM 调用支持 reasoning 字段 ↓ 5. Tool calls 执行pre/post hooks ↓ 6. 结果注入 → 循环直到最终响应 ↓ 7. Post-Execution ├── 保存会话 ├── flush memory └── 触发背景学习核心差异学习闭环的精确触发点触发条件满足任一即触发 ├── Tool call ≥ 5 次复杂任务 ├── 出错后自动恢复自我纠错 ├── 用户纠正 Agent 输出 └── 非显而易见的工作流 触发后 后台进程总结执行轨迹trajectory → 生成/更新 SKILL.md → 完全静默用户无需操作迭代预算Hermes默认 20 轮可配置 → 更大的预算允许 Agent 探索更复杂的任务路径 → 更多轮次 更多学习机会 更多技能沉淀 OpenClaw同样有 Agent Loop 上限 → 但没有学习闭环嵌入 → 多出来的轮次只是更多执行不是更多学习4.4 闭环学习层——Closed Learning Loop灵魂核心这是 Hermes 区别于所有其他 Agent 框架的根本所在。“A closed learning loop — Agent-curated memory with periodic nudges.Autonomous skill creation after complex tasks.Skills self-improve during use.FTS5 session search with LLM summarization for cross-session recall.Honcho dialectic user modeling.”五步核心循环┌─────────────────────────────────────────────────────────┐ │ │ │ ① 执行Execute │ │ 完成任务记录完整执行轨迹trajectory │ │ ↓ │ │ ② 评估Evaluate │ │ 任务结束时自动反思后台触发 │ │ ↓ │ │ ③ 提炼Distill │ │ 自主创建/更新 SKILL.md Memory nudge │ │ ↓ │ │ ④ 检索Recall │ │ 下次任务时 FTS5 搜索 LLM 总结历史 │ │ ↓ │ │ ⑤ 优化Optimize │ │ Skill 自改进 Curator 周期性剪枝 │ │ ↓ │ │ 回到 ① ——正反馈循环 │ │ │ └─────────────────────────────────────────────────────────┘四大核心组件组件 1Agent-Curated MemoryAgent 自主管理的持久记忆两大文件 ┌──────────────────────────────────────────────┐ │ MEMORY.md │ │ 项目/环境事实、规则、教训 │ │ 上限约 2200 字符 / 800 tokens │ │ 存储位置~/.hermes/memories/ │ │ │ │ → Agent 通过 memory tooladd/replace/remove│ │ 自己写、删、合并 │ │ → 容量接近上限时必须先 curation 才能新增 │ │ → 每次会话开始以冻结快照注入 system prompt │ │ 中途修改不影响当前会话 │ └──────────────────────────────────────────────┘ ┌──────────────────────────────────────────────┐ │ USER.md │ │ 你的偏好、风格、背景 │ │ 上限约 1375 字符 / 500 tokens │ │ │ │ → 跨会话保持用户画像一致性 │ │ → 与 Honcho 建模协同越用越懂你 │ └──────────────────────────────────────────────┘周期性 Nudges任务中或结束后Agent 收到内部 Prompt——“最近学到什么值得永久记住”→ Agent 主动判断并持久化。这是自发的不需要用户说记住这个。组件 2Autonomous Skill Creation Self-Improvement自主技能创建与自改进触发条件 ├── 复杂任务≥5 次 tool call ├── 出错恢复 ├── 用户纠正 └── 非显而易见的工作流 存储格式 ~/.hermes/skills/category/skill-name/SKILL.md YAML frontmatter Markdown 步骤 遵循 agentskills.io 标准 自改进机制 ├── 每次调用记录 bump_use() 使用计数 ├── 支持 patch增量修改而非全量重写 └── v0.12 Curator2026.4.30 新增 每 7 天后台运行 → 评分、合并、剪枝低效 Skill → 自动重写更优版本Progressive Disclosure渐进式披露——关键设计Tier 0目录卡片 只加载 Skill 名称和描述 约 3000 tokens 总量 → 注入系统提示词 → 判断方向是否匹配 Tier 1书架取书 方向对了 → 展开完整 SKILL.md 内容 → Agent 开始使用该技能 Tier 2深入参考 需要更多细节 → 加载补充说明 → 完整的步骤、注意事项、边界条件 效果即使 200 个 Skill上下文成本仍接近 40 个组件 3FTS5 Cross-Session Recall跨会话全文检索 LLM 总结存储全部历史对话存入 SQLite~/.hermes/state.db 启用 FTS5 全文索引 检索流程 需要时查询 → FTS5 全文搜索匹配相关片段 → LLM通常轻量模型总结相关片段 → 注入当前上下文 与闭环结合 episodic memory发生了什么── 情景记忆 procedural memory怎么做 ── 程序性记忆Skill → 两类记忆分离避免混淆 作用让 Agent 记得过去所有对话但只注入必要部分组件 4Honcho Dialectic User Modeling辩证用户建模可选插件hermes memory setup 开启 核心机制 辩证式建模方法 → 同时建模用户和 Agent 之间的关系 → 覆盖 12 个身份维度 维度包括 ├── 偏好编码风格、沟通方式 ├── 决策风格激进/保守/折中 ├── 技术水平初学/中级/专家 ├── 工作习惯早鸟/夜猫/碎片化 ├── 信息密度偏好简洁/详细 ├── 幽默感偏好 ├── ...等 与其他层协同 → 让 Skill 更个性化不只是怎么做而是按你的方式做 → 让 Memory 更精准记住对你重要的事 v0.7.0 变化 Honcho 从唯一高级记忆后端降级为可插拔后端之一 与 MEM0、ByteRover 等 6 个第三方服务平起平坐 默认兜底纯文件 全文检索 → 先行者在撞上社区真实投诉后的战略让步四大组件如何闭合记忆事实层 这个项目用 Python 3.12测试框架是 pytest ↓ 提炼 技能流程层 遇到 pytest 报错 → 先看 conftest.py → 再检查 fixtures → 最后看 import ↓ 检索 下次任务FTS5 搜到历史 Skill 匹配 ↓ 优化 Skill 自改进 Curator 剪枝 记忆更新 ↓ 正反馈循环用得越多 → 提炼越多 → 检索越准 → 改进越快4.5 进化引擎层——GEPAGenetic-Pareto Prompt EvolutionHermes 的杀手锏也是社区最被吹捧的硬核差异。GEPA 的学术来源论文Lakshya Agrawal 等人ICLR 2026 Oral 标题《反思性提示词进化可以跑赢强化学习》 Reflective Prompt Evolution Can Outperform Reinforcement Learning 独立仓库NousResearch/hermes-agent-self-evolution 框架DSPy 核心算法GEPA为什么不走 RL 路线主流方案SkillRL / SAGE 强化学习 → 梯度更新 → 强化技能库 问题 ├── 数值 reward 颗粒度太粗跑了得 0.6 分不知道哪里对哪里错 ├── 需要上万次评估才能收敛 └── 训练成本高 GEPA 的对立路线 刻意抛弃强化学习 → 不用梯度更新 → 靠大模型的反思能力 进化算法 → 论文证明不仅跑赢 RL样本利用效率还更高GEPA 三大底座底座 1反思性变异Reflective Mutation不是瞎猜式的随机变异 流程 1. 读取之前的执行轨迹trace 2. LLM 反思 这次为什么做对了 这次为什么做错了 提示词到底该改哪几个字 3. 基于反思生成候选变体 vs 传统随机变异 传统随机改几个字 → 跑评估 → 留高分 GEPA先想清楚改什么 → 针对性修改 → 跑评估 → 变异质量高得多收敛快得多底座 2帕累托前沿选择Pareto Frontier Selection生成了一批候选技能后怎么选 传统方法一刀切只留全局均分最高的 问题丢失多样性可能在边缘场景表现差 GEPA 方法帕累托前沿 只要某个候选在哪怕一个评估样本上表现最强 → 它就会被保留下来 示例 候选 A平均 85 分最高 90 候选 B平均 78 分但某个边界 case 得分 95 候选 C平均 82 分内存占用最低 → A、B、C 都保留各有所长 → 保证技能探索的多样性和鲁棒性底座 3自然语言反馈作为变异信号传统 RL reward 0.6 ← 一个浮点数 → 你根本不知道是哪里对哪里错 → 梯度更新方向模糊 GEPA feedback 这一步没检查边界条件 feedback 应该先读配置再写缓存 feedback 错误处理逻辑遗漏了超时情况 ← 具体的自然语言反馈 → LLM 读得懂这种反馈 → 据此产生下一轮变体 → 比解读一个浮点数有效得多GEPA 完整工作流┌──────────────────────────────────────────────────────┐ │ Step 1采样评估集 │ │ 系统定期读取现有 SKILL 文件 │ │ 从历史会话中抽样或合成搞出评估集 │ └──────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────┐ │ Step 2GEPA 介入 │ │ 读取执行轨迹 │ │ → 反思提意见Reflective Mutation │ │ → 生成候选变体 │ └──────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────┐ │ Step 3评估与选择 │ │ 跑一轮评估 │ │ → 帕累托前沿算法挑出赢家 │ │ → 保留多样性不是只留最高分 │ └──────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────┐ │ Step 4人类审查关键安全阀 │ │ 优化后的 Skill 不会直接覆盖原文件 │ │ → 生成一个 Pull Request │ │ → 必须等人类审核员点头合并 │ │ → 系统永远不会直接提交 │ └──────────────────────────────────────────────────────┘GEPA 的性能数据根据 Nous Research 数据 重复性任务效率提升40% vs GRPO 强化学习基线平均高出 6%特定任务最高高出 20% 所需试错次数少 35 倍 收敛所需评估次数100-500 次传统 RL 需上万次4.6 持久化层——混合存储架构存储结构~/.hermes/ ├── state.db ← SQLite会话历史 FTS5 全文索引 ├── memories/ │ ├── MEMORY.md ← 持久事实环境、规则、教训 │ └── USER.md ← 用户偏好风格、习惯、背景 ├── skills/ │ ├── deployment/ │ │ └── deploy-staging/ │ │ └── SKILL.md ← 自动生成的技能文件 │ ├── devops/ │ │ └── server-monitor/ │ │ └── SKILL.md │ └── ... └── sessions/ ├── session-001.jsonl ├── session-002.jsonl └── ...四层内存分离Token 控制核心设计┌──────────────────────────────────────────────────┐ │ 1. Always-On常驻内存 │ │ MEMORY.md USER.md 冻结快照 │ │ 每次会话注入 system prompt │ │ 命中 provider prompt cache → token 成本极低 │ ├──────────────────────────────────────────────────┤ │ 2. On-Demand按需内存 │ │ FTS5 搜索 LLM 总结 │ │ 需要时才检索不占默认上下文 │ ├──────────────────────────────────────────────────┤ │ 3. Procedural程序性内存 │ │ SKILL.md 技能文件 │ │ 渐进式披露Tier 0 概要 → Tier 1 完整 → Tier 2 │ ├──────────────────────────────────────────────────┤ │ 4. Passive被动内存 │ │ Honcho 用户建模 │ │ 可选开启后台被动构建 │ └──────────────────────────────────────────────────┘ 关键设计缓存感知Cache-Aware → 会话初始化时冻结快照 → 高频模型调用可高效使用缓存的上下文窗口 → 学习过程不会不断增加 Token 费用上下文压缩前的保护上下文接近阈值时 Step 1: Memory Flush 强制 Agent 将关键状态写入磁盘文件 ↓ Step 2: 压缩总结 对上下文进行摘要压缩 ↓ Step 3: 继续运行 压缩后的上下文 持久化文件 无损继续4.7 执行沙箱层——六终端后端比 OpenClaw 更细粒度的安全与性能权衡后端执行环境隔离级别适用场景local宿主机直接运行无日常开发、访问本地文件dockerDocker 容器完全隔离Namespaces, cap-drop ALL不受信任代码、CI/CDssh远程服务器网络边界计算密集型任务daytona云端工作空间完全隔离云容器长期保存状态的云端环境modal无服务器沙盒完全隔离云 VM突发 GPU 需求、按量付费singularityHPC 容器Namespaces–containall学术研究集群灵活性 从个人笔记本 → 企业服务器 → HPC 集群 在隔离强度与执行效率之间做任务级选择 每个任务可以独立选择后端 不需要全局统一配置五、技能系统全拆解会生长的 SkillHermes Skill vs 传统 Skill传统 SkillOpenClaw 等 人工编写 → 安装 → 固定不变 → 过时了手动更新 Hermes Skill 自动生成 → 自动匹配 → 自动进化 → 自动优化 ├── 生命周期劈成两截 │ 一截运行时静默生成 │ 一截离线硬核进化 └── 用户完全无感SKILL.md 完整格式---# Part 1: Frontmatter元数据name:deploy-stagingdescription:一键部署到 staging 环境version:1.2.0platforms:[linux,docker]metadata:hermes:tags:[devops]category:deploymentauto_generated:true# Hermes 自动生成标记use_count:23# 使用计数last_improved:2026-05-15# 上次进化时间confidence:0.87# 自评估置信度---# Part 2: Markdown Body步骤说明## 什么时候用当代码合并到 main 分支后需要部署到 staging 环境时。## 步骤1. git pull origin main 2. 检查 conftest.py 配置 3. 运行 pytest--staging 4. docker build-t staging:latest . 5. docker push registry/staging:latest 6. kubectl rollout restart deployment/staging## 注意事项-先检查 conftest.py再检查 fixtures-staging 环境变量在 .env.staging 中-如果 pytest 失败不要继续部署## 错误恢复-部署失败 → kubectl rollout undo-测试失败 → 检查最近的 commit diff技能的完整生命周期┌─────────────────────────────────────────────────────┐ │ Phase 1静默生成运行时 │ │ │ │ 用户要求完成复杂任务 │ │ ↓ │ │ Agent 执行任务tool call ≥ 5 或出错恢复 │ │ ↓ │ │ 硬规则触发后台进程总结 trajectory │ │ ↓ │ │ 自动打包成 SKILL.md → 存入 ~/.hermes/skills/ │ │ ↓ │ │ 完全静默用户可能根本不知道 │ └─────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ Phase 2渐进式加载下次使用 │ │ │ │ Tier 0名称 描述注入 system prompt~3000 token│ │ ↓ 方向匹配 │ │ Tier 1展开完整 SKILL.md 内容 │ │ ↓ 需要更多细节 │ │ Tier 2加载补充说明 │ └─────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ Phase 3使用中改进运行时 │ │ │ │ 每次 bump_use() 使用计数 1 │ │ 支持 patch 增量修改不全量重写 │ │ 记录成功/失败轨迹 │ └─────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ Phase 4离线进化GEPA │ │ │ │ 系统定期读取 SKILL 历史会话 │ │ ↓ │ │ GEPA反思性变异 → 帕累托选择 → 评估 │ │ ↓ │ │ 优化后的 Skill → 生成 PR不直接覆盖 │ │ ↓ │ │ 人类审核 → 合并 → 新版技能生效 │ └─────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ Phase 5Curator 周期剪枝v0.12 │ │ │ │ 每 7 天后台运行 │ │ → 评分使用频率 × 成功率 × 置信度 │ │ → 合并相似技能合并 │ │ → 剪枝低效技能降级或删除 │ │ → 重写自动生成更优版本 │ └─────────────────────────────────────────────────────┘六、记忆系统全拆解四层 vs 双文件与 OpenClaw 记忆对比OpenClaw双文件 日志 Hermes四层混合 ┌───────────────────────┐ ┌──────────────────────────┐ │ MEMORY.md │ │ MEMORY.md事实层 │ │ 长期记忆 │ │ 上限 800 tokensAgent 自管│ │ │ │ │ │ memory/YYYY-MM-DD.md │ │ USER.md用户偏好层 │ │ 短期日志 │ │ 上限 500 tokensAgent 自管│ │ │ │ │ │ sessions.jsonl │ │ skills/程序性记忆层 │ │ 会话历史 │ │ 自动生成的 SKILL.md │ │ │ │ │ │ │ │ state.db情景记忆层 │ │ │ │ SQLite FTS5 全文检索 │ │ │ │ │ │ │ │ Honcho用户建模层可选 │ │ │ │ 12 维辩证式用户画像 │ └───────────────────────┘ └──────────────────────────┘谁决定什么值得记住——最关键的区别OpenClaw → 人决定。Agent 按规则把关键信息写入 MEMORY.md → 规则写在 AGENTS.md 里开发者配置 → 确定性强但不会主动发现值得记住的东西 Hermes → Agent 自己决定。通过 Periodic Nudges → Agent 自己判断什么值得持久化 → 主动性强但可能判断不准 → 社区发现Hermes 判断自己是否完成任务时几乎总觉得自己成功了 → 所以反思出来的记忆非常薄弱程序性记忆——Hermes 独有层OpenClaw 只有事实性记忆 文件服务器 IP 是 192.168.1.10 ← 知道是什么 Hermes 额外有程序性记忆 遇到 pytest 报错 → 先看 conftest.py → 再检查 fixtures ← 知道怎么做 这是从情景记忆走向程序性记忆的质变 情景记忆记得发生了什么episodic 程序性记忆知道该怎么做procedural → 让记忆变成可以读、可以改、可以提交到 Git、可以团队共享的工件七、Agent Loop 深度对比Hermes vs OpenClaw维度OpenClawHermes调度模型Gateway 主导的 Channel 命令队列Agent Loop 主导的 ReAct 循环提示词构建Gateway 统一注入按渠道动态生成Agent 内部组装加载快照 Skill 摘要工具执行Gateway 注入工具链Pi 执行Agent 直接调用支持 pre/post hooks学习闭环❌ 无v0.12 后补 Active Memory✅ 核心架构关切一等公民迭代预算默认上限默认 20 轮更多轮次 更多学习核心逻辑位置在 Gateway在 Agent Loop设计取向重网关轻 Agent轻网关重 Agent最本质的区别学习闭环的嵌入位置。OpenClaw执行是执行学习是学习两码事 → v0.12 后开始补课Dreaming 做离线记忆整理 → Active Memory 在主回复前跑记忆子 Agent Hermes执行即学习学习即执行一码事 → 每次复杂任务完成 → 自动提炼技能 → 每次会话结束 → 自动 nudge 记忆 → 学习闭环嵌入在 Agent Loop 的每一个 Post-Execution 阶段八、功能全景工具系统40 内置工具类别工具说明文件管理read/write/edit/search文件系统全操作浏览器browser_navigate/click/screenshotPlaywright 语义快照终端exec/bashShell 命令执行通信email/calendar/contacts邮件、日历、通讯录子代理delegate_task单任务/最多 3 个并行子任务记忆memory_add/replace/removeAgent 自主管理记忆技能skill_create/update/search技能生命周期管理搜索web_search/kb_search网络和知识库搜索多平台消息网关Telegram ──┐ ┌── SignalOpenClaw 不支持 Discord ──┤ │ Slack ──┼── Gateway ────────┤── CLI/TUI WhatsApp ──┤ 单进程多渠道│ Signal ──┘ └── 跨平台上下文保持LLM 提供商200 模型OpenRouter → Claude / GPT / Gemini / Llama / DeepSeek OpenAI → GPT-5.4 / GPT-5.4 Thinking Nous Portal → Hermes 模型系列 Ollama → Gemma 4 / Llama 4 / Qwen 3.5 / DeepSeek本地 其他 → z.ai / Kimi / MiniMax / GLM / 自定义端点 一条命令切换模型无需改代码MCP 双向集成MCP 客户端连接外部 MCP 服务器数据库、API、文件系统 MCP 服务器模式v0.6.0将 Hermes 暴露为 MCP 服务器 → IDE 和其他工具可将 Hermes 用作后端九、安全模型安全默认设置机制说明Docker 沙箱生产部署推荐只读 root cap-drop ALL提示词注入扫描v0.7.0 默认开启工具权限限制限制 Agent 可在无人监督情况下使用的工具凭证过滤防止 API 密钥出现在 Agent 上下文中审计日志hermes logs --follow实时监控人类在环审查GEPA 进化的 Skill 必须人类审核才能合并插件安全设计Event Hooks 系统 6 种钩子 → 5 种是触发即忘fire-and-forget的看客 → 系统根本不管返回值 修改 Agent 运行上下文的注入点 → 只有 1 个 官方底线 就算插件代码跑崩了也绝不拖垮 Agent 的主循环 底层逻辑 把开发者当成潜在敌人 → 只开放最小必要接口 → 确保核心稳定性十、局限性与诚实说明┌──────────────────────────────────────────────────────────┐ │ 1. 记忆容量硬上限 │ │ MEMORY.md 800 tokens / USER.md 500 tokens │ │ → 防止 token 爆炸需要 Agent 主动 curation │ │ → 但 Agent 可能判断不准什么该删 │ ├──────────────────────────────────────────────────────────┤ │ 2. Skill 质量依赖 LLM 自评估 │ │ → 早期可能需人工微调 │ │ → 社区反馈精心调制的技能被自动进化流程覆盖 │ ├──────────────────────────────────────────────────────────┤ │ 3. Curator 是周期性而非实时 │ │ → 每 7 天才运行一次 │ │ → 不会即时优化 │ ├──────────────────────────────────────────────────────────┤ │ 4. 反思质量存疑 │ │ → Agent 判断是否完成时几乎总觉得自己成功了 │ │ → 反思出来的记忆非常薄弱 │ ├──────────────────────────────────────────────────────────┤ │ 5. 不适合零容错场景 │ │ → 核心合同、底层代码、财务模型 → 全自动是隐患 │ │ → 容错率高的日常重复任务 → 能站得住 │ ├──────────────────────────────────────────────────────────┤ │ 6. 依赖强模型做反思 │ │ → 弱模型执行 routine 可以但反思质量不够 │ └──────────────────────────────────────────────────────────┘十一、ima.copilot 中的映射Hermes 原版ima.copilot 版本作用MEMORY.mdmemory_md持久化事实与决策USER.mduser_md用户档案skills/ SKILL.mdSkill 系统use_skill技能加载与执行FTS5 SQLiteqa层会话上下文跨会话检索state.dbsessionsdaily层日摘要短期记忆Honcho User Modeling—暂无对应用户建模GEPA 进化引擎—暂无对应技能自动进化Curator—暂无对应技能周期剪枝Periodic Nudgesmemory_write用户触发记忆持久化ima.copilot 采用了 Hermes 的记忆架构思路双文件 层级分离但暂未集成 GEPA 进化引擎和 Honcho 用户建模。十二、演进弧线从激进到克制2026.02.25 Hermes 首发 旗号与你共同成长的 Agent 路线主动记忆、自动进化、强行替用户做决定 → 一口气冲到 57,200 颗星 ↓ 2026.04.03 v0.7.0 韧性更新 悄悄往回撤了半步 → Honcho 从唯一高级后端降级为可插拔后端之一 → 纯文件 全文检索成为默认兜底 → 把记忆的选择权交还给了用户 ↓ 先行者在撞上社区真实投诉后的战略让步 → 觉得现在的规则系统还吃不透所有复杂场景 → 有些选择不必强行替用户做同时OpenClaw 在反方向补课2026.04.05 OpenClaw 发布 Dreaming → 离线记忆整理短期流水文档 → 提炼 → 晋升为 MEMORY.md ↓ 2026.04.10 OpenClaw 发布 Active Memory → 主回复前跑记忆子 Agent → 大模型做裁判的主动派打法 → 粒度比 Hermes 固定 15 轮一次的微调更细 ↓ 大家全都在往替你做决定这条路上靠 Hermes 只不过下注最早、最狠十三、选型指南选择 Hermes如果你需要✅ 长期陪伴、越用越懂的 AI 伙伴 Honcho 用户建模 持续技能生成 数周后 Agent 会记住你的编码规范和决策偏好 ✅ 复杂、重复性高的研发任务 代码分析、数据处理、研究流程的效率复利 第一次生成技能后后续速度提升 40% ✅ 深入定制会学习的 AI 基于 Python DSPy 的架构 可以介入学习循环修改进化算法 作为研究平台使用不选择 Hermes如果你需要❌ 零容错的关键业务 核心合同、底层代码、财务模型 全自动模式本身是隐患 ❌ 严格的合规与审计控制 Gateway 的多 Agent 路由、RBAC、策略引擎 金融、医疗等行业的治理要求 ❌ 快速搭建、稳定优先 700 社区技能几小时连全渠道 不想等 Agent 慢慢学习十四、总结Hermes 的智能不是功能多而是闭环正反馈——Agent-Curated Memory 把记忆从被动存储变成主动管理Skill Auto-Creation 把经验从一次性消耗变成可复用资产FTS5 LLM Recall 把历史从归档文件变成活的检索库GEPA 把技能优化从人工调参变成算法驱动的进化Honcho 把用户理解从静态配置变成辩证式建模Curator 把技能库从无限膨胀变成有序收敛用得越多 → 提炼越多 → 检索越准 → 改进越快 → 三个月后你拥有一个真正共事多年的 Agent。但这不是魔法——它是一套精心设计的工程机制把越用越聪明从口号变成系统行为。每一步都有硬规则兜底每一次进化都需要人类审查。Hermes 赌的不是今天能多完美而是未来模型更强时它的架构能最先吃到红利。