LangChain教你搭积木，CrewAI教你编队，AutoGen教你开会。但有一个问题它们都没解决：你的Agent昨天犯的错，今天还会再犯。Nous Research的Hermes Agent用14万行Python代码给出了一个不同的答案——让Agent从自己的经验中创建技能，在使用中改进技能，跨会话记住你是谁。这不是又一个LLM wrapper，这是一个会自我进化的AI操作系统。
141K
Python生产代码行数
12个
消息平台适配器
74个
内置技能
6种
终端执行后端
为什么又一个Agent框架？因为别人都在造工具，它在造大脑
先看一组对比：
| 能力 | Hermes Agent | LangChain | CrewAI | AutoGen |
|---|---|---|---|---|
| 闭环学习 | 内置技能创建+改进 | 无 | 无 | 无 |
| 多平台消息 | 12个适配器开箱即用 | 需自建 | 有限 | 无 |
| 持久化记忆 | Honcho用户建模+FTS5搜索 | 基础Chain | 无 | 无 |
| 上下文压缩 | 迭代式LLM摘要 | 无 | 无 | 无 |
| MCP集成 | 完整支持+OAuth 2.1 | 无 | 无 | 无 |
| 成本追踪 | 按会话+按供应商计费 | 部分 | 无 | 无 |
关键差异在闭环学习。LangChain的Agent执行完任务就结束了，下次还是从零开始。Hermes Agent不同——它会在复杂任务完成后自动创建.md格式的技能文件，下次遇到类似问题直接调用，而且技能会在使用中持续改进。这个机制让Agent越用越聪明，而不是每次都重新发明轮子。
架构拆解：六层递进，每层都有亮点
Hermes Agent的代码组织遵循清晰的分层架构，202个Python模块各司其职。从上到下拆解：
第一层：入口与网关
网关层（gateway/ 目录，约28万行代码）是最重的一层。核心文件gateway/run.py达到6332行，承担了所有平台的消息路由、会话管理和指令解析。12个平台适配器覆盖了企业通讯的主流场景：
- 国际平台：Telegram、Discord、Slack、WhatsApp、Signal、Matrix、Email、SMS
- 国内平台：钉钉（DingTalk）、飞书（Feishu）
- 开发者工具：Mattermost、原生CLI
Gateway还内置了OpenAI兼容的HTTP API（/v1/chat/completions），意味着你可以把Hermes Agent当作一个增强版的LLM API端点，直接替换现有系统中的OpenAI调用。
第二层：Agent核心
run_agent.py（8492行）是大脑。核心是一个带工具调用的对话循环，单次对话最多执行90次迭代。几个值得关注的设计：
迭代式上下文压缩（agent/context_compressor.py，2030行）——这是我看过的最精巧的上下文管理方案：
- 按token预算（不是消息数量）保护头部和尾部消息
- 先做廉价预处理：裁剪旧的工具输出结果
- 再用辅助廉价模型（比如Haiku 4.5）生成摘要
- 后续压缩时，把上一次摘要和新消息一起喂给LLM，增量更新
- 摘要预算上限：压缩内容的20%，但不超过12K tokens
SUMMARY_PREFIX = "[CONTEXT COMPACTION] Earlier turns compacted..."
_SUMMARY_RATIO = 0.20 # 分配压缩内容的20%给摘要
_SUMMARY_TOKENS_CEILING = 12_000 # 摘要永远不超过12K tokens
辅助模型系统（agent/auxiliary_client.py，1926行）——主模型负责推理和决策，辅助模型负责视觉分析、文本摘要、采样等低复杂度任务。这让你可以用Claude Opus做核心推理，同时用Haiku做上下文压缩，成本降低10倍。
第三层：工具注册表——解决循环导入的优雅方案
tools/registry.py只有约110行代码，但它解决了所有Agent框架都头疼的问题：工具文件之间的循环导入。
传统方案是在一个大文件里import所有工具，但这会导致任何工具的import失败都连累整个系统。Hermes Agent的方案：
注册表模式
每个工具文件在模块级别调用registry.register()，声明名称、所属工具集、JSON Schema和处理函数。工具之间完全不互相import。
懒发现
model_tools.py（仅472行）在需要时才触发_discover_tools()，通过importlib.import_module()加载约21个工具模块。
失败隔离
某个工具import失败（比如缺少依赖）只会记录日志，不会影响其他工具和Agent启动。
这个设计模式值得所有Agent框架借鉴。在FluxWise智流科技的企业Agent平台设计中，我们也采纳了类似的注册表模式来管理可插拔的业务技能。
第四层：技能系统——Agent的长期记忆
74个内置技能 + 50多个可选技能，全部用Markdown格式存储（YAML frontmatter + Markdown正文），兼容agentskills.io标准。技能系统采用渐进式披露：
- 元数据层：名称、描述、触发条件——用于快速匹配
- 完整指令层：详细的执行步骤——匹配成功后加载
- 关联引用层：模板文件、参考文档——按需加载
最有趣的是技能自动创建。当Agent完成一个复杂多步骤任务后，会自动将操作序列提炼为新的技能文件。下次遇到类似问题，直接调用技能而不是重新推理。虽然目前还是实验性功能，但这个方向指向了一个真正能积累经验的AI系统。
第五层：记忆与持久化
三层记忆架构：
Honcho用户建模——通过辩证问答（Dialectic Q&A）构建用户画像，语义搜索 + LLM合成。效果是Agent能说出"根据我们上次讨论的X..."这样的话。
会话搜索——SQLite + FTS5全文搜索虚拟表，6次版本化schema迁移。LLM驱动的跨会话回忆，不是简单的关键词匹配。
程序性记忆——用户的MEMORY.md和人设的SOUL.md，持久化存储在文件系统中。
第六层：智能模型路由
agent/smart_model_routing.py（168行）实现了一个轻量但实用的多模型路由：
- 检测到速率限制 → 立即切换到备用模型
- 上下文逼近极限 → 建议更便宜的替代
- 多供应商感知：通过models.dev注册表 + 自定义端点元数据做模糊匹配
这对企业用户意味着：一个配置文件搞定多供应商failover，不需要在代码层面处理OpenAI和Anthropic的差异。
MCP集成：不是玩具级别的
很多框架说支持MCP（Model Context Protocol），但Hermes Agent的实现深度是另一个量级：
- 完整的OAuth 2.1 PKCE流程：支持GitHub、Google等现代MCP服务器的认证
- CSRF防护 + 状态验证：生产级安全标准
- Token自动刷新：长时间运行的Agent不会因为token过期中断
- 采样支持：MCP服务器可以在工具调用过程中请求LLM补全
- 细粒度控制：每个MCP服务器可以单独设置RPM限制、token上限、模型覆盖
tools/mcp_tool.py + tools/mcp_oauth.py合计2019行代码，这不是一个demo，这是生产级实现。
六种终端后端：从笔记本到HPC集群
Agent执行工具时需要一个运行环境。Hermes Agent提供了6种选择：
| 后端 | 适用场景 | 成本 | 隔离性 |
|---|---|---|---|
| 本地Shell | 开发调试 | 免费 | 无 |
| Docker容器 | 安全执行 | 低 | 高 |
| 远程SSH | 已有服务器 | 已有 | 中 |
| Modal Serverless | 按需计算 | 按秒计费 | 完全隔离 |
| Daytona持久容器 | 需要状态保持 | 低 | 高 |
| Singularity HPC | 科研计算 | 看集群 | 完全隔离 |
Modal后端特别有意思：Agent空闲时几乎不花钱（不到1美分），需要执行代码时自动启动GPU实例。这对制造业企业来说很实际——你的AI Agent不需要24小时占用服务器资源，只在有任务时按需消耗。
工程质量：3700个测试不是摆设
- 372个测试文件，约3700个测试用例
- 集成测试用
@pytest.mark.integration标记分离 - pytest-xdist支持并行执行
- 依赖版本全部pin范围锁定（供应链安全）
- Pydantic 2.12+做数据验证
- 全面的类型标注
代码中有几个值得学习的工程细节：
线程安全的异步桥接（model_tools.py）——Python异步编程最常见的坑是asyncio.run()创建事件循环后关闭，导致缓存的httpx/AsyncOpenAI客户端报"Event loop is closed"错误。Hermes Agent用threading.local()为每个线程维护持久事件循环，三种场景各有处理路径：主CLI线程、异步上下文、工作线程。
结构化摘要模板——上下文压缩生成的摘要遵循固定格式：目标、进展、决策、文件变更、下一步。这确保压缩后的信息仍然是可操作的，而不是模糊的概括。
企业落地：强在哪里，弱在哪里
auto_awesome企业级优势
多租户消息网关——12个平台适配器 + 会话隔离，构建内部Slack/钉钉机器人不需要自己写平台SDK。
成本可控——按供应商计费追踪、上下文压缩减少token消耗、辅助模型分流低复杂度任务、速率限制自动降级。
审计合规——SQLite会话存储记录完整的消息历史、工具调用日志、成本明细，可导出用于GDPR/SOX合规。
安全防护——危险工具执行前需要审批、路径遍历保护、提示注入防御、错误信息中的凭据剥离。
自托管——$5/月的VPS就能跑，不依赖任何云厂商。MIT协议，可商用。
但也有硬伤：
- 单进程限制——没有集群/分布式Agent池，不能横向扩展。每个VPS运行一个Agent实例
- Gateway耦合——6332行的核心路由文件，扩展新平台需要改核心代码
- 无向量检索——记忆搜索依赖FTS5全文匹配，语义召回能力弱
- 团队文档不足——教程面向个人开发者，缺少企业级部署指南（多人协作、密钥管理、监控告警）
判断：谁应该用，谁不该用
适合的场景：
- 需要一个记住用户、越用越好的内部AI助手
- 需要在钉钉/飞书/Slack等现有工具中部署AI能力
- 研发团队想用Agent做论文阅读、代码审查、知识积累
- 预算有限，需要多模型智能路由控制成本
不适合的场景：
- 需要数百个Agent并发处理任务的高吞吐系统
- 需要深度定制每个环节的工程团队（不如用LangChain自己搭）
- 只需要简单的ChatBot功能（杀鸡用牛刀）
Hermes Agent的定位很清晰：它不是一个库，是一个产品。你不是在它基础上构建，而是直接部署它、配置它、让它自己进化。对于80%的企业AI应用场景，这可能才是正确的姿势——与其花3个月用LangChain从零搭建一个Agent，不如花3天部署Hermes Agent，然后让它自己学会你的业务。