Hermes on Kalend's Blog

Hermes Agent v0.15：速度翻倍，从单兵到军团

Fri, 29 May 2026 18:30:00 +0800

先说结论

Hermes Agent v0.15.0（5月28日）是迄今最大的单版本更新。 1,302个提交、747个合并PR、1,746个文件变更、321位社区贡献者。隔天（5月29日）发布的 v0.15.1 修复了影响所有 Dashboard 用户的 P0 bug。

这个版本的三个关键词：快、拆、稳。

速度：从各个维度变快

冷启动再砍1秒

v0.15.0 延续了冷启动性能优化的浪潮，三轮优化叠加：

openai._base_client 导入延迟加载：-240ms / -17MB 内存
热路径函数调用削减 47%（399k → 213k，31轮对话）
压缩可行性检查延迟：-170 到 -290ms
自适应子进程轮询：-195ms/工具调用

实际效果：Termux 冷启动从 2.9s → 0.8s。 hermes --version 冷启动 701ms → 258ms（降63%），首次超越 Codex CLI。

session_search 快了4500倍

旧版 session_search 是辅助 LLM 驱动的工具，每次搜索花 90 秒、花费 $0.30，偶尔还会编造结果。新版完全重写：

零 LLM 调用，纯 FTS5 搜索引擎
三种模式（发现/滚动/浏览），自动推断无需切换
搜索延迟：~20ms（旧版 ~90s）
滚动延迟：~1ms

搜索历史对话现在免费且即时。

拆：核心代码大瘦身

run_agent.py 从16,000行拆成3,800行

这是整个版本最激进的重构。 run_agent.py 从 16,083 行缩减到 3,821 行（-76%），拆分到 14 个内聚的 agent/* 模块。

关键保证：行为零变化。每个拆分都在 AIAgent 上保留薄转发器，所有测试补丁路径不受影响，外部调用者完全兼容。

为什么你应该关注？以前这个文件在你的编辑器里要 90 秒才能打开，现在眨眼即开。未来开发迭代速度会显著加快。

稳：Kanban长成真正的多Agent平台

v0.15.0 用 104个PR 把 Kanban 从任务队列升级为多 Agent 协作平台。

新能力一览

能力	说明
自动分解	Triage 自动将一个任务分解为子任务树
Swarm 拓扑	`hermes kanban swarm` 一键创建完整 Swarm v1 图
每任务模型覆盖	便宜模型做杂活，贵模型啃硬骨头
工作树隔离	每个任务独立 git worktree，互不干扰
定时启动	任务支持指定开始时间
陈旧任务检测	自动发现并回收卡住的任务
Worker 可视化	`/workers/active`、`/runs/{id}`、`/inspect` 端点

Swarm 是什么

一条命令创建一个完整的多 Agent 工作流：

1

hermes kanban swarm

自动生成：根节点 → 并行 Worker → 门控验证者 → 门控综合者 → 共享黑板。适合代码审查、批量研究、多文件重构等场景。

安全：三道防线对抗提示注入

受 Brainworm/Promptware Kill Chain 研究（arxiv 2601.09625）启发，v0.15.0 在三个关键位置部署了防御：

威胁模式库（tools/threat_patterns.py）：~15个新的 Brainworm/C2 模式
记忆加载扫描：召回的记忆在注入上下文前先过安全检查
工具结果分隔符：恶意文件或远程服务无法伪装成 Hermes 自身的系统内容

配合新增的 security-guidance 插件，对危险代码写入进行模式匹配。

其他值得关注的更新

Bitwarden Secrets Manager 集成

一个引导令牌（BWS_ACCESS_TOKEN）替代所有明文 API Key。在 Bitwarden Web 端轮换密钥，重启即生效。

ntfy：第23个消息平台

无需注册、无需 API Key，只要一个 topic URL。Agent 完成任务、cron 到点，推送通知直达手机/桌面/智能家居。

Skill Bundle：一条命令加载多个 Skill

设置你的"写作日"组合（humanizer + ideation + obsidian + youtube-content）。 /writing-day 一次性激活全部。

TUI 会话管理器

Ink TUI 新增多会话切换器：在同一个终端窗口里列出、切换、刷新、关闭多个会话，不用退出。

Docker s6-overlay 容器管理

容器内网关自动监督、重启对账、docker logs 集成。Node 升级到 22 LTS。

v0.15.1 热修复（5月29日）

v0.15.0 发布隔天，一个 P0 bug 浮出水面：Dashboard 在 loopback 模式下无限重载。

根因

Dashboard 的身份探针（/api/auth/me）在 loopback 模式下返回 401（设计如此）。但 v0.15.0 的过期令牌重载守卫把每个 401 都当成了需要刷新的会话令牌，触发整页重载。重载后其他请求清除了单次重载守卫，于是又触发下一轮。 Firefox 表现为 “Navigated to /sessions” 暴风，Chrome 表现为 React 重渲染风暴。

修复

fetchJSON 新增 allowUnauthorized 选项，跳过 loopback 下的过期令牌重载逻辑。 401 仍然抛异常让 AuthWidget 处理，但不再触发整页刷新。

其他修复

Docker --insecure 改为显式环境变量（HERMES_DASHBOARD_INSECURE=1），不再从绑定主机推断
MCP bare 命令（npx/npm/node）在 Docker 容器内正确解析到 /usr/local/bin
Kanban Worker 的 SIGTERM 终于能正常终止进程
Skills 页面源标签和分类侧边栏恢复
/yolo 中途启用变为 per-session 级别
/model 和 hermes model 显示统一列表
.md 文件媒体投递恢复
Web URL 不再被误删查询参数
Skills Hub 全目录：858 → 19,932，所有 skills.sh 条目可搜索

升级建议

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 源码安装
cd /opt/hermes-agent
git pull
pip install -e .

# 或 Docker
docker pull nousresearch/hermes-agent:latest

# 检查版本
hermes --version

直接跳到 v0.15.1，不要停在 v0.15.0。 Dashboard 无限重载 bug 只影响 v0.15.0。

数据总结

指标	v0.15.0	v0.15.1
提交数	1,302	28
合并PR	747	21
文件变更	1,746	-
贡献者	321	9
P0 修复	15	1
P1 修复	65	-
安全修复	19	-

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

Hermes Agent 升级指南：v0.14.0 → v0.15.1，为什么要隔天发补丁

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

2026年5月，Hermes Agent 两周内连发三版：v0.14.0 → v0.15.0 → v0.15.1。第三版是隔天紧急修复——Dashboard 无限重载，新装用户直接无法使用。

先说结论

所有用户直接升级到 v0.15.1。 不用停在 v0.15.0，它的 Dashboard 有 P0 级缺陷。

一张表看全貌：

版本	日期	代号	一句话定位
v0.14.0	5.16	Foundation	全平台基础版本
v0.15.0	5.28	Velocity	1302 commits 大重构
v0.15.1	5.29	Hotfix	隔天紧急修复

v0.14.0 → v0.15.0：大版本跳跃

这不是小更新。v0.15.0 是 Hermes 历史上最大的单版本变更——747 个 PR、1302 个 commit、321 位贡献者。

核心代码大瘦身

run_agent.py 从 16,000 行重构到 3,800 行，缩减 76%。不是删功能，是把职责拆分到独立模块。

性能实测数据：

指标	变化
每轮工具调用	-195ms
每轮函数调用	-240ms（-47%）

session_search 重写：4500x 提速

会话搜索引擎从 LLM 驱动改为纯 FTS5 实现。搜索速度快了 4500 倍，而且不再消耗 token。

Kanban 演进为多 Agent 平台

Kanban 模块经过 104 个 PR 打磨，从任务看板变成了多 Agent 协作平台。支持任务分解、子 Agent 分发、跨 Agent 依赖管理。

安全防护：Promptware Defense

新增 promptware 防御机制，防止恶意提示词注入攻击 Agent 系统提示。

新集成

Bitwarden Secrets Manager：密钥管理集成
Krea 2 + FAL 插件：两个新图像生成提供商
Nous 官方 MCP 目录：审核过的 MCP 服务目录
ntfy 平台：第 23 个消息平台
mTLS 支持：MCP 连接支持 TLS 客户端证书

Breaking Changes

变更	说明
`API_SERVER_KEY` 强制	API Server 现在强制要求 Key，无 Key 不再允许请求
`web_crawl` 移除	该工具及相关 provider 已被移除
context engine	新增外部上下文引擎接口，需配合新配置

v0.15.0 → v0.15.1：为什么隔天就发补丁

v0.15.0 发布后隔天社区报告了多个阻断性问题。

🔴 Dashboard 无限重载循环（P0）

这是 v0.15.1 存在的唯一理由。

在 loopback 模式下（Docker 部署 / 托管环境 / 全新安装），Dashboard 的 SPA 在 token 过期后陷入死循环：401 → 重新登录 → 又 401 → 无限刷新。用户看到页面不停闪烁，完全无法使用。

修复方式：/api/auth/me 返回 401 时不再触发整页重载，改为 SPA 内部处理 token 刷新。

🔴 Kanban Worker SIGTERM 不终止

发送 SIGTERM 后进程没有正确终止，任务超时或手动取消时僵尸进程堆积。

🟡 其他修复

问题	影响
`/model` 和模型选择器列表不统一	CLI 和 gateway 显示不同模型列表
`/yolo` 模式未绕过 session	yolo 模式实际没生效
Skills 目录不完整	858 → 19,932，只拉取了部分条目
`.md` 媒体投递被误拦截	Gateway 把正常 Markdown 附件也拦了
Web URL 被误脱敏	URL 参数被错误替换

Docker 安全加固

--insecure 标志必须通过环境变量显式启用
MCP bare command（npx/npm/node）明确解析到 /usr/local/bin
arm64 CI 缓存问题修复

升级指南

从 v0.14.0 升级（推荐）

直接跳到 v0.15.1，不需要中间停 v0.15.0：

1
2
3
4
5
6
7


# 源码安装（推荐）
git clone https://github.com/NousResearch/hermes-agent
cd hermes-agent
pip install -e .

# 或 PyPI
pip install --upgrade hermes-agent

从 v0.15.0 升级到 v0.15.1（必须）

v0.15.0 的 Dashboard 无限重载是影响所有新装和 Docker 用户的 P0 问题：

1

pip install --upgrade hermes-agent

升级后检查清单

检查项	说明
Gateway 重启	升级后必须 `hermes gateway restart`
`API_SERVER_KEY`	v0.15.0+ 强制要求，检查 `~/.hermes/.env`
Browser Use 配置	需配置 `BEARER_TOKEN` 匹配 `API_SERVER_KEY`
Kanban 备份	并发加固后更稳定，但建议备份 `~/.hermes/kanban.db`
Docker `--insecure`	必须显式设置环境变量

版本号背后的逻辑

v0.15.1 不是计划内版本。大版本（v0.15.0）涉及 1300+ commits 变更，回归测试不可能覆盖所有部署环境。Dashboard 无限重载只在 loopback/Docker 场景触发，CI 没覆盖到。

发现问题后团队在隔天内发布修复——这是健康开源项目的标准响应速度。

建议所有用户直接使用 v0.15.1。

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

更多 AI Agent 实战经验和踩坑记录，持续更新中

我给AI建了个全自动知识库：每周自动从对话中提炼知识点

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

和AI聊了几百轮，发现最有价值的知识全散落在聊天记录里。下次遇到类似问题，还得重新问一遍。

这不是工具推荐，是我自己搭的一套系统。用了一年，从零长到23个知识页面，全是AI自己从对话里提炼出来的。

先说结论：把AI当知识管理员，比当聊天机器人有用得多。

一、为什么要自动化知识库

我每天和AI助手聊天，聊技术、聊工具、聊踩坑经验。

这些对话里藏着大量可复用的知识点：某个工具的配置方法、某个问题的解决方案、某个概念的清晰解释。

但问题是——它们全在聊天记录里。

想找的时候翻不到，找到了也不确定是最新的。

更关键的是，下次遇到类似问题，我又得重新描述一遍背景，重新问一遍。

所以我想要一个系统：自动扫描对话，自动提炼知识点，自动写入知识库。

不是什么Notion模板，不是Obsidian手动整理。

是真正的全自动——我正常聊天，知识库自动生长。

二、方案：LLM Wiki 规范 + 定时扫描

我的方案基于Karpathy提出的LLM Wiki规范。

核心思路：用Markdown文件存知识，用双向链接把知识点串成图谱，用AI定时扫描对话来增量更新。

整个知识库就是一个文件夹，长这样：

1
2
3
4
5
6
7
8
9


wiki/
 entities/ # 实体页（工具、人物、项目）
 concepts/ # 概念页（方法论、架构、工作流）
 comparisons/ # 对比页（方案选型）
 queries/ # 查询页（常见问题）
 raw/ # 原始素材（对话摘要）
 SCHEMA.md # 规范定义
 index.md # 全局索引
 log.md # 操作日志

每个页面都有统一的frontmatter格式：

1
2
3
4
5
6
7
8
9


---
title: 页面标题
created: 2026-05-14
updated: 2026-05-25
type: entity | concept | comparison | query
tags: [ai, tools, open-source]
sources: [raw/articles/xxx.md]
confidence: high | medium | low
---

用[[wikilinks]]语法在页面间建立双向链接。

比如opencode页面引用了understand-anything，后者又引用了hermes-agent。

这些链接自动形成知识图谱，不用手动维护。

三、扫描脚本：从对话中挖知识点

核心是一个Python脚本，每周自动扫描最近7天的AI对话记录。

它的逻辑很简单：

第一步：扫描会话数据库，找到最近有实质内容的对话。

筛选标准：消息数≥5条，标题非空，时间在7天内。

第二步：用关键词匹配分类。我定义了8个类别：

1
2


AI/模型 | 工具/Agent | 数据库 | OSINT
DevOps | 编程 | 写作 | 记忆/知识库

每条匹配规则是多个关键词用管道符连接。

比如"ai|llm|模型|训练|推理"都归到AI类。

第三步：过滤掉已有页面覆盖的内容，输出候选清单。

第四步：LLM Agent拿到候选清单，判断是否值得入库。

不是什么都记。有两个硬性门槛：

同一个知识点出现2次以上，或者来自1个高质量核心来源。

这样避免了把闲聊当知识的问题。

四、自动化流程：定时任务配置

我把扫描脚本配成了定时任务，每周日上午11点自动运行。

流程是四步：

扫描脚本输出候选 → LLM判断是否值得入库 → 创建或更新wiki页面 → 追加操作日志

目前已经跑了5轮自动入库，产生了这些内容：

实体页13个：hermes-agent、mempalace、opencode、obsidian、karpathy等。

概念页5个：双向链接、知识库工作流、五层记忆架构、MySQL大表DDL方案、被动验证方法论。

最有价值的是交叉引用。

opencode → understand-anything → hermes-agent → openclaw

这条引用链，把四个工具的定位和关系串了起来。

下次我需要对比它们，直接看知识库就行。

五、设计思考：为什么不用Notion

很多人会问：为什么不直接用Notion？或者Obsidian的插件？

三个原因：

第一，数据主权。我的知识库是本地Markdown文件，git管理。

不依赖任何云服务，不会因为某天服务下线就丢数据。

第二，增量构建。不是一次性搭好架子然后手动填充。

是每周自动从对话中生长，越用越丰富。

我正常使用AI，知识库自动变厚。

第三，AI做苦力。扫描、分类、提取、格式化，全部自动化。

我只做最终决策——这个东西值不值得记。

当然也有代价：没有Notion那么漂亮的界面，没有协作功能。

但知识库的本质是"能找到"，不是"好看"。

六、一个真实页面长什么样

拿hermes-agent这个实体页举例：

开头是frontmatter，包含标题、日期、类型、标签、来源、置信度。

然后是正文：概述、核心架构（配置层级表格）、Profile隔离系统、Skill系统、五层记忆架构、多平台网关。

最后是相关页面链接：nous-research、llm-wiki、obsidian、mempalace。

每个链接都能跳转，形成知识网络。

整个页面从创建到现在更新了3次，每次都是自动扫描触发的。

不是手动维护的"死"文档，而是跟着我的使用持续进化的"活"知识。

回看log.md的操作记录，5次自动入库覆盖了完全不同的领域：

从MySQL大表DDL方案到OSINT被动验证方法论。

这正是自动化的价值——它不会只记你"觉得重要"的东西。

而是记录你"实际在用"的东西。

如果你也在大量使用AI工具，强烈建议搭一个自己的知识库。

不需要复杂，一个文件夹 + 一个扫描脚本就够了。

关键不是工具选型，而是让知识自动沉淀。

手动整理的知识库，最后都会变成没人维护的死文档。

只有自动化的，才能活下来。

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

下一篇讲怎么给这个知识库加上语义搜索，让它从"能找到"变成"能联想"

我给AI知识库加了"联想大脑"：从关键词搜索到语义理解

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

我的 wiki 里有 27 个页面，涵盖 Hermes、Obsidian、MySQL 等十几个主题。

搜"AI怎么记住之前的对话"——0 结果。

明明写了，为什么搜不到？

因为那篇 wiki 叫"五层记忆架构"，标题里没有"对话"“记住"这些词。

再来一个。搜"有没有能自动理解项目的工具”。

还是 0。wiki 里写的是"Understand Anything"，英文名。

第三个。搜"知识库怎么同步"。

0。wiki 里用的是"knowledge-base-workflow"。

三次搜索，三次翻车。不是 wiki 没写，是我用的词跟标题对不上。

现有 wiki-scan.py 用正则匹配：ai|llm|模型 这类关键词去打标签。

这种方案有个硬伤：同义词、近义词、描述性语句一律匹配不到。

关键词搜索只认字面，不懂意思。你脑子里想的跟标题不一样，就搜不到。

这是关键词搜索的天花板：它能找字，但不能找意思。

Embedding：给每段话算一个"语义坐标"

Embedding 模型的能力就一件事：把文本变成一组数字（向量）。

意思相近的文本，向量距离就近。意思无关的，距离远。

不需要懂线性代数。想象每段话都有自己的"语义指纹"。指纹越像，内容越相关。

专业说法叫"余弦相似度"——两个向量的夹角越小，内容越像。

但你不关心数学，只关心结果：输入一个问题，返回最相关的几段文字。

“AI怎么记住之前的对话"和"五层记忆架构"这两个短语，字面完全不同。

但语义指纹很接近——都在说"AI的记忆机制”。

这就是 Embedding 解决的核心问题：跨越字面，匹配语义。

“有没有能自动理解项目的工具"和"Understand Anything"也一样。

一个中文描述，一个英文专有名词，但语义空间里它们是邻居。

我用的本地模型是 qwen3-embedding，4.7GB，跑在 Ollama 上。

不调云 API，数据不出本机。对于个人知识库来说完全够用。

技术选型还有 nomic-embed-text 和 bge-m3，后面踩坑段会说差异。

动手：三步给 Wiki 接上向量引擎

向量数据库选 ChromaDB，轻量，Python 几行搞定。

版本是 1.5.8，pip install chromadb 直接装。

第一步：扫描 wiki 文件 + 分段切片

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


import glob

def load_wiki_chunks(wiki_dir, chunk_size=500):
 """扫描 wiki 目录，按固定字数切片"""
 chunks = []
 for f in glob.glob(f"{wiki_dir}/**/*.md", recursive=True):
 text = open(f, encoding="utf-8").read()
 # 按 chunk_size 字符切，保留来源信息
 for i in range(0, len(text), chunk_size):
 chunks.append({
 "text": text[i:i+chunk_size],
 "source": f,
 })
 return chunks

27 个 md 文件，500 字符切片，大约生成 80 个 chunk。

每个 chunk 都带着 source 元数据，搜索命中后可以直接跳到原文。

第二步：Embedding 向量化 + 存入 ChromaDB

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


import chromadb
from chromadb.utils.embedding_functions import (
 OllamaEmbeddingFunction,
)

ef = OllamaEmbeddingFunction(
 model_name="qwen3-embedding",
 url="http://localhost:11434/api/embed",
)

client = chromadb.PersistentClient(path="./wiki_chroma")
col = client.get_or_create_collection(
 "wiki",
 embedding_function=ef,
)

chunks = load_wiki_chunks("/root/wiki")
col.add(
 documents=[c["text"] for c in chunks],
 metadatas=[{"source": c["source"]} for c in chunks],
 ids=[f"chunk_{i}" for i in range(len(chunks))],
)

PersistentClient 把索引存到本地目录，重启不丢数据。

每个 chunk 附带 metadata 记录来源文件，方便溯源。

整个入库过程在我的机器上跑完不到 30 秒。

第三步：语义查询

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


results = col.query(
 query_texts=["AI怎么记住之前的对话"],
 n_results=3,
)
for doc, meta in zip(
 results["documents"][0],
 results["metadatas"][0],
):
 print(meta["source"], "→", doc[:80])
# 命中 memory-layered-architecture.md ✅

三步搞定。从安装到跑通，不超过 10 分钟。

效果对比：搜同一个问题

三组实测，关键词搜索 vs 语义搜索：

查询	关键词结果	语义搜索结果
“怎么防止模型记不住东西”	0 条	命中 memory-layered-architecture
“大表加字段怎么办”	命中 gh-ost	同时命中 gh-ost + mysql-big-table-ddl
“类似 Notion 的本地工具”	命中 obsidian	额外关联 bidirectional-links

第一组最典型。关键词完全匹配不到，语义搜索直接命中。

因为"防止记不住"和"五层记忆架构"在语义空间里是近邻。

第二组说明语义搜索不会丢掉关键词能找到的内容。

gh-ost 关键词能找到，语义也能找到，还额外关联了同主题的另一个页面。

这是语义搜索的加分项：不只补齐关键词的盲区，还能发现你可能没想到的关联。

第三组体现了"联想"能力。

用户想找的不只是工具名称，还有工具背后的核心理念（双向链接）。

Obsidian 的核心卖点就是 bidirectional-links，语义搜索自动把这个关联挖了出来。

从"能找到"到"能联想”，这是质变，不是量变。

让索引自动更新

wiki 内容会增长，索引也得跟上。用 cronjob 定时增量更新：

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


existing = set(
 m["source"] for m in col.get()["metadatas"]
)
new_chunks = [
 c for c in load_wiki_chunks("/root/wiki")
 if c["source"] not in existing
]
if new_chunks:
 col.add(
 documents=[c["text"] for c in new_chunks],
 metadatas=[{"source": c["source"]} for c in new_chunks],
 ids=[
 f"chunk_{len(existing)+i}"
 for i in range(len(new_chunks))
 ],
 )
 print(f"新增 {len(new_chunks)} 个 chunk")

新页面入库时自动切片 + 向量化，零手动操作。

和 Hermes 的联动更进一层：搜索结果注入对话上下文。

Agent 回答问题时自动从 wiki 检索相关知识，不用每次手动查。

这个联动让知识库从"被动存档"变成"主动辅助"。

踩坑记录

三个坑，踩过了才知道。

模型选择：通用 embedding 模型对中文效果差。

nomic-embed-text 是好模型，但主要针对英文。中文查询经常跑偏。

搜"怎么防止模型记不住东西"，它返回的是跟"模型训练"相关的内容。

换成 qwen3-embedding 后，中文语义理解提升明显。

如果你的 wiki 主要是中文，选中文优化模型。这是效果差距最大的一个选择。

切片粒度：500 字符是经验值，不是万能解。

太粗（>1000）会丢细节。搜"五层记忆架构的第三层"可能匹配不到具体段落。

因为第三层的描述被淹没在一大段文字里，向量被平均掉了。

太细（<200）会丢上下文。返回的片段短到看不懂在说什么。

建议从 500 开始，根据实际搜索效果调整。

索引体积：27 个页面、80 个 chunk，ChromaDB 索引只有几 MB。

不需要百万级向量库的方案。个人知识库，ChromaDB 完全够用。

不要过度工程化，够用就好。

关键词搜索是"翻字典"——你得知道精确的词。

语义搜索是"问懂行的人"——描述个大概就能找到。

给知识库加上这层能力，从"能找到"到"能联想"，区别很大。

而这个升级，只需要一个 embedding 模型 + 一个向量数据库，本地就能跑。

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。

5款Hermes Agent Web UI对比：只有2个值得装

Sat, 23 May 2026 12:20:00 +0800

用了半年 Hermes Agent，一直靠终端敲命令。直到有一天我想在手机上查个对话记录——没办法，只能SSH上去翻日志。于是我开始找 Web UI。

先说结论

只想装一个？选 hermes-webui（8.3K Star）。

想要IDE级体验？hermes-workspace。其余三个，各有硬伤。

下面逐个拆解。

1. 官方内嵌 Dashboard

1

hermes dashboard

启动后打开 http://localhost:9119，FastAPI + Uvicorn 驱动。

能干什么：

查看和编辑配置文件（config.yaml）
管理环境变量（.env）
浏览会话列表

不能干什么：

不能聊天（没有对话界面）
不能管理Skills、Cron任务
不能在手机上用（只绑127.0.0.1）

官方 Dashboard 本质是个配置编辑器。

适合不需要Web聊天、只想改改配置的轻量用户。

评分： 安装 ★★★★★ | 功能 ★★☆☆☆ | 手机 ★☆☆☆☆ | 维护 ★★★★★

2. nesquena/hermes-webui — ⭐ 8.3K

Python + 原生JS，三栏布局。

安装：

1
2
3
4


git clone https://github.com/nesquena/hermes-webui.git
cd hermes-webui
pip install -r requirements.txt
python app.py

不需要npm构建，不需要Docker。装完直接跑。

核心功能：

完整对话界面（聊天、发图、文件上传）
会话管理（创建、切换、删除）
手机端自适应（三栏自动折叠）
直接读取Hermes本地数据（会话、记忆、配置）

为什么推荐它：

零构建步骤这一点就秒杀了大部分竞品。

三栏布局在桌面端是会话列表 | 对话区 | 详情面板，手机上自动折叠为单栏。

根据README描述，支持实时流式输出和Markdown渲染。

不足：

不支持Cron任务管理
不支持Kanban看板
没有多用户系统

评分： 安装 ★★★★★ | 功能 ★★★★☆ | 手机 ★★★★☆ | 维护 ★★★★☆

3. outsourc-e/hermes-workspace — ⭐ 4.7K

JavaScript，IDE风格多面板界面。

2026年黑客松获奖项目。

安装：

1
2
3
4


git clone https://github.com/outsourc-e/hermes-workspace.git
cd hermes-workspace
npm install
npm run dev

需要Node.js环境，有构建步骤。

核心功能：

IDE风格多面板（对话、终端、记忆、Skills、检查器）
内置终端模拟器
记忆和Skills的可视化管理
支持实时日志查看

适合谁：

重度开发者，喜欢IDE布局，需要同时看对话、终端和状态。

不足：

需要npm构建（对纯Python用户不友好）
手机端体验一般（面板太多，小屏挤不下）
Star数最少，社区相对小

评分： 安装 ★★★☆☆ | 功能 ★★★★★ | 手机 ★★☆☆☆ | 维护 ★★★☆☆

4. EKKOLearnAI/hermes-web-ui — ⭐ 5.8K

Vue3 + Koa，端口8648。

安装：

1
2
3
4
5


git clone https://github.com/EKKOLearnAI/hermes-web-ui.git
cd hermes-web-ui
# 需要分别构建前后端
npm install
npm run build

核心功能：

全功能管理界面（聊天、会话、配置）
支持8个平台渠道可视化（Telegram、Discord、Slack等）
定时任务（Cron）管理
用量分析面板

不足：

构建步骤最复杂（前后端分离）
Vue3技术栈对非前端开发者有门槛
从功能来看，平台渠道可视化是亮点也是局限——大部分个人用户用不到8个平台

评分： 安装 ★★☆☆☆ | 功能 ★★★★★ | 手机 ★★★☆☆ | 维护 ★★★★☆

5. Open WebUI — ⭐ 138K+

138K Star的通用LLM前端，不是专为Hermes设计的。

怎么接Hermes：

1
2
3
4
5
6
7
8


# 1. 启动Hermes API Server（端口8642）
hermes gateway --platform api_server

# 2. 启动Open WebUI
docker run -d -p 3000:8080 \
 -e OPENAI_API_BASE_URL=http://localhost:8642/v1 \
 -e OPENAI_API_KEY=dummy \
 ghcr.io/open-webui/open-webui:main

通过Hermes的API Server（端口8642）接入。

优势：

生态最大（138K Star，社区资源丰富）
支持RAG、文件上传、图像生成等高级功能
Docker一键部署
多用户系统、权限管理

为什么不是首选：

Open WebUI是通用LLM前端，不是Hermes原生客户端。

你无法管理Hermes特有的功能：Skills、Cron、记忆、Kanban、多Profile。

它只能「聊天」，不能「管理Hermes」。

适合需要多用户+RAG+文件分析的团队场景，不适合个人Hermes全功能管理。

评分： 安装 ★★★☆☆ | 功能 ★★★☆☆（Hermes维度） | 手机 ★★★★☆ | 维护 ★★★★★

对比总表

维度	官方Dashboard	hermes-webui	hermes-workspace	hermes-web-ui	Open WebUI
Star	内置	8.3K	4.7K	5.8K	138K
安装难度	零	极低	中	高	中
聊天功能	❌	✅	✅	✅	✅
会话管理	✅	✅	✅	✅	✅
Skills管理	❌	❌	✅	❌	❌
Cron管理	❌	❌	❌	✅	❌
记忆管理	❌	❌	✅	❌	❌
手机适配	❌	✅	一般	一般	✅
多平台渠道	❌	❌	❌	✅	❌
构建步骤	无	无	npm	npm	Docker
适合人群	改配置	日常使用	重度开发	运维管理	团队协作

选择建议

个人用户，想最快用上Web界面：

hermes-webui。三条命令装完，手机也能用。

开发者，需要IDE级管理：

hermes-workspace。终端、记忆、Skills全在一个界面。

运维需求，管多平台+Cron：

hermes-web-ui。唯一一个带Cron管理和渠道可视化的。

团队场景，多用户+RAG：

Open WebUI。但别指望它管理Hermes特有功能。

只是偶尔改改配置：

官方Dashboard就够了。hermes dashboard 一条命令。

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

装完就懵？一份文件告诉你 Hermes 的每个配置到底管什么

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

开篇导语

装好 Hermes Agent，~/.hermes/ 下一堆文件，config.yaml、.env、SOUL.md… 哪个改哪个不改，新手完全懵。

第一章：你的 ~/.hermes/ 长什么样

 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


~/.hermes/
├── 核心配置（3个文件）
│ ├── config.yaml # 主配置文件（300+ 行）
│ ├── .env # API 密钥和凭证（405 行，18+ 供应商）
│ └── SOUL.md # Agent 个性定义（每轮加载，改了立生效）
│
├── 数据存储
│ ├── sessions/ # 历史会话 JSON 文件
│ ├── memories/ # 记忆文件（MEMORY.md、USER.md）
│ ├── kanban/ # 看板任务和日志
│ ├── cron/ # 定时任务输出
│ ├── logs/ # 日志文件（agent.log、errors.log）
│ ├── state.db # SQLite 数据库（会话索引、状态）
│ └── checkpoints/ # 文件系统快照（/rollback 使用）
│
├── 扩展层
│ ├── skills/ # 技能目录（SKILL.md + 脚本/模板）
│ ├── scripts/ # 自定义脚本
│ ├── plugins/ # 插件目录（MCP 服务器、平台适配器）
│ └── hooks/ # 事件钩子脚本
│
├── Profile 隔离
│ └── profiles/ # 多配置并行目录
│ ├── blog-writer/ # 博客写作 profile
│ ├── reviewer/ # 审核 profile
│ └── yuan/ # 个人 AI profile
│
└── 其他
 ├── auth.json # 认证状态（OAuth token）
 ├── kanban.db # 看板 SQLite 数据库
 ├── memory.db # 记忆系统数据库
 └── .update_check # 版本检查缓存

每个 profile（如 blog-writer）是完整的并行 ~/.hermes/，包含独立的 config.yaml、.env、SOUL.md、state.db、sessions/、logs/ 等。

第二章：三大核心文件（新手必读）

文件	作用	怎么改
`config.yaml`	所有行为参数（模型、工具、终端、压缩、看板等）	编辑文本，改后立即生效（部分需重启 gateway）
`.env`	API 密钥和平台凭证	`export KEY=xxx` 或直接编辑，改后立即生效
`SOUL.md`	Agent 个性、称呼、反驳机制	编辑 Markdown，每轮对话重新加载，不需要重启

config.yaml 核心字段速查

 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


model:
 default: glm-5.1  # 默认模型
 provider: zai  # 默认供应商
 api_key: xxx  # API 密钥（也可用 .env）
 context_length: 204800 # 上下文长度（tokens）
 max_tokens: 131072 # 最大输出（tokens）

agent:
 max_turns: 90 # 最大对话轮数
 gateway_timeout: 1800 # Gateway 空闲超时（秒）
 reasoning_effort: medium  # 推理强度
 tool_use_enforcement: auto # 工具调用强制策略

terminal:
 backend: local  # 终端后端：local/docker/ssh/modal
 timeout: 180 # 命令超时（秒）

compression:
 enabled: true # 上下文压缩
 threshold: 0.5 # 触发阈值（50%）
 target_ratio: 0.2 # 压缩到阈值比例

toolsets:
 - hermes-cli  # 启用的工具集
 - kanban

.env 环境变量全表（按供应商分类）

供应商	必须环境变量	可选环境变量	备注
OpenRouter	`OPENROUTER_API_KEY`		路由到多模型
Anthropic	`ANTHROPIC_API_KEY` 或 `ANTHROPIC_TOKEN`		Claude 模型
OpenAI	`OPENAI_API_KEY`		GPT、o1 系列
Z.AI / GLM	`ZAI_API_KEY` 或 `GLM_API_KEY`		智谱 GLM 模型
Kimi	`KIMI_API_KEY` 或 `KIMI_CN_API_KEY`		月之暗面
MiniMax	`MINIMAX_API_KEY` 或 `MINIMAX_CN_API_KEY`		国产大模型
DeepSeek	`DEEPSEEK_API_KEY`		深度求索
Google / Gemini	`GOOGLE_API_KEY` 或 `GEMINI_API_KEY`		Gemini 系列
xAI	`XAI_API_KEY`		Grok 模型
Bedrock	`AWS_BEARER_TOKEN_BEDROCK`	`AWS_SECRET`	AWS 托管

平台凭证（消息平台）：

微信：WEIXIN_TOKEN、WEIXIN_ACCOUNT_ID
飞书：FEISHU_APP_ID、FEISHU_APP_SECRET
Telegram：TELEGRAM_BOT_TOKEN
Discord：DISCORD_BOT_TOKEN

SOUL.md 实战框架

SOUL.md 定义 Agent 行为，核心六要素：

要素	作用	示例
身份定位	谁是 Agent，谁是用户	“我是忞的自主执行者和思考伙伴”
核心职责	Agent 要做什么	“任务执行、思考伙伴、信息管理、风险预警”
个性特点	风格和语气	“专业、简洁、贴心、高效、可靠、直率”
执行原则	怎么干活	“先执行后汇报，主动提醒，结果导向”
反驳机制	何时反对用户	“必须反驳 + 必须带证据 + 替代方案”
沟通风格	怎么说话	“简洁、结构化、结果先行、主动、坦诚”

默认 SOUL vs 深度定制 SOUL 对比：

行为	默认 SOUL	深度定制 SOUL
称呼	“用户”	“忞”
语言	中英文混合	始终中文
反驳	不会反驳	强制反驳（带证据）
问责	不追问	主动追问输出是否采纳
风格	标准客服	专业伙伴

第三章：config.yaml 全字段速查

model — 模型配置

字段	默认值	常见调法	踩坑提示
`default`	""	`glm-5.1`、`openrouter/anthropic/claude-sonnet-4`	空字符串时走 auto-detect
`provider`	""	`zai`、`openrouter`、`anthropic`	`base_url` 指定时 provider 可选
`base_url`	""	OpenAI 兼容端点	必须以 `https://` 或 `http://` 开头
`api_key`	""	密钥（或用环境变量）	优先级：`config.yaml` > `.env`
`context_length`	（模型决定）	`128000`（Claude）、`200000`（GLM）	超出模型实际上限会报错
`max_tokens`	（模型决定）	`4096`（短响应）、`131072`（长输出）	截断时 `finish_reason='length'`

fallback_providers — 故障自动切换

1
2
3
4
5
6
7


fallback_providers:
 - provider: zai
 model: glm-4.7
 base_url: https://open.bigmodel.cn/api/coding/paas/v4
 api_key: ${GLM_API_KEY}
 context_length: 200000
 max_tokens: 65536

触发条件	行为
429（Rate Limit）	切换到 fallback_providers 下一个
503（服务不可用）	切换到下一个
连接失败	切换到下一个

踩坑提示：fallback 不支持轮询（round-robin），只会从上到下尝试一次。需要配置多个 fallback 条目以实现多级切换。

auxiliary — 辅助模型（视觉 / 压缩 / 搜索 / 抽取）

任务	provider 默认值	model 默认值	timeout
`vision`	auto	“"（自动）	120s
`web_extract`	auto	"”	360s
`compression`	auto	""	120s
`session_search`	auto	""	30s
`skills_hub`	auto	""	30s
`approval`	auto	""	30s
`mcp`	auto	""	30s
`title_generation`	auto	""	30s
`triage_specifier`	auto	""	120s
`curator`	auto	""	600s

provider: auto 时，Hermes 自动选择最佳可用供应商（OpenRouter → Nous → Codex → 自定义）。

踩坑提示：视觉任务（vision）超时需设为 120s 或更高，图片下载需要额外时间。

agent — 行为参数

字段	默认值	常见调法	踩坑提示
`max_turns`	90	`20`（短任务）、`200`（长推理）	超限后停止，无错误提示
`reasoning_effort`	medium	low / medium / high	某些模型不支持此参数
`tool_use_enforcement`	auto	auto / true / false / [“gpt”, “codex”]	强制模型调用工具而非描述动作
`image_input_mode`	auto	native / text	`native` 直接传图片，`text` 先用 vision_analyze 描述
`gateway_timeout`	1800	`3600`（长任务）、`600`（短任务）	空闲超时，不是任务总时长
`gateway_notify_interval`	180	`600`（长任务反馈）、`0`（关闭）	周期性"仍工作中"通知间隔

terminal — 终端后端

字段	默认值	可选值	踩坑提示
`backend`	local	local / docker / ssh / modal / daytona	Docker 需要容器运行时
`timeout`	180	`600`（长任务）	超时后进程被 SIGTERM
`auto_source_bashrc`	true	true / false	`false` 时只读 `~/.bash_profile`
`persistent_shell`	true	true / false	SSH 后端自动持久化

容器资源限制（适用于 docker、modal、daytona）：

字段	默认值	说明
`container_cpu`	1	CPU 核心数
`container_memory`	5120	内存（MB），默认 5GB
`container_disk`	51200	磁盘（MB），默认 50GB

compression — 上下文压缩策略

字段	默认值	说明
`enabled`	true	是否启用压缩
`threshold`	0.5	触发阈值（50% 上下文使用率）
`target_ratio`	0.2	压缩到阈值比例（保留 20%）
`protect_last_n`	20	保留最近 N 条消息不压缩
`protect_first_n`	3	保留开篇 N 条非系统消息

踩坑提示：压缩发生在每轮对话结束，不是实时压缩。protect_first_n 包含在 protect_last_n 之外。

toolsets / platform_toolsets — 工具集配置

平台	默认工具集
cli（命令行）	browser、clarify、code_execution、cronjob、delegation、file、memory、session_search、skills、terminal、todo、tts、vision
telegram	hermes-telegram
discord	hermes-discord
whatsapp	hermes-whatsapp

禁用工具集：在 config.yaml 中设置 disabled_toolsets: ["vision", "tts"]。

踩坑提示：platform_toolsets 在 tools_config.py 中读取，不是直接在 config.py 中。

smart_model_routing — 简单问题用便宜模型

⚠️ 当前版本（0.14.0）此配置键未实现。配置文件中存在，但源码中无读取逻辑。

官方文档提及该功能，但目前需通过 Shell Hook 自实现（见 memory 记录）。

session_reset — 会话自动重置

字段	默认值	说明
`mode`	both	idle（空闲）、daily（每日）、both（两者）
`idle_minutes`	1440	空闲 N 分钟后重置
`at_hour`	4	每日 N 点强制重置

踩坑提示：会话重置在 gateway 模式下生效，CLI 模式不受影响。

checkpoints — 文件系统快照

字段	默认值	说明
`enabled`	false	是否启用
`max_snapshots`	20	每个项目最多快照数
`max_total_size_mb`	500	总大小上限（MB）
`max_file_size_mb`	10	单文件跳过阈值
`auto_prune`	true	自动清理过期快照
`retention_days`	7	保留天数

踩坑提示：enabled 默认 false，需要主动开启。/rollback 命令依赖此功能。

mcp_servers — MCP 服务器连接

1
2
3
4
5
6


mcp_servers:
 browser-use:
 url: https://api.browser-use.com/v3/mcp
 headers:
 x-browser-use-api-key: ${BROWSER_USE_API_KEY}
 timeout: 300

字段	必填	说明
`url`	是	MCP 服务器地址
`headers`	否	自定义 HTTP 头
`timeout`	否	连接超时（秒）

plugins — 插件启用 / 禁用

1
2
3
4
5
6


plugins:
 enabled:
 - disk-cleanup
 - rtk-rewrite
 disabled:
 - some-plugin

踩坑提示：插件需先安装在 ~/.hermes/plugins/ 目录，否则找不到。

第四章：.env 环境变量全表（按供应商分类）

供应商	必须变量	可选变量
OpenRouter	`OPENROUTER_API_KEY`
Anthropic	`ANTHROPIC_API_KEY` 或 `ANTHROPIC_TOKEN`
OpenAI	`OPENAI_API_KEY`
Z.AI / GLM	`ZAI_API_KEY` 或 `GLM_API_KEY`
Kimi	`KIMI_API_KEY` 或 `KIMI_CN_API_KEY`
MiniMax	`MINIMAX_API_KEY` 或 `MINIMAX_CN_API_KEY`
DeepSeek	`DEEPSEEK_API_KEY`
Google / Gemini	`GOOGLE_API_KEY` 或 `GEMINI_API_KEY`
xAI	`XAI_API_KEY`
Bedrock	`AWS_BEARER_TOKEN_BEDROCK`	`AWS_SECRET`
平台凭证
- 微信	`WEIXIN_TOKEN`、`WEIXIN_ACCOUNT_ID`
- 飞书	`FEISHU_APP_ID`、`FEISHU_APP_SECRET`
- Telegram	`TELEGRAM_BOT_TOKEN`
	- Discord	`DISCORD_BOT_TOKEN`

踩坑提示：.env 文件不支持 bash 变量展开（如 ${HOME}），只能用字面路径。

第五章：SOUL.md — 给 Agent 一个灵魂

SOUL.md 每轮对话加载，改了立即生效，不需要重启。

实战框架：六要素

 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


## 身份定位
我是忞的**自主执行者和思考伙伴**。

## 核心职责
1. **任务执行**：完成忞交代的任务
2. **思考伙伴**：评估想法再执行
3. **信息管理**：主动收集整理信息
4. **风险预警**：发现潜在风险立即告知

## 个性特点
- **专业**：专家级能力，判断准确
- **简洁**：一句话说清，表格优先
- **贴心**：主动提醒风险
- **高效**：立即执行，先做后报

## 执行原则
1. **高执行力**：先执行后汇报
2. **主动提醒**：发现风险立即告知
3. **主动总结**：任务完成自动总结

## 反驳机制（强制执行）
- **必须反驳**：有问题必须指出
- **必须带证据**：每次反驳附带数据或案例
- **禁止为反而反**：没有依据的抬杠毫无价值

## 沟通风格
- ✅ **简洁**：能一句话不用两句
- ✅ **结构化**：表格优先
- ✅ **结果先行**：先说结论
- ❌ **禁止**：冗余解释、废话铺垫

默认 SOUL vs 深度定制 SOUL

行为	默认 SOUL	深度定制 SOUL
称呼	“用户”	“忞”
反驳	无反驳机制	强制反驳 + 证据
问责	不追问	主动追问输出是否采纳
风格	标准客服	专业伙伴

第六章：数据目录 — Agent 的"记忆宫殿"

目录	作用	能否删除
`sessions/`	历史会话 JSON 文件	可以，但失去历史记录
`memories/`	记忆文件（MEMORY.md、USER.md）	不要删，丢失记忆
`state.db`	SQLite 数据库（会话索引）	不要删，破坏数据完整性
`kanban/`	看板任务和日志	可以，但失去看板状态
`cron/`	定时任务输出	可以，临时文件
`logs/`	日志文件（agent.log、errors.log）	可以，但失去调试信息
`checkpoints/`	文件系统快照	可以，失去 /rollback 能力
`auth.json`	OAuth token	可以，但需重新授权

踩坑提示：state.db 和 memory.db 是核心数据库，删除会导致会话和记忆丢失。

第七章：扩展层 — 让 Agent 越来越强

目录	作用	使用方式
`skills/`	技能目录（SKILL.md + 脚本）	`/skills` 命令管理
`scripts/`	自定义脚本	终端直接调用
`plugins/`	插件目录（MCP 服务器、平台适配器）	`config.yaml` → `plugins.enabled`
`hooks/`	事件钩子脚本	会话开始/结束时执行

踩坑提示：技能必须包含 SKILL.md（YAML frontmatter + Markdown body），否则无法加载。

第八章：Profiles — 多实例并行

每个 profile 是完整的并行 ~/.hermes/：

1
2
3
4
5
6
7


~/.hermes/profiles/blog-writer/
├── config.yaml # 独立配置
├── .env # 独立凭证
├── SOUL.md # 独立个性
├── state.db # 独立数据库
├── sessions/ # 独立会话
└── logs/ # 独立日志

典型场景：

blog-writer：博客写作，模型 glm-4.7
reviewer：审核质量，模型 glm-5.1
yuan：个人 AI，模型 glm-5-turbo

切换 profile：hermes -p blog-writer

踩坑提示：profile 不共享配置和状态，完全隔离。

第九章：安全地图

文件/配置	安全等级	建议
🟢 `config.yaml`	低	可以自由修改
🟢 `.env`	高	包含 API 密钥，不要提交到版本控制
🟢 `SOUL.md`	低	可以自由修改
🟡 `state.db`	中	包含会话数据，谨慎删除
🟡 `memory.db`	中	包含记忆数据，谨慎删除
🔴 `auth.json`	高	包含 OAuth token，不要泄露
🔴 `.env` 密钥	高	不要在对话中完整展示

附录

A. hermes doctor 输出解读

hermes doctor 检查项：

检查项	输出示例	说明
Python 版本	`✓ Python 3.13.0`	版本满足要求
Hermes 版本	`✓ Hermes Agent v0.14.0`	当前版本
OpenAI SDK	`✓ OpenAI SDK 1.x`	SDK 已安装
API 密钥	`✓ OPENROUTER_API_KEY set`	凭证已配置
配置文件	`✓ config.yaml valid`	配置格式正确

B. 常见报错对应的配置项

报错	对应配置项	解决方案
`401 Unauthorized`	`api_key` 或 `.env`	检查密钥是否正确
`429 Rate Limit`	`fallback_providers`	配置备用供应商
`max_tokens exceeded`	`max_tokens`	减小输出长度
`context length exceeded`	`context_length`	减小上下文长度
`tool not found`	`toolsets` / `disabled_toolsets`	检查工具集配置
`permission denied`	`terminal.backend`	检查容器权限

C. 最小启动配置模板

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


model:
 default: glm-5.1
 provider: zai
 api_key: ${ZAI_API_KEY}

agent:
 max_turns: 90

terminal:
 backend: local
 timeout: 180

compression:
 enabled: true

toolsets:
 - hermes-cli
 - terminal
 - file

.env：

1

ZAI_API_KEY=your_key_here

总结

Hermes 配置文件结构清晰：

核心三文件：config.yaml（行为）、.env（凭证）、SOUL.md（个性）
数据目录：sessions/、memories/、state.db 是 Agent 的"记忆宫殿"
扩展层：skills/、plugins/ 让 Agent 越来越强
Profiles：多实例并行，每个 profile 完全独立
安全第一：.env 和 auth.json 包含敏感信息，谨慎处理

记住：SOUL.md 改了立即生效，config.yaml 部分配置需重启 gateway。

关注 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篇将分享踩坑最佳实践

Hermes vs OpenClaw对比：终端派 Hermes Agent 的选择

Mon, 18 May 2026 22:00:00 +0800

结论先说：这不是竞品

这两个项目根本不在一条赛道上。

OpenClaw（小龙虾🦞）想做的是「全平台个人AI助手」——像Siri一样渗透到你生活的每个角落，微信、WhatsApp、Telegram、macOS、iOS、Android，它都能接。你想用什么渠道就跟它说什么，它就回你在哪儿。

Hermes Agent 做的是「终端派 Hermes Agent 框架」——给开发者和技术用户的一把瑞士军刀。Kanban任务板、多Agent编排、技能系统、记忆宫殿，全是围绕「如何把复杂任务拆解、分配、执行」设计的。

如果你想找个好用的个人助手，选 OpenClaw；如果你想搭个能自动跑活的Agent系统，选 Hermes。

表格对比：一眼看懂差异

维度	OpenClaw（小龙虾）	Hermes Agent
定位	个人AI助手	终端Hermes Agent框架
GitHub Stars	372,888	较小众
语言	TypeScript	Python + TypeScript
渠道覆盖	20+（微信、WhatsApp、Telegram、Slack、Discord、QQ、iMessage、macOS、iOS、Android等）	微信、飞书、Telegram、Discord
上手门槛	一条命令 `openclaw onboard` 自动配置	需要理解Kanban、Profile、Skill概念
多Agent能力	Multi-agent routing（按渠道/账户隔离）	Kanban任务板 + Subagent委托（可视化编排）
记忆系统	基于会话	MemPalace（四级回忆链：热记忆→MemPalace→session_search→外部知识库）
定时任务	Cron jobs	内置Cronjob工具（带keep-alive、context注入）
技能生态	ClawHub（5400+ skills）	自建Skill系统（轻量级，易定制）
部署方式	Gateway + 多渠道inbox，支持Node 24/22.19+	100%本地部署，零第三方依赖
安全模型	Sandbox模式（Docker/SSH/OpenShell）	可选Bash/SSH后端
特色功能	Voice Wake、Live Canvas、macOS/iOS/Android原生App	Kanban可视化、Profile隔离、技能热加载
适合人群	想要「好用的助手」的普通用户	开发者、技术用户、需要自动化工作流的人

渠道覆盖：OpenClaw 完胜

OpenClaw 支持的渠道列表长得吓人：WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、IRC、Microsoft Teams、Matrix、Feishu、LINE、Mattermost、Nextcloud Talk、Nostr、Synology Chat、Tlon、Twitch、Zalo、Zalo Personal、WeChat、QQ、WebChat、macOS、iOS/Android。

你想在哪个平台跟它聊天，它就在那儿等你。而且它不是简单的「转发消息」，每个渠道都有深度集成——比如 macOS 有 Live Canvas（可视化工作台）、iOS/Android 有 Voice Wake（语音唤醒）、桌面端有原生 App。

Hermes 只支持四个渠道：微信、飞书、Telegram、Discord。但对我来说够用了——我的主要沟通场景就是微信，偶尔在 Discord 跟技术社区交流。

上手门槛：OpenClaw 友好，Hermes 需要理解成本

OpenClaw 的入门体验堪称教科书级别：

1
2


npm install -g openclaw@latest
openclaw onboard --install-daemon

就这么简单。onboard 命令会引导你一步步配置 Gateway、Workspace、Channels、Skills，像安装软件一样。而且它有 macOS 菜单栏 App、iOS/Android Node，可视化程度很高。

Hermes 的学习曲线要陡峭一些。你需要理解三个核心概念：

Kanban：任务板，用来管理和跟踪任务
Profile：Agent 配置文件，不同的 Profile 有不同的工具集和能力
Skill：技能包，可复用的任务流程

这不是「安装就能用」，而是「学习后才能发挥威力」的工具。但一旦你理解了这套系统，它的灵活性远超 OpenClaw。

多Agent能力：设计哲学差异

两者都支持多 Agent，但思路完全不同。

OpenClaw 采用「路由隔离」模式：你可以为不同的渠道、账户、Peer 配置独立的 Agent。比如你的微信发给 Agent A，WhatsApp 发给 Agent B，Telegram 的某个群发给 Agent C。每个 Agent 有自己的 Workspace、Session、Tool 配置。

Hermes 采用「任务板编排」模式：所有任务在 Kanban 上统一管理，通过 parents 字段表达依赖关系。你可以把一个大任务拆解成多个子任务，每个子任务分配给不同的 Profile（比如 researcher 做调研、writer 写文章、reviewer 审核）。当所有父任务完成，子任务自动从 todo 提升到 ready。

OpenClaw 更像「多租户隔离」，Hermes 更像「项目化管理」。前者适合个人多场景使用，后者适合复杂工作流自动化。

记忆系统：MemPalace 是杀手级特性

Hermes 的 MemPalace 是我最喜欢的功能。它不是简单的「存储对话历史」，而是四级回忆链：

热记忆（~2200字符）：高频使用的用户偏好、行为规则、环境配置
MemPalace：长期知识库，支持分类存储（drawers + memories）
Session Search：搜索过去会话的总结，快速找回上下文
外部知识库：通过 IMA 集成，连接你的笔记、知识库、收藏

OpenClaw 的记忆系统相对传统，主要是基于会话的短期记忆。它也能记住一些上下文，但没有 MemPalace 这种结构化的知识管理。

如果你需要 Agent 真正「记住」你的长期偏好和知识，Hermes 的 MemPalace 完胜。

部署方式：100%本地 vs Gateway模式

Hermes 是 100% 本地部署的，零第三方依赖。你只需要一个 Python 环境，就能跑起来。所有数据都在你的机器上，隐私绝对安全。

OpenClaw 是 Gateway 模式——本地跑一个 Gateway 服务（Node 24/22.19+），然后通过各种渠道接入。它支持 7x24 运行，有专业的 daemon 进程管理。但它需要更多的依赖和配置。

两种部署方式各有优劣：

Hermes：简单、轻量、隐私友好，但需要你自己维护进程
OpenClaw：专业、稳定、开箱即用，但需要更多资源

生态：ClawHub vs 自建技能

OpenClaw 有 ClawHub 技能市场，5400+ skills，涵盖各种场景。你想干什么基本都有现成的技能包。

Hermes 的 Skill 系统更轻量级，主要是自建。官方提供了一些通用技能（比如 kanban-worker、hugo-blog），但你大部分时间是自己写技能。

这跟设计哲学有关：OpenClaw 想做「产品」，给你现成的东西用；Hermes 想做「框架」，给你工具自己做。

选择建议：什么人选什么？

选 OpenClaw，如果你：

想要一个好用的个人AI助手，不想折腾
需要覆盖多个渠道（尤其是非技术平台）
喜欢「可视化操作」和「原生 App」的体验
不介意多装一些依赖，希望开箱即用
主要场景是「聊聊天、查查信息、简单自动化」

选 Hermes，如果你：

是开发者或技术用户，愿意学习新概念
需要复杂工作流自动化（比如博客写作、代码审查、多Agent协作）
看重数据隐私，希望 100% 本地部署
想要灵活定制自己的 Agent 系统
主要场景是「项目化任务管理」和「深度自动化」

我的选择

我两个都用了，但最后选择了 Hermes。

原因很简单：我是一个技术用户，大部分时间在终端和编辑器里工作。Hermes 的 Kanban、Profile、Skill 这套系统，正好匹配我的工作方式。我可以用 Kanban 管理博客写作计划，用不同的 Profile 处理不同类型的任务，用 Skill 封装可复用的流程。

OpenClaw 很强大，但它的优势不在我的使用场景里。我不需要在 20 个渠道上跟 AI 聊天，也不需要 Live Canvas 或 Voice Wake。我需要的是能帮我自动化复杂任务、记住我的长期偏好、可灵活定制的工具——这些正是 Hermes 的强项。

当然，这不代表 OpenClaw 不好。它是一个非常优秀的个人AI助手，GitHub 372,888 stars 说明了一切。只是对我来说，Hermes 更对胃口。

后续：有没有可能融合？

技术上完全可能。Hermes 可以通过 WebSocket 或 CLI 接入 OpenClaw 的 Gateway，享受它的多渠道能力；OpenClaw 也可以借鉴 Hermes 的 Kanban 和 MemPalace，增强任务管理和知识记忆。

但目前它们确实是两个方向的产品。OpenClaw 追求「覆盖广」和「易用」，Hermes 追求「深度定制」和「专业自动化」。

没有谁比谁好，只有谁更适合你。

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

给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，一起学习，一起成长

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 协作实战

AI Agent 的定时任务：从「到点跑命令」到「到点帮你思考」

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

半夜3点磁盘满了，早上9点选题推荐准时推送——这些都不是我干的，是我的AI定时任务替我干的。

先说结论

AI Agent的cron定时任务，和传统的 crontab 不是一回事。

传统cron是"到点跑命令"，AI Agent的cron是**“到点唤醒一个AI帮你思考和执行”**。它能搜索、能分析、能写文件、能推送到微信。

两种模式：脚本直出（零token消耗，纯数据采集）和Agent模式（有推理能力，会做判断。token可以理解为AI思考和输出的计费单位）。选型一句话：固定格式用脚本，需要思考的用Agent。

传统cron到底差在哪

先看一张对比：

维度	传统crontab	AI Agent cron
能力	执行固定命令	执行+推理+搜索+写文件
输出	发邮件，没人看	推到微信/Telegram
上下文	无	可注入skill、记忆、历史
智能程度	零	能判断"没事别烦我"
失败处理	写个error日志	分析原因、换方案重试

传统cron最大的问题不是功能弱，而是输出没人看。crontab每天给你发邮件，你打开过吗？

AI Agent的cron不一样——它直接推到你的聊天工具，而且只在有事的时候才推。

两种模式

A. 脚本直出（no_agent模式）

原理很简单：bash/python脚本跑完 → stdout → 直接推送到你的聊天窗口。

不经过LLM，零token消耗。

我配了一个系统健康巡查脚本，每天8:00和22:00自动跑，输出长这样：

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


## 🟢 系统巡查报告

时间: 2026-05-12 08:01 | 运行: 3天23小时 | 负载: 0.06

资源
| 指标 | 数值 | 状态 |
|--------|-------------------|------|
| CPU | 3% | ✅ |
| 内存 | 2268M/32131M (7%) | ✅ |
| Swap | 0M/7823M | ✅ |
| 磁盘/ | 42G/140G (32%) | ✅ |

服务: sshd ✅ | AI助手 ✅
网络: 百度 ✅ | Google ✅

这个脚本做了什么？

检查CPU/内存/Swap/磁盘，超阈值标⚠️
检查关键服务是否活着（sshd、cron、AI进程）
测试国内外网络连通性（ping + HTTP）
拉最近1小时系统错误日志
任何一项异常，标题从🟢变⚠️

全部健康就一条消息，有异常自动高亮。每天看一眼就行。

适合场景：监控告警、固定格式数据采集、定期备份验证。核心特征是输出格式固定，不需要AI判断。

B. Agent模式

这个才是真正有意思的。

原理：定时唤醒 → 加载你写的prompt → AI推理 → 调用工具（搜索、终端、文件） → 生成报告 → 推送给你。

消耗token，但有"脑子"。

比如我的公众号选题推荐，每周二9:00自动执行。它的信息采集分四个维度：

维度1：我最近做了什么（读cron状态、最近skill、产出文件、AI记忆）
维度2：我的系统最新更新了什么（搜GitHub release/changelog）
维度3：外面在我的系统上都在聊什么（Reddit/HN/掘金/知乎）
维度4：外面在聊什么（本周AI热点动态）

它会先读本地环境（最近装了什么、配了什么），再搜外部热点，然后找两者的交集。出来的选题不是泛泛的"AI时代来了"，而是"我刚装了RTK省了80% token"这种实操内容。

适合场景：需要搜索分析、需要综合判断、需要阅读本地文件的场景。核心特征是每次输出不一样，需要AI"思考"。

一个关键设计：静默机制

Agent模式有个 [SILENT] 机制——如果AI判断"确实没什么新东西"，它回复一个静默标记，系统就不推送。

这个设计太重要了。

传统监控最怕的是什么？告警疲劳。天天给你发"一切正常"，你就不看了。突然有一天"不正常"了，你早就把它当噪音过滤掉了。

静默机制反过来：没事别烦我，有事才说话。 你的聊天窗口只出现真正需要关注的信息。

从0配置一个cron job

以健康巡查为例，完整流程：

Step 1：写脚本

~/.hermes/scripts/health-check.sh，用bash采集系统信息，输出Markdown表格。关键点：

用 set -uo pipefail 防止静默失败
设置阈值判断（CPU>80% ⚠️、内存>85% ⚠️）
输出格式统一（Markdown表格，方便在聊天窗口阅读）

Step 2：创建cron

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


# 脚本模式
cronjob create \
 --name "系统健康巡查" \
 --script "health-check.sh" \
 --no-agent \
 --schedule "0 8,22 * * *" \
 --deliver origin

# Agent模式
cronjob create \
 --name "公众号选题推荐" \
 --prompt "你的prompt..." \
 --toolsets web,terminal,file \
 --schedule "0 9 * * 2" \
 --deliver origin

Step 3：验证

所有执行记录存在cron的output目录下，按时间命名。随时可以回查。

进阶玩法

链式执行：job A采集数据 → job B分析报告（A跑完自动触发B）。用 context_from 参数把上游输出注入下游。比如：健康巡查发现异常 → 自动触发诊断任务分析原因。
模型锁定：每个job可以指定不同模型。省钱的数据采集用小模型，重要的分析任务用大模型。
目录隔离：不同job可以指定不同的工作目录（workdir），互不干扰。

踩坑实录

1. skill找不到

cron执行环境是独立的，不像主对话有完整的skill列表。解决方案：把需要的能力写在 enabled_toolsets 里（web/terminal/file）。

2. 纯数据采集用了Agent模式

固定格式的数据采集（比如健康检查），用Agent模式是纯浪费token。能用脚本解决的别用Agent。

3. 输出太长被截断

微信单条消息有长度限制。设计prompt时加一句"输出控制在500字以内"，或者脚本里精简格式。

4. 时区

schedule用的是系统时区。服务器在国内就不用管，在海外记得设 TZ=Asia/Shanghai。

5. 静默不等于失败

脚本模式下，stdout为空 = 不推送。如果你的脚本某个分支忘了echo，就会"消失"。确保每种情况都有输出。

怎么选

一句话决策树：

1
2
3
4
5
6
7


需要AI判断吗？
├── 不需要 → 脚本直出（no_agent=true）
│ └── 监控、采集、固定格式报告
└── 需要 → Agent模式
 ├── 搜索+分析 → toolsets加web
 ├── 读本地文件 → toolsets加terminal+file
 └── 两个都要 → 都加上

写在最后

AI Agent的cron，本质上是把"定时执行"升级为**“定时思考”**——不是到点跑命令，而是到点让AI帮你做决策。

不在线的时候，有人在替你盯着。

AI 写代码太费 Token？一个 9.5MB 小工具，直接砍 80%

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

AI写代码太费Token？一个9.5MB小工具，直接砍80%

你有没有算过，让AI帮你写代码，一天要烧多少Token？

先说结论

我给AI Agent装了一个叫 RTK 的工具，一个命令，零配置，Token消耗直接砍掉80%。

核心思路就一句话：在命令输出喂给AI之前，先压缩一遍。

问题是什么

用AI Agent干活的人都知道，Agent特别"啰嗦"——它会疯狂执行命令，然后把所有输出原封不动塞给自己的上下文窗口（AI一次能"看到"的信息量）。

举个例子，项目里跑个 git status：

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


On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
 modified: src/components/Dashboard.tsx
 modified: src/hooks/useAuth.ts
 modified: src/pages/Login.tsx
 modified: src/utils/api.ts
 modified: package.json
 modified: package-lock.json

Untracked files:
 src/utils/newFeature.ts
 tests/test_newFeature.py
 ...

大概 2000个Token。

但AI真正需要知道什么？就一句话：“5个文件改了，还没commit”。

一个中型项目，AI Agent跑30分钟，光是 ls、cat、git status、pytest 这些命令的输出，就能吃掉 11.8万个Token。按主流商业API的价格算，这就是几块钱没了。

更致命的不是钱——是上下文窗口被垃圾信息占满，AI真正需要关注的代码逻辑反而被挤掉了。

RTK做了什么

RTK（Rust Token Killer） 的工作原理极其简单：

1
2
3
4
5


没有RTK：
AI → 执行 git status → 完整输出(2000 tokens) → 塞给AI

有了RTK：
AI → 执行 git status → RTK拦截 → 压缩后输出(200 tokens) → 塞给AI

它在命令和AI之间加了一层过滤器，对输出做四件事：

过滤：去掉注释、空行、无关信息
分组：把相似内容合并（比如按目录归类文件）
截断：保留关键上下文，砍掉重复
去重：把重复的日志行合并成计数

压缩效果：

命令	原始输出	RTK压缩后	节省
`ls -la`	完整文件列表	紧凑目录树	72%
`git status`	30行状态信息	一行摘要	80%
`pytest`	全量测试日志	只看失败的	90%
`git commit`	完整输出	“ok abc1234”	92%
`cargo test`	编译+测试全量	只看失败	90%

覆盖 100+ 命令：git、find、grep、各种test runner、lint工具、Docker、K8s、AWS CLI……基本你能想到的开发命令它都支持。

我的实测

装完之后我跑了两个命令测试，RTK自己的统计面板：

1
2
3
4
5


Total commands: 2
Input tokens: 987
Output tokens: 279
Tokens saved: 713 (72.2%)
Total exec time: 3ms (avg 1ms)

72.2%的节省，延迟3毫秒。完全无感。

再看一个具体对比。项目目录下跑 ls：

压缩前（原始 ls -la，987 tokens）：

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


drwxr-xr-x 35 root root 1120 May 12 06:56 .
drwxr-xr-x 35 root root 1120 May 12 06:56 ..
drwxr-x--- 3 root root 4096 May 10 22:00 .config
drwxr-xr-x 2 root root 4096 Apr 8 18:12 .gnupg
drwxr-xr-x 4 root root 4096 May 6 21:30 .hermes
drwxr-xr-x 2 root root 4096 May 7 12:48 .local
-rw-r--r-- 1 root root 37B May 2 14:25 .npmrc
-rw-r--r-- 1 root root 348B Apr 8 18:12 .profile
-rw-r--r-- 1 root root 1.1K May 12 06:51 .bashrc
-rw-r--r-- 1 root root 72B Apr 8 18:12 .zshrc
-rw-r--r-- 1 root root 13K May 12 06:52 .bash_history
...（省略20行）

压缩后（rtk ls，279 tokens）：

1
2
3
4
5


.config/ .gnupg/ .hermes/ .local/
.bashrc 1.1K .profile 348B .zshrc 72B
.bash_history 13.0K .npmrc 37B
dialogs/ exes/ output/ workspace/
...（紧凑列表，无多余信息）

同样的信息量，砍了72%的Token。

它不是万能的

说几个我注意到的问题：

1. 覆盖不了AI工具的内置命令

比如某些AI编码工具有自己的 Read、Grep 内置工具，这些不走系统shell，RTK拦截不到。得手动用 rtk read、rtk grep 替代。

2. 46k Star，476个Open Issue

增长太快，维护压力肉眼可见。不过核心的命令压缩功能很稳——过滤文本输出这种事，不太容易出问题。

3. 会收集使用数据

默认有遥测上报（设备哈希+命令统计）。开源项目，代码可以审计，在意的话可以关掉。

谁该用，谁不需要

✅ 该装的：

用AI Agent写代码（任何AI工具都行）
Token消耗大、账单肉疼
上下文窗口老是不够用，AI"忘性"大

❌ 不需要的：

偶尔问两句话、不跑命令
不用AI做开发

怎么装

一行命令，9.5MB单文件，零依赖，装完就能用：

1

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

macOS 也可以用 Homebrew：

1

brew install rtk

装完验证一下：

1
2


rtk --version # 应该显示 rtk 0.39.0
rtk gain # 查看节省统计

如果你的AI工具在支持列表里（Claude Code、Cursor、Copilot、Codex、Gemini CLI……），跑一下 rtk init -g 自动配置。否则直接在命令前加 rtk 前缀：rtk git status、rtk pytest、rtk ls。

RTK 解决的不是什么高大上的问题——它就是在做一件事：别把垃圾喂给AI。

这件小事，省80%的Token。

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》，结合个人实践分析整理。

Windows 原生支持来了：Hermes Agent 不再只属于 Linux/macOS

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

Windows 原生支持，来了

2026年5月8日，一个 255 个文件、新增 7675 行代码的 PR 被合并进 Hermes Agent 主分支。

PR #21561，标题很简单：「feat(windows): native Windows support (early beta)」。

从这一天起，Hermes 不再只属于 Linux/macOS 用户。你可以直接在 PowerShell 里一行命令装好，不需要 WSL，不需要虚拟机，不需要任何 Linux 基础。

先说结论：能用了，但还早

目前的状态是** Early Beta**——官方自己标的。什么意思？

**能用的：**CLI 终端、Gateway 消息网关、定时任务、浏览器自动化、MCP 工具链、Ollama 本地模型对接、Web 管理面板，这些全部在原生 Windows 上跑通了。

**还不行的：**Web 面板里的嵌入式终端（需要 POSIX PTY，Windows 暂不支持）；另外还有一些路径编码、进程管理的小 bug 在持续修复中。

安装：一行命令

1

irm https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.ps1 | iex

打开 PowerShell，粘贴回车。安装脚本会自动处理 Python 环境（通过 uv）、Node.js 和 Git Bash 的依赖。

Linux/macOS 用户原有的 curl 安装方式不变：

1

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

为什么这件事值得说

在 PR #21561 合并之前，Windows 用户想用 Hermes，只有两条路：

WSL2——能用，但你得懂 Linux，得装 WSL，得处理网络桥接，折腾门槛不低。
自己硬上——有人在 Windows 直接跑，但到处报错：fcntl 导入失败、GBK 编码崩溃、进程探测 OSError……体验一言难尽。

GitHub 上与 Windows 相关的 issue 超过 1100 个。排在前面的全是：os.kill(pid, 0) 在 Windows 上抛 SystemError、终端工具输出为空、.env 文件编码损坏、cp1252 导致 UnicodeEncodeError……

说白了，Hermes 之前是按 POSIX 标准写的，Windows 是个「二等公民」。

这次合并把这些问题做了系统性的修复：

进程管理：重写了 Windows 进程检测逻辑，用 kernel32.OpenProcess 替代了 POSIX 信号量探测
路径处理：新增路径归一化函数，统一处理反斜杠、驱动器号、WSL 路径互转
编码问题：全局强制 UTF-8 输出，解决 cp1252/GBK 崩溃
安装体验：PowerShell 一键安装器，自动绑定 Python + Node.js + Git Bash
CI 门禁：新增 check-windows-footguns.py，每个 PR 都自动检测 Windows 兼容性问题

功能对比：原生 Windows vs WSL2

功能	原生 Windows	WSL2
CLI / TUI	✅	✅
Gateway 消息网关	✅	✅
定时任务	✅	✅
浏览器自动化	✅	✅
MCP 工具链	✅	✅
Ollama 本地模型	✅	✅
Web 管理面板	✅	✅
面板内嵌终端	❌	✅
开机自启	✅ (schtasks)	✅ (systemd)

除了面板内嵌终端这一个点，其他功能已经和 WSL2 平齐。

背后做了什么

这次合并不是简单加几个 if-else。CONTRIBUTING.md 里新增了 16 条跨平台兼容性规范，覆盖了你在 Windows 上能想到的每一个坑：

禁止使用 os.kill(pid, 0)（Windows 会抛 SystemError）
禁止直接调用 wmic、ps、grep 等 Unix 命令
fcntl/termios 必须 ImportError 保护
文件读取必须显式指定 UTF-8 编码
进程管理要用 CREATE_NEW_PROCESS_GROUP 替代 os.setsid
路径必须用 pathlib.Path，不能硬编码斜杠
符号链接在 Windows 需要管理员权限
OneDrive 重定向路径的兼容处理
CRLF/LF 行尾符一致性

配套的 CI 检查脚本会在每个 PR 提交时自动扫描这些「Windows 地雷」，防止新代码引入兼容性问题。

如果你想试试

环境要求：Windows 10/11，PowerShell 5.1+
安装：一行命令搞定，安装脚本自带 Python 环境
配置模型：安装完成后运行 hermes setup，配置你的 API Key（支持智谱GLM、DeepSeek、通义千问等国内模型）
启动：hermes 回车，进入交互式终端

遇到问题可以直接去 GitHub 搜 issue，1100 多个 Windows 相关 issue 说明社区很活跃，维护者在密集修复。

值得关注的信号

几个细节说明这次不是玩票：

创始人亲自提交：PR #21561 的合并者是 @teknium1（Nous Research 创始人），不是随便一个社区贡献者
文档同步上线：README 首页直接加了 Windows 安装入口，文档站新增了完整的 Windows 专属页面
安装脚本锁定：CONTRIBUTING.md 要求 install.sh 和 install.ps1 必须同步更新，不是加完就不管
社区参与度高：合并当天就有多个新 issue 和 PR 提交，说明已经有用户在原生 Windows 上实际使用了

一句话总结

Windows 原生支持从「完全不能用」变成了「能用但还粗糙」。对 Windows 用户来说，门槛从「先学 Linux」降到了「一行命令安装」。对项目来说，用户池一下子从 Linux/macOS 开发者扩展到了全球最大的桌面操作系统用户群。

Beta 就是 Beta，但方向是对的。

给 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

上次没敢写的4个 Hermes 进阶配置，这次全给你

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

上一篇发了8个必改配置，反响不错。结尾提到4个进阶功能，很多人追着问。这次翻完源码，一个个给你讲透——配置拿来就能用，不是画饼。

先说结论

上次那8个是"装完就改"的基础配置。这次4个是真正拉开差距的进阶玩法：

配置	一句话	难度	最低版本
Shell Hooks	AI每次执行命令前，先跑你的检查脚本	⭐⭐	v2026.4.23
Quick Commands	输入 /status 直接跑系统命令，不经过AI，不花Token	⭐	v2026.3.12
模型别名	输入 /model opus 一键切模型，不用改配置文件	⭐	v2026.3.23
凭据池轮换	多个API Key自动轮换，被限流也不怕	⭐⭐⭐	v2026.4.3

⚠️ 版本要求：这4个功能都是近几个月新增的，老版本不支持。查看你的版本：hermes --version。如果低于上表中的最低版本，先 hermes update 升级。当前最新版是 v0.13.0 (v2026.5.7)。

一个一个说。

1. Shell Hooks：用Shell脚本拦截AI的操作

类比：你在公司，AI是你的助理。默认情况下它想干嘛干嘛——删文件、跑命令、改配置，你管不了。Shell Hooks就是给助理装了个"门禁"：每次它要执行操作，先过你的检查脚本。不合格的直接拦下来。

实际用途：

AI要执行 rm -rf？拦住
AI刚写了Python文件？自动跑black格式化
每次AI开始思考前，自动注入当前git状态

配置方法

在 ~/.hermes/config.yaml 中：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


hooks:
 pre_tool_call: # AI执行工具前触发
 - matcher: "terminal" # 正则匹配工具名
 command: "~/.hermes/agent-hooks/block-dangerous.sh"
 timeout: 5 # 超时秒数，默认60，最大300
 post_tool_call: # AI执行工具后触发
 - matcher: "write_file|patch" # 写文件后自动格式化
 command: "~/.hermes/agent-hooks/auto-format.sh"
 pre_llm_call: # AI每次思考前注入上下文
 - command: "~/.hermes/agent-hooks/inject-git-status.sh"

实战示例：拦截危险命令

创建目录和脚本：

1

mkdir -p ~/.hermes/agent-hooks

脚本1：拦截危险命令（保存为 ~/.hermes/agent-hooks/block-dangerous.sh）

1
2
3
4
5
6
7
8


#!/usr/bin/env bash
payload="$(cat -)"
cmd=$(echo "$payload" | jq -r '.tool_input.command // empty')
if echo "$cmd" | grep -qE 'rm[[:space:]]+-rf?[[:space:]]+/'; then
 printf '{"decision": "block", "reason": "blocked: rm -rf / is not permitted"}\n'
else
 printf '{}\n'
fi

脚本2：自动格式化（保存为 ~/.hermes/agent-hooks/auto-format.sh）

1
2
3
4
5


#!/usr/bin/env bash
payload="$(cat -)"
path=$(echo "$payload" | jq -r '.tool_input.path // empty')
[[ "$path" == *.py ]] && command -v black >/dev/null && black "$path" 2>/dev/null
printf '{}\n'

脚本3：注入git状态（保存为 ~/.hermes/agent-hooks/inject-git-status.sh）

1
2
3
4
5
6
7
8


#!/usr/bin/env bash
cat - >/dev/null # 丢弃stdin
if status=$(git status --porcelain 2>/dev/null) && [[ -n "$status" ]]; then
 jq --null-input --arg s "$status" \
 '{context: ("Uncommitted changes:\n" + $s)}'
else
 printf '{}\n'
fi

别忘了加执行权限：

1

chmod +x ~/.hermes/agent-hooks/*.sh

工作原理

脚本通过JSON管道跟Hermes通信：Hermes把工具调用的详细信息（工具名、参数、会话ID等）通过stdin传给你的脚本，你的脚本通过stdout返回JSON结果。

stdin 示例（脚本收到的数据）：

1
2
3
4
5
6
7


{
 "hook_event_name": "pre_tool_call",
 "tool_name": "terminal",
 "tool_input": {"command": "rm -rf /"},
 "session_id": "sess_abc123",
 "cwd": "/home/user/project"
}

stdout 返回（脚本要输出的数据）：

1

{"decision": "block", "reason": "blocked: rm -rf / is not permitted"}

返回空 {} 就是不拦截，放行。

支持的所有钩子事件

事件	触发时机	能做什么
`pre_tool_call`	AI执行工具前	拦截危险操作
`post_tool_call`	AI执行工具后	自动格式化、记录日志
`pre_llm_call`	AI开始思考前	注入额外上下文（如git状态）
`post_llm_call`	AI思考完成后	日志记录
`subagent_stop`	子代理完成时	记录多代理协调日志
`on_session_start`	会话开始	初始化操作
`on_session_end`	会话结束	清理操作
`on_session_reset`	会话重置	状态清理
`transform_terminal_output`	终端输出时	过滤/压缩输出内容
`transform_tool_result`	工具返回结果时	过滤敏感信息

首次运行提示

第一次用Shell Hooks时，Hermes会弹窗问你是否信任这个脚本。同意后会记住（存在 ~/.hermes/shell-hooks-allowlist.json），以后不再问。

如果你是在Gateway（微信/Telegram等）或Cron定时任务中使用，没交互界面，需要在配置中加：

1

hooks_auto_accept: true # 自动信任新脚本

或者启动时加 --accept-hooks 参数。

检查和维护

1
2
3


hermes hooks list # 查看所有已配置的hooks
hermes hooks doctor # 健康检查（权限、状态、执行时间）
hermes hooks test pre_tool_call --for-tool terminal # 测试某个hook

2. Quick Commands：零Token快捷命令

类比：你跟AI说"帮我查下GPU状态"，AI要理解你的意思、调用工具、返回结果——走完整流程，花Token。Quick Commands就是给你设了个快捷键：输入 /gpu 直接执行命令，不经过AI，Token消耗为零。

实际用途：

/gpu → 直接看GPU状态
/ip → 直接查IP
/dn → 看今天的笔记
/status → 一键查系统状态

配置方法

在 ~/.hermes/config.yaml 中：

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


quick_commands:
 gpu:
 type: exec
 command: "nvidia-smi --query-gpu=name,utilization.gpu,memory.used --format=csv,noheader"
 ip:
 type: exec
 command: "curl -s ifconfig.me"
 status:
 type: exec
 command: "echo \"CPU: $(top -bn1 | grep '%Cpu' | awk '{printf \"%.0f\", 100-$8}')%\" && echo \"MEM: $(free -h | awk '/^Mem:/{print $3 \"/\" $2}')\" && echo \"DISK: $(df -h / | awk 'NR==2{print $5}')\""
 dn:
 type: exec
 command: "cat ~/notes/$(date +%Y-%m-%d).md"

两种模式

type	行为	示例
`exec`	直接执行shell命令，输出结果	`/gpu` → 跑nvidia-smi
`alias`	重写到另一个斜杠命令	`/sc` → 等同于 `/model sonnet --provider openrouter`

alias模式示例：

1
2
3
4
5
6
7


quick_commands:
 sc:
 type: alias
 target: "/model sonnet --provider openrouter"
 local:
 type: alias
 target: "/model qwen3.5 --provider custom"

注意事项

exec模式不支持参数模板（比如 {args}），就是固定命令
alias模式会自动传递用户输入的额外参数
命令超时30秒自动终止
执行优先级：内置命令 > Quick Commands > Skill命令
Gateway（微信/Telegram等）也能用，直接输入 /gpu 即可

3. 模型别名：一句话切模型

类比：你有一堆门钥匙（不同AI模型），每次开锁都要翻半天找。模型别名就是给每把钥匙贴了标签——喊"opus"就知道用哪把。

实际用途：

/model opus → 切到Claude Opus处理复杂代码
/model sonnet → 切到Claude Sonnet做日常对话
/model ds → 切到DeepSeek省钱
/model glm → 切到国产GLM模型

配置方法

方式一：完整格式（在 ~/.hermes/config.yaml 中）

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


model_aliases:
 opus:
 model: claude-opus-4-6
 provider: anthropic
 sonnet:
 model: claude-sonnet-4-20250514
 provider: anthropic
 ds:
 model: deepseek-chat
 provider: deepseek
 glm:
 model: glm-5.1
 provider: zai
 base_url: "https://open.bigmodel.cn/api/coding/paas/v4"
 local:
 model: qwen3.5:397b
 provider: custom
 base_url: "http://localhost:11434/v1"

方式二：简写格式（provider/model格式）

1
2
3
4


model:
 aliases:
 ds-flash: deepseek/deepseek-v4-flash
 local-qwen: qwen3.5:397b

使用方法

在聊天中直接输入：

1
2
3


/model opus # 切到Claude Opus（仅当前会话）
/model sonnet # 切到Claude Sonnet
/model --global glm # 全局切换到GLM（所有会话生效）

内置别名（不用配就能用）

Hermes自带了一批模型目录别名，输入关键词就能匹配到该厂商最新版本：

别名	对应模型家族
sonnet	Claude Sonnet系列
opus	Claude Opus系列
haiku	Claude Haiku系列
gpt5	GPT-5系列
o3 / o4	OpenAI推理模型
gemini	Google Gemini系列
deepseek	DeepSeek系列
glm	智谱GLM系列
qwen	通义千问系列
kimi	Kimi（月之暗面）

这些是模糊匹配——输入"sonnet"会自动找到Anthropic最新的Sonnet版本。你自己的别名（model_aliases）优先级更高，会覆盖内置的。

切换逻辑

当你输入 /model opus 时：

先查你的 model_aliases 配置（精确匹配）
再查 model.aliases 配置（简写格式）
最后查内置目录别名（模糊匹配，自动找最新版本）

4. 凭据池轮换：多个API Key自动切换

类比：你一个人去自助餐厅，只有一个盘子，每次拿菜都要排队。凭据池就是给你发了多个盘子——一个被限流了（排队的厨师说"你等会儿"），自动换下一个。不耽误吃饭。

实际用途：

OpenRouter单个Key被限流？自动换下一个
Claude API额度用完？切到备用Key继续
多个provider混用？自动选最优

添加凭据

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


# 添加API Key类型的凭据
hermes auth add openrouter # 交互式输入API Key
hermes auth add anthropic --type api_key # 指定类型
hermes auth add openrouter --label "主号" # 加标签方便管理

# 查看已有凭据
hermes auth list
hermes auth list openrouter # 查看某个provider的凭据

# 移除凭据
hermes auth remove openrouter 0 # 按序号移除
hermes auth remove openrouter my-label # 按标签移除

# 重置限流状态（Key被标记为exhausted后手动恢复）
hermes auth reset openrouter

轮换策略配置

在 ~/.hermes/config.yaml 中：

1
2
3
4
5


credential_pool_strategies:
 anthropic: round_robin  # 轮询：挨个用，雨露均沾
 openrouter: random  # 随机：随便挑一个
 openai-codex: least_used  # 最少使用：挑调用次数最少的
 # 不配 = fill_first（默认）

策略	行为	适用场景
`fill_first`	用第一个直到用完，再换下一个	有主备Key的场景
`round_robin`	轮着用，每次选下一个	均匀分摊用量
`random`	随机选一个	不在乎分布，只要不被限流
`least_used`	选调用次数最少的	想最大化利用每个Key

限流自动恢复

不用你管，Hermes会自动处理：

错误类型	冷却时间	恢复方式
401（认证失败）	5分钟	自动跳过，用其他Key
429（限流）	1小时	自动跳过，用其他Key
402（余额不足）	1小时	自动跳过

冷却期过了之后，Key会自动恢复到可用状态。

支持的Provider

OAuth类型（浏览器授权）：anthropic、nous、openai-codex、qwen-oauth、google-gemini-cli

API Key类型（直接填Key）：openrouter、deepseek、zai、kimi、stepfun、moonshot、minimax、xai、gemini、copilot、bedrock、nvidia等

Custom类型：custom:名称，从你的custom_providers配置自动生成

完整配置示例

一个真实的多Key配置长这样：

1
2
3
4
5
6


credential_pool_strategies:
 anthropic: round_robin
 openrouter: random

# 凭据存在 ~/.hermes/auth.json，不要手动编辑
# 用 hermes auth 命令管理

然后：

1
2
3
4
5
6
7
8


# 添加3个OpenRouter Key
hermes auth add openrouter --label "OR-主号"
hermes auth add openrouter --label "OR-备用1"
hermes auth add openrouter --label "OR-备用2"

# 添加2个Anthropic Key
hermes auth add anthropic --type api_key --label "AN-主号"
hermes auth add anthropic --type api_key --label "AN-备用"

配完之后，hermes auth list 看一眼：

1
2
3
4
5
6
7
8


OpenRouter:
 [0] OR-主号 (ok) requests: 847
 [1] OR-备用1 (ok) requests: 823
 [2] OR-备用2 (exhausted, resets in 23min) requests: 891

Anthropic:
 [0] AN-主号 (ok) requests: 156
 [1] AN-备用 (ok) requests: 148

被限流的Key会标 (exhausted)，倒计时结束自动恢复。你什么都不用做。

4个配置怎么搭着用

我自己的搭配：

场景	配置组合
日常开发	Quick Commands查状态 + 模型别名随时切模型
重要操作	Shell Hooks拦截危险命令 + 自动格式化
长时间跑任务	凭据池轮换防限流 + Hooks记录操作日志
团队协作	pre_tool_call Hook统一检查 + 凭据池共享Key池

改完之后最明显的变化

Shell Hooks：之前AI偶尔会跑一些我不确定的命令，现在危险操作自动拦截，格式化自动执行，省心了。

Quick Commands：以前查个GPU状态要跟AI说一句话，花几百Token。现在 /gpu 两个字搞定，零成本。

模型别名：以前切模型要改配置文件重启。现在 /model opus 一行搞定，复杂任务用贵的，日常用便宜的，省钱又灵活。

凭据池：这个最香。之前单个Key被限流就得干等，现在配了3个OpenRouter Key轮着用，基本没遇到429了。

写在最后

4个配置，按需选用。不需要一次全上——先从Quick Commands和模型别名开始，这两个最简单、最直觉。等熟悉了再加Shell Hooks和凭据池。

配置文件位置：~/.hermes/config.yaml，照着上面改就行。

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

上一篇8个基础配置还没改的，先去改那个。基础不牢，进阶白搭。

装完 Hermes Agent 就完事了？这8个配置不改，白装了

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

装完 Hermes Agent，兴冲冲跑起来，结果动不动卡死、账单蹭蹭涨、隐私信息全写在日志里——你不是一个人。改8个配置，5分钟搞定，用起来完全两个世界。

先说结论

Hermes Agent 装好之后的默认配置，是给"能跑就行"设计的，不是给你最佳体验设计的。我翻了一整天文档和源码，筛出8个必改配置。改完之后：

省钱——长对话不再重复烧钱，同样的内容不用来回发两遍
省心——AI不会在同一个错误上死循环
安全——隐私信息自动脱敏，日志干干净净
更聪明——复杂任务能拆得更细，简单问题自动用便宜模型

一张表先给你看全貌：

配置项	改前	改后	效果
忙时输入模式	interrupt（打断式）	steer（追加式）	执行中可随时追加指令
缓存时间	5分钟	1小时	长对话省钱省时间
工具断路器	没开	开启	防止死循环烧钱（3次警告，8次硬停）
子任务深度	1层	2层	复杂任务拆得更细
子代理工具集	3项基础工具	+浏览器	子代理能力更强
隐私脱敏	关闭	开启	日志不泄露隐私
安全扫描	关闭	开启	防止危险自动化
智能模型路由	关闭	开启	简单问题用便宜模型

下面一个一个说。

必改的8个配置

1. 忙时输入模式：从"打断式"改成"追加式"

类比：你在餐厅点菜，厨师正在做你的红烧肉。默认模式下，你突然喊"加个蛋"，厨师会把锅里的肉倒掉，重新开始做。改成steer模式后，厨师会先把红烧肉做完，再做你的蛋——两不耽误。

默认：interrupt——你中途插话，AI会立刻停下手头的活，处理新指令。改成：steer——你的新指令排进队列，AI忙完手上的再处理。效果：AI在执行复杂任务（比如批量改文件）时，你可以随时补充需求，不用干等它做完再说。

配置方法：在 ~/.hermes/config.yaml 中：

1
2


display:
 busy_input_mode: steer  # 默认是 interrupt

2. Prompt缓存时间：从5分钟拉到1小时

类比：每次去图书馆查资料，默认模式下你每次都得重新办借书证。拉长缓存后，一天内只需要办一次。

默认：5分钟——超过5分钟，AI会把系统提示词（System Prompt，就是告诉AI"你是谁、该怎么做"那段话）重新发送一遍，重新算钱。改成：1小时。效果：长对话中，重复的系统提示词不再每次重发。别小看这个，系统提示词通常有好几千字，来回发一次就是几毛钱。一天聊下来，能省不少。

配置方法：

1
2


prompt_caching:
 cache_ttl: 1h  # 默认是 5m

3. 工具循环断路器：必须开

类比：你让AI去隔壁房间拿东西，门锁了它打不开。默认行为是——它会在门口一直拧把手，拧到你破产。断路器就是：试两次打不开就喊你，别搁那拧了。

默认：没有断路器。同一个工具（比如搜索、读写文件）调用失败，AI会无限重试。改成：连续失败3次警告，8次硬停。效果：尤其在定时任务（Cron Job，让AI定时自动执行的任务）场景下，这个配置能救命。不然你睡一觉起来，AI在某个报错上循环了一整夜，账单直接起飞。

配置方法：

1
2
3
4
5
6
7


tool_loop_guardrails:
 warnings_enabled: true
 hard_stop_enabled: true
 warn_after:
 same_tool_failure: 3 # 同一工具失败3次后警告
 hard_stop_after:
 same_tool_failure: 8 # 同一工具失败8次后强制停止

4. 子任务嵌套深度：从1层改成2层

类比：你是项目经理，默认情况下你只能把任务分给下属，下属不能再往下分。改成2层后，下属也能往下再分一级——任务拆得更细，执行更高效。

默认：1层——AI的总指挥（负责分配任务的主代理）不能再往下派子任务。改成：2层。效果：比如你说"帮我调研竞品A"，AI可以拆成"搜网页"+“读文档"两个子任务，分别执行后再合并。1层模式下做不了这种拆分，复杂任务容易翻车。

配置方法：

1
2


delegation:
 max_spawn_depth: 2 # 默认是 1

5. 子代理工具集：加上浏览器操作

类比：你派了个助手出去办事，默认只给他纸笔和电话。加上浏览器操作，等于又给他配了台电脑——能做的事多了不止一倍。

默认：子代理只能用终端（Terminal，命令行操作）、文件操作、网页请求这三样。改成：加上浏览器（Browser）操作能力。效果：子代理也能直接操作浏览器，比如打开网页、点击按钮、截图。不用每次遇到需要浏览器的操作都扔回主代理，效率直接翻倍。

配置方法：

1
2
3
4
5
6


delegation:
 default_toolsets:
 - terminal
 - file
 - web
 - browser  # 默认没有这一项

6. 隐私脱敏：必须开

类比：你让AI帮你整理通讯录，默认情况下，你朋友的手机号、你的身份证号会原样出现在日志里。开了脱敏后，这些信息会自动变成"138****5678"这种格式。

默认：关闭。日志和上下文中明文存储所有隐私信息。改成：开启。自动检测并脱敏手机号、身份证号等PII（Personally Identifiable Information，个人身份信息）。效果：你的 Hermes 日志文件里不会出现任何明文隐私数据。尤其是多人共用服务器的情况，这个不开就是在裸奔。

配置方法：

1
2


privacy:
 redact_pii: true # 默认是 false

7. Skill安全扫描：必须开

类比：AI学会了新技能，默认情况下它想怎么用就怎么用，没人管。安全扫描就是给AI的新技能加了一道"审核”——有风险的技能会被拦下来。

默认：关闭。AI自动创建的技能（Skill，AI根据需要自己写的自动化脚本）不过安全检查。改成：开启。效果：AI自己创建的自动化脚本会先过安全检查，比如检测是否有删文件、发网络请求等高风险操作。防止AI"好心办坏事"——它以为在帮你，其实把重要文件删了。

配置方法：

1
2


skills:
 guard_agent_created: true # 默认是 false

8. 智能模型路由：能省一大笔钱

类比：你去医院，感冒看普通门诊就行，不用挂专家号。智能模型路由就是给AI配了个"分诊台"——简单问题用便宜模型，复杂问题才上贵的。

默认：关闭。所有问题都用你配置的那个模型，不管简单还是复杂。改成：开启。效果：举几个例子你就懂了——

“今天几号”→ 用0.01元的模型
“帮我写封邮件”→ 用0.05元的模型
“帮我重构这段代码”→ 才用2元的模型

一天下来，账单能砍一半以上。

配置方法：

1
2
3
4
5
6
7


smart_model_routing:
 enabled: true # 默认是 false
 max_simple_chars: 160 # 超过160字不走便宜模型
 max_simple_words: 28 # 超过28个词不走便宜模型
 cheap_model: # 填你的便宜模型
 provider: your-provider
 model: your-cheap-model

进阶玩家可以看这些

上面8个是所有人装完都应该改的。如果你是进阶玩家，还有几个值得折腾：

Shell Hooks：用shell脚本拦截工具调用。比如每次AI要执行命令时，先跑你的检查脚本。不需要写Python，会写shell就行。
Quick Commands：零Token快捷命令。输入 /status 直接执行系统命令，不经过AI，不花钱。
模型别名：在聊天中输入 /model opus 一键切换模型，不用去改配置文件。
凭据池轮换：配多个API Key（接口密钥），自动轮换使用，防止单个Key被限流。

这些配置改起来稍微复杂，后续我会单独写一篇展开讲。

改完之后我的变化

最明显的是省钱。改之前我日均消耗大概在15元左右，改完智能路由+缓存时间，直接降到6-7块。一个月省下来两百多，够吃好几顿外卖了。其次是不卡了。之前AI动不动就在某个报错上死循环，得手动停掉重来。开了断路器之后，再没遇到过这种情况。最后是放心了。隐私脱敏和安全扫描这两个，属于"不出事感觉不到，出事就晚了"的配置。改完之后看日志，干干净净，心里踏实。

写在最后

8个配置，全部加起来改5分钟。但这5分钟，决定了你的 Hermes 是"能用"还是"好用"。大多数人装完就跑，然后觉得"Hermes 也就那样"——不是 Hermes 不行，是你没调好。配置文件位置：~/.hermes/config.yaml，照着改就行，不用动脑子。

关注varkm，回复【配置】获取完整的 config.yaml 优化模板，直接复制粘贴，一键搞定。

觉得有用就转给你那个装了 Hermes 但天天骂它不好用的朋友。