Jiayun's Blog

“The self-improving AI agent” — 这不是一句营销口号。当你读完 Hermes Agent 的 23 万行 Python 代码，你会发现它的每一层架构都在服务于同一个目标：让 Agent 在使用中变得更好。本文将从架构师的视角，拆解这个由 Nous Research 开源的通用 AI 代理平台。

一、Hermes Agent 是什么？

Hermes Agent 是 Nous Research 开源的通用 AI 代理平台（MIT 许可），GitHub 上已获得大量关注。它的核心主张是：一个能在使用中自我进化的 Agent，跑在任何地方，连接任何平台，使用任何模型。

这不是又一个 “LLM wrapper”。Hermes Agent 解决的是一个完整的系统工程问题：

• 如何让同一个 Agent 同时在 Telegram、Discord、Slack、微信、CLI 上运行？
• 如何让 Agent 从复杂任务中提取经验，下次自动复用？
• 如何安全地让 Agent 操作终端、浏览器、文件系统？
• 如何在不同 LLM 提供商之间无缝切换，甚至自动故障转移？

让我们从架构全景开始。

二、架构全景：五层洋葱模型

Hermes Agent 的整体架构可以用一个五层洋葱模型来理解。每一层只依赖内层，不依赖外层：

  graph TB
    subgraph "Layer 5: Platforms 平台层"
        TG[Telegram] 
        DC[Discord]
        SL[Slack]
        WX[微信/企微]
        CLI[CLI Terminal]
        WA[WhatsApp]
        MT[Matrix]
        FS[飞书]
        DT[钉钉]
        EM[Email]
        SI[Signal]
        SMS[SMS]
        QQ[QQ Bot]
        WH[Webhook]
        HA[HomeAssistant]
        MM[Mattermost]
        BB[BlueBubbles]
        API[API Server]
    end

    subgraph "Layer 4: Gateway 网关层"
        GW[GatewayRunner]
        SS[Session Manager]
        DL[Delivery Router]
    end

    subgraph "Layer 3: Agent 代理层"
        AI[AIAgent<br/>run_conversation]
        PB[Prompt Builder]
        CC[Context Compressor]
        MM2[Memory Manager]
    end

    subgraph "Layer 2: Tools 工具层"
        REG[Tool Registry]
        TM[Terminal]
        BR[Browser]
        FS2[File Ops]
        WEB[Web Search]
        SK[Skills]
        CR[Cron]
        DT2[Delegate]
        MCP[MCP Client]
    end

    subgraph "Layer 1: Foundation 基座层"
        PR[Provider Adapters<br/>OpenAI·Anthropic·Bedrock·Gemini]
        CFG[Config System]
        LOG[Logging & State]
    end

    TG & DC & SL & WX & CLI --> GW
    GW --> AI
    AI --> REG
    AI --> PB & CC & MM2
    REG --> TM & BR & FS2 & WEB & SK & CR & DT2 & MCP
    AI --> PR
    PR --> CFG

代码规模速览

一个有趣的观察：网关层（51K）比代理层（12K）大四倍。这说明 Hermes Agent 的核心智能逻辑是紧凑的，而真正的工程复杂性在于"如何接入真实世界"——处理每个平台的消息格式、速率限制、权限模型、富媒体差异。

三、Gateway：万物互联的统一抽象

Gateway 是 Hermes Agent 最有工程价值的设计之一。它解决的问题是：如何让一个 Agent 同时在 20+ 个平台上运行，而不需要 20 套代码？

3.1 BasePlatformAdapter：平台的契约

所有平台适配器继承自 BasePlatformAdapter 这个抽象基类：

  classDiagram
    class BasePlatformAdapter {
        <<abstract>>
        +connect() bool
        +disconnect()
        +send(chat_id, text, metadata) 
        +send_image(chat_id, path)
        +send_voice(chat_id, path)
        +send_typing(chat_id)
        +edit_message(chat_id, msg_id, text)
        +truncate_message(text, limit) List
        -_notify_fatal_error()
    }

    BasePlatformAdapter <|-- TelegramAdapter
    BasePlatformAdapter <|-- DiscordAdapter
    BasePlatformAdapter <|-- SlackAdapter
    BasePlatformAdapter <|-- WeixinAdapter
    BasePlatformAdapter <|-- SignalAdapter
    BasePlatformAdapter <|-- MatrixAdapter
    BasePlatformAdapter <|-- WhatsAppAdapter
    BasePlatformAdapter <|-- DingTalkAdapter
    BasePlatformAdapter <|-- FeishuAdapter
    BasePlatformAdapter <|-- WeComAdapter
    BasePlatformAdapter <|-- EmailAdapter
    BasePlatformAdapter <|-- APIServerAdapter
    BasePlatformAdapter <|-- "...12+ more"

这个设计有几个值得注意的细节：

UTF-16 边界安全截断。 Telegram 的消息长度限制是 4096 个 UTF-16 code units，而不是 Unicode 码点。Emoji 和 CJK 扩展字符占两个 UTF-16 单元。BasePlatformAdapter 在基类层面实现了一个二分搜索算法来精确截断，确保永远不会切断一个字符的中间：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

def _prefix_within_utf16_limit(s: str, limit: int) -> str:
    if utf16_len(s) <= limit:
        return s
    lo, hi = 0, len(s)
    while lo < hi:
        mid = (lo + hi + 1) // 2
        if utf16_len(s[:mid]) <= limit:
            lo = mid
        else:
            hi = mid - 1
    return s[:lo]

SSRF 防护。 基类提供了 _ssrf_redirect_guard 异步函数，防止外部 URL 被重定向到内网地址。这是 Agent 安全的关键——当 Agent 需要下载用户提供的图片 URL 时，不能让它被恶意重定向到 http://169.254.169.254/ 去获取云元数据。

3.2 GatewayRunner：会话编排

GatewayRunner 是网关层的核心编排器，负责管理 Agent 实例的生命周期：

  flowchart LR
    MSG[平台消息] --> GW[GatewayRunner]
    GW --> |"session_key\n(platform:chat_id)"| CACHE{Agent Cache\nLRU 128}
    CACHE --> |命中| AGENT[AIAgent Instance]
    CACHE --> |未命中| CREATE[Create AIAgent]
    CREATE --> AGENT
    AGENT --> |run_conversation| RESP[Response]
    RESP --> GW
    GW --> |send| MSG2[平台回复]

    TIMER[Idle Timer\n1h TTL] --> |evict| CACHE

Agent 缓存是关键性能优化。 每个 AIAgent 实例持有 LLM 客户端、工具 schema、内存提供者等重量级对象。如果每条消息都创建新实例，prompt caching 就失效了（Anthropic 和 OpenAI 都根据 system prompt 的稳定性来缓存 KV）。所以 GatewayRunner 维护了一个 LRU 缓存（最大 128 个），按 platform:chat_id 索引，空闲超过 1 小时自动驱逐。

会话源追踪。 每条消息都携带一个 SessionSource 数据结构，记录了平台、聊天 ID、用户名、线程 ID、聊天类型（DM/群组/频道）等元数据。这些信息被注入到 system prompt 中，让 Agent 知道"我现在在跟谁、在哪个平台、什么场景下对话"。

四、AIAgent：万行编排者

run_agent.py 只有一个类——AIAgent，但它有 11,778 行。这不是设计缺陷，而是一个有意识的权衡：把所有编排逻辑集中在一个文件里，让调用链可追踪。

4.1 核心循环

  flowchart TD
    START[用户消息] --> BUILD[构建 System Prompt\n注入 Memory + Skills + Platform Context]
    BUILD --> API[调用 LLM API\n支持流式/非流式]
    API --> CHECK{响应类型?}
    CHECK --> |纯文本| DONE[返回响应]
    CHECK --> |工具调用| TOOL[执行工具\nhandle_function_call]
    TOOL --> RESULT[工具结果]
    RESULT --> |加入消息历史| API
    API --> |迭代限制检查| LIMIT{超过 max_iterations?}
    LIMIT --> |是| SUMMARY[生成总结响应]
    LIMIT --> |否| CHECK

    style START fill:#4f46e5,color:#fff
    style DONE fill:#059669,color:#fff
    style SUMMARY fill:#d97706,color:#fff

这是一个经典的 ReAct（Reasoning + Acting）循环，但 Hermes Agent 在这个基础上加了几层精巧的控制：

自动故障转移。 当主模型 API 返回错误时，classify_api_error 会判断错误类型（速率限制、认证失败、上下文超限、服务不可用），然后决定是重试、降级到备用模型、还是压缩上下文后重试。失败不是终点，而是触发自愈的信号。

上下文自动压缩。 当对话超过模型的上下文窗口时，ContextCompressor 会介入——用一个辅助模型（通常是更便宜的模型）对中间对话轮次做摘要，保留头尾上下文。压缩后的摘要被标记为"参考信息，不是活跃指令"，防止模型把历史任务当成当前指令执行。

4.2 多提供商适配

Hermes Agent 不绑定任何 LLM 提供商。它通过适配器模式支持多种 API 格式：

  graph LR
    subgraph "AIAgent"
        LOOP[对话循环]
    end

    subgraph "Provider Adapters"
        OAI[OpenAI Compatible\nOpenRouter · NVIDIA NIM\nXiaomi MiMo · z.ai · HuggingFace]
        ANT[Anthropic Native\nClaude Direct API]
        BED[AWS Bedrock\nCross-region inference]
        GEM[Google Gemini\nVertex AI]
    end

    LOOP --> |"api_mode=openai"| OAI
    LOOP --> |"api_mode=anthropic_messages"| ANT
    LOOP --> |"api_mode=bedrock"| BED
    LOOP --> |"api_mode=gemini"| GEM

其中 anthropic_adapter.py 值得关注。它不只是简单的格式转换——还处理了 Anthropic 的思考预算（thinking budget）管理。不同版本的 Claude 模型支持不同的思考级别（low/medium/high/xhigh/max），适配器会根据模型版本自动映射：

这种细粒度的适配，是"能用"和"用好"之间的差距。

五、工具系统：自注册的插件架构

Hermes Agent 的工具系统是一个优雅的自注册架构。每个工具文件在模块加载时自动注册到中央注册表，无需手动维护工具列表。

5.1 注册表模式

  sequenceDiagram
    participant Main as model_tools.py
    participant Reg as tools/registry.py
    participant Term as tools/terminal_tool.py
    participant Browse as tools/browser_tool.py
    participant File as tools/file_tools.py

    Main->>Reg: discover_builtin_tools()
    Reg->>Reg: AST scan: find modules with registry.register()
    Reg->>Term: import → auto-register
    Term->>Reg: registry.register(name, schema, handler, toolset)
    Reg->>Browse: import → auto-register
    Browse->>Reg: registry.register(name, schema, handler, toolset)
    Reg->>File: import → auto-register
    File->>Reg: registry.register(name, schema, handler, toolset)
    Main->>Reg: get_tool_definitions(enabled_toolsets)
    Reg-->>Main: [filtered tool schemas]

AST 预扫描是一个精妙的优化。 在发现阶段，注册表不会盲目 import 所有 Python 文件——它先用 ast.parse() 静态分析每个模块，检查是否包含顶层的 registry.register() 调用。只有确认是工具模块的文件才会被 import。这避免了副作用（有些辅助模块 import 时可能触发网络请求或依赖检查）。

5.2 Toolsets：工具的分组与编排

工具被组织成 toolsets——逻辑分组，让不同场景使用不同的工具集合：

  graph TB
    subgraph "Core Tools 核心工具"
        WS[web_search\nweb_extract]
        TM[terminal\nprocess]
        FL[read_file\nwrite_file\npatch\nsearch_files]
        BR[browser_*\n10个浏览器工具]
        VIS[vision_analyze\nimage_generate]
    end

    subgraph "Knowledge Tools 知识工具"
        SK[skills_list\nskill_view\nskill_manage]
        MEM[memory\nsession_search]
        TODO[todo]
    end

    subgraph "Orchestration Tools 编排工具"
        DEL[delegate_task]
        EXEC[execute_code]
        CRON[cronjob]
        SEND[send_message]
    end

    subgraph "Toolset Composition"
        HERMES_CLI["hermes-cli\n所有工具"]
        HERMES_TG["hermes-telegram\n所有工具"]
        RESEARCH["research\nweb_search + browser"]
        SAFE["safe\n只有只读工具"]
    end

    HERMES_CLI --> WS & TM & FL & BR & VIS & SK & MEM & TODO & DEL & EXEC & CRON & SEND

子代理的工具限制尤为关键。 当 delegate_task 生成子代理时，DELEGATE_BLOCKED_TOOLS 硬编码了禁止列表：子代理不能再递归委派（防止无限嵌套）、不能与用户交互（clarify）、不能写入共享内存（memory）、不能发消息到其他平台（send_message）。最大嵌套深度为 2 层。这些限制不是任意的——每一条都源自真实的安全或稳定性问题。

六、技能系统：Agent 的长期记忆与进化

技能（Skills）是 Hermes Agent 最独特的设计——也是"自我进化"这个标签的技术基础。

6.1 技能即知识

  graph LR
    subgraph "Skills 目录结构"
        ROOT["~/.hermes/skills/"]
        ROOT --> GH["github/\ngithub-pr-workflow/\ngithub-code-review/\n..."]
        ROOT --> ML["mlops/\naxolotl/\nvllm/\nwhisper/\n..."]
        ROOT --> SD["software-development/\nplan/\ntest-driven-development/\nsystematic-debugging/\n..."]
        ROOT --> CR["creative/\nascii-art/\nmanim-video/\n..."]
    end

    subgraph "Skill 结构"
        SKILL["SKILL.md"]
        SKILL --> FM["YAML Frontmatter\nname · description · tags\nplatform · version"]
        SKILL --> BODY["Markdown Body\n何时使用 · 步骤 · 陷阱\n验证步骤"]
        SKILL --> REF["references/\ntemplates/\nscripts/"]
    end

每个技能是一个包含 SKILL.md 的目录。SKILL.md 使用 YAML frontmatter + Markdown body 的格式，包含：

• 何时使用（When to Use）：触发条件
• 步骤（Steps）：具体操作步骤，包含命令
• 陷阱（Pitfalls）：已知的坑和解决方案
• 验证（Verification）：如何确认任务成功

6.2 学习闭环

技能系统的核心不是"有技能"，而是"技能会进化"：

  flowchart TD
    TASK[复杂任务完成\n5+ 工具调用] --> OFFER[Agent 主动提议\n'要保存为技能吗?']
    OFFER --> |用户同意| CREATE[skill_manage\naction=create]
    
    USE[下次遇到类似任务] --> MATCH[技能索引匹配\nskills_list扫描]
    MATCH --> LOAD[skill_view 加载]
    LOAD --> EXEC[按技能步骤执行]
    EXEC --> ISSUE{遇到问题?}
    ISSUE --> |步骤过时| PATCH[skill_manage\naction=patch\n立即修复]
    ISSUE --> |命令失败| PATCH
    ISSUE --> |缺少步骤| PATCH
    PATCH --> BETTER[技能进化完成\n下次更准确]

    style CREATE fill:#059669,color:#fff
    style PATCH fill:#d97706,color:#fff
    style BETTER fill:#4f46e5,color:#fff

关键设计决策：技能在使用中修复。 系统提示词中明确要求：如果加载了一个技能但发现它过时或不完整，不要等待，立即 patch。这创造了一个正反馈循环——使用越多，技能越准确。

内置技能库覆盖了 26 个领域、上百个具体技能，从 GitHub PR 工作流到 PyTorch FSDP 训练、从 Minecraft 服务器搭建到 Whisper 语音识别。

6.3 记忆系统：双层持久化

除了技能（过程性知识），Hermes Agent 还有声明性记忆系统：

  graph TB
    subgraph "Built-in Memory 内建记忆"
        MEMORY["MEMORY.md\nAgent 的笔记\n环境事实 · 工具怪癖 · 经验"]
        USER["USER.md\n用户画像\n姓名 · 偏好 · 习惯 · 纠正"]
    end

    subgraph "External Memory Plugins 外部记忆插件"
        HONCHO["Honcho\n辩证式用户建模"]
        MEM0["Mem0"]
        HOLO["Holographic"]
        HIND["Hindsight"]
        BYTE["ByteRover"]
        SUPER["SuperMemory"]
        RETAIN["RetainDB"]
        VIKING["OpenViking"]
    end

    subgraph "Session Search 会话搜索"
        FTS["FTS5 全文索引\n所有历史对话"]
        SUM["LLM 摘要\n按需回忆"]
    end

    MEMORY --> |每次对话注入| PROMPT[System Prompt]
    USER --> |每次对话注入| PROMPT
    HONCHO --> |可选增强| PROMPT
    FTS --> |"session_search 工具"| AGENT[Agent 主动搜索]

双轨制记忆设计的智慧： 内建记忆（MEMORY.md / USER.md）是纯文本文件，简单、可审计、永远不会因为第三方服务故障而丢失。外部记忆插件（如 Honcho）是可选增强，提供更高级的语义检索和用户建模，但永远不会替代内建存储。这是"必须可靠的基础 + 可选的高级功能"的经典模式。

七、安全架构：Defense in Depth

对于一个能操作终端和文件系统的 Agent，安全不是事后补丁——它必须是架构的一部分。

7.1 多层安全防线

  graph TB
    subgraph "Layer 1: Input Sanitization"
        PROMPT_INJECT["Prompt Injection Detection\n10+ 威胁模式匹配"]
        INVISIBLE["不可见字符检测\nZWJ · ZWNJ · BOM"]
        CONTEXT_SCAN["上下文文件扫描\nAGENTS.md · .cursorrules"]
    end

    subgraph "Layer 2: Tool-Level Guards"
        PATH_SEC["路径安全\n防止目录遍历"]
        SSRF["SSRF 防护\n防止内网访问"]
        APPROVAL["危险命令审批\nrm -rf · sudo · iptables"]
        URL_SAFE["URL 安全检查\n阻止已知恶意域名"]
    end

    subgraph "Layer 3: Execution Boundaries"
        DELEGATE["子代理工具限制\n不能递归 · 不能发消息"]
        BUDGET["工具调用预算\n每轮最大调用数"]
        TIMEOUT["执行超时\n前台600s · 后台可配"]
    end

    subgraph "Layer 4: Data Protection"
        REDACT["敏感信息脱敏\nAPI Key · Token · Password"]
        PII["PII 哈希\n会话日志中的用户ID"]
        CRED["凭证文件隔离\n读取后不回显"]
    end

Prompt Injection 检测值得特别关注。 prompt_builder.py 中定义了 10+ 种威胁模式，在任何外部文本（AGENTS.md、.cursorrules、SOUL.md）被注入 system prompt 之前进行扫描：

还检测 Unicode 不可见字符（零宽连接符、零宽非连接符、BOM 等），这些可以被用来在看似正常的文本中隐藏恶意指令。

八、上下文工程：有限窗口的无限对话

大模型的上下文窗口是有限的，但用户期望 Agent 能"记住"所有历史。Hermes Agent 用**上下文压缩（Context Compaction）**优雅地解决了这个矛盾。

8.1 压缩策略

  flowchart LR
    subgraph "Before Compression"
        H[HEAD\nSystem Prompt\n+ 前几轮]
        M[MIDDLE\n中间 N 轮对话\n工具调用 · 结果]
        T[TAIL\n最近几轮\n当前任务上下文]
    end

    subgraph "After Compression"
        H2[HEAD\n保持不变]
        S[SUMMARY\n结构化摘要\n✅ 已解决 · ⏳ 待处理\n📁 当前工作目录状态]
        T2[TAIL\n保持不变\nToken 预算保护]
    end

    M --> |辅助模型摘要| S
    H --> H2
    T --> T2

几个精妙的设计细节：

摘要被标记为"参考信息"。 压缩后的文本以特殊前缀开头：“这是从上一个上下文窗口的交接——作为背景参考，不是活跃指令。不要回答或执行摘要中提到的请求。” 这防止了模型把历史任务当成当前指令。

结构化摘要模板。 不是随意的文本摘要，而是要求辅助模型生成包含"已解决问题"、“待处理事项”、“当前工作目录状态"的结构化输出。这确保了压缩后的信息在语义上更有用。

迭代式压缩。 如果对话继续增长到再次触发压缩，新的摘要会合并旧的摘要，而不是丢弃。信息在多次压缩中逐步精炼，而不是突然丢失。

九、子代理编排：分而治之

delegate_task 工具实现了一个子代理架构，让 Agent 可以并行处理独立任务：

  flowchart TB
    PARENT[父 Agent\n完整上下文] --> |delegate_task| DISPATCH{批量 or 单任务?}
    
    DISPATCH --> |单任务| CHILD1[子 Agent 1\n隔离上下文\n独立终端会话\n受限工具集]
    
    DISPATCH --> |批量并行\n最多3个| PAR[ThreadPoolExecutor]
    PAR --> CHILD2[子 Agent A]
    PAR --> CHILD3[子 Agent B]  
    PAR --> CHILD4[子 Agent C]
    
    CHILD1 --> |摘要| PARENT
    CHILD2 & CHILD3 & CHILD4 --> |摘要| PARENT

    style PARENT fill:#4f46e5,color:#fff
    style CHILD1 fill:#059669,color:#fff
    style CHILD2 fill:#059669,color:#fff
    style CHILD3 fill:#059669,color:#fff
    style CHILD4 fill:#059669,color:#fff

上下文隔离是核心设计原则。 每个子 Agent：

• 获得全新的对话（不继承父对话历史）
• 拥有独立的 task_id（独立终端会话）
• 使用受限的工具集（不能递归委派、不能访问共享内存）
• 只返回最终摘要给父 Agent

父 Agent 的上下文永远不会被子 Agent 的中间步骤污染。 这解决了 Agent 系统中最常见的问题——中间工具调用的大量输出淹没了主要任务的上下文。

此外，Hermes Agent 还支持跨进程委派——通过 ACP（Agent Communication Protocol），父 Agent 可以启动 Claude Code、Codex 等外部 Agent 进程作为子代理，不限于自身的 Python 运行时。

十、定时任务：无人值守的自主运行

cron 模块实现了一个文件锁保护的定时调度器：

  sequenceDiagram
    participant GW as Gateway
    participant SCH as Scheduler
    participant LOCK as File Lock
    participant JOB as Cron Job
    participant AGENT as AIAgent

    loop 每60秒
        GW->>SCH: tick()
        SCH->>LOCK: acquire .tick.lock
        alt 获取锁成功
            SCH->>JOB: 检查所有 job 的 next_run
            loop 每个到期 job
                JOB->>AGENT: 创建临时 AIAgent
                AGENT->>AGENT: run_conversation(job.prompt)
                AGENT-->>JOB: 执行结果
                JOB->>GW: delivery(result, target_platform)
            end
            SCH->>LOCK: release
        else 锁被占用
            SCH-->>GW: skip (其他进程正在tick)
        end
    end

关键设计：job prompt 必须完全自包含。 因为 cron job 在一个全新的会话中运行，没有任何对话上下文。所以 prompt 必须包含完成任务所需的全部信息——目录路径、配置参数、输出要求。这是对用户的一个强约束，但它保证了 cron job 的可靠性和可预测性。

交付路由。 job 执行完毕后，结果可以路由到任何已连接的平台——Telegram 群组、Discord 频道、微信、或者保存为本地文件。这使得"每天早上 9 点在 Telegram 发送服务器状态报告"这样的场景变得 trivial。

十一、设计哲学提炼

通读 Hermes Agent 的 23 万行代码，我提炼出六条核心设计哲学：

1. 分层清晰，单点控制

Gateway 只管消息路由，AIAgent 只管对话编排，工具注册表只管工具调度。每一层有一个明确的"编排者”。run_agent.py 的 12K 行看似巨大，但它确保了所有控制流逻辑在一个文件内可追踪——你不需要跳转五个文件才能理解一次工具调用是如何发生的。

2. 自注册 > 手动注册

工具不需要在某个中央配置文件里列举。每个工具模块在加载时自动注册。注册表通过 AST 预扫描避免了不必要的 import 副作用。这使得添加新工具只需要两步：写一个 Python 文件、在文件里调用 registry.register()。

3. 进化 > 静态

技能不是写好就不变的文档——它们在每次使用中被验证、被修正。记忆不是一次性记录——它在每次对话中被检索、被更新。这种活的知识库是 Hermes Agent 区别于其他 Agent 框架的最大特征。

4. 安全是架构，不是补丁

从 prompt injection 检测、SSRF 防护、路径安全、子代理工具限制到 PII 脱敏——安全措施不是事后加的，而是嵌入在每一层的设计中。BasePlatformAdapter 在基类层面就处理了 UTF-16 边界安全和 SSRF 防护。

5. 优雅降级 > 强依赖

外部记忆插件挂了？内建 MEMORY.md 还在。主模型 API 超限？自动切换到备用模型。上下文窗口满了？自动压缩中间对话。整个系统的设计哲学是每个组件都可以独立失败，不影响核心功能。

6. 适配器模式的极致运用

20+ 平台适配器、4 种 LLM API 适配器、8 种记忆后端——Hermes Agent 几乎在每个"需要对接外部系统"的地方都使用了适配器模式。这不是过度设计——对于一个需要"在任何地方运行、使用任何模型"的系统，适配器模式是唯一可扩展的选择。

十二、写在最后：Agent 的工程本质

Hermes Agent 给我最大的启示是：一个优秀的 AI Agent 产品，80% 的工程量不在"调用 LLM"上，而在"如何把 LLM 嵌入到真实世界中"。

44K 行的工具代码、51K 行的平台适配代码、50K 行的 CLI 和配置代码——这些"不性感"的工程工作，才是让 Agent 从 demo 变成产品的关键。

而 Hermes Agent 做对的最核心的一件事是：它给 Agent 装上了一个学习引擎。 技能系统、记忆系统、会话搜索——这三者组合在一起，让 Agent 不再是一个无状态的函数调用，而是一个持续积累经验的智能体。

这大概就是 “Hermes”（赫尔墨斯——希腊神话中的信使之神）这个名字的深意：不只是传递信息，而是在传递中学习，在学习中进化。

参考来源

• Hermes Agent GitHub Repository — 源码分析基础
• Hermes Agent Documentation — 官方文档
• Nous Research — 开发团队
• Agent Communication Protocol (ACP) — 跨代理通信协议
• Honcho — 辩证式用户建模记忆系统