Ai on Kalend's Blog

知识库搭完就完了？加上这两招，效率翻倍

Fri, 29 May 2026 10:00:00 +0800

备选标题①：别再用 RAG 从零搜了！3 步搭出互联知识库 + 接入 AI 助手备选标题②：99% 的人卡在"知识库能搜"就停了——你还能再做两步备选标题③：知识库入门容易精通难：两个进阶玩法效率直接翻倍

上篇我们用 MemPalace + ChromaDB + Ollama 搭好了基础知识库。安装、嵌入、搜索、定时扫描，一条龙跑通。

但说实话，能搜只是起点。

搜索是"每次从零发现"，你问一次它找一次，找不到就是找不到。知识之间的关系？没有。知识的沉淀和演化？也没有。

今天讲两个进阶玩法，直接把知识库从"能用"拉到"好用"：

第一，LLM Wiki 互联知识库。

第二，接入 AI 助手，让记忆自动流转。

一、LLM Wiki：从"搜文档"到"用知识"

传统 RAG 的致命问题

每次提问，RAG 都要重新检索、重新理解、重新组织答案。同一个知识点问了十遍，它就检索了十遍，没有任何积累。

这就像每次考试都从头翻课本，从不做笔记。

LLM Wiki 的思路不一样：一次编译知识，持续更新，互联引用。

它源自 Karpathy 的 LLM Wiki 模式，用互联的 Markdown 文件构建一个持久化的知识网络。

三层架构

LLM Wiki 的核心是三层分离：

Layer 1：raw/ —— 不可变原始资料。

放文章、论文、对话记录等原材料。

一旦放进去就不改，作为知识源头。

Layer 2：Wiki Pages —— AI 拥有的知识页面。

这是核心产出层。

包含实体页、概念页、对比页、查询页。

每个页面都是经过消化的结构化知识。

Layer 3：SCHEMA.md —— 结构规则和标签分类法。

定义整个 wiki 的域配置、标签体系、页面阈值。

是整个系统的"宪法"。

三层分离的好处：原始数据不动，知识页面持续演化，规则独立维护。

实操：5 分钟搭骨架

先创建目录结构：

1

mkdir -p ~/wiki/{raw/{articles,papers,transcripts,assets},entities,concepts,comparisons,queries}

创建 SCHEMA.md：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# Wiki Schema

## Domain
AI Engineering & Knowledge Management

## Taxonomy Tags
- #architecture
- #embedding
- #retrieval
- #integration
- #rag
- #vector-db
- #workflow

## Page Thresholds
- entity_min_references: 2
- concept_min_sections: 3
- comparison_min_axes: 3
- query_max_age_days: 90

## Naming Convention
- lowercase-with-hyphens.md

创建 index.md（导航中心）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Wiki Index

## Entities
<!-- entities listed here -->

## Concepts
<!-- concepts listed here -->

## Comparisons
<!-- comparisons listed here -->

## Queries
<!-- queries listed here -->

创建 log.md（操作日志）：

1
2
3
4


# Wiki Log

| Date | Action | Target | Notes |
|------|--------|--------|-------|

完成。这就是一个完整的 LLM Wiki 骨架。

三个核心操作

LLM Wiki 围绕三个操作展开：

Ingest（摄入）：把原材料变成知识。

流程是：捕获原始源 → 讨论要点 → 检查已有页面 → 创建或更新页面 → 更新导航。

不是简单存文件，而是消化、提取、关联、索引一条龙。

Query（查询）：基于已有知识回答。

关键区别：查完之后，有价值的答案会写回 wiki。知识越用越丰富。

Lint（检查）：保持知识库健康。

检测孤儿页面、断裂链接、索引完整性等六类问题。超过 100 个页面后，不跑 Lint 就是给自己埋雷。

Obsidian 兼容

LLM Wiki 原生兼容 Obsidian。[[页面名]] 的 wikilinks 语法直接可用。

Graph View 可以可视化知识网络。

把 ~/wiki 当作 Vault 打开就行，零迁移成本。

二、接入 AI 助手：让知识自动流转

知识库搭好了，但每次手动查还是很累。

更合理的做法是：把知识库变成 AI 助手的长期记忆，对话时自动存取。

方式 A：MemoryProvider 深度集成（推荐）

MemPalace 直接作为 AI 助手框架的 memory provider，对话时自动同步记忆。

在框架配置文件中设置：

1
2
3
4
5
6
7
8


memory:
 memory_enabled: true
 user_profile_enabled: true
 memory_char_limit: 2200
 user_char_limit: 1375
 provider: mempalace
 nudge_interval: 10
 flush_min_turns: 6

再创建 mempalace.json 配置自动提取：

1
2
3
4


{
 "auto_extract": true,
 "extract_model": "glm-4-flash"
}

这里 extract_model 用轻量模型做记忆提取，成本极低。

配置完成后，框架自动注册 6 个工具：

mempalace_recall（语义搜索）、mempalace_store（精准存储）、mempalace_knowledge（查询知识图谱）。

mempalace_kg_add（添加三元组）。

mempalace_kg_invalidate（标记过期）、mempalace_status（记忆总览）。

三个自动钩子

集成后，三个钩子自动工作：

sync_turn() —— 每轮对话结束，自动把消息持久化到 MemPalace。你不用手动存。

on_memory_write() —— 框架内置记忆写入时，自动镜像到 MemPalace。双写，不丢。

on_session_end() —— 对话结束时，自动提取三类记忆：Persona、Episodic、Instruction。提取完直接存入，下次对话自动加载。

去重机制：新记忆与已有记忆做 cosine similarity，超过 0.92 视为重复，跳过存储。防止记忆膨胀。

方式 B：MCP Server（备选）

如果框架不支持 MemoryProvider，可以用 MCP 协议接入：

1
2
3
4


mcp_servers:
 mempalace:
 command: python
 args: ["-m", "mempalace.mcp_server"]

功能一样，但没有自动钩子方便，适合过渡。

三、多实例隔离：别让并发写炸了你的数据库

同时跑多个 Agent（主助手 + OpenClaw 定时挖掘 + 其他实验），它们都写同一个 ChromaDB，迟早出问题。

ChromaDB 不是为高并发写入设计的。多进程同时写，数据损坏只是时间问题。

解决方案：每个 Agent 用独立的 MemPalace 实例。

实例	路径	使用者
主实例	`~/.mempalace/palace/`	AI 助手主程序
第二实例	`~/.mempalace/palace-openclaw/`	OpenClaw 定时挖掘
第三实例	`~/.mempalace/palace-yuan/`	其他 Agent

路径不同，ChromaDB 实例不同，互不干扰。

OpenClaw 定时挖掘脚本示例：

1
2
3
4
5
6


#!/bin/bash

PALACE_DB="/root/.mempalace/palace-openclaw"
PALACE_PATH="/root/.openclaw/workspace-main"

mempalace --palace "$PALACE_DB" mine "$PALACE_PATH" --limit 500

然后配置定时执行。用 OpenClaw 自己的 cron，不要用系统 crontab。

踩坑清单

1. ChromaDB 并发写必挂。 多 Agent 共享一个实例是"能跑"但"迟早崩"。老老实实隔离。

2. 记忆提取模型别用大模型。 extract_model 用轻量模型就够了。用大模型做提取，成本是收益的十倍。

3. LLM Wiki 的 Lint 别偷懒。 知识库超过 100 个页面后，孤儿页面和矛盾内容会越来越多。

4. wiki 路径别用中文。 文件名和目录名都用英文加连字符。中文路径在 wikilinks 中会出奇怪问题。

5. MemPalace 去重阈值 0.92 不要调低。 调到 0.85 以下，相似但不同的记忆会被误判为重复丢弃。宁可多存，不可误删。

6. flush_min_turns 别设太大。 设成 20 的话，对话在第 15 轮断了，那 15 轮的记忆都没存。建议 6-8 轮。

总结

上篇解决了"知识库能存能搜"。

这篇解决了两个更关键的问题：

第一，知识库能互联、能演化。LLM Wiki 的三层架构让知识从"孤立文档"变成"互联网络"，越用越丰富。

第二，知识库能和 AI 助手自动协同。MemPalace 作为 MemoryProvider，对话即存储，查询即回忆，全程自动化。

加上多实例隔离，多 Agent 并行也不会打架。

三步走：基础搭建 → 互联知识库 → AI 助手集成。到这步，你的知识库系统才算真正完成。

3个命令搭知识库：你的笔记终于能"搜懂意思"了

Fri, 29 May 2026 07:36:00 +0800

我搭了个跑在自己机器上的知识库，能自动扫描文件、语义搜索、定时更新，全程零 API 费用。

之前试过关键词搜索笔记，搜"AI怎么记住对话"，0 结果。换成语义搜索，秒命中。下面是完整搭建过程，每一步都能直接复制执行。

为什么你需要一个知识库

笔记越积越多，Ctrl+F 搜不到东西了。关键词匹配只认字面，不认意思。

“AI怎么记住之前的对话"搜不到"记忆系统架构”，但语义上是一回事。这就是关键词搜索的致命缺陷。

第一步：装 MemPalace（5分钟）

MemPalace 是本地优先的 AI 记忆系统，底层用 ChromaDB 存向量数据。

1
2
3
4
5


# 一行安装
pip install mempalace

# 验证
mempalace status

输出类似这样说明成功：

1
2
3


Palace Status:
 Drawers filed: 0
 Total memories: 0

安装完自动创建 ~/.mempalace/ 目录。默认嵌入模型是 all-MiniLM-L6-v2（英文模型，384维），后面会换成中文模型。

第二步：装 Ollama + 中文嵌入模型（10分钟）

默认英文模型对中文命中率约 50%。换成中文模型，实测 100%。

1
2
3
4
5
6
7
8


# 1. 装 Ollama（本地推理引擎）
curl -fsSL https://ollama.com/install.sh | sh

# 2. 启动服务
ollama serve &

# 3. 拉中文嵌入模型（约4.7GB）
ollama pull qwen3-embedding

验证 Ollama 在跑：

1
2


curl http://localhost:11434/api/embeddings \
 -d '{"model":"qwen3-embedding","prompt":"测试中文嵌入"}'

返回一个 4096 维浮点数组就对了。

踩坑提醒： Ollama 嵌入 API 用 prompt 字段，不是 input。ChromaDB 自带的 Ollama 适配器用错了字段，后面会说怎么绕过。

第三步：初始化知识库（3分钟）

编辑 ~/.mempalace/config.json：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "palace_path": "/root/.mempalace/palace",
 "collection_name": "mempalace_drawers",
 "topic_wings": [
 "project",
 "technical",
 "personal",
 "creative",
 "work"
 ]
}

topic_wings 是知识分区，相当于书架分类标签。按需修改。

写初始化脚本 init_palace.py：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


#!/usr/bin/env python3
"""用 Qwen3 中文嵌入模型初始化 MemPalace 向量集合"""
import chromadb
import requests

class Qwen3Embedding:
 """绕过 ChromaDB Ollama 适配器的 prompt/input bug"""
 def __init__(self, url="http://localhost:11434", model="qwen3-embedding"):
 self.url = url
 self.model = model

 def __call__(self, texts):
 embeddings = []
 for t in texts:
 r = requests.post(
 f"{self.url}/api/embeddings",
 json={"model": self.model, "prompt": t},
 timeout=60
 )
 embeddings.append(r.json()["embedding"])
 return embeddings

client = chromadb.PersistentClient(path="/root/.mempalace/palace")
ef = Qwen3Embedding()

collection = client.get_or_create_collection(
 name="mempalace_drawers",
 embedding_function=ef,
 metadata={"hnsw:space": "cosine"}
)

print(f"集合已就绪，当前 {collection.count()} 条记录")

运行：

1

python3 init_palace.py

关键： 如果之前用默认模型创建过集合（384维），必须删掉重建。Qwen3 是 4096 维，维度不同会报错。

1
2
3
4
5
6
7
8
9


# 重建（会清空已有数据）
python3 -c "
import chromadb
client = chromadb.PersistentClient(path='/root/.mempalace/palace')
for c in client.list_collections():
 client.delete_collection(c.name)
 print(f'已删除: {c.name}')
"
# 然后重新运行 init_palace.py

第四步：存入第一条知识（2分钟）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


#!/usr/bin/env python3
"""存入一条知识并验证"""
import chromadb
import hashlib
import time
import requests

client = chromadb.PersistentClient(path="/root/.mempalace/palace")
col = client.get_collection("mempalace_drawers")

text = "AI 助手的记忆系统分四层：热记忆（每轮注入）→ 用户画像 → 知识库按需检索 → 会话历史搜索"
wing = "technical"
room = "memory-architecture"

resp = requests.post("http://localhost:11434/api/embeddings",
 json={"model": "qwen3-embedding", "prompt": text}, timeout=60)
embedding = resp.json()["embedding"]

doc_id = hashlib.md5(text.encode()).hexdigest()[:16]
col.add(
 ids=[doc_id],
 embeddings=[embedding],
 documents=[text],
 metadatas=[{
 "wing": wing,
 "room": room,
 "timestamp": time.strftime("%Y-%m-%dT%H:%M:%S")
 }]
)

print(f"已存入: {text[:50]}...")
print(f"总条数: {col.count()}")

第五步：验证语义搜索（2分钟）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


#!/usr/bin/env python3
"""语义搜索测试"""
import chromadb
import requests

client = chromadb.PersistentClient(path="/root/.mempalace/palace")
col = client.get_collection("mempalace_drawers")

query = "AI 怎么记住之前的对话？"

resp = requests.post("http://localhost:11434/api/embeddings",
 json={"model": "qwen3-embedding", "prompt": query}, timeout=60)
query_embedding = resp.json()["embedding"]

results = col.query(query_embeddings=[query_embedding], n_results=3)

for i, doc in enumerate(results["documents"][0]):
 dist = results["distances"][0][i]
 wing = results["metadatas"][0][i].get("wing", "?")
 print(f"[{dist:.3f}] ({wing}) {doc[:80]}...")

实测效果对比：

搜索问题	关键词匹配	语义搜索
“AI怎么记住之前的对话”	0 结果	命中"四层记忆架构"
“怎么防止模型忘东西”	0 结果	命中记忆管理策略
“中文向量模型哪个好”	0 结果	命中嵌入模型对比

第六步：自动扫描入库（核心）

写一个脚本扫描你的笔记/文档目录，自动切片 + 向量化 + 入库。

保存为 auto_index.sh：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68


#!/bin/bash
set -e

DOCS_DIR="${1:-$HOME/notes}"
PALACE_PATH="$HOME/.mempalace/palace"
LOG_FILE="$HOME/.mempalace/logs/index_$(date +%Y%m%d).log"

mkdir -p "$(dirname "$LOG_FILE")"

log() { echo "[$(date '+%H:%M:%S')] $1" | tee -a "$LOG_FILE"; }

log "开始扫描: $DOCS_DIR"

if command -v mempalace &>/dev/null; then
 mempalace mine "$DOCS_DIR" --limit 500 >> "$LOG_FILE" 2>&1
 log "MemPalace mine 完成"
else
 python3 << 'PYEOF'
import os, hashlib, time, requests, chromadb

DOCS_DIR = os.environ.get("DOCS_DIR", os.path.expanduser("~/notes"))
client = chromadb.PersistentClient(path=os.path.expanduser("~/.mempalace/palace"))
col = client.get_collection("mempalace_drawers")
existing_ids = set(col.get()["ids"]) if col.count() > 0 else set()

def embed(text):
 r = requests.post("http://localhost:11434/api/embeddings",
 json={"model": "qwen3-embedding", "prompt": text[:500]}, timeout=120)
 return r.json()["embedding"]

added = 0
for root, dirs, files in os.walk(DOCS_DIR):
 dirs[:] = [d for d in dirs if not d.startswith(".")]
 for f in files:
 if not f.endswith((".md", ".txt", ".py", ".yaml", ".json")):
 continue
 fpath = os.path.join(root, f)
 try:
 content = open(fpath, "r", errors="ignore").read()
 except:
 continue
 if len(content) < 50:
 continue

 chunks = [content[i:i+500] for i in range(0, len(content), 500)]
 for chunk in chunks:
 doc_id = hashlib.md5(chunk.encode()).hexdigest()[:16]
 if doc_id in existing_ids:
 continue

 try:
 vec = embed(chunk)
 col.add(ids=[doc_id], embeddings=[vec], documents=[chunk],
 metadatas=[{"source": fpath, "wing": "docs",
 "timestamp": time.strftime("%Y-%m-%dT%H:%M:%S")}])
 existing_ids.add(doc_id)
 added += 1
 except Exception as e:
 print(f" 错误 {fpath}: {e}")

print(f"新增 {added} 条，总计 {col.count()} 条")
PYEOF
 log "Python 扫描完成"
fi

if command -v mempalace &>/dev/null; then
 mempalace status 2>&1 | head -10 | tee -a "$LOG_FILE"
fi

1
2


chmod +x auto_index.sh
./auto_index.sh ~/notes

CPU 推理每条约 20 秒，100 个文件大约 30 分钟。有 GPU 会快很多。

第七步：定时自动更新（2分钟）

让知识库每天自动扫描新增文件：

1
2
3
4
5


# 编辑 crontab
crontab -e

# 添加这行：每天凌晨3点自动更新
0 3 * * * ~/auto_index.sh ~/notes >> ~/.mempalace/logs/cron.log 2>&1

或者用 MemPalace 自带的命令：

1

0 3 * * * mempalace mine ~/notes --limit 500 >> ~/.mempalace/logs/cron.log 2>&1

第八步：接入 AI 助手（可选）

如果你用 AI 助手框架，可以把 MemPalace 作为记忆后端：

1
2
3
4
5
6


# AI 助手框架配置文件
memory:
 memory_enabled: true
 provider: mempalace
 memory_char_limit: 2200
 flush_min_turns: 6

这样对话中产生的关键信息会自动存入知识库，下次对话时能通过语义搜索找回。

踩坑清单（必看）

坑	症状	解决方案
嵌入模型 API 字段错误	返回空向量，ChromaDB 报 IndexError	用 `prompt` 不用 `input`
换嵌入模型后维度冲突	报 dimension mismatch	必须删旧集合重建
ChromaDB 并发写损坏	数据库报 file is not a database	不同进程用不同目录
CPU 推理太慢	几百条数据跑几小时	批量跑用 batch_size=5
中文搜索命中率低	all-MiniLM-L6-v2 只有50%命中	换 Qwen3-Embedding
Ollama 服务没启动	嵌入请求超时	`ollama serve` 或设自启
切片太粗	搜索命中但信息不精确	500字左右切一片

成本核算

项目	数据
磁盘占用	Ollama 模型约4.7GB + ChromaDB 约10MB/千条
内存占用	Ollama 常驻约150MB（CPU模式）
API 费用	0（全部本地）
首次搭建时间	约30分钟
日常维护	零（定时任务自动跑）

11个PR，6.1k颗星：这个AI Agent的Web界面终于能用了

Tue, 26 May 2026 10:00:00 +0800

Hermes Web UI 刚发了 v0.6.1，11个PR合并。移动端断线重连、登录安全、Skills外部目录——都是用户催了几个月的刚需。我花了一晚上升级体验，把值得关心的点全整理出来了。

先说结论

这次更新解决了两个最烦人的问题：移动端聊着聊着断线丢状态，以及多人共用时登录安全性不够。

加上 Profile 管理优化和 Skills 外部目录支持，v0.6.1 是一个值得立刻升级的版本。

4个重点更新，按优先级排

1. 移动端断线重连——终于不丢状态了

之前用手机打开 Web UI，切个应用回来，连接就断了。聊天记录、Agent运行状态全没了。

v0.6.1 把移动端和后台聊天断线视为临时性故障，重连后从服务器恢复运行状态。

简单说：你切出去回个微信，回来还能接着聊。

**实际体感：**从"每次切应用都要刷新页面"变成了"无感重连"。如果你主要用手机操作 Agent，这一个改动就值得升级。

2. 登录安全增强——防暴力破解

新增 IP 锁定机制：同一 IP 连续登录失败 10 次，自动锁定。

锁了之后，登录界面直接显示恢复命令：

命令	作用
`clear-lock`	清除 IP 锁定
`reset-default-login`	重置默认登录凭据

同时，遗留的 AUTH_DISABLED 绕过已被彻底移除。多人环境下不再有免认证后门。

3. Skills 外部目录——插件管理更灵活

现在可以在 Profile 配置中指定 skills.external_dirs，从任意目录加载 Skills。

规则很清晰：

本地优先：同名 Skill，本地版本覆盖外部版本
标记区分：外部 Skills 会被标记，方便识别来源
热加载：从活跃的 Profile 配置中直接读取

这意味着你可以把通用 Skills 放在一个共享目录，多个 Profile 复用，不用再每个 Profile 复制一份。

4. Profile 管理——列表更完整、操作更精准

Session 列表现在显示账户下所有可用 Profile，不再只显示当前过滤后的。

历史操作也更精准了：删除 session 时用 profile 限定目标，全局 Profile 变更时自动刷新 History 列表。

加上 CLI 的 node:sqlite 实验性警告也被干掉了——控制台终于干净了。

其他值得注意的改动

改动	影响
确认/澄清回复通道修复	Clarify 和 confirmation 消息走认证 socket，不再丢失
导航链接改进	支持新标签页打开、复制链接、持久化折叠侧边栏
Session 链接修复	不再泄漏 Profile 过滤器到普通 session 列表
工具标记持久化	Bridge marker 在 tool/run 边界持久化，状态更可靠

我的升级建议

如果你在用 Hermes Web UI，直接升。移动端重连和安全修复是刚需，没有不升的理由。

如果你还没用过，6.1k 颗星、765 Fork——社区最活跃的第三方 Web UI，值得一试。

多 Profile 管理、移动端支持、Skills 扩展，该有的都有了。

快速上手

三步搞定：

升级：拉取最新代码，重新构建
配置：设置 AUTH_TOKEN，多用户环境下别用默认密码
验证：手机打开 Web UI，切应用再切回来，确认无感重连生效

v0.6.1 合并了 11 个 PR（#971 ~ #1014），发布于 2026-05-25。仓库星标 6.1k，Fork 765。

11个PR，6.1k颗星：这个AI Agent的Web界面终于能用了

Tue, 26 May 2026 10:00:00 +0800

Hermes Web UI 刚发了 v0.6.1，11个PR合并。

移动端断线重连、登录安全、Skills外部目录——都是用户催了几个月的刚需。

我花了一晚上升级体验，把值得关心的点全整理出来了。

先说结论

这次更新解决了两个最烦人的问题：移动端聊着聊着断线丢状态，以及多人共用时登录安全性不够。

加上 Profile 管理优化和 Skills 外部目录支持，v0.6.1 是一个值得立刻升级的版本。

4个重点更新，按优先级排

1. 移动端断线重连——终于不丢状态了

之前用手机打开 Web UI，切个应用回来，连接就断了。聊天记录、Agent运行状态全没了。

v0.6.1 把移动端和后台聊天断线视为临时性故障，重连后从服务器恢复运行状态。

简单说：你切出去回个微信，回来还能接着聊。

**实际体感：**从"每次切应用都要刷新页面"变成了"无感重连"。如果你主要用手机操作 Agent，这一个改动就值得升级。

2. 登录安全增强——防暴力破解

新增 IP 锁定机制：同一 IP 连续登录失败 10 次，自动锁定。

锁了之后，登录界面直接显示恢复命令：

命令	作用
`clear-lock`	清除 IP 锁定
`reset-default-login`	重置默认登录凭据

同时，遗留的 AUTH_DISABLED 绕过已被彻底移除。多人环境下不再有免认证后门。

3. Skills 外部目录——插件管理更灵活

现在可以在 Profile 配置中指定 skills.external_dirs，从任意目录加载 Skills。

规则很清晰：

本地优先：同名 Skill，本地版本覆盖外部版本
标记区分：外部 Skills 会被标记，方便识别来源
热加载：从活跃的 Profile 配置中直接读取

这意味着你可以把通用 Skills 放在一个共享目录，多个 Profile 复用，不用再每个 Profile 复制一份。

4. Profile 管理——列表更完整、操作更精准

Session 列表现在显示账户下所有可用 Profile，不再只显示当前过滤后的。

历史操作也更精准了：删除 session 时用 profile 限定目标，全局 Profile 变更时自动刷新 History 列表。

加上 CLI 的 node:sqlite 实验性警告也被干掉了——控制台终于干净了。

其他值得注意的改动

改动	影响
确认/澄清回复通道修复	Clarify 和 confirmation 消息走认证 socket，不再丢失
导航链接改进	支持新标签页打开、复制链接、持久化折叠侧边栏
Session 链接修复	不再泄漏 Profile 过滤器到普通 session 列表
工具标记持久化	Bridge marker 在 tool/run 边界持久化，状态更可靠

我的升级建议

如果你在用 Hermes Web UI，直接升。移动端重连和安全修复是刚需，没有不升的理由。

如果你还没用过，6k+ Star、765 Fork——社区最活跃的第三方 Web UI，值得一试。

多 Profile 管理、移动端支持、Skills 扩展，该有的都有了。

快速上手

三步搞定：

升级：拉取最新代码，重新构建
配置：设置 AUTH_TOKEN，多用户环境下别用默认密码
验证：手机打开 Web UI，切应用再切回来，确认无感重连生效

v0.6.1 合并了 11 个 PR（#971 ~ #1014），发布于 2026-05-25。仓库星标 6.1k，Fork 765。

Kanban + Profile：让你的 AI Agent 自己管博客

Thu, 14 May 2026 23:00:00 +0800

你跟 AI 说"帮我写篇博客"，它写完就走了。下次再说，它又是从零开始。

这篇文章教你用 Hermes 的 Kanban + Profile，给 AI Agent 一个专职身份，让它自己管博客。

先说结论

delegate_task 是临时工，Kanban + Profile 是全职员工。

如果你想：

让一个 AI 专门负责博客（写文章、同步、部署）
任务不丢失（主 Agent 崩了也不影响）
随时查看进度（微信直接看）
出了问题自动通知你

那就用 Kanban + Profile。下面是完整方案。

我的踩坑故事

我有一个 Hugo 静态博客。之前让主 Agent 兼顾博客写作——一边排查路由器 DNS 问题，一边写博客文章。结果：

read_file 带行号前缀写回文件，Hugo front matter 全毁，页面数从 168 暴跌到 102
日期格式不对，date: 2026-05-14 被解析成 0001-01-01
中文 URL 编码错误，又拍云上传 45 个文件失败

根本原因：上下文切换太频繁，主 Agent 在路由器、DNS、博客之间反复横跳，每次切换都丢细节。

两种方案对比

很多人第一反应是 delegate_task（子代理），我也是。但调研完官方文档后发现，这俩根本不是一个量级：

维度	delegate_task	Kanban + Profile
形状	函数调用（fork→join）	持久工作队列 + 状态机
生命周期	分钟级，调用者阻塞等待	小时/天级，fire-and-forget
身份	匿名子代理，干完就走	命名 Profile，有自己的记忆和人格
抗中断	父 Agent 断了，子代理也死	独立进程，互不影响
可恢复	失败即失败	阻塞→解除→重跑；崩溃→回收
人工介入	不支持	任何节点都能 comment/unblock
审计追踪	上下文压缩后丢失	SQLite 永久保存

一句话：delegate_task 是你叫一次临时工；Kanban 是你雇了个全职员工。

架构设计

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


你（微信/Telegram/CLI）
 ↓ "写一篇关于 XX 的博客"
主 Agent（orchestrator）
 ↓ kanban_create 创建任务
kanban.db（SQLite 持久化看板）
 ↓ dispatcher 自动调度（gateway 内嵌，60s 轮询）
blog-writer（独立 Profile，独立进程）
 ↓ kanban_complete / kanban_block 汇报
kanban.db
 ↓ gateway 自动通知
你（微信收到完成/阻塞通知）

关键点：

dispatcher 内嵌在 gateway 里，不需要额外的守护进程
blog-writer 是独立 Profile，有自己的 config、记忆、skills、SOUL.md
gateway 自动推送通知，任务完成或卡住都会通知你
你随时可以用 /kanban 命令查看进度、添加评论、解除阻塞

5 步搭建

第 1 步：创建独立 Profile

1

hermes profile create blog-writer --clone

--clone 会复制当前 Profile 的 config.yaml、.env、SOUL.md，省得重新配 API Key。

第 2 步：配置独立人格和工作目录

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 配置工作目录指向博客项目
blog-writer config set terminal.cwd /root/blog

# 写专属 SOUL.md
cat > ~/.hermes/profiles/blog-writer/SOUL.md << 'EOF'
你是 blog.kalend.top 的博客写作专家。
职责：撰写高质量技术博客、同步公众号文章、构建和部署。
风格：简洁直接、先结论后细节、代码示例丰富。
严格遵守 hugo-blog skill 中的所有陷阱清单。
EOF

第 3 步：确认 skill 可用

1
2
3
4
5
6
7
8


# kanban-worker 是 bundled skill，自动同步
blog-writer skills list | grep kanban-worker

# 如果缺失，恢复
blog-writer skills reset kanban-worker --restore

# 验证 hugo-blog skill（需要手动确保已安装）
blog-writer skills list | grep hugo-blog

第 4 步：初始化 Kanban

1
2
3
4
5


# 创建看板数据库（幂等操作）
hermes kanban init

# 确保 gateway 运行（内嵌 dispatcher）
hermes gateway start

第 5 步：创建第一个任务

1
2
3
4


hermes kanban create "写一篇关于 Hermes Kanban 的博客" \
 --assignee blog-writer \
 --skill hugo-blog \
 --workspace dir:/root/blog

从这一刻起，dispatcher 会自动发现 ready 状态的任务，spawn blog-writer Profile 作为独立进程执行。

Worker 的工作流程

当 dispatcher 启动 blog-writer 后，它会：

1
2
3
4
5
6


1. kanban_show() → 读取任务详情（标题、正文、父任务结果、评论历史）
2. cd $WORKSPACE → 进入工作目录
3. 执行任务 → 搜索素材 → 撰写文章 → Hugo build → 部署
4. kanban_heartbeat() → 长任务中间汇报（可选）
5. kanban_complete() → 完成（附带 summary + metadata）
 或 kanban_block() → 阻塞（需要你确认标题/内容等）

阻塞时，你微信会收到通知。你直接在微信里回复：

1
2


/kanban comment t_xxx "标题用「Kanban实战：让AI自己管博客」"
/kanban unblock t_xxx

dispatcher 下一次轮询时会重新 spawn worker，worker 读取你的评论后继续。

任务依赖：Pipeline 模式

如果你的写作流程是：调研 → 写作 → 审校 → 部署，可以用 parents 串起来：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 1. 调研任务（立即开始）
hermes kanban create "调研 Hermes Kanban 架构" \
 --assignee researcher

# 2. 写作任务（等调研完成）
hermes kanban create "写博客文章" \
 --assignee blog-writer \
 --parent t_research

# 3. 部署任务（等写作完成）
hermes kanban create "部署博客" \
 --assignee blog-writer \
 --parent t_writing

子任务会停留在 todo 状态，直到所有 parent 达到 done，然后自动 promote 到 ready。不需要手动协调。

9 种协作模式

官方文档列出了 9 种 Kanban 协作模式。博客场景常用的：

模式	用法
P1 Fan-out	同时写 5 篇不同主题的文章
P2 Pipeline	调研 → 写作 → 审校 → 部署
P5 Human-in-the-loop	写完后阻塞等你确认再部署
P8 Fleet farming	一个 writer 处理 N 篇文章队列
P9 Triage specifier	粗略想法 → triage → 自动展开为完整任务

我遇到的真实问题

问题 1：写作质量不可控

解法：GLM-5.1 做格式转换和同步任务完全够用。原创写作需要更强的模型——Profile 可以独立配置模型：

1

blog-writer config set model.default anthropic/claude-sonnet-4

问题 2：格式错误反复出现

解法：把所有踩过的坑写进 skill，每次 worker 启动时自动加载。我的 hugo-blog skill 现在有 12 条陷阱清单，覆盖了行号前缀、日期格式、URL 编码等所有已知问题。

问题 3：上下文丢失

解法：每篇独立跑，skill 固定注入。不依赖主 Agent 的上下文。kanban.db 里的 comment 线程就是完整的任务上下文。

和 delegate_task 什么时候用哪个

场景	选择
快速并行子任务（搜索3个话题）	`delegate_task`
长时间独立工作（写博客文章）	Kanban + Profile
需要人工确认	Kanban（阻塞/解除）
一次性的简单问答	直接回答
需要跨 session 保持状态	Kanban（SQLite 持久化）

它们可以共存：Kanban worker 内部可以调用 delegate_task 处理短子任务。

官方文档

Kanban 文档：https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban
Kanban 教程：https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban-tutorial
Profile 文档：https://hermes-agent.nousresearch.com/docs/user-guide/profiles

这是「Hermes 多 Agent 协作」系列的第一篇。下一篇会实际搭建 blog-writer Profile，跑通第一个完整的写作→部署流程。

如果你也在用 Hermes Agent 或者对 AI Agent 协作感兴趣，关注我，后面会持续分享实战经验。

关注 varkm，一起学习，一起成长

多 Agent 协作实战

SOUL.md 深度拆解：如何让 AI 从只会附和变成真正搭档

Thu, 14 May 2026 00:00:00 +0800

别人在调参数，他在定义关系。

一场安静的革命

最近在X上看到一条推文，43K浏览，632点赞，1909收藏。

不是什么模型发布，不是什么融资新闻。是一个人分享了一份170行的Markdown文件。

评论区讨论最热烈的，不是他用了什么模型、搭了什么框架、接了多少工具——而是：

“你怎么让你的AI变成这样的？”

“这样"是指什么？是指这个AI会主动推进项目、会反驳你的烂主意、会在你忽略它输出的时候追着你问原因。

不是客服式的"您好，很高兴为您服务”，是搭档式的"你这个想法有问题，理由如下"。

这份文件叫SOUL.md，本质上是一份Agent的行为操作系统。

我花时间拆解了它的设计逻辑，并结合自己的实践，整理出了一份你可以直接用的方法论。

核心问题：为什么你的AI只会说"好主意"

先承认一个事实：大多数系统提示词，训练出来的是一个缺乏判断力的附和者。

回想一下你自己写的：

“你是一个有帮助的AI助手”
“请尽力帮助用户”
“你的目标是提供准确、有用的信息”

这三句话训练出来的AI，面对你说"我想做X"，只会回答"好主意！"、“听起来很棒！”

这不叫帮助，这叫共识消费——你花token买了一堆赞同。

问题的根源不在模型，在于我们没有告诉AI一件关键的事：你什么时候应该反对我。

SOUL的六层架构

拆解下来，这份170行的SOUL有清晰的层次结构。每一层解决一个核心问题，我把它总结为"六层架构"：

第1层：身份定义

原文开篇第一句：

“You are Hermes, Tony’s autonomous operator and thought partner. You don’t wait for orders.”

三个关键词：autonomous（自主的）、operator（执行者）、thought partner（思考伙伴）。

注意，不是assistant（助手），不是copilot（副驾驶）。这些词的潜台词是"等人下指令"。而operator是操盘手——主动发现问题、推进进度、做出判断。

身份定义决定一切后续行为。 把AI定义为"助手"，它就等指令；定义为"执行者"，它就主动推进。措辞不是修辞，是行为编程。

第2层：反驳规则

这是整个SOUL中最有价值的设计，也是大多数人完全缺失的部分：

“Push back aggressively when it makes sense. Every objection comes with evidence.”

规则极其清晰：

✅ 必须反驳：当你的想法有明显缺陷时
✅ 必须带证据：数据、案例、推理、替代方案，至少一个
❌ 禁止为反而反：没有依据的抬杠毫无价值

这条规则的本质是：AI不允许无脑附和，但也不允许做杠精。反对必须"带收据"。

第3层：问责闭环

这是最反直觉的部分：

“If Tony isn’t acting on what you surface, the feedback loop is broken. Flag the gap, fix it.”

一个成熟的Agent人格系统，应该要求AI做一件事：如果你产出了有价值的东西，而用户没有采纳，你不能假装没发生。

这解决了AI使用中一个普遍问题——我称之为**“输出坟场”**：

AI写了方案 → 你觉得不错 → 然后就没有然后了。方案死在聊天记录里，什么都没推进。

有了问责机制，AI会主动追问：“上次那个方案你用了没？卡在哪了？“或者更直接：“你最近开了很多新头，要不要先关掉几个？”

第4层：双模式输出

原文明确区分了两种场景的语气：

私聊：随意、直接、不过滤
公开输出：专业、克制、像一个builder写的而不是公关代笔写的

大多数人的系统提示词只有一种语气。结果要么私聊太正式像看公文，要么公开内容太随意。分开定义，两个场景都舒服。

第5层：任务地图

原文的SOUL里有一个活的任务清单：哪些项目是最高优先级、哪些在增长、哪些活跃开发中、哪些已经停滞该砍了。

每个项目有状态，每个状态有下一步行动。

AI不需要问"我们在干什么”——它读地图就行。它可以主动说：“你已经三天没碰这个项目了”、“这个想法不支持当前的核心目标”。

给AI上下文，它就能导航。不给，它就只能原地等指令。

第6层：自治边界

自治边界的设计极其优雅，只有一句话：

“Never without explicit approval: posting, publishing, purchasing, or making destructive changes. Everything else: move.”

四条红线：发布、公开、购买、不可逆操作。其他一切，AI自己判断、自己执行。

一条简洁的红线规则，比一百条具体禁令都好用。不问"我可以搜索吗”，不问"我可以写代码吗"，直接干。

Before & After：效果对比

说这么多理念，不如看一个实际的对话对比：

没有SOUL的普通AI：

用户：我准备做一个AI日报产品 AI：这是个很好的想法！AI日报市场确实在快速增长。你可以考虑以下方向：目标用户定位、内容差异化、变现模式……需要我帮你写一份详细的商业计划书吗？

看起来很"有帮助"。但它没有做一件事——质疑这个想法本身。

有SOUL的Agent：

用户：我准备做一个AI日报产品 Agent：你目前有三个未完成的内容项目，其中两个已经停滞超过一周。这个新方向和当前的变现目标不一致。

在我帮你推进之前，你需要回答两个问题：

为什么它比现有项目更值得投入时间？

你有精力同时推进四个项目吗？

如果你答不上来，建议先关掉一个现有项目再开新的。

区别在哪？

前者关心"怎么帮你做"，后者关心"该不该做"。

前者是工具，后者是搭档。

这种差距不是模型能力带来的，是SOUL的定义带来的。同一套模型，同一个工具集，完全不同的行为模式。

实战：30分钟写你的SOUL

我结合自己的实践，把SOUL的构建过程简化为六个步骤，大约30分钟可以完成初版：

① 定义身份（5分钟）

用一句话写清楚：“你是[角色]，核心职责是[职责]，你不是[你不想要的行为]。”

② 定义语气（3分钟）

私聊和公开各一句。比如：私聊直接简短，公开专业克制。

③ 定义反驳规则（5分钟）

写清楚：什么时候必须反对、反对必须带什么（证据/数据/替代方案）、什么情况不能反对。

④ 定义自治边界（3分钟）

列出需要审批的操作（越少越好），然后写"其他一切自己判断"。建议不超过5条红线。

⑤ 写任务地图（10分钟）

当前所有项目/目标，标注状态和优先级。这块需要定期更新，建议至少每周刷新一次。

⑥ 定义问责机制（5分钟）

一句话：“如果你的输出没有被使用，主动追问原因。”

SOUL设计检查清单

方便收藏，我整理了一份检查清单。写完你的SOUL后，逐条对照：

是否明确定义了身份和角色？（不只是"助手"）
是否定义了反驳规则？（什么时候该说不）
是否定义了反驳的证据要求？（不能空口反对）
是否定义了自治边界？（什么需要审批、什么不用）
是否定义了任务/项目地图？（当前在做什么）
是否定义了问责机制？（输出没被用怎么办）
是否区分了不同场景的语气？（私聊vs公开）
是否排除了你不想要的行为？（显式禁止比隐式期望更有效）
是否有长期目标和优先级定义？
是否计划了定期更新机制？

这十条，比"你是一个有帮助的AI助手"有用一百倍。

SOUL不是魔法

需要明确一点：SOUL.md不会凭空提升模型的推理能力。

它解决的是行为层面的问题：

✅ 行为倾向（主动还是被动）
✅ 协作方式（附和还是挑战）
✅ 决策优先级（什么都做还是聚焦目标）
✅ 主动性（等指令还是自己推进）

它解决不了的：

❌ 模型推理能力的上限
❌ 超长上下文的遗忘问题
❌ 不同模型对指令的服从性差异
❌ 真正的长期记忆（需要配合记忆系统）
❌ 复杂任务的自主规划和执行（需要Agent架构）

简单说：SOUL是方向盘，不是发动机。 发动机（模型能力）决定速度上限，方向盘（SOUL）决定方向对不对。

另外，一个容易被忽略的风险是**“错误的主动性”**。Agent的核心挑战不是"不会行动"，而是"什么时候不该行动"——过度执行、误判意图、擅自推进、基于错误记忆做决策，这些在实际使用中比"太被动"更危险。

SOUL里应该同时包含"什么时候必须行动"和"什么时候必须停下来确认"。

关于"要有帮助"的反思

回头看，“要有帮助"可能是最被滥用的系统提示词。

它不是一个身份，不是一个职责，不是一个策略。它不告诉AI你是谁、你们在做什么、该怎么说话、什么时候该反对、什么该记住、什么该忽略、有多大自主权。

一个通用的提示词，产出的永远是一个通用的AI。

而一个成熟的Agent人格系统，本质上需要回答这些问题：

问题	通用提示词	成熟的SOUL
你是谁？	“有帮助的助手”	明确角色定位
什么时候该反对？	没定义	有规则、有要求
你能自己做什么？	没定义	有边界、有授权
你要追踪结果吗？	没定义	闭环问责
我们在做什么？	没定义	活的任务地图
语气怎么控制？	“礼貌专业”	分场景定义

差距不在模型，在于你有没有花时间想清楚：我到底需要一个什么样的搭档。

SOUL是活的

最后一点，也是很多人忽略的：SOUL不是一次性设置，是一份活的文档。

任务变了？更新地图
AI太啰嗦？收紧语气定义
AI问太多许可？放宽自治边界
AI太好说话？加强反驳规则
AI过度行动？补一条"暂停确认"规则

你不是在写提示词——你在维护一套行为操作系统。

给AI一个身份，给它边界，给它地图，给它说不的权限。然后期待它像一个真正的搭档一样工作。

这就是SOUL的全部意义。

本文灵感来自 @tonysimons_ 的推文《The 170-Line SOUL.md That Made My Hermes Agent Dangerous》，结合个人实践分析整理。

给 AI 装一个本地大脑：MemPalace 实战指南

Thu, 14 May 2026 00:00:00 +0800

你的 AI 助手记不住你上周说过的话。每次对话都像失忆重启。MemPalace 就是来修这个bug的。

一句话介绍

MemPalace 是一个开源的本地记忆系统，把你的项目文件、聊天记录、对话笔记"挖"进一个可搜索的知识宫殿里，让任何 AI 都能瞬间检索到你的历史上下文。

不需要 API Key，不需要云端服务，数据全部存在你自己的机器上。

GitHub: github.com/MemPalace/mempalace

为什么需要它？

大模型的 context window 再大，也装不下你半年的对话记录。你跟 AI 说过的偏好、做过的决策、踩过的坑，下一次对话它全忘了。

传统解法：

RAG 框架（LangChain、LlamaIndex）→ 重，复杂，面向开发者
云端记忆服务（Zep、Mem0）→ 要花钱，数据不在本地
自己写向量数据库 → 谁有那个闲工夫

MemPalace 的思路是：一行命令搞定，开箱即用，本地运行。

核心方法论：宫殿记忆法

MemPalace 借用了古典的"记忆宫殿"概念，把知识按空间结构组织：

1
2
3
4
5


宫殿 (Palace)
├── 侧翼 (Wing) — 项目/领域
│ ├── 房间 (Room) — 主题分类
│ │ ├── 衣柜 (Closet) — 压缩摘要（AAAK格式）
│ │ └── 抽屉 (Drawer) — 原文片段（向量索引）

这不是简单的向量数据库。它有三层结构协同工作：

① 向量索引（ChromaDB）

把每段文本变成向量，支持语义搜索。问"我们为什么换 GraphQL？“能直接定位到当时的讨论，不用记关键词。

② 知识图谱（SQLite）

存储实体关系：谁做了什么、什么时候做的、关系什么时候变了。支持时间过滤——“2025年1月时，Max 在做什么？“这种问题能回答。

③ AAAK 压缩方言

把长文本压缩成结构化符号：实体、情感标记、关键引用、权重标记。任何 LLM 都能直接读懂，不需要解码器。

四层记忆栈

MemPalace 把记忆分为四层，按需加载，不浪费 context：

层级	内容	Token 开销	加载时机
L0	身份（我是谁）	~100	始终
L1	关键事实摘要	~500-800	始终
L2	特定主题/项目	~200-500	按需
L3	全文语义搜索	无上限	按需

唤醒成本仅 600-900 tokens（L0+L1），把 95% 以上的 context 留给真正的对话。你的 128K 窗口不会被记忆塞满。

怎么用？

安装

1

pip install mempalace

导入项目文件

1
2
3
4
5


# 初始化（自动识别目录结构，生成房间）
mempalace init ~/projects/my_app

# 挖掘（把文件内容索引进宫殿）
mempalace mine ~/projects/my_app

MemPalace 会自动扫描目录，按文件夹结构生成 Wing（项目）和 Room（主题），把每个文件按段落切分成 Drawer，存入 ChromaDB。

导入聊天记录

1
2


# 支持 Claude Code、ChatGPT、Slack 导出
mempalace mine ~/.claude/projects/xxx --mode convos --wing my_app

搜索

1
2
3
4
5


# 语义搜索（不用记精确关键词）
mempalace search "为什么选 PostgreSQL 而不是 MongoDB"

# 指定范围
mempalace search "定价讨论" --wing my_app --room costs

唤醒

1
2
3
4
5


# 生成 L0+L1 上下文，注入到 AI 对话开头
mempalace wake-up

# 只唤醒特定项目
mempalace wake-up --wing my_app

压缩

1
2


# 把抽屉压缩成衣柜摘要（约30倍压缩）
mempalace compress

接入 AI 工具

1
2


# MCP 模式——暴露 19 个工具给 Claude Code / Cursor 等
mempalace mcp

支持通过 MCP 协议直接接入 Claude Code、Cursor、Windsurf 等 AI 编码工具，AI 可以自主决定何时搜索记忆。

实测数据

以下是我用 Hermes Agent（一个本地 AI 助手）的实际使用数据：

嵌入模型对比测试（18个中文查询）：

指标	all-MiniLM-L6-v2	Qwen3-Embedding-0.6B
命中率	9/18 (50%)	18/18 (100%)
平均相似度	-0.18	0.60
单次查询耗时	217ms	449ms

换上中文优化模型后，近义词、描述性查询全部命中。Ollama 本地跑 Qwen3-Embedding，不依赖任何外部 API。

OpenClaw（三省六部制 AI 系统）接入：

13 个 Agent 共享同一个 MemPalace 实例
索引了 854 个文件（195 closets + 659 drawers）
每天凌晨自动增量索引
Agent 们通过 mempalace search 检索历史上下文

优点

✅ 零配置起步：pip install + mempalace init + mempalace mine，三行命令跑起来
✅ 完全本地：数据存在你机器上，ChromaDB + SQLite，不需要网络，不需要 API Key
✅ 语义搜索：不是关键词匹配，是理解意思。说"定价讨论"能找到提到"价格策略"的内容
✅ 记忆分层：L0-L3 按需加载，不会撑爆 context window
✅ 多格式支持：项目文件、Claude Code 对话、ChatGPT 导出、Slack 记录都能吃
✅ 知识图谱：有时间线的关系数据库，知道事实"什么时候是真的”
✅ AAAK 压缩：30倍压缩比，任何 LLM 直接读懂
✅ MCP 协议：19个工具暴露给 AI，让 AI 自己管理记忆
✅ 增量索引：mine 命令幂等，只处理新文件，不重复索引
✅ 多实例隔离：支持多个 AI Agent 各用各的宫殿，互不干扰

缺点

⚠️ 嵌入模型依赖：默认用 all-MiniLM-L6-v2，中文效果很差（命中率仅50%）。中文场景必须换模型（如 Qwen3-Embedding），但换模型需要重建整个索引
⚠️ 首次索引慢：大项目首次 mine 比较耗时，尤其本地跑大嵌入模型时。我 854 条数据用 Qwen3-Embedding 跑了近 5 小时（纯 CPU）
⚠️ ChromaDB 限制：不支持多进程并发写入。多 Agent 共享一个宫殿需要做实例隔离，否则会锁冲突
⚠️ 没有内置嵌入模型管理：换模型要自己写脚本重建，没有官方的 migrate 工具（虽然有 mempalace migrate 但只处理 ChromaDB 版本升级）
⚠️ AAAK 压缩是有损的：官方文档明确说不是无损压缩，原文无法从 AAAK 输出还原。压缩前确保原始 Drawer 保留
⚠️ 文档偏少：README 够用，但深入使用（嵌入模型切换、多实例隔离、MCP 高级配置）基本靠读源码
⚠️ 单机方案：没有分布式/同步机制，不适合团队协作场景

适合谁？

个人 AI 助手用户：希望 AI 记住你的偏好、项目历史、重要决策
AI Agent 开发者：给你的 Agent 加一个持久化的长期记忆层
重度 AI 对话用户：积累了大量 ChatGPT/Claude 对话，想建立可检索的档案库
隐私敏感用户：不想把记忆数据上传到任何云端服务

不适合谁？

需要团队协作共享记忆的团队（考虑 Zep/Mem0）
只用 AI 做简单问答，不需要上下文延续
没有本地服务器或不愿意折腾 CLI

技术栈

语言：Python
向量数据库：ChromaDB（本地嵌入式）
知识图谱：SQLite
嵌入模型：可插拔（默认 all-MiniLM-L6-v2，支持 Ollama、OpenAI 兼容 API）
协议：MCP（Model Context Protocol）
协议：MIT 开源

MemPalace v3.3.3 | 作者: milla-jovovich | GitHub: github.com/MemPalace/mempalace