Hermes Agent 架构深度解析
核心问题：大多数 Agent 框架，其实都是"无状态"的
用 LangChain、AutoGPT、OpenClaw 这些框架时，你会发现一个共同点：它们是任务的执行器，但不是经验的积累者。
你让它做了一件事，下次遇到完全一样的场景，它不会说"这件事我上个月做过，当时用的是 X 方法"。记忆是分立存储的，技能是人手工维护的，Agent 本身不会从工作流里提取规律。
这是 Hermes 试图解决的核心问题。
---
Hermes 的聚焦点：让 Agent 自己长本事
Hermes 花最多笔墨设计的，不是 API 抽象、不是工具注册、不是多平台网关——这些它都有，但这些是手段，不是目的。
它的核心聚焦点是：让 Agent 在完成任务的过程中，把经验凝固成可复用的技能（Skill），并在后续使用中持续改进这些技能。
具体来说：Agent 完成任务后，如果发现这个工作流以后还会出现，就把它写成一个 Skill 文件。下次遇到同类任务，直接加载这个 Skill，边用边改进。如果发现 Skill 里有错误，直接改，改完下次就生效。
这意味着一个持续运行的 Hermes 实例，会随着使用变得越来越"懂行"——它记住你用什么工具、习惯什么流程、在哪些地方容易出错。这些不是靠人工配置的，是它自己长出来的。
---
这个目标导向的架构选择
围绕"让 Agent 自己长本事"这个目标，Hermes 做了一些配套的设计。
记忆系统是被动积累，技能系统是主动沉淀。 记忆系统（MEMORY.md、USER.md）是 Agent 用来记住事实和偏好的地方，容量有上限（2,200 和 1,375 字符），满了必须整理。这逼迫 Agent 保持记忆的高密度，而不是什么都往里塞。技能系统则是 Agent 自己写给自己的操作手册，可以不断扩充。两套系统各司其职。
会话开始时注入记忆，然后用冻结的快照贯穿整个会话。 这是个务实的工程决策。会话过程中记忆可能更新，但如果每次更新都重建系统提示词、实现会变得复杂，而且推理过程可能因为记忆突变而出现跳跃。Hermes 选择让快照在会话内稳定，用工程简洁性换取一致性。代价是记忆更新有延迟——这次会话的改动，下次会话才生效。
对话历史的检索走 SQLite + FTS5。 跨会话搜索历史对话是个真实需求，但为了这个功能额外部署 Elasticsearch 太重了。Hermes 用 SQLite 的全文搜索扩展实现同样的能力，LLM 总结搜索结果，而不是直接返回长文本。这套组合对轻量部署很友好。
三种 API 模式在内部统一。 chat_completions、codex_responses、anthropic_messages 这三种接口格式不同，但 Hermes 把它们在内部统一成 OpenAI 的消息结构。核心代码不感知差异，换模型不需要动核心逻辑。这是典型的抽象层思维——把变化的部分隔离开。
可中断的 API 调用。 /stop 命令、新消息覆盖旧消息、Ctrl+C——这些操作在 Hermes 里是干净的：中断信号到达时，API 线程被放弃，partial response 直接丢弃，不往对话历史里写半成品消息。代价是浪费一次 API 调用的费用，好处是 history 一致，不需要写额外的容错逻辑。
多执行后端的隔离。 Terminal 后端支持六种（local、Docker、SSH、Daytone、Singularity、Modal），Browser 后端支持五种，Daytone 和 Modal 还支持环境休眠。执行环境和对话入口完全分离——你从 Telegram 发消息，Agent 可以跑在云端的 Modal 环境里，你不需要 SSH 进去维护。
回调钩子让 UI 层可替换。 Agent 运行过程中的状态变化（工具执行、模型思考、流式输出）都通过明确的回调接口暴露。CLI 实现一部分回调，Telegram 实现另一部分，Discord 再实现另外一部分，核心代码不写任何 UI 逻辑。
---
一些保留意见
Skill 的自我演进是这个框架最有野心的部分，也是风险最高的。Agent 自己生成代码、自己改进——错误会累积，回滚机制没有在文档里看到详细说明。另外，项目的维护依赖小团队热情，生态建设也需要时间。
---
总结
Hermes 的核心创新不是什么新技术，而是一个明确的目标：让 Agent 自己在工作流里积累经验，而不是每次都从零开始。
围绕这个目标，它的架构选择方向是清晰的：用有界的资源迫使系统主动管理（记忆容量限制）；用冻结快照换取工程简洁和推理一致性；用抽象层隔离变化（API 模式、UI 回调、执行后端）；用 SQLite + FTS5 在轻量部署下实现全文搜索。
不是一个炫技的项目，是一个知道自己在解决什么问题的项目。