Ai-Agent 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 实战经验和踩坑记录，持续更新中

踩过的坑全给你：Blog Agent 最佳实践

Wed, 20 May 2026 00:00:00 +0800

跟着前三篇搭完 Pipeline，满怀信心跑了一次——然后各种炸。这篇文章是我踩了 50+ 个坑之后，精选出 12 个最致命的。

多Agent协作系列第4篇/共4篇（收尾篇） | 避坑指南 | 约2800字 | 作者：varkm

先说结论

踩了 50 多个坑，80% 集中在五个环节。

我把最致命的 12 个挑出来，按"写→排→配→协→省"五个阶段给你。

每个坑都附具体命令和代码。

不是"建议你检查一下"，是"复制这条命令就能验证"。

一、写作篇：Agent 写的东西能看吗

内容质量不是模型能力问题，是验证流程问题。

Writer 写什么不重要，Reviewer 能拦住什么才重要。

坑1：子代理编造不存在的配置键名

这是最致命的一个坑，没有之一。

子代理会"幻觉"出看似合理的配置键名。

比如 tool_circuit_breaker，听起来很专业对吧？

源码里根本没有这个键。正确的叫 tool_loop_guardrails。

读者拿去配，白配。文章发出去，评论区翻车。

类似的情况还有：busy_input_mode 实际叫 display.busy_input_mode。

prompt_cache_ttl 实际叫 prompt_caching.cache_ttl。

验证方法——每个键名必须过这关：

1

grep -rn "键名" hermes_cli/config.py

不存在就不要写，哪怕 AI 信誓旦旦说"我确认过"。

这条规则我写进了 Reviewer 的检查清单，至今拦住了 20+ 次编造。

坑2：AI 味套话满天飞

“值得注意的是”、“总的来说”、“首先…其次…最后”。

这些话一出现，读者秒懂：AI 写的。

解法： 把 AI 味关键词清单写进 Reviewer 的规则文件。

逐段扫描，强制替换为自然过渡。

不是零容忍——允许 1-2 处漏网，但多了必须打回重写。

我维护了一份清单，大概 15 个高频 AI 味词组。

每次审校先跑一遍关键词扫描，比人工逐段看效率高 10 倍。

坑3：评测文事实核查翻车

“发布不到一个月”——实际仓库已创建 3 个月。

“不支持 Docker”——仓库里 Dockerfile 就在根目录。

“我两个都在用”——说实话，根本没用过第二个。

这条最危险，因为读者会去验证。一旦翻车，信任归零。

核心原则： 每一条事实声明都必须验证。

星数看 GitHub API，技术栈看源码，体验只写真话。

验证命令：

1
2


curl -s https://api.github.com/repos/owner/repo \
 | jq '{stars: .stargazers_count, created: .created_at}'

版本追溯三步法：

1
2
3


git log --oneline --all --grep="功能名" | head -5
git tag --contains <commit_hash> | head -3
git show --no-patch --format="%H %ci %s" <commit_hash>

写作篇一行检查：grep -rn "配置键名" config.py

二、排版篇：微信客户端是最大的敌人

微信渲染引擎会做你意想不到的事。

所有样式必须 inline，微信会剥离 <style> 和 class。

这是排版篇的第一条铁律，后面所有坑都跟它有关。

坑4：列表标签全线崩溃

<ul>、<ol>、<li>，三个标签在微信里有三个独立 bug。

<ol> 编号跨板块连续计数：第一个列表从 1 开始没问题。

第二个列表不从 1 开始，接着上一个的编号往下数。

<ul> 加手动 bullet 产生双圆点，一行出现两个点。

<li> 的 margin 产生空行，每个 item 变成空行 + 内容两行。

我在这三个标签上各踩了一轮，前后折腾了两天。

终极方案： 全部不要用。

所有列表统一用 ◆ 替代：

1
2


<p style="margin:4px 0;line-height:1.8;
padding-left:14px;">◆ 列表内容</p>

简单、稳定、不炸。这是 3 轮踩坑之后的终极结论。

坑5：代码块黑底黑字

微信会剥离 <pre> 标签的 color 样式，只剩 background。

黑色背景 + 黑色文字 = 完全看不了。

读者截图问我"代码块怎么什么都没有"。

我才知道这个坑——在电脑浏览器里是正常的。

解法： 永远不要用深色代码块背景。

浅色方案用 <section> 包裹：

1
2
3
4
5
6


<section style="background:#f6f8fa;
border-radius:6px;padding:14px;
border:1px solid #e1e4e8;">
<pre style="margin:0;color:#24292e;
font-size:14px;">代码内容</pre>
</section>

关键是用 <section> 而不是直接靠 <pre> 的样式。

深色方案也可以，但同样必须用 <section> + <span> 做语法高亮。

坑6：封面图中文变方格

Pillow 默认字体（DejaVu）不支持中文。

所有中文字符渲染成方格/空白。

发出去才知道——封面上的标题全是空白方块。

解法： 必须用系统 CJK 字体，且 .ttc 文件要加 index=0：

1
2
3
4
5
6


from PIL import ImageFont
font = ImageFont.truetype(
 "/usr/share/fonts/opentype/noto/"
 "NotoSansCJK-Bold.ttc",
 36, index=0
)

.ttc 是字体集合文件，不指定 index 可能加载到错误字体。

这个参数踩了我半小时才找到原因。

排版篇一行检查：grep -n '<ul>\|<ol>\|<li>' article.html

三、配置篇：80% 的崩溃来自两个默认值

不是功能不好用，是默认配置没改。

改两个配置，解决 80% 的 Pipeline 崩溃。

坑7：max_tokens 太小导致截断

默认 max_tokens 只有 4096。

一篇 2000 字的文章大概需要 8000-12000 token。

超了直接截断，Agent crash，日志显示：

1
2


Response truncated (finish_reason='length')
refusing to execute incomplete tool arguments

解法： Profile 配置里改成 32768 或更大：

1
2


model:
 max_tokens: 32768

Worker 自己改不了这个值。

必须由 Orchestrator 在 Profile 配置文件里提前设好。

算笔账： 一次跑完 vs 截断重跑。

截断一次 = 浪费已消耗的 token + 重新跑一遍完整流程。

max_tokens 调大，单次不会多花，但省掉了重试的浪费。

坑8：Skill 文件没复制到 Profile 目录

全局 skill 目录和 Profile 独立目录是两套。

Profile 看不到全局目录里的 skill，必须手动复制。

报错信息：

1

Error: Unknown skill(s): article-review

明明装了，为什么找不到？因为装错地方了。

解法： Orchestrator dispatch 前检查并复制：

1
2


cp -r ~/.hermes/skills/devops/article-review \
 ~/.hermes/profiles/blog-writer/skills/devops/

路径规则：全局 ~/.hermes/skills/ ≠ Profile 独立目录。

我第一次遇到这个报错时，反复重装了 3 遍 skill 才反应过来。

装的全是全局目录，Profile 根本看不到。

这两个配置改完，80% 的 Pipeline 崩溃直接消失。

配置篇一行检查：grep "max_tokens" ~/.hermes/profiles/你的profile/config.yaml

四、协作篇：Agent 编排的三个反模式

Pipeline 不是流程负担，是质量保险。

跳过的每一步，都会在下游加倍还回来。

坑9：跳过 Pipeline 裸写

手动 delegate_task 直接让一个 Agent 写文章，没有 Reviewer。

看起来快，实际上：

对比项	Pipeline	裸写
Reviewer 把关	有	无
审计链路	有	无
返工次数	1-2 次	3-5 次
总耗时	16 分钟	30+ 分钟

裸写最大的问题不是质量差。

是你不知道质量差——没有 Reviewer 告诉你哪里有问题。

等读者反馈，已经晚了。

我写过一篇裸写的文章，3 个配置键名编造，2 处 AI 味套话。

没有 Reviewer 拦，全发出去了。后来评论区被指出才改。

强制规则： 走完整 Kanban Pipeline，无例外。

流程：Writer → Reviewer → Creator → Reviewer → 发布。

坑10：task_id 幻觉编造

kanban_complete 时传入编造的 task_id。

kernel 验证不通过，直接报错：

1

phantom id blocks the completion

核心： task_id 只能来自 kanban_create 的返回值。

不要从文字描述里"编"，不要从上一轮的上下文里"猜"。

正确写法——先捕获返回值，再传入：

1
2
3
4
5
6


card = kanban_create(
 title="审校文章", assignee="reviewer"
)
kanban_complete(
 created_cards=[card["task_id"]]
)

错误写法：从摘要中看到 “t_deadbeef” 就传进去。

kernel 会验证每个 id 是否真实存在，幻编的 id 100% 被拦截。

坑11：Reviewer 模型比 Writer 弱

Writer 用最强模型写，Reviewer 用弱模型审。

结果：审校形同虚设，该拦的拦不住。

规则： 审核模型必须 ≥ 写作模型。

角色	推荐模型	定位
Writer	glm-4.7	性价比写稿
Creator	glm-4.7	排版生成
Reviewer	glm-5.1	强模型把关

贵的模型只干贵的事——审核就是最该花 token 的环节。

五、成本篇：怎么让 Agent 省着花

不是不能用贵模型，是别在不需要的地方用。

坑12：Pipeline 被反复"跳过"

完整 Pipeline 6 步全 PASS 只需 16 分钟。

但经常有人觉得"Pipeline 慢"，手动跳过。

跳过的后果：质量不过关 → 返工 → 再跑一遍 → 总耗时翻倍。

不要跳。 16 分钟换一次通过，比跳过之后返工 30 分钟划算。

分层用模型才是真省钱

全文用一个模型 = 全程用最贵的模型 = 浪费。

写作用性价比模型，快且便宜。

排版用同样的性价比模型。

审核用强模型，只审核一次。

贵模型用得少，但每次用在关键位置。

max_tokens 调大 + 模型分层，总成本反而比"省钱方案"更低。

具体算一下：Writer 跑 5 分钟用 glm-4.7，Reviewer 跑 2 分钟用 glm-5.1。

比全程用 glm-5.1 省 60% 以上 token。

该省省，该花花——审核环节绝不省钱。

系列 4 篇收尾

回顾整个多Agent协作系列：

第 1 篇 讲了 Kanban + Profile，让 Agent 有了分工和身份。

Kanban 是任务看板，Profile 是 Agent 的角色配置。

两者结合，Agent 从"什么都干"变成"各司其职"。

第 2 篇 搭建了 Blog Writer Agent，7 步从零到能写能部署。

从安装框架到写第一篇文章，全程可跟着操作。

第 3 篇 组建了完整 Pipeline，多 Agent 协作链路跑通。

Writer 写稿 → Reviewer 审校 → Creator 排版 → 发布。

6 步全 PASS 只需 16 分钟。

第 4 篇（这篇）补上了最后一环：搭完怎么不炸。

12 个坑，5 个阶段，每个都有具体命令和代码。

收藏这篇，每次跑 Pipeline 之前扫一遍检查清单。

四篇读完，你就有了一套完整的 Agent 博客系统。

从搭建到协作到避坑，该踩的坑我都替你踩了。

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

多Agent协作系列完更，回复【agent】获取完整检查清单和 Profile 配置模板

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

AI Agent 会话管理实战：3条命令搞定多任务切换

Sun, 17 May 2026 22:57:00 +0800

先说结论

AI 助手聊到一半，突然想起另一件事，怎么办？

大多数人直接在同一个对话里追问。结果就是：上下文被无关内容塞满，AI 开始"串台"，之前聊的东西也找不回来了。

解决方案就三条命令：

1
2
3


/title 博客开发 ← 给当前对话起个名字
/new ← 开一个全新对话
/resume 博客开发 ← 随时切回来继续

下面展开说说。

痛点：所有话题混在一个对话里有多灾难

跟 AI 助手聊久了，你是不是也遇到过这些情况：

聊着写代码，突然想问网络诊断，但切了话题之前的代码上下文就没了
一个对话塞了十几个话题，AI 回复开始串上下文，把 A 任务的信息用到 B 上
上周聊过的东西，翻半天记录也找不到

本质问题是：AI 的上下文窗口是有限的。所有话题挤在一起，有用信息被稀释，AI 的回答质量直线下降。

核心命令：会话切换三件套

在微信、Telegram、Discord 等所有聊天平台都能用：

命令	作用	示例
`/title 名称`	给当前会话命名	`/title 博客迁移`
`/new`	创建全新会话，当前会话保留	`/new`
`/resume 名称`	恢复之前命名的会话	`/resume 博客迁移`

再加一条查看命令：

命令	作用
`/sessions`	列出所有历史会话（含标题、预览、最后活跃时间）

典型工作流：A → B → 回 A

1
2
3
4
5
6
7


/title 博客文章 ← 给当前任务 A 命名
...写文章中...
/new ← 切到全新会话
/title 网络诊断 ← 开始任务 B
...修网络中...
/resume 博客文章 ← 切回 A，上下文完整保留
...继续写...

其他实用命令

除了会话切换，还有几个高频命令：

对话控制：

命令	作用
`/retry`	重试上一条回复（不满意就重来）
`/undo`	撤回上一轮对话
`/stop`	终止正在运行的任务
`/compress`	手动压缩上下文（长对话变卡时用）

信息查看：

命令	作用
`/status`	查看当前会话信息
`/model`	切换模型
`/usage`	查看 token 用量
`/help`	查看所有可用命令

高级功能：

命令	作用
`/branch` 或 `/fork`	从当前对话分叉，探索不同方向
`/goal`	设置跨轮次的持续目标
`/background` 或 `/bg`	后台运行任务

/new 的别名是 /reset，效果一样。 /background 还可以用 /btw 触发。

实战场景

场景 1：多任务并行

我日常最常用的模式——同时推进多个任务：

1
2
3
4
5
6
7
8
9


/title 博客文章
...写了一半...

/new
/title 服务器监控
...查了下告警...

/resume 博客文章
...继续写，之前的上下文都在...

关键点：每次切走之前先 /title，不命名的话恢复时只能靠 /sessions 手动找。

场景 2：长对话变卡

一个会话聊了太多次，AI 开始"忘记"前面的内容：

1

/compress ← 压缩上下文，释放空间

AI 会自动总结已有对话，腾出上下文窗口给后续对话。

场景 3：试错探索

对 AI 的回答不满意，想试另一个方向，但不想丢失当前进度：

1
2
3


/branch 方案B ← 从当前位置分叉
...试了方案B...
 ← 不满意的话，原对话还在

CLI 用户额外福利

终端模式下还有几个独有命令：

命令	作用
`/clear`	清屏 + 新建会话
`/history`	查看完整对话历史
`/save`	保存当前对话
`/snapshot`	创建/恢复状态快照
`/handoff`	把 CLI 会话移交到聊天平台

这些在微信等聊天平台不可用，只在终端 CLI 模式下支持。

小结

会话管理不是花架子，是真正影响 AI 使用效率的核心能力。记住这三条：

命名：/title 给每个任务打标签
切换：/new 开新话题，老话题自动保留
恢复：/resume 随时切回，上下文完整

养成习惯后你会发现：AI 不再串上下文了，之前聊过的东西随时能找回，多任务并行变得非常自然。

给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能记住你说过的每一句偏好，你就不需要每次对话都从头开始。

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，但方向是对的。

装完 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 但天天骂它不好用的朋友。