别再被过期的教程误导了：Hermes AI Agent 新手最稳的十步走（v0.13.0 实战）

本段核心问题：为什么市面上那么多 Hermes 教程都“不好用”了？一篇面向 v0.13.0 的新手教程到底该重写成什么样？

一个已经发布很久的工具，再写“从零开始”似乎有点蹭热度。但当我翻看几篇旧教程，并对照最新的 v0.13.0 版本重新走一遍流程后，我意识到：这篇教程非写不可。

Hermes 这类工具最大的敌人不是复杂，而是“教程过期”。一份过期的教程比没有教程更麻烦——因为它大部分内容还是对的：安装命令可能还能跑，provider 也能配，CLI 也能聊两句。于是你很容易把问题归结到自己身上。可新版本已经把大量能力推进到生产化一侧：durable multi-agent Kanban、/goal、checkpoints v2、Gateway 自动恢复会话、no_agent cron、Google Chat、providers plugin、Curator 维护技能库……连安全默认项都比早期严了不少。

麻烦就藏在这里。旧教程往往把重点放在“跑起来”，而新版 Hermes 真正需要的是“养起来”。前者是安装、选模型、发第一条消息；后者还要管记忆、技能、消息入口、任务调度、profile 边界和自动化。顺序一乱，就会变成最典型的 Agent 新手灾难：工具看起来很强，人却坐在屏幕前查半天 token、allowlist、base URL 和 profile 状态。

尤其是那些一上来就讲“7×24 小时 Agent 军团”的文章。看着当然兴奋——自动接单、自动写稿、自动发布、多平台调度、飞书中台、任务看板、长期记忆，一口气全摆出来，像是明天就能把一家公司塞进电脑里。我强烈不建议第一天就这么干。 一个 bot token 填错，一个 profile 切错，一个本地模型 endpoint 写错，半天就没了。

所以这篇还是新手教程，但不是“复制这行命令就行”的那种。我想写一个更笨、更稳的顺序：从零开始把一个 Hermes 养活，先让它稳定说话、能用工具、能恢复会话、知道什么该记、什么不该记。这个地基站住了，再去接 Gateway、Memory、Skills、Profile、Cron、Kanban。

先让一个 Hermes 稳定工作。

Hermes 到底是什么？—— 不止是模型，而是一个 Agent 运行时

本段核心问题：Hermes 和那些普通聊天 AI 或“Hermes 模型”有什么区别？它到底能帮你做什么？

首先别把 Hermes Agent 和 Hermes 模型 混在一起。名字相近，东西不是一类。

在我看来，Hermes 更像一个 Agent runtime。模型只是脑子，Hermes 管的是脑子之外那些麻烦事：工具、会话、记忆、Skills、自动化任务、聊天入口、多 Agent profile 和任务看板。

普通聊天工具像临时喊来的助手，问完就散。Hermes 更像是给这个助手安排了一张固定的桌子——旁边有笔记本、有 SOP、有消息入口，也有一块任务板。临时问一句概念解释，用不上这么重的家伙；但整理日报、追踪资料、维护项目、保存偏好、定时执行低风险任务，才是它舒服的位置。

反思：我曾经以为装好 Hermes、配个 API Key 就算“会用”了。结果跑了三天就发现：会话记不住、工具调用乱报错、同一个问题在不同 profile 里答案完全不同。后来才明白，我缺的不是模型能力，而是一套从“跑起来”到“养起来”的 SOP。

Hermes 核心概念示意

第一天不要做的三件事 —— 避开新手最常见的坑

本段核心问题：刚接触 Hermes 时，哪些“高级玩法”碰都不要碰，否则会浪费大量排错时间？

新手最容易被“高级玩法”带跑。我也不例外——看到多平台 Gateway、多 profile、Kanban 调度，手就痒。可这类东西第一天全打开，排错面会膨胀得很快。

  1. 不要同时接入多个聊天平台
    Telegram、Discord、Slack、WhatsApp、飞书都能接，但任何一个 bot token、allowlist、home channel、平台权限没配好，Hermes 看起来就像坏了。选一个（比如 Telegram）跑通再说。

  2. 不要一上来就创建多个 Profile（多 Agent）
    Profile 很强，但每个 profile 都有自己的配置、密钥、记忆、sessions、skills、cron、gateway 状态。一口气创建 commander、coder、reviewer、researcher，排错面会直接翻倍。

  3. 不要第一天就尝试本地模型
    本地模型当然好玩，可第一次上手时，base URL、模型名、OpenAI-compatible 接口、上下文长度、工具调用稳定性会一起涌上来。先用一个稳定云端 provider 跑通，心里有了基准，再接 Ollama 或 vLLM，会少很多冤枉路。

我会按这个顺序走：

安装 Hermes
→ 选择模型 provider
→ 跑通 CLI / TUI 会话
→ 确认 sessions 能恢复
→ 配 SOUL / Memory
→ 用 Skills
→ 接 Gateway
→ 建 Profile
→ 上 Cron / Kanban / Docker
顺序图

第一步：先把版本跑出来 —— 安装与基本验证

本段核心问题：在 Windows、macOS 或 Linux 上，如何正确安装 Hermes 并确认环境正常？

安装本身不复杂。官方脚本就这一行（适用于 macOS、Linux 和 WSL2）：

curl -fsSL https://get.hermes.org | bash

如果你用的是 Windows，现在不用先绕去 WSL2 了。官方已经放出 Windows Native Beta，可以在 PowerShell 里直接装：

powershell -NoProfile -ExecutionPolicy Bypass -Command "iwr -useb https://get.hermes.org | iex"

需要说明：Windows 原生支持是真的，但它目前仍是 beta。CLI、TUI、Gateway、Profile、Skills 这些主线能力可以按 Windows 原生路径走；Dashboard 里的内嵌 terminal 仍然更偏 WSL2 场景。如果你只是想在 Windows 上把 Hermes 跑起来，原生安装没问题；但如果要做重度开发、长期自动化和复杂本地工具链，WSL2 仍然是更稳的备选。

安装完成后，重载 shell（Windows PowerShell 里直接重开一个窗口）：

source ~/.bashrc
# 或者
source ~/.zshrc

立刻检查版本：

hermes --version

现在的最新版输出大概是这样：

Hermes Agent v0.13.0 (2026.5.7)
Up to date

这一步别省。Hermes 改得太勤，很多“教程失效”未必是作者写错了，常常只是命令长了新枝。

准备认真用的话，doctor 也别往后拖：

hermes doctor

它不神秘，就是把环境、配置和依赖扫一遍。比自己盯着报错猜半天强。

我还会顺手跑一次：

hermes --help

不是为了背命令，而是先看一眼入口。model、gateway、cron、kanban、skills、curator、memory、profile、dashboard、logs 都在这一屏里。Hermes 现在的重心，其实也写在这一串命令里了。

help 截图

第二步：把模型接上 —— 选择稳定 Provider

本段核心问题：Hermes 本身不是模型，那么如何为它配置一个能稳定工作的模型提供商？

Hermes 不是模型，它必须接一个 provider。最稳的入口是：

hermes model

官方支持的 provider 非常多：Nous Portal、OpenRouter、OpenAI Codex、Anthropic、Kimi、Qwen、DeepSeek、Hugging Face、AWS Bedrock、GitHub Copilot、Vercel AI Gateway、自定义 OpenAI-compatible endpoint 等。

第一次用，不要追求最花哨。先跑通最要紧。 我会按这个顺序选：

  • 已有稳定 API Key → 先用它
  • 不知道选什么 → OpenRouter 或 Nous Portal
  • 想用国内模型 → Kimi / Qwen 先跑简单任务
  • 想用本地模型 → 等 CLI 跑通以后再接 Ollama / vLLM

还有一个硬条件容易被忽略：Hermes 要求模型至少 64K context。Agent 要带工具、历史、记忆、任务状态，小上下文模型很容易半路失忆。

模型配完后，先别接 Telegram。先在终端里确认它能回答：

hermes --tui

或者经典 CLI：

hermes

第一条测试不要问哲学，也不要让它写大项目。问一个能验证工具的任务：

请检查当前目录，告诉我这里最像主项目入口的 5 个文件，并说明你的判断依据。

成功标准很简单：

  • 它知道当前 provider 和模型。
  • 它能正常回复。
  • 它能在需要时调用文件或终端工具。
  • 你追问第二轮，它没有断掉。

这一步过了，才算 Hermes 有生命体征。

第三步：确认会话能恢复 —— 这是 Agent 和普通聊天的分水岭

本段核心问题：Hermes 如何记住之前的对话？怎么测试会话恢复功能是否正常？

Agent 工作台跟普通聊天最大的区别之一，是能接着干。跑完一个简单会话后，退出，再试：

hermes --continue

或者：

hermes -c

能回到刚才的上下文，说明 sessions 基础正常。后面的长期任务、多 Agent、Gateway、Cron，都会用到它。

如果恢复不了，先查：

hermes sessions list

很多人以为是记忆坏了，其实只是切了 profile，或者 session 没保存。

反思：我见过太多人把“会话恢复”和“长期记忆”搞混。会话恢复只是让你接着上次的话题聊，不丢历史；而记忆（Memory）是让 Agent 学会你的偏好和工作环境。两者配合，才是真正的连续性。

第四步：搞懂 Hermes 的几类配置文件 —— 别把东西放错地方

本段核心问题：Hermes 有多个配置文件，各自负责什么？如何避免配置混乱？

Hermes 的配置不难，难的是别把东西放错地方。

文件路径 用途 示例内容
~/.hermes/.env 存放密钥 API Key、bot token、平台 token
~/.hermes/config.yaml 普通配置 默认模型、terminal backend、gateway、工具开关
~/.hermes/SOUL.md 稳定人格和硬规则 回答前先验证，危险命令要提醒
~/.hermes/memories/MEMORY.md Agent 的工作笔记 这台机器的环境、项目习惯、踩过的坑
~/.hermes/memories/USER.md 用户偏好 默认中文、结论先行、少写长篇废话
项目根目录的 AGENTS.md 项目级规则 这个项目怎么测试、不能动哪些目录

这里最容易犯的错，是把所有东西都塞进 MEMORY.md。 我以前也这么干过，结果很快就乱了。固定规则应该放 SOUL.md，项目规范放 AGENTS.md，会变化的环境事实和工作笔记才放 MEMORY.md，用户偏好放 USER.md。

新手第一版 SOUL.md 不用写得像公司制度，几行就够：

# Hermes 行为规则

不确定的命令、路径、配置，先查再答。
三步以上任务先列计划。
高危操作先说明风险，不要直接执行。
完成任务后告诉我怎么验证。
临时猜测不要写进长期记忆。

别一开始写两千字人设。写太满，后面自己都不知道哪条规则在起作用，Hermes 也未必知道。

第五步：Memory 和 Skill 不是一回事 —— 记事实 vs 存流程

本段核心问题：如何区分“让 Agent 记住我的偏好”和“让 Agent 学会一个工作流程”？

Hermes 有意思的地方，不在于它会“记住我”这句话，而在于它能把记忆和流程分开。

  • Memory 记事实和偏好。
    例如：“以后整理 AI 工具更新时，保留英文产品名、原始链接和 Markdown 格式。” 这适合进 Memory。

  • Skill 记流程和 SOP。
    例如：“每次生成 AI 工具日报时，先抓 AI hot，再看 X 热门推文，再按 agent/coding/video/image/infra 分类，最后给出 5 个可写选题。” 这适合沉淀成 Skill。

我会这样区分：Memory = 它该知道什么；Skill = 某类任务该怎么做。

Memory vs Skill

训练 Hermes 时，天天喊“记住我”用处有限。一个任务做顺了，直接让它沉淀成 Skill，效果更稳定：

我们刚才这个流程以后会反复用。请把它保存成一个 Skill，包含触发条件、执行步骤、注意事项和验证方法。

写完别急着信，检查一下：

hermes skills list

外部技能也能搜：

hermes skills search github
hermes skills inspect <skill-name>
hermes skills install <skill-name>

最新版里还有 Curator。这个东西我挺喜欢，它管的是 agent-created skills——重复的合并，过时的归档，质量差的清掉。

hermes curator status
hermes curator run

它不是来乱删技能的。bundled 和 hub-installed skills 不会被它自动处理；归档也能恢复。把它当成技能库保洁就行，别当成技能库刽子手。

第六步：接 Gateway，让 Hermes 出现在聊天软件里

本段核心问题：如何把 Hermes 接入 Telegram、飞书等聊天平台，让它真正变成“随时可用的助手”？

CLI 跑通以后，再接 Gateway。

hermes gateway setup
hermes gateway run

长期运行可以用：

hermes gateway install
hermes gateway start
hermes gateway status

如果只是本地试，gateway run 更直观。它在前台跑，报错能直接看到。等一切稳定，再装成后台服务。

接平台时先选一个。个人用，Telegram 或 Discord 通常最快。团队协作，飞书会更顺手。具体有哪些平台，以当前版本的 hermes gateway setup 菜单为准，不要拿旧教程硬套。

Gateway 成功不看服务有没有启动，要看聊天软件里能不能给 Hermes 发消息，并收到回复。

第一条消息可以很简单：

请回复一句话，说明你已经通过当前聊天平台接入 Hermes。

再发第二条：

请记住，以后我从这个聊天入口让你整理资料时，默认输出 Markdown，并保留原始链接。

第二天换一个说法让它做同类任务，看它有没有沿用偏好。测到这一步，才算测到了 Gateway + Memory 的组合能力。

Gateway 示意

第七步：Profile 才是多 Agent 的正确起点

本段核心问题：如何创建多个不同职责的 Agent（比如一个写代码、一个做审查）？Profile 和沙箱有什么区别？

很多人说多 Agent，其实说的是多个 profile。Profile 是独立的 Hermes home。每个 profile 都有自己的 config.yaml、.env、SOUL.md、memories、sessions、skills、cron jobs、state database。

创建一个写代码助手：

hermes profile create coder --clone
coder setup
coder chat

创建一个审查助手：

hermes profile create reviewer --clone
reviewer setup
reviewer chat

--clone 的意思是复制当前配置、密钥和 SOUL，但给新 profile 一套新的 sessions 和 memory。它适合创建相似但职责不同的 agent。

如果要完整复制（包括记忆、会话、skills、cron），可以用：

hermes profile create backup --clone-all

这里必须讲一个坑：Profile 不是 sandbox。 Profile 只是状态隔离——隔离的是配置、记忆、会话、技能，不隔离文件权限。默认 local terminal backend 下，它仍会以当前用户身份访问文件系统。

如果只想让它在某个项目目录工作，要设置 terminal.cwd。如果要限制命令执行环境，就得用 Docker、SSH、Modal、Singularity 这类 backend。

记住：Profile 管身份和状态，Sandbox 管权限和边界。 不要把两者混了。

第八步：Docker 到底解决什么问题 —— 两种集成方式别搞混

本段核心问题：Docker 和 Hermes 有哪两种集成方式？分别解决什么场景？

Docker 和 Hermes 有两种关系：

  1. 把 Hermes 本体跑在 Docker 里
    适合部署长期在线的服务，也能少污染宿主机环境。

  2. Hermes 还在宿主机跑，但它执行终端命令时进 Docker 沙箱
    适合不想让 Agent 直接碰宿主机的场景。

这两个不是一回事。

把 Hermes 本体跑在 Docker 里，最小形态大概是：

mkdir -p ~/.hermes

docker run -it --rm \
  -v ~/.hermes:/opt/data \
  nousresearch/hermes-agent setup

后台 gateway：

docker run -d \
  --name hermes \
  --restart unless-stopped \
  -v ~/.hermes:/opt/data \
  -p 8642:8642 \
  nousresearch/hermes-agent gateway run

核心是这个挂载：~/.hermes:/opt/data。因为 /opt/data 是容器里的 Hermes 状态目录——.env、config、sessions、memories、skills、cron、logs 都在这里。没挂载，容器重建后，很多东西就没了。

只是想让 Hermes 命令执行更安全，可以先用：

hermes config set terminal.backend docker

这时 Hermes 本体还在宿主机，进 Docker 的只是 terminal tool。

第九步：Kanban 是最新版最值得关注的新能力

本段核心问题：如何用 Kanban 让多个 Hermes Profile 像一个小团队一样协作？

只做个人聊天，Kanban 不是第一天要开的东西。但要让多个 Hermes profiles 像一个小团队一样协作，Kanban 就很关键。

最新版里可以直接看：

hermes kanban --help

它的描述很清楚：这是一个 durable SQLite-backed task board。任务可以被原子 claim，可以设置依赖，可以由 named profile 在隔离 workspace 中执行。

最新版继续把这件事往前推，增加了 heartbeat、reclaim、zombie detection、retry budget、incomplete exit auto-block 等能力。翻译成人话就是：以前多 Agent 很像“派出去就听天由命”，现在更像有任务板、有心跳、有失败恢复、有交接记录。

入门只需要知道这几个命令：

hermes kanban init
hermes kanban boards list
hermes kanban create --help
hermes kanban list
hermes kanban show <task-id>
hermes kanban dispatch --help

不要第一天就让它自动接管大项目。 更适合的练习是：

创建一个小任务板：AI 日报生产。
任务 A：收集 10 条 AI hot。
任务 B：筛出 5 个可写选题。
任务 C：给每个选题写标题和读者痛点。
让 researcher profile 做 A，让 editor profile 做 B 和 C。

这类任务失败成本低，结构清楚，适合测试 Kanban。

Kanban 界面

第十步：Cron 适合做固定任务，不适合许愿

本段核心问题：如何为 Hermes 设置定时任务？哪些任务适合自动化，哪些不适合？

Hermes 有 cron：

hermes cron list
hermes cron add
hermes cron status
hermes cron run <job>

最新版还加入了 no_agent cron——某些 watchdog 类任务只跑脚本，不必每次都启动 Agent。

我给 cron 的第一批任务通常很保守：

  • 早上出一份 AI 工具简报
  • 晚上备份一个目录
  • 每周审计一次 Skills
  • 每天看一个网页有没有更新

这些活儿出错了也好处理。自动发布文章、自动删文件、自动操作账号，我不建议第一天就交给它。自动化不是越猛越好——能复查、能回滚、能解释，才能长期放着跑。

排错顺序 —— 别凭感觉乱改配置

本段核心问题：当 Hermes 出问题时，应该按什么顺序排查？

Hermes 出问题时，最怕凭感觉乱改 .env 和 config.yaml。我一般先跑这一串：

hermes doctor
hermes model
hermes setup
hermes sessions list
hermes --continue
hermes gateway status
hermes logs errors

常见问题速查：

  • hermes: command not found → 多半是 shell 没重载，先 source ~/.bashrc 或 source ~/.zshrc。
  • 模型不回 → 先查 provider、API Key、模型名、base URL。
  • 本地模型奇怪 → 重点看 endpoint 是否 OpenAI-compatible、context 够不够、模型名和实际加载的是否一致。
  • Gateway 启动了却收不到消息 → 别急着重装，token、allowlist、pairing、home channel、平台权限逐项看。
  • 记忆没生效 → 先确认是不是同一个 profile，再看 session 是否恢复、MEMORY.md / USER.md 有没有写入。
  • Profile 能访问外部文件 → 不奇怪，profile 管状态，sandbox 才管边界。
  • Docker 重启后配置丢了 → 大概率是 ~/.hermes 没挂到 /opt/data。
  • Skills 乱了 → 先看 hermes skills list 和 hermes skills audit，别上来手删一堆。

一个适合第一周的练习：AI 日报助手

本段核心问题：如何通过一个真实、低成本的小任务，逐步把 Hermes 从“能说话”训练成“能干活的助手”？

我觉得第一周最适合拿 AI 日报练手。它够真实，又不危险——做坏了最多是一份简报难看，不会把项目删掉。

第一天：在 CLI 里直接丢这个任务：

请帮我生成一份今天的 AI 工具更新简报。
要求：

  1. 每条保留产品名、原始链接、更新时间
  2. 按 agent / coding / video / image / infra 分类
  3. 输出 Markdown
  4. 末尾写一下哪些偏好值得下次继续保留

它做完以后，不要只看内容，要纠正格式。比如：

以后这类简报不要写空泛评价。每条只保留事实、链接和一句“值得看的原因”。
请把这个偏好写入你的记忆。

第二天换一个要求：

继续昨天的 AI 工具更新简报。
但这次只保留最值得写成公众号文章的 5 条。
每条给出：标题方向、读者痛点、实操交付物。

连续做三天，差不多就能沉淀成 Skill：

我们已经连续做了三次 AI 工具更新简报。
请把稳定流程保存成一个 Skill，名字叫 ai-daily-brief。
要求包含触发条件、信息来源、筛选规则、输出格式和验证方法。

这比第一天喊“帮我打造一个 AI 帝国”实在得多。小任务安全、低成本、可复查，Hermes 也能在这个过程中慢慢记住偏好，沉淀流程，之后再接聊天软件、定时任务、Profile、Kanban，心里会有底。

收一下 —— 连续性才是 Hermes 的真正价值

我看重 Hermes，主要是因为“连续性”。很多 AI 工具并不笨，只是太容易断。今天刚教会一个格式，明天换个窗口又忘；今天修过一个坑，后天又绕回来犯一次。

Hermes 把 memory、skills、sessions、gateway、profiles、kanban 放在一起，正是冲着这个断裂去的。但它也不是免维护机器。模型要选，密钥要管，工具要配，日志要查，权限要审，Skills 要清理，任务边界也要设计。它会成长，可它长成什么样，很大程度上取决于人怎么喂任务、怎么给反馈、允许它保存什么流程。

我的建议仍然很土：先跑通一个会话，再养成一个流程，再组织一支队伍。

第一天做到三件事就够了：

hermes model
hermes --tui
hermes doctor

能说话，能用工具，能恢复，能排错。这个地基打好，Hermes 才有资格变成长期 AI 工作台。

实用摘要 / 操作清单（一周内可落地）

第一天

  • [ ] 执行 curl -fsSL https://get.hermes.org | bash 安装
  • [ ] 运行 hermes doctor 检查环境
  • [ ] 配置一个云端模型 provider（如 OpenRouter）
  • [ ] 执行 hermes --tui 测试对话和工具调用
  • [ ] 测试 hermes --continue 恢复会话

第二天

  • [ ] 编写 ~/.hermes/SOUL.md（5～10 行规则）
  • [ ] 通过对话让 Hermes 记住一个偏好（写入 USER.md）
  • [ ] 学习 hermes skills list 和 hermes skills search

第三天

  • [ ] 设置 Gateway（选一个聊天平台，如 Telegram）
  • [ ] 在聊天软件中发送第一条消息并收到回复
  • [ ] 测试 Gateway + Memory：让 Hermes 记住平台专用偏好

第四～五天

  • [ ] 创建第二个 profile（如 coder）
  • [ ] 理解 profile 与 sandbox 的区别
  • [ ] 可选：尝试 Docker 沙箱执行

第六～七天

  • [ ] 用 AI 日报任务沉淀一个 Skill
  • [ ] 尝试 cron 定时执行低风险任务
  • [ ] 可选：用 Kanban 创建一个小型多任务板

一页速览（One‑page Summary）

模块 一句话核心 关键命令
安装 用官方脚本，Windows 有原生 Beta curl ... | bash
模型 先选云端 64K+ 模型跑通 hermes model
会话 能恢复会话才算有“连续性” hermes --continue
配置 区分 .env、config.yaml、SOUL.md、MEMORY.md hermes doctor
Memory vs Skill 记忆记事实，技能存流程 hermes skills save
Gateway 把 Hermes 接到聊天软件 hermes gateway setup
Profile 多 Agent 的正确起点，但不是沙箱 hermes profile create
Docker 两种模式：跑本体 or 沙箱执行 terminal.backend docker
Kanban 让多个 profile 像团队一样协作 hermes kanban init
Cron 定时任务，从低风险开始 hermes cron add

常见问答（FAQ）

Q1：Hermes 和普通的 ChatGPT 有什么区别？
Hermes 是一个 Agent 运行时，而不仅仅是模型。它自带会话管理、长期记忆、可复用的技能（Skill）、多聊天平台接入（Gateway）、多身份 Profile、任务看板（Kanban）和定时任务（Cron）。你可以把它理解为“给 AI 助手配了一张固定的办公桌和全套工具”。

Q2：我必须用云端模型吗？能不能完全本地运行？
可以。Hermes 支持 Ollama、vLLM 等本地 OpenAI-compatible 端点。但新手建议先用云端模型跑通全流程，确认环境正常后再切换到本地模型，否则排错时会多一层变量。

Q3：Windows 用户到底该用 WSL2 还是原生 Beta？
如果你只是跑 CLI、TUI、Gateway、Profile 和 Skills，原生 Beta 够了。但如果要做重度开发、长期自动化、或者依赖 Dashboard 内嵌 terminal 的功能，WSL2 仍然是更稳的选择。

Q4：我的 Hermes 总是“失忆”，明明教过它偏好，第二天又忘了。
先检查两点：① 是否每次都用同一个 profile？② 是否使用了 --continue 恢复会话？偏好写入 USER.md 后，只有同一个 profile 且会话恢复（或新会话读取了该文件）才会生效。另外避免把固定规则写进 MEMORY.md。

Q5：多个 Profile 之间会互相干扰吗？
默认隔离：每个 profile 有独立的配置、记忆、会话、技能和 cron。但文件系统权限不隔离——它们都以宿主机当前用户身份访问文件。如果需要限制文件访问，请使用 Docker 等 terminal backend。

Q6：Kanban 适合单人使用吗？
适合。即使只有一个 profile，Kanban 也能帮你把复杂任务拆成有序步骤，避免 Agent 一次性处理太多上下文导致混乱。你可以用 hermes kanban create 建任务，再让 Agent 逐个处理。

Q7：Cron 任务失败了怎么办？
先用 hermes cron status 查看任务状态，再用 hermes logs errors 看错误日志。推荐第一周只让 cron 执行只读或低风险任务（如生成简报、检查更新），避免自动写入或删除操作。

Q8：我的 Gateway 启动成功，但聊天软件收不到回复。
逐项排查：bot token 是否正确？allowlist 是否包含你的用户 ID？home channel 是否设置？平台侧权限（如 Telegram 的 “/start”）是否已触发？用 hermes gateway status 和 hermes logs errors 能看到大部分问题。