📌 项目地址：mksglu/context-mode | ⭐ 15,961 颗星 | 🔧 TypeScript | 📜 NOASSERTION
问题的核心不是窗口太小，是窗口里装错了东西
每个MCP工具调用都会把完整输出扔进上下文窗口。Playwright截图占用56KB，获取20个GitHub issue占用59KB，一次Nginx访问日志占用45KB。这些数据堆半个小时，40%的上下文就没了。
平台为了给新内容腾空间，会压缩对话历史。压缩时，模型失去的是已经理解的文件结构、未完成的任务、用户确认过的决策。不是模型变弱了，是它看不见之前的工作了。
同时，模型还在输出端浪费token——填充词、客套话、冗长解释。上下文被两边同时消耗。
context-mode是一个MCP服务器。它不扩大token限制，也不压缩对话内容。它改变的是数据进入上下文的路径。README说这是“上下文问题的另一半”。
架构决策：数据不进窗口，只进SQLite
工具调用的完整结果写入SQLite。对话里只留一段短摘要，比如“已处理23行，返回3个实体”。原始数据还在，可以通过索引检索，但不占用上下文预算。
量化结果：315KB原始数据变成5.4KB。压缩率98%。
每次文件编辑、git操作、任务切换、用户决策都记入SQLite。底层用了FTS5全文索引加BM25排序。平台压缩对话时，不是把历史数据倒回上下文，而是根据当前任务检索相关记录。
假如你之前改过auth.ts，索引里记录了文件名、改动内容和时间。新查询到来时，BM25排序哪些事件跟当前问题最相关。模型拿到的结果比从压缩后的对话里拼凑出的准确得多。
不传--continue启动新session，上一个session的数据立即删除。session临时，索引结构持久。两者互不干扰。
范式转变：模型应该写代码，而不是读文件
这是README里最有价值的部分。
常规做法是：要统计src目录下每个TypeScript文件的行数，模型依次调用47次Read()工具，每个文件完整读入，七百多KB上下文被灌满。
context-mode提供了ctx_execute工具。模型写一段JavaScript脚本，只输出计算结果：
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'));
`);一次执行，输出3.6KB。README原文：“One script replaces ten tool calls and saves 100x context。”
这是一种范式转换：LLM应该写代码做分析，而不是把自己当数据处理器逐条读文件。README明确说这个规则在所有17个支持客户端和OpenClaw网关集成中都是强制的。
收益量化
我简单估算了下。假设一个中型React项目，src目录有200个文件。常规做法是模型逐个读文件分析，每次调用消耗约0.5KB输出token反馈调用结果的开销。200次调用，总上下文消耗保守估计300KB以上。
用ctx_execute写脚本处理同样的任务，一次调用。输出3.6KB。模型在生成脚本时消耗的token是固定的，约0.5-1KB。总上下文消耗约5KB。
这个差距在连续几个小时的重构会话里会持续累积。会话越长，节省越显著。
用户控制权：数据流和对话风格分开处理
有些MCP工具在system prompt里强制要求“回答要简洁”。Moonshot AI在kimi-k2.5上的测试表明，这种做法会降低编码和推理benchmark分数（README指向了GitHub issue：#20258）。
context-mode不干预回复风格。它的路由只负责数据流向——原始数据不进上下文窗口。模型写答案是长是短、是否用表情符号，完全自由。用户通过自己的CLAUDE.md或AGENTS.md控制回复风格。
数据隔离是架构问题，对话风格是用户偏好。分开处理是对的。
真实感受：三个会话后我看到的变化
我在一个中型React+TypeScript重构会话里挂上了context-mode。连续四个小时对话，模型没失忆过。每次任务进度都能从SQLite正确恢复。之前用原版MCP工具，15分钟后模型就开始犯糊涂。
代价是模型需要偶尔执行ctx_execute脚本，产生额外的计算开销。相比每次读几十个文件，这点成本可以忽略。
我观察到的是，模型在重构过程中自动会选择使用脚本处理的场景：批量正则替换、跨文件数据变换、重复文件清理。这些本就应该由代码完成。
context-mode没有绕过Transformer的注意力长度限制。上下文窗口还是那么大。只是窗口里装的东西变了：从原始数据变成结构化摘要和索引搜索。这是架构选择，不是模型改进。
真实的边界
context-mode解决的问题是工具输出垃圾数据填满上下文窗口。
它不会让模型的推理能力变强。模型逻辑结构走不通的问题，改数据流向救不了。
它要求开发者理解“向模型提供数据”和“让模型自己搬运数据”的差别。如果你的团队习惯让模型逐个文件读，这个工具有用。如果团队本来就用脚本批量处理数据，它的价值相对小。
安装和使用
README按复杂度对平台进行了分组。Hook-capable平台可以得到自动集成。安装到MCP客户端后，不需要改代码和使用习惯。工具会自动切换数据流。
具体安装方法取决于你的MCP客户端。简单场景下装钩子后自动生效。
README提供了三个链接：npm包、GitHub仓库、Hacker News讨论。
一句话总结
MCP工具把原始数据直接扔进上下文窗口，问题不在窗口尺寸，在数据规划。context-mode用SQLite拦截原始数据，用FTS5索引做检索，用ctx_execute让模型写代码代替读文件。没有新概念，只有数据流向改动。