seven-dpt-mcp

seven-dpt-mcp

一个轻量、本地运行的 MCP 服务，为 Claude（适用于任何项目）提供一组可持续推进的长期问题，以及逐步破解这些问题的循环——费曼的十二个最喜欢的问题方法，由灵感三元模型驱动。

• 费曼的方法（经 Gian-Carlo Rota 介绍）：在脑海中保留约 12 个尚未解决的问题；每当遇到一种新技巧，就用它逐一检验这些问题。
• 灵感 = 唤起 + 超越 + 接近动机（Thrash & Elliot）：某种刺激唤起一种可能性，你超越问题当前的框架，然后受到行动的激励。

服务保存状态并提供脚手架；连接的大模型负责思考——服务内部不运行 LLM，也不需要 API 密钥。

工具

工具	用途
add_problem	将一个长期问题添加到你的问题集（达到约 12 个上限后会拒绝添加，直到你归档/合并某个问题——或传入 overCap）
update_problem	编辑、归档、解决或重新打开问题。关闭问题时需提供 resolution——说明原因，以及重新打开的触发条件；合并属于一种归档，其 resolution 会注明吸收该问题的对象
list_problems	查看尚未解决的问题
get_problem	一个问题及其所有火花（想法、下一步、结果）——即记忆
evoke	循环的核心。 输入一种技巧；返回你的问题列表，以及一套沿着唤起 → 超越 → 接近逐步推进的脚手架
capture_spark	针对某个问题保存一个候选想法和具体的下一步（可选 costToOpen——预计后续投入；prior——你给出的 p(works)，不可变，用于之后校准；以及声明类型三元组：claimType（universal/existential-bounded）、forbids——火花排除的一种观察结果，以及 exhaustion——何时应放弃而非重新搁置。以上字段均只写入一次）
update_spark	记录火花的结果——状态（tried/worked/failed）、cost（实际投入）、value（分级收益，失败时为 0）。失败也要记录；零价值结果是学习后台投入策略的信号。如果 claimType/forbids/exhaustion 尚未设置，可补填（只写入一次：之后不会修改）
wake_status	立即评估每个已搁置问题/火花的 wakeCondition——成熟度、进展，以及每个原子的当前值/目标值回显

存储位置：~/.local/share/seven-dpt/store.json（可通过 SEVEN_DPT_DB 覆盖）。所有项目共用一个存储库，即共享一个大脑。

唤醒条件（0.1.4）

归档问题时，会将其搁置并设置重新打开的触发条件——但用文字写下的触发条件，意味着只能寄希望于“有人会记得”。wakeCondition 让它变得可计算：一个小型谓词（对 sparkCount 等原子使用 all/any，也可以设置 date 门槛、针对路径的 fileMatches / fileLines / fileCount，或显式的 manual 说明），可在归档/解决问题（update_problem）、搁置火花（update_spark）或记录一个一开始就设有门槛的火花（capture_spark）时附加。环境摘要会在每次会话开始时评估所有条件，并显示已成熟的条件（附带行动/重新搁置指引）、正在成熟的条件（附带 current/target 进度），以及醒目提示任何来源变得无法读取的条件：唤醒来源消失后必须立刻报警，不能永远停留在 0%。每个条件都会回显目标（prior-ledger.jsonl 12/20），因此路径或单位错误会在设置时就显现，而不是几个月后才被发现。不会自动重新打开：系统会提示条件已成熟，由你决定。CLI 使用 --wake 可打印完整记录。

主张类型（0.1.5）

带有唤醒条件的停放火花可以复苏——但没有任何说明规定它何时可以消亡，因此一个不可证伪的希望可以永远留在摘要中。0.1.5 为每个火花添加了一组三个可选的主张类型字段，遵循与 prior 相同的反事后设定原则，且只能写入一次：

• claimType——universal（“这始终成立”）与 existential-bounded（“在规定的框架内，某处成立”）。受框架限制的空值并不意味着主张失败；为主张标注类型，可避免把框架终止误读为杠杆终止。
• forbids——火花排除的一项具体观察。如果没有任何事物被排除，就没有任何东西能反驳它；此时火花只是一种情绪，而非主张。
• exhaustion——退役谓词，与 wakeCondition 互为对偶：满足该条件时，火花会被放弃，而非重新停放。

在捕获时设置这些字段，或在字段尚未设置时稍后补填（update_spark）；事后修改会被拒绝，并显示明确通知——看到结果后再改写主张所排除的内容，正是这些字段旨在阻止的传统主义伎俩。ledger_invariants.py 会标记孤立的存在性主张火花（已停放且有唤醒条件，但没有耗尽条件——可以复苏，却永不消亡），而 calibration.py 会为每个已评分队列标记其 claimType 构成。

启动方式

首次运行时（尚无存储文件），存储会用 seven-dpt 自身的三个未解决产品问题初始化——自动检测重复出现的问题、后台支出策略，以及主动呈现。此设计决策是有意为之：这些种子问题是通用工具级的（每次安装都相同，针对的是工具而非你），因此服务从第一分钟起就用自己的方法来检验自身，而且在你添加自己的问题之前，环境摘要也有内容可显示。它们是你的存储中的普通条目——你可以随意编辑、替换或清除；已有存储绝不会被触碰。因此，它一运行就已经在“处理自己的问题”：你忙于其他事情时，这些问题会留在上下文中，并可能因无关的发现而被触发。如何、何时以及投入多少精力追查后台问题的策略刻意没有写入代码——它应在之后从累积的 spark → outcome 历史中学习，这就是 update_spark 存在的原因。

这段历史就是奖励通道：每个 spark 都带有一个 prior（捕获时你给出的成功概率——之后不可更改，因此在足够多的 spark 得出结果后，可以根据实际结果校准你所表达的置信度）、一个 costToOpen（预估后续投入，捕获时设定并保留）、一个 cost（追查至得出结论后实际投入的精力），以及一个 value（分级的收益，未命中时为 0）。analysis/reservation_value.py 会将其转化为 Pandora's Box / Gittins 保留价值排名——但它会检查数据是否充分，在已解决的 spark（包含 cost 和 value，包括失败）积累到足够数量之前，拒绝输出数值，避免策略建立在虚假的精确度上。贝叶斯配套工具 analysis/reservation_value_bayes.py 已于 2026-10-10 停用（可在 git 历史中找到）：它从未被调用过，而且它应用于 spark 先验概率的去偏映射，是用另一个程序的账本拟合的，在那里得到的方向与此存储自身的 spark 正好相反。analysis/calibration.py 是 prior 循环中负责审计的部分：它从任意双行 JSONL 账本（其中包含预先登记的先验概率和结果）中，评估所述先验概率与实际结果的一致性（可靠性表、Brier/skill、漂移检查）；--json 会持久化该账本的去偏映射和分桶，供 analysis/self_check.py 使用。不会对 spark 先验概率应用任何映射。存储自身的统计结果——已解决 spark 的先验概率均值与成功比例，并附 Wilson 区间——会在存在至少十个带先验概率且已解决的 spark 后，作为一行显示在会话摘要中；--priors 会列出每个 spark 的先验概率及其结果。--split YYYY-MM-DD 会在变更点处分割曲线（模型升级会重新定价估算值——未经检验，不要跨升级合并），范围标记会报告已评分数据对的 claimType 组成，因为将受范围限制的 null 结果评为 claim 失败，是唯一一种仅凭数字无法被审计发现的偏差。analysis/ledger_invariants.py 审计的是该账本记录的程序，而不是任何单个探测：它针对一种失败情形检查确定性不变量——每项结果在局部上都合理，但项目仍然出错。检查项包括 park-streak（主要指标连续 K 次得出跨零 verdict，意味着应怀疑的是测量工具，而不是想法）、预登记时的统计功效（低于已存档 MDE 的门槛在运行之前就无法得出结论）、通道活跃状态标记，以及 ORPHANED-EXISTENTIAL（被搁置且有唤醒条件但没有 exhaustion 的 spark 可以复活，却永远不会终结——实际上无法证伪的投入）。它会报告自身的注释分类覆盖率，在出现警报时以状态码 1 退出，支持使用 --asof 进行反推，并通过 --json 输出 ALERT 标记，供钩子或 wakeCondition（对输出使用 fileMatches）设置门控。

安装（为所有项目启用）

通过 npm（推荐）

已发布到 npm——无需构建步骤。为每个项目注册（用户范围）：

claude mcp add --scope user seven-dpt -- npx -y seven-dpt-mcp

来自源代码（替代方式）

npm install && npm run build
# Register for every project (user scope). Use an ABSOLUTE node path — hooks and MCP
# servers don't source your shell profile, so nvm-style setups need one:
claude mcp add --scope user seven-dpt -- "$(command -v node)" "$(pwd)/dist/index.js"

然后让问题常驻上下文——合并到 ~/.claude/settings.json，这样每次会话启动时都会在上下文中包含待解决的问题：

{
  "hooks": {
    "SessionStart": [
      { "matcher": "startup", "hooks": [{ "type": "command", "command": "npx -y seven-dpt-mcp --digest", "timeout": 10 }] },
      { "matcher": "resume",  "hooks": [{ "type": "command", "command": "npx -y seven-dpt-mcp --digest", "timeout": 10 }] },
      { "matcher": "clear",   "hooks": [{ "type": "command", "command": "npx -y seven-dpt-mcp --digest", "timeout": 10 }] }
    ]
  }
}

（如果是从源代码安装的？请将每条命令替换为绝对 node 路径 + /absolute/path/to/seven-dpt-mcp/dist/index.js --digest——钩子不会加载 shell 配置文件，因此 nvm 风格的设置需要使用绝对路径。）

（如果没有待解决的问题，--digest 不会输出任何内容；全新安装时会输出预置的三个问题——这是引导流程正常运行的表现，不是噪声。）

验证这个想法

1. 添加几个自己的长期问题——add_problem。
2. 在任何代码库中遇到有趣的技巧时，调用 evoke；观察 Claude 如何针对每个问题测试它，并重新表述那些有启发的问题。
3. 让它用 capture_spark 记录有用的结果，然后在尝试之后调用 update_spark。
4. 几天后，调用 get_problem——如果累积的线索让你觉得有用，这个想法就得到验证了。

已知的 MVP 限制（有意为之）

• 使用 JSON 文件，采用最后写入胜出策略（适合单用户）。
• evoke 的匹配由已连接的模型完成，而非通过嵌入进行预排序。

许可证

Apache-2.0 — 参见 LICENSE。