OpenClaw 使用技巧：降低 Token 消耗，立竿见影

说明：如果您还没有部署OpenClaw，可以参考我们的优惠界面。
随着使用时间变长，OpenClaw 会积累越来越多的上下文和记忆。如果不加控制，同一个问题的 Token 消耗可能从几千一路涨到几万甚至几十万。本篇从「立刻能见效」出发，介绍几种简单实用的降本方法。

一、斜杠命令：快速“瘦身”当前会话

对于日常对话场景，最快见效的办法就是用好几条内置的斜杠命令。它们的用法都很简单：直接在聊天框里发送给 OpenClaw 即可（无需加其他前缀）。

1. /compact：压缩当前会话上下文

作用：
让 OpenClaw 对当前会话历史做一次“总结压缩”，尽量保留关键信息，丢掉多余的细节，从而在后续对话中显著降低 Token 消耗。

使用场景：

• 和机器人聊了很久，一个问题前面要带一大段历史；
• 明显感觉响应变慢、价格飙升，但又不想完全清空上下文；
• 当前话题还要继续，但不需要保留所有细节。

用法：

在当前聊天窗口直接发送：

/compact

OpenClaw 会尝试把之前的对话收敛为较短的“摘要记忆”，并在后续对话中优先使用这个摘要，减少每次请求的上下文长度。

---

2. /reset：保留记忆，重置当前话题

作用：
重置当前会话的短期上下文，但保留长期记忆和全局配置。可以理解为「这段对话从头来过，但你之前帮我记住的关键信息仍然存在」。

使用场景：

• 当前话题已经结束，接下来要聊完全不同的事情；
• 上下文已经很臃肿，继续往下聊 Token 会越来越高；
• 但你又不希望清空所有历史记忆（比如个人偏好、团队代号、项目背景等）。

用法：

在当前聊天窗口直接发送：

/reset

执行后：

• 当前对话线程的历史上下文会被清空；
• Agent 的长期记忆（写入 MEMORY / 重要存档）仍然会保留；
• 后续问题会在“新话题”的上下文里继续。

---

3. /new：开启一段全新的对话

作用：
创建一个真正“从零开始”的新会话，可以类比为「新建一个对话标签页」。

使用场景：

• 想在同一个频道里，彻底开启一个全新的对话；
• 不希望任何历史上下文干扰当前的问题；
• 需要做 AB 对比测试——一个会话保留上下文，另外一个完全从头。

用法：

在当前聊天窗口直接发送：

/new

执行后，OpenClaw 会以“新会话”的身份与你对话。通常来说，这比在原线程里不断滚动历史、继续追加问题要更加节省 Token。

---

二、多 Agent 分工：从架构层面降低 Token 消耗

当你开始用 OpenClaw 同时承载「写文档」「写代码」「运营维护」「团队管理」等多种任务时，所有内容都堆在一个 Agent 的大脑里，会带来两个明显问题：

1. 记忆越来越杂乱
   写代码、写周报、写公告、记代号，全都在同一个 workspace 中；模型在每次生成时都要从「一大堆不相关内容」中筛出有用信息。
2. 每个会话的上下文越来越长
   为了让它“记得住”之前的讨论，你会不断把历史信息喂给同一个 Agent，这会持续放大每一次调用的 Token。

更合理的做法是：像组织团队那样拆分 Agent——

• 为不同团队 / 不同飞书群 / 不同职能，配置各自独立的 Agent；
• 每个 Agent 有自己的 workspace、记忆、技能、模型；
• 某个团队的长对话、知识积累，只占用对应 Agent 的上下文，而不是污染整个系统。

这样做的收益包括：

• 单个 Agent 的上下文更干净，模型推理时不必在无关信息中“找针”；
• 每类任务使用自己的对话历史，整体 Token 消耗更可控；
• 出问题时，排查和优化也可以针对某个 Agent 独立进行。

如果你希望按「飞书群聊 → 独立 Agent」的方式落地，可以参考这篇详细教程（已包含命令行操作示例和绑定策略）👉 配置相互独立 Agent（飞书多 Agent 实战教程）

在实际项目里，经常是一套组合拳：先通过多 Agent 分工，从架构层面把大脑拆干净，再在每个 Agent 内部用 /compact / /reset 控制单次对话的上下文长度。

---

三、用 memory-search 替代「无限长对话」

除了直接控制上下文本身，还有一种更“聪明”的方式来降低 Token： 不要把所有东西都塞进同一段对话，而是让 Agent 学会“查资料”。

OpenClaw 提供了 memory-search 能力，可以让 Agent 在需要时主动去查找历史记忆，而不是靠把所有历史对话一股脑地塞进上下文。一个典型思路是：

1. 把关键信息固化到 memory / 文件 / 知识库中；
2. 开启 memory-search；
3. 让 Agent 在需要时用“查询”的方式取回小块相关内容，而不是每次都携带整段历史上下文参与推理。

这样一来：

• 模型输入中只包含当前问题 + 与之高度相关的一小段记忆；
• 不需要为了“怕它忘”而在每次对话里重复大量背景；
• 在复杂项目里，长远看比“全靠上下文”更节省、也更稳定。

memory-search是OpenClaw默认开启的机制，你要做的就是在进行完一轮完整的对话，或是在OpenClaw完成一轮任务后，养成让龙虾记忆重要信息的习惯，还是直接从对话框告诉它就行。

---

小结

以上三种方式，可以叠加使用：

• 日常随手用 /compact、/reset、/new 掌控当前对话长度；
• 在架构上拆分多 Agent，让不同任务各用各的脑；
• 逐步把长期知识迁移到 memory / 知识库，用 memory-search 做“精确查找”，而不是“暴力塞上下文”。

合理组合这些手段，你会很快看到两个变化：一是对话响应更稳定、跑偏更少，二是每个月的 Token 账单不再「一路爬坡」。

---

🚀 开发者社区与支持

1️⃣ OpenClaw 开发者交流社区

Discord 解锁更多进阶玩法

点击一键加入社群
注：加入后可获取最新插件模板与部署方案

2️⃣ 专属服务支持

加入 Whatsapp / 企业微信享受专属技术支持

渠道	扫描/点击进入
Whatsapp 频道
企业微信

---

更多详情请访问官方落地页： Tencent Cloud OpenClaw