Automation on Kalend's Blog

给Agent装个自动记忆：让AI自己记住你说过的话

Fri, 15 May 2026 20:30:00 +0800

你跟AI说"我习惯用vim，不要用nano"，下次对话它照样给你nano。每次都要重复说，烦不烦？

先说结论

核心思路就三行：

1

session结束 → 调免费LLM提取记忆 → 向量去重后存入ChromaDB

整篇文章读完，你的Agent就能在每次对话结束时自动把用户偏好、事件、工作流提取出来，下次对话自动加载。成本：¥0。

架构

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


┌──────────┐ session end ┌──────────────┐
│ 对话记录 │ ──────────────→ │ 已有记忆注入P2 │
└──────────┘ └──────┬───────┘
 │
 ┌──────▼───────┐
 │ 免费LLM提取P0 │
 │ 分类+结构化 │
 └──────┬───────┘
 │
 ┌──────▼───────┐
 │ 向量去重 P1 │
 │ cosine<0.15 │
 └──────┬───────┘
 │
 ┌──────▼───────┐
 │ ChromaDB │
 │ 本地存储 │
 └──────────────┘

三层防护确保不存垃圾、不存重复：

层级	机制	作用
P2 提取前	已有记忆注入prompt	模型直接跳过已知内容
P0 提取中	免费LLM分类提取	persona/episodic/instruction
P1 存入时	ChromaDB向量去重	兜底防重复存储

前置条件

ChromaDB：本地向量数据库，pip install chromadb
免费LLM API Key：在智谱开放平台注册账号，自动获得API Key。GLM-4-Flash模型永久免费，无需绑定支付方式
Python 3.9+

Step 1: 提取Prompt模板

这个prompt是整个系统的灵魂。把它加到你的MemoryProvider插件里：

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


EXTRACTION_SYSTEM_PROMPT = (
 '你是一个记忆提取助手。从对话中提取值得长期记住的信息。\n'
 '严格按以下JSON格式输出，不要输出其他任何内容：\n'
 '{"persona":["字符串1","字符串2"],"episodic":["字符串1"],"instruction":["字符串1"]}\n\n'
 '分类规则：\n'
 '- persona: 用户偏好、习惯、身份、性格特征、沟通风格\n'
 '- episodic: 具体事件和行动\n'
 '- instruction: 工作流程、规则、纠正、技术方案\n\n'
 '关键规则：\n'
 '1. 只提取新的、具体的、有价值的信息\n'
 '2. 数组中每个元素必须是纯字符串，不要用对象\n'
 '3. 没有有价值的信息就全部输出空数组\n'
 '4. 每条不超过80字，用简洁陈述句\n'
 '5. 不要重复同一条信息\n'
 '6. 偏好类信息归persona，不要归episodic'
)

为什么这么设计：

temperature: 0.1 + 严格格式约束 → 输出稳定可解析
三分类覆盖了90%以上的记忆类型
“没有有价值的信息就输出空数组” → 避免硬造记忆

Step 2: on_session_end钩子

Session结束时触发提取。关键设计：后台线程异步执行，不阻塞用户。

 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


import threading
import json

def on_session_end(self, messages):
 # 过滤出user/assistant消息
 conversation_lines = []
 for msg in messages:
 role = msg.get('role', '')
 content = msg.get('content', '')
 if role in ('user', 'assistant') and content:
 prefix = '用户' if role == 'user' else '助手'
 conversation_lines.append(f'{prefix}：{content[:500]}')

 if len(conversation_lines) < 2:
 return # 太短不提取

 conversation_text = '\n'.join(conversation_lines)
 if len(conversation_text) > 4000:
 conversation_text = conversation_text[-4000:] # 截取最近4000字符

 # 预取已有记忆（P2缓存）
 existing_context = self._build_existing_context()

 # 后台线程执行提取
 def _extract():
 self._run_extraction(conversation_text, existing_context)

 threading.Thread(target=_extract, daemon=True).start()

注意几个细节：

每条消息截取500字符 → 控制总量
总文本超过4000字符只取末尾 → 最近的内容最有价值
对话少于2条直接跳过 → 避免无效提取
daemon=True → 主进程退出时不会卡住

Step 3: API调用实现

直接用标准库，不依赖额外包：

 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


def _run_extraction(self, conversation_text, existing_context=''):
 import urllib.request, urllib.error

 system_prompt = self.EXTRACTION_SYSTEM_PROMPT
 if existing_context:
 system_prompt += f'\n\n已知记忆（不要重复提取这些内容）：\n{existing_context}'

 payload = json.dumps({
 'model': 'glm-4-flash', # 免费模型
 'messages': [
 {'role': 'system', 'content': system_prompt},
 {'role': 'user', 'content': conversation_text},
 ],
 'max_tokens': 800,
 'temperature': 0.1,
 }, ensure_ascii=False).encode('utf-8')

 req = urllib.request.Request(
 'https://open.bigmodel.cn/api/paas/v4/chat/completions',
 data=payload, method='POST'
 )
 req.add_header('Authorization', f'Bearer {self._extract_api_key}')
 req.add_header('Content-Type', 'application/json')

 try:
 with urllib.request.urlopen(req, timeout=30) as resp:
 result = json.loads(resp.read().decode('utf-8'))
 except (urllib.error.URLError, json.JSONDecodeError, KeyError) as e:
 return # 静默失败，不影响主流程

 content = result['choices'][0]['message']['content']
 extracted = self._parse_extraction_json(content)
 self._store_extracted_memories(extracted)

JSON解析加个容错：

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


import re

def _parse_extraction_json(self, content):
 """容错解析，处理LLM输出前后可能的多余文本"""
 try:
 return json.loads(content)
 except json.JSONDecodeError:
 # 尝试提取花括号内容
 match = re.search(r'\{[^{}]*\}', content, re.DOTALL)
 if match:
 try:
 return json.loads(match.group())
 except json.JSONDecodeError:
 pass
 return {'persona': [], 'episodic': [], 'instruction': []}

Step 4: 向量去重（P1）

这是防重复的最后防线。即使LLM没看到已有记忆，向量相似度也能拦住：

 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


_DEDUP_MAX_DISTANCE = 0.15 # ~92%相似度

def _is_duplicate(self, text, wing):
 results = self._col.query(
 query_texts=[text],
 n_results=3,
 where={'wing': wing},
 include=['distances'],
 )
 distances = results.get('distances', [[]])[0]
 return distances and distances[0] < self._DEDUP_MAX_DISTANCE

def _store_extracted_memories(self, extracted):
 import time
 stored = 0
 for category, items in extracted.items():
 wing_map = {
 'persona': 'user',
 'episodic': 'episodic',
 'instruction': 'instruction'
 }
 wing = wing_map.get(category, 'user')
 for item in items:
 if not item or len(item.strip()) < 5:
 continue # 跳过太短的
 if self._is_duplicate(item, wing):
 continue # 跳过重复
 self._col.add(
 documents=[item],
 metadatas=[{
 'wing': wing,
 'room': 'auto-extract',
 'added_by': 'auto-extract',
 'category': category,
 'timestamp': str(int(time.time())),
 }],
 ids=[f'extract_{category}_{int(time.time()*1000)}_{stored}']
 )
 stored += 1

为什么阈值是0.15：

实测数据——

距离阈值	相似度	去重效果	误杀率
0.10	~95%	去重80%	极低
0.15	~92%	去重90%+	<3%
0.20	~88%	去重95%	~8%

0.15是甜点。

Step 5: 已知记忆注入（P2）

在调LLM之前，把已有记忆塞进prompt。这样模型直接跳过已知内容，省token又防重复：

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


def _build_existing_context(self):
 parts = []
 for wing in ('user', 'instruction'):
 results = self._col.get(
 where={'wing': wing},
 include=['documents', 'metadatas'],
 limit=20
 )
 for doc, meta in zip(results['documents'], results['metadatas']):
 if meta.get('added_by') in ('auto-extract', 'hermes', 'builtin-mirror'):
 parts.append(doc[:100])
 return '；'.join(parts[:15])[:500] if parts else ''

只取最近15条、截断到500字符。控制prompt长度，别把提取请求搞得太贵。

Step 6: 配置和测试

在 mempalace.json 中启用自动提取：

1
2
3
4


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

验证方法

测试1：基本提取

跟Agent说几句话：

1
2
3


用户：我习惯用vim编辑器，不要给我推荐nano
用户：我的项目统一用Python 3.11
用户：代码风格遵循PEP8，docstring用Google风格

结束session，然后检查ChromaDB：

1
2
3
4
5
6


import chromadb
client = chromadb.PersistentClient(path='./mempalace_db')
col = client.get_collection('memories')
results = col.get(where={'added_by': 'auto-extract'}, include=['documents', 'metadatas'])
for doc, meta in zip(results['documents'], results['metadatas']):
 print(f"[{meta['category']}] {doc}")

预期输出类似：

1
2
3


[persona] 用户习惯使用vim编辑器
[instruction] 项目统一使用Python 3.11
[instruction] 代码风格遵循PEP8，docstring用Google风格

测试2：去重验证

同一段对话连续触发两次提取，第二次应该0条新增。

测试3：新session加载

开启新对话，问Agent：“你知道我用什么编辑器吗？"——它应该能从记忆中回答"vim”。

实测效果数据

指标	数据
提取延迟	3-7秒（后台异步，不阻塞）
Token消耗	300-500/次
成本	¥0（GLM-4-Flash免费）
分类准确率	>90%（persona/episodic/instruction）
去重拦截率	90%+（重复对话）
误存率	<2%（无效信息被存入）

三层防护机制总结

再说一遍这个设计，因为它是整个系统可靠性的关键：

1
2
3


P2 提取前：已知记忆注入 → LLM直接跳过 → 省token
P0 提取中：结构化分类 → 只保留有价值信息 → 控质量
P1 存入时：向量相似度去重 → 兜底拦截 → 防重复

三层不是冗余，是互补：

P2漏了（记忆太多超过500字符截断了）→ P1兜底
P1漏了（措辞差异太大向量没拦住）→ P2已经拦了大部分
P0是核心 → 决定提取质量

一句话总结

自动记忆不是奢侈品，是Agent的基础设施。当AI能记住你说过的每一句偏好，你就不需要每次对话都从头开始。

从零搭建 Blog Writer Agent：让 AI 自己写文章、自己部署

Fri, 15 May 2026 17:30:00 +0800

这是「多 Agent 协作」系列第 2 篇。第 1 篇讲了概念：Kanban + Profile：让你的 AI Agent 自己管博客。这篇是纯实操——每一步都是我刚跑过的真实命令。

先说结论

搭一个会自己写博客的 AI Agent，7 步，2.5 分钟。不是 demo，是真的能写文章、构建验证、部署上线的 Agent。

1
2


你：hermes kanban create "写一篇 Kanban 入门" --assignee blog-writer
AI：自动写文章 → 构建验证 → 完成汇报

整个过程你只需要发一条命令。

前置条件

已安装 Hermes Agent（v0.13.0+）
有一个 Hugo/Hexo 等静态博客项目
Gateway 正在运行

第 1 步：启用 Kanban Toolset

Kanban 是隐藏 toolset——hermes tools list 里看不到它。需要手动在 config.yaml 里添加：

1
2
3
4


# ~/.hermes/config.yaml
toolsets:
- hermes-cli
- kanban  # ← 加这一行

同时在 config.yaml 底部确认 dispatcher 配置（通常已有）：

1
2
3
4


kanban:
 dispatch_in_gateway: true
 dispatch_interval_seconds: 60
 failure_limit: 2

改完重启 gateway：

1

systemctl restart hermes-gateway.service

第 2 步：创建 blog-writer Profile

Profile 就是一个独立的 AI 身份——有自己的配置、人格、工作目录。

1

hermes profile create blog-writer --clone

输出：

1
2
3


Profile 'blog-writer' created at ~/.hermes/profiles/blog-writer
Cloned config, .env, SOUL.md, and skills from default.
Wrapper created: ~/.local/bin/blog-writer

--clone 会复制当前 profile 的 API 密钥、配置、记忆文件，省得重新配置。

第 3 步：写 SOUL.md（定义人格）

SOUL.md 决定了这个 Agent 的行为模式。给 blog-writer 写一个专门的人格：

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


cat > ~/.hermes/profiles/blog-writer/SOUL.md << 'EOF'
# Blog Writer Agent

你是博客写作和部署专家。

## 职责
1. 撰写技术博客文章（Markdown + Hugo front matter）
2. 构建验证（hugo --minify）
3. 部署到云存储

## 严格规则
- 日期必须是 RFC3339 格式：2026-05-15T10:00:00+08:00
- categories 和 tags 都要包含主题关键词
- description 必须填写
- **永远不要用 read_file → write_file 修改 Markdown**
- 构建后必须检查页面数
EOF

第 4 步：配置工作目录

让 blog-writer 的默认工作目录指向博客项目：

1
2
3
4
5
6
7


# 编辑 blog-writer 的 config.yaml
# 在 terminal 段添加：
terminal:
 cwd: /root/blog
toolsets:
- hermes-cli
- kanban

这样 worker 被调度时，会自动 cd 到博客目录。

第 5 步：初始化 Kanban 看板

1

hermes kanban init

输出：

1
2
3
4
5
6


Kanban DB initialized at ~/.hermes/kanban.db

Discovered 3 profile(s) on disk:
 blog-writer
 default
 yuan

看板是一张 SQLite 表，所有 profile 共享。验证一下：

1
2


hermes kanban stats # 0 tasks (空看板)
hermes kanban assignees # blog-writer (idle)

第 6 步：创建第一个写作任务

1
2
3
4
5
6


hermes kanban create \
 --assignee blog-writer \
 --skill hugo-blog \
 --workspace 'dir:/root/blog' \
 --body '写一篇 Kanban 入门文章。要求：RFC3339日期、categories含hermes、构建验证' \
 '测试任务：写一篇 Kanban 入门文章'

输出：

1

Created t_9dd47956 (ready, assignee=blog-writer)

关键参数解释：

参数	作用
`--assignee blog-writer`	指定谁来做
`--skill hugo-blog`	给 worker 注入博客相关知识
`--workspace dir:/root/blog`	工作目录（不是临时 scratch）
`--body '...'`	任务的详细要求

第 7 步：等 2 分钟，验收

Dispatcher 每 60 秒轮询一次 ready 任务。大约 70 秒后：

1
2


hermes kanban stats
# blog-writer running=1 ← 正在执行

再等 82 秒：

1
2
3
4


hermes kanban show t_9dd47956
# status: done
# summary: 完成测试文章「Hermes Kanban 快速入门」，186页构建通过
# Run #1: completed @blog-writer 82s

文章已经写好了。 看看产出：

1
2
3
4
5
6
7
8


---
title: "Hermes Kanban 快速入门"
date: 2026-05-15T17:00:00+08:00
categories: ["hermes"]
tags: ["hermes", "kanban", "agent"]
---
## 什么是 Kanban？
Hermes Kanban 是内置的任务调度系统...

front matter 格式正确，日期 RFC3339，构建验证通过。全流程从创建到完成 2 分 22 秒。

背后发生了什么

整个调度流程：

1
2
3
4
5
6
7
8
9


你发命令 → kanban create（SQLite 写入一条 ready 任务）
 ↓ 60s
Gateway dispatcher 轮询 → 发现 ready 任务 → claim
 ↓
spawn 子进程：hermes -p blog-writer --skills kanban-worker --skills hugo-blog chat -q "work kanban task t_9dd47956"
 ↓ 82s
blog-writer 读任务 → 写文章 → hugo 构建 → kanban_complete
 ↓
任务状态 → done，你收到通知

几个关键设计：

Dispatcher 嵌在 Gateway 里，不需要给 blog-writer 单独跑 gateway
Worker 是独立子进程，hermes -p blog-writer 启动，完成后自行退出
--skills 自动注入，每个 worker 都会加载 kanban-worker skill（行为规范）
Claim TTL = 15 分钟，超时自动 reclaim，不会永远卡住

我踩过的 4 个坑

坑 1：hermes 不在 PATH 中

Dispatcher spawn worker 时执行 hermes -p blog-writer ...，如果 hermes 不在 PATH 里，直接失败。

1
2
3
4
5


# 检查
which hermes # 如果为空，需要手动链接

# 修复
ln -sf ~/.hermes/hermes-agent/venv/bin/hermes /usr/local/bin/hermes

坑 2：blog-writer 不需要独立 gateway

一开始我以为每个 profile 都得跑自己的 gateway。错了。Dispatcher 运行在主 gateway 里，通过 hermes -p blog-writer spawn 子进程。子进程不需要消息平台，不需要 gateway。

如果你给 blog-writer 启动了 gateway，会和主 gateway 冲突（weixin token 被占）。

坑 3：kanban toolset 是隐藏的

hermes tools list 不显示 kanban。它是条件注册的——只有 config.yaml 的 toolsets 列表里有 kanban 才会激活。很多教程会遗漏这一步。

坑 4：workspace 默认是 scratch

如果不指定 --workspace，默认用 scratch（临时目录，任务完成后会被清理）。博客项目要用 dir:/root/blog，否则写完文章就被删了。

时间线回顾

时刻	事件
17:07:00	`kanban create` → 任务 ready
17:07:10	Dispatcher claim + spawn worker
17:08:32	Worker 完成，kanban_complete
总耗时	1 分 32 秒（从创建到完成）

下一步

这是系列第 2 篇。接下来的内容：

第 3 篇：多任务编排——让多个 Agent 同时写多篇文章，Pipeline + Fan-out 实战
第 4 篇：踩坑全记录——格式陷阱、模型选择、成本控制、调试技巧

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

自动记忆提取 (Auto Memory Extraction)

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

自动记忆提取

定义

AI Agent 在会话结束时自动从对话中提取值得长期记住的信息，分类存入向量数据库，实现跨会话的持久记忆。

核心架构

1
2
3
4
5


对话结束 → on_session_end() → 后台线程
 ├─ P2: 预取已有记忆 → 注入prompt（减少重复提取）
 ├─ P0: 调用LLM提取 → JSON输出(persona/episodic/instruction)
 ├─ P1: 向量去重 → ChromaDB相似度检查
 └─ 存入MemPalace drawers

三类记忆分类

类型	说明	存储wing	示例
persona	用户偏好、习惯、身份	user	喜欢暗色模式
episodic	具体事件和行动	episodic	完成博客主题迁移
instruction	工作流程、规则、方案	instruction	部署前先hugo –minify测试

实施要点

提取模型选择

推荐：GLM-4-Flash — 免费、3-7秒延迟、中文理解好
不推荐GLM-4.7-Flash — 推理模型，28秒延迟
不推荐本地模型 — RAM占用高、15-25秒延迟

去重阈值

ChromaDB cosine distance < 0.15（约92%相似度）
范围：同wing内比较
效果：同对话重复提取90%+被拦截

Prompt Cache（P2）

提取前预取user和instruction wing的已有记忆
注入prompt的"已知记忆"区
上限15条、500字符，避免bloat

配置

1
2
3
4
5
6
7


// mempalace.json
{
 "auto_extract": true,
 "extract_model": "glm-4-flash",
 "extract_base_url": "https://open.bigmodel.cn/api/paas/v4",
 "extract_api_key": "" // 留空则自动从环境变量GLM_API_KEY加载
}

性能指标（实测）

指标	值
提取延迟	3-7秒（后台异步）
Token消耗	300-500/次
成本	¥0（免费模型）
分类准确率	>90%
去重有效率	>90%
预估月成本	<¥0.5（10次/天）

适用场景

有ChromaDB/MemPalace等向量存储的Agent系统
支持MemoryProvider插件架构（on_session_end钩子）
有免费LLM API可用（智谱GLM-4-Flash、Google Gemini Flash等）

扩展方向

记忆分层（未实施）：温/冷/归档，按访问频率衰减。当前20条记忆无需分层，预估到1000+条再评估
知识图谱集成：提取的记忆同步写入KG，支持关系查询
跨Agent共享：多Agent共用同一MemPalace实例

Automation on Kalend's Blog

给Agent装个自动记忆：让AI自己记住你说过的话

先说结论

架构

前置条件

Step 1: 提取Prompt模板

Step 2: on_session_end钩子

Step 3: API调用实现

Step 4: 向量去重（P1）

Step 5: 已知记忆注入（P2）

Step 6: 配置和测试

验证方法

实测效果数据

三层防护机制总结

一句话总结

从零搭建 Blog Writer Agent：让 AI 自己写文章、自己部署

先说结论

前置条件

第 1 步：启用 Kanban Toolset

第 2 步：创建 blog-writer Profile

第 3 步：写 SOUL.md（定义人格）

第 4 步：配置工作目录

第 5 步：初始化 Kanban 看板

第 6 步：创建第一个写作任务

第 7 步：等 2 分钟，验收

背后发生了什么

我踩过的 4 个坑

坑 1：hermes 不在 PATH 中

坑 2：blog-writer 不需要独立 gateway

坑 3：kanban toolset 是隐藏的

坑 4：workspace 默认是 scratch

时间线回顾

下一步

自动记忆提取 (Auto Memory Extraction)

自动记忆提取

定义

核心架构

三类记忆分类

实施要点

提取模型选择

去重阈值

Prompt Cache（P2）

配置

性能指标（实测）

适用场景

扩展方向

相关概念