昨天分享了90%的人还未解锁的 Claude Code 10 个隐藏指令
其中就是Claude Code近期刚上线了/btw：不中断的临时追问命令
这不，才发现OpenClaw 也发布了新命令 /btw
解决的问题是：
你和 AI 一路深入讨论架构，聊到第 50 轮，忽然想插一句：“这个函数的时间复杂度是多少？”本来一句话就能说清的事，AI 却先“回忆”起五分钟前的一段无关功能，实现细节连说三段，完全忘了你问的是复杂度。
这不是 AI 变笨了，而是被上下文污染了。
一、上下文污染
上下文污染（Context Pollution）被低估已久：错误或无关的信息进入上下文窗口，被模型当作事实引用，随着对话推进不断强化，最终让推理跑偏。
一个典型过程：
- 第 1 轮：你让 AI review 登录模块
- 第 20 轮：AI 在排查一个 bug 时误把“token 过期”理解成“token 永久有效”
- 第 30 轮：这个错误理解被写进上下文并保留下来
- 第 50 轮：你继续问登录问题，AI 的回答夹带了这条错误认知
这不是一次性的“失误”，而是复利式错误：每一轮都在加固旧误解，直到整个推理建立在错误假设上。
为什么在 Agent 上更致命？
- 多轮交互：不是一问一答，长对话更容易累积误差
- 工具调用：每次调用结果都会吞进上下文
- 状态累积：窗口不断膨胀，有用信息被挤出，无关或错误信息沉淀
二、滑动窗口的诅咒
当上下文过长，主流做法是滑动窗口：把早期内容压缩/删除，用摘要代替。粗暴有效，但有三大坑：
- 关键信息优先丢：压缩规则多为“留最近、丢最早”。但“最早”不等于“不重要”。例如第一轮你说“预算上限 5 万”，到第 30 轮触发压缩，它被丢弃，于是 AI 开始推荐超预算方案。
- 压缩引入新错：摘要不是原文。生成摘要时模型会脑补“核心内容”、舍弃“次要细节”。判断一旦出错，错误会被固化为“已确认的事实”。
- 无关信息混入：你说“帮我重构这个函数”，顺手贴了段无关日志。日志进了上下文，后续推理就会引用它——因为系统没有识别出“无关”。
三、OpenClaw 的解法：上下文隔离
OpenClaw 3.22 带来一个看似不起眼的功能：/btw 侧问命令。类似的想法最早可追溯到 Claude Code 2.1.72，允许在代码任务执行时随时插问（如：/btw what does retry logic do?），后台主任务不被打断。
官方描述要点：
- 不影响主对话上下文：用
/btw提问不会写进主对话窗口，是一次独立、隔离的查询。 - 不调用工具：不会触发新工具执行，避免额外上下文噪音。
- 直接用知识回答：纯知识检索或常识解答，不依赖对话历史。
它解决的是一个高频刚需：你在做复杂任务时，突然冒出一个无关但必须确认的小问题。
四、为什么要单独做成一个命令
表面看 /btw 是“快速问答”，完全可以新开对话。但现实里，它缓解了两个痛点：
- 心智负担：新开会话意味着记住刚才进度、在新会话重建背景、在两个对话间来回切换。
- 上下文连续性：这类问题本就不应引用当前历史，也无需写回当前上下文。
/btw把这个意图显式化：这是独立问题，请单独处理。
五、上下文工程的多层防御
/btw 只是 OpenClaw 上下文治理体系的一角。从 3.7 起，OpenClaw 引入一套“上下文工程”机制：
1）Context Engine 插件接口
3.7 的 Context Engine 暴露 7 个生命周期钩子，让插件在不同阶段介入：
- bootstrap：Agent 启动时，初始化上下文状态
- ingest：收到新消息时，过滤/预处理输入
- assemble：组装上下文时，决定上下文组成
- compact：触发压缩时，自定义压缩策略
- afterTurn：每次回复后，保存/清理状态
- prepareSubagentSpawn：子 Agent 启动前，隔离其上下文
- onSubagentEnded：子 Agent 结束后，合并或丢弃结果
核心理念：上下文管理不是“一刀切”，而是可配置、可插件化。
2）lossless-claw：无损上下文
官方在 3.7 点名了一个示例插件：lossless-claw。它区分两类信息：
- 硬约束：数字、日期、人名、偏好等结构化事实——优先保留
- 软信息：闲聊、分析过程、非关键描述——可压缩
这比“只留最近”或“均匀压缩”更聪明。
3）子 Agent 上下文隔离
当你用子 Agent 处理子任务时，主 Agent 的上下文不会被污染。通过 prepareSubagentSpawn 和 onSubagentEnded 两个钩子，系统为子 Agent 维护独立上下文空间，任务结束后再决定如何合并。
六、上下文污染的不可逆性
上下文污染棘手在于不可逆：一旦错误写入，它不会自动消失；每次推理都会读到它，并进一步强化“这是真的”。你很难“撤回”一条错误陈述，只能：
- 开新对话：放弃当前上下文，损失进度
- 明确纠正：让 AI 忽略，但模型可能仍执着旧理解
- 上下文隔离：把错误信息与后续推理隔开
/btw 的思路就是第三种：不修旧创，先防新伤。
七、为什么 2026 年这个问题更突出
- Agent 从“玩具”变“生产工具”：2025 年的 Agent 偏玩具属性，交互短、任务轻，污染难以显性。到 2026 年，OpenClaw 用户开始在工作中依赖它承担复杂任务，长对话、多步骤、持续运行成为常态，污染直接拉低生产力。
- 长上下文窗口的“虚假安全感”：GPT‑5.4 支持 100 万 token 上下文，Claude Opus 4.6 支持 20 万。开发者以为“够大就万事大吉”。忽略了污染——窗口越大，污染的“蓄水池”越大。更大的窗口不代表更干净的上下文。
八、从“上下文工程”到“上下文治理”
/btw 的出现折射了更大的转向：上下文管理正在从“工程问题”走向“治理问题”。
- 工程思路：压缩算法、滑动窗口、摘要生成
- 治理思路：哪些信息可以进入？哪些该隔离？哪些该永久丢弃？
好的产品设计，让复杂机制“隐身”，用户只感受到价值：问完就走，主对话不受影响。这就是 /btw 的意义。