OpenClaw 使用 codex 额度 5.6 sol 长会话越跑越贵？我做了一个可验证的安全换代器
大家好，我最近把自己在长期运行 OpenClaw 项目会话时遇到的一类问题，整理成了一个独立开源项目：**OpenClaw Session Keeper**。
项目地址：[OpenClaw Session Keeper](https://github.com/MoeAisaka/openclaw-session-keeper)
它要解决的不是“怎么让模型多记住一点”，而是一个更具体的工程问题：
> 当一个 AI Agent 项目持续运行数十轮甚至数百轮，如何在上下文不断增长、请求成本进入长上下文加价区间之前，安全地换一代物理会话，同时保留稳定的项目入口、任务状态和用户手动选择的模型配置？
### 为什么需要它
长会话一开始很舒服：项目背景、历史决策和当前任务都在同一条上下文里。但随着轮次增长，会逐渐出现三个问题：
1. **每一轮都要重复处理更长的输入上下文。** 即使回答很短，请求成本也可能持续上升。
2. **部分模型存在长上下文阶梯计费。** 一旦单次请求越过阈值，输入和输出都可能按更高倍率计算。
3. **直接重置会话很危险。** 最近对话、工作流状态、模型选择或关键产物路径如果没有可靠交接，任务很容易“换代即失忆”。
手动复制一段摘要可以临时缓解，但它无法稳定回答这些问题：摘要是否完整？旧转录是否真的归档？新会话是否创建成功？模型和 Thinking 配置是否继承？如果中间一步失败，应该继续还是停止？
Session Keeper 把这件事做成了一条可验证、失败即停止的工程链路。
### 它是怎么工作的
OpenClaw 中可以把项目入口理解为两层：
- `sessionKey`：稳定的项目入口；
- `sessionId`：当前承载上下文的物理会话。
Session Keeper 保留稳定的 `sessionKey`，只在满足条件时轮换背后的物理 `sessionId`。完整流程是：
1. 持续检查 Token 、物理会话年龄和空闲状态；
2. 到达检查点后，提取有上限的近期可见对话、活动工作流和相关长期记忆；
3. 备份完整转录，并计算 SHA-256 校验值；
4. 只有在会话空闲、备份完成、记忆可用且所有校验通过时，才调用 OpenClaw Gateway 的正式接口重置物理会话；
5. 回读并验证新的 `sessionId`，恢复用户手动选择的模型、Thinking 与 Fast 设置；
6. 注入一条有幂等标记的可见续接通知，让操作者知道换代已经完成。
其中任何一步失败，换代都会停止，不会带着不完整状态继续向前。
### 它不是什么
Session Keeper 不是一个把所有历史“魔法压缩”进提示词的摘要器，也不会声称零损失继承全部上下文。
它采用的是更保守的策略：**完整转录留在本地归档，新会话只恢复继续工作所需的有限上下文，并把文件和外部状态视为事实来源。** 这样做牺牲了一部分无边界的聊天连续感，换来了可审计、可恢复和可验证。
### Token 与阶梯计费效果
仓库内置了一个可配置、可复算的成本估算器。默认参考场景为：
- 连续 40 轮；
- 首轮输入上下文 48,000 Token；
- 每轮上下文增加 8,000 Token；
- 每轮输出 2,000 Token；
- 已完成请求达到 235,000 总 Token 后换代；
- 换代后首轮输入恢复为 48,000 Token；
- 冷启动按未缓存输入计费，不假设完美缓存。
结果如下：
| 指标 | 不使用 Keeper | 使用 Keeper | 差异 |
| --------------------- | -------------- | ------------ | ------------ |
| 处理的总 Token | 8,240,000 | 5,240,000 | **-36.4%** |
| 长上下文加价请求 | 11 次 | 0 次 | **-11 次** |
| 估算 Credits | 264.65 | 169.50 | **-36.0%** |
| 物理会话换代 | 0 次 | 1 次 | +1 次 |
这组数据是公开假设下的参考场景，**不是所有工作负载都能节省 36% 的承诺，也不是实际账单**。真实结果会受到系统提示词、工具 Schema 、缓存命中率、上下文增长速度、模型价格和换代时机影响。
你可以直接复算，也可以替换为自己的用量参数：
```bash
python3 cost_estimator.py
python3 cost_estimator.py --json
```
对于没有阶梯加价的模型，把长上下文倍率设为 `1`，仍可评估减少重复上下文带来的 Token 变化。
### 安全边界
这个工具不需要模型 Provider API Key，配置文件也不应该保存任何 Key。当前实现还包括：
- 运行中的会话绝不重置；
- SQLite 运行态以只读方式访问；
- 外部命令使用参数数组调用，不经过 Shell 拼接，并设置超时；
- 状态文件采用原子写入并限制为当前用户可读；
- 转录副本写入后重新计算哈希；
- 提交与推送前执行自定义脱敏扫描和 gitleaks；
- GitHub Actions 使用只读权限，关键 Action 固定到完整提交 SHA；
- `main` 禁止强推和删除，合并前必须通过测试与秘密扫描。
当前公开主分支已通过 32 项自动化测试，GitHub CI 覆盖 Python 3.10 、3.12 和 3.13。
### 快速开始
运行环境：Python 3.10+、OpenClaw、nmem；当前主要面向 macOS/Linux 等 POSIX 环境。
```bash
git clone https://github.com/MoeAisaka/openclaw-session-keeper.git
cd openclaw-session-keeper
mkdir -p "$HOME/.config/openclaw-session-keeper"
pc config.example.json "$HOME/.config/openclaw-session-keeper/config.json"
chmod 600 "$HOME/.config/openclaw-session-keeper/config.json"
# 先替换示例会话，再做只读演练
python3 session_rollover.py scan --dry-run
```
建议先用非关键会话验证 dry-run、路径和阈值，再接入周期任务。生产环境不要直接照抄示例阈值，应根据模型上下文窗口、计费规则和自己的平均增长速度调整。
### 适合谁
- 长期使用 OpenClaw 项目会话的个人开发者；
- 需要让 AI Agent 跨多轮持续执行任务的团队；
- 使用长上下文或阶梯式计费模型，希望控制 Token 消耗的人；
- 需要保留用户手动模型选择，并在会话重置后继续工作的多模型环境。
项目仍处于早期版本，欢迎提交 Issue、真实负载数据和兼容性反馈。如果你愿意，也可以用自己的会话增长参数跑一次成本估算，把结果和实际账单差异分享出来。
---
原文链接：[点击查看](https://www.v2ex.com/t/1227192)
项目地址：[OpenClaw Session Keeper](https://github.com/MoeAisaka/openclaw-session-keeper)
它要解决的不是“怎么让模型多记住一点”，而是一个更具体的工程问题：
> 当一个 AI Agent 项目持续运行数十轮甚至数百轮，如何在上下文不断增长、请求成本进入长上下文加价区间之前，安全地换一代物理会话，同时保留稳定的项目入口、任务状态和用户手动选择的模型配置？
### 为什么需要它
长会话一开始很舒服：项目背景、历史决策和当前任务都在同一条上下文里。但随着轮次增长，会逐渐出现三个问题：
1. **每一轮都要重复处理更长的输入上下文。** 即使回答很短，请求成本也可能持续上升。
2. **部分模型存在长上下文阶梯计费。** 一旦单次请求越过阈值，输入和输出都可能按更高倍率计算。
3. **直接重置会话很危险。** 最近对话、工作流状态、模型选择或关键产物路径如果没有可靠交接，任务很容易“换代即失忆”。
手动复制一段摘要可以临时缓解，但它无法稳定回答这些问题：摘要是否完整？旧转录是否真的归档？新会话是否创建成功？模型和 Thinking 配置是否继承？如果中间一步失败，应该继续还是停止？
Session Keeper 把这件事做成了一条可验证、失败即停止的工程链路。
### 它是怎么工作的
OpenClaw 中可以把项目入口理解为两层：
- `sessionKey`：稳定的项目入口；
- `sessionId`：当前承载上下文的物理会话。
Session Keeper 保留稳定的 `sessionKey`，只在满足条件时轮换背后的物理 `sessionId`。完整流程是：
1. 持续检查 Token 、物理会话年龄和空闲状态；
2. 到达检查点后，提取有上限的近期可见对话、活动工作流和相关长期记忆；
3. 备份完整转录，并计算 SHA-256 校验值；
4. 只有在会话空闲、备份完成、记忆可用且所有校验通过时，才调用 OpenClaw Gateway 的正式接口重置物理会话；
5. 回读并验证新的 `sessionId`，恢复用户手动选择的模型、Thinking 与 Fast 设置；
6. 注入一条有幂等标记的可见续接通知，让操作者知道换代已经完成。
其中任何一步失败，换代都会停止，不会带着不完整状态继续向前。
### 它不是什么
Session Keeper 不是一个把所有历史“魔法压缩”进提示词的摘要器，也不会声称零损失继承全部上下文。
它采用的是更保守的策略：**完整转录留在本地归档，新会话只恢复继续工作所需的有限上下文，并把文件和外部状态视为事实来源。** 这样做牺牲了一部分无边界的聊天连续感，换来了可审计、可恢复和可验证。
### Token 与阶梯计费效果
仓库内置了一个可配置、可复算的成本估算器。默认参考场景为：
- 连续 40 轮；
- 首轮输入上下文 48,000 Token；
- 每轮上下文增加 8,000 Token；
- 每轮输出 2,000 Token；
- 已完成请求达到 235,000 总 Token 后换代；
- 换代后首轮输入恢复为 48,000 Token；
- 冷启动按未缓存输入计费，不假设完美缓存。
结果如下：
| 指标 | 不使用 Keeper | 使用 Keeper | 差异 |
| --------------------- | -------------- | ------------ | ------------ |
| 处理的总 Token | 8,240,000 | 5,240,000 | **-36.4%** |
| 长上下文加价请求 | 11 次 | 0 次 | **-11 次** |
| 估算 Credits | 264.65 | 169.50 | **-36.0%** |
| 物理会话换代 | 0 次 | 1 次 | +1 次 |
这组数据是公开假设下的参考场景，**不是所有工作负载都能节省 36% 的承诺，也不是实际账单**。真实结果会受到系统提示词、工具 Schema 、缓存命中率、上下文增长速度、模型价格和换代时机影响。
你可以直接复算，也可以替换为自己的用量参数：
```bash
python3 cost_estimator.py
python3 cost_estimator.py --json
```
对于没有阶梯加价的模型，把长上下文倍率设为 `1`，仍可评估减少重复上下文带来的 Token 变化。
### 安全边界
这个工具不需要模型 Provider API Key，配置文件也不应该保存任何 Key。当前实现还包括：
- 运行中的会话绝不重置；
- SQLite 运行态以只读方式访问；
- 外部命令使用参数数组调用，不经过 Shell 拼接，并设置超时；
- 状态文件采用原子写入并限制为当前用户可读；
- 转录副本写入后重新计算哈希；
- 提交与推送前执行自定义脱敏扫描和 gitleaks；
- GitHub Actions 使用只读权限，关键 Action 固定到完整提交 SHA；
- `main` 禁止强推和删除，合并前必须通过测试与秘密扫描。
当前公开主分支已通过 32 项自动化测试，GitHub CI 覆盖 Python 3.10 、3.12 和 3.13。
### 快速开始
运行环境：Python 3.10+、OpenClaw、nmem；当前主要面向 macOS/Linux 等 POSIX 环境。
```bash
git clone https://github.com/MoeAisaka/openclaw-session-keeper.git
cd openclaw-session-keeper
mkdir -p "$HOME/.config/openclaw-session-keeper"
pc config.example.json "$HOME/.config/openclaw-session-keeper/config.json"
chmod 600 "$HOME/.config/openclaw-session-keeper/config.json"
# 先替换示例会话，再做只读演练
python3 session_rollover.py scan --dry-run
```
建议先用非关键会话验证 dry-run、路径和阈值，再接入周期任务。生产环境不要直接照抄示例阈值，应根据模型上下文窗口、计费规则和自己的平均增长速度调整。
### 适合谁
- 长期使用 OpenClaw 项目会话的个人开发者；
- 需要让 AI Agent 跨多轮持续执行任务的团队；
- 使用长上下文或阶梯式计费模型，希望控制 Token 消耗的人；
- 需要保留用户手动模型选择，并在会话重置后继续工作的多模型环境。
项目仍处于早期版本，欢迎提交 Issue、真实负载数据和兼容性反馈。如果你愿意，也可以用自己的会话增长参数跑一次成本估算，把结果和实际账单差异分享出来。
---
原文链接：[点击查看](https://www.v2ex.com/t/1227192)
· 0 个赞
· 0 个赞