Context Mode
部署 Context Mode：分别验收 MCP 注册、钩子与会话连续性
以 Node 要求、包版本、诊断和宿主路由作为独立验收条件，建立可控的本地 Context Mode 集成。
你将学会
- 所查包要求 Node 至少为 22.5.0。
- 注册、路由和连续性需要分别测试。
- 卸载集成与删除持久数据不是同一操作。
开始前需要
- 基础 JSON 与 MCP 概念
- 隔离测试客户端和虚构数据
解释本章真实实现边界，并用明确的证据样例核验。
先看结论
- 所查包要求 Node 至少为 22.5.0。
- 注册、路由和连续性需要分别测试。
- 卸载集成与删除持久数据不是同一操作。
复制安装步骤前先固定环境
所查提交的 package.json 版本为 1.0.169，Node engine 要求至少 22.5.0。打包脚本中的较旧编译目标不是安装要求。应记录宿主真正选用的运行时，而不只是另一个终端打印出的 Node 版本。原生依赖和宿主启动时的 PATH 差异，可能导致两套环境行为不同。
发布的可执行程序名为 context-mode。README 对部分宿主提供插件安装方式，对其他宿主提供直接 MCP 注册方式。应阅读与你部署的宿主及版本对应的章节。下面配置为一次性通用 stdio MCP 测试客户端固定包版本；配置位置与外层语法仍由客户端决定。安装依赖可能运行安装脚本，需先审查。
独立验证三项能力
首先确认宿主发现预期 MCP 工具，并完成无敏感索引与搜索往返。其次检查该集成是否安装并实际启用了把普通工具工作导向 Context Mode 的钩子。最后用虚构会话事实测试该宿主文档中的连续性行为。通过第一道验收并不能证明后两项也正常。
ctx_doctor 是项目命名的诊断工具，某些插件宿主还提供斜杠命令包装。不要把某个宿主的专属斜杠命令粘贴到另一个客户端，再认定服务器损坏。保存诊断和所选集成路径：缺失钩子、缺失语言运行时与 SQLite 后端不可用，需要不同修复。
明确回退方式与数据归属
把宿主配置、已安装包和持久内容视为三类部署产物。保留此前测试配置副本，记录选定包版本，辨认该宿主报告的数据路径。移除 MCP 注册可以停止工具访问，却不一定删除已索引内容；反过来，删除存储内容也不等于卸载插件。
只有注册、实际路由、检索准确性与重启行为都符合该宿主的文档要求，才能验收。本章不认证所有平台适配器或公共托管服务。若拟对外提供服务，应另外评估所查 Elastic-2.0 条款；本地集成可用不能证明有权提供服务，也不能证明租户隔离。
实施步骤
- 1
审查依赖及具体宿主的集成指南。
- 2
在一次性环境中记录运行时和包版本。
- 3
检查工具发现、诊断及样例往返。
- 4
使用项目数据前验证路由与重启行为。
可复制示例
{"mcpServers":{"context-mode":{"command":"npx","args":["-y","context-mode@1.0.169"]}}}常见问题
为什么看得到工具，上下文仍然增长？
MCP 注册可能已经成功，但自动路由缺失或未生效。应检查实际工具调用路径，不能假设钩子已经安装。
打包目标较旧，能否直接使用 Node 18？
所查包声明 Node >=22.5.0。编译目标不能替代声明的运行时要求。
资料来源
- README.md来源核查 2026-09-07
- package.json来源核查 2026-09-07
- LICENSE来源核查 2026-09-07
- src/store.ts来源核查 2026-09-07
- src/search/unified.ts来源核查 2026-09-07
- src/server.ts来源核查 2026-09-07
- src/executor.ts来源核查 2026-09-07
- src/security.ts来源核查 2026-09-07
- src/session/purge.ts来源核查 2026-09-07
- tests/store-bytecap.test.ts来源核查 2026-09-07