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分钟
日常维护	零（定时任务自动跑）

AI文章有股味：11特征自查

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

你的AI文章有股AI味：这11个中文特征，你至少中了3个

用AI写文章的人越来越多，但大部分AI产出的文字有个致命问题——一眼就能看出是AI写的。问题不在内容，而在"味"。

先说结论

有个开源项目整理了40个AI写作特征，其中11个是中文独有的。

大部分人至少中3个，严重的全中。

这些特征不是"错"，而是AI的统计本性导致的。

知道后改起来不难。下面逐个拆解，每个都给Before和After对照。

为什么AI写的东西有"味"

AI本质上是个统计鹦鹉。

它不"理解"内容，只是根据概率预测下一个词。所以它总是选最"安全"、最"常见"的搭配。

结果就是——用AI写100篇企业文化宣传稿，长得都差不多。

中文AI味的11个特征

1. 互联网黑话堆砌

一段话里塞5-6个互联网黑话，读起来像PPT。

高频词： 赋能、抓手、闭环、沉淀、链路、矩阵、生态、打法、组合拳、底层逻辑

Before：

我们需要找到核心抓手，打通全链路闭环，通过私域裂变赋能品牌心智沉淀，构建护城河壁垒。

After：

我们需要想清楚核心策略是什么，把获客到复购的流程跑通，让用户记住品牌。

自检： 你的文章里，一段话出现3个以上黑话的段落，就是重灾区。

2. 形容词膨胀

把普通的事说得像改变世界。

高频词： 划时代、颠覆性、卓越、典范、标杆、翘楚、令人瞩目

Before：

这是一款具有划时代意义的颠覆性产品，在行业中树立了全新标杆，堪称卓越典范。

After：

这款产品有几个明显区别于竞品的功能。发布两周注册用户超过10万。

自检： 数一数你文章里"颠覆"“卓越"“标杆"出现几次。超过2次就该删。

3. 宏大叙事框架

把任何小事都放在时代大潮里讲。

高频句式： “在…的背景下”、“随着…的不断发展”、“在…的浪潮中”

Before：

在数字化转型的大背景下，随着人工智能技术的不断发展，企业面临着前所未有的机遇与挑战。

After：

企业现在用AI的地方越来越多。但也带来了新问题。

自检： 看你的开头。如果前两行出现了"背景下"“大趋势"“浪潮”，删掉重来。

4. 意义升华

不允许任何事实只是事实，一定要赋予它意义。

高频句式： “具有重要的现实意义”、“发人深省”、“值得深入思考”

Before：

这一发现具有重要的现实意义和深远的理论价值，为我们理解这一现象提供了全新视角，值得深入思考。

After：

这一发现解释了之前观测到但无法确认的现象。研究团队已公开数据和代码。

自检： 搜"意义"“价值"“值得”。如果它们不是在讨论具体的价格或数值，就删掉。

5. 模板化过渡

用套话硬把上下文连起来，实际上逻辑是断的。

高频句式： “值得注意的是”、“综上所述”、“毋庸置疑”、“更值得一提的是”

Before：

值得注意的是，该技术在医疗领域取得了显著成效。更值得一提的是，其应用范围还在不断扩大。综上所述，前景广阔。

After：

这项技术目前用在医疗领域最多。其他领域的应用也在增长。

自检： 搜那几个高频句式。找到了，删掉，看句子还通不通。通常更通。

6. 客套收尾

文章结尾突然变成客服。

高频句式： “希望对你有所帮助”、“感谢您的阅读”、“欢迎随时交流”

Before：

以上就是关于机器学习的全部介绍。希望本文对您有所帮助。感谢您的耐心阅读！

After：

（直接删掉。文章在最后一个实质观点处结束。）

自检： 如果你的结尾是"希望…“开头，删。读者不需要祝福。

7. 四六句对仗

像政府工作报告或演讲稿。

高频句式： “只有…才能…；只有…才能…”

Before：

只有不断创新，才能不断进步；只有不断学习，才能不断成长；只有不断突破，才能不断超越。

After：

持续改进依赖创新和学习，但也需要务实——先验证想法再扩大投入。

自检： 朗读一遍。如果哪段读起来像领导讲话，改。

8. 假辩证

什么话题都要列正反两面，篇幅还几乎对等。

高频句式： “一方面…另一方面…"、“需要找到平衡”

Before：

人工智能带来了巨大便利，提高了效率。但与此同时，也引发了伦理问题。一方面AI可以辅助诊断，另一方面数据隐私不容忽视。需要在发展与监管之间找到平衡。

After：

AI在医疗领域增长很快，但数据隐私的监管还没跟上。欧盟的AI法案尝试解决这个问题，效果有待观察。

自检： 搜"一方面"“平衡”。如果你两面都写了但没给出自己的判断，这就是假辩证。

9. 四字成语滥用

密度太高，而且总用最常见的那几个。

高频成语： 日新月异、突飞猛进、方兴未艾、如虎添翼、乘风破浪、潜移默化

Before：

随着科技的日新月异，各行各业突飞猛进，新兴产业如雨后春笋般涌现，可谓方兴未艾。

After：

新技术催生了一些新行业，也改变了老行业的做法。变化最快的是金融和零售。

自检： 数成语数量。一段话里超过2个四字成语，就多了。

10. 万能结尾

空洞的未来展望。

高频句式： “未来可期”、“前景广阔”、“拭目以待”

Before：

展望未来，随着技术不断进步，前景广阔，未来可期。让我们拭目以待，共同迎接更美好的明天。

After：

明年计划在三个新城市上线。

自检： 如果你的结尾是"未来可期"“拭目以待”，替换成具体事实或直接删掉。

11. 数字枚举强迫

什么内容都要往固定数字框架里塞。

高频句式： “三大趋势”、“五大特征”、“四大要素”

Before：

当前行业呈现三大发展趋势：一是智能化加速推进，二是绿色化蔚然成风，三是全球化持续深化。这五大特征构成了四大核心要素。

After：

行业最近的变化：智能化程度提高，环保要求加严，海外市场竞争加剧。

自检： 数一数文章里有几个"三大"“五大"“四大”。超过3个就是病。

快速自查清单

特征	高频词/句式	一句话判断标准
黑话堆砌	赋能/抓手/闭环/链路	一段话3个以上黑话
形容词膨胀	颠覆性/卓越/标杆	“颠覆"“标杆"超过2次
宏大叙事	“在…背景下”/“浪潮”	开头两行出现就删
意义升华	“重要意义”/“值得思考”	搜"意义”，非数值就删
模板过渡	“值得注意的是”/“综上所述”	删掉后更通顺就删
客套收尾	“希望对你有帮助”	出现就删
四六对仗	“只有…才能…”	朗读像领导讲话就改
假辩证	“一方面…另一方面”	没给判断就是假辩证
成语滥用	日新月异/方兴未艾	一段超2个四字成语
万能结尾	未来可期/拭目以待	替换成具体事实
数字强迫	三大/五大/四大	超过3个就多

怎么改？三个实操技巧

技巧一：朗读。

哪段读着像领导讲话，就改哪段。

写完文章出声读一遍，比任何工具都管用。AI味的段落读起来特别"顺”，顺到不自然。

技巧二：成语换大白话。

看到四字成语，问自己：能不能用日常用语说同样的事？

“日新月异”→“变化很快”。“赋能”→“帮助”。“闭环”→“跑通流程”。

每个替换都让文章更接地气。

技巧三：删"意义"句。

搜索"意义"“价值"“前景"“未来可期”。

这些词后面的句子，90%可以整句删掉。剩下的10%，用具体数据替换。

以上特征整理自开源项目 humanizer（MIT协议），该项目基于维基百科"AI写作特征"条目，总结了40个中英文AI写作特征。

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

多Agent协作实战：从写稿到审核的完整Pipeline

Tue, 19 May 2026 07:00:00 +0800

一篇AI对比文章，4个Agent接力完成，10步Pipeline自动跑通。中间经历3轮审核修复循环，全程1.5小时零人工介入。

先说结论

我们搭了一套多Agent协作的写作Pipeline。

4个专职Agent：写作、审核、博客部署、公众号发布，各司其职。

10步自动流水线：从第一行字写出来，到博客上线、公众号草稿就绪，全自动。

质量门禁：审核不通过，下游任务直接卡住，修好了才放行。

这是系列第3篇。第1篇讲了Kanban+Profile架构，第2篇搭了单个Writer Agent。

这篇是多Agent协作的完整实战——怎么让4个Agent接力干活、互相检查、自动修复。

1. 4个Agent怎么分工

先看全局。每个Agent有自己的Profile（身份配置）和SOUL.md（行为规范）。

Agent	职责	模型	特点
blog-writer	写原始文章	glm-5.1	204K上下文，有记忆
reviewer	审核内容质量	glm-5.1	只审不改，无记忆
blog-creator	转Markdown+部署	glm-4.7	最精简工具集
mp-creator	转公众号HTML+上传	glm-4.7	4个微信skill

类比：像一个编辑部——

◆ Writer是记者，负责采访写稿
◆ Reviewer是编辑，负责审稿把关
◆ Creator是排版员，负责报纸和网站两个渠道的排版

注意模型选择：写作和审核用强模型(glm-5.1)，格式转换用弱模型(glm-4.7)。

为什么？格式转换是机械活，不需要创造力。省下来的Token是真金白银。

2. Pipeline全景：10步流水线

 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


 ① blog-writer ② reviewer Fan-out
 ┌──────────────┐ ┌──────────────┐ ┌─────────────────┐
 │ 写原始文章 │──────▶│ 内容审核 │──PASS│ 并行分发 │
 │ (glm-5.1) │ 7min │ PII/事实/AI味 │12min └──────┬──────────┘
 └──────────────┘ └──────────────┘ │
 ┌───────────┴───────────┐
 ▼ ▼
 ③ blog-creator ④ mp-creator
 ┌──────────────┐ ┌──────────────┐
 │ Markdown+部署 │ │ HTML+封面+上传│
 │ (glm-4.7) │ │ (glm-4.7) │
 └──────┬───────┘ └──────┬───────┘
 │ │
 ▼ ▼
 ⑤ reviewer ⑥ reviewer
 ┌──────────────┐ ┌──────────────┐
 │ Blog格式审核 │ │ 公众号格式审核 │
 └──────┬───────┘ └──────┬───────┘
 PASS ✅ FAIL ❌
 │ │
 ▼ ▼
 博客上线 ┌──────────────────┐
 │ ⟳ 审核修复循环×3轮 │
 │ ⑦修复→⑧审核→⑨修复 │
 │ →⑩审核 PASS ✅ │
 └──────────────────┘

解释一下关键节点：

◆ Step ①②：Writer写完文章，交给Reviewer审核内容
◆ Fan-out：审核通过后，同时派给Blog和公众号两个渠道
◆ Step ③④：两个Creator并行工作，互不等待
◆ Step ⑤⑥：各自的Reviewer再审一遍格式
◆ Step ⑦-⑩：公众号没过，进入修复循环

Blog那边一次通过，公众号那边经历了3轮修复。为什么？

因为公众号对段落长度有严格限制（每段≤100字），模型对"手机屏幕3行"的物理感知不够精确。

3. 依赖链：怎么让Agent自动接力

核心机制是Kanban的parents依赖。

创建任务时指定parents，意思是：“等这些父任务完成后，我才启动”。

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


# 创建Writer任务
kanban_create(title="写对比文章", assignee="blog-writer")

# 创建Reviewer任务，依赖Writer
kanban_create(title="审核内容", assignee="reviewer",
 parents=["t_writer_xxx"])

# 创建两个Creator任务，依赖Reviewer
kanban_create(title="部署博客", assignee="blog-creator",
 parents=["t_reviewer_xxx"])
kanban_create(title="公众号推文", assignee="mp-creator",
 parents=["t_reviewer_xxx"])

注意看最后两行——它们的parents是同一个Reviewer任务。

这意味着Reviewer通过后，Blog和公众号同时启动。

这就是Fan-out（扇出）：一个任务完成，触发多个下游并行执行。

4. 质量门禁：FAIL就卡住

Reviewer不是走过场。它有5级审核维度，每级有明确的通过标准：

优先级	检查项	判定标准
🔴 必须通过	PII信息脱敏	手机号/邮箱/IP必须处理
🔴 必须通过	事实准确性	数据有来源，技术描述正确
🟡 3处FAIL	AI味检测	废话铺垫/过度道歉/套话
🟢 仅建议	品牌名	不强制，给出建议
🔵 格式规范	平台适配	Blog/公众号各有专项检查

关键机制：Reviewer判定FAIL时，在kanban_complete的metadata里写入问题列表。

下游任务的parents依赖没满足，不会自动启动。

必须创建修复任务，修好后再提交审核。这就是"门禁"——

不是标记一下就过了，是真的挡住，修好才放行。

5. 实战：3轮修复循环

说说真实发生的事。

第一轮公众号HTML生成后，Reviewer发现11个段落超标（限制100字/段）。

其中3个段落超过150字，在手机上会显示成一大坨。

mp-creator收到问题列表，拆分段落。

Reviewer二轮审核——还有5段超标。继续修。

第三轮审核——91个段落全部≤100字，PASS。

整个过程零人工介入。Reviewer自动FAIL，mp-creator自动读问题列表修复。

从第一次FAIL到最终PASS，修复循环自动跑了3轮。

教训：模型对"手机屏幕3行=100字"这种物理约束，理解不够精确。需要多轮迭代。

6. 模型分级：省钱的关键

4个Agent不是都用最贵的模型。按职责复杂度分级：

职责	模型	为什么
原创写作	glm-5.1（强）	需要创造力和上下文
内容审核	glm-5.1（强）	找错需要精确理解
格式转换	glm-4.7（省）	机械任务，够用即可
辅助工具	glm-4.5-air（最省）	压缩/搜索等轻量任务

实际效果：写作和审核两个最关键的环节用强模型保证质量。

格式转换这种"体力活"用弱模型，成本直接砍半。

而且reviewer在下游兜底，弱模型出了问题也能被拦截。

7. 搭建要点回顾

如果你也想搭这样的Pipeline，关键步骤：

◆ Step 1：为每个角色创建独立Profile
◆ Step 2：写SOUL.md定义行为规范
◆ Step 3：配置review skill的审核checklist
◆ Step 4：用kanban的parents参数搭建依赖链
◆ Step 5：按职责复杂度分配模型

最关键的设计决策是质量门禁。

没有它，Agent就是各干各的，错误会一路传到最终发布。

有了它，每个环节都有人把关，问题在传播之前就被拦截。

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

多Agent协作系列第3篇 · 第4篇将分享踩坑最佳实践

Andrej Karpathy

Mon, 01 Jan 0001 00:00:00 +0000

Andrej Karpathy

概述

AI 研究者，曾任 Tesla AI 总监、OpenAI 联合创始成员。提出 LLM Wiki 概念——让 AI 增量构建持久化知识库的文件结构规范。

来源

raw/articles/rwayne-hermes-obsidian-llm-wiki-2026.md

Hermes Agent

Mon, 01 Jan 0001 00:00:00 +0000

Hermes Agent

概述

Hermes Agent 是 [[nous-research]] 开发的开源自主 AI 代理框架。支持多平台（CLI、Telegram、Discord、微信等）、多模型提供商，核心特点是内置技能学习循环和五层记忆架构。

核心架构

配置文件层级

层级	文件	用途	安全级别
核心	config.yaml	主配置：模型、工具、网关、MCP	🟡
核心	.env	API密钥与机密	🔴
核心	SOUL.md	Agent性格，每轮加载无需重启	🟢
数据	state.db	会话状态	🟡
数据	sessions/	会话记录	🟢 可删
数据	memories/	MEMORY.md + USER.md 热记忆	🟡
数据	memory.db	记忆后端（可删，数据在.md）	🟢
数据	kanban.db	看板任务数据	🟡
扩展	skills/	技能系统（更新不覆盖）	🟢
扩展	scripts/	脚本	🟢
扩展	hooks/	事件钩子	🟢

Profile 隔离系统

每个 profile 位于 profiles/<name>/，是独立的 Hermes home：

拥有独立的 config.yaml、SOUL.md、sessions、memories、skills、auth、cron、kanban
关键限制：全局 skills/ 对 profile worker 不可见，需手动复制到 profiles/<name>/skills/
适用场景：多角色隔离（如 blog-writer、reviewer 等独立 profile）

Skill 系统

按分类组织在 skills/，每个技能包含 SKILL.md 与可选的 refs/templates/scripts。技能从经验中积累可复用程序化知识，跨会话持久化，且不会被 Hermes 更新覆盖。

记忆系统

五层记忆架构（详见 [[memory-layered-architecture]]）：

L0: Persona (SOUL.md) — 每轮注入
L1: 热记忆 (MEMORY.md + USER.md) — 每轮注入
L2: [[mempalace]] 语义检索 — 按需
L3: 知识图谱 — 按需
L4: 会话历史 — 按需

多平台网关

支持 CLI、Telegram、Discord、微信（WeChat）、WhatsApp、Slack 等。网关状态保存在 gateway_state.json 和各平台子目录中。

版本

当前 v0.14.0。更新命令：hermes update。

IMA OpenAPI

Mon, 01 Jan 0001 00:00:00 +0000

IMA OpenAPI

概述

腾讯 IMA（ima.qq.com）的 OpenAPI 接口，提供云端笔记管理和知识库操作能力。与 [[mempalace]] 的本地记忆互补，负责云端文档管理。

功能模块

Notes 笔记管理

搜索笔记、浏览笔记本、获取笔记内容
创建笔记（import_doc）、追加内容（append_doc）
写入前强制 UTF-8 编码校验（否则乱码不可修复）

Knowledge-base 知识库

上传文件到知识库、添加网页链接
搜索知识库内容、浏览知识库条目
获取可添加的知识库列表

认证

Client ID + API Key，HTTP POST + JSON Body 发送到 ima.qq.com。

注意事项

文件上传到知识库时保持原样不转码
PowerShell 5.1 环境需特殊处理（GBK 编码问题）

在记忆系统中的位置

作为 [[memory-layered-architecture]] 中的外部知识源，处理需要跨设备/持久化的大文件和文档管理。与 Hermes 的集成优先级低于 [[mempalace]] 的深度集成。

MemPalace

Mon, 01 Jan 0001 00:00:00 +0000

MemPalace

概述

本地优先的 AI 记忆操作系统。逐字存储对话历史，不摘要不压缩，支持语义检索和知识图谱。与 [[hermes-agent]] 集成后形成五层记忆架构。

项目信息

项目	详情
GitHub	https://github.com/MemPalace/mempalace
Stars	47,687
版本	v3.3.3
许可证	MIT
安装	`pip install mempalace`

核心能力

宫殿结构：Wing(人/项目) → Room(日期/话题) → Drawer(逐字原文块)
混合搜索：BM25 关键词 + ChromaDB 向量语义
知识图谱：SQLite 三元组存储实体关系
MCP Server：29 个 MCP 工具，支持 mempalace_store/recall/knowledge 等
多实例隔离：不同系统使用独立 palace 实例

基准成绩

LongMemEval R@5 = 98.4%（无需 LLM）

嵌入模型

从 all-MiniLM-L6-v2（英文为主，中文命中率 50%）迁移到 Qwen3-Embedding-0.6B（中英双语，中文命中率 100%），通过 [[ollama]] 本地部署。

实际部署

实例	路径	数据量	使用者
Hermes 主	~/.mempalace/palace/	40 drawers	Hermes MCP Server
OpenClaw	~/.mempalace/palace-openclaw/	659 drawers	OpenClaw 定时挖掘
Yuan	~/.mempalace/palace-yuan/	预留	Yuan profile

与 Hermes 集成

路径A（已实施）：MCP 工具方式 — config.yaml 配置 mempalace MCP Server
路径B（待实施）：MemoryProvider 插件 — 实现自动 prefetch/sync_turn 深度集成

Nous Research

Mon, 01 Jan 0001 00:00:00 +0000

Nous Research

概述

Nous Research 是 Hermes Agent 的开发团队，专注于开源 AI 代理框架。

代表项目

Hermes Agent — 自主 AI 代理框架，支持多平台、多模型、技能系统

来源

raw/articles/rwayne-hermes-obsidian-llm-wiki-2026.md

OpenClaw

Mon, 01 Jan 0001 00:00:00 +0000

OpenClaw

概述

OpenClaw（小龙虾🦞）是 [[hermes-agent]] 的直接竞品，定位为全平台个人 AI 助手。

项目信息

项目	详情
GitHub Stars	37.2万
语言	TypeScript
许可证	MIT
创建时间	2025-11
赞助商	OpenAI、GitHub、NVIDIA、Vercel

核心特性

20+ 渠道支持（含微信/QQ）
Voice Wake（语音唤醒）
Live Canvas（实时画布）
原生 App（桌面+移动）
ClawHub：5400+ 社区 skills

与 Hermes 的设计哲学差异

维度	OpenClaw	Hermes Agent
定位	全平台个人助手	终端 Agent 框架 + 多 Agent 编排
语言	TypeScript	Python
记忆系统	内置	五层架构 + [[mempalace]]
扩展	ClawHub 社区	Skill 系统 + Kanban Pipeline
编排	单 Agent	多 Agent（orchestrator + worker）

共存部署

在同一台机器上同时运行 Hermes 和 OpenClaw。OpenClaw 使用独立的 [[mempalace]] 实例（/root/.mempalace/palace-openclaw/），避免 ChromaDB 并发写冲突。

Understand Anything

Mon, 01 Jan 0001 00:00:00 +0000

Understand Anything

25.8K 星代码理解工具，把整个项目变成交互式知识图谱。Tree-sitter + LLM 混合架构，7-agent pipeline。

概述

Understand Anything（Lum1104/Understand-Anything）是一个基于 Tree-sitter + LLM 的代码理解工具，能将整个代码库转化为交互式知识图谱。通过 7-agent 流水线实现代码分析、关系提取和可视化展示。支持 15+ 主流开发平台。

核心数据

指标	数值
GitHub Stars	25.8K
Forks	2.2K
Commits	539
许可证	MIT
主语言	TypeScript
最后更新	2026-05-24

技术架构

Tree-sitter: 语法解析层，提取代码结构（AST）
LLM: 语义理解层，分析代码关系和意图
7-Agent Pipeline: 多代理协作完成分析任务
交互式知识图谱: 可视化展示模块间关系

支持平台

Claude Code、Cursor、VS Code + Copilot、[[opencode]]、Codex、Gemini CLI 等 15+ 平台。

安装与使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 通用安装
curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash

# 针对 OpenCode 平台
curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s opencode

# 使用
/understand # 分析代码库
/understand-dashboard # 打开可视化面板
/understand --language zh # 中文模式

与 [[opencode]] 的关系

Understand Anything 原生支持 [[opencode]] 作为宿主平台。在 OpenCode 中安装后，可通过 /understand 命令直接调用，将当前项目的代码结构转为知识图谱，辅助理解和导航。

与 [[hermes-agent]] 的关系

作为代码理解工具，Understand Anything 的知识图谱输出可以作为 [[hermes-agent]] 编排编码任务时的上下文输入，帮助 Agent 更好地理解项目结构。

来源

2026-05-25 cron 会话：微信公众号文章研究与撰写（“25K星的代码理解神器：把整个项目变成知识图谱”）

五层记忆架构

Mon, 01 Jan 0001 00:00:00 +0000

五层记忆架构

概述

[[hermes-agent]] 的记忆系统由五层组成，从每轮注入到按需检索，形成完整的长短期记忆链路。设计原则：热记忆 = 指路牌（只放每次都需要的），MemPalace = 百科全书（按需检索）。

五层结构

层级	名称	存储	容量	加载方式
L0	Persona	SOUL.md	~3000字符	每轮注入
L1	热记忆	MEMORY.md + USER.md	~2200字符上限	每轮注入（启动时冻结）
L2	语义检索	[[mempalace]] ChromaDB	无硬限	按需 mempalace_recall
L3	知识图谱	[[mempalace]] SQLite 三元组	无硬限	按需 mempalace_knowledge
L4	会话历史	session_search (FTS5)	全量	按需搜索

回忆优先级

1

热记忆(L0+L1) → MemPalace语义搜索(L2) → session_search(L4) → 结构化文件

溢出机制

当热记忆超过 ~70% 容量时，非核心信息下沉到 [[mempalace]]：

网络拓扑、环境配置 → 下沉
项目细节、技术记录 → 下沉
核心偏好、高频踩坑 → 保留
行为规则、授权声明 → 保留

三工具协同

工具	定位	集成层级
[[hermes-agent]] 内置	记忆编排中枢	L0 + L1
[[mempalace]]	本地长期语义记忆	L2 + L3
[[ima-openapi]]	云端知识库	外部知识源

嵌入模型

使用 Qwen3-Embedding-0.6B（4096维，通过 [[ollama]] 部署），中文命中率从 50% 提升到 100%。

知识库自动化工作流

Mon, 01 Jan 0001 00:00:00 +0000

知识库自动化工作流

核心链路

1

文档导入 → AI 整理 → Wiki 生成 → 双向链接 → 无限循环

步骤

下达指令：告诉 Hermes「把这篇文章写入知识库」
Hermes 自动整理：提取实体/概念/关系，创建结构化 Markdown
文件结构生成：按 LLM Wiki 规范创建带 frontmatter 的页面
Obsidian 展示：打开知识库目录，双向链接浏览 + Graph View
循环积累：每次导入新文档，已有页面自动更新，矛盾标注，关联增强

关键规则

「写入知识库」「导入知识库」→ 触发写入操作
「结合知识库」「查一下知识库」→ 触发检索
日常普通对话不触发知识库操作

优势

全程不需要手动操作图形界面
知识持续积累而非每次从零开始
矛盾自动标注，来源可追溯

来源

raw/articles/rwayne-hermes-obsidian-llm-wiki-2026.md

AI on Kalend's Blog

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

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

传统 RAG 的致命问题

三层架构

实操：5 分钟搭骨架

三个核心操作

Obsidian 兼容

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

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

三个自动钩子

方式 B：MCP Server（备选）

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

踩坑清单

总结

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

为什么你需要一个知识库

第一步：装 MemPalace（5分钟）

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

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

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

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

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

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

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

踩坑清单（必看）

成本核算

AI文章有股味：11特征自查

你的AI文章有股AI味：这11个中文特征，你至少中了3个

先说结论

为什么AI写的东西有"味"

中文AI味的11个特征

1. 互联网黑话堆砌

2. 形容词膨胀

3. 宏大叙事框架

4. 意义升华

5. 模板化过渡

6. 客套收尾

7. 四六句对仗

8. 假辩证

9. 四字成语滥用

10. 万能结尾

11. 数字枚举强迫

快速自查清单

怎么改？三个实操技巧

多Agent协作实战：从写稿到审核的完整Pipeline

1. 4个Agent怎么分工

2. Pipeline全景：10步流水线

3. 依赖链：怎么让Agent自动接力

4. 质量门禁：FAIL就卡住

5. 实战：3轮修复循环

6. 模型分级：省钱的关键

7. 搭建要点回顾

Andrej Karpathy

Andrej Karpathy

概述

相关实体

来源

Hermes Agent

Hermes Agent

概述

核心架构

配置文件层级

Profile 隔离系统

Skill 系统

记忆系统

多平台网关

版本

相关

IMA OpenAPI

IMA OpenAPI

概述

功能模块

Notes 笔记管理

Knowledge-base 知识库

认证

注意事项

在记忆系统中的位置

相关

MemPalace