爆斩 98% 上下文开销：深入拆解 context-mode 架构与 MCP 沙盒执行引擎

1. 痛点突围：它究竟击穿了什么工程死穴？

终端智能体（Coding Agent）的底层设计存在严重的资源错配。当前大部分工程实践将大语言模型当成了原始 I/O 处理器。一次 Playwright 快照吃掉 56 KB 上下文，批量拉取 20 个 GitHub Issue 吞噬 59 KB，单次调试请求 access.log 再灌入 45 KB。连续执行 30 分钟复杂排错任务，上下文窗口被海量未经清洗的 JSON 字符串与 HTML 节点占满，触发被动的会话压缩（Compaction）。

会话压缩机制是开发体验崩塌的源头。压缩逻辑为了腾出 Token 预算，粗暴丢弃历史操作链条。智能体开始遗忘上一轮刚刚修改的文件路径、丢掉未完成的任务栈，并在同类报错中反复打转。大模型在回复时附带的大量客套话与过渡文本，更是在输入与输出两侧同时消耗窗口算力。

context-mode 选择重构数据流向。它的立论基础非常明确：模型应该负责编写分析逻辑，而不是负责吞吐原始字节。当需要统计 50 个源代码文件的函数数量时，传统模式必须执行 47 次 Read() 操作灌入 700 KB 文本；context-mode 驱动模型生成一段 Node.js/Python 脚本扔进本地沙盒执行，仅通过 console.log() 返回格式化后的 3.6 KB 统计汇总。数据在宿主机沙盒内部完成闭环，315 KB 的原始输入被直接压制到 5.4 KB，实现 98% 的上下文冗余削减。

💡 架构核心洞见：大模型的本质是代码编译器与意图路由器，绝非数据流缓冲池；让代码去数据所在的位置运行，只把计算结果送回上下文。

2. 核心架构与底层数据流向解析

context-mode 是一个标准的 MCP（Model Context Protocol）协议服务器，通过深度挂载客户端的生命周期钩子（Hooks）拦截全量 I/O。架构核心由执行沙盒、状态追踪引擎、基于 SQLite FTS5 的检索记忆库，以及意图路由系统四个子模块构成。

[ Client CLI (Claude / Gemini) ]
           │  ▲
 (1) Hooks │  │ (6) Compacted Result (e.g. 5.4 KB)
           ▼  │
┌───────────────────────────────────────────────┐
│ context-mode MCP Server                       │
│                                               │
│  ┌──────────────────┐   ┌──────────────────┐  │
│  │ Routing Intercept│──>│ Sandboxed Runner │  │
│  │ (PreTool Hooks)  │   │ (ctx_execute)    │  │
│  └──────────────────┘   └────────┬─────────┘  │
│                                  │            │
│                                  ▼            │
│  ┌──────────────────┐   ┌──────────────────┐  │
│  │ FTS5 Search Core │<──│ Session Tracker  │  │
│  │ (BM25 Retrieval) │   │ (SQLite Engine)  │  │
│  └──────────────────┘   └──────────────────┘  │
└───────────────────────────────────────────────┘
           │                       ▲
 (2) Script│                       │ (4) Raw Data
           ▼                       │
┌─────────────────────┐   ┌─────────────────────┐
│ Node.js/OS Sandbox  │──>│ Local FS / APIs     │
│ Execution Runtime   │(3)│ (315 KB Source Dump)│
└─────────────────────┘   └─────────────────────┘

数据流动遵循明确的单向收敛原则：

1. 运行时切面拦截：智能体在决定调用文件读取或外部网络请求时，PreToolUse 钩子截获意图，强制将原始调用重定向至 ctx_execute 或 ctx_batch_execute。
2. 代码生成与本地隔离：LLM 输出精简的 JavaScript/Bash 脚本代码片段。代码直接在本地沙盒环境中起子进程运行，直接对接底层文件系统或目标 API。
3. 结果蒸馏与回填：脚本内部完成过滤计算，只允许标准输出（stdout）进入会话，拦截海量未经处理的原始负载。
4. 无向量状态持久化：系统通过 SQLite 监听每一次文件修改、Git 动作与执行错误。当触发压缩事件时，系统不把历史操作无脑塞回上下文，而是将其建立为 FTS5 倒排索引，后续仅响应基于 BM25 算法的高匹配度局部片段请求。

在语言风格的处理上，context-mode 拒绝在系统提示词中加入强迫性的“简短输出”约束。Moonshot AI 在 kimi-k2.5 上的实测已经证实，强行用 Prompt 限制模型输出字数会导致推理链路严重受损。context-mode 的边界清晰：只控制数据往哪里流，绝不干预模型最终给开发者的回答采用何种论述格式。

3. 技术选型与性能横向硬核对比

在长上下文工程落地中，开发者通常在“堆砌物理窗口大小”、“外挂向量数据库”与“切片路由执行”之间摇摆。下表为各方案的关键工程指标对照：

传统 RAG 模式在处理代码任务时存在先天缺陷。代码是高度结构化且具备严密语法拓扑的信息体，一旦被切片并转化为语义向量，诸如函数调用依赖关系、作用域边界以及精确的变量重命名链路都会出现断裂。context-mode 抛弃向量概念，选择纯文本倒排索引（FTS5）配合沙盒执行计算，在保证零依赖冷启动的同时，把代码定位精度牢牢锁死在字符级别。

4. 手把手极客实操：从零构建最小闭环

本节以 Claude Code 官方生态为例演示如何构建最小闭环，并验证执行沙盒拦截与压缩率监控效果。

环境准备与插件激活

确保系统已安装 Node.js >= 22.5 以及 Claude Code v1.0.33 以上版本。

# 检查 CLI 版本
claude --version

# 添加 context-mode 插件市场源并安装
/plugin marketplace add mksglu/context-mode
/plugin install context-mode@context-mode

# 重载插件使沙盒工具生效
/reload-plugins

系统就绪状态检查

在终端内输入插件内置检查指令：

/context-mode:ctx-doctor

输出必须确保全部检查通过：

[x] Node.js Runtime (v22.12.0 detected)
[x] SQLite FTS5 Extension Loaded
[x] Hook Registration: PreToolUse, PostToolUse, PreCompact, SessionStart
[x] Sandbox Permissions: OK

自动化拦截实战演示

配置完成后，在 Claude Code 会话中发出针对大批量文件的聚合分析请求。智能体将自动路由至 ctx_execute 工具，底层生成的 JavaScript 沙盒执行代码如下：

// 该脚本由 Agent 自主生成并提交给 ctx_execute 沙盒工具
// 目标：统计 src/ 目录下全部 TypeScript 文件的有效代码行数，规避逐个文件 Read
import fs from 'node:fs';
import path from 'node:path';

const TARGET_DIR = 'src';

// 递归扫描目标目录获取全量文件路径
function scanDir(dir) {
  let entries = fs.readdirSync(dir, { withFileTypes: true });
  return entries.flatMap(entry => {
    const fullPath = path.join(dir, entry.name);
    return entry.isDirectory() ? scanDir(fullPath) : fullPath;
  });
}

// 执行局部计算逻辑，绝对不把未经统计的原始文件内容吐进上下文
const tsFiles = scanDir(TARGET_DIR).filter(file => file.endsWith('.ts'));
const stats = tsFiles.map(file => {
  const content = fs.readFileSync(file, 'utf8');
  const validLines = content.split('\n').filter(line => line.trim().length > 0).length;
  return `${file}: ${validLines} lines`;
});

// 最终仅输出纯文本结果至标准输出
console.log(stats.join('\n'));

运行时监控与节省率统计

执行分析后，开发者可直接调用统计命令查看上下文预算保护情况：

/context-mode:ctx-stats

终端输出如下统计矩阵：

Tool                 Calls    Tokens In     Tokens Out    Savings Ratio
------------------------------------------------------------------------
ctx_execute             1       320 B          480 B          98.2%
read_file (prevented)  47       680 KB         0 B           100.0%
------------------------------------------------------------------------
Total Session Savings: 679.2 KB (approx. $1.35 saved)

5. 生产落地踩坑指南与避坑建议 (Gotchas)

在将 context-mode 引入核心生产开发流时，需要特别警惕以下几个涉及状态生命周期与环境隔离的工程陷阱。

⚠️ 避坑预警 [会话持久化与状态污染]：context-mode 默认采取严格的无状态策略。当退出终端智能体时，如果下次启动没有显式传递 --continue 参数，旧会话所记录的 SQLite 历史索引与上下文追踪记录会被系统立刻物理删除。如果在排错过程中中断了 CLI 会话，且需要智能体继续保持对之前修改历史的精确感知，必须使用 claude --continue 重启会话，否则上下文追踪器会以完全清空的白板状态启动。

⚠️ 避坑预警 [沙盒执行环境权限受限]：沙盒工具 ctx_execute 默认依赖主机全局 Node.js/Python 进程。如果你的项目采用高度隔离的私有化 Monorepo 体系（例如 pnpm 隔离或虚拟环境），由模型自动编写的沙盒测试脚本可能无法通过常规方式直接 import 本地未声明为全局可用的第三方依赖。针对这种情况，应当在项目的 CLAUDE.md 或系统的环境变量中明确标注运行时解析路径，约束智能体在生成 ctx_execute 脚本时仅使用标准库（如 node:fs、node:child_process）完成聚合计算，严禁引入未决的外部模块。

⚠️ 避坑预警 [非 Hook 平台的降级陷阱]：目前仅有 Claude Code、Gemini CLI 等少数平台原生开放底层 Hooks。如果将 context-mode 以纯 MCP 模式部署在 VS Code Claude 插件或 Cursor 等未接管 Hooks 的环境中，系统无法在执行底层实现硬性拦截。智能体依然会优先调用编辑器内置的原生文件读取工具。必须手动在系统提示词末尾注入 context-mode 提供的硬性路由指令集，强制 Agent 优先通过 ctx_execute 与 ctx_search 展开探索，避免开销防御策略失效。