Hermes架构全景图：从入口到交付的完整数据流

#21 Hermes架构全景图：从入口到交付的完整数据流

「Hermes Agent自进化智能体深度解析」系列 | 模块九 · 第1篇

如果你只看到六步循环，你只看到了冰山一角

在#07中，我们拆解了Hermes的会话循环六步------Intent Parse、Context Assembly、Planning、Tool Dispatch、Execution、Response Synthesis。那篇文章发布后，很多读者私信我说："原来Hermes的执行流程这么清晰。"但我要告诉你一个残酷的事实：那六步，只是冰山露出水面的部分。

为什么残酷？因为如果你把六步循环当成Hermes的全部，你就会像拿着一张地图却以为看到了整座城市------你看到了道路，却没看到调度中心、变电站、信号系统、维护工厂。六步循环描述的是"一次请求如何被执行"，但它没有回答一个更致命的问题：Hermes凭什么在第100次执行时比第1次更强？

答案藏在水面之下。在六步循环的背后，Hermes运行着一套五层架构系统------从用户入口到底层基础设施，每一层都在为"自进化"这个终极目标服务。今天，我们终于要画出这张完整的架构全景图。

这不是一张静态的架构图。这是一台正在运转的进化机器的剖面图。

Hermes五层架构全景

在深入每一层之前，先看全貌。Hermes的五层架构遵循一个严格的原则：上层不关心下层的实现，下层不假设上层的意图。 这不是一句口号，这是写在每一行代码里的设计契约。

复制代码

┌─────────────────────────────────────────────────────────────────┐
│                    LAYER 1: INTERFACE LAYER                     │
│         CLI · API Gateway · Web UI · IDE Plugin                 │
│    ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
│    │   CLI    │  │REST/WS   │  │ Web UI   │  │  IDE     │     │
│    │Terminal  │  │API Gate  │  │Dashboard │  │ Plugin   │     │
│    └──────────┘  └──────────┘  └──────────┘  └──────────┘     │
└────────────────────────────┬────────────────────────────────────┘
                             │ Goal / Query / Command
┌────────────────────────────▼────────────────────────────────────┐
│                 LAYER 2: ORCHESTRATION LAYER                    │
│      Goal Parser · Planning Engine · Kanban Board               │
│    ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │
│    │  Goal Parser │  │  Planning    │  │   Kanban     │       │
│    │  Intent →    │  │  Engine      │  │   Board      │       │
│    │  Structured  │  │  DAG Builder │  │  Progress    │       │
│    │  Tasks       │  │  Replanner   │  │  Tracker     │       │
│    └──────────────┘  └──────────────┘  └──────────────┘       │
└────────────────────────────┬────────────────────────────────────┘
                             │ Task DAG / Subgoals
┌────────────────────────────▼────────────────────────────────────┐
│                   LAYER 3: EXECUTION LAYER                      │
│     Worker Registry · Tool Dispatch · Subagent Manager          │
│    ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │
│    │   Worker     │  │    Tool      │  │   Subagent   │       │
│    │   Registry   │  │   Dispatch   │  │   Manager    │       │
│    │  Skill →     │  │  Runtime     │  │  Spawn/Join  │       │
│    │  Worker Map  │  │  Scheduler   │  │  Isolation   │       │
│    └──────────────┘  └──────────────┘  └──────────────┘       │
└────────────────────────────┬────────────────────────────────────┘
                             │ Context Requests / Memory Queries
┌────────────────────────────▼────────────────────────────────────┐
│                  LAYER 4: INTELLIGENCE LAYER                    │
│     Context Engine · Memory System · Skill Registry             │
│    ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │
│    │  Context     │  │   Memory     │  │    Skill     │       │
│    │  Engine      │  │   System     │  │   Registry   │       │
│    │  RAG · Rerank│  │  STM·LTM·EP │  │  Learn·Share │       │
│    │  Compress    │  │  Consolidate │  │  Verify      │       │
│    └──────────────┘  └──────────────┘  └──────────────┘       │
└────────────────────────────┬────────────────────────────────────┘
                             │ LLM Calls / Storage / Protocol
┌────────────────────────────▼────────────────────────────────────┐
│                   LAYER 5: FOUNDATION LAYER                     │
│     LLM Backends · Storage · MCP Protocol · Observability       │
│    ┌───────┐ ┌───────┐ ┌───────┐ ┌──────────┐ ┌──────────┐   │
│    │ GPT-5 │ │Claude │ │ Gemini│ │  Vector  │ │   MCP    │   │
│    │o-series│ │ 4.x  │ │ 2.5   │ │   Store  │ │ Protocol │   │
│    └───────┘ └───────┘ └───────┘ └──────────┘ └──────────┘   │
│    ┌──────────┐ ┌──────────┐ ┌──────────┐                     │
│    │  Object  │ │  Struct  │ │  Log &   │                     │
│    │  Store   │ │  Logs    │ │  Metrics │                     │
│    └──────────┘ └──────────┘ └──────────┘                     │
└─────────────────────────────────────────────────────────────────┘

Layer 1：Interface Layer --- 用户触达的第一公里

Interface Layer是用户与Hermes交互的入口，但它的设计哲学远不止"输入框+输出框"。CLI为开发者提供原子级控制，每一个flag都对应一层内部参数；API Gateway承载外部系统的集成调用，支持REST和WebSocket双协议，意味着Hermes既能被同步调用，也能推送流式结果；Web UI是面向非技术用户的可视化面板，但它的真正价值在于将Kanban Board的状态实时映射到前端；IDE Plugin则让开发者在不离开编辑器的情况下触发Goal。

关键在于：无论从哪个入口进来，Interface Layer都会将输入标准化为统一的Goal对象。 CLI的一条命令、API的一个POST请求、Web UI的一次点击，最终都变成同一份数据结构流入Layer 2。这种"入口归一化"是Hermes能被多种场景复用的前提。

Layer 2：Orchestration Layer --- 大脑的指挥中心

Goal进入Layer 2后，第一个迎接它的是Goal Parser。Goal Parser不只是"解析意图"------它会将自然语言Goal拆解为结构化的Task DAG（有向无环图），每个Task节点包含前置依赖、预期输出、验收标准。Planning Engine负责构建和优化这个DAG，当某个Task失败时，Replanner会动态调整后续路径而不是从头重跑。Kanban Board则像项目管理工具一样追踪每个Task的状态（Backlog → In Progress → Review → Done），并持久化到存储中。

自进化的关键点： Planning Engine会记录每次规划的成功率和耗时。经过足够多的执行后，它会学会对特定类型的Goal采用更短的规划路径------这不是prompt工程，这是架构级别的学习能力。

Layer 3：Execution Layer --- 手脚的调度引擎

拿到Task DAG后，Execution Layer开始干活。Worker Registry维护着"Skill→Worker"的映射关系，每个Worker是一个独立的执行单元。Tool Dispatch Runtime是这里的核心齿轮------它根据Task的type和context，从可用工具池中选择最合适的工具组合，调度执行，并收集结果。Subagent Manager负责管理子智能体的生命周期：按需生成、隔离运行、结果汇合、安全销毁。

Execution Layer的设计目标是"无感扩展"。当你给Hermes装了一个新的MCP工具，Tool Dispatch Runtime会在下一次心跳时自动注册它，无需重启、无需配置。这就是为什么Hermes的工具库可以像App Store一样持续增长------扩展机制本身就是自进化的。

Layer 4：Intelligence Layer --- 自进化的心脏

这是五层架构中最核心的一层，也是Hermes区别于所有"执行框架"的分水岭。Context Engine负责在有限上下文窗口中装下最相关的信息------它通过RAG检索、Rerank排序、压缩算法三步，从海量数据中蒸馏出"此时此刻最有用的上下文"。Memory System采用三层存储模型：STM（Short-Term Memory）存储当前会话，LTM（Long-Term Memory）存储跨会话的持久知识，EP（Episodic Memory）存储历史执行片段用于类比推理。Skill Registry是技能的注册中心------新学到的技能、验证通过的技能、被分享的技能，都汇聚于此。

震撼时刻将在后面揭晓------当你看到同一个Goal在第1次和第100次执行时，Layer 4的差异会让你重新理解什么叫"自进化"。

Layer 5：Foundation Layer --- 一切的地基

最底层是基础设施层。LLM Backends支持多模型路由------GPT-5用于复杂推理，Claude用于长上下文理解，Gemini用于多模态处理，o-series用于数学和代码。这种多模型策略不是"都试试看"，而是根据Task的类型自动路由到最合适的模型。Storage层包含Vector Store（向量检索）、Object Store（文件和二进制数据）、Structured Logs（结构化日志）。MCP Protocol是工具通信的标准化协议，所有外部工具通过MCP接入。Observability模块提供全链路日志和指标，每一次执行都留下完整的审计轨迹。

Foundation Layer的每一行日志，都是自进化的训练数据。 没有这层的数据沉淀，上面四层的"越用越强"就是无源之水。

与传统Agent框架的架构对比

理解了五层架构后，一个自然的问题是：这和LangChain、AutoGen、CrewAI有什么本质区别？先看数据：

维度	LangChain	AutoGen	CrewAI	Hermes
架构模式	链式管道（Chain）	多Agent对话	角色协作团队	五层解耦+自进化闭环
记忆系统	外挂Memory模块	对话历史缓冲	共享上下文池	STM+LTM+EP三层记忆
自进化能力	无（需手动调Chain）	无（需手动调Prompt）	无（需手动调Role）	Skill学习+规划优化+记忆巩固
工具管理	Tool抽象层	函数调用	工具装饰器	MCP协议+自动注册+动态调度
上下文管理	手动切分	窗口裁剪	共享黑板	RAG+Rerank+压缩+自动注入
验证机制	Output Parser	人工确认	交叉验证	Skill验证+执行审计+反馈闭环

核心差异用一句话概括：LangChain/AutoGen/CrewAI是"执行框架"------它们让Agent能做事；Hermes是"进化框架"------它让Agent越做事越强。

这不是修辞。在LangChain中，你写的第100条Chain和第1条Chain没有任何区别------除非你自己手动改代码。在AutoGen中，第100次对话和第1次对话用的是同一套Prompt------除非你自己手动调Prompt。但在Hermes中，Layer 4的Intelligence Layer会在每一次执行中学习、积累、优化。这不是配置变更，这是架构级别的自进化能力。

一个Goal穿越五层架构的完整旅程

光看静态架构图还不够。让我们跟踪一个真实的Goal，看它如何在五层架构中流转。

Goal：`/goal 实现一个基于用户行为的智能推荐系统`

Layer 1 · Interface Layer --- 入口归一化

用户在CLI中输入上述命令。Interface Layer将其标准化为Goal对象：

json 复制代码

{
  "goal_id": "G-20260601-0847",
  "raw_input": "实现一个基于用户行为的智能推荐系统",
  "entry_point": "cli",
  "timestamp": "2026-06-01T08:47:23Z",
  "metadata": {
    "user_id": "U-001",
    "project_context": "e-commerce-platform"
  }
}

这一层没有"智能"，只有标准化。但标准化本身就是在为自进化服务------统一的Goal格式意味着所有入口的经验可以被统一学习。

Layer 2 · Orchestration Layer --- 拆解与规划

Goal Parser将Goal拆解为Task DAG：

复制代码

┌────────────────────────────────────────────────────────┐
│                    Goal: 智能推荐系统                    │
│                                                        │
│  T1: 需求分析 ──→ T2: 数据模型设计 ──→ T3: 算法选型    │
│                        │                  │             │
│                        ▼                  ▼             │
│                   T4: API设计       T5: 核心引擎实现    │
│                        │                  │             │
│                        ▼                  ▼             │
│                   T6: 集成测试 ←── T7: 性能优化        │
│                        │                               │
│                        ▼                               │
│                   T8: 部署与文档                        │
└────────────────────────────────────────────────────────┘

Planning Engine在这个阶段做了两件关键的事：第一，检查Skill Registry中是否有"推荐系统"相关的Skill模板------如果有，直接复用规划经验；第二，检查Memory System中是否有历史失败的教训------如果有，在DAG中自动增加验证节点。第一次执行时两者都是空的，但这正是"第1次"和"第100次"差异的伏笔。

Layer 3 · Execution Layer --- 调度与执行

每个Task被分配给对应的Worker。T1（需求分析）由GeneralWorker处理，T3（算法选型）可能需要CodeWorker，T5（核心引擎实现）需要CodeWorker+TestWorker协作。Tool Dispatch Runtime为每个Worker配备合适的工具集------代码分析工具、文档生成工具、测试框架。

Layer 4 · Intelligence Layer --- 智能灌注

这是最关键的一层。每当一个Worker需要执行Task时，它会先向Intelligence Layer请求上下文。Context Engine从Memory System中检索相关的历史经验、代码片段、最佳实践，经过压缩后注入Worker的上下文窗口。Skill Registry提供可复用的技能模板。

Layer 5 · Foundation Layer --- 执行落地

具体的LLM调用在这里发生。T5（核心引擎实现）可能被路由到GPT-5（代码生成能力强），T3（算法选型）可能被路由到Claude（长上下文理解能力强）。每次调用的输入输出都记录到Structured Logs中，Vector Store同步更新。

震撼时刻：第1次 vs 第100次

现在，让我们看同一个Goal在执行100次后的差异。假设你在过去的99次中，用不同的项目、不同的需求，反复让Hermes构建推荐系统相关的功能。

第1次执行（Layer 4 · Intelligence Layer状态）：

复制代码

Context Engine  → 空检索结果（无历史经验）
Memory System   → STM: 当前会话上下文
                  LTM: 空
                  EP: 空
Skill Registry  → 无"推荐系统"相关Skill
Plan Result     → 8个Task, 预计耗时45min, 首次成功率约60%

第100次执行（Layer 4 · Intelligence Layer状态）：

复制代码

Context Engine  → 自动注入：
                  - 37条推荐算法选型经验（从EP中检索）
                  - 12个高频错误模式（从LTM中检索）
                  - 本项目的用户行为数据Schema（从RAG中检索）
Memory System   → STM: 当前会话上下文
                  LTM: 89条推荐系统领域知识
                       23条性能优化经验
                       15条常见Bug修复方案
                  EP: 99次推荐系统相关执行的片段
Skill Registry  → "推荐系统基础模板 v3.2"（自动学习+社区分享）
                  "协同过滤引擎 v2.1"（从第47次执行中提炼）
                  "冷启动处理 v1.8"（从第72次失败中学习）
Plan Result     → 5个Task（复用模板后自动合并）, 预计耗时12min, 首次成功率约94%

看到了吗？Task从8个减到5个，耗时从45分钟降到12分钟，成功率从60%升到94%。 这不是你改了任何配置，不是你调了任何Prompt------这是Hermes自己在99次执行中学会了怎么做推荐系统。Layer 4的Intelligence Layer像一个经验丰富的架构师，每次执行都在积累判断力、技能和直觉。

这就是"自进化"这四个字的工程含义：不是代码的自动修改，而是经验的自动积累、技能的自动提炼、规划的自动优化。

分层解耦的设计哲学

看到这里，你可能会问：为什么要分五层？一体化架构不是更简单吗？

答案来自三个维度：

独立替换。 LLM领域今天的主角是GPT-5，半年后可能是其他模型。在一体化架构中，换模型意味着改整个系统。在五层架构中，换模型只需要改Layer 5的Backend配置，上面四层完全不受影响。Hermes能在GPT-4→GPT-5→Claude的切换中无缝迁移，靠的就是这层抽象。

独立进化。 Layer 4的Skill Registry需要高频更新（每次执行都可能学到新Skill），Layer 5的Storage需要稳定可靠（数据不能丢）。如果把它们揉在一起，你面临的抉择是"为了快速迭代而牺牲可靠性"还是"为了可靠性而牺牲进化速度"。分层后，每一层按自己的节奏进化，互不拖累。

清晰接口。 层与层之间的接口是明确定义的Goal对象、Task DAG、Context Request、LLM Call。这意味着你可以独立测试每一层，独立监控每一层的性能，独立定位问题到某一层。在调试"为什么这次规划失败了"时，你只需要看Layer 2的日志，不需要翻遍整个系统。

复制代码

┌───────────────────────────────────────────────────┐
│           分层解耦的三大收益                        │
│                                                   │
│  ┌─────────────┐  ┌─────────────┐  ┌───────────┐ │
│  │  独立替换    │  │  独立进化    │  │  清晰接口  │ │
│  │             │  │             │  │           │ │
│  │ Layer 5 换  │  │ Layer 4     │  │ 每层可    │ │
│  │ 模型不改    │  │ 高频学习    │  │ 独立测试  │ │
│  │ 上层代码    │  │ 不拖累下层  │  │ 独立监控  │ │
│  └─────────────┘  └─────────────┘  └───────────┘ │
└───────────────────────────────────────────────────┘

这不是过度设计。这是自进化系统的必然选择------一个需要持续学习的系统，必须在架构层面保证学习过程不会破坏执行过程的稳定性。

总结：从六步循环到五层架构

回顾一下我们走过的路。在#07中，我们从微观视角拆解了Hermes的会话循环六步------那是"一次请求如何被执行"的故事。今天，我们从宏观视角画出了Hermes的五层架构------这是"整个系统如何运转"的故事。

六步循环发生在Layer 2到Layer 4之间。Intent Parse是Goal Parser的工作，Context Assembly是Context Engine的工作，Planning是Planning Engine的工作，Tool Dispatch是Tool Dispatch Runtime的工作，Execution是Worker的工作，Response Synthesis是Orchestration Layer的收尾工作。六步循环描述的是一次请求的横向流程，五层架构描述的是整个系统的纵向结构。两者正交，组合在一起才是完整的Hermes。

而贯穿这一切的核心线索，始终是自进化。Layer 2学习规划经验，Layer 3学习工具使用策略，Layer 4学习领域知识和技能，Layer 5积累执行数据------五层架构的每一层都是自进化链条上的一个环节，缺一不可。

下一站：我们不会一层一层地拆解------那太慢了。我们从最精密的齿轮开始，深入Tool Dispatch Runtime的内部机制：它是如何在毫秒级做出工具选择决策的，如何处理工具失败和降级，以及它的调度策略如何随着执行经验的积累而自动优化。

#22，我们将拆解Hermes的手脚------Tool Dispatch Runtime。

延伸阅读与交流

本文涉及的Hermes Agent自进化智能体技术体系，目前已有系统化的深度学习资源可供参考。中国通信工业协会通信和信息技术创新人才培养工程项目办公室将于近期组织相关技术专题分享，围绕本文讨论的AI原生架构、智能体工作流、自进化数据层等方向展开系统讲解。

专题信息

主题：AI原生Hermes自进化智能体系统
时间：2026年7月4-5日（周末）
形式：线上直播
内容方向：AI原生架构 · Hermes智能体拆解 · 全栈扩展 · 智能自动化 · 产品级实战 · Context Engine · 自进化数据层

分享嘉宾

王老师（Gavin），Agentic AI企业联合创始人兼CTO，十余年硅谷AI系统工程经验。长期深耕NLP、强化学习、可控AI与智能体系统架构，提出"语言即控制（Language as Control）"原创范式，在RLHF、PPO、DPO、GRPO等方向有系统化工程实践，推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。

技术交流

联系人：Sam
WeChat：NLP_ChatGPT_LLM
Hermes Agent技术文档：https://hermes-agent.nousresearch.com/docs/

Hermes架构全景图：从入口到交付的完整数据流

#21 Hermes架构全景图：从入口到交付的完整数据流

如果你只看到六步循环，你只看到了冰山一角

Hermes五层架构全景

Layer 1：Interface Layer --- 用户触达的第一公里

Layer 2：Orchestration Layer --- 大脑的指挥中心

Layer 3：Execution Layer --- 手脚的调度引擎

Layer 4：Intelligence Layer --- 自进化的心脏

Layer 5：Foundation Layer --- 一切的地基

与传统Agent框架的架构对比

一个Goal穿越五层架构的完整旅程

Goal：/goal 实现一个基于用户行为的智能推荐系统

震撼时刻：第1次 vs 第100次

分层解耦的设计哲学

总结：从六步循环到五层架构

延伸阅读与交流

Goal：`/goal 实现一个基于用户行为的智能推荐系统`