夜雨聆风你在跟AI讨论一个复杂的代码架构问题，聊到第50轮的时候，突然想问一句"这个函数的时间复杂度是多少"。
就这么简单的一个问题。
但AI的回复可能让你血压升高：它开始"回忆"五分钟前你们讨论的一个无关功能，然后花了三段话来解释那个功能的实现细节，完全忘了你正在问的是时间复杂度。
这不是AI变笨了。这是上下文污染。
一、上下文污染：AI Agent的慢性病
上下文污染（Context Pollution）是一个被低估的问题。
它的定义很简单：当错误或不相关信息进入AI的上下文窗口后，这些内容会被模型当成事实来引用，随着对话推进不断被强化，最终导致推理结果偏离。
举个例子：
第1轮：你让AI帮你review一个登录模块第20轮：AI在处理一个bug时产生了一个错误理解，把"token过期"理解成了"token永久有效"第30轮：这个错误理解进入上下文，被当作事实保留下来第50轮：你在问登录模块的问题，AI的回复里夹带了这个错误理解这不是一次性错误。这是复利式错误——每轮对话都在强化这个错误，直到你发现AI在用一个完全错误的假设来回答你的问题。
为什么这个问题在AI Agent上特别严重？
因为Agent与传统聊天机器人不同：
多轮交互：Agent处理的是长对话，不是一问一答 工具调用：每次工具执行的结果都会进入上下文 状态累积：上下文窗口会不断膨胀，有用信息被挤出，有害信息反而沉淀下来
二、滑动窗口的诅咒
现有AI Agent解决上下文膨胀的方式很粗暴：滑动窗口。
当对话超过阈值时，系统自动压缩/删除早期对话，用摘要替代原始内容。
这个机制有几个致命问题：
问题一：关键信息被优先丢弃
滑动窗口的压缩策略通常是"保留最近的，压缩/删除最早的"。但"最早"不等于"最不重要"。
用户说"我的预算上限是5万"，这句话可能只出现了第一轮。如果对话在第30轮触发压缩，这句约束就会被丢掉。
AI开始给你推荐超出预算的方案——因为它已经不记得你的约束了。
问题二：压缩本身引入错误
摘要不是原文。AI在生成摘要时，会"脑补"一些它认为的"核心内容"，同时丢弃它认为的"次要细节"。
如果这个判断出错，摘要就会包含错误信息。更糟糕的是，这些错误信息会被当作"已确认的事实"固化在后续对话中。
问题三：无关信息污染上下文
用户问AI"帮我重构这个函数"，然后顺手把一段无关的日志粘贴进去。这段日志被当作上下文的一部分，在后续的推理中被引用——因为它没有被识别为"无关"。
这就是上下文污染最常见的场景：无关信息混入，被模型当作有效上下文处理。
三、OpenClaw的解法：上下文隔离
OpenClaw 3.22引入了一个看似不起眼的功能：/btw 侧问命令。
这个命令不是OpenClaw首提的，最早应该在 Claude Code 2.1.72 版本中推出，其允许用户在代码任务执行过程中，随时插入问题（例如 /btw what does retry logic do?）进行快速查询，而不会中断后台的主任务流程
它的官方描述是：
新增的
/btw命令让你可以在不影响主对话上下文的情况下快速提问。Agent 不会调用任何工具，直接用知识回答——适合「顺便问一句」的场景。
这段描述有几个关键点：
1. 不影响主对话上下文
当你用 /btw 问一个问题时，这个问题不会进入主对话的上下文窗口。它是一个独立的、隔离的查询。
2. 不调用工具
这意味着它不会产生新的工具调用结果，不会往上下文里塞新的内容。
3. 直接用知识回答
纯粹的知识查询，不需要依赖对话历史。
这解决的是一个具体但高频的痛点：你正在处理一个复杂任务，突然想起一个与此无关但需要确认的问题。
四、为什么 /btw 值得单独做一个命令
表面上看，/btw 只是一个"快速问答"功能。你完全可以说"我开一个新对话来问这个问题"。
但实际上，这个命令解决的是心智负担和上下文连续性两个问题。
心智负担
开新对话意味着你要：
记住你刚才在聊什么 在新对话里重新建立背景 处理两个对话之间的状态割裂
/btw 让你不用离开当前对话，同时保持主对话的上下文纯净。
上下文连续性
当你问"顺便说一句，这个函数的复杂度是多少"时，你需要的是：
AI的回答 不需要引用当前对话的历史 不需要把这个回答加入当前对话
/btw 把这个需求显式化了——它告诉AI："这个问题是独立的，请单独处理。"
五、上下文工程的多层防御
/btw 只是OpenClaw上下文管理体系的冰山一角。
从3.7版本开始，OpenClaw引入了一套上下文工程机制：
1. Context Engine插件接口
3.7版本的Context Engine提供了7个生命周期钩子，允许插件在上下文的不同阶段介入：
bootstrap | ||
ingest | ||
assemble | ||
compact | ||
afterTurn | ||
prepareSubagentSpawn | ||
onSubagentEnded |
这套机制的核心思想是：上下文管理不是铁板一块，它是可配置的、可插件化的。
2. lossless-claw：无损上下文
官方在3.7版本中点名了一个插件示例：lossless-claw。
它的设计思路是区分"硬约束"和"软信息"：
硬约束：数字、日期、人名、偏好等结构化事实——优先保留 软信息：闲聊、分析过程、非关键描述——可以压缩
这比粗暴的"保留最近"或"均匀压缩"更智能。
3. 子Agent上下文隔离
当你启动一个子Agent来处理子任务时，主Agent的上下文不会被子Agent的操作污染。
prepareSubagentSpawn 和 onSubagentEnded 这两个钩子让系统可以在子Agent生命周期内维护独立的上下文空间，任务结束后再决定是否合并结果。
六、上下文污染的不可逆性
为什么上下文污染是一个棘手的问题？
因为它有不可逆性。
一旦错误信息被写入上下文，它不会自动消失。每次模型推理都会重新读取这些信息，每次读取都会强化它对"这是一个事实"的认知。
你无法"撤回"上下文中的某个错误陈述。你只能：
开启新对话：放弃当前上下文，损失所有进度 明确纠正：告诉AI"你说的不对，请忽略"，但模型可能仍然坚持原有理解 上下文隔离：用某种机制把错误信息和后续推理隔开
/btw 的设计思路对应第三种：不修复污染，而是防止污染产生。
七、为什么这个问题会在2026年变得突出
上下文污染不是新问题。但2026年它变得突出的原因有两个：
1. AI Agent从"玩具"变成"生产工具"
2025年的AI Agent主要是极客的玩具，交互时间短，任务简单。上下文污染还没来得及发作。
2026年，OpenClaw的用户开始在工作中依赖Agent处理复杂任务。长对话、多步骤任务、持续运行成为常态。上下文污染开始影响实际生产力。
2. 长上下文窗口带来虚假安全感
GPT-5.4支持100万token上下文，Claude Opus 4.6支持20万token。
开发者开始觉得"上下文够大，不需要担心溢出"。但这忽略了污染问题的存在——窗口大了，污染的容量也大了。
更大的窗口不等于更干净的上下文。如果不解决污染问题，更大的窗口只是让错误信息有更多空间积累。
八、从"上下文工程"到"上下文治理"
/btw 功能的出现，折射出一个更大的趋势：上下文管理正在从"工程问题"变成"治理问题"。
工程问题的思路是：压缩算法、滑动窗口、摘要生成。
治理问题的思路是：什么信息可以进入上下文？什么信息应该被隔离？什么信息应该被永久丢弃？
好的产品设计，是让复杂的技术机制变得不可见，同时让用户体验到它的价值。
你不需要理解上下文污染的原理，也不需要知道 /btw 是如何实现隔离的。你只需要知道：问完就走，主对话不受影响。
这就是 /btw 的价值。
（全文完）
