GitHub 趋势 · 第 13 期
你的 Agent 不是变笨了，是被上下文淹死了：context-mode 砍掉 98%，但许可证不是 MIT
#AI编码工具#MCP#上下文窗口#开源许可证
我的判断：context-mode 解决的是真问题——AI 编程 Agent 在 agent 模式下，上下文窗口最容易被自己调用的工具原始输出淹没。它的「沙箱化工具输出」思路靠谱，98% 压缩在基准测试里也站得住。但两个坑先说清：一是许可证是 Elastic License 2.0（ELv2），不是 MIT，有字段限制；二是 98% 是「工具输出」维度的压缩，不是模型智商加成，别当银弹。
痛点：你的上下文，是被自己读死的
你有没有这种体验：让 Claude Code / Codex 跑一个任务，它 Read 了 47 个文件、调了 30 次工具，半个钟头后上下文就红了——Agent 开始忘事、重复劳动、甚至把前面写好的代码改坏。问题不在模型，在于原始数据（日志、HTML 快照、CSV、git log）全灌进了上下文窗口。context-mode 要做的，就是把这部分「脏数据」挡在窗口外。
项目是什么
context-mode 是一个 MCP server（也提供各平台插件），定位是「上下文问题的另一半」。它不替你写代码，而是在 agent 运行时做三件事：把工具原始输出放进沙箱只留摘要、把会话事件存进本地 SQLite 并在上下文压缩时按 BM25 检索召回、鼓励模型「用代码思考」而非把数据读进上下文。覆盖 17 个平台：Claude Code、Codex、Cursor、Gemini CLI、Copilot CLI、Kimi Code、Qwen Code、Zed、Kiro、Antigravity IDE、OpenClaw、Pi Agent、OMP 等。
核心能力
| 能力 | 做法 | 效果 |
|---|---|---|
| 上下文节省 Context Saving | 沙箱化工具输出，只回摘要 | 315 KB → 5.4 KB，98% 压缩 |
| 会话连续性 Session Continuity | 编辑/错误/决策进 SQLite，压缩后 BM25 召回 | 不回灌原始上下文，按需检索 |
| 用代码思考 Think in Code | 让 Agent 写脚本算结果，只 console.log 答案 | 700 KB → 3.6 KB |
| 17 平台路由 Routing | MCP + hooks 强制路由 | 启用 hooks ~98% 省，仅指令文件 ~60% |
README 里的基准测试（取原文数据）：
| 场景 | 原始 | 上下文 | 节省 |
|---|---|---|---|
| Playwright 快照 | 56.2 KB | 299 B | 99% |
| GitHub Issues ×20 | 58.9 KB | 1.1 KB | 98% |
| Access log ×500 | 45.1 KB | 155 B | 100% |
| 7.5 MB JSON API | 7.5 MB | 0.9 KB | 99% |
上手：README 原命
Claude Code（取自 README）：
/plugin marketplace add mksglu/context-mode /plugin install context-mode@context-mode
通用 npm 全局安装：
npm install -g context-mode
Cursor（macOS / Linux，取自 README）：
git clone https://github.com/mksglu/context-mode.git ln -s "$PWD/context-mode" ~/.cursor/plugins/local/context-mode
会话内常用命令（取自 README）：
ctx stats → 上下文节省 / 调用次数 / 会话报告 ctx doctor → 诊断运行时、hooks、FTS5、版本 ctx index → 索引本地文件或目录供后续检索 ctx search → 检索已索引内容 ctx upgrade → 从 GitHub 更新、重建、重配 hooks ctx purge → 永久删除知识库中所有索引内容
Think in Code 范式（README 原例，逐字）：
// Before: 47 × Read() = 700 KB. After: 1 × ctx_execute() = 3.6 KB.
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'));
`);
我的判断：适合谁 / 不适合谁 / 坑
适合谁：长任务、长会话、频繁读大文件 / 日志 / 网页的 agent 工作流；上下文经常爆窗的个人或团队。
不适合谁：短平快单次问答；对「source-available 但有限制」许可证敏感的闭源产品或要做托管 SaaS 的团队。
三个坑：
1. 许可证是 ELv2——可自用 / 改 / 分发，但不能把它包装成竞品托管 SaaS，也不能删许可证声明。它不是 OSI 认证的开源，商用托管要当心。
2. 98% 是工具输出压缩，不是万能；需要 Agent 配合「用代码思考」才见效，纯靠指令文件的平台只省 ~60%。
3. 依赖本地 SQLite + FTS5 + hooks，无 hooks 平台效果打折；ctx purge 会永久删除索引。
地址：https://github.com/mksglu/context-mode
Star：21,727（本周 +935，抓取于 2026-09-10）
许可证：Elastic License 2.0 (ELv2)，source-available（非 MIT / 非 OSI 开源）
数据来源：GitHub Trending 官方（weekly）· WebFetch 抓取，命令与数据均取自项目 README 原文
你最常被哪种「脏数据」撑爆上下文——日志、网页快照、还是大文件？留言说说你的场景。下期继续盯榜，候选方向是本地优先 AI 桌面与多智能体金融框架。
#AI编码工具#MCP#上下文窗口#开源许可证