Hermes Agent：设计一个能陪你走得更远的聊天机器人

很多人第一次用聊天 Agent 时，遇到的最大问题不是「怎么问」，而是「第二天再打开，机器人不认识我了」。对话记录还在，但上下文丢了；昨天定的计划没踪影；同一个问题要重新解释一遍。如果你也遇到过这种挫败感，说明你已经在触碰长期会话的核心挑战了。

Hermes Agent 对这个问题的回答是：从设计的第一天起，就把「能长期跑」当作一个系统问题来对待，而不是靠每次对话重新 prompt。这篇内容会拆解四个关键模块——会话结构、跨平台入口、记忆管理、上下文稳定性——让你在落地 Hermes 时少走弯路。

会话不只是聊天记录

我们习惯把对话理解成「我说了什么、它答了什么」的线性序列。实际上，聊天平台里的「会话」要复杂得多。

一个完整的会话至少包含这几层：

• session 标识：平台用来区分「这是同一轮对话」的唯一 ID，断线重连后靠它恢复
• 用户关系：谁在说话、有什么权限、上下文怎么关联到特定用户
• 后台任务：你让机器人执行的一个耗时操作，它在后台跑着，结果要异步推回来
• 线程恢复：对话被中断后，怎么从断点继续，而不是从头开始

Hermes 的 Messaging Gateway 把这些能力统一管起来。接入任何一个聊天平台，你不需要自己处理 platform-specific 的细节，Gateway 替你抽象掉了。

Messaging Gateway：18个平台的统一入口

Hermes 支持接入 18 个消息平台：Telegram、Discord、Slack、WhatsApp、Signal、Email，以及钉钉、飞书、企业微信、微信等国内主流平台。每个平台在语音、图片、文件、线程、反应等功能支持上各有差异，比如有些平台不支持会话线程，有些平台没有语音消息能力。Gateway 帮你抹平这些差异，让你的对话逻辑不用跟着平台改。

几个核心命令直接决定了会话能不能跨时间连续运转：

• /new 或 /reset：开始新对话，清空当前会话
• /resume [name]：恢复一个已命名的会话，接上之前的上下文
• /title [name]：给当前会话起个名字，方便后续找回
• /status：查看当前会话的基本信息
• /compress：手动压缩对话上下文，减少 token 消耗
• /background <prompt>：把耗时任务丢到后台，不阻塞对话，任务完成后结果自动推回来
• /stop：停止正在运行的 Agent
• /sethome：把当前聊天设为主频道，跑偏了能一键回到主线

会话不会一直跑下去，有三种重置策略：

• 每日重置：默认每天凌晨 4:00 清空一次
• 空闲重置：默认 1440 分钟（约 24 小时）无活动后自动重置
• 组合模式：上述任一条件触发就重置

这些策略可以针对不同平台单独配置。比如 Telegram 配置空闲 240 分钟，Discord 配置空闲 60 分钟——两个平台的行为可以不一样。

团队协作时还有个实用的配对机制：成员直接 DM 机器人，收到一次性配对码后由管理员审批通过：

hermes pairing approve telegram XKGH5N7P

让机器人记住真正重要的事

很多人在用 Agent 时犯的错，是把聊天记录整段塞进记忆。短期内有效，但时间一长，记忆库被垃圾淹没，真正重要的偏好和线索反而找不到了。

Hermes 的 Memory 功能设计上就考虑到了这一点。它不是「存所有」，而是「存值得存的」。

系统有两层记忆文件，均存放在 ~/.hermes/memories/ 目录：

• MEMORY.md：代理的个人笔记，存储环境事实、项目约定、经验教训，限制约 2,200 字符
• USER.md：用户档案，存储偏好和沟通风格，限制约 1,375 字符

通过 memory 工具管理条目，三种操作都是用子字符串匹配：

• 添加：memory add "User prefers Chinese responses"
• 替换：memory replace "old_text" "new_text" — 不需要写完整原文，只要能唯一标识
• 删除：memory remove "不再需要的条目关键字"

容量超出限制时系统会报错并显示当前条目列表。处理流程：先查看用量，识别可合并的条目（比如两条关于 Python 版本的记录可以合并成一条），再用 replace 整合，然后添加新内容。容量超过 80% 时应该主动整合，而不是继续堆砌。

Memory 适合存关键事实，但不适合做会话回溯。如果你想找某次具体的讨论，应该用会话搜索功能——它存储在 ~/.hermes/state.db，是 SQLite 数据库，支持 FTS5 全文搜索，和 Memory 是两个独立的能力。

值得进长期记忆的有三类信息：

1. 稳定偏好：比如你习惯用英文回复技术问题，或者你不喜欢机器人发太长的消息
2. 身份背景：你是做什么的、在哪个团队、主要关心什么问题
3. 长期任务线索：比如「这个项目下个月上线」，需要多轮对话逐步推进的目标

不适合进记忆的：临时的 debug 问答、操作步骤的流水账、一次性问题的答案。这些过了就没价值，占用容量反而拖累后续对话质量。

还有一个容易被忽略的点：Memory 的变更在当前会话不会生效，要到下一会话才能看到——它是个快照，不是实时更新的。

上下文文件：场景化的稳定器

有时候你会希望机器人在进入某个特定场景时自动加载一套规则。比如一进某个代码仓库，Hermes 就知道「这个项目用 Python 3.11、依赖管理用 Poetry、测试要跑 pytest」——而不是每次都靠你在 prompt 里说明。

Hermes 的上下文文件解决的就是这个。支持的类型有：

优先级规则是：每个会话只加载一个项目上下文类型（首个匹配者胜出），即 .hermes.md → AGENTS.md → CLAUDE.md → .cursorrules。SOUL.md 作为 Agent 身份文件始终独立加载，不在这个优先级体系内。

一个 AGENTS.md 的实际内容可能长这样：

# 项目类型
FastAPI backend，使用 SQLAlchemy ORM

# 编码规范
数据库操作统一用 async/await

# 测试要求
使用 pytest-asyncio，所有异步函数必须有对应测试

如果你想定义 Agent 的沟通风格，可以在 SOUL.md 里写清楚。比如 "You are a senior backend engineer. Be terse and direct. Prefer one-liners over verbose solutions." — 简洁直接，不废话。Hermes 每次启动都会从这里加载人格设定。

文件超长会被截断：超过 20,000 字符的文件，保留前 70% 和后 20%，中间部分丢弃。这是为了防止提示词膨胀，同时保留开头和结尾的关键信息。

会话期间还有渐进发现机制。当 Agent 通过工具访问某个文件路径时，会自动向上追溯检查（最多 5 层父目录），找到相关目录的上下文文件后注入。这让子目录的特定规则能在需要时自然出现，而不是一开始全塞进系统提示词——后者会让每轮对话的 token 消耗居高不下。

让系统持续健康运转

前面的设计都做好了，还差一步：怎么让这套系统长期健康运转。

平台跟进要持续。Telegram、Discord、Slack 这类平台各自在迭代，一个平台的 API 行为变了，Gateway 层可能需要适配。维护成本要在项目规划里提前考虑。

会话边界要清晰。什么时候该清空上下文、什么时候该保留记忆、什么时候让用户重新认证——这些边界条件要提前想清楚，不然遇到极端情况会手足无措。

后台任务反馈要可靠。你丢了一个任务到后台，跑完了结果推不回来，这是最打击信任感的。用 /background 丢任务后，确认消息推送通道是否畅通，是运营检查的必选项。

定期复盘交互模式。失败的对话有哪些共性？是 prompt 表达不清晰，还是上下文文件没覆盖到，还是任务拆得太粗？复盘几次之后，团队会积累出自己的最佳实践。

还有两个日常运维的常用命令：/usage 查看 token 消耗，/insights 看过去 30 天的使用趋势。两者结合能帮你判断什么时候该压缩上下文、什么时候该优化上下文文件。

对于团队使用，还有一个安全建议：消息平台一定要配置允许用户列表，永远不要设 GATEWAY_ALLOW_ALL_USERS=true。配置示例：

TELEGRAM_ALLOWED_USERS=123456789,987654321
DISCORD_ALLOWED_USERS=123456789012345678

危险命令审批也有四种选项：一次性（once）、当前会话（session）、始终允许（always）、直接拒绝（deny）。建议默认选 session，避免误加永久白名单。

最后

聊天机器人能不能长期跑，不取决于某一个功能点，而取决于你在设计阶段有没有把会话当成一个系统来对待。Messaging Gateway 管住入口，Memory 管住记忆，上下文文件管住场景，运营机制管住健康度——这四个模块各司其职，串联起来才是完整的长期会话方案。

Hermes 在这几个方向上都有对应的设计。落地时不用一口气全上，从最痛的点开始迭代就好。