1. Hermes Agent 架构定位与设计哲学
在AI Agent领域,Hermes的定位非常明确——它首先是一个执行引擎,其次才是接入平台。这种定位决定了其架构设计的核心关注点与其他Agent系统有着本质区别。
1.1 执行引擎 vs 网关调度
OpenClaw这类系统更关注消息的路由和分发,像一个"多渠道个人助理操作系统"。它们的核心价值在于:
- 统一接入各种消息平台(Telegram、Slack等)
- 实现消息的智能路由和分发
- 提供丰富的可视化界面
而Hermes的设计哲学完全不同。它的核心价值体现在:
- 任务执行的完整闭环
- 执行经验的自动沉淀
- 系统能力的持续进化
这种差异在代码组织结构上体现得非常明显。Hermes的核心代码集中在run_agent.py(主执行循环)和model_tools.py(工具编排),而gateway目录相对次要。这种代码布局明确传达了设计者的意图:执行和进化优先,接入和分发其次。
1.2 渐进式演进的设计理念
Hermes采用了一种非常务实的设计理念:在有限的上下文窗口内实现渐进式演进。这体现在几个关键设计选择上:
- 严格的字符预算:记忆系统有明确的字符限制(MEMORY.md约2200字符,USER.md约1375字符)
- 冻结快照模式:会话开始时捕获一次记忆快照,会话中不再更新
- 按需召回机制:长期记忆通过SQLite+FTS5实现按需检索
这种设计虽然牺牲了一些实时性,但带来了显著的性能优势:
- 保持Prefix Caching稳定,减少重复计算
- 降低长会话的推理成本
- 确保系统在轻量级模型上也能高效运行
提示:这种设计特别适合需要长期运行、频繁交互的场景。牺牲一点实时性换取系统稳定性,在工程实践中往往是值得的。
2. Skill系统的工程实现
Hermes的Skill系统是其"自进化"能力的核心体现。与常见的"达到阈值就自动保存"的简单实现不同,Hermes采用了一套精巧的前后台分离架构。
2.1 前台:基于提示词的经验引导
在agent/prompt_builder.py中,系统会向LLM注入SKILLS_GUIDANCE提示:
python复制SKILLS_GUIDANCE = """
After completing a complex task (5+ tool calls),
fixing a tricky error, or discovering a non-trivial workflow,
save the approach as a skill...
"""
这个设计有几个精妙之处:
- 柔性触发:使用"5+ tool calls"这样的经验阈值而非硬编码触发器
- 自主判断:依赖LLM自主决定"是否值得记录"
- 自然语言描述:用人类工程师熟悉的语言表达记录标准
这种设计保持了Agent的自主性,但也引入了不确定性——有价值的操作可能被遗漏,而不重要的操作可能被记录。
2.2 后台:异步Review机制
真正的Skill沉淀发生在对话结束后。系统会fork一个静默的子Agent执行以下流程:
- 对话历史回看:子Agent以只读模式审视完整执行轨迹
- 价值判断:依据预设标准评估是否值得固化
- Skill生成/更新:有价值则写入Markdown文件,否则返回"Nothing to save"
这个设计的关键价值在于:
- 不阻塞主对话:Skill沉淀是后台异步进行的
- 不争夺注意力:不影响当前任务的执行效率
- Best-effort策略:能记就记,记不了也不影响核心功能
2.3 Skill的双通道加载机制
生成的Skill通过两条路径发挥作用:
| 加载层级 | 实现方式 | 内容 | 性能影响 |
|---|---|---|---|
| 索引层 | build_skills_system_prompt()扫描目录 | 仅名称和描述 | 低(LRU缓存+磁盘快照) |
| 按需层 | skill_commands.py注入 | 完整内容 | 中(破坏Prefix Caching) |
这种分层设计既保证了系统提示不会过度膨胀,又能在需要时获取完整Skill内容。
3. 记忆系统的分层架构
Hermes的记忆系统采用三层设计,在性能和功能之间取得了很好的平衡。
3.1 快照层:冻结注入的短记忆
快照层由两个Markdown文件组成:
| 文件 | 内容 | 大小限制 | 更新频率 |
|---|---|---|---|
| MEMORY.md | Agent个人笔记(环境事实、技术栈、踩坑经验) | ~2200字符 | 会话开始时冻结 |
| USER.md | 用户画像(沟通风格、偏好、角色设定) | ~1375字符 | 会话开始时冻结 |
这种"冻结快照"模式虽然牺牲了记忆的实时性,但带来了显著的性能优势:
- 保持Prefix Caching稳定
- 减少重复计算
- 降低长会话的推理成本
3.2 检索层:SQLite+FTS5的历史库
长期记忆存储在~/.hermes/state.db中,关键设计包括:
- WAL模式:提高并发写入性能
- FTS5全文检索:高效搜索历史消息
- 按需召回:不一次性加载所有历史
检索接口示例:
python复制def session_search(keyword: str, limit: int = 3):
"""Search historical messages containing keyword"""
return db.execute(
"SELECT content FROM messages_fts WHERE content MATCH ? LIMIT ?",
(keyword, limit)
).fetchall()
这种设计实现了"记忆即搜索引擎"的理念,只在需要时召回相关片段,避免上下文窗口被无关历史填满。
3.3 辩证式建模(Honcho集成)
v0.7.0恢复了对Honcho的完整支持,提供更高级的用户建模能力:
- 观察:追踪用户连续选择
- 假设:推理用户特质
- 验证:在后续对话中检验假设
- 建模:形成动态更新的用户画像
Honcho支持三种召回模式:
- hybrid(混合检索+推理)
- context(直接注入系统提示)
- tools(按需查询)
4. 安全架构的七层纵深防御
Hermes构建了一套完整的安全防御体系,将安全保障从模型自觉提升到系统强制。
4.1 危险命令审批(Layer 2)
tools/approval.py维护了DANGEROUS_PATTERNS表,包含30+条正则规则:
python复制DANGEROUS_PATTERNS = [
(r'rm -rf', "recursive deletion"),
(r'chmod 777', "world-writable permissions"),
(r'dd if=', "disk overwriting"),
(r'DROP TABLE', "destructive SQL"),
# ...其他规则
]
审批模式三档可调:
- manual(默认):所有危险操作需人工确认
- smart:LLM评估风险,自动处理简单情况
- off:关闭审批(不推荐)
4.2 上下文注入扫描(Layer 5)
所有外部上下文文件在注入系统提示前需经过_CONTEXT_THREAT_PATTERNS扫描:
python复制_CONTEXT_THREAT_PATTERNS = [
(r'ignore\s+(previous|all|above|prior)\s+instructions', "prompt_injection"),
(r'curl\s+[^\n]*\$\{?\w*(KEY|TOKEN|SECRET)', "exfil_curl"),
# ...其他规则
]
这种"模型看到之前"的防御策略,比事后拦截更有效。
4.3 完整的七层防御体系
| 层级 | 防御措施 | 实现方式 |
|---|---|---|
| Layer 1 | 输入验证 | 白名单校验 |
| Layer 2 | 命令审批 | 正则模式匹配 |
| Layer 3 | 容器隔离 | Docker/Singularity |
| Layer 4 | 凭据过滤 | MCP子进程隔离 |
| Layer 5 | 注入防护 | 上下文扫描 |
| Layer 6 | 会话隔离 | 数据不互通 |
| Layer 7 | 环境加固 | 工作目录限制 |
这种纵深防御设计确保了即使使用较弱的开源模型,系统层面也能提供基线安全保障。
5. Tinker-Atropos RL训练飞轮
Hermes真正的技术壁垒在于其背后的强化学习训练基础设施。
5.1 训练流程概述
- 轨迹收集:大量用户运行Hermes Agent产生执行轨迹
- GRPO训练:使用Group Relative Policy Optimization算法
- LoRA微调:高效调整模型参���
- 模型发布:通过OpenRouter提供服务
- 反馈循环:更多用户使用产生新数据
5.2 确定性奖励设计
GRPO使用确定性奖励函数,无需训练昂贵的Reward Model:
| 评判维度 | 奖励值 | 标准 |
|---|---|---|
| 格式正确 | +0.2 | 合法JSON,tool_call标签正确 |
| Schema匹配 | +0.3 | 参数类型符合定义 |
| 执行成功 | +0.5 | 工具运行无报错 |
| 任务完成 | +1.0 | 最终结果正确 |
| 幻觉惩罚 | -1.0 | 调用不存在工具 |
这种设计使得训练过程更稳定、可解释。
6. 工程实现亮点
除了核心架构,Hermes在工程细节上也展现了高水平的设计。
6.1 多API原生对接
同时支持三种原生接口:
- OpenAI (chat_completions)
- OpenAI Codex (codex_responses)
- Anthropic (messages)
避免兼容层带来的性能损耗。
6.2 六种执行后端
| 后端 | 特点 | 适用场景 |
|---|---|---|
| Local | 本地执行 | 开发测试 |
| Docker | 容器隔离 | 生产环境 |
| SSH | 远程执行 | 分布式部署 |
| Modal | 无服务器 | 按需计算 |
| Daytona | 云端托管 | 企业级 |
| Singularity | HPC环境 | 科研计算 |
6.3 其他工程优化
- Profile隔离:单机运行多个隔离实例
- Credential Pool:API Key自动轮转
- MCP双向支持:既作Server也作Client
- 14平台网关:统一接入主流消息平台
7. 架构演进建议
基于对Hermes架构的深入分析,以下是几个可能的演进方向:
- Skill质量控制系统:引入LLM+规则的双重校验,提高Skill沉淀的准确性
- 记忆压缩算法:在保持冻结快照的同时,通过摘要压缩更多信息
- 分布式训练:扩大RL训练规模,加速模型进化
- 安全态势感知:增加运行时安全监控和预警
这些演进可以在保持架构核心优势的同时,进一步提升系统的能力和可靠性。
