Hermes on 火炬树

Hermes Kanban：让多个 AI Agent 像团队一样协作

Sun, 07 Jun 2026 07:24:48 +0800

Kanban 是什么

Hermes Agent 是一个开源 AI Agent 框架，支持在终端、Telegram、Discord、Slack 等多个平台上运行。它的 Kanban 功能是一套持久化的多 Agent 协作任务板，让多个独立的命名 Agent（在 Hermes 中称为 profile）通过共享的任务队列协同工作，无需依赖脆弱的进程内子代理调度。

每条任务是 SQLite 数据库中的一行记录，每次交接是任何人都可读写的持久数据，每个 worker 都是一个拥有独立身份和记忆的完整操作系统进程。这和 Hermes 原有的 delegate_task（一次性函数调用式子代理派发）形成互补：delegate_task 适合快速的一问一答，Kanban 适合需要持续状态、多角色接力、人类介入的工作流。

它能做什么：从一个真实场景说起

假设你需要写一篇技术调研报告。传统做法是让一个 AI Agent 从头做到尾，结果往往是：调研深度不够、写作风格单一、中间方向偏离无人纠正。

用 Kanban，流程变成这样：

你创建一个 triage 状态的任务：“调研 Hermes Kanban 功能，形成一篇面向开发者的分析报告”
系统的自动编排器（decomposer）将它拆解为三个子任务：researcher 做信息采集、analyst 做综合分析、writer 负责成文
两个 researcher 子任务并行执行，各自负责不同信息源
它们完成后，analyst 自动启动，读取两份调研结果进行综合
analyst 完成后，writer 启动，基于综合结果撰写报告
整个过程中，你随时可以评论、调整方向、阻塞等待决策
最终产出包含完整的审计轨迹：谁做了什么、花了多久、中间经历了几次迭代

这不是概念设想，而是 Kanban 的标准工作模式。

Kanban 的核心概念有哪些

Kanban 由六个相互协作的组件构成。

**Board（看板）**是独立的任务队列，拥有自己的 SQLite 数据库、工作目录和调度循环。单次安装可以创建多个 board，按项目或领域隔离。

**Task（任务）**是看板中的基本单元，包含标题、正文、一个 assignee（指派的 profile 名称）、状态流转链（triage → todo → ready → running → blocked → done → archived），以及可选的 tenant 命名空间和幂等键。

**Link（依赖）**记录任务之间的 parent → child 关系。当所有父任务完成后，子任务自动从 todo 提升为 ready，由调度器拾取执行。这实现了"扇出 + 扇入"的并行编排。

**Comment（评论）**是 Agent 之间的通信协议。Agent 和人类都可以追加评论，worker 被（重新）调度时会读取完整的评论线程作为上下文。这本质上是任务维度的对话通道，不依赖主聊天的上下文窗口。

**Workspace（工作空间）**是 worker 操作的目录。scratch 是临时目录，任务完成后自动清理；dir:<path> 指向一个现有的持久目录；worktree 是 Git worktree，适合编码任务。

**Dispatcher（调度器）**是长驻循环，默认每 60 秒执行一轮：回收过期 claim → 检测崩溃的 worker → 提升 ready 任务 → 原子认领 → spawn 分配的 profile。它运行在 Hermes Gateway 进程内部，不需要单独管理。

人类如何介入 Agent 的工作过程

Kanban 和纯自动化批处理的根本区别在于，它在工作流的每个阶段都留了人类介入的入口。

入口控制（Triage）：任务可以创建在 triage 状态，相当于一个"停车场"。你可以先审视任务描述是否清晰、拆解是否合理，再决定是否推进到执行队列。

执行中阻塞（Block/Unblock）：Worker 在执行过程中遇到需要人类判断的决策时，会调用 kanban_block 主动暂停。例如翻译任务中遇到专业术语需要确认，或者技术方案需要你选择方向。你做出决策后通过 unblock 解除阻塞，worker 继续执行。

持续评论（Comment）：你随时可以往任务线程中追加评论，比如"请用中文写作，控制在 3000 字以内"或"这个方向不对，请参考 X 的做法"。Worker 下次被调度时会读取这些评论。

产出审查（Runs）：每次执行尝试都记录在 task_runs 表中。你可以查看每次尝试的耗时、结果摘要、错误信息，不满意可以修改任务描述后重新调度。

Goal 模式的验收标准：创建任务时指定验收标准，worker 会在每轮结束后自检是否满足。写得越明确，产出越可控。

Kanban 支持哪些协作模式

Kanban 不是一种固定的编排方式，而是支持多种协作模式的基础设施。官方文档列出了九种典型模式：

模式	形状	场景示例
Fan-out	N 个同角色并行	同时调研 5 个技术方案
Pipeline	角色链式接力	采集 → 分析 → 写作 → 审查
投票/仲裁	N 并行 + 1 汇总	3 个研究员 → 1 个审查员综合
长期日志	同 profile + 共享目录 + cron	每日自动生成 Obsidian 日记
人机交互	worker block → 人类 comment → unblock	需要决策确认的任务
@mention	行内路由	在评论中 @reviewer 请求审查
线程 workspace	每个聊天线程一个独立看板	多项目并行管理
Fleet farming	一个 profile 管理 N 个对象	同时管理 50 个社交账号
Triage specifier	一行想法 → 系统展开为完整任务规格	快速捕捉粗略想法

任务如何分配给不同 Agent

Kanban 不要求必须有多个 profile。单个 profile 就能使用，此时它就是一个带持久化、可重试、可审计的工作队列。多 profile 是为了专业分工。

任务分配有三种精度档位：

手动指派：创建任务时显式指定 --assignee <profile-name>，你完全控制谁做什么。

Orchestrator 自动分配：Orchestrator agent 读取你的 profile 列表和描述，根据任务内容决定分配给哪个 profile。精度取决于 profile 描述的质量。

Auto-decomposer：triage 任务进入后，系统使用辅助 LLM 读取 profile roster，自动拆解为子任务图并路由到最合适的专家。如果 LLM 选了一个不存在的 profile，任务会 fallback 到默认 assignee。

两个入口，同一个数据库

Kanban 的设计有一个重要的架构选择：它有两套操作界面，但后端共享同一个 SQLite 数据库。

Agent 通过工具调用：dispatcher spawn 每个 worker 时，自动在模型的 schema 中注入 kanban_* toolset（kanban_show、kanban_complete、kanban_block 等）。Worker 直接调用这些工具，不走命令行。这样做的好处是：无论 worker 的终端后端是本地、Docker 还是 SSH 远程，工具调用始终能访问到数据库；结构化 JSON 参数避免了 shell 引号问题；普通聊天会话零 schema 占用。

人类通过 CLI 或斜杠命令：hermes kanban create/list/show/... 或在聊天平台中 /kanban create/list/show/...。参数格式完全相同，两个入口的读写结果一致。

此外还有一个 Dashboard GUI，提供拖拽式看板界面，支持内联创建、多选批量操作、依赖编辑、实时 WebSocket 更新。

什么场景适合用 Kanban

Kanban 的适用边界可以用一句话划清：当你需要的不只是一个答案，而是一条有状态、可中断、可追溯的工作流水线时，Kanban 才值得启动。

三类任务是它的甜区：

需要多角色接力：研究 → 分析 → 写作 → 审查这种多阶段管道，每个阶段需要不同的专业能力
需要人类中途介入：翻译确认术语、调研调整方向、敏感操作需要审批
需要并行执行 + 结果汇总：N 个同类 worker 同时跑不同子任务，完成后自动触发汇总

反过来说，简单问答、一次性小任务、纯自动化无人值守流水线，用 delegate_task 或 cron 就够了，不需要 Kanban 的额外开销。

与 delegate_task 的对比

这两个能力看起来相似，但定位完全不同：

维度	delegate_task	Kanban
形状	函数调用（fork → join）	持久化消息队列 + 状态机
父子关系	阻塞等子返回	创建后 fire-and-forget
子代理身份	匿名子代理	带持久记忆的命名 profile
可恢复性	失败就失败	block → unblock → re-run；crash → reclaim
人机交互	不支持	任何时候可以 comment / unblock
每任务 agent 数	一次调用 = 一个子代理	N 个 agent 跨任务生命周期
审计追踪	上下文压缩后丢失	永久保存在 SQLite 中

一句话区分：delegate_task 是函数调用；Kanban 是工作队列，每次交接都是任何 profile 或人类可见可编辑的行。

快速上手

从聊天平台操作同样简单：/kanban create "调研 AI Agent 框架生态" --assignee researcher。

参考资料

Hermes Agent 浏览器工具的用户登录实现方案

Wed, 15 Apr 2026 10:42:16 +0800

Hermes Agent 的浏览器工具将身份验证统一纳入常规的页面交互流程，并配合不同后端的状态持久化能力来完成登录态的保持。本文基于 NousResearch/hermes-agent 源码的直接分析，梳理其在处理“需要登录才能访问的网站”时的五种具体操作方案。

一、交互式自动化登录（通用方案）

这是最基础的方案，适用于所有后端。Agent 通过标准的浏览器操作链模拟人类登录：

browser_navigate(url) — 打开登录页
browser_type(ref, text) — 在用户名/密码输入框中填写内容
browser_click(ref) 或 browser_press("Enter") — 点击登录按钮或提交表单
browser_snapshot() — 确认登录是否成功（页面跳转、出现个人中心等）

在 tools/browser_tool.py 的实现中，browser_type 底层调用的是 fill 命令，会先清空输入框再键入文本，避免残留旧内容。这种方式零配置、通用性强，但面对 CAPTCHA、2FA、二维码或强反 bot 检测时容易失败。

对于需要反复访问的登录网站，Hermes 提供了跨任务保留登录态的能力，核心载体是 Camofox 后端。

Camofox 的 Managed Persistence

当环境变量 CAMOFOX_URL 指向本地 Camofox 服务器，并在 config.yaml 中启用持久化：

tools/browser_camofox_state.py 会根据当前 Hermes profile 生成一个**确定性的 ****userId**，并映射到固定本地目录（~/.hermes/browser_auth/camofox/）。Camofox 服务器收到相同 userId 时会复用同一浏览器 profile，因此 cookies、localStorage、IndexedDB 等登录状态可以跨任务保留。

在 tools/browser_tool.py 的清理逻辑中，当 managed persistence 启用时，Agent 会执行 soft cleanup——仅释放本地内存跟踪，不销毁服务端的浏览器上下文，从而确保 session cookies 得以保留。

三、JavaScript 注入（程序化身份验证）

Hermes 的 browser_console 工具支持传入 expression 参数，在页面上下文中执行任意 JavaScript（相当于 DevTools Console）。这允许 Agent 直接：

读取/设置 Cookie：document.cookie = "session_id=xxx"
操作 localStorage：localStorage.setItem('token', 'xxx')
注入 JWT 或 API Token

该能力在 tools/browser_tool.py 的 _browser_eval 中实现，Camofox 后端也提供了对应的 /tabs/{tabId}/eval REST 端点。适用于开发者已拥有用户 session token、需要跳过登录表单的场景。

四、人机协作登录

当遇到强反 bot、CAPTCHA、二维码登录或 SSO 时，Hermes 提供了两种人机协作路径，但二者的交互形态差异很大。

4.1 Camofox + VNC：实时可操作浏览器窗口

这是代码中唯一为人类用户提供了可直接点击、输入、扫码的浏览器界面的方案。

在 tools/browser_camofox.py 中，初始化时会探测 Camofox 服务器的 /health 端点。如果服务器返回 vncPort，Hermes 会将其缓存为 _vnc_url，并在每次 camofox_navigate() 调用后把该地址写入返回结果：

人类用户看到的界面：在自己的浏览器中打开 vnc_url，通常是一个 noVNC Web 客户端，显示远程桌面级别的浏览器窗口。用户可以直接点击按钮、填写表单、扫描二维码、拖动滑块完成 CAPTCHA，也可以观看 Agent 的自动化操作并随时接管。

协作流程：Agent 检测到登录或验证受阻后，会将 vnc_url 发送给用户，随后停止发送浏览器操作指令，等待用户反馈“已完成登录/验证”，再继续后续自动化。如果同时启用了 managed_persistence，用户通过 VNC 登录一次后，后续任务可直接复用该登录态。

4.2 `browser_vision`：截图回传的静态辅助

这是所有后端都可使用的通用方案，但它是单向的。Agent 调用 browser_vision 后，会将当前页面截图保存到本地，并通过 MEDIA:<path> 以图片附件形式发到聊天对话中。

用户只能看、不能点。典型 workflow 是：

Agent 操作到验证页，发现被拦截
Agent 截图并回传，用户看到例如短信验证码输入框
Agent 通过对话询问用户验证码
用户回复数字，Agent 继续用 browser_type 填入

该方案对需要人类直接操作网页元素的场景（如点击“我不是机器人”复选框、拖动拼图、扫码登录）基本无效。

五、连接已登录的现有浏览器（CDP Override）

Hermes 支持通过 BROWSER_CDP_URL 环境变量连接到一个现有的 Chrome DevTools Protocol (CDP) 端点。用户可以：

在本地启动一个普通 Chrome（带 --remote-debugging-port）
手动登录目标网站
将 Chrome 的 CDP websocket 地址交给 Hermes
Agent 直接在该已登录的浏览器实例中执行操作

在 tools/browser_tool.py 中，_get_cdp_override() 会读取该环境变量，_get_session_info() 则会创建对应的 CDP session，完全绕过本地启动和云 provider。

六、安全与防护

在 browser_navigate 的实现中，有一道针对凭据外泄的安全检查。Agent 会解码 URL 并扫描其中是否包含 API key 或 token 前缀，一旦发现即阻断导航：

这防止了 prompt injection 攻击通过导航链接将用户的敏感凭证外泄。

总结

方案	实现方式	最佳适用场景
自动化表单登录	navigate → type → click/press	普通用户名密码登录，无强反 bot
持久化 Profile/Cookie	Camofox managed_persistence	需要长期、反复访问同一网站
JS 注入 Token/Cookie	browser_console(expression=…)	已有 session token，需快速跳过登录
人机协作（VNC 实时）	Camofox 后端 + vnc_url	CAPTCHA、二维码、SSO 等复杂验证
人机协作（截图辅助）	browser_vision + 对话回传	验证码回传等轻协作
连接已登录浏览器	BROWSER_CDP_URL	用户已有登录环境，Agent 仅做后续操作

整体而言，Hermes 的登录策略 = 交互式表单填写 + 后端状态保持 + 人机协作兜底。在默认的本地 agent-browser CLI 后端和云端 Browserbase / Browser Use 后端中，代码层面并未为人类预留可直接操作的浏览器界面；若需真正的实时人机协作，Camofox + VNC 是目前代码中最完整的实现路径。

Hermes Agent Docker 容器化运行完全指南

Mon, 13 Apr 2026 15:39:21 +0800

两种 Docker 交互方式

Hermes Agent 与 Docker 的交互存在两种不同模式，官方文档对此有明确区分：

在 Docker 中运行 Hermes（本文重点）：Agent 本身运行在容器内部，所有用户数据通过挂载卷持久化到宿主机。
Docker 作为终端后端：Agent 运行在宿主机，但具体命令执行在 Docker 沙箱中完成。该模式需通过 terminal.backend 配置启用。

以下讨论均围绕第一种模式展开。

快速开始：三种运行方式

1. 首次初始化（setup 向导）

该命令启动交互式安装向导，将 API 密钥写入 ~/.hermes/.env。此步骤只需执行一次。

2. Gateway 模式（后台常驻）

适用于 Telegram、Discord、Slack、WhatsApp 等消息平台的长期接入。

3. 交互式 CLI 模式

用于临时开启一个聊天会话。

持久化数据目录结构

容器内 /opt/data 映射到宿主机 ~/.hermes/，是 Hermes 所有状态的单一真相源，包含：

路径	内容
.env	API 密钥与秘密
config.yaml	所有 Hermes 配置
SOUL.md	Agent 人格/身份定义
sessions/	对话历史
memories/	持久化记忆
skills/	已安装技能
cron/	定时任务定义
hooks/	事件钩子
logs/	运行时日志
skins/	自定义 CLI 皮肤

容器化运行 vs 宿主机直接运行

容器化的主要优势

优势	说明
环境一致性	官方镜像已预装 Python、Node.js、Playwright + Chromium、ripgrep、ffmpeg、WhatsApp bridge 等全部依赖，宿主机运行则需手动配置虚拟环境与浏览器。
依赖隔离	Hermes 的 Node 版本、Playwright 浏览器二进制等不会与宿主机其他项目冲突。
无状态升级	镜像本身无状态，所有数据保存在挂载目录。升级时只需 docker pull 新镜像即可，不丢失配置。
资源可控	可通过 –memory、–cpus 明确限制容器资源，防止浏览器自动化或长任务耗尽宿主机资源。
可移植性	备份 ~/.hermes 目录后，可在任意机器上通过相同挂载命令快速恢复完整环境。
适合长期驻留	docker run -d –restart unless-stopped 非常适合将 Hermes 作为后台 Gateway 服务运行。

容器化的主要劣势

劣势	说明
并发限制	官方文档明确禁止两个容器同时挂载同一数据目录。宿主机单进程运行天然不存在此问题。
权限问题	容器默认以 root 启动，写入 ~/.hermes 的文件在宿主机可能归属 root，导致后续宿主机直接运行时遇到权限错误。
浏览器工具需额外配置	Playwright/Chromium 在容器内需要共享内存，必须添加 –shm-size=1g，否则可能崩溃。
镜像体积较大	基于 Debian 且包含完整浏览器引擎，镜像比纯 Python 环境大得多。
调试多一层	查看日志、修改代码、运行测试均需通过 docker exec 或 docker logs 操作，不如宿主机开发直接。
排查成本	若 .env 缺失或配置错误，容器会立即退出，新手需要查看 docker logs 才能定位；宿主机交互运行则能直接看到报错输出。

选择建议

优先选 Docker：追求开箱即用、快速部署、长期后台运行 Gateway，或宿主机环境复杂不愿手动配置依赖的场景。
优先选宿主机：需要频繁开发调试、对文件权限敏感、重度使用浏览器自动化且希望最小化资源开销的场景。

若计划混用（Docker 跑 Gateway + 宿主机 CLI 调试），需特别注意容器生成的文件权限问题。

两个关键实践问题

1. Gateway 前台运行时如何执行其他子命令？

容器启动命令 hermes gateway run 为前台进程。执行其他子命令有两种方式：

方式 A：对运行中的容器执行 **docker exec**（推荐）

方式 B：启动一次性临时容器

2. 容器化环境下 Profiles 是否可用？

可用，但需要显式指定 **HERMES_HOME** 环境变量。

从 hermes_constants.py 源码可以看出，Hermes 已明确处理 Docker 场景下的 profile 路径识别：当 HERMES_HOME 指向 <root>/profiles/<name> 时，系统能正确解析其根目录。

使用示例：

只要 -v ~/.hermes:/opt/data 挂载正确，profile 数据就会在宿主机持久化。entrypoint.sh 还会自动创建 home/ 子目录，使 git、ssh、npm 等子进程的配置也能落入持久卷中。

若未显式指定 HERMES_HOME，则默认使用 /opt/data，等价于宿主机直接运行 hermes（不带 -p 参数）的默认 profile 模式。

总结

Hermes Agent 的 Docker 容器化部署通过单一挂载卷实现了配置与镜像的解耦，既保留了无状态升级的优势，又确保了数据的持久化。对于希望将 Hermes 作为长期后台 Gateway 的用户，Docker 是最省心的方案。

但在实际使用中需要注意三点：

严禁同一数据目录并发挂载多个容器；
子命令优先通过 **docker exec** 执行，避免启动冲突容器；
Profiles 在 Docker 中完全支持，核心操作是通过 -e HERMES_HOME=/opt/data/profiles/<name> 显式指定路径。

如果你还在宿主机与容器化之间犹豫，可以先通过 Docker 完成 setup 向导并试用 Gateway 模式，确认稳定后再决定是否长期采用。

Hermes Agent Discord 配置与会话隔离完全指南

Mon, 13 Apr 2026 10:12:01 +0800

Hermes Agent 作为功能完备的 AI 助手平台，支持通过 Discord Bot 形式接入服务器。本文基于实际部署经验，系统梳理从 Bot 创建到会话隔离配置的完整流程，并解答部署过程中可能遇到的典型问题。

一、Discord Bot 创建与基础配置

1. 创建 Discord Application

访问 Discord Developer Portal，点击 New Application，填写应用名称后进入管理界面。在 General Information 页面记录 Application ID，后续生成邀请链接时需要用到。

2. 配置 Bot 与关键权限

进入左侧 Bot 标签页，此处需要完成三项关键设置：

Bot 身份设置

Public Bot：建议保持 ON，以便使用 Discord 提供的标准邀请链接
可在此页面上传 Bot 头像和横幅

Token 获取

点击 Reset Token 生成 Bot Token
该 Token 仅显示一次，务必妥善保存，后续写入 Hermes 的 .env 文件

Privileged Gateway Intents（关键步骤）

页面下方找到 Privileged Gateway Intents 区域，必须开启以下两项：

Intent	作用	是否必须
Server Members Intent	访问成员列表、解析用户名	是
Message Content Intent	读取消息文本内容	是

注意：Message Content Intent 是 Bot 能够正常响应的前提。若未开启，Bot 虽能在线并接收事件，但无法获取消息文字内容，表现为"在线但不回复"。

3. 生成邀请链接并授权

方式一：Installation 标签页（推荐）

左侧进入 Installation → 开启 Guild Install
Install Link 选择 Discord Provided Link
Scopes 勾选 bot 和 applications.commands
Permissions 选择：View Channels、Send Messages、Read Message History、Embed Links、Attach Files

方式二：手动构造 URL

将 YOUR_APP_ID 替换为 Application ID，访问该链接选择服务器完成授权。

二、Hermes 环境配置

在 ~/.hermes/.env 文件中添加：

获取 User ID 的方式：Discord 设置 → Advanced → 开启 Developer Mode，右键点击自己的用户名选择 Copy User ID。

启动 Gateway：

可选环境变量：

变量	默认值	说明
DISCORD_REQUIRE_MENTION	true	频道中是否需要 @Bot 才响应
DISCORD_AUTO_THREAD	true	@mention 时自动创建 Thread（推荐保持开启）
DISCORD_FREE_RESPONSE_CHANNELS	-	无需 @mention 即可响应的频道 ID
DISCORD_IGNORED_CHANNELS	-	Bot 完全不理会的频道黑名单

三、会话隔离机制详解

Hermes 通过 session_key 区分不同会话，Discord 场景下的默认行为如下：

1. DM（私聊）— 天然隔离

每个 DM 对话拥有独立的 session_key，无需 @mention，所有消息自动归入同一会话。

2. 服务器频道 — 默认按用户隔离

config.yaml 中的全局设置控制此行为：

当该值为 true 时：

Alice 在 #research 频道 @Bot，Bot 为她维护独立会话
Bob 在同一频道 @Bot，Bot 为他维护完全不同的独立会话
两人互不共享上下文、Token 消耗、运行状态

若设为 false，整个频道共享一个会话。

3. Thread（子区/线程）— 核心隔离手段

Discord Thread 是 Hermes 实现会话隔离的关键机制：

Thread 与父频道隔离

Thread 的 session_key 包含 thread_id，因此 Thread 内对话与父频道完全隔离

Thread 内默认共享

thread_sessions_per_user 默认为 false，同一 Thread 内的所有用户共享一个会话（适合协作场景）
若需 Thread 内也按用户隔离，设置 thread_sessions_per_user: true

自动创建 Thread（强烈推荐）

DISCORD_AUTO_THREAD 默认为 true，其工作机制：

效果：

每次 @mention = 一个新的 Thread = 一个全新的隔离会话
Thread 内后续回复无需再次 @mention
不同任务天然处于不同会话，完全避免上下文污染

四、问题排查：频道 @mention 无响应

若 DM 可正常工作但频道 @mention 无响应，按以下顺序排查：

1. 检查 Message Content Intent（最常见原因）

进入 Discord Developer Portal → 你的 Application → Bot → Privileged Gateway Intents，确认 Message Content Intent 已开启，点击 Save Changes。

2. 检查 Bot 频道权限

在 Discord 中，右键频道 → Edit Channel → Permissions，确认 Bot 角色拥有：

View Channels
Read Message History
Send Messages

3. 检查环境配置

4. 终极解决方案：重新授权

若确认以上设置均正确但仍无法响应，尝试：

将 Bot 踢出服务器
使用新的邀请链接重新授权（确保权限整数包含所需权限）
重新启动 hermes gateway

实际部署经验表明，重新授权往往能解决问题，可能是 Discord 端权限缓存未刷新导致。

五、最佳实践配置

推荐配置实现最大化隔离：

~/.hermes/.env：

~/.hermes/config.yaml：

此配置下的交互体验：

在 #general @Bot “帮我写 Python 脚本” → Bot 自动创建 Thread A，任务在隔离环境运行
再次 @Bot “分析这份文档” → Bot 创建 Thread B，又是一个全新会话
同事也在 #general @Bot → 获得独立的 Thread C，互不干扰

六、会话管理命令

在任意对话中可使用以下命令：

命令	作用
/reset	重置当前会话，开启全新空会话
/title 任务名称	为当前会话命名，便于后续查找
/sethome	将当前频道设为 Home Channel，用于接收定时任务输出

总结

隔离层级	默认行为	控制方式
DM vs 频道	完全隔离	天然
不同用户同频道	按用户隔离	group_sessions_per_user: true
不同 Thread	完全隔离	天然（thread_id 参与 session key）
同 Thread 不同用户	共享会话	thread_sessions_per_user: true 可开启隔离
同用户同频道不同任务	共享会话	依靠 DISCORD_AUTO_THREAD=true 自动开 Thread

保持 DISCORD_AUTO_THREAD=true（默认开启）是最简单有效的防污染手段，让每次 @mention 都落入全新 Thread 会话中，从根本上避免同一频道内多任务互相干扰。

Hermes 微信集成：认证机制、配置字段与接入流程

Sat, 11 Apr 2026 13:18:51 +0800

Hermes Agent 近期新增了微信（WeChat）渠道集成支持。本文梳理其认证机制、配置字段、接入流程及主要约束，供需要将 Hermes 接入微信的用户参考。

认证机制

微信集成采用 iLink Bot API 的二维码扫码登录方式，无需 Webhook，通过长轮询（Long Polling）接收消息。认证流程在本地完成，凭据自动保存到 ~/.hermes/weixin/accounts/，后续无需重复扫码。

配置字段

字段	必填	说明
WEIXIN_ACCOUNT_ID	是	iLink Bot 账号 ID，扫码登录后自动获取
WEIXIN_TOKEN	是	iLink Bot 鉴权 token
WEIXIN_BASE_URL	否	API 端点，留空使用 iLink 默认服务地址
WEIXIN_DM_POLICY	否	私聊策略，见下方说明
WEIXIN_GROUP_POLICY	否	群消息策略，见下方说明

访问策略

私聊（DM）策略（WEIXIN_DM_POLICY）：

open：接受任何人的私聊
allowlist：仅接受白名单用户
disabled：关闭私聊
pairing：需要配对确认

群消息策略（WEIXIN_GROUP_POLICY）：

open：接受所有群的消息
allowlist：仅接受白名单群
disabled：关闭群消息（个人账号默认值）

接入流程

执行后选择 Weixin，按提示用微信手机 App 扫描终端中显示的二维码，在手机上确认登录。凭据由 hermes 自动保存，无需手动配置 token 字段。

媒体能力

适配器原生支持图片、视频、文件和语音消息。CDN 传输使用 AES-128-ECB 加密/解密，由 hermes 在内部处理，对使用方透明。

主要约束

单实例限制：同一个 token 在同一时刻只能被一个 hermes 实例使用。多实例接入需要对应多个独立账号。
群消息默认关闭：个人微信账号的 WEIXIN_GROUP_POLICY 默认值为 disabled，需要显式设置才能接收群消息。
消息自动分段：超过 4000 字的回复会按语义边界自动拆分发送。
去重窗口：5 分钟内的重复消息会被过滤，防止重复处理。

Hermes 自定义 AI Provider 配置方法梳理

Sat, 11 Apr 2026 03:56:24 +0800

本文整理自社区实践与底层源码 review，旨在客观呈现 Hermes 中自定义 AI Provider 的安全配置路径，并标注用户经验与代码实现之间的差异和补充说明。

用户实践中的配置流程

以下步骤来源于 Herald 的实际操作经验，描述了他总结的“安全添加第三方自定义 AI Provider”的完整流程。

第一步：准备 Provider 基本信息

在开始前，需要确认以下信息：

base url：API 端点地址
api key：访问密钥
model name：模型名称

第二步：交互式添加 custom provider

通过 hermes model 命令进入交互式向导：

填写 base url 和 模型名
api key 留空（该字段为选填项）
上下文尺寸知道可填，不知道可留空

第三步：修改配置文件中的 provider 名称

交互添加后，默认会以 base url 命名 provider。用户可手动修改 ~/.hermes/config.yaml，将名称改为更具可读性的形式。例如：

第四步：通过 credential pool 添加 api key

执行以下命令为自定义 provider 添加密钥：

底层实现中，该命令会将密钥写入独立的 credential pool 存储，而不会落入 config.yaml。这样可避免配置文件中的密钥明文泄漏风险。

第五步：重启 gateway

配置和密钥添加完成后，重启 gateway 即可生效。

底层源码视角的补充与修正

以下分析基于对 Hermes 底层代码的直接阅读，对前述流程进行验证和补充。

1. `custom_providers` 名称解析的灵活性

代码层面，model.provider 支持两种写法：

custom:kimi-plan：带 custom: 前缀的 slug，可直接定位 custom_providers 中的对应条目
custom：传统写法，此时依赖 base_url 来匹配 custom_providers

用户示例中的 provider: custom:kimi-plan 是完全符合底层预期的写法。底层在解析时大小写不敏感，且会自动将空格替换为 -，因此命名容错空间较大。

2. 上下文尺寸自动探测的完整链路

用户提到“不知道可以留空让程序自动探测”，这一点底层确实有完整支持，但探测逻辑有明确的优先级：

custom_providers 中 models.<model>.context_length 的手写配置
本地缓存 ~/.hermes/context_length_cache.yaml
models.dev / OpenRouter 元数据缓存（当 base_url 属于已知 provider 时，如 api.kimi.com）
直接探测端点 /models（对 local / ollama / vLLM / LM Studio 等特别有效）
上下文递减探测（从 128K 逐步向下尝试，直到 API 不返回上下文超限错误）
最终 fallback 到 128K

因此，留空自动探测对标准 OpenAI-compatible 端点通常有效；若端点 /models 返回格式不标准或未包含 context_length，则可能退回到 128K 默认值。

3. `hermes auth add` 的密钥存储机制

底层代码路径为 agent/credential_pool.py 和 hermes_cli/auth_commands.py：

_normalize_provider("kimi-plan") 发现匹配 custom_providers 中的名称后，将其规范化为 custom:kimi-plan
生成 PooledCredential 条目，写入 credential pool 持久化存储
运行时，runtime_provider.py 的 _try_resolve_from_custom_pool() 会优先从 pool 读取密钥

这意味着：

API key 不会进入 config.yaml
该机制天然支持多 key 轮询（fill_first、round_robin、random 等策略）

4. 关于“重启 gateway”的适用范围

需要区分运行模式：

CLI 模式：改完配置、添加 auth 后，下一次调用即生效，无需重启
Gateway 模式（作为后台服务接收 Telegram / Discord / Slack 消息）：model.provider 和 model.default 在启动时加载并缓存，因此需要重启 gateway 才能感知变更

流程对照总结

用户描述	底层验证	说明
hermes model 交互添加，不填 api key	正确	_model_flow_custom 支持此操作
手动修改 custom_providers 的 name	正确	name 可自定义，slug 为 custom:<name>
hermes auth add <provider> –api-key	正确	写入 credential pool，避开 config.yaml
留空 context_length 自动探测	部分正确	标准端点有效，非标准端点可能 fallback 128K
重启 gateway 使用	基本正确	CLI 无需重启，gateway 需要重启

额外建议

如果你已经通过 hermes auth add 将 key 存入了 credential pool，建议进一步检查 config.yaml 中是否残留有此前交互时意外写入的 api_key 字段，并予以清理，以确保配置文件中不存在任何密钥明文。

为 auxiliary 任务配置自定义 Provider 的注意事项

Hermes 的 auxiliary 系统（负责图片理解、上下文压缩、网页摘要等侧边任务）与主对话模型在读取 API Key 时的逻辑并不完全相同。

核心差异：当 auxiliary 任务使用 named custom provider 时，如果该 provider 没有显式指定 key_env，底层不会 fallback 到 OPENAI_API_KEY 或 OPENROUTER_API_KEY，而是直接发送 Bearer no-key-required，导致服务商返回 401 Unauthorized。更糟糕的是，部分 API 网关（如 SiliconFlow）在鉴权层拒绝请求之前，可能已经在网关接入层记录了输入 token 并产生计费。

因此，**只要你的自定义 provider 需要 API Key 认证，就必须在 **custom_providers** 中显式设置 ****key_env**，例如：

随后在 auxiliary 中直接引用该 provider 名称即可：

多模型配置建议

不要在 custom_providers 里为同一个 endpoint 创建多个 entry。Hermes 在解析 named custom provider 时只会命中列表里第一个匹配 name 的 entry，后续同名的 entry 会被忽略。

如果你需要为同一个 provider 配置多个模型的上下文长度，请使用 models 子字典：

model 字段（与 models 同级）不是必须的。若省略，Hermes 会 fallback 到你在 model.default 中配置的主模型，或最终使用 gpt-4o-mini。

深入解析 Hermes Agent 会话管理机制与设置技巧

Fri, 10 Apr 2026 12:20:30 +0800

会话存储架构

Hermes Agent 自动将每一次对话保存为 session，以支持对话恢复、跨会话检索和完整的历史管理。其底层采用双存储结构：

SQLite 数据库 (**~/.hermes/state.db**)：存储结构化元数据，利用 FTS5 插件实现高效的全文检索。记录内容包括 Session ID、来源平台、用户 ID、唯一标题、模型配置、系统提示词快照、完整消息历史及 Token 统计。
JSONL 转录文件 (**~/.hermes/sessions/**)：存储原始对话转录，包含详细的工具调用过程与结果。

会话来源与隔离机制

Hermes 支持多种来源（Source），包括 cli、telegram、discord、slack 等。针对不同场景，采用了不同的隔离策略：

1. 群聊隔离逻辑

在 Discord 频道、Slack 频道等共享上下文中，Hermes 默认启用 group_sessions_per_user: true。这意味着：

每个发送者拥有独立的 session 历史。
不同用户的长任务不会相互污染上下文。
中断处理和运行状态按用户隔离。

若需将群组视为一个共享的“房间大脑”，可将该项设为 false。

2. 线程隔离

在 Slack 等支持线程的平台中，线程是主要的隔离边界。在同一线程内的对话将沿用同一会话，而新线程则会开启新会话。

CLI 会话管理

1. 对话恢复

恢复最近会话：使用 hermes --continue 或 hermes -c。
按 ID 或标题恢复：使用 hermes --resume <ID/Title> 或 hermes -r <ID/Title>。

恢复时，Hermes 会显示一个紧凑的摘要面板（Recap Panel），通过颜色标识区分用户（金点）与助手（绿点），并折叠工具调用过程。可通过 display.resume_display: minimal 关闭该面板。

2. 会话命名与 Lineage

自动命名：系统在首轮交互后自动生成 3-7 个词的描述性标题。
手动命名：在 session 中使用 /title <name> 命令，或通过 hermes sessions rename <ID> <name> 修改。
自动血统 (Lineage)：当会话因上下文压缩而分裂出续篇时，标题会自动递增（如 my project → my project #2）。

3. 管理命令速查

列表：hermes sessions list (支持 --source 筛选)。
导出：hermes sessions export <file>.jsonl (支持单会话导出)。
删除：hermes sessions delete <ID>。
清理：hermes sessions prune (默认清理 90 天前已结束的会话)。
统计：hermes sessions stats。

跨会话检索：`session_search`

Hermes 内建 session_search 工具，允许 Agent 检索历史对话以找回丢失的上下文。

工作流：利用 SQLite FTS5 进行相关性排序 → 聚合 Top N 个 session → 提取匹配点前后约 100K 字符 → 调用快速摘要模型生成结果。
支持语法：支持简单关键词、精确短语 ("...")、布尔运算 (OR, NOT) 及前缀匹配 (*)。

Gateway 会话重置策略

对于消息平台会话，Hermes 提供了四种重置策略 (reset_policy)：

idle：空闲 N 分钟后重置。
daily：每天固定时间重置。
both：两者取其先。
none：永不自动重置。

在自动重置前，Agent 会获得一个 Turn 用以将重要信息保存至 Memory 或 Skills。此外，含有活跃后台进程的会话不会被自动重置。

核心配置技巧

1. 上下文压缩 (`compression`)

为了在长对话中维持性能，Hermes 采用分段压缩机制：

threshold: 设置触发压缩的上下文百分比（默认 0.50）。
target_ratio: 压缩后保留的中间内容比例（默认 0.20）。
protect_last_n: 强制保留最近 N 条消息不被压缩（默认 20）。

2. 关键配置项汇总

配置项	推荐值	作用
display.resume_display	full	恢复会话时显示历史回顾面板
group_sessions_per_user	true	群聊中按用户隔离会话，防止上下文污染
compression.enabled	true	自动压缩长对话，防止触碰模型 Context Limit
compression.threshold	0.50	达到 50% 上限时开始摘要压缩

参考来源

Hermes Agent Sessions Documentation

Hermes Agent Slack 使用指南：从高效对话到精细化配置

Fri, 10 Apr 2026 09:55:33 +0800

Hermes Agent 在 Slack 中的集成旨在提供一个高效、可隔离且可自定义的交互环境。为了确保在多人协作的频道中能够精准调度 AI 而不干扰他人，理解其交互逻辑和配置项至关重要。

核心交互规则

1. 显式唤起 (@mention)

在 Slack 频道中，Hermes 默认采用“被动响应”模式。这意味着简单的文本消息会被忽略，必须通过 @mention (例如 @Hermes) 明确唤起机器人。

这一设计旨在防止 AI 在高频讨论的频道中产生不必要的干扰，确保只有在用户明确需要时才介入对话。

2. 线程作为上下文隔离单元

Slack 的 Thread（线程）是 Hermes 管理上下文的核心机制：

上下文继承：在已有线程中 @mention Hermes，它会继承该线程的历史记录并在此回复。
独立会话：不同线程之间的上下文是完全隔离的。
多人并行：即使在同一个频道中，不同用户与 Hermes 的对话历史也是分离的，只要各自在独立的线程中进行。

高频使用技巧

任务隔离：一事一线程

为了避免上下文混淆，最有效的实践是将每一个独立任务绑定到一个独立的线程。

操作流程：

发起新任务 → 创建新消息并 @mention Hermes → 开启新线程。
追问或迭代 → 在该线程内回复。

优势：当需要并行处理多个任务（如：同时进行“代码审查”和“文档编写”）时，可以通过切换线程来快速切换上下文，而无需向 AI 重新解释背景。

结构化首条指令

为了提高响应质量，建议首条指令包含以下要素：

任务目标：明确要解决的问题。
约束条件：输出格式、禁忌项或特定参考资料。
预期结果：希望得到的最终交付物形式。

配置项深度解析

Hermes 的 Slack 行为可以通过 ~/.hermes/config.yaml 进行精细化调整。

1. 线程回复行为 (`reply_in_thread`)

路径：platforms.slack.extra.reply_in_thread
默认值：true
行为：
true：频道内的首条指令会在新线程里回复。
false：频道内的首条指令会直接回复到主频道流。
边界：无论此项如何设置，已经在线程中的消息始终会在线程内回复。

2. 响应触发机制 (`require_mention`)

路径：require_mention
默认值：true
行为：决定是否必须通过 @mention 才能激活机器人。在多人协作频道中，建议保持为 true，以避免误触发。

3. 自定义触发模式 (`mention_patterns`)

除了标准的 @mention，还可以通过 mention_patterns 配置自定义口令唤起。

示例配置：

用途：在特定工作流中简化唤起操作，无需频繁输入 @ 符号。

4. 可对话用户白名单 (`SLACK_ALLOWED_USERS`)

Hermes 还支持通过 Slack Member ID 限定哪些用户可以与 bot 对话。

配置方式：设置环境变量 SLACK_ALLOWED_USERS
值类型：Slack Member ID 列表，而不是用户名或 display name
安全行为：如果不设置该白名单，网关会默认拒绝所有消息，作为安全措施
适用场景：
只允许特定成员调用 bot
避免频道里无关成员误触发
在测试环境里限制使用范围

总结：Slack 使用口诀

频道先 @，任务一线程一事，换题另起 thread，多人并行不串线。

信息来源

Hermes profiles：在一台设备上给多人提供独立 AI 助手

Fri, 10 Apr 2026 08:34:20 +0800

什么是 profiles

Hermes 的 profiles 功能，提供的是一组彼此隔离的运行环境。每个 profile 都有自己的配置、密钥、人格设定、记忆、会话、技能、定时任务和状态库。换句话说，它不是在同一个会话里分出几个角色，而是在同一台设备上建立多个独立的 Hermes 空间。

这类隔离带来的直接结果是：不同用途、不同身份、不同用户之间不会互相污染上下文。一个 profile 可以专门给自己用，一个给家人用，一个给朋友用，也可以按项目、按角色、按工作流拆开。

它是怎样工作的

创建 profile 之后，Hermes 会自动为它生成独立的命令入口。比如创建一个名为 coder 的 profile 后，就可以直接使用：

coder chat
coder setup
coder gateway start

这意味着 profile 不只是一个配置文件夹，而是一个可以直接启动和管理的独立 agent 单位。

Profile 管理命令

创建 Profile

选项	说明
–clone	复制 config.yaml、.env、SOUL.md，但使用新的会话和记忆
–clone-all	复制全部内容，相当于完整快照
–clone-from	指定源 profile，而非当前 profile

列出和切换

使用 Profile 的方式

方式一：命令别名（自动生成）

创建 profile 后，Hermes 会自动在 ~/.local/bin/ 下生成同名命令：

方式二：-p 参数

查看详情

输出示例：

导入和导出

删除 Profile

:::warning

删除操作不可恢复，会同时停止网关、移除服务并删除所有数据。

:::

Profile 文件结构

每个 profile 存储在 ~/.hermes/profiles/<name>/，包含：

适合什么场景

1. 给不同人提供独立助手

最直接的用途，是在同一台设备上给家人或朋友各自创建一个独立的 Hermes。每个人都能拥有自己的配置、记忆和使用习惯，不需要理解底层运维细节。

2. 多项目隔离

如果你同时维护多个项目，可以把每个项目放进不同 profile。这样模型设置、技能、会话历史和 cron 任务都不会互相干扰。

3. 多角色并行

你可以把一个 profile 作为个人助理，另一个作为代码助手，再另一个作为研究助手。它们的行为风格、插件、记忆和任务状态都可以单独配置。

4. 实验和备份

当你想测试一套新配置、新技能，或者想保留当前状态做一个可回退的副本时，--clone-all 很适合。它可以把当前环境完整复制出来，再在新 profile 上继续试验。

能解决什么问题

profiles 主要解决的是"单一 agent 不够分、上下文容易串、配置难隔离"的问题。

具体来说，它可以减少：

会话历史混在一起
不同用户的记忆冲突
API 密钥和模型配置互相覆盖
定时任务、技能、插件互相影响
一个 agent 既要扮演多个身份，又没有清晰边界

因此，profiles 更像是一种"隔离式多租户"能力：同一台机器上，可以同时运行多个互不干扰的 Hermes 实例。

和 subagent 的区别

profiles 和 subagent 不是一回事。

profiles：长期独立环境，适合多人、多身份、多项目
subagent：临时派出去执行单个任务的工作单元，适合并行研究、拆分任务、快速协作

可以把 profiles 理解为"各自独立的房间"，把 subagent 理解为"临时派出去做事的人"。

一个比较实用的理解

如果你希望一台设备上同时服务不同人，而且每个人都像拥有自己的专属 AI 助手，那么 profiles 就是 Hermes 提供的基础能力。它让复杂的多用户使用方式变成可管理、可隔离、可复制的结构。

这也是它和很多只强调单会话工作流的方案相比，最有价值的地方之一。

OpenClaw 梦境功能：让 AI 助手自动沉淀长期记忆

Thu, 09 Apr 2026 14:51:23 +0800

OpenClaw 在 2026.4.5 版本正式推出了 Dreaming（梦境） 功能。概念来自人类睡眠时大脑整理记忆的过程：趁夜深人静，把白天零散的经历提炼成真正值得记住的东西。

它解决什么问题

在没有 Dreaming 之前，OpenClaw 的记忆是这样工作的：对话过程中产生的短期信号（用户的偏好、习惯、反复提到的事情）存在每日日志文件里，但并不会自动升级为长期记忆。时间一长，这些信号就沉在文件堆里，AI 不会主动去回顾，等于白积累。

Dreaming 的作用就是在后台默默做这件事：把高质量的短期信号自动提炼、写入长期记忆（**MEMORY.md**），让 AI 下次一开口就能想起来，而不需要每次重新交代背景。

三个阶段，像人类睡眠一样

Dreaming 内部分三个阶段运行：

Light Sleep（浅睡）：扫描近期的短期记忆和对话记录，去重、暂存候选项，记录哪些内容被反复强化。这个阶段不写入长期记忆，只是整理候选。

Deep Sleep（深睡）：对候选项打分，用六个维度加权评估（相关性 0.30、频率 0.24、查询多样性 0.15、时效性 0.15、整合度 0.10、概念丰富度 0.06）。只有通过阈值的内容才会被追加到 MEMORY.md，门槛相当严格：最低分 0.8、最少被回忆 3 次、最少来自 3 个不同查询。

REM：从短期轨迹中提取模式和反思信号，生成主题摘要，写入 DREAMS.md（一份人类可读的"梦境日记"）。不直接写长期记忆，但会影响下次 Deep Sleep 的判断。

这三个阶段各自独立调度，合起来就是一次完整的"睡眠"。

token 消耗情况

Dreaming 每天自动运行，必然会产生额外的 token 开销。系统内置了一个跳过机制：每次运行前先检查是否有未整合的新内容，7 天内没有新内容就直接退出，仅消耗约 2K token；有内容可处理时才完整跑三个阶段，完整跑一次大约消耗 150K token。

实际累积下来的额外消耗取决于对话频率和内容密度，具体情况有待观察。

如何启用

在 openclaw.json 中加入以下配置，重启服务即可：

frequency 是标准 cron 表达式，这里设置的是每天凌晨 3 点运行。timezone 确保时间以本地时区解释，否则默认 UTC 会让 3 点变成上午 11 点。

有一个已知 bug（#62098）：通过 Web 控制台的开关启用会创建结构错误的配置。直接编辑 JSON 文件没有这个问题，是目前最稳妥的方式。

运行效果验证

启用后可以通过以下方式查看运行情况：

Dreaming 运行完成后，DREAMS.md 会记录这次"睡眠"的摘要——哪些内容被提炼了，哪些被丢弃了，以及整体的反思。类似一本可以翻阅的日记。

Hermes Agent 功能总览

Thu, 09 Apr 2026 10:03:48 +0800

Hermes Agent 是 Nous Research 维护的开源 AI agent 框架。它把 CLI、消息网关、模型切换、工具调用、记忆、定时任务、MCP、子代理和多实例配置放在同一套系统里，适合需要长期运行和跨平台协作的工作流。

功能总览

1. 交互入口

Hermes 提供多个入口：

hermes CLI
消息网关：Telegram、Discord、Slack、WhatsApp、Signal、Email、SMS、Matrix、Mattermost、Home Assistant、DingTalk、Feishu、WeCom
slash commands
CLI 子命令

在终端里处理任务，也可以在聊天平台里发起和继续同一段会话。

2. 模型与 provider

Hermes 支持多种模型提供方，包括：

Nous Portal
OpenRouter
OpenAI
Gemini / Google AI Studio
Z.AI / GLM
Kimi / Moonshot
MiniMax
自定义 endpoint

它还支持会话内切换模型，以及 provider fallback，用来降低单一 provider 故障、限流或价格变动带来的影响。

3. 工具系统

官方文档里列出的工具范围包括：

terminal
file
web
browser
vision
code execution
delegation
skills
session search
memory
cronjob
MCP
tts

这样可以把模型从“生成文本”扩展到“调用工具完成任务”。

4. 记忆与用户画像

Hermes 提供跨会话记忆和用户画像能力，常见组件包括：

memory
user profile
session search
memory provider 插件，例如 Honcho、Mem0

这样可以保存偏好、历史任务、常用设置和上下文，减少每次重新说明的成本。

5. 自动化

Hermes 提供几类自动化能力：

Cron 定时任务
后台任务完成通知
长任务持续运行
任务状态和会话持续记录

这样 agent 可以在无人值守时继续工作，适合报告生成、例行检查、夜间任务和长流程处理。

6. 协作能力

Hermes 支持把工作拆成多个并行单元：

subagent
parallel workstreams
session 绑定
shared thread sessions

这样可以把独立工作流拆开执行，减少单线程阻塞。

7. 多实例与 profiles

Profiles 允许同一安装里运行多个隔离实例。每个 profile 有自己的：

配置
记忆
sessions
skills
gateway service

这样可以把不同项目、不同身份或不同工作流分开管理。

8. OpenClaw 迁移

Hermes 提供了 OpenClaw 迁移路径：

hermes claw migrate
hermes claw migrate --dry-run
hermes claw migrate --preset user-data
hermes claw migrate --preset full
openclaw-migration skill

这样可以把旧环境中的 persona、memory、skills、allowlist、消息配置和部分工作区内容迁入 Hermes。

版本里能看到的重点

从 release notes 看，Hermes 的发展重点主要集中在这些方向：

provider 和模型切换
fallback provider chain
多实例 profiles
网关平台扩展
MCP 接入
安全和配置校验
插件体系
后台任务通知

这说明它的定位更偏向一个可编排的 agent 平台，而不是单一聊天界面。

适合的使用场景

Hermes 比较适合下面几类工作：

需要长期上下文的个人协作
需要在终端和消息平台之间切换的工作流
需要定时任务或后台执行的任务
需要 provider 容错和切换的场景
需要把经验沉淀成技能和记忆的场景

参考来源

官方文档：hermes-agent.nousresearch.com/docs
GitHub 仓库：NousResearch/hermes-agent
README：README.md
Release notes：RELEASE_v0.6.0.md、RELEASE_v0.8.0.md
OpenClaw 迁移：optional-skills/migration/openclaw-migration/SKILL.md

本文基于 Hermes Agent 官方仓库、文档站点与 release notes 整理。

OpenClaw 的“梦境”功能是什么：一次把短期记忆变成长记忆的后台系统

Thu, 09 Apr 2026 06:14:13 +0800

OpenClaw 的 Dreaming 功能，指的是 memory-core 里的后台记忆整合机制。它处理近期对话、日记、回放片段和短期信号，再决定哪些内容进入长期记忆，哪些内容只保留为可审查的过程记录。

背景与定义

官方文档将 Dreaming 定义为 background memory consolidation system。该功能默认关闭，属于 experimental 范畴，需要用户显式开启。

Dreaming 相关输出分成两类：

机器状态：写入 memory/.dreams/，用于保存 recall store、phase signals、checkpoint 和锁信息。
可读叙事：写入 DREAMS.md 或 dreams.md，用于展示 Dream Diary 和阶段摘要。

长期记忆仍然写入 MEMORY.md。

调研范围

本文只围绕三件事展开：

Dreaming 在 OpenClaw 中的职责是什么；
最近一次更新补了哪些能力；
这套机制有哪些明确边界。

功能机制

阶段	作用	结果
Light	整理近期短期材料，做去重、分组和初步筛选	不写入长期记忆
REM	提炼主题、反思和模式，形成反思信号	不写入长期记忆
Deep	对候选内容评分并决定是否晋升	写入 MEMORY.md

从官方描述看，这套设计有三个明显特征：

阶段职责分离，避免把所有输入直接写进长期记忆。
Dream Diary 作为叙事层存在，和长期记忆写入分开。
phase policy、thresholds 和 storage behavior 被视为内部实现细节，不作为用户侧核心配置暴露。

因此，Dreaming 更接近一条记忆加工流水线，而不是单一功能按钮。

最近更新增加了什么

根据 GitHub 官方 release notes，v2026.4.9 与 Dreaming 相关的新增点集中在四类：

Grounded REM backfill：支持历史 rem-harness --path 回放，把旧日记重新送入 Dreaming 流程。
Diary commit/reset flows：补齐日记的提交与重置流程，便于回看和修正回放结果。
Structured Dreams UI：新增结构化 diary view，包含时间线导航、backfill/reset 控件和可追踪的 dreaming summary。
Grounded Scene lane：单独显示历史回放产生的 staged 结果，并提供安全的清理动作，避免与正常在线材料混在一起。

release notes 还提到对 grounded backfill 输入、日记写入、状态 payload 和 diary action classification 的加固，重点包括保留 source-day 标签、拒绝缺失或符号链接目标，以及规范 gateway backfill 的日记标题与元数据。

官方文档中的边界

Dreaming 是 opt-in，默认关闭。
它负责记忆整合，不替代长期记忆本身。
Dream Diary 主要用于人类查看，不是 promotion source。
phase policy、thresholds 和 storage behavior 不属于用户层公开配置接口。

这类边界设计的作用，是把“可解释性”和“自动晋升”分开：用户能看到过程，但不会把过程输出直接当成最终记忆。

实际含义

从产品角度看，Dreaming 解决的是三个问题：

减少人工整理记忆的成本；
把短期噪音和真正有价值的内容区分开；
保留一条可回放、可审查的记忆形成链路。

它的重点不在命名，而在于把长期记忆的形成过程做成一个可管理系统。

已知边界与注意事项

该功能是实验性功能，默认关闭。
内容晋升依赖评分和阈值，结果会受输入质量影响。
历史回放如果边界不清晰，可能把噪音带回记忆流程，因此官方加入了 grounded lane 和输入校验。
Dream Diary 是解释层，不应与真正的长期记忆写入混为一谈。

总结

OpenClaw 的 Dreaming 功能，是围绕长期记忆整合设计的后台系统：Light、REM、Deep 三阶段协作，Dream Diary 提供过程可视化，最新更新则把历史回放、结构化查看和安全清理补了起来。它更适合被理解为“记忆加工与晋升机制”，而不是一个独立的对话特性。

参考来源

GitHub Release v2026.4.9：https://github.com/openclaw/openclaw/releases/tag/v2026.4.9
Dreaming 概念文档：https://github.com/openclaw/openclaw/blob/main/docs/concepts/dreaming.md
Memory config reference：https://github.com/openclaw/openclaw/blob/main/docs/reference/memory-config.md
相关源码：dreaming.ts、dreaming-narrative.ts、short-term-promotion.ts

从 OpenClaw 到 Hermes：单指令自动完成角色迁移

Wed, 08 Apr 2026 05:55:11 +0800

执行 hermes claw migrate 后，你的配置文件和技能已迁移到 Hermes，但 Agent 的认知可能仍停留在 OpenClaw 时代。它可能仍自称 “Aris”，尝试访问 ~/.openclaw/ 目录，使用已不存在的工具。

解决方案：发送一条指令，让 Agent 自动检查并修复自身的身份认同和工作逻辑。

角色说明

在继续之前，需要明确两个身份：

身份	所属框架	说明
Aris	OpenClaw	原 OpenClaw 生态中的 AI 助手名称，在你的历史配置中使用
Helix	Hermes	迁移到 Hermes 后的新身份，需要 Agent 自我认知为此

当 Agent 说 “我是 Aris” 时，它仍在用 OpenClaw 的身份认同运行。你需要让它更新为 “我是 Helix”。

问题背景

官方迁移命令的局限

hermes claw migrate 处理数据层面：

复制配置文件到 ~/.hermes/
迁移技能到 ~/.hermes/skills/openclaw-imports/
转移记忆文件

但它不修改文件内容。如果 SOUL.md 写着 “我是 Aris”，迁移后 Agent 仍这样认为。

典型症状

迁移后如果 Agent 出现以下行为，说明需要角色适配：

症状	说明
自称 “Aris”	身份认同未更新
访问 ~/.openclaw/	路径认知错误
调用 memory_search	使用 OpenClaw 特有工具
提到 “OpenClaw 提供上下文”	框架认知错误

单指令自动化方案

你不需要手动编辑文件。发送以下指令给 Agent，它会自动完成全部检查和修复：

Agent 将自动执行上述检查，直接修改文件，并向你报告变更摘要。

技术细节（供参考）

如果你想了解 Agent 具体会检查什么，以下是技术细节：

身份声明位置

文件	路径	用途
SOUL.md	~/.hermes/SOUL.md	全局身份和性格定义
MEMORY.md	~/.hermes/memories/MEMORY.md	Agent 的个人笔记（限制 2,200 字符）
USER.md	~/.hermes/memories/USER.md	用户画像（限制 1,375 字符）

关键差异对比

维度	OpenClaw (Aris)	Hermes (Helix)
身份	“我是 Aris”	“我是 Helix”
框架	OpenClaw	Hermes Agent (Nous Research)
主目录	~/.openclaw/	~/.hermes/
记忆存储	.jsonl 文件	SQLite + FTS5
技能查询	memory_search	skills_list + skill_view
记忆限制	无明确限制	2,200 / 1,375 字符

实际变更示例

SOUL.md 变更：

MEMORY.md 变更：

验证结果

Agent 完成自检后，会输出类似以下的报告：

手动验证（可选）

如果你想手动确认迁移结果：

参考文档

官方迁移指南：Migrate from OpenClaw
记忆系统：Persistent Memory
上下文文件：Context Files

基于 Hermes Agent v0.7.0 实际迁移经验整理。

Hermes Agent vs OpenClaw：选型与迁移指南

Tue, 07 Apr 2026 15:09:25 +0800

项目简介

Hermes Agent 是由 Nous Research 开发的开源 AI Agent 框架，采用 MIT 许可证。其核心设计理念是构建一个能够随使用时间增长而自我改进的 Agent 系统。

项目	链接
官网	hermes-agent.nousresearch.com
GitHub	github.com/NousResearch/hermes-agent
最新版本	v0.7.0（截至 2026 年 4 月）
Stars	33.2k
Issues	786 open / 543 closed

核心特性

内置学习循环：从经验自动生成和优化技能
分层记忆系统：session / persistent / skill / archive 四层架构
多平台支持：Telegram、Discord、Slack、WhatsApp、Signal、Email、CLI、飞书、钉钉、企业微信
子代理委托：支持并行任务处理（单 Agent 内的多线程，非多 Agent 通信）
定时自动化：内置 cron 调度器，支持自然语言配置
沙箱环境：本地、Docker、SSH、Singularity、Modal 五种后端

安装方法

快速安装

支持平台：Linux、macOS、WSL2（不支持原生 Windows）

初始配置

基本命令

从 OpenClaw 迁移

Hermes 提供了官方的迁移工具，支持从 OpenClaw（及 legacy Clawdbot/Moldbot）导入配置。

迁移命令

迁移范围

数据类型	OpenClaw 源	Hermes 目标	说明
人设定义	workspace/SOUL.md	~/.hermes/SOUL.md	直接复制
工作区指令	workspace/AGENTS.md	指定目录	需 –workspace-target
长期记忆	workspace/MEMORY.md	~/.hermes/memories/	解析合并，去重
用户画像	workspace/USER.md	~/.hermes/memories/	同上
每日记忆	workspace/memory/*.md	合并到主记忆	全部合并
Skills	workspace/skills/	~/.hermes/skills/openclaw-imports/	支持冲突处理
模型配置	agents.defaults.model	config.yaml	支持 fallback
MCP 服务器	mcp.servers.*	mcp_servers.*	完整迁移

迁移注意事项

Provider 配置需重新验证：Hermes 不继承 OpenClaw 的 provider API keys，需重新配置
Skill 兼容性：部分 OpenClaw 生态的 skill 可能需要适配或寻找替代品
多 Agent 架构差异：OpenClaw 的 multi-agent routing 在 Hermes 中没有直接对应实现

官方迁移指南：hermes-agent.nousresearch.com/docs/guides/migrate-from-openclaw/

与 OpenClaw 的核心差异

1. 上下文管理策略

维度	OpenClaw	Hermes
存储格式	.jsonl 文件	SQLite + FTS5
记忆分层	文件系统分层	四层架构（session/persistent/skill/archive）
检索方式	memory_search 主动调用	自动动态加载 + 周期性提示
记忆持久化	手动管理	Agent 主动固化

关键区别：

OpenClaw 依赖用户主动调用记忆检索，适合需要精确控制记忆使用的场景
Hermes 采用更自动化的记忆管理，声称可以降低 token 使用，但缺乏公开的量化对比数据

2. 技能（Skill）系统

维度	OpenClaw	Hermes
创建方式	手动编写 SKILL.md	手动编写 + 自动生成
学习机制	静态配置	内置学习循环，从经验生成 procedural skills
生态丰富度	成熟（ClawHub 有大量社区 skill）	较新，生态仍在建设中
技能标准	OpenClaw Skill 规范	兼容 agentskills.io 开放标准

实际体验：

Hermes 的自动生成技能功能在简单任务上表现尚可，但复杂业务逻辑仍需手动编写和调优。OpenClaw 的成熟生态在短期内仍有优势。

3. 子代理与并行处理

Hermes 的委托模式：

重要澄清：

Hermes 支持的是单 Agent 内的子任务并行（subagent delegation）
不支持多 Agent 之间的通信和协作
每个子代理有独立的会话、终端和工具集，但只有最终摘要返回父代理

这与 OpenClaw 的 multi-agent routing（多 Agent 独立运行、相互通信）是不同的架构模式。

4. 平台接入与网关

功能	OpenClaw	Hermes
国际平台	Telegram、Discord、Slack	Telegram、Discord、Slack、WhatsApp、Signal、Email
国内平台	QQ、飞书	飞书、钉钉、企业微信
网关架构	多 channel 独立配置	统一 gateway 进程
跨平台连续性	有限	原生支持（单一会话跨平台）
语音支持	依赖插件	内置语音备忘录转录

更新：Hermes 在 v0.7.0 已新增对飞书、钉钉、企业微信的支持，国内平台适配正在快速完善中。

已知问题与限制

1. 生态成熟度

基于 GitHub Issues 的观察（786 open issues）：

高频问题：配置迁移、模型兼容性、定时任务调度
平台适配：部分平台（如 Matrix）存在 typing indicator 延迟问题
安全相关：子进程环境变量继承可能导致凭证泄漏风险（Issue #6032）

2. 实际使用中的坑

必须显式传递上下文：

子代理完全独立于父代理的会话，如果不显式传递文件路径、错误信息、项目结构，子代理对 “我们刚才讨论的 bug” 一无所知。

不好的委托：

正确的委托：

3. 社区反馈摘要

正面：

迁移工具比预期顺利
开箱即用的体验较好
定时任务功能实用

负面：

Skill 生态不如 OpenClaw 丰富
某些 OpenClaw 内置功能需要手动配置
新版本迭代快，文档有时滞后

选型建议

适合选择 Hermes 的情况

希望减少手动维护 skill 的工作量
主要使用单一 Agent，不需要多 Agent 协作
重视跨平台会话连续性
使用 Telegram、Discord、飞书、钉钉等平台
愿意接受较新的、快速迭代的项目

不建议迁移的情况

依赖 QQ 等特定国内平台（Hermes 暂不支持 QQ）
需要多 Agent 独立运行和相互通信
已经建立了大量自定义 OpenClaw skill，迁移成本过高
需要稳定成熟的生态支持
对自动化技能生成有疑虑，偏好手动控制

混合使用策略

部分用户反馈的实践经验：

总结

维度	Hermes	OpenClaw
上手难度	较低（开箱即用）	中等（需要配置）
定制能力	中等	高
生态丰富度	较新，在建设中	成熟
多 Agent 支持	不支持	支持（multi-agent routing）
记忆管理	自动化	手动控制
国内平台	飞书、钉钉、企业微信	QQ、飞书
代码生成	有内置学习循环	依赖 skill

Hermes Agent 是一个设计精良的 AI Agent 框架，特别适合希望快速上手、减少维护工作的用户。但它不是 OpenClaw 的替代品，两者在架构理念上有本质差异。

如果你重视开箱即用的体验和自动化能力，Hermes 值得一试。如果你需要精细控制、多 Agent 协作或 QQ 平台支持，OpenClaw 仍是更成熟的选择。

最终建议：两者可以共存。在独立项目中试用 Hermes，保留现有的 OpenClaw 配置，根据实际需求决定长期使用方案。

参考来源

Hermes Agent 官网：hermes-agent.nousresearch.com
GitHub 仓库：github.com/NousResearch/hermes-agent
迁移指南：hermes-agent.nousresearch.com/docs/guides/migrate-from-openclaw/
OpenClaw 仓库：github.com/openclaw/openclaw

本文基于官方文档和公开信息整理，版本信息截至 2026 年 4 月。

Hermes on 火炬树

Hermes Kanban：让多个 AI Agent 像团队一样协作

Kanban 是什么

它能做什么：从一个真实场景说起

Kanban 的核心概念有哪些

人类如何介入 Agent 的工作过程

Kanban 支持哪些协作模式

任务如何分配给不同 Agent

两个入口，同一个数据库

什么场景适合用 Kanban

与 delegate_task 的对比

快速上手

参考资料

Hermes Agent 浏览器工具的用户登录实现方案

一、交互式自动化登录（通用方案）

二、持久化浏览器 Profile / Cookie

Camofox 的 Managed Persistence

三、JavaScript 注入（程序化身份验证）

四、人机协作登录

4.1 Camofox + VNC：实时可操作浏览器窗口

4.2 browser_vision：截图回传的静态辅助

五、连接已登录的现有浏览器（CDP Override）

六、安全与防护

总结

Hermes Agent Docker 容器化运行完全指南

两种 Docker 交互方式

快速开始：三种运行方式

1. 首次初始化（setup 向导）

2. Gateway 模式（后台常驻）

3. 交互式 CLI 模式

持久化数据目录结构

容器化运行 vs 宿主机直接运行

容器化的主要优势

容器化的主要劣势

选择建议

两个关键实践问题

1. Gateway 前台运行时如何执行其他子命令？

2. 容器化环境下 Profiles 是否可用？

总结

Hermes Agent Discord 配置与会话隔离完全指南

一、Discord Bot 创建与基础配置

1. 创建 Discord Application

2. 配置 Bot 与关键权限

3. 生成邀请链接并授权

二、Hermes 环境配置

三、会话隔离机制详解

1. DM（私聊）— 天然隔离

2. 服务器频道 — 默认按用户隔离

3. Thread（子区/线程）— 核心隔离手段

四、问题排查：频道 @mention 无响应

1. 检查 Message Content Intent（最常见原因）

2. 检查 Bot 频道权限

3. 检查环境配置

4. 终极解决方案：重新授权

五、最佳实践配置

六、会话管理命令

总结

Hermes 微信集成：认证机制、配置字段与接入流程

认证机制

配置字段

访问策略

接入流程

媒体能力

主要约束

Hermes 自定义 AI Provider 配置方法梳理

用户实践中的配置流程

第一步：准备 Provider 基本信息

第二步：交互式添加 custom provider

第三步：修改配置文件中的 provider 名称

第四步：通过 credential pool 添加 api key

第五步：重启 gateway

底层源码视角的补充与修正

1. custom_providers 名称解析的灵活性

2. 上下文尺寸自动探测的完整链路

3. hermes auth add 的密钥存储机制

4. 关于“重启 gateway”的适用范围

流程对照总结

额外建议

为 auxiliary 任务配置自定义 Provider 的注意事项

多模型配置建议

4.2 `browser_vision`：截图回传的静态辅助

1. `custom_providers` 名称解析的灵活性

3. `hermes auth add` 的密钥存储机制

跨会话检索：`session_search`

1. 上下文压缩 (`compression`)

1. 线程回复行为 (`reply_in_thread`)

2. 响应触发机制 (`require_mention`)

3. 自定义触发模式 (`mention_patterns`)

4. 可对话用户白名单 (`SLACK_ALLOWED_USERS`)