Context Mode：上下文窗口的"另一半问题"

场景开篇

你让 Claude Code 帮你分析一个 GitHub 仓库。它用 Playwright 抓了首页快照——56 KB。又读了 20 个 issue——59 KB。再看了一眼访问日志——45 KB。半小时后，你的 200K 上下文窗口已经用掉 40%。

然后对话被压缩（compact）。Claude 忘了你在改哪个文件，忘了任务进度，忘了你最后问的问题。它礼貌地说："抱歉，能再说一遍你在做什么吗？"

所有人都在解决"如何把更多信息塞进上下文"——RAG、长上下文窗口、嵌入模型。但几乎没人解决"如何让更少的信息从上下文里漏出去"。工具输出洪水、会话压缩失忆、模型啰嗦——这三件事各自不致命，合在一起让 AI 编码代理的实际可用上下文缩水 60%。

Context Mode 解决的是这另一半问题。

四个方向

Context Mode 是一个 MCP 服务器，解决上下文问题的四个方向：

1. 上下文节省：沙箱化工具输出

工具输出是上下文最大的污染源。一次 Playwright 快照 56 KB，一次 GitHub issue 列表 59 KB，一次访问日志 45 KB。这些数据代理只需要看一眼，不需要一直放在上下文里。

Context Mode 的方案是沙箱工具：工具输出不进入上下文窗口，而是进入一个 SQLite 数据库。代理拿到的是一个引用（"快照已存储，ID: snap_abc123"），不是 56 KB 的原始 HTML。需要时再通过 FTS5 全文检索取回相关片段。

数据：315 KB 原始输出 → 5.4 KB 索引引用。98% 减少。

2. 会话连续性：事件追踪 + BM25 检索

对话压缩（compact）是 AI 编码代理的失忆症。压缩后，代理忘了文件编辑历史、git 操作、任务进度、错误信息、用户决策。

Context Mode 的方案是事件日志：每次文件编辑、git 操作、任务创建、错误发生、用户决策都被记录到 SQLite。压缩时，Context Mode 不把事件倒回上下文，而是建立 FTS5 全文索引。代理需要时用 BM25 检索取回相关事件。

关键设计：不 --continue 时，上次会话数据立即删除。新会话 = 干净状态。这避免了"幽灵记忆"问题——旧会话的错误决策不会污染新会话。

3. Think in Code：代理写代码而不是读数据

这是最有意思的设计。Context Mode 强制一个范式转变：

代理不应该读 50 个文件来数函数，而应该写一个脚本数函数，console.log 结果。

一次 ctx_execute 调用 = 3.6 KB。47 次 Read 调用 = 700 KB。100 倍节省。

这不是新概念——人类程序员早就这么做了。你不会逐行读 50 个文件来数函数，你写 grep -c "function" *.ts。但 AI 代理习惯于用 Read 工具逐个读文件，因为这是最直接的 API。Context Mode 通过路由指令强制代理改用代码执行。

// 之前：47 × Read() = 700 KB
// 之后：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'));
`);

4. 不强制文风

Context Mode 明确拒绝做"文风强制"。它管数据去哪里，不管模型怎么说话。

这不是疏忽，是刻意设计。README 引用了 Moonshot AI 的案例：激进的简洁提示词会降低编码和推理基准测试分数。kimi-k2.5 在强制简洁提示下表现变差。

这个决策揭示了一个被忽视的问题：很多"AI 优化"工具在优化错误的东西。强制模型简短看起来像在节省 token，实际上在牺牲质量。Context Mode 的立场是：上下文管理是基础设施问题，文风是模型能力问题，不要混为一谈。

17 平台支持：Hook 是关键

Context Mode 支持 17 个客户端：Claude Code、Cursor、Codex、Gemini CLI、OpenCode、Antigravity、Kiro、Copilot、Hermes Agent 等。

支持分两层：

• Hook 层：能注入 hook 的平台（Claude Code、Gemini CLI），自动路由强制执行。代理想用 Read 时被 hook 拦截，改用 ctx_execute。
• MCP 层：不能注入 hook 的平台，只装 MCP 服务器。代理可以用沙箱工具，但不会被强制路由。

Hook 层是关键差异。没有 hook，代理可能"忘记"用沙箱工具，直接 Read 一个大文件。有 hook，代理被强制走沙箱路径。

这和数据库的"透明查询重写"类似：PostgreSQL 的查询规划器会自动选择最优索引，不需要应用层改 SQL。Context Mode 的 hook 自动重定向工具调用，不需要代理改 prompt。

路由块：注入还是不注入

Context Mode 通过 SessionStart hook 在会话开始时注入"路由指令"——一段告诉代理"优先用沙箱工具"的文本。

关键设计选择：不写入项目文件。路由指令在运行时注入，不污染 CLAUDE.md 或 AGENTS.md。

这避免了"配置文件污染"问题。很多工具要求你在项目里加一段配置，导致 CLAUDE.md 越来越长，最终变成工具广告板。Context Mode 选择运行时注入，项目文件保持干净。

数据

• 仓库：mksglu/context-mode
• 语言：TypeScript
• 协议：MIT
• 今日 stars：88
• 17 平台支持
• 11 个 MCP 工具（6 个沙箱 + 5 个元工具）
• 6 个 hook（PreToolUse、PostToolUse、UserPromptSubmit、PreCompact、SessionStart、Stop）
• Hacker News 首页第一名（570+ points）

适合谁

• 用 Claude Code / Cursor / Codex 做长会话开发的开发者
• 上下文窗口经常不够用的团队
• 需要会话压缩后保持连续性的场景
• 多工具协作（Playwright + GitHub + 日志分析）的代理流水线

不适合：短会话一次性任务（上下文管理收益不明显）、非编码场景（Context Mode 针对编码代理优化）、需要跨会话长期记忆（Context Mode 的会话数据在 --continue 时保留，不 continue 时删除）。

收尾

Context Mode 揭示了一个被忽视的真相：上下文问题不是"塞不塞得下"的问题，是"漏不漏得出去"的问题。

所有人都在扩大上下文窗口——200K、1M、10M token。但如果你每次工具调用都漏 50 KB，每次压缩都失忆，每次回答都啰嗦——10M token 也不够用。

Context Mode 的贡献是系统化地堵住四个漏水口：工具输出沙箱化、会话事件持久化、代码执行替代文件读取、文风不强制。四个方向合在一起，让 200K token 的实际可用容量接近 200K，而不是缩水到 80K。

这和内存管理的历史一致。早期操作系统没有虚拟内存，程序直接访问物理内存，一个程序泄漏内存就崩溃。后来发明了虚拟内存、内存保护、分页——不是让内存更大，而是让内存更安全。Context Mode 给 AI 代理的上下文窗口装了一个"虚拟内存管理器"。

当所有人都在追逐更大的上下文窗口时，Context Mode 提醒我们：问题不是窗口不够大，是窗口漏得太快。