当 Session 成了枷锁：从 OpenClaw 的上下文焦虑到 Hermes Agent 的解法

一个真实的痛点

用 OpenClaw 久了，有一个操作已经刻进了肌肉记忆：/new。

每隔一段时间，你必须手动开一个新 session。原因很朴素——上下文窗口越来越大，token 费用水涨船高，模型开始胡说八道。这是所有对话式 AI Agent 用户都会遇到的"上下文膨胀"问题。

但 /new 本身又制造了新的痛苦，而且是更隐蔽、更折磨人的那种：

痛苦一：Session 回溯困难。 特别是在企业微信、飞书这类 IM 里使用时，历史 session 散落在聊天记录的各个角落，想找回三天前那个关于"数据库迁移"的对话？祝你好运。

痛苦二：任务切换的两难困境。 把一个 session 想象成一个正在进行的任务。当这个任务被阻塞了（比如等 CI 跑完、等同事回复），你想临时做另一件事。这时候你面对的是一个经典的 lose-lose：

• 在当前 session 里做 → 上下文被污染（"串稀"），原来的任务线索被冲淡，模型开始混淆两件事。
• /new 开新 session → 新任务可以干净地做，但原来那个被阻塞的任务？你再也回不去了。那个 session 的上下文、中间状态、已经建立的理解，全部丢失。

所以你面临的是一个根本性的 UX 困境：

这不是 bug，这是 OpenClaw "gateway-first" 架构的必然结果：它把 session 当成一个消息路由的容器，而不是一个任务的工作空间。

本质上，这是一个单线程系统被迫处理多任务的问题。而 /new 是一把只能往前切的刀——切了就没有回头路。

先回答一个问题：OpenClaw 上真的无解吗？

不完全是。OpenClaw 有一个 session-logs 技能，可以用 jq 搜索和分析历史 session 日志。它也支持 subagent 驱动的开发模式（subagent-driven-development），可以把独立任务拆到子 agent 去执行。还有 executing-plans 技能，能在独立 session 中执行计划并设置检查点。

但这些更像是"补丁"而非"架构级解决方案"。session 日志搜索是事后补救，subagent 是任务分发而非任务暂停/恢复。核心问题——session 作为一等公民的生命周期管理——在 OpenClaw 的设计中并不是重点。

Hermes Agent 如何从架构层面解决这个问题

Hermes Agent 对 session 的处理方式完全不同。它不是把 session 当作一次性的聊天窗口，而是当作可持久化、可检索、可恢复的工作单元。以下是它针对上述每个痛点的具体解法：

1. 上下文膨胀？自动压缩，不用你操心

Hermes 内置了一套双层压缩系统，彻底消除了手动 /new 的必要性：

• Agent 层压缩（50% 阈值）：当 prompt token 数达到上下文窗口的 50% 时，自动触发。它会保留头部（系统提示 + 首轮对话）和尾部（最近 20 条消息），把中间部分用辅助模型压缩成一份结构化摘要——包含目标、进展、阻塞项、关键决策、相关文件等。
• Gateway 层压缩（85% 阈值）：作为安全网，防止在 IM 平台上消息堆积导致 API 报错。

压缩不是简单的截断，而是迭代式的结构化总结。第二次压缩时，它会更新上一次的摘要，把"进行中"的项目移到"已完成"，加入新进展，删除过时信息。这意味着一个 session 可以跑很长时间，上下文始终保持精炼。

你不再需要 /new 来控制成本和防止幻觉。系统自己会做。

2. 任务被阻塞？随时挂起，随时恢复

这是 Hermes 最直接解决你痛点的能力——Session Resume：

# 给当前任务起个名字
/title 数据库迁移方案

# 去做别的事（自然结束或开新 session）
# ...

# 随时回来
hermes -c "数据库迁移方案"

在 IM 平台（企业微信、飞书、Telegram 等）上同样可以用 /title 命令。

恢复 session 时，Hermes 会显示一个对话回顾面板：用金色圆点标记你的消息，绿色菱形标记 agent 的回复，折叠工具调用，截断过长内容。你能在几秒内回忆起"上次做到哪了"。

更妙的是自动谱系命名：当 session 因为压缩而分裂成新 session 时，Hermes 自动编号——数据库迁移方案 → 数据库迁移方案 #2 → 数据库迁移方案 #3。用 hermes -c "数据库迁移方案" 恢复时，自动跳到最新的那个。

任务阻塞时，你可以放心离开。它会在原地等你。

3. Session 回溯困难？全文搜索 + 跨 Session 召回

Hermes 把所有 session 存储在 SQLite 数据库中（带 FTS5 全文搜索索引），提供了完整的管理命令：

# 列出最近的 session
hermes sessions list

# 按平台过滤
hermes sessions list --source wecom

# 全文搜索（agent 内置工具，自动触发）
# 当你提到"上次那个..."时，agent 会自动搜索历史 session

session_search 工具支持 FTS5 查询语法（短语搜索、布尔运算、前缀匹配），搜索结果会经过 LLM 总结后返回，不是丢给你一堆原始文本。

你不再需要在企业微信的聊天记录里翻找。所有 session 都有结构化索引。

4. 想同时做两件事？Subagent 并行委派

当你在一个任务中需要临时处理另一件事，但又不想污染当前上下文时，Hermes 的 delegate_task 提供了第三条路：

delegate_task(
    goal="检查 staging 环境的 nginx 配置是否正确",
    context="服务器 IP: 10.0.1.5，关注 SSL 证书和反向代理配置",
    toolsets=["terminal"]
)

子 agent 拥有完全隔离的上下文，独立的终端 session，最多 3 个并行执行。完成后只有最终摘要进入父 session 的上下文——不会串稀，不会膨胀。

你可以直接在对话框里用自然语言明确表达你想并行做或者你想把复杂任务委派出去做。

比如：

“帮我起三个 agent，分别去调研一下 A、B、C 三个框架的最新优缺点，最后给我个汇总表格。”

“这是一个大工程的规划文档，请用 delegate_task 开一个子 agent 帮我把第一个模块的代码写了，写完测通过了再把结果给我。”

工作流对比：同一个场景，两种体验

场景：你正在用 agent 做数据库迁移方案，写到一半，同事在群里问你一个 K8s 部署问题，你需要临时查一下。

OpenClaw 的体验

1. 当前 session 正在讨论数据库迁移
2. 同事问了 K8s 问题 → 两个选择都很糟：
   • 在当前 session 回答 → 上下文被 K8s 内容污染，回来继续迁移方案时模型可能混乱
   • /new 开新 session → K8s 问题解决了，但迁移方案的 session 找不回来了
3. 最终：要么忍受混乱，要么重新建立迁移方案的上下文

Hermes Agent 的体验

1. /title 数据库迁移方案 — 给当前任务命名
2. 去处理 K8s 问题（新 session 或在 IM 的另一个对话中）
3. hermes -c "数据库迁移方案" — 回到原来的任务，看到回顾面板，无缝继续
4. 或者更优雅：直接在当前 session 里 delegate_task 让子 agent 查 K8s 问题，结果以摘要形式返回，完全不影响主线

总结

根本区别在于设计哲学：OpenClaw 把 session 当作一次性的对话流，用完即弃；Hermes 把 session 当作可管理的工作单元，有名字、有索引、有生命周期、可以暂停和恢复。

当你的工作模式是多任务并行、频繁切换、需要长期追踪的时候，后者的架构优势是碾压级的。你不再需要在"省钱"和"保持上下文"之间做痛苦的取舍——系统替你两个都做了。