在 AI 编码代理的日常工作中，上下文窗口正面临前所未有的压力。一次 Playwright 快照测试会产生 56 KB 的原始数据，二十个 GitHub Issues 贡献 59 KB，一个访问日志文件轻松达到 45 KB。当会话持续三十分钟后，约 40% 的上下文已被工具输出占据，而代理在压缩对话以释放空间时，往往会丢失正在编辑的文件、进行中的任务以及用户上一次的需求表述。这种上下文膨胀问题正在成为制约 AI 编码代理能力的核心瓶颈。
Context Mode 作为一款 MCP 服务器，从三个维度系统性解决这一困境：首先是通过沙盒化工具将原始数据隔离在上下文之外，实现 98% 的 token 压缩；其次是通过会话连续性机制，在对话压缩后依然能够恢复完整的工程状态；第三是推动范式转变，让大语言模型专注于代码生成而非数据处理。本文将深入剖析这套工程方案的实现细节与落地参数。
沙盒工具的核心设计
传统的 AI 编码代理在调用工具时，工具的完整输出会被直接注入到上下文窗口中。这些输出包括日志文件、API 响应、测试快照、代码仓库内容等，通常体积庞大且包含大量与当前任务无关的原始数据。Context Mode 的解决方案是在工具执行层面建立一道筛选机制，通过 preToolUse 钩子拦截可能产生大规模输出的工具调用，引导其使用专门的沙盒工具而非直接执行。
ctx_execute 是最核心的沙盒工具，它在隔离的子进程中运行代码脚本，支持 JavaScript、TypeScript、Python、Shell、Ruby、Go、Rust、PHP、Perl、Elixir 等十一门语言。关键设计在于：脚本的标准输出会被捕获并仅以极小体积返回上下文，而原始数据 —— 包括日志文件、API 响应、快照内容 —— 始终保持在沙盒内部。以 Playwright 快照为例，原始输出为 56.2 KB，经过沙盒处理后仅 299 B 进入上下文，缩减比例达 99%。
当输出超过 5 KB 且提供了 intent 参数时，Context Mode 会切换到意图驱动的过滤模式。它将完整输出索引到知识库中，然后搜索与意图匹配的内容片段，仅返回相关的结果并附带可搜索术语词汇表供后续查询使用。这种设计避免了传统截断方式可能导致关键信息丢失的问题。
ctx_batch_execute 进一步扩展了沙盒能力，允许在单次调用中运行多条命令或执行多个搜索查询。基准测试显示，在仓库研究场景中，原始输出 986 KB 经处理后仅 62 KB 进入上下文，节省幅度达 94%。这一工具特别适合需要并行分析多个文件或执行多项检查的工作流。
ctx_execute_file 则针对文件处理场景优化，它在沙盒中处理文件内容，原始数据从不离开隔离环境。访问日志处理演示了极致压缩：45.1 KB 的原始日志经处理后仅 155 B 进入上下文，压缩率接近 100%。
知识库与检索机制
Context Mode 构建了一个基于 SQLite FTS5 的知识库系统，用于存储和检索被索引的内容。ctx_index 工具将 markdown 内容按标题分块，同时保证代码块的完整性，然后存储到 FTS5 虚拟表中。分块策略优先保持代码块的连续性，这对于需要理解代码逻辑的检索尤为重要。
检索采用 BM25 排名算法，这是一种基于词频和逆文档频率的概率相关度评分方法。系统同时应用两种 tokenizer 策略：Porter 词干提取确保 running、runs、ran 等同源词能够匹配；三元组子串匹配则支持部分字符串查询，例如 useEff 能够匹配 useEffect。两种策略的排名结果通过 Reciprocal Rank Fusion（RRF） 融合，确保证相关性高的文档在两种策略中都获得良好排名时能够优先呈现。
多词查询还会经过 ** proximity reranking** 重新排序，查询词在内容中越接近，排名越高。例如搜索 "session continuity" 时，两个词相邻出现的段落会比相隔数段的内容排名更靠前。
模糊纠错机制使用 Levenshtein 距离 修正拼写错误后再执行搜索，kuberntes 会自动纠正为 kubernetes 进行检索。结果展示采用 智能片段提取 策略，不是简单截取前 N 个字符，而是定位查询词在内容中的位置，围绕匹配点返回上下文窗口，确保返回结果包含用户真正需要的信息。
知识库采用 TTL 缓存 策略，索引内容保存在项目级 SQLite 数据库中。24 小时内重复请求相同 URL 会直接返回缓存提示而非重新获取，14 天以上的旧内容会在启动时清理。这意味着使用 --continue 恢复会话时，已索引的文档可以跨重启持久化，无需重新抓取。
会话连续性的工程实现
上下文窗口存在固定容量限制，当对话过长时代理会执行压缩操作 —— 丢弃早期消息以腾出空间。传统实现中，这一操作意味着丢失关键的工程状态：正在编辑的文件、进行中的任务、已解决的错误、用户的特殊偏好等。Context Mode 通过四类钩子的协同工作实现了会话连续性。
PostToolUse 钩子 在每次工具调用后触发，捕获所有有意义的会话事件。事件按优先级分类：P1 关键级包括文件读写编辑、任务创建完成、用户提示内容；P2 高级包括 Git 操作、工具错误、环境变量变化；P3 普通级包括 MCP 工具调用、子代理调用、技能激活；P4 低级包括角色设定、会话意图分类、大型数据引用。
PreCompact 钩子 在对话压缩前触发，读取所有已捕获的会话事件，按优先级构建不超过 2 KB 的 XML 快照，存储到 session_resume 表中。如果预算紧张，低优先级事件会被丢弃而优先保留关键状态。
SessionStart 钩子 在会话恢复或启动时触发，当检测到压缩恢复场景时，从 session_resume 表检索快照，写入结构化事件文件并自动索引到 FTS5，然后构建包含十五个类别的会话指南，注入 <session_knowledge> 指令到上下文。代理得以从用户上一次提示继续工作，无需重复表述需求。
不同平台对钩子的支持程度存在差异。Claude Code、Gemini CLI、VS Code Copilot 实现完整的五种钩子支持；OpenCode 和 KiloCode 通过 TypeScript 插件实现工具级拦截但缺少 SessionStart；Cursor 因 SessionStart 被验证器拒绝目前无法实现压缩恢复；Codex CLI 的钩子系统正处于开发中；部分平台如 Zed 和 Antigravity 暂不支持任何钩子，需要通过手动复制路由文件实现约 60% 的压缩效果。
性能基准与落地参数
根据官方基准测试，关键场景的压缩效果如下：Playwright 快照从 56.2 KB 降至 299 B（99% 缩减），二十个 GitHub Issues 从 58.9 KB 降至 1.1 KB（98% 缩减），访问日志从 45.1 KB 降至 155 B（100% 缩减），Git 日志从 11.6 KB 降至 107 B（99% 缩减）。完整会话统计显示，315 KB 原始输出最终仅 5.4 KB 进入上下文，会话持续时间从约三十分钟延长至约三小时。
部署时需要关注的关键参数包括：沙盒输出大小阈值默认为 5 KB，超过此阈值且提供 intent 时启用智能过滤；知识库缓存 TTL 为 24 小时，超过此时间的重复请求会重新获取；内容清理周期为 14 天，超期内容自动删除；渐进式节流针对频繁搜索调用，前三次返回正常结果两页，四到八次返回单页结果加警告提示，九次以上重定向到 ctx_batch_execute。
安全策略方面，Context Mode 继承宿主平台已有的权限规则。如果在 Claude Code 中配置了 deny 规则如 Bash(sudo *)、Bash(rm -rf /*)、Read(.env)，这些规则同样适用于沙盒环境。权限检查会对命令链进行拆分处理，echo hello && sudo rm -rf /tmp 会因包含 sudo 匹配项而被阻止。
实施建议
对于希望在 AI 编码代理中部署上下文优化的团队，建议从以下步骤开始：首先确认目标平台是否支持 preToolUse 和 postToolUse 钩子，这是实现沙盒路由的前提；其次安装 context-mode 并完成配置验证，使用 /ctx-doctor 命令检查运行时、钩子、FTS5 和版本状态；然后通过 /ctx-stats 监控实际压缩效果；最后根据团队工作流调整渐进式节流参数以平衡检索深度与上下文消耗。
这套方案的核心价值在于重新定义了大语言模型在编码任务中的角色 —— 不是将原始数据塞入上下文让模型自行处理，而是让模型专注于编写分析脚本并接收精简的结果。在处理大规模代码仓库、频繁的测试运行、复杂的日志分析等场景时，这种范式转换能够显著提升代理的可用性和响应速度。
资料来源
- GitHub 仓库：https://github.com/mksglu/context-mode
- Hacker News 讨论：https://news.ycombinator.com/item?id=44365432