Hermes Agent 深度实战：当我们终于造出「越用越聪明」的 AI Agent——从自进化闭环、三层记忆架构到 200+ 模型接入的完整工程指南（2026）

2026年2月，Nous Research 发布 Hermes Agent，两个月 GitHub Star 突破 11 万。有人说它是「爱马仕」，有人说它是 OpenClaw 的最强挑战者。但当你深入它的源码，会发现这些标签都太浅了——它的真正价值在于：把「自我进化」从营销词汇变成了工程现实。

一、背景：为什么现有的 Agent 框架都卡在了同一个地方

过去两年，我们见过太多 Agent 框架：LangChain、AutoGPT、Claude Code、CrewAI……它们解决的问题很清晰：怎么让 LLM 调用工具，怎么做计划，怎么分解任务。

但所有这些框架都有一个共同的致命缺陷：它们不会成长。

你用 AutoGPT 跑了一个月的项目，它依然每次从零开始。同样的问题，它会犯同样的错，需要你重复同样的解释。Agent 的「经验」永远留在对话里，一旦会话结束，一切都消失。

这不是 Bug，是设计上的根本性取舍——大多数框架把 Agent 当成「工具的调用器」，而不是「会学习的系统」。

Hermes Agent 的切入点就在这里。它的核心问题不是「怎么让 Agent 调用工具」，而是「怎么让 Agent 在每次调用中变得更好」。

二、核心定位：从「会调用工具」到「会自我进化」

Hermes Agent 的官方定位是 self-improving AI agent，官方 slogan 是「A personal AI agent that gets smarter the more you use it」。

这两个短句背后的工程量是巨大的。

大多数 Agent 框架的架构是：用户 → LLM → 工具 → 返回结果。

Hermes Agent 的架构是：用户 → LLM → 工具 → 结果评估 → 记忆沉淀 → 技能生成 → 下次复用 → 循环。

区别在于有没有后半段。那后半段具体是怎么实现的？

2.1 自进化学习闭环的五步机制

Hermes Agent 的自进化不是靠人工维护知识库，而是由 Agent 自己驱动整个闭环：

完成任务 → 策划记忆 → 创建 Skill → Skill 自改进 → FTS5 召回 → 用户建模 → （循环）

策划记忆：任务完成后，Agent 自主判断什么值得记住。不是全量存储，是选择性提炼。这个决策由 LLM 本身做出，取决于当前任务的复杂度、错误次数和可复用性。

创建 Skill：当 Agent 发现某个任务模式出现两次以上，它会自动生成一个 Markdown 格式的 Skill 文件。Skill 包含触发条件、具体步骤和注意事项。生成的 Skill 会经过自测验证——Agent 会模拟执行一次，确保流程正确。

Skill 自改进：当已有的 Skill 在执行中失败（比如依赖的 API 变了），Agent 会自动分析失败原因并修复 Skill 内容，不需要人工介入。

FTS5 召回：通过 SQLite 的全文索引（FTS5）按需检索历史对话。检索到的内容会用轻量模型做摘要，只注入最相关的片段，避免 token 爆炸。

用户建模：基于 Honcho 协议，从用户行为中持续推断和更新用户画像（偏好、沟通风格、工作习惯）。

这五步对应认知科学中的三种记忆类型：

• 情景记忆：会话历史 → FTS5 检索
• 语义记忆：持久事实 → MEMORY.md
• 程序性记忆：执行流程 → Skill 文件

把认知科学的框架映射到工程实现上，这个设计思路是自洽的。

三、架构概览：3 万行 Python 代码里的工程哲学

截至 v0.14.0，Hermes Agent 约有 3 万行 Python 代码（不含网站和测试），这个体量的项目值得认真拆解。

3.1 目录结构与职责划分

架构上几个关键决策值得重点说：

第一，Agent 循环和工具执行在同一进程。 run_agent.py 中的 AIAgent 类管理整个生命周期，没有走微服务那套。这对部署简单性和状态共享是最优解——所有状态都在内存里，跨调用没有序列化开销。

第二，工具自注册模式。 每个工具文件在模块级别调用 registry.register() 声明自己，不需要中心化的注册表。发现机制通过 AST 分析检测哪些 .py 文件包含注册调用，零配置。

第三，SQLite + WAL 模式。 单文件数据库，支持多读者 + 单写者，适合网关多平台并发的场景。WAL 模式保证写入不阻塞读取，这对同时连接 Telegram 和 Discord 的场景很重要。

第四，Profile 系统。 v0.6.0 引入多实例 Profile，每个 Profile 拥有独立的配置、记忆库、会话历史、Skill 集合和工具权限。相当于在同一台机器上跑多个完全隔离的 Agent 进程——工作用一个，个人用另一个。

3.2 内存占用与部署门槛

不跑本地 LLM 的情况下，Agent 进程本身占用不到 500MB。官方宣称可以在 $5/月的 VPS 上运行，这个数据从架构看是合理的——SQLite 很轻量，主要开销在对话历史的内存占用，这部分通过上下文压缩和冻结快照做了控制。

四、Agent 循环深度拆解：控制机制比你想的更精密

run_agent.py 中的 AIAgent 类是整个系统的心脏，理解它的循环机制是关键。

4.1 基本流程

接收用户消息 → 构建请求（含 system prompt + 记忆 + 上下文）
→ 调用 LLM → 解析响应
→ 如果包含工具调用则执行工具 → 把工具结果加入上下文
→ 再次调用 LLM → 直到 LLM 不再请求工具调用
→ 返回最终响应

这个循环有几个关键的控制机制：

4.2 迭代预算控制

IterationBudget 类实现了一个线程安全的迭代计数器，防止 Agent 陷入死循环。

# 父 Agent 默认 90 次迭代
# 子 Agent（子代理）默认 50 次迭代
MAX_ITERATIONS_PARENT = 90
MAX_ITERATIONS_CHILD = 50

这个设计解决的是：Agent 有时会陷入死循环，反复调用同一个工具。迭代预算是硬上限，到了就强制停止，防止 token 和费用失控。

4.3 并行工具执行

Agent 循环中的工具分类策略把工具分成三类：

_NEVER_PARALLEL_TOOLS = {"clarify"}  # 需要用户交互，永不并行
_PARALLEL_SAFE_TOOLS = {"web_search", "read_file"}  # 纯读操作，可安全并行
_PATH_SCOPED_TOOLS = {"write_file", "patch"}  # 写操作，需路径隔离后条件并行

_MAX_TOOL_WORKERS = 8  # 最大并发工作线程数

路径隔离检查确保两个写操作不会同时改同一个文件：

def _check_path_conflict(tool_calls):
    """检查两个写操作是否操作同一路径或子目录"""
    written_paths = set()
    for call in tool_calls:
        if call.tool in _PATH_SCOPED_TOOLS:
            path = call.params.get("path", "")
            # 路径规范化：解析 .. 和符号链接
            normalized = Path(path).resolve()
            for existing in written_paths:
                if normalized == existing or normalized.is_relative_to(existing):
                    return True  # 路径冲突，禁止并行
            written_paths.add(normalized)
    return False

这套分类策略的底层逻辑是：真正的工程系统中，大多数工具调用是读多写少。并行执行能显著缩短总执行时间，同时通过路径隔离保证正确性。

4.4 中断与转向机制

Agent 执行过程中可能会收到用户的新指令（比如用户在 Agent 运行时又发了一条消息）。处理方式用双标志位：

_interrupt_requested = False   # 中断请求
_pending_steer = None          # 待注入的转向指令

设计原则：不打断正在执行的工具，等当前工具批次完成后再处理。原因是 write_file 如果被打断，可能导致文件写了一半。保证操作的原子性，这个选择很务实。

4.5 System Prompt 组装：两级缓存加速

PromptBuilder 负责组装完整的 system prompt，包含多个层次：

组装在会话开始时完成并缓存——这保证了 LLM API 的 KV Cache（前缀缓存） 命中率。每次对话只计算一次前缀 token 的 KV 对，后续请求直接复用，大幅降低延迟和费用。

五、工具系统：自注册 + Toolset 组合

5.1 ToolRegistry 的自注册模式

传统的工具系统是中心化的注册表，新工具需要修改注册表代码。Hermes Agent 反其道而行：工具自己注册自己。

# tools/registry.py 中的注册结构
class ToolEntry:
    name: str           # 工具名
    toolset: str        # 所属工具集
    schema: dict        # JSON Schema（参数定义）
    handler: callable   # 处理函数
    check_fn: callable # 前置环境检查
    requires_env: bool # 是否需要执行环境
    is_async: bool     # 是否异步执行
    description: str   # 工具描述
    emoji: str         # CLI 显示图标

每个工具文件在模块级别调用注册：

# tools/terminal.py
from .registry import registry

def terminal_handler(params):
    """执行 Shell 命令"""
    cmd = params.get("command", "")
    timeout = params.get("timeout", 30)
    return subprocess.run(cmd, shell=True, timeout=timeout, capture_output=True)

registry.register(
    name="terminal",
    toolset="hermes-core",
    schema={
        "type": "object",
        "properties": {
            "command": {"type": "string", "description": "要执行的命令"},
            "timeout": {"type": "integer", "description": "超时时间（秒）", "default": 30}
        },
        "required": ["command"]
    },
    handler=terminal_handler,
    check_fn=lambda: shutil.which("bash") is not None,
    requires_env=True,
    is_async=False,
    description="Execute shell commands in the terminal",
    emoji="🖥️"
)

发现机制 discover_builtin_tools() 通过 AST 分析自动检测所有包含 registry.register() 的 .py 文件，零配置。新增一个工具只需要创建一个新文件，Agent 启动时自动发现并注册。

5.2 Toolset 组合系统

核心工具集 _HERMES_CORE_TOOLS 包含 63 个工具，所有平台共享：

平台特定的 toolset（hermes-telegram、hermes-discord 等 20+ 个）通过 includes 引用核心工具集，只需要定义平台特有部分：

# hermes-telegram.toolset
includes:
  - hermes-core        # 引用核心工具集
tools:
  - telegram_send_message    # 飞书特有工具
  - telegram_get_updates
  - telegram_format_response

这种组合式设计的好处：新平台接入成本极低。新增一个飞书适配器，不需要重复定义 web_search，只需要定义飞书特有的消息 API。

5.3 MCP 双向支持：接入 6000+ 工具

MCP（Model Context Protocol）是 2026 年工具调用领域的重要协议。Hermes Agent 对 MCP 的支持是双向的：

作为 MCP 客户端：可以连接外部 MCP 服务器，动态注册对方的工具。

# mcp_client.py 动态注册外部 MCP 工具
async def connect_mcp_server(server_url: str):
    tools = await mcp_protocol.discover_tools(server_url)
    for tool in tools:
        registry.register(
            name=tool.name,
            toolset="mcp-external",
            schema=tool.inputSchema,
            handler=mcp_forward_handler(tool),  # 转发请求到 MCP 服务器
            is_async=True
        )

作为 MCP 服务端：可以被 Cursor、VS Code AI 插件等接入，成为这些编辑器的后端 Agent。

# mcp_serve.py MCP 服务端暴露
async def run_mcp_server(agent: AIAgent):
    server = MCPServer(agent)
    # 暴露 stdio 接口，兼容 MCP 协议
    await server.start()

六、记忆系统：三层架构与冻结快照

这是 Hermes Agent 和其他 Agent 拉开差距最大的地方。

6.1 三层记忆架构

Layer 1：内置记忆（Built-in Memory）

两个 Markdown 文件，存储在 ~/.hermes/memories/：

• MEMORY.md：Agent 的个人笔记。记录环境事实、项目约定、工具使用技巧、踩坑经验。2,200 字符上限，约 800 tokens。
• USER.md：用户画像。记录偏好、沟通风格、工作习惯。1,375 字符上限，约 500 tokens。

两者加起来固定 1,300 tokens，是会话启动时必注入的开销。这个上限设计很有意思——它强迫 Agent 做记忆提炼，不是把所有东西都扔进去。

Layer 2：外部记忆 Provider

支持 8 个可插拔后端，最常用的是 Honcho（Hermes 团队自研）。Honcho 基于轻量级的语义向量存储，提供更丰富的用户建模（12 个身份层次）。同时只激活一个外部 Provider。

Layer 3：会话搜索（Session Search）

所有历史会话存入 SQLite，带 FTS5 全文索引。需要时用关键词或语义检索找到相关历史片段，然后用轻量模型（Gemini Flash）做摘要，注入最相关的片段。

6.2 冻结快照模式：前缀缓存的工程实现

这个设计解决了一个很实际的问题：LLM API 的 KV Cache 效率。

如果不冻结快照，每次记忆更新都会改变系统 prompt 的前缀，导致 KV Cache 失效，后续每个 token 都要重新计算前面所有 token 的 KV 对——费用翻倍，延迟翻倍。

Hermes Agent 的解法是 读写分离：

# 会话开始时：创建快照并锁定
snapshot = memory_manager.get_snapshot()  # 获取当前记忆快照
system_prompt = build_with_snapshot(snapshot)  # 构建时锁定，之后不变

# 后续所有请求用同一个 system_prompt，前缀缓存命中率 100%
# 当前会话的更新只写磁盘，不刷新内存中的 system_prompt

# 会话进行中
memory_manager.update("new important info")  # 更新磁盘文件
# 系统 prompt 保持不变——直到下一个会话才生效

这个策略的代价：当前会话中对记忆的修改，需要等到下一个会话才能被读取。对于大多数场景，这个延迟是可接受的——你不会期望 Agent 在同一会话内「突然」意识到它刚才写错了。

6.3 记忆注入的安全机制

记忆系统有一个容易被忽视的安全设计：上下文围栏（Context Fencing）。

记忆内容注入时用 <memory-context> 标签包裹：

<memory-context>
[Agent 的记忆内容 - 环境事实、项目约定、踩坑经验]
</memory-context>

<user-message>
[用户当前输入]
</user-message>

这个标签有两个作用：

1. 帮助 LLM 区分「记忆的事实」和「用户当前的输入」
2. 安全扫描：检测注入/泄露模式，防止恶意指令通过记忆操控 Agent 行为

记忆条目之间用 §（section sign）分隔——选一个不常见的字符，降低与正文内容冲突的概率。

七、Skill 系统：让 Agent 学会「举一反三」

7.1 Skill 的本质

Skill 是 Hermes Agent 进化的最小单位。本质上是一个 Markdown 文件，记录了「怎么做某件事」的完整流程。

<!-- skills/my-project-deploy.md -->
# Project Deployment Skill

## 触发条件
When the user says "deploy project" or "发布项目"

## 执行步骤
1. cd to project root and run `git status` to check uncommitted changes
2. If uncommitted:
   - `git add .`
   - `git commit -m "auto-save before deploy"`
3. Run `npm run build` to create production bundle
4. rsync dist/ to production server
5. SSH into server and restart pm2 service: `pm2 restart myapp-prod`

## 注意事项
- Always check git status first — never deploy with uncommitted changes
- Server IP is stored in MEMORY.md under [production]
- PM2 service name: "myapp-prod"
- Run health check after deploy: `curl -f https://api.example.com/health`

7.2 Skill 的自生成过程

Skill 的生成不是靠模板匹配，而是 Agent 自主判断：

# skill_generator.py 核心逻辑
async def evaluate_for_skill(session_transcript: list[Message]):
    task_count = count_repetitive_tasks(session_transcript)
    
    if task_count >= 2:
        # 同一个任务出现2次以上，触发 Skill 生成
        pattern = extract_common_pattern(session_transcript)
        
        # 让 LLM 生成 Skill 草稿
        draft = await llm.generate_skill(
            prompt=f"""Based on the following task pattern, generate a Skill file.
            
            Pattern:
            {pattern}
            
            Output a complete Skill markdown file with:
            - Trigger conditions
            - Step-by-step execution
            - Important notes"""
        )
        
        # 自测：Agent 模拟执行一遍，验证流程正确性
        result = await agent.execute_skill(draft, dry_run=True)
        
        if result.success:
            await save_skill(draft)
            await log_skill_created(pattern, task_count)
        else:
            # 记录失败原因，供下次改进
            await log_skill_failure(pattern, result.error)

7.3 Skill 的渐进加载

Skill 系统面临一个 token 膨胀问题：随着使用时间增长，Skill 数量可能达到几十甚至上百个，全部加载进 context 不现实。

Hermes Agent 用三级按需加载解决：

这和操作系统的分页机制异曲同工——只加载正在使用的部分，不需要的部分留在磁盘（Skill 文件）上。基础上下文固定在 1,500 tokens 内，Skill 库膨胀不会增加基础开销。

八、多平台网关：消息统一架构

Hermes Agent 的网关层是一个统一的路由层，让同一个 Agent 实例可以同时连接多个消息平台。

Telegram ──┐
Discord ───┼── Gateway ── AIAgent Core ── Toolset: Terminal
Slack ─────┤                │
WhatsApp ──┘                ├── Toolset: Web Search
                            ├── Toolset: Browser
                            └── Toolset: Memory

核心的消息统一格式：

# gateway/platform_adapter.py 统一消息格式
class UnifiedMessage:
    def __init__(self, platform: str, content: str, sender: str, 
                 metadata: dict):
        self.platform = platform      # 来源平台
        self.content = content        # 消息内容
        self.sender = sender          # 发送者
        self.metadata = metadata      # 平台特有信息（群组、话题等）
    
    def to_agent_format(self) -> str:
        """转换为 Agent 可处理的统一格式"""
        return f"[{self.platform}:{self.sender}] {self.content}"
    
    def format_response(self, response: str) -> dict:
        """将 Agent 响应适配回各平台的格式"""
        platform_formatters = {
            "telegram": lambda r: {"text": r, "parse_mode": "Markdown"},
            "discord": lambda r: {"content": r},
            "slack": lambda r: {"text": r},
        }
        return platform_formatters[self.platform](response)

支持 12+ 平台：Telegram、Discord、Slack、WhatsApp、Signal、SMS、Email、DingTalk（钉钉）、Feishu（飞书）、Mattermost、BlueBubbles、Home Assistant。

每新增一个平台，只需要实现一个 PlatformAdapter，不需要改核心逻辑。这套架构的设计模式和现代前端的「统一状态管理」思路一致——所有平台差异在适配层抹平。

九、部署实战：从 $5 VPS 到 GPU 集群

9.1 一键安装

# Linux / macOS / WSL2 / Android Termux
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

安装脚本自动处理所有依赖：Python 3.11+、Node.js v22+、ripgrep、ffmpeg、uv。

9.2 模型配置

# 阿里云百炼示例
hermes config set model.provider custom
hermes config set model.base_url "https://dashscope.aliyuncs.com/compatible-mode/v1"
hermes config set model.api_key "sk-xxx"
hermes config set model.default "qwen3.6-plus"

# Docker 部署（docker-compose.yml）
services:
  hermes:
    image: nousresearch/hermes-agent
    volumes:
      - ./config:/opt/hermes/.config
      - ./memories:/opt/hermes/.hermes/memories
      - ./skills:/opt/hermes/.hermes/skills
    environment:
      - MODEL_PROVIDER=custom
      - MODEL_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
      - MODEL_API_KEY=${DASHSCOPE_KEY}
    restart: unless-stopped

支持 200+ 模型接入：OpenAI GPT-5.x、Claude Opus 4.6、Gemini 3.1 Pro、DeepSeek、Qwen3-Max/3.6-Plus、GLM-5、Kimi K2.5 等。切换模型不需要改代码，一条命令搞定。

9.3 环境后端对比

十、性能优化：让 Agent 跑在 $5 VPS 上

10.1 Token 节省六大机制

官方测试数据显示，合理配置可节省 30%-90% 的 token 消耗：

1. 分级记忆注入：L1 固定 1,300 tokens，L2/L3 按需加载。Skill 库膨胀不增加基础开销。

2. 渐进式技能加载：默认只加载 Skill 名称索引（20 tokens/个），完整内容仅在使用时加载。

3. 上下文压缩：长会话自动压缩历史，保留关键决策点，删除冗余轮次。

4. KV Cache 复用：冻结快照 + System Prompt 缓存，确保前缀缓存命中率最大化。

5. 模型分级：简单任务用 Mini/Nano 模型（如 qwen3-mini），复杂推理切到旗舰模型。按任务难度分配资源。

6. 输出控制：设置 max_tokens 上限，防止模型「话多」。

10.2 上下文压缩实现

# agent/context_compressor.py 核心逻辑
class ContextCompressor:
    def compress(self, messages: list[Message]) -> list[Message]:
        # 对话太短，不压缩
        if len(messages) < 10:
            return messages
        
        # 提取关键信息：决策点、工具调用结果、错误记录
        critical_points = []
        for msg in messages:
            if msg.is_decision_point() or msg.is_error() or msg.modified_files:
                critical_points.append(msg)
        
        # 生成摘要替换冗余内容
        summary = await self.summarize(messages)
        
        # 返回压缩后的上下文
        return [
            Message(role="system", 
                    content=f"[已压缩上下文 — 原始 {len(messages)} 轮]\n{summary}"),
            *critical_points  # 关键决策点和错误保留
        ]

压缩触发条件：对话轮次超过阈值（默认 10 轮）或 token 消耗超过阈值。压缩时保留所有决策点和错误记录，删除中间的过程性对话。

十一、与 OpenClaw 的对比：不是竞争，是互补

Hermes Agent 和 OpenClaw 常被拿来比较，但两者定位有显著差异：

两者不是非此即彼的关系——有用户把 OpenClaw 作为日常随身助手，用 Hermes Agent 作为后台自动化引擎。OpenClaw 的插件生态更丰富，Hermes Agent 的自我进化更彻底。

十二、总结：自进化 Agent 的工程启示

Hermes Agent 给行业最宝贵的不是另一个 Agent 框架，而是它示范了一条工程上可行的「让 AI 自我进化」的路径。

可工程化的自进化需要三个前提：

1. 记忆的结构化：不是日志 dump，是分层的、可检索的、有上限的。无限膨胀的记忆是工程灾难。
2. 技能的可验证性：自动生成的 Skill 必须能通过自测，否则会把错误固化。
3. 进化的选择性：不是所有经验都值得记住。LLM 本身做决策，判断什么值得沉淀。

认知科学的工程映射：

• 情景记忆 → SQLite FTS5 检索
• 语义记忆 → MEMORY.md 持久化
• 程序性记忆 → Skill 文件系统

这三个映射不是装饰性的类比，而是直接影响代码实现的架构决策。

对 Agent 架构设计者的建议：

• 不要把「自我进化」做成插件，要做成原生能力。事后打补丁的进化系统迟早会被遗忘。
• 记忆不是越多越好，有上限的强制提炼比无限膨胀更有价值。
• Prefix Cache 是 Agent 部署优化的低垂果实——从第一天就把 System Prompt 缓存考虑进去。
• 工具的自注册模式值得借鉴，它让系统的可扩展性和可测试性同时提升。

2026 年的 Agent 战场，工具调用能力已经同质化了。真正的差异化在于：谁能持续进化，谁的记忆最有效，谁能在长时间运行中保持稳定。

Hermes Agent 在这三个维度上都给出了值得参考的工程答案。它的成功不是靠某个惊艳的算法创新，而是靠对 Agent 长期运行中真实痛点的系统性解决。

本文基于 Hermes Agent v0.14.0（2026年7月）源码分析写成。技术细节如有出入，以官方最新版本为准。