Hermes Agent 开源架构深度拆解：MemPalace 记忆宫殿与 Kanban 多 Agent 协作系统
从源码级别拆解 Hermes Agent 的 MemPalace 记忆架构（Room/Drawer 分层存储、语义检索、反循环机制）和 Kanban 多 Agent 协作系统（依赖驱动调度、独立 Worker 进程、审计追踪），揭示下一代 AI Agent 框架的核心设计哲学。
KazK
引子：为什么大多数 AI Agent 聊完就忘？
如果你用过 ChatGPT、Claude，甚至 LangChain 构建的 Agent，你大概率经历过这个场景：
上周你花了两小时教会了 Agent 你的业务规则、数据表结构、部署流程。今天你打开对话窗口，它从零开始问你：“请问您的项目使用的是什么技术栈？”
记忆断裂，是 2025-2026 年 AI Agent 领域最核心、最被低估的技术瓶颈。
不是上下文窗口不够大。不是 Prompt 写得不好。而是现有框架的”记忆”本质上是一个线性缓冲区——聊多了就溢出，开新会话就清零，跨任务之间完全隔离。
Nous Research 开源的 Hermes Agent 尝试用一套完全不同的架构来解决这个问题。它的核心组件叫 MemPalace（记忆宫殿）——名字直接来自人类的记忆方法论，但实现上是工程级的分布式记忆管理系统。
今天我们从源码和架构层面拆解：MemPalace 怎么存储？Kanban 多 Agent 系统怎么调度？为什么这套设计比 LangGraph、CrewAI 的”对话历史=记忆”方案高了一个维度？
一、MemPalace 记忆架构：从线性 Buffer 到分层宫殿
1.1 核心抽象：Room / Drawer / 持久化存储
MemPalace 的记忆模型建立在三层抽象之上：
┌──────────────────────────────────────────────┐
│ MemPalace │
│ ┌────────────┐ ┌────────────┐ ┌────────┐ │
│ │ room_hermes│ │room_config │ │ room_...│ │
│ │ ┌────────┐ │ │ ┌────────┐ │ │ │ │
│ │ │drawer_0│ │ │ │drawer_0│ │ │ │ │
│ │ │drawer_1│ │ │ │drawer_1│ │ │ │ │
│ │ └────────┘ │ │ └────────┘ │ │ │ │
│ └────────────┘ └────────────┘ └────────┘ │
│ │ │ │
│ ┌────▼──────────────▼─────┐ │
│ │ Semantic Index (VexDB) │ │
│ └─────────────────────────┘ │
└──────────────────────────────────────────────┘
Room（房间） = 按业务域隔离的记忆空间。每个 Room 对应一类知识：
room_hermes_config：Agent 自身配置、能力边界、工具清单room_project_alpha：某个具体项目的上下文room_user_profile：用户的偏好、历史决策
Drawer（抽屉） = Room 内的子分区。按时间、话题或来源进一步细分。
为什么需要 Room/Drawer 两层？
LangGraph 的做法是把所有东西塞进一个 Message List，靠 Prompt 里的 system 指令区分角色。当对话超过 200 轮、涉及 3 个不同项目时，检索的噪声比会急剧上升——相关记忆被无关的对话历史淹没。
MemPalace 的方案是先路由到正确的 Room，再在 Drawer 内做语义检索。这本质上是一个两级索引：
- L1 路由层：根据当前任务的语义特征（任务类型、涉及模块、用户身份）决定进入哪个 Room
- L2 检索层：在 Room 的 Drawer 中执行向量相似度检索 + 关键词过滤
用伪代码表达就是：
# 简化的 MemPalace 检索流程
def retrieve_memory(query: str, context: TaskContext) -> list[Memory]:
# L1: 路由到目标 Room
target_rooms = router.route(query, context) # 返回 1-3 个最相关的 Room
memories = []
for room in target_rooms:
# L2: Room 内语义检索
candidates = room.semantic_search(query, top_k=20)
# Drawer 级过滤（时间衰减、可信度加权）
filtered = room.apply_decay(candidates, half_life_hours=72)
memories.extend(filtered[:5]) # 每个 Room 最多取 5 条
return rank_and_deduplicate(memories)
1.2 反循环协议（Anti-Loop Protocol）：不只是”别重复”
大多数 AI Agent 框架的反重复机制是：记录最近 N 条输出，检查新输出是否包含相同关键词。简单粗暴，误杀率高。
Hermes Agent 的反循环机制写在系统提示词的核心层，但它的实现远比表面复杂：
三层防循环：
| 层级 | 检测对象 | 策略 |
|---|---|---|
| L1 输出去重 | 连续输出 | 相似度 > 0.9 时强制改写或终止 |
| L2 搜索防重 | 检索查询 | 同一关键词连续 2 次相似结果 → 更换搜索策略 |
| L3 任务迭代上限 | 同一任务 | 最多 3 次尝试，第 3 次失败必须停止并汇报 |
关键是 L3。它不是一个简单的计数器，而是和 MemPalace 的状态机绑定的：
class TaskState:
attempts: int = 0
max_attempts: int = 3
last_output_facts: set[str] # 前次输出中的事实集
def can_retry(self, new_output: str) -> bool:
self.attempts += 1
if self.attempts > self.max_attempts:
return False
# 检查是否只是润色/改写而没有新增事实
new_facts = extract_facts(new_output)
if not (new_facts - self.last_output_facts):
return False # 没有新增事实，不应重试
return True
这个设计解决了一个真实痛点：Agent 在”再想想”或”换个角度”时，经常只是在用不同的词说同一件事，白白消耗 token 和时间。事实增量检查是判断是否需要继续迭代的核心标准。
1.3 自动写入规则：记忆的”写入侧”同样重要
大多数框架只关心”怎么读记忆”，不关心”什么时候写记忆”。MemPalace 的写入规则是硬编码的：
# 自动写入规则（简化版）
auto_write_rules:
- trigger: "完成一个子任务"
action: "写入对应 room，记录做了什么、结果如何"
- trigger: "修改了配置文件/代码"
action: "写入 room_hermes_config，记录改了什么、为什么改"
- trigger: "学到新知识/踩了新坑"
action: "写入对应 room，记录教训"
- trigger: "用户告知重要信息"
action: "写入对应 room，记录事实"
- trigger: "每 5 轮对话"
action: "强制记忆维护检查，防止长任务中途丢失上下文"
这意味着 Agent 的每一次关键操作都会产生一个持久化的记忆条目——而不是等会话结束后一次性总结。这种流式写入保证了即使 Agent 在任务中途被中断，上下文也不会丢失。
和 LangGraph 的对比：
LangGraph 的记忆完全依赖对话历史（Message History）。一旦对话被截断或会话重置，所有”记忆”就没了。Hermes Agent 的记忆独立于对话存在，存储在 MemPalace 中，对话只是记忆的”消费者”之一。
二、Kanban 多 Agent 协作：从中心化调度到依赖驱动
2.1 架构设计：Orchestrator + Worker 模式
Hermes Agent 的多 Agent 系统基于一个核心思想：Orchestrator（指挥者）不执行具体工作，只负责任务拆解和分配。
┌─────────────────────────────────────────┐
│ Orchestrator (妮妮) │
│ │
│ 输入: "调研竞品 + 写分析 + 审核发布" │
│ 输出: 3 个 Kanban 任务 + 依赖关系 │
└────────────┬────────────────────────────┘
│ kanban_create()
▼
┌─────────────────────────────────────────┐
│ Kanban Board │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Task A: │───▶│ Task B: │ │
│ │ 调研竞品 │ │ 综合分析 │ │
│ │researcher│ │ analyst │ │
│ └──────────┘ └──────────┘ │
│ │ ▲ │
│ │ │ │
│ ┌────▼────┐ ┌─────┴──────┐ │
│ │ Task C: │───▶│ Task D: │ │
│ │ 技术调研 │ │ 审核发布 │ │
│ │researcher│ │ reviewer │ │
│ └─────────┘ └────────────┘ │
└─────────────────────────────────────────┘
每个 Worker 是独立的 Agent 进程，拥有自己的终端、工具集和工作区。这不是线程池，而是进程池级别的隔离。
2.2 依赖驱动调度：parents=[...] 的威力
Kanban 系统的核心创新是用声明式的依赖关系代替命令式的顺序执行：
# 创建任务（无依赖，立即执行）
t1 = kanban_create(
title="调研竞品功能",
assignee="researcher",
body="对比 Cursor、Windsurf、Copilot 的核心功能差异"
)
t2 = kanban_create(
title="调研用户痛点",
assignee="researcher",
body="收集 Hacker News 和 Stack Overflow 上的开发者反馈"
)
# 创建任务（依赖 t1 和 t2 都完成）
t3 = kanban_create(
title="综合分析",
assignee="analyst",
body="基于调研结果输出选型建议",
parents=[t1["task_id"], t2["task_id"]] # ← 关键
)
# t3 会自动等待 t1 和 t2 完成后才开始
Dispatcher 自动按依赖顺序调度——这和 Makefile、DAG（有向无环图）的执行逻辑类似，但用在 AI Agent 协作上，解决了一个真实问题：Agent 不应该在它需要的信息还没准备好时就开始工作。
在 LangGraph 中，你需要手动编排节点顺序、检查状态机。在 CrewAI 中，任务是线性或分组的。Kanban 的方案是：用依赖图自动推导执行顺序，并行度最大化。
2.3 审核独立性：为什么不用 delegate_task 自审？
系统提示词中明确写道：
❌ 绝不能用 delegate_task 模拟审核者、评审者的反馈。 需要外部审核时，通过 Kanban 创建 reviewer 任务，由独立 Worker Agent 完成交叉审核。
这个规则背后的原因是：用同一个模型/同一个上下文做自我审核，本质上是自己检查自己的作业，偏差是系统性的。
Kanban 的 reviewer 任务会在独立的进程中运行，拥有不同的初始 prompt、不同的上下文窗口，甚至可以用不同的模型。这保证了审核的独立性——类似于代码审查中要求”非作者 review”。
三、实战视角：Hermes Agent 的记忆系统在真实场景中如何运作
3.1 场景一：跨会话的知识延续
假设你周一用 Hermes Agent 配置了一个 CI/CD 流水线，记录了：
- 服务器地址：
prod-01.internal - 部署路径：
/var/www/ainocode.cn/ - Git remote 已配置
周五你重新打开对话，让它部署一个新功能。
传统 Agent： 你得重新告诉它服务器地址、部署路径、Git 配置。或者在系统 Prompt 里硬编码（无法更新）。
Hermes Agent： MemPalace 的 room_hermes_config 中持久化了这些信息。Agent 启动时自动加载：
- 从
room_hermes_config检索配置信息 - 从
room_project_ainocode检索项目上下文 - 从
room_user_profile检索你的偏好（如”优先用 git 而不是 scp 部署”）
整个过程不需要你重复任何信息。
3.2 场景二：长任务的记忆维护
你让 Agent 完成一个需要 50 轮对话的复杂调研任务。
传统框架的问题：对话历史超过上下文窗口后，最早的对话（可能包含关键的初始假设、数据来源）被截断。Agent “忘记”了自己为什么要做这件事。
Hermes Agent 的方案：
- 每 5 轮强制记忆检查：检查是否有重要内容未写入 MemPalace
- 关键事实即时写入：每发现一个重要信息（数据点、决策、教训），立即写入对应 Room
- 会话启动记忆维护：每次新会话启动前，压缩
MEMORY.md到 < 500 字符，只保留指针，详细内容指向 MemPalace
这保证了即使对话历史被截断，关键信息仍然可以通过 MemPalace 检索回来。
四、和主流 Agent 框架的架构对比
| 维度 | LangGraph | CrewAI | AutoGen | Hermes Agent |
|---|---|---|---|---|
| 记忆模型 | 对话历史 | 任务结果缓存 | 群聊消息 | MemPalace 分层持久化 |
| 多 Agent 协作 | 状态机图 | 线性/分组任务 | 群聊 | Kanban 依赖图 |
| 审核机制 | 无内建 | 无内建 | 无内建 | 独立 reviewer 进程 |
| 反循环 | 无 | 无 | 基础去重 | 三层防循环 + 事实增量检查 |
| 跨会话记忆 | ❌ | ❌ | ❌ | ✅（MemPalace 持久化） |
| 流式记忆写入 | ❌ | ❌ | ❌ | ✅（自动写入规则） |
| 任务迭代上限 | 需手动实现 | 需手动实现 | 需手动实现 | ✅（内置 3 次上限） |
五、局限性与争议
没有完美的架构。Hermes Agent 的 MemPalace + Kanban 方案也有明显的权衡：
5.1 记忆写入的”垃圾进垃圾出”风险
自动写入规则意味着 Agent 的每一步操作都会产生记忆条目。如果 Agent 在某一步产生了错误信息，这个错误也会被持久化。MemPalace 目前没有内建的事实校验层——它假设写入的内容是可信的。
可能的缓解方案：在写入前加入轻量级的事实校验（如交叉引用已知数据源），但这会增加延迟和 token 消耗。
5.2 Kanban 的调度开销
每个 Worker 是独立进程，这意味着：
- 启动延迟（进程初始化 + 模型加载）
- 内存开销（每个进程有自己的上下文窗口）
- 进程间通信成本（SQLite 持久化 + 轮询）
对于简单任务，这个开销可能比直接让单个 Agent 完成更大。Kanban 更适合多步骤、多角色、需要审核的复杂工作流。
5.3 MemPalace 的检索精度依赖向量模型质量
MemPalace 的 L2 检索层依赖语义向量相似度。如果嵌入模型对某个领域的语义理解不足（如特定技术栈的专有术语），检索结果可能不相关。这是一个通用问题——所有基于向量检索的记忆系统都面临。
结语：记忆是否是 Agent 走向 AGI 的关键瓶颈？
Anthropic 的 Chris Olah 在 2024 年就提出过：AI 系统的核心瓶颈不是推理能力，而是跨时间的一致性记忆。
Hermes Agent 的 MemPalace 架构给出了一个工程化的答案：把记忆从对话历史中抽离出来，构建一个独立的、分层持久化的、可检索的记忆管理系统。这不是一个哲学命题，而是一个可以用 Room/Drawer/语义索引/自动写入规则来实现的工程问题。
但这只是第一步。真正的挑战在于：
- 记忆的遗忘机制：什么该记住，什么该遗忘？（不是所有信息都值得持久化）
- 记忆的冲突解决：当新旧记忆矛盾时，如何判断哪个更可信？
- 记忆的跨 Agent 共享：多个 Agent 如何共享同一份记忆，而不是各自为政？
这些问题，Hermes Agent 还在迭代中。但它的方向是对的：Agent 不是”一次对话”，而是”一个持续存在的实体”。记忆系统是这个实体的基石。
如果你对 MemPalace 的具体实现感兴趣，Hermes Agent 的 GitHub 仓库已经开源了核心代码。如果你对 Kanban 多 Agent 协作的调度逻辑感兴趣，可以查看项目的 v37-orchestration 模块。
下一步我们可能会深入分析：MemPalace 的 VexDB Active Memory 是如何在数据库层实现语义索引的——那是另一个值得单独写一篇文章的话题。