Codegraph on 潘达窝

给 MCP 服务器做减法（二）：从 MCP 退到 CLI 的 fail-loud 改造

Sun, 06 Sep 2026 20:05:43 +0800

给 MCP 服务器做减法（二）：从 MCP 退到 CLI 的 fail-loud 改造

上一篇讲的是 token 账——cbm 和 codegraph 两件套的定义层税有 ~8,600 tokens/会话。这一篇讲更彻底的一刀：把 cbm（codebase-memory-mcp）整个从 MCP 进程形态退到 CLI 形态，以及退的过程中撞出来的 fail-loud 教训。数据都是本机实测（Windows 11，cbm v0.10.8，codegraph v1.6.0）。

MCP 形态的固定成本：不只是 token

先看进程结构。MCP 形态下，cbm 是三层：

flowchart LR
A[MCP 客户端] -- stdio, 每会话一个 --> B[stdio server]
B -- IPC --> C[中心 daemon]
C -- fork --> D[index worker 池]

这个结构意味着三笔固定成本，而且没有一笔能省掉：

每会话拉起一个 stdio server。只要有 N 个客户端连着，就有 N 份进程开销。上游 #1764 报的就是这个：空闲 MCP 客户端每个烧 ~0.7 核，N 会话 = N 核。
daemon 冷启。CLI 侧实测冷启一次 daemon 约 5 秒；MCP 侧更糟，上游 #1955 报新客户端要等 15-30s 才能连上健康 daemon。
worker 的资源上限形同虚设。我实测索引本仓库（~1900 文件的 C 项目）时 worker 吃到 2.7GB 内存（预算 2.8GB 几乎打满）、242s CPU；282MB 的单个 exe；stdio server 在空闲时段还平均烧 ~30% 单核。预算是 advisory 的（#1973），宁可 OOM 也不降级（#1997 报 14k 文件 monorepo 全量索引分配 ~11.5GB，无视配置）。

然后才是 token 账。cbm 的 MCP 定义层（tools/list + initialize.instructions + prompts）实测 ~5,850 tok，15 个工具 22.4KB；跟 codegraph 合计 ~8,600 tok/会话。而且 cbm 的结果还是双份返回——tree 文本 + structuredContent JSON，同一份数据塞两遍进上下文。

单看哪个数字都不致命，叠起来就是"我明明没怎么用它，它却一直在烧"的体感。最后那根稻草是 watcher，先看 2026-09-04 那次实测的完整账单：

指标	实测值	备注
index worker 内存	2.7GB（预算 2.8GB 几乎打满）	PID 1172，索引本仓库
index worker CPU	242s / 运行约 2 分钟	~21% 单核
MCP stdio server CPU	330+ CPU 秒 / 17 分钟	空闲时段平均 ~30% 单核
二进制体积	282MB 单个 exe	cbm.zip 才 37MB
watcher 行为	`strategy=git` 每 3~5 秒一轮 + 每轮 reap 一个 worker	自触发重索引循环，#1953
同仓库 codegraph 对照	磁盘 1.1GB（db 160MB + WAL 882MB）	checkpoint 饥饿，与 cbm #1083 同款病

worker 触发链当时是实锤的：会话工具在仓库内写 .codegraph/、graphify-out/（未 gitignore、untracked）→ git-strategy watcher 判定 changed → daemon 反复 fork worker。这不是低概率 bug，是默认配置的必然后果——watcher 默认开、git 策略对 untracked 敏感、而工具产物恰恰就是 untracked 文件。上游四连发可以佐证这不是孤例：#1953 watcher 自触发、#2015 worker 失败无退避（有人 4h43m 里 fork 了 2233 个 worker）、#1083 WAL 无上限（有人跑出 115GB）、#1991 每请求 ~12ms 固定地板。

为什么裁剪在 MCP 侧做不干净

第一反应是裁工具面。cbm 支持 --tool-profile=scout，实测能从 argv 解析、立即生效，定义层 ~8.6K → ~5.8K tok。但往下走就发现问题了：

1
2
3


档位 1 scout 配置 → 省 32%，零改动，但 15 个工具里只留一小撮
档位 2 自编译加 arch 档 → 要改 src/mcp/mcp.c 的 mcp_tool_allowed()，约 20 行
档位 3 退出 MCP 走 CLI → 省 68%，15 个工具全部可用

档位 2 的尴尬在于：我想要的"arch 档"（get_architecture、query_graph、detect_changes、index_status、check_index_coverage、list_projects 这 6 个 codegraph 没有的工具）上游没有，得自己打补丁。而 cbm 0.10.x 几乎周更，上游自己的 profile 裁剪 PR（#1649 思路的 DACL 补丁）已经在冲突边缘——大补丁 rebase 会痛，这是结构性问题，不是手艺问题。

更隐蔽的是配置漂移。MCP 形态下 cbm 的行为散落在好几处：_config.db（藏在 cache 目录里，#1744 报升级会丢设置）、config.json、argv、daemon 启动时机。两个具体的坑：

1
2


watcher_enabled → 只在 daemon 启动时读，改完必须 daemon stop 再起
daemon 环境变量 → 被首个会话固化，后续会话无法按需调整

也就是说，就算工具面裁干净了，运行时行为还是被"谁先启动谁说了算"的 daemon 固化——每会话一个 stdio server + 中心 daemon 的三层结构里，daemon 环境被第一个连上来的会话定型，后面的人只能接受。

这是我最终选档位 3 的真正原因：不是 token 省 68% 有多诱人，而是 MCP 形态下"裁剪"永远是在别人的进程模型里打补丁。CLI 形态下，进程模型是我的，每次调用都是干净的一次性子进程，没有固化、没有漂移。

退到 CLI：全量 15 个工具，选择权交给 skill

形态变化一句话：cbm 不再注册为 MCP server，改用

1

codebase-memory-mcp cli --json <tool> [args...]

按需子进程调用。它有个很方便的性质：每个 MCP 工具都有 CLI 等价物，所以"裁剪"这个概念直接消失了——15 个工具全量可调，一个不少，也就不存在"profile 裁不干净"的问题。工具面不再占据每个会话的上下文，调用时才产生成本。

定义层的账当场就变了：

组合（定义层）	≈ tokens/会话	相对两件套
cbm MCP + codegraph MCP（现状）	~8,600	—
cbm scout 档 + codegraph	~5,840	省 32%
cbm arch 补丁档 + codegraph	~4,550	省 47%
cbm 退 CLI，仅 codegraph 进 MCP	~2,750	省 68%

而且 bytes/4 是乐观估算——schema 是标点密集的 JSON，真实分词约 bytes/3~3.5，两件套体感可能到 ~10-11K tokens。CLI 形态下这笔税直接归零。

代价是模型看不到工具列表了，“什么时候用哪个命令"得有人管。我的方案是用 skill 规约约束，而且刻意收得很窄——只保留三个实测有效的场景，其余一律禁用：

场景	命令	为什么留给 cbm
架构概览	`cbm cli get_architecture`（aspects=clusters/cycles/hotspots）	cbm 独有，codegraph 无架构视图
图查询	`cbm cli query_graph`（Cypher、复杂度门槛）	cbm 独有
commit 影响半径	`cbm cli detect_changes`（git diff → 传递影响集）	diff 基，codegraph 的 impact 是符号基

规约里还给三类典型工作流定了调用法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


开源调研 clone 后 codegraph init + index（一次全量，之后增量自动）；
 cbm 只在确定要做架构级分析时 index_repository mode=full（语义边只有 full/moderate 有），
 用完 daemon stop；大仓（>1 万文件）用 mode=fast 先垫底。
 引用代码前必跑 check_index_coverage——parse_partial 区域的图结果不可信。

二次开发 日常 impact/callers 走 codegraph；提交前跑一次 cbm detect_changes 当"影响面自检"，
 配合 query_graph 查改动的传递调用深度。
 cbm watcher 关掉（#1953），索引新鲜度靠提交前手动 index。

自研项目 仓库 < 几千文件时 codegraph 一个就够；cbm 只做里程碑体检
 （get_architecture aspects=cycles,hotspots 查循环依赖和上帝节点）。

配套的索引分层原则也写进了规约：

1
2


codegraph = 活层（always-on，保存 ~0.3s 增量，喂日常符号工作）
cbm = 深层（milestone / 按需全量，喂架构分析与影响面，用完 daemon stop）

会话开始时 hook 自动 init/sync，我不手动管索引；cbm 只在确定要做架构级分析时 index_repository 一次，用完 daemon stop。产物目录（.codegraph/、.codebase-memory/）一律 gitignore，防 watcher 互喂。

这里有个反直觉的取舍：CLI 化之后单次冷启 daemon 要 ~5 秒，比 MCP 常驻"慢"了。但对一个每会话只按需调两三次的深层工具，5 秒 × 2 次 < 常驻进程烧掉的一切——包括那个 watcher 死循环和 2.7GB worker。低频工具的合理形态就是一次性子进程，不是常驻服务。

fail-loud：静默空结果比报错更危险

CLI 化过程中最值钱的教训是这个：工具返回"空结果"有两种可能——真的没有，或者工具坏了。MCP 形态下这两者都表现为一个正常的响应，模型根本分不清。三个实锤案例（记载在我的环境备忘里，均为实测）：

案例一：upstream #1682。 CALLS 边丢失时，trace_path 返回 callers_total: 0——和"这个函数真的没有调用方"在响应格式上完全不可区分。我一开始信了图谱的"没有调用方”，后来 grep 复核才发现调用方明明存在。

案例二：detect_changes 对非法 direction 静默返回空。 传错参数不报错，返回一个空的影响集。影响面自检场景里，“空"意味着"这次改动无风险”——把工具错误翻译成了错误的安全结论。

案例三：since 参数拒收 ^ 后缀。 传 v1.0^ 直接被拒。这算好的，好歹是个显式失败——但如果不看退出码，管道里它同样表现为"空"。

1
2
3
4
5


危险的共同模式：
 输入非法 / 内部状态损坏
 → 静默返回空集
 → 模型把"空"读成"事实上的不存在"
 → 下游结论全错，且无任何报错痕迹

防御手段我总结成三条，全部写进了 skill 规约：

否定性结论必须 grep 复核。“没有调用方/没有引用"这类结论，图谱零结果不可信——静默漏报与真实无调用不可区分，先 grep 原文再下结论。
批量修改必须带断言。用脚本补丁改配置时 assert count == 1，失败即整体回滚。我实际靠这个救回过两次——python 补丁锚点缩进错误，把一批配置键插进了错误的嵌套层级（比如插到 themeVariables.xyChart 内部），键"存在"但静默失效。批量改配置结构后还要用括号深度计数脚本断言键的层级，或者干脆整段重写而不是锚点替换。
黑名单 + 全量审计代替打地鼠。检测的"坏值清单"必须有定义来源（比如主题调色板全集），只列已知坏值会漏掉"自家配置被误用"这类新形态。正确姿势是先渲染全部形态 → 像素级/结构级普查 → 对照定义来源全集，一次扫完，而不是发现一个修一个。

把这三条合在一起，就是 skill 规约里给所有图谱类工具定的防呆前置：

1
2
3


调图谱工具前： index_status 确认索引新鲜度（索引落后时 detect_changes 结果失真）
调完拿结论前： 结论是"空/没有/零" → 强制 grep 复核，禁止直接采信
写脚本改配置： assert count==1 + 层级断言，失败即整体回滚

这三条没有一条是 cbm 特有的——任何"返回结构化结果"的工具都适用。图谱只是把问题放大了，因为它看起来太可信了：返回带行号、带符号名的精确结果，模型（和我）都倾向于直接信。

有意思的是，这个原则直接催生了 fork 补丁计划里的 #4：给 cbm 加配置化工具禁用清单（tools_disabled，双侧生效），要求禁用必须 fail-loud——调用被禁的工具要显式报错而不是静默失败，且 --help 输出与实际工具面一致。禁用一个工具后它还能被调用、或者 help 里还列着，都是配置漂移的静默形态。

fail-loud 说白了就一句话：宁可让错误炸在这一层，也不要让它变成一层之下的"空结果”。静默空结果最阴险的地方在于它消耗的是信任而不是报错——你不会去排查一个"正常"的空响应。

Windows 的 DACL 仪式

CLI 化没解决的一个问题：cbm 在 Windows 上对 daemon endpoint 做强制 ACL 检查（上游 #1624/#1856/#2023 的 ACL 设计），撞上时直接报 secure daemon endpoint could not be created。

我踩过的绕法，按代价排序：

1
2
3
4
5
6


# 1. 搬运行时目录（官方思路，但只能搬家不能豁免检查本身）
CBM_RUNTIME_DIR=D:\data\codebase-memory-mcp\runtime

# 2. 临时绕过：收紧目标目录 ACL 让检查通过（D:\data 这么干过，事后要 icacls /reset 恢复）

# 3. fork 补丁计划 #2：加 CBM_SKIP_DACL_HARDENING 开关

#2 的关键是：CLI 形态同样受 DACL 检查拖累——退到 CLI 躲开了 MCP 的进程结构税，但躲不开单机安全检查对本地回环通信的开销。CBM_RUNTIME_DIR 只是把战场挪走，检查本身还在跑。所以补丁计划里专门立了 #2：一个显式的跳过开关，本地单人场景没必要每次都做安全仪式。

这类问题在 Linux 上根本不存在，纯 Windows 单机税。但代价结构很典型：设计给多用户/低信任场景的防御，在单用户高信任环境里变成每个请求都要交的过路费。和 MCP 工具面裁剪是同构的——都是"默认配置为我不存在的场景付费"。

fork 补丁计划：把教训变成 issue

最后整理一下 fork 仓库的 issue 清单。写出来是因为每一条背后都是上面某一节的一个教训：

#	内容	状态
#1	CLI 方案取代 profile 裁剪	已关闭——直接退 CLI，profile 档位没了存在必要
#2	`CBM_SKIP_DACL_HARDENING` 开关	待做——CLI 侧同样受检查拖累
#3	默认值反转	待做——已补 CLI 侧证据：daemon 冷启 ~5s/次、detect_changes 非法 direction 静默空、since 拒收 `^`
#4	配置化工具禁用清单（tools_disabled 双侧生效 + fail-loud + `--help` 一致性）	待做——挡住实测判负的 5 个工具被误用

补丁纪律沿用之前定下的：机械、小、可重放。上游几乎周更，#1649 已经在冲突边缘，任何超出"加一组名字/加一个开关"粒度的补丁都是给未来的自己挖坑。

值得单独说的是 #1 被关闭这个信号：最初计划里"给 MCP 加更好的 profile 档位"是正经理方案，做着做着发现 CLI 形态让整个问题消失了。最好的裁剪是不需要裁剪——工具面从来不进上下文，就无所谓留哪 6 个砍哪 9 个。

这套退法在整体方案里的位置

退 CLI 不是孤立动作，它是一个分层方案的地基。完整规划是三步：

1
2
3
4


P0 只包 codegraph 进 MCP（4 个短工具：search / source / relations / impact）
P1 CBM 保持 CLI 按需调用——本文讲的退法就是这一步的落地
P2 仅当"出会话跑 CLI"摩擦大到不可接受，才在门面里延迟拉起 CBM 三个工具
 （第一次调用才 spawn cbm cli，空闲超时 daemon stop）

配套的验收清单里，几条硬指标直接针对 MCP 形态的老病：

1
2
3
4


- 会话 tools/list 工具数 ≤ 8，描述合计 ≤ 4KB（对 ~22.4KB 的 cbm 全量）
- 日常 search/source/relations/impact 不启动 cbm.exe / cbm daemon
- 结果无双份 JSON（cbm 的 tree + structuredContent 双份是重点封杀对象）
- 需要架构分析时有文档化的 CLI 一步（含 daemon stop）

同样重要的是"明确不做"清单：不给 cbm 关 LSP、拆 daemon、硬内存上限——那是敌对 fork，和周更上游打架。改不动的地方绕过去（CLI、CBM_RUNTIME_DIR），绕不过去的立 issue（#2/#3/#4），这就是补丁计划全部是"开关级"改动的原因。

复盘下来，“从 MCP 退到 CLI"与其说是性能优化，不如说是一次责任边界的回收：进程模型、调用时机、失败语义，全部收回到我自己的 skill 规约里。代价是我要自己维护规约、自己复核否定性结论。但考虑到静默空结果曾经让我把"图谱说没有调用方"当成事实写进结论——这笔交易不亏。

给 MCP 服务器做减法（一）：实测判负的工具与裁剪依据

Sun, 06 Sep 2026 20:04:24 +0800

给 MCP 服务器做减法（一）：实测判负的工具与裁剪依据

我深度用了两周 codebase-memory-mcp（下称 cbm），一个把代码库索引成知识图谱的 MCP 服务器，15 个工具。结论是：15 个里只有 3 个场景真正立住了，其余全部判负——要么被 codegraph 同类工具碾压，要么 CLI 里一行命令就有等价物，不值得在每轮对话里交定义层税。这篇记录判负的证据和方法，不记录情绪。

先算账：15 个工具的定义层税单

判负之前先量化"养着这些工具要花多少钱"。MCP 的成本模型里有个容易被忽略的项：工具定义不是调用时才付费，而是每个会话每轮对话都常驻在上下文里。

cbm 是 stdio server，我就以 MCP 客户端身份把它拉起来，抓 tools/list 的真实载荷。探针是个几十行的 Node 脚本（简化版）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// mcp_probe.cjs：拉起 stdio server，抓 initialize + tools/list 全量载荷
const child = spawn(cmd, args, { stdio: ["pipe", "pipe", "inherit"] });

send({ jsonrpc: "2.0", id: 1, method: "initialize",
 params: { protocolVersion: "2024-11-05", capabilities: {}, clientInfo: { name: "probe" } } });
send({ jsonrpc: "2.0", method: "notifications/initialized" });
send({ jsonrpc: "2.0", id: 2, method: "tools/list" });

child.stdout.on("data", buf => {
 // 按 Content-Length 拆帧，落盘每个响应的原始字节数
 frames.push({ id: msg.id, bytes: buf.length, payload: msg });
});

初版只量了 tools/list，后来发现漏了两项：MCP initialize 响应里的 instructions 字段（规范客户端会注入系统提示词）和 prompts 列表。补齐后的完整账单：

定义层	codegraph	cbm 全量
tools/list（描述+schema）	6,762B ≈ 1,691 tok	22,441B ≈ 5,610 tok（15 个工具）
instructions 字段	4,226B ≈ 1,057 tok	808B ≈ 202 tok
prompts 列表	无	2 个 ≈ 37 tok
定义层小计	≈ 2,748 tok	≈ 5,850 tok

payload 字节数到手后换算 token。这里有个容易自欺的地方：用 bytes/4 估是乐观值，对 schema 这种标点密集的 JSON，真实分词更接近 bytes/3~3.5：

1
2
3


// 估算口径：两档一起报，给区间不给单点
const tokensOptimistic = bytes / 4; // 乐观下界
const tokensRealistic = bytes / 3.5; // 标点密集 JSON 的经验档

两个 server 一起挂着，定义层合计 ≈ 8,600 tokens/会话，乐观估算下真实体感可能到 10-11K。

最扎眼的是 codegraph 那行 4.2KB 的 instructions：一整套行为指令（“直接回答别委派子 agent"“先于 Read/Grep 调用”）。这是把工具用法写死进系统提示词，替模型做工作方式决策。cbm 反过来，instructions 很短，但用 15 个工具的长描述把复杂性全堆在 tools/list 里。两种路线，交的税一样。

调用时的开销另算，而且更隐蔽：cbm 每个结果是双份返回——tree 文本和 structuredContent JSON 是同一份数据给两遍，结果侧直接 ×2。codegraph 单份但载荷密，官方自己承认常驻上下文 +80%。

结果侧的浪费也顺手写进了探针：同一个结果，content 里是 tree 文本，structuredContent 里是同数据的 JSON 序列化。对模型来说信息为零增益，token 直接翻倍。

判负的标准：三条硬证据

“我感觉没用"不是裁剪依据，MCP 工具面的每一次删减都要能回答：删了之后工作流会不会退化？

我的判负标准是三条，全部可复测：

真实调用率：回看若干个真实会话的调用记录，哪些工具被 agent 主动调过；
结果质量：调了之后，是否真的省掉了后续的 grep/Read 次数，还是拿到结果还得回原始文件验证；
CLI 等价性：这个工具在 cbm cli 里有没有一行等价命令——有的话，退出 MCP 只损失"agent 自主发现"这一点，能力不丢。

第 1 条有个陷阱要说明：agent 不调 ≠ 工具差。可能是 schema 写得糊、描述太长模型没读进去。但对裁剪来说结论一样成立——一个 agent 不会主动调的工具，挂在工具面里就是纯税。

这三条里第 3 条最关键，它把"裁剪"从减法变成了搬家：MCP 定义层省下的 token 是确定的，能力通过 CLI 随时可取回。没有等价物的工具才需要真正纠结去留。

还有一个反向的佐证：实测里 agent 对工具的误用集中出现在少数几个工具上——schema 越长、描述越糊，模型越容易拿错误的参数组合去撞。工具面越长这个问题越严重，15 个工具互相干扰，单个工具的描述再精准也救不回来。

逐个判负：砍掉的、留下的、可惜的

15 个工具过一遍筛子。判负名单按"被谁替代"分组，证据都来自实测记录和上游 issue。

flowchart LR
A[cbm 15 个工具] --> B{三条硬证据筛}
B -->|被 codegraph 碾压| C[判负组 1：符号级查询]
B -->|CLI 有等价物| D[判负组 2：管理面]
B -->|真实会话零调用| E[判负组 3：list_projects]
B -->|三场景对照实验立住| F[保留：3 个场景工具]

判负组 1：符号级查询，被 codegraph 碾压。 这是最大的一组。符号搜索、取源码、调用链——这些是 codegraph 的基本盘，而且强得多：

能力	cbm 工具	codegraph 对应	判负理由
符号搜索	search_graph	search	codegraph 一次返回限定元数据，够用且轻
取源码	get_code_snippet	node / explore	explore 一次拉一组符号的完整源码，cbm 做不到
调用链	trace_path	callers / callees / trace	cbm 有 #1991：每请求固定 ~12ms 地板（0.9.0 时代是亚毫秒），codegraph 无此税

trace_path 的判负最干脆：调用链分析 codegraph 的 callers/callees/trace 全覆盖，cbm 这边还背着 12ms/请求的进程间协调地板。同一次查询，没有理由选慢的那个。

判负组 2：管理面，全走 CLI。 索引、同步、daemon 控制（index_repository、daemon stop、config 类）占了好几个工具位，但它们的调用者是人，不是 agent——我从来没需要让模型自主决定"什么时候重建索引”。这类工具留在 MCP 工具面里，等于让每轮对话为低频管理操作付常驻税。

判负组 3：list_projects。 T1-T3 对照实验里，三个真实场景（架构概览、图查询、变更影响）它一次都没进过调用路径，而 CLI 里一行就有。典型的"挂在那显得功能全"的工具。

唯一可惜的舍弃：semantic_query。 概念级查找（“找处理重试的逻辑"这类不精确匹配符号名的需求）是符号搜索真覆盖不了的。但它依赖向量语义边——而语义边恰恰是素材里判定"贬值最快"的那类增值插件。如果哪天真需要，方案是把它做成搜索工具的可选参数挂 vector 索引，不单开工具。

留下的：3 个场景。 对照实验里立住的三个，恰好都是 codegraph 没有的能力：

1
2
3
4
5
6
7


get_architecture # 架构概览：Leiden 社区划分、复杂度热点、循环依赖
query_graph # 图查询：写 Cypher 做"谁调了 X"、跨模块模式确认
detect_changes # 变更影响：git diff → 受影响符号的传递集（提交前自检）

# 另有两个排查辅助留在 CLI 侧，不进 MCP：
index_status # 索引新鲜度——结果失真前先看这个
check_index_coverage # 覆盖度审计——parse_partial 区域的图结果不可信

这 3 个能立住不是偶然：get_architecture 的 Leiden 社区和 detect_changes 的传递影响集是图算法，tree-sitter 解析完之后的加工增值；而符号级查询本质是"更贵的 grep”，模型演进越快这类工具越容易被原生搜索追平。不贬值的是图算法、覆盖度审计、跨会话索引资产——裁剪就是留下不贬值的。

中间档：scout 和 arch，为什么不选

裁剪不是只有"全留"和"全退"两个选项。cbm 官方有 tool-profile，自编译还能加自定义档，我在这两档之间停留过，最后还是走了 CLI。

scout 档是零改动方案，一行配置：

1
2
3
4
5
6
7
8


{
 "mcpServers": {
 "codebase-memory-mcp": {
 "command": "codebase-memory-mcp",
 "args": ["--tool-profile=scout"]
 }
 }
}

arch 档官方没给，要自己编译——在 src/mcp/mcp.c 的 mcp_tool_allowed() 里加一组工具名，约 20 行：

1
2
3
4
5


// 思路示意：在白名单函数里加一个档位判断
if (strcmp(profile, "arch") == 0) {
 return tool_in(tool, "get_architecture", "query_graph", "detect_changes",
 "index_status", "check_index_coverage", "list_projects", NULL);
}

三档的省幅：

档位	动作	定义层 token	相对现状
现状两件套	—	~8,600	—
scout 档	一行配置	~5,840	省 ~32%
arch 档	自编译补丁	~4,550	省 ~48%
退出 MCP	CLI + skill	~2,750	省 68%

scout/arch 档对"还想留在 MCP 里"的人是合理阶梯。但它们有个共同问题：判负的工具只是被藏起来了，定义层的判断负担还在——我要持续维护"哪些该露出来"的清单，而 CLI 路线把这个维护成本一次性归零。既然判负证据已经够了，中间档只是延迟同一个结论，我没有停在那。

保留集的工作流：CLI + skill 配方

退出 MCP 之后，cbm 的形态从"server 常驻"变成"按需起进程”。三个场景各自有固定配方：

1
2
3
4
5
6
7
8


# 场景 1：架构概览——大仓库第一刀，先看事实上的模块切分
cbm cli get_architecture --aspects clusters

# 场景 2：跨模块确认——Cypher 直查
cbm cli query_graph --query "..."

# 场景 3：commit 影响半径——提交前跑一次当自检
cbm cli detect_changes --since HEAD~1

和 CLI 配套的是把配方烧进一个 skill：skill 里写死"什么信号出现时调哪个 CLI 命令、结果为空怎么排查"。这相当于把"MCP 工具描述"的引导职能从定义层搬到了 skill 文本——区别是 skill 文本只在需要时加载，不占每轮对话。

说白了这是一笔交换：放弃 agent 的自主发现（模型自己看到工具描述决定调用），换成确定性调度（skill 规则触发）。实测下来 agent 自主发现 15 个工具的成功率并不高——schema 太长，描述互相干扰，误用和空转不少。确定性调度反而准。

两个 server 的分工随之定型，索引也分成两层：

1
2


codegraph = 活层（always-on，保存后 ~0.3s 增量，喂日常符号工作）
cbm = 深层（milestone/按需全量，喂架构分析与影响面，用完 daemon stop）

裁剪后的定义层税单：8,600 → 只剩 codegraph ≈ 2,750 tok，省 68%，且 cbm 的结果侧双份开销也一并消失。

反向参照：如果只留 8 个工具，理想长什么样

判负做完，我把两个 server 的能力摊在桌面上重新排列了一次：假如从零设计一个最小工具面，它应该是什么形状。这张表也是裁剪依据的一部分——它划出了"该留的"和"增值插件"的边界。

六个能力层、8 个工具，管理面全部走 CLI 不占 MCP 定义层：

层	工具	接口要点	对应物
L1 定位	search	名称/正则/BM25，返回限定元数据	codegraph search
L2 读取	source	符号 → 源码+签名+紧邻调用	codegraph node / explore
L3 关系	relations	方向(in/out/path)+边类型，游标分页	codegraph callers/callees/trace
L4 变更	impact / diff_impact	符号级影响；git diff → 传递影响集	codegraph impact / cbm detect_changes
L5 导览	architecture	modules(社区)/cycles/hotspots	cbm get_architecture（独有）
L6 信任	coverage	逐文件解析覆盖+索引新鲜度	cbm check_index_coverage（独有）

按短描述+精简 schema 算，8 工具的定义层预算约 3-4KB ≈ 900 tok。对比现状 8,600，省幅在 70% 以上。

同样重要的是明确排除的清单——这些是调研里判定"贬值最快"的增值插件：

1
2


向量语义边、相似度边、跨仓 intelligence、运行时轨迹注入、
ADR 存图、graph UI、常驻 daemon/协调层

这张表给我的最大启发是"成本前置 vs 成本后置"的分野：cbm 是成本前置 + 捆绑销售（耐用品和易耗品强制一起买），codegraph 是成本后置 + 行为导演。模型演进越快，为弱模型设计的补偿性智能贬值越快——L1 到 L3 那几层本质是"更贵的 grep"，而 L5/L6 依赖的图算法和覆盖度审计不会贬值。裁剪清单和这张表是同一个判断的两个投影。

代价核对：判负清单之外的理由

工具面裁剪解决 token，但 cbm 的账不止这一页。记录性能侧的实测，作为"为什么不留着试试"的补充证据。

2026-09-04 的一次普通会话里抓到的数字（本机 Windows 11，~1900 文件的 C 项目）：

指标	实测值	对应上游 issue
index worker 内存	2.7GB（预算 2.8GB 几乎打满）	#1973：预算是 advisory，宁可 OOM 不降级
MCP stdio server	空闲时段 ~30% 单核	#1764：每个空闲客户端烧 ~0.7 核
二进制体积	282MB 单个 exe	—
watcher	每 3~5 秒一轮自触发重索引	#1953：git 策略对 untracked 文件敏感，工具产物喂它死循环
失败 worker	无退避无限重 fork	#2015：4h43m 内 2233 个 worker

触发链已经实锤：会话工具在仓库里写 .codegraph/ 这类产物目录 → git-strategy watcher 判定 changed → daemon 反复 fork worker。解法之一是把产物目录 gitignore，但更根本的是——一个"高性能"卖点著称的索引服务，默认配置下会和客户端工具互相喂出死循环，这本身就是工具面之外的设计债。

cbm 的深度（LSP 类型解析 + 语义边）是用内存和常驻进程换的，codegraph 的增量快是用磁盘和 WAL 换的，没有免费午餐。但"深度"大部分在判负清单里已经卖不出去了——剩下 3 个场景恰恰不依赖常驻 daemon，按需起进程跑完就停，反而是对它资源模型最友好的用法。

裁剪的尽头是一个朴素的判断：MCP 工具面应该只放"agent 每轮都可能自主用到"的东西，低频能力、管理面、被更强工具覆盖的能力，都该退到 CLI。15 个工具筛完剩 3 个场景，token 省 68%，误用率归零（没有可误用的了）——这个比例让我怀疑大部分 MCP 服务器都超配了一倍以上。下一篇写从 MCP 退到 CLI 的过程中暴露的另一类问题：CLI 静默失败——空结果和真失败不可区分，agent 拿着空输出继续推理，比误用工具更危险。所以下一步是给 CLI 做 fail-loud 改造：非法参数报错、空结果带原因、退出码讲真话。