#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 ·  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有什么本质区别？先看数据：维度LangChainAutoGenCrewAIHermes架构模式链式管道（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对象：{  "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 · Orch2 · Orchestration Layer — 拆解与规划Goal Parser将Goal拆解为Task DAG：┌────────────────────────────────────────────────────────┐│                    Goal: 智能推荐系统                    ││                                                        ││  T1: 需求分析 ──→ T2: 数据模型设计 ──→ T3: 算法选型    ││                        │                  │             ││                        ▼                  ▼             ││                   T4: API设计       T5: 核心引擎实现    ││                        │                  │             ││                        ▼                  ▼             ││                   T6: 集成测试 ←── T7: 性能优化        ││                        │                               ││                        ▼                               ││                   T8: 部署与文档                        │└────────────────────────────────────────────────────────┘Planning Engine在这个阶段做了两件关键的事：