把AI编程代理的"失忆症"治好了——Context Mode 如何用沙盒+SQLite让上下文窗口扩容6倍

一句话结论

Context Mode 不是"又一个MCP工具"，而是对"AI编程代理如何管理自己的记忆"这个问题的工程级回答。它用沙盒执行环境把原始工具输出隔离在上下文窗口之外，用SQLite FTS5索引实现压缩后的精准恢复，再用"Think in Code"范式把LLM从"数据阅读器"变成"代码生成器"。315KB的session输出压到5.4KB，session时间从30分钟延长到3小时——这不是优化，这是重新定义了Agent的可用性边界。

项目速览

问题背景：为什么Agent总在"失忆"

AI编程代理（Claude Code、Cursor等）的工作方式很简单：你说话，它调用工具，工具返回原始数据，原始数据进入上下文窗口，LLM基于这些数据推理和回答。

但这里有个致命的瓶颈：

• 一次 Playwright 浏览器快照 = 56.2 KB
• 20个 GitHub Issues = 58.9 KB
• 500条访问日志 = 45.1 KB
• 153次 git commit 记录 = 11.6 KB

Agent在上下文窗口里攒了这些原始数据后，30分钟内就会耗尽窗口——然后开始"压缩"（compact）。压缩的本质是删东西，而删掉的往往是：你刚修改了哪些文件、之前的任务进度、用户的关键需求。

结果？Agent"失忆"了。它不记得5分钟前做了什么，不记得你明确说过的约束条件，开始重复之前已经完成的步骤。

这就是 Context Mode 要解决的问题。

三层架构：沙盒、索引、Think in Code

第一层：沙盒化工具输出（Context Saving）

核心洞察：LLM不需要看到原始数据，它只需要看到处理后的结果。

Context Mode 提供了一组沙盒化的MCP工具：

关键：原始数据从不进入上下文窗口。

举个例子：你想知道47个TypeScript文件各有多少行。

传统方式： Agent调用Read工具47次，每次返回整个文件内容 → 700 KB上下文消耗。

Context Mode方式： Agent写一段Node.js脚本，用ctx_execute跑一次 → 只返回47行结果 → 3.6 KB。

// Agent生成的脚本
ctx_execute("javascript", `
  const files = fs.readdirSync('src').filter(f => f.endsWith('.ts'));
  files.forEach(f => console.log(f + ': ' + 
    fs.readFileSync('src/'+f,'utf8').split('\n').length + ' lines'));
`);

47次调用 + 700 KB → 1次调用 + 3.6 KB。这就是"Think in Code"范式——别让LLM读数据，让它写代码处理数据。

第二层：会话连续性（Session Continuity）

沙盒解决了"原始数据不进上下文"的问题，但Agent仍然会"失忆"——因为上下文压缩会删掉进度信息。

Context Mode的解决方案：五类Hook + SQLite FTS5索引。

PreToolUse     → 工具执行前拦截，路由到沙盒
PostToolUse    → 工具执行后捕获事件
UserPromptSubmit → 捕获用户决策和修正
PreCompact     → 压缩前生成≤2KB的snapshot
SessionStart   → 压缩/恢复后还原现场

所有事件（文件编辑、git操作、任务状态、错误、用户决策）写入本地SQLite数据库，FTS5虚拟表做全文索引。压缩后不是把所有数据倒灌回上下文，而是用BM25搜索只拿当前最相关的信息。

效果：Agent精确恢复现场，不会把50个文件全部塞回上下文。

BM25配置细节也很讲究：Porter词干提取（"generates"、"generating"、"generated"匹配同一词干）、trigram子串匹配、标题和标题权重5倍。

第三层：Think in Code 范式

这可能是三层中最有哲学深度的一层。

传统AI编程的工作流：

人类提需求 → LLM推理 → 调用工具获取数据 → LLM基于数据继续推理 → 输出结果

Context Mode 的工作流：

人类提需求 → LLM推理 → 写代码处理数据 → 沙盒执行 → 只看结果 → LLM基于结果推理 → 输出

区别在哪里？

传统方式把LLM当"数据阅读器"——它需要看到所有数据才能理解。Context Mode把LLM当"代码生成器"——它只需要理解问题，写代码让机器去处理，然后看结果。

这跟人类工程师的工作方式一致：你不会打开47个文件一行行数行数，你会写一行命令find src -name "*.ts" | xargs wc -l。

性能数据：98%不是营销数字

完整session累积： 315 KB → 5.4 KB，98%缩减。

session时间： ~30分钟 → ~3小时，6倍延长。

这些数字在多个独立评测中被验证（pyshine.com、itnotetk.com、easytool.me）。不是实验室理想条件，是真实开发场景。

平台兼容性与Hook策略

Context Mode 对14+平台的覆盖不是"一刀切"，而是按Hook完整度分三级：

关键差异： 没有PreToolUse Hook的平台，一次未路由的fetch就足以把整个session累积的节省全部抵消。所以Context Mode明确建议"Always enable hooks where supported"。

费曼视角："这不是在优化Token，这是在重新定义Agent的可用性"

费曼会怎么说？

"如果你不能向一个6岁的孩子解释清楚，那你并没有真正理解它。"

好，我来试试：

想象你在做一个复杂的乐高模型，说明书有500页。但你只能同时看10页，每过30分钟就必须撕掉5页——因为你桌子太小了。问题是：你撕掉的可能是"已经拼好的部分"和"接下来要拼什么"的提示。

Context Mode 做了什么？

1. 它做了一个"摘要机器"：你不需要看500页说明书，你只需要看每10页的"进度总结"（沙盒化）。
2. 它做了一个"记忆抽屉"：每当你完成一步，它把关键信息存进抽屉（SQLite索引）。桌子不够大的时候，它从抽屉里精准找回你此刻最需要的信息，而不是把整本说明书再摊出来。
3. 它改变了你的思考方式：以前你是"一页一页读说明书"，现在你是"扫一眼目录，直接跳到需要的那页"（Think in Code）。

这就是为什么session时间能从30分钟延长到3小时。 不是因为你桌子变大了（上下文窗口没变），而是因为你学会了如何更高效地使用有限的空间。

与相关项目的对照阅读

Context Mode 跟之前拆解的两个项目在同一生态但解决不同问题：

关键洞察：三者互补。

• Context Mode 解决"Agent自己的记忆管理"
• Understand-Anything 解决"人类如何理解代码"
• codebase-memory-mcp 解决"Agent如何高效查询代码结构"

如果你每天3小时以上的Agent编程session → Context Mode是必须的。
如果你经常带新人或做代码审查 → Understand-Anything。
如果你频繁做"这个函数被谁调用"这类查询 → codebase-memory-mcp。

许可策略的深意：ELv2而非MIT

Context Mode 采用 Elastic License 2.0（ELv2），不是常见的MIT。这意味着：

• ✅ 可以fork、修改、分发
• ✅ 可以个人使用、团队内部使用
• ❌ 禁止 重新打包成closed-source SaaS对外销售
• ❌ 禁止 移除授权声明

作者明确说选择ELv2是为了"挡掉vendor重新打包的情境"。这很合理——这个项目解决的是平台级问题（Claude Code、Cursor等平台都面临），如果被某个厂商打包成闭源产品出售，社区贡献者的利益无法保障。

这透露出一个信号： 作者认为Context Mode解决的是一个足够基础、足够普适的问题，值得用更严格的许可来保护其开源属性。

局限与存疑

1. 完全依赖Hook的平台差异

虽然号称支持14+平台，但不同平台的Hook完整度差异很大。Cursor的SessionStart目前被其validator拒绝，OpenClaw的插件支持还在早期。"98%节省"只在Full Hook平台可预期，MCP-only平台只能做到60%。

2. Think in Code的学习曲线

Agent需要学会"写代码处理数据而非读取数据"。这不是自动的——需要prompt工程引导。Context Mode提供routing文件（CLAUDE.md、AGENTS.md等）来注入这种思维范式，但效果取决于模型对这种范式的遵循程度。

3. SQLite FTS5的查询局限

FTS5 + BM25擅长文本搜索，但对于"结构化查询"（如"找出所有在过去3天内修改且被测试覆盖的文件"）不如专门的图数据库（如codebase-memory-mcp用的知识图谱）。Context Mode和codebase-memory-mcp的结合可能是最佳实践。

4. 长期session的状态累积

虽然session时间延长到3小时，但SQLite索引库会不断累积。ctx_purge可以清理，但用户需要手动触发。没有自动的索引过期/压缩机制（至少目前文档未提及）。

适用判断：谁应该用

强烈推荐

可以用

不建议

我的判断

Context Mode 不是"又一个MCP工具"，它解决的是AI编程Agent最底层的可用性问题——上下文窗口管理。

这个问题的严重性被低估了。很多用户以为"Claude Code突然变笨了"是因为模型降级，实际上很可能是上下文压缩导致的"失忆"。Context Mode 把这个隐形的问题显性化，并给出了工程级的解决方案。

三层架构的分工很清晰：

• 沙盒解决"数据隔离"
• 索引解决"记忆恢复"
• Think in Code解决"思维模式"

但最大的价值可能不在技术层面，而在范式层面。

"Think in Code"——让LLM写代码处理数据而不是读取数据——这个范式不只适用于Context Mode，它是一种通用的Agent设计哲学。未来的AI编程工具，都应该遵循"LLM是代码生成器，不是数据阅读器"这个原则。

参考来源

• GitHub: https://github.com/mksglu/context-mode
• 架构详解: https://pyshine.com/Context-Mode-Context-Window-Optimization-AI-Coding-Agents/
• 中文实战: https://www.itnotetk.com/2026/05/05/context-mode-mcp-context-window-saver/
• 使用指南: https://www.easytool.me/blog/context-mode-ai-coding-context-window-guide.html
• MCP Market: https://mcpmarket.com/server/context-mode
• 7 Best Tools对比: https://milvus.io/blog/claude-code-context-management-tools.md
• 许可: Elastic License 2.0 (ELv2)

#ContextMode #MCP #上下文窗口 #AI编程 #SQLite #FTS5 #沙盒 #ThinkInCode #小凯