清晰策略节省API令牌 | AI生成和翻译
问题： 频繁使用 /clear（开启新会话）是使用 Claude/Hermes 代理时节省 token 的策略之一吗？
答案：
是的，完全正确。在代理式 CLI 工作流中，/clear 是最直接的节省 token 的手段之一。以下是其核心逻辑：
为什么上下文长度 = token 成本
会话中的每条消息都会追加到上下文窗口中，该窗口会在 每次后续 API 调用 时被发送。因此，一个 50 轮对话的成本不是 50 ×（最后一轮消息的 token 数），而是 50 ×（累积历史 token 数）。这在实际中呈二次方增长。
第 1 轮：发送 100 token
第 5 轮：发送 500 token
第 20 轮：发送 2000 token ← 即使每条消息都很小
/clear 作为精准工具
当你执行 /clear 时：
- 上下文重置为零（或仅保留系统提示）
- 下一次调用只消耗新消息 + 系统提示的 token
- 你会丢失历史，但获得一个干净的起点
关键在于：大多数任务并不需要完整的历史记录——它们只需要最近 1-3 轮的上下文。因此，在不同子任务之间使用 /clear 几乎总是正确的选择。
何时激进地使用 /clear
| 场景 | 是否清除？ |
|---|---|
| 从调试切换到编写 | ✅ 是 |
| 新建文件/新功能 | ✅ 是 |
| 长时间多工具探索后 | ✅ 是 |
| 在调试单个 bug 的中途 | ❌ 否——上下文是关键支撑 |
| 继续执行多步骤计划 | ❌ 否 |
与 /clear 配合的其他节省 token 策略
既然你正在构建 CLI 代理（ww、zz 等），你可能已经了解其中一些，但完整情况如下：
- 频繁使用
/clear——主要手段 - 精简系统提示——不要在每个会话中塞满 2000 token 的指令
- 工具输出截断——如果你的代理读取文件/运行 bash，在注入上下文之前主动截断标准输出
- 先总结再清除——让 Claude 总结当前状态 →
/clear→ 将总结作为第一条消息注入。有损但低成本 - 任务分解——将大型代理任务拆分为独立的子任务，每个子任务使用新的会话
- 避免重新读取未更改的文件——在客户端缓存文件内容，不要每轮都重新注入
先总结再清除的代码模式
def compress_session(client, history):
summary = client.messages.create(
model="claude-sonnet-4-20250514",
max_tokens=500,
messages=history + [{
"role": "user",
"content": "用不到200字总结当前任务状态。包括：已完成事项、下一步计划、任何关键变量/路径/决策。"
}]
)
# 现在清除历史，只注入总结
return [{
"role": "user",
"content": f"[会话恢复] 上下文：{summary.content[0].text}"
}]
这就是 Claude Code 的 “compact” 功能在内部所做的——本质上就是先总结再清除。
结论
是的，/clear 是一级策略。需要养成的思维习惯是：将每次 /clear 视为一次 git 提交边界——完成一个连贯的工作单元，清除，重新开始。不要仅仅因为方便就让上下文跨不相关任务累积。