代码知识图谱（Code Knowledge Graph, CKG）的价值最终要通过「查询」与「推理」兑现：前者决定 agent 能否以最小代价取得准确的结构化事实，后者决定工具能否跨越单点事实回答「改这一处会波及什么」「这条数据流从哪来」之类的高阶问题。本章在第三章（抽取与增量）所确立的图结构之上，从表达力层级、查询语言暴露策略、MCP 集成粒度、推理能力矩阵、检索范式五个维度，系统比较 Graphify、GitNexus、CodeGraph 三者，并归结到评测模型 D5（查询表达力）与 D6（集成面）的判据。
需要预先说明本章的分析视角：我们不把「查询能力」等同于「底层图库功能」，而聚焦于agent 实际可触达的查询面------即 MCP 工具签名、暴露的查询语言、以及推理原语的组合方式。同一张图，若只给单入口模板，其可达查询空间远小于开放 Cypher 时。因此本章的「表达力」是调用方可达的表达力，而非图数据模型的理论表达力（后者请参考第二章的图模型对照）。
4.1 查询表达力层级 L0--L6：形式化定义与三工具天花板
为可比地衡量三者的查询天花板，我们引入一套从「点查」到「图算法」的七级表达力层级（L0--L6），其理论根植于图查询语言的形式化研究------包括正则路径查询（Regular Path Queries, RPQ）及其合取扩展（CRPQ）、传递闭包与导航式查询等 (Revisiting the Expressiveness Landscape of Data Graph Queries)。该层级并非任意划分，而是对应「查询语言能表达的计算类别」：从单点检索（L0）到图灵式图算法（L6），表达力逐级单调递增，但每一级的实现成本与可控性也同步变化。
| 层级 | 名称 | 典型能力 | 表达示例 |
|---|---|---|---|
| L0 | 点查（point lookup） | 按 id/标签取单节点属性 | get_node(label) |
| L1 | 一跳邻居（1-hop） | 取某节点直接相连节点 | get_neighbors(label) |
| L2 | 定长多跳（fixed multi-hop） | 固定跳数内的路径/子图 | shortest_path(a, b, max_hops=8) |
| L3 | 变长/传递闭包（variable-length / transitive closure） | 形如「所有被 A 间接调用的函数」 | Cypher MATCH (a)-[:CALLS*1..5]->(b) |
| L4 | 子图模式匹配（subgraph motif matching） | 多子句模式、WHERE 过滤、OPTIONAL MATCH | Cypher 多 MATCH + WHERE 组合 |
| L5 | 聚合/分析（aggregation/analysis） | COUNT/COLLECT/GROUP BY、WITH 管道 | Cypher WITH ... RETURN count(*) |
| L6 | 图算法（graph algorithms） | PageRank、社区发现、中心性 | 需 GDS 类插件或预计算服务 |
L2/L3 分界的可操作判据。 上表 L2 与 L3 的示例（shortest_path(a, b, max_hops=8) 与 MATCH (a)-[:CALLS*1..5]->(b)）在形式上都属「带上界的不定长遍历」，若仅以「路径长度是否可变」为分界，二者无法区分------而这条分界线直接决定 Graphify 的天花板判定，因此必须给出可操作规则：
L2/L3 判据：查询返回的是「单条（或 k 条）路径」，还是「满足条件的完整可达集合」。 前者判 L2，后者判 L3。
按此判据，shortest_path 即便允许 max_hops=8，其语义仍是求最短路------返回一条（或若干条）路径，不产生传递闭包意义上的节点集，故判 L2 ；而 [:CALLS*1..5] 返回全部满足长度约束的匹配，构成一个有界传递闭包，故判 L3 。这条判据之所以比「长度是否可变」更本质，是因为 L3 的真正门槛不在「跳几步」，而在结果的基数由图结构自身决定、而非由查询预先固定 ------这正是传递闭包区别于定长连接的地方，也是下游聚合（L5）得以成立的前提：能对「集合」做 count，却无法对「一条路径」做有意义的聚合。据此，凡返回受影响节点集合 的影响面分析（Graphify get_pr_impact、CodeGraph codegraph_impact(depth=2)、GitNexus impact）一律判 L3 ，而非 L2；返回单条路径的 shortest_path 则稳定判 L2。本章后文所有分级均按此规则校准。
核心论点：Cypher 原生支持 L3--L5，而包装式接口（如 CodeGraph 的 QueryBuilder、Graphify 的 query_graph）被开发者预设的模板封顶在 L3+。 这一差别不是工程实现的偶然，而是查询语言「声明式暴露程度」的必然结果：声明式语言把「算什么」交给调用方描述，模板式接口把「能算什么」提前写死在工具签名里。
为什么 L3 是分水岭？因为变长路径与传递闭包（transitive closure）首次引入了量化/不定界遍历 ------查询不再是一棵固定形状的树，而是一条可被图结构自身「展开」的关系链。在形式化理论中，RPQ 的表达力严格强于仅做定长连接的查询；而当路径长度可带区间 [1..5] 或无界 * 时，查询甚至可能不可终止（在稠密图上路径数指数膨胀）。L4/L5 进一步叠加了模式组合与聚合，使「计数、分组、去重、投影」成为查询的一等公民------这些恰恰是模板式接口最难预先穷举的部分。
进一步说，L4 与 L5 把「查询」从「取数」升级为「分析」。例如 L4 可表达「找出所有同时继承基类 B、被测试 T 覆盖、却未被任何公共 API 引用的内部类」这类多约束子图模式；L5 则可进一步「按模块聚合，统计每个模块的平均扇入扇出」。这类查询在代码审查、技术债评估、架构治理中极有价值，而它们恰恰落在 Cypher 的舒适区、却超出任何预置模板的枚举能力------因为组合爆炸使「为每种模式都造一个工具」在工程中不可行。
Cypher 的表达力锚点。 Cypher（及其开放规范 openCypher）以模式匹配与变长路径为一等公民；openCypher 官方明确其定位已转向「为实现者铺就通往 GQL 的道路」，并随 ISO/IEC 39075 GQL 于 2024 年 4 月 11 日 正式发布而进入增量对齐阶段 (openCypher)。GQL 是自 1987 年 SQL 以来 ISO 发布的第一个全新数据库语言标准 ，其查询结构与 Cypher 基本一致（同样使用 MATCH ... RETURN 与 ASCII-art 模式），差异主要在少数关键字（如 GQL 用 INSERT 对应 Cypher 的 CREATE、用 FOR 对应 UNWIND），并新增了量化路径模式（quantified path patterns）等增强 (GQL: The ISO standard for graphs has arrived)。变长路径 *1..5、无界 *、以及 WITH ... RETURN 的聚合管道，使单条语句即可覆盖 L3--L5；若底层图库装载图算法插件，还可触及 L6。因此「是否原生暴露 Cypher」在相当程度上等价于「能否突破 L3 天花板」------这正是 D5 判据的核心分水岭。
GQL 标准的意义在于：它使上述表达力不再是某家图库的私有方言，而成为可移植的能力基线。对 CKG 这类长期维护的资产而言，选择「原生契合 GQL/Cypher」的查询面，意味着未来可被更多图工具消费、查询可被复用与迁移；反之，绑定某一工具的私有模板接口，则把查询逻辑锁死在实现细节里。本章不评判「是否该用标准语言」这一工程哲学问题，但把它列为 D5 的隐含判据之一。
三工具天花板判定：
-
GitNexus ------ 天花板「可组合 L6」（图库侧前件已核实，部署侧前件未核实），实际 L5+。 它是三者中唯一暴露原生 Cypher 的工具（
cypher工具，参数statement必填、params对象、repo可选；输出{markdown, row_count}）(GitNexus tools.ts)。这意味着 agent 可写出任意 L0--L5 查询。关于 L6，本报告作了一次专门核实，因为「若图库支持算法过程则可达 L6」这一条件式表述若不验证前件，就等于把假设当能力计入。核实结果：其底层 LadybugDB（「formerly KuzuDB」）的上游 Kuzu 自 0.10.0 起提供algo扩展，把 PageRank、Louvain、K-Core 分解、强连通分量、弱连通分量 等图算法以 CypherCALL函数的形式原生暴露 ，且可与任意 Cypher 子句自由组合（先CALL project_graph('G', ['Person'], ['KNOWS'])建立投影图，再CALL page_rank('G') WITH node AS n ORDER BY rank DESC LIMIT 10 MATCH (n)<-[...]-(...)续接）(Kuzu --- Algo extension、Kuzu 0.10.0 Release)。因此前件在图库层面成立 ，「理论 L6」不再是悬空假设。但仍有一个前件未能核实：algo是需INSTALL/LOAD的可选扩展 ，而 GitNexus 运行于浏览器 WASM 环境，其构建产物是否包含并允许加载该扩展，本报告未在源码或文档中找到依据，记为未公开 ；且 GitNexus 的 MCP 面本身未提供任何以图算法为语义的工具，L6 只能经cypher手写触及。综合判定：GitNexus 属「可组合 L6」------图库侧能力已核实，部署侧可用性未核实。 其pdg_query（mode必填 controls/flows、target必填，须--pdg启用）以「锚定目标、不做全仓枚举」的方式提供数据流子图模式（L4 级），impact/trace提供有界多跳闭包（L3 级）。 -
Graphify ------ 组合式表达力封顶约 L3+，另含已实装的「固定视图 L6」。 其 MCP 表面由
serve.py（v8）实定义并注册 的 10 个 工具构成：README 对外公开的 7 个（query_graph、get_node、get_neighbors、shortest_path、list_prs、get_pr_impact、triage_prs），加上 README 未列、但同样进入tools/list的 3 个服务层工具（get_community、god_nodes、graph_stats）(Graphify serve.py)。按前述 L2/L3 判据：shortest_path（max_hops默认 8，返回单条路径）判 L2 ，get_pr_impact（返回受影响节点集合）判 L3 ；query_graph以自然语言驱动范围子图遍历（mode枚举 bfs/dfs，默认 bfs；depth默认 3；token_budget默认 2000），其表达力取决于内部 LLM 把自然语言映射为哪种遍历------本质仍受「预置遍历模板」约束，封顶约 L3。至于那 3 个服务层工具，此处需要一次判定规则上的澄清，否则容易对 Graphify 系统性折价。
get_community（Leiden 社区）与god_nodes（度中心性排序）在输出层面 交付的，正是标准的 L6 级图算法结果，且是已实装、开箱即用、无未核实前件 的。本章因此把 L6 拆为两个子档，并对三家同规则落点：- 固定视图 L6------算法结果由厂商预计算、以固定出口交付；调用方不能自选算法、调参数或改投影范围。
- 可组合 L6------调用方可在查询语言内自选算法，并与其他子句任意组合。
据此，Graphify 落在「固定视图 L6（已实装）」，GitNexus 落在「可组合 L6（图库侧已核实、部署侧未核实）」，CodeGraph 两者皆无。 需要强调：这两个子档不是「真 L6 与假 L6」的关系，而是同一表达力层级的两种交付形态------前者以自由度换取零学习成本与结果确定性，后者以确定性换取覆盖未预见问题的能力。此前将 Graphify 的已实装能力以「不可自定义组合」为由判为「不提升表达力上限」，同时将 GitNexus 的未验证条件式能力直接计入高位，是两套标准并行，本次修订予以纠正。Cypher 在 Graphify 上仅在导出 Neo4j/FalkorDB 后可用------即「在线无 Cypher，离线导出才有」。
-
CodeGraph ------ 天花板约 L3+，单入口动态分发（8 个定义 / 默认暴露 1 个）。 它仅默认暴露一个 MCP 工具
codegraph_explore（query必填、maxFiles默认 12、projectPath可选）(CodeGraph tools.ts)。源码中tools数组逐字定义 8 个工具------codegraph_explore、codegraph_search、codegraph_callers、codegraph_callees、codegraph_impact、codegraph_node、codegraph_status、codegraph_files------但DEFAULT_MCP_TOOLS = new Set(['explore'])使getTools()／getStaticTools()只把explore放进tools/list返回值，其余 7 个「处理函数始终存在、功能完整」，仅在CODEGRAPH_MCP_TOOLS环境变量白名单（逗号分隔短名，如explore,node,search）中被点名时才现身；execute()内还有isToolAllowed()做二次防御性拒绝。这一实现细节印证了 README 「其余工具保持完全可用但默认不列出」的表述。换言之，agent 侧只见单入口，表达力上限由开发者预设的查询模板界定（L0--L3），L4/L5 聚合与模式组合不通过该入口直接暴露------即便隐藏的codegraph_callers／codegraph_callees（symbol必填、limit默认 20）与codegraph_impact（symbol必填、depth默认 2）在白名单开放后可提升表达力------按前述判据，callers/callees返回直接邻居集合属 L1 ，codegraph_impact(depth=2)返回受影响节点集合属 L3 ------仍无 L4/L5 的声明式组合能力，也无任何形态的 L6。此外，当 MCP server 未绑定默认项目时，withRequiredProjectPath()会把projectPath由可选升格为必填，这是三家中唯一在 schema 层面做动态必填切换的设计。
需要强调的是：三者的「可表达上限」差异，主要源于查询语言的暴露形态，而非底层图的能力差异。Graphify 与 CodeGraph 的图本身足以承载 L4/L5 信息（边带溯源、节点带类型），只是其 MCP 接口未把「写聚合查询」的权力交给调用方。这就把本章的核心矛盾暴露出来：表达力的上限，是用「灵活性」换「安全性/可控性」换来的------下一节展开。
L6 的实际含义值得点明。以「找出若重构则波及面最广的枢纽模块」这类架构问题为例，三家的处境并不相同：Graphify 能直接回答 ------god_nodes 就是按度中心性排序的枢纽清单，get_community 给出社区划分，调用一次即得，且不要求调用方具备任何图算法知识；GitNexus 也能回答 ，但需调用方自己写出正确的 Cypher（若其部署允许加载 algo 扩展则可直接 CALL page_rank，否则须用聚合子句近似度中心性）；CodeGraph 则无法在 MCP 面表达这类问题。
可见分野不在「谁有 L6」，而在自由度与确定性之间怎么取舍 ：Graphify 交付的是「开发者替你选好的那几个高价值算法结果」，代价是问题一旦偏离预设视图（例如想按「加权调用频次」而非「度」排序枢纽，或想只在某个子模块内做社区发现）就无从表达；GitNexus 交付的是「你自己组合」，代价是正确性责任转移给了调用方（见 4.2 弊一），且其部署侧前件尚未核实。这正是 D5 把「是否可达 L6、以何种形态可达」同时作为判据的原因------它不是理论趣味，而是「工具能否回答架构级问题」与「谁来为这个回答的正确性负责」两个问题的交汇点。
4.2 「暴露查询语言」的双刃剑
将 Cypher 这样的图查询语言直接暴露给调用方，是一把明显的双刃剑，其利弊必须并陈，不能因为「表达力强」而遮蔽工程与安全风险。
利：表达力无上限、可组合、可审计。 GitNexus 的 cypher 工具让 agent 能表达任意 L0--L5 查询，无需工具作者预先穷举用例。对「罕见但合法」的检索（如「找出所有既继承 A 又被 B 测试覆盖的类」），声明式语言天然优于固定模板。Cypher 语句本身也是可审查、可缓存、可度量的工件，便于在 CI 中复跑与回归。
弊一：Text-to-Cypher 的幻觉与准确率风险。 当调用方是 LLM 而非人类时，它会「即兴生成」Cypher。这一环节的可靠性有可查的学术证据，且结论并不乐观。据一项在 Hetionet 生物医学知识图谱上、以 240 条三级复杂度查询构成的基准评测显示，ChatGPT-4o 的执行准确率（execution accuracy）为 72.1% ，经微调的 CodeLlama-13B 为 69.2% ；同一研究还指出，引入上下文感知的 schema 注入后，ChatGPT-4o 的组件匹配准确率相对朴素提示提升了 23.6 个百分点 ------反过来说，没有 schema 接地时，准确率会显著劣化 (Enhancing knowledge graph interactions: A comprehensive Text-to-Cypher pipeline with large language models)。另一项以语义 schema 引导提示（T2CSS）的研究报告 GPT-4 达到约 86% 的正确率 (Prompting large language models based on semantic schema for text-to-Cypher transformation towards domain Q&A)。而在开源小模型侧，形势更严峻：Text2Cypher-2024v1 基准上，Qwen2.5-7B-Instruct 的基线执行准确率仅 20.84% 、语法错误率 25.6% ，即便叠加草稿式 schema 链接与自纠正工作流也只升至 29.14% (SpiderCypher / Text-to-Cypher 复现仓库)；Neo4j 官方亦专门撰文分析 Text2Cypher 模型的系统性失败模式 (Neo4j Text2Cypher: Analyzing Model Struggles and Dataset Improvements)。
把这组数字放进本报告的语境，可推出一条对选型有直接约束力的结论：GitNexus 暴露 Cypher 所解锁的「无限表达力」，其实际兑现率受制于调用方模型的 Text-to-Cypher 能力 。若 agent 由前沿模型驱动，七成上下的执行准确率尚可用「人在环上复核」兜住；若由本地小模型驱动，两三成的准确率意味着这条「无限表达力」通道在多数时候是失效甚至有害的。更棘手的是错误的呈现形态：SQL 写错通常报错，而 Cypher 写错------尤其是关系方向写反、标签拼错、变长区间写窄 这三类错误（此三类系本报告归纳的典型错误 ，非引自某项失败模式分类研究；上引 Neo4j 官方对 Text2Cypher 系统性失败模式的分析可作旁证，但其分类维度与此不同）------往往返回一个语法合法的空结果集。空集在 agent 眼中与「确实不存在」不可区分，于是模型会自信地得出「没有调用者，可以安全删除」这类灾难性结论。
但这条论证必须再往下推一层，否则会错怪 Cypher。 严格地说，「标签拼错 → 静默空集」对 Neo4j 系并不成立：数据库确实提供了警告信道 。当查询引用了库中不存在的标签、关系类型或属性键时，Neo4j 会返回 Neo.ClientNotification.Statement.UnknownLabelWarning（GQLSTATUS 01N50，分类 UNRECOGNIZED，严重级 WARNING，状态描述明确写着「The label X does not exist in database Y. Verify that the spelling is correct.」）、UnknownRelationshipTypeWarning（01N51）与 UnknownPropertyKeyWarning；针对本节「弊二」将述的无界变长路径，还另有 UnboundedVariableLengthPatternWarning 专门提示「模式无上界，建议为跳数添加上限」(Neo4j --- List of notification codes)。换言之，「这个空集是因为拼错、还是因为真的不存在」这一信息，在数据库层是可得的。
真正的问题因此不在语言层，而在工具实现层 ：GitNexus cypher 工具的输出契约是 {markdown, row_count}（见 4.1 对其工具签名的一手核实）------只有结果与行数，没有 notification 字段 。数据库递上来的警告信道，被 MCP 工具的输出 schema 原样丢弃了。这一改写把论断的性质从「Cypher 语言的固有缺陷」升级为「本工具实现层面的、可归因且可修复的缺陷 」：它更准确（不冤枉语言），也更犀利（指出的是一处几十行代码即可补上的窟窿），并且直接落在 D6「集成面」的判据上------一个 MCP 工具是否把底层系统已提供的诊断信息完整透传给调用方，是集成质量的可观测指标。
还需澄清一点，且方向上对 GitNexus 有利：空集的不可区分性并非 Cypher 独有。 模板式接口同样存在------向 codegraph_callers(symbol) 传入一个拼错的符号名，返回的一样是空集，agent 一样无法区分「该函数确无调用者」与「符号名写错了」；Graphify 的 get_neighbors(label) 同理。差异在错误面的大小而非有无 ：模板接口的错误面基本是一个参数（符号名），Cypher 的错误面则是整个语言（标签、关系方向、变长区间、属性名的多维组合）。故二者风险量级不同，性质相同------把它写成「GitNexus 独有的坑」并不公允。
而且它并非无解 。已知的缓解手段至少有三条：其一，查询前 schema 自省 ------先取回图的标签与关系类型清单再生成语句，本节前引研究已证 schema 注入使组件匹配准确率提升 23.6 个百分点，正是这条路径的现成实证；其二，空集回退探针 ------返回 0 行时自动追发一条存在性验证查询（确认标签/关系类型/符号名是否存在于 schema），把「空」拆解为「查错了」与「真没有」两种可区分状态；其三，透传数据库 notification ，即把 {markdown, row_count} 扩展为 {markdown, row_count, notifications}。本报告核实：三家在 MCP 面均未实现上述任何一条------Graphify 与 CodeGraph 的工具输出中同样不含「本次查询是否命中了已知 schema」的任何元信息。
因此论断 2 的最终形态不是对某一家的指控，而是一条当前一代 CKG 工具共同的设计留白 ------它与 4.3 将指出的 listChanged 留白同构：协议与底层系统都已经提供了能力位，三家实现都没有用上。本报告判断：这是「以 agent 而非人类为一等调用方」这一新范式尚未被工具设计者充分内化的表现。其危害不在于查询失败，而在于失败被伪装成了成功------人类用户看到空表会本能地怀疑自己写错了，agent 不会。
弊二：无界路径的性能与内存爆炸。 Cypher 的无界变长路径 MATCH (a)-[:CALLS*]->(b) 在稠密调用图上可能引发路径数指数级膨胀，导致查询迟迟不返回甚至 OOM。GitNexus 在 cypher 工具文档中给出护栏提示：优先用 pdg_query 而非对原始 [:CDG*]/[:REACHING_DEF*] 做全量扫描 (GitNexus tools.ts)。但关键风险点在于：该护栏只是文档提示，并非语句级强制 ------cypher 工具自身没有服务端行数上限、超时参数或语句改写校验（其 readOnlyHint:true 仅声明「只读意图」，并不解析语句内容）。
可以用一条（示意性、非照搬源码的）Cypher 直观说明双刃剑：
cypher
// 正向：一行即可回答 L5 级聚合「每个模块被多少函数调用」
MATCH (m:Module)<-[:CALLS*1..5]-(f:Function)
RETURN m.name, count(DISTINCT f) AS fanIn
ORDER BY fanIn DESC这条语句在模板式接口中往往需要多个工具多次调用才能近似；但同一语法若被改写为无界 CALLS* 或在超大队列上运行，就可能拖垮服务端。GitNexus 用文档护栏提示规避，但如前所述，护栏非强制。
GitNexus 的只读策略与缺口。 read-only-policy.ts 提供 GITNEXUS_MCP_READ_ONLY 环境变量（0/1）：只读模式下会整体屏蔽 cypher、rename、group_sync、group_list 等不在只读白名单内的工具及 @group 路由 (GitNexus read-only-policy.ts)。然而当只读模式关闭 时，该策略并不对 Cypher 语句内容做写子句（CREATE/MERGE/DELETE/SET）的清洗或拦截------即「原始 Cypher 表面在只读关闭时无语句级写护栏」。这是「暴露查询语言」固有的攻击面，需在使用侧（权限分级、网络隔离、只读模式默认开启）补足。
治理含义：若要将「暴露 Cypher」用于生产，建议默认开启 GITNEXUS_MCP_READ_ONLY（整体屏蔽 cypher 等写/危险工具），仅在受信任的只读分析会话中按需放开；同时应在网络层限制 MCP server 可达范围。CodeGraph 的单入口因不存在「语句」概念，天然规避此类治理负担。
CodeGraph 的单入口动态分发优势。 与之相反，CodeGraph 以单一 codegraph_explore 入口接收自然语言/符号查询，由内部调度多工具、并以内置输出预算管控体量（MAX_OUTPUT_LENGTH=15000，且按文件数自适应 maxOutputChars/maxFiles：<150 文件取 13000/4、<500 取 18000/5、<5000 取 24000/8、≥15000 取 24000/8）(CodeGraph tools.ts)。MAX_INPUT_LENGTH=10000 限制查询/符号长度防止注入过载。其优势是调用方面对一个语义明确、带预算封顶的工具，几乎不存在「写语句」的概念，从而天然规避 Cypher 的幻觉与危险写句风险；代价是表达力被封顶在模板集内（见 4.1）。
Graphify 的中间路线。 Graphify 既未暴露 Cypher（在线态），也未彻底单入口化：它把 NL 驱动的 query_graph 与若干语义明确的细粒度工具（get_neighbors、shortest_path、get_pr_impact 等）并列，外加前述 3 个服务层统计工具。它把「表达力」问题转化为「预置一组够用的遍历原语」------在「灵活」与「安全/可控」之间取中：没有 Cypher 的写风险，也没有 CodeGraph 那样极致的上下文经济性。
把三种定位放在同一坐标上：GitNexus 是「开放查询面 + 显式护栏」的放权型；CodeGraph 是「收口单入口 + 内置预算」的管控型；Graphify 是「NL 驱动遍历 + PR 锚定」的折中型。三者对「agent 应有多大查询自主权」给出了不同答案，而这正是「暴露查询语言」这一设计决策在实践中的连续谱------没有唯一正确值，只有与部署场景的匹配度。
Cypher 独家暴露的战略意义（D5 分水岭）。 GitNexus 是三家里唯一暴露通用图查询语言 的------这意味着它的查询表达力上界不由厂商预设的 API 决定，而由 Cypher 语言本身决定：用户可以问出开发者从未设想过的问题，例如「找出所有被超过 5 个上游模块依赖、却没有任何测试覆盖的枚举类」。相反，Graphify 与 CodeGraph 都是固定 API，「能问什么」完全由厂商圈定，任何超出模板的意图都无从表达。这一差异在三类场景下是决定性的：① 探索性分析 ------分析师拿到陌生代码库想随手问几嘴；② 一次性审计查询 ------合规/安全人员需要临时构造的精确模式，不值得厂商为其造专用工具；③ 研究用途------需要可复现、可参数化的批量查询。代价同样明确：Cypher 有学习曲线，非专家难以写对；LLM 生成 Cypher 存在注入风险（见 4.2 弊一）；最危险的是性能不可控------用户能写出拖垮数据库的查询（如 4.2 弊二的无界路径），而厂商固定 API 因模板受限天然规避了这类风险。表达力上限与风险下限，在这里是同一枚硬币的两面。
综上，是否暴露查询语言，本质是在「能力上限」与「可控性下限」之间划拨预算：GitNexus 把预算拨向能力（高上限 + 需治理），CodeGraph 把预算拨向可控（低上限 + 零治理负担），Graphify 居中。任何选型都不可能同时最大化两者，这正是「双刃剑」题中之义。
4.3 MCP 集成粒度哲学（10/17/1）：细粒度 API vs 单入口分发
按本章开篇声明的统一计数规则（源码定义数 / 默认 tools/list 可见数），三者为 Graphify 10 / 10（README 对外列 7）、GitNexus 17 / 17、CodeGraph 8 / 1 （见共享事实库 §5，及本章 4.1 对三家源码的一手核实）。用于粒度对比的是「默认可见数」这一列，即 10 / 17 / 1。这一悬殊折射出三种截然不同的集成粒度哲学，而非简单的「工具多与少」。
需要立刻补充一点，否则读者会把 CodeGraph 的「1」与 Graphify 的「10」当成对称的两个数：二者性质并不相同。 CodeGraph 的另外 7 个工具实现完整、随时可开 ，只是被默认配置挡在 tools/list 之外；Graphify 的 10 个则是全部注册、无条件可见 。因此在讨论上下文成本 时，CodeGraph 记 1 是准确的（默认部署下它确实只占 1 个工具的 token 预算）；但在讨论能力覆盖时，CodeGraph 应记 8。本章在这两处分别使用对应口径，并在每处标明用的是哪一个。
细粒度（Graphify 10、GitNexus 17）：意图显式、可组合、但占用上下文。 GitNexus 的 17 个工具分「每仓 15 + 组级 2」（group_list、group_sync），后者是其独有的多仓/仓库组 能力------可通过契约注册表（Contract Registry）跨仓路由，这是另两者不具备的协作面 (GitNexus tools.ts)。细粒度使每个工具语义窄、参数少、误用率低，且便于权限分层（如 rename 标 DESTRUCTIVE、dry_run 默认 true；group_sync 标 DESTRUCTIVE；query/context/impact 支持 maxTokens 预算；仓库级工具注入 branch 参数）。
单入口（CodeGraph 1）：上下文极省、选择错误率最低、但黑箱。 仅 codegraph_explore 一个工具意味着大模型在 tools/list 中只需在「用/不用」间二选一，几乎不存在「选错工具」的可能。
组级工具：三者中唯一的跨仓协作面
在 17 个工具中，group_list 与 group_sync 这 2 个组级（group-scoped）工具 值得单独论证，因为它们是三家里唯一的多仓库能力，也是 GitNexus 在用户给定的六轮对决中拿下「多仓库支持」一轮的技术依据。源码层面可核实三点：其一，二者不注入 branch 参数 ------仓库级工具在运行时被统一注入可选 branch 以锚定固定分支索引，而组级工具因不指向单一仓库故无此参数（此处需作一处诚实的口径说明：17 − 2 = 15 个仓库级工具，但本报告未能从源码逐一确认这 15 个是否全部 被注入 branch------list_repos 一类不针对具体仓库的工具很可能同样不需要，因此本报告不断言 「组级 2 个是仅有的不注入 branch 的工具」，确切数目记为未核实 ）；其二，group_sync（name 必填，可选 skipEmbeddings／exactOnly）被标注为 DESTRUCTIVE_TOOL_ANNOTATIONS，因为每次调用都会写入 contracts.json------即契约注册表（Contract Registry）是一份需要显式同步的持久化产物 ，而非查询时即时计算；其三，仓库级工具通过 repo 参数传入以 @ 开头的值（如 @my-group）即可切换到组路由模式，这是跨仓查询的实际入口 (GitNexus tools.ts)。
跨仓能力的价值场景高度集中，但在这些场景里几乎不可替代。第一类是微服务架构的跨服务影响面分析 ：服务 A 修改了一个 REST 契约，需要知道服务 B、C、D 中哪些调用方会被打破。单仓工具在此彻底失灵------因为调用关系跨越了仓库边界，任何单仓图都只能看见半条边。GitNexus 的 impact 工具为此提供了 crossDepth 参数（默认 1、上限 32）与 subgroup 参数，专门刻画「跨仓传播几层」。第二类是共享库的升级评估 ：内部 SDK 发版前，需要枚举全部下游仓库的受影响面。第三类是 monorepo 拆分或服务合并的重构决策，需要同时读取多个仓库的结构。
反方视角同样成立，且约束颇为现实。其一，跨仓分析的准确性受制于契约识别的准确性 ------如果服务间通过消息队列、gRPC 反射或动态路由通信，静态图很可能连不上这条边，此时 crossDepth 再大也无济于事。其二，contracts.json 需要 group_sync 显式维护，这引入了新的陈旧化（staleness）风险 ：单仓索引过期尚有 lastCommit 与 HEAD 比对可提示，而组级契约是否与各成员仓当前状态一致，缺乏同等的自动校验机制（本报告未在源码中找到组级 staleness 检查，记为未公开 ）。其三，也是最关键的------trace 工具的 crossDepth 上限被硬编码为 1 ，即跨仓路径追踪只支持一跳 。这意味着「服务 A → 服务 B → 服务 C」的两跳跨服务调用链无法在单次 trace 中完整追出。本报告判断：GitNexus 的多仓能力在「一跳影响面」上是真实且独有的，但在「多跳跨服务链路追踪」上仍有明确的能力天花板，选型时不应把它想象成完整的分布式调用链分析器。
最后需要提示一处与许可证的交互约束：跨仓/微服务分析本质上是企业级场景 ，而 GitNexus 采用 PolyForm Noncommercial 1.0.0 许可，商业使用需另行授权（详见第五章）。这构成一个结构性张力------这项能力最有价值的使用者，恰恰是最不被开源许可覆盖的那一类使用者。
粒度与「工具疲劳 / 上下文膨胀」的权衡。 依 MCP 规范，每个工具向模型呈现的定义由 name、description、inputSchema（JSON Schema）三部分构成，客户端通过 tools/list 取得后须置入模型上下文，模型才可能选中它 (MCP Specification · Tools)。这就带来一条硬性的定量关系：工具定义的上下文占用与工具数量成正比，且这笔开销在每一轮对话都要重复支付 。Anthropic 公布的实测口径给出了量级参照：GitHub MCP 的 35 个工具约 26K token、Slack 的 11 个工具约 21K token、Jira 单家即约 17K token；一个五服务器、58 工具的常见配置，在用户说第一句话之前就已消耗约 55K token ，而其内部观测到的极端案例是工具定义吃掉 134K token (Introducing advanced tool use on the Claude Developer Platform)。据此估算，单个工具的平均成本约在 700--2000 token 区间，比常被引用的「200--500 token」经验值高出一个档次------因为真实工具的 inputSchema 往往有十余个参数与冗长的描述文本。
比 token 更严重的是准确率。Anthropic 明确指出「最常见的失败是选错工具与填错参数，尤其当工具名相近时」，并公布了启用 Tool Search Tool（defer_loading，即惰性加载）前后的对照：Opus 4 从 49% 提升至 74% ，Opus 4.5 从 79.5% 提升至 88.1% ，同时 token 占用下降约 85% （上下文消耗由约 77K 降至约 8.7K）(Anthropic)。第三方对多项基准的汇编则显示更陡峭的崩塌曲线：BFCL 日程排程任务从 4 个工具增至 51 个时，正确率由 43% 跌至 2% ；RAG-MCP 压力测试中，把全部工具塞进提示的基线准确率仅 13.62% ，改用检索式加载后升至 43.13%（该数字可回溯至一手论文 RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation, arXiv:2505.03275，其「10 个 → 100+ 个」的区间刻画则来自下述汇编）；该汇编同时指出，在 741 个工具的测试中，位于列表中段（40--60% 位置）的工具命中率仅 22--52%，呈典型的「lost in the middle」长上下文位置偏误（工程汇编数据，非 peer-reviewed，The Collapse Curve of Tool Selection）。
把这条曲线套到 10/17/1 上，需要格外小心------这里正是本章最容易出错的地方，故把推理过程完整摊开。
第一步：厘清现有证据的边界。 上述可核实的观测点只有三个量级------4 → 51 （BFCL，43% → 2%）、10 → 100+ （RAG-MCP，基线 13.62%）、以及 741 个工具时的中段位置偏误。在 10 与 51 之间，公开数据没有任何观测点。 因此「崩塌曲线的拐点落在 20--30 个工具附近」这一常被引用的说法，本报告回查所引来源后未能找到依据 ：该汇编原文并未给出任何拐点数字，它给出的是一棵工程决策树（「工具 < 约 10 且语义清晰 → 无需检索」「工具定义 > 10k token 或 10--200+ 个 → 上 defer loading + 检索」），这是部署建议 ，不是准确率崩塌的观测点 。本报告因此不采用「20--30 拐点」这一表述，并提请读者注意：此类具体数字在二手转述中极易被当作实测结论流传，本报告此前的草稿亦一度如此。
第二步：正面处理一个反例，否则「平坦区」的说法站不住。 BFCL 那条曲线在只有 4 个工具 时正确率就已经是 43% 。43% 显然不是什么「平坦区高位」。对此的正确解读是：该曲线度量的是相对衰减，而非绝对水平 ------43% 是这项日程排程任务本身的难度基线（一个与工具数无关的常数项），曲线真正说明的是「再加 47 个工具会让它继续掉 41 个百分点」。把 43% 读成「4 个工具时的选择准确率上限」是误读。但反过来同样成立、且必须承认：我们也无法用这条曲线反推出「17 个工具时准确率仍然很高」，因为它根本没有测量绝对水平。任何声称「17 落在平坦区」的表述，都超出了证据能支撑的范围。
第三步：改用一个更保守、但结论更硬的版本。 综上，本章的论断修正为：三者的工具数（17 / 10 / 1）均远低于已被观测到严重劣化的量级（100+ 乃至 741），因此「17 个工具会让 agent 选晕」这一直觉批评缺乏证据支持。 请注意这个版本的好处------它不依赖任何未被观测到的拐点，也不需要假设 17 落在什么「平坦区」，只依赖「已观测到劣化的量级远高于 17」这一条可核实事实。结论不变，说服力反而更强。
第四步：诚实记下反向的一面。 Anthropic 官方给出的启用 Tool Search 的推荐门槛是「10 个以上工具，或工具定义超过 10k token，或挂载多个 MCP 服务器 」(Claude Docs --- Tool search tool)。按此门槛，GitNexus（17）与 Graphify（10）都已落在「建议考虑惰性加载」的区间内 。但必须把话说清楚：这是一条关于 token 经济性 的工程建议，不是 关于选择准确率崩塌的实测判定，二者不可混为一谈------否则就会把「该考虑优化上下文了」偷换成「模型已经选不准了」。
第五步：回到真正可量化的成本------上下文占用。 按前述每工具 700--2000 token 估算，17 个工具约需 12K--34K token，10 个约 7K--20K ，1 个约 0.7K--2K 。在 200K 上下文窗口下，17 与 1 的差距约占窗口的 6%--16%，可观但不致命；然而若用户同时挂载了另外三四个 MCP 服务器，总量就会迅速逼近已被观测到劣化的量级。因此本报告判断：CodeGraph 单入口的收益主要来自 token 经济性与 KV 缓存稳定性，而非「避免选错工具」 ------后者是它自己讲的故事，在 17 个工具的量级上缺乏实证支撑。这与它自报的「89% 更少工具调用、60% 更便宜、69% 更少 token」在方向上自洽（厂商自报，未经独立验证），但因果链条应被修正：省的是 token，不是错误率。
一种本可调和二者的方案是「渐进式披露」（progressive disclosure）：默认只暴露少量高频工具，tools/list 初始轻量，待 agent 显式需要更深能力时再惰性加载------这正是 Anthropic Tool Search Tool 与 Agent Skills 共同采用的三层结构（元数据约 50 token、完整说明约 500 token、参考文档 2000+ token 且仅按需加载）。MCP 规范其实已为动态工具集预留了协议位：服务器可声明 listChanged 能力，并在工具列表变化时发出 notifications/tools/list_changed 通知 (MCP Specification · Tools)。然而三家当前实现均未采用该机制：GitNexus 全量静态暴露 17 个、CodeGraph 以 DEFAULT_MCP_TOOLS 硬编码默认 1 个（其余需用户手动配环境变量白名单）、Graphify 固定 10 个（README 仅列 7 个）。换言之，三家的粒度选择都是「静态给定」而非「动态协商」，都没有用上协议已经提供的能力。这是本章识别出的一处共同的、可被下一代实现改进的设计留白------尤其对 CodeGraph 而言，它完全可以把隐藏的 7 个工具做成「按需披露」而非「手动白名单」，从而在不牺牲 token 经济性的前提下恢复可发现性。
反方视角：细粒度并非必然劣势。 反对「单入口最优」的观点认为，当任务需要「先用 impact 再 rename 再 trace」的显式编排时，细粒度工具让模型能逐步推理并中途校验；单入口则将编排责任内化于不可见的实现，难以干预或回滚。GitNexus 用工具注解（readOnlyHint/destructiveHint/idempotentHint）与 maxTokens 预算，在「细粒度」与「可控性」之间做了工程补偿。因此粒度哲学没有绝对优劣，取决于「agent 自主编排」与「上下文经济性」哪侧权重更高------高自主编排偏好细粒度，高上下文预算约束偏好单入口。
落到具体选型：若 agent 工作流以「单步问答、低延迟、上下文受限」（如边缘/长上下文敏感场景）为主，CodeGraph 默认暴露的 1 个工具最稳；若以「多步编排、跨仓分析、需要罕见查询」为主，GitNexus 的 17 工具（含 2 个组级）覆盖最全；Graphify 的 10 工具则适合「PR 评审 + 图遍历」的常规研发辅助。
值得单独说明工具注解（tool annotations）的判据价值：MCP 规范允许工具声明 readOnlyHint/destructiveHint/idempotentHint，供宿主决定「是否需用户确认」「是否可自动重试」。GitNexus 对 rename/group_sync 标 DESTRUCTIVE、对 cypher 标只读，是其细粒度治理的抓手；CodeGraph 对所有工具标 readOnlyHint:true，与其「无写操作」定位一致。注解的存在本身不保证安全（如 4.2 所述，cypher 的只读仅是意图声明），但它是 D6「集成可控性」子判据的可观测信号。
4.3.1 三种集成哲学的深层分歧：框架与模型依赖
上一节从「上下文预算」角度对比了粒度，但 10/17/1 的真正分歧在于三者对「agent 应把复杂度放在哪」给出了不同答案，而这种答案在不同 Agent 框架与不同模型能力下会产生截然不同的表现。
CodeGraph 的极简派（1 个工具 codegraph_explore 动态分发）。 它把全部复杂度藏在单一入口之后，赌的是「LLM 更擅长填参数而非选工具」。这一赌注在「工具选择是主要错误来源」时成立：单一工具使选择错误率趋零，agent 永远不必在 query 与 context 间犹豫。但其代价同样结构性：为承载多类查询，codegraph_explore 的入参 schema 必然膨胀（在 query/maxFiles/projectPath 之外还需内部消歧），一旦返回不符预期，错误定位极困难------调用方看不到「我本该用哪个更专工具」，只能反复调同一个黑箱；更微妙的是，LLM 失去了从工具名获得的能力提示（tool-name-as-hint），explore 这个名字几乎不透露它既能做影响面分析也能做架构概览。
GitNexus 的富工具派（17 个）。 list_repos/query/context/impact/trace/detect_changes/check/rename/cypher/route_map/tool_map/shape_check/api_impact/explain/pdg_query/group_list/group_sync 每个语义明确、各司其职，理论上最贴合「显式编排」。但 17 个工具描述本身就会吃掉可观的上下文预算（见 4.3 的 token 估算），且存在真实语义重叠：query（混合检索）与 cypher（原生图查询）在「我想搜点什么」时易混淆；impact（一般影响）与 api_impact（API 契约影响）的边界需要调用方理解二者之别。这种重叠可能制造选择困难。但须与 4.3 的结论对齐：问题的根源是语义边界不清，而非工具数量本身 ------公开证据支持「功能重叠会干扰选择」，却不支持「17 这个数量级会导致崩塌」。因此对 GitNexus 粒度的合理批评应落在「query 与 cypher、impact 与 api_impact 的边界需要调用方自行理解」上，而不是落在「工具太多」上。
Graphify 的中庸派（实定义 10 个，README 公开 7 个）。 query_graph/get_node/get_neighbors/shortest_path/list_prs/get_pr_impact/triage_prs 这 7 个为 README 公开项；serve.py（v8）另实定义 get_community（取 Leiden 社区）、god_nodes（度中心性排序，直接识别超级枢纽）、graph_stats（图级统计：节点/边/社区计数与置信度分布）3 个预计算图分析工具。值得点明：Graphify 把一部分高价值图算法的结果预先算好端出来，而不是让调用方自己用查询语言现算------这与 GitNexus「给你 Cypher 自己写」的哲学形成鲜明对照，恰好强化了本章「三种集成哲学」的论点。这 10 个工具中，有 3 个（list_prs/get_pr_impact/triage_prs）直接绑定 PR ------这暴露了 Graphify 的真实定位更偏「代码审查辅助」而非通用代码理解。中庸的价值在于：10 个工具的上下文占用（按前述估算约 7K--20K token）仍属可控，且 PR 相关工具构成清晰的能力簇，使「评审前预检」这类主场景几乎零学习成本；其代价是通用探索能力不足，一旦问题超出 PR 与图遍历，用户只能退回 query_graph 的自然语言赌一把。另需指出一处由 README 口径造成的真实用户成本 ：那 3 个服务层工具虽已注册进 tools/list、agent 实际可见，却未被写入 README------这意味着人类用户在读文档选型时会低估 Graphify 的能力（尤其是它已实装的固定视图 L6），而 agent 却能看见并调用它们。文档口径落后于实现口径，本身是 D10（生态可持续性）项下值得记录的一处观察。
三种哲学没有优劣，但在不同 Agent 框架与不同模型能力下表现截然不同 ：在「工具自动路由 + 强模型」框架下，GitNexus 的 17 工具能被充分利用，富工具派占优；在「极简 prompt + 弱模型 / 长上下文敏感」框架下，CodeGraph 的单入口反而最稳，因为弱模型在 17 个语义有重叠的工具里更容易选错（注意此处的限定：这是关于弱模型 + 语义重叠的条件性判断，与 4.3 已驳斥的「17 个工具本身就会导致崩塌」不是一回事）；Graphify 的 10 工具则在多数中等能力模型上取得最稳的性价比。这解释了为何同一工具在不同评测里名次浮动------集成粒度本身是模型能力的放大器，而非独立变量。
4.4 推理能力对比：从 CKG-EVAL D5 独立推导的九维评估框架
「推理」区别于「查询」之处，在于它跨越多个图结构、组合约束并产出新结论（而非仅取回既有节点/边）。
评估框架的来源必须先交代清楚。 若直接把某一家产品的功能清单当作横向对比的行标题，则「比什么」这件事本身就已由该产品决定了胜负------这是评测方法论上的框架偏袒（framing bias） ，比措辞偏袒更隐蔽，也更难被读者察觉，因为矩阵是全章视觉说服力最强的构件。本节因此不采用任何一家的功能表，而是从 CKG-EVAL 的 D5（查询表达力） 判据出发独立推导评估维度。D5 关心的核心问题是「调用方能从这张图里问出什么、以及问出来的东西能不能用」，把它展开为接口层可观测的问题，得到三组共九个维度：
第一组·沿边推理（D5 核心，对应 L2--L3 表达力）。 图之所以是图，首先在于可沿边传播，由此得到三个维度：① 影响分析 （给定节点，求其可达影响集）、② 路径追踪 （给定两点，求连接它们的路径）、③ 数据流 / 程序依赖（沿「值如何流动」而非「谁调用谁」这一组语义不同的边推理）。
第二组·跨图与聚合推理（对应 L4--L6 表达力）。 超出单条边的组合与归约能力：④ 架构视图 （对全图做聚合、社区发现或中心性计算，属 L5--L6）、⑤ 变更检测 （在两个图版本之间做差分推理，是九维中唯一引入时间维度的）、⑥ 重构/重命名（唯一「推理即写操作」的类别，其输出不是报告而是对源码的改动）。
第三组·推理结果的可用性（D5 的隐含判据，与 D6 交界）。 同样一条结论，调用方能否安全地用它：⑦ 结论可解释性 / 边溯源 （推理链上的边是确定抽取还是启发推测，调用方能否看见）、⑧ 输出预算与上下文经济性 （推理结果能否在有限上下文内被完整消费）、⑨ 工程单元锚定（推理能否直接挂到 PR / commit 这类真实工程对象上，而非只停留在符号层）。
前六维回答「能推出什么」，后三维回答「推出来的东西能不能用」。必须明说的是：维度 ⑦⑧⑨ 是本报告为纠正框架偏袒而补入的。 若只取前六维，矩阵会退化为「谁的专用工具多谁赢」------而那六个维度恰好高度重合于功能面最宽者的能力轮廓，其中变更检测、重构、数据流三类更是几乎只有一家有具名工具。补齐九维之后，矩阵才呈现出三家各有胜负的真实图景。
| # | 推理维度（源自 D5 判据） | Graphify | GitNexus | CodeGraph |
|---|---|---|---|---|
| ① | 影响分析（L3） | get_pr_impact/triage_prs（PR 级锚定） |
impact（direction 上/下游必填；maxDepth 默认 3、上限 32；timeoutMs 默认 30s、上限 3600s；limit 默认 100、上限 1e4） |
codegraph_impact（白名单短名 impact；depth 默认 2；默认隐藏，须白名单开放） |
| ② | 路径追踪（L2） | shortest_path（返回单条路径） |
trace（maxDepth 默认 10、上限 30；crossDepth 硬编码上限 1） |
codegraph_explore 内部可达，无独立可调入口 |
| ③ | 数据流 / 程序依赖（PDG） | 未公开 | pdg_query（须 --pdg，TS/JS 优先） |
未公开（调用图隐含） |
| ④ | 架构视图（L5--L6 聚合） | get_community/god_nodes/graph_stats（预计算，固定视图 L6，已实装） |
shape_check/api_impact/route_map/tool_map；另可经 cypher 组合（可组合 L6，部署侧未核实） |
codegraph_explore 概览（模板级，无 L6） |
| ⑤ | 变更检测（版本间差分） | 未公开 | detect_changes、check（语义深度未公开） |
未公开（auto-sync 隐式） |
| ⑥ | 重构/重命名（推理即写） | 未公开 | rename（dry_run 默认 true，DESTRUCTIVE） |
未公开 |
| ⑦ | 结论可解释性 / 边溯源 | 逐边三态标注 EXTRACTED / INFERRED / AMBIGUOUS（三家中唯一） | 未暴露逐边溯源，结论以单一置信呈现 | 未暴露逐边溯源 |
| ⑧ | 输出预算与上下文经济性 | token_budget（query_graph，默认 2000） |
maxTokens（query/context/impact 支持） |
按仓库规模自适应 的 maxOutputChars/maxFiles，另有 MAX_OUTPUT_LENGTH=15000 硬顶（三家中最完备） |
| ⑨ | 工程单元锚定（PR/commit） | PR 为一等公民 （list_prs/get_pr_impact/triage_prs） |
explain + prompt detect_impact（间接） |
未公开 |
横向看，九维矩阵给出的图景比「谁的工具多」复杂得多。在 ①--⑥（能推出什么）上，GitNexus 明显领先 ：它是唯一同时覆盖数据流、变更检测、重构三类的工具，推理原语最完整，这与它开放 Cypher、功能面最宽是一致的。但在 ⑦--⑨（推出来的能不能用）上，格局反转：维度 ⑦ 只有 Graphify 得分，且是压倒性的（详见下文「推理结论的可信度上界」）；维度 ⑧ 由 CodeGraph 拿下，它是唯一按仓库规模自适应调节输出预算的实现；维度 ⑨ 同样属于 Graphify。
换言之，GitNexus 赢在推理的广度，Graphify 赢在推理结论的可信度与工程落地，CodeGraph 赢在推理结果的可消费性。 这三者不是同一把尺子上的高低，而是三个不同的取舍面------而这正是补入 ⑦⑧⑨ 三维之后才能看见的东西。此外还有两处共同空白值得记下：维度 ⑤（变更检测）是三者在 MCP 面均未提供完整推理的领域，维度 ③ 的跨程序（类 SDG）数据流则连 GitNexus 也未覆盖。
影响分析。 GitNexus 的 impact 是三者中最显式可参数化的：强制指定 direction（upstream/downstream），并以 maxDepth（≤32）与 timeoutMs（≤3600s）双重封顶，防止无界闭包爆炸 (GitNexus tools.ts)。Graphify 的 get_pr_impact 把影响分析绑定到 PR 这一工程单元（输入 pr_number），更贴合「评审前预检」场景；triage_prs 进一步用 AI 给评审队列排序。CodeGraph 的 codegraph_impact（白名单短名 impact）功能存在但默认隐藏，须经 CODEGRAPH_MCP_TOOLS 白名单开放。三者的影响分析按 4.1 判据均属 L3（返回受影响节点集合）。
路径追踪。 GitNexus trace 以 maxDepth（≤30）与 crossDepth（≤1，跨调用边界深度）约束，适合「沿调用链追到哪」的问答；Graphify shortest_path 提供最短路径（L2），语义更窄但确定性更强；CodeGraph 经 explore 内部可达路径，但非独立可调参数。
数据流/程序依赖图（PDG）。 仅 GitNexus 显式提供 pdg_query（控制流 controls 与数据流 flows 两种模式），且以目标锚定、不做全仓枚举的方式规避开销------这是其相较另两者的独有能力（GitNexus tools.ts)。但其 PDG 以 TS/JS 为主，跨程序（类 SDG）数据流被推迟（未公开是否支持）。
重构/重命名。 GitNexus rename 标注 DESTRUCTIVE 且 dry_run 默认 true，体现「推理后操作」的谨慎默认。值得注意，重构/重命名是少数「推理即写操作」的任务：其输出不是一份报告，而是对源码的改动。因此 dry_run 默认 true 这一设计尤为关键------它让「先预览影响、再决定是否落地」成为默认流程，降低了误改风险。Graphify 与 CodeGraph 在 MCP 面未暴露此类写操作，等于把「推理→改写」的闭环留在工具之外，由用户在编辑器侧完成，这是它们在「推理完整性」上的明显留白。
变更检测。 这是唯一在三者 MCP 面均「未公开完整推理」的任务：GitNexus 有 detect_changes/check 工具但语义深度未公开；Graphify 与 CodeGraph 未暴露独立变更检测入口（CodeGraph 的 auto-sync 隐含增量感知，但能否在 MCP 面作为「推理」显式调用未公开）。变更检测本可由「增量图 diff + 影响传播」组合实现，属 L3+ 推理，其缺失使三者都难以在 MCP 面直接回答「这次提交相对上次改了哪些关键依赖」------这是推理能力矩阵上共同的空白。
推理结论的可信度上界。 三家都宣称支持「影响面分析」（impact analysis），但其结论可信度存在一个常被忽视的硬上界：基于图的可达性推理，其结论可信度上界等于图中边的可信度下界 ------只要推理链上有一条错误的边，整条结论就被污染。这正是第三章边溯源三态（EXTRACTED 确定 / INFERRED 启发 / AMBIGUOUS 推测）在本章的承接点：当 impact 或 trace 的闭包跨越一条 AMBIGUOUS 推测边时，输出应被标为「低置信」，而非与确定边一视同仁。换言之，推理能力的真实边界不在「能不能跑通」，而在「图中边够不够干净」------这是第 6 章场景验证必须正视的前提，也是本章对全书最大的方法论贡献：任何影响面结论都必须附带边可信度加权，否则在弱解析语言 / 跨文件场景下会系统性高估准确性。
顺带指出一个被低估的差异化事实：在三者中，只有 Graphify 显式给边打上 EXTRACTED（源码显式）/ INFERRED（推导）/ AMBIGUOUS（推测）三态溯源 （边溯源三态概念承接自第 3 章，而「仅 Graphify 实现逐边标注」由共享事实库 §2 核实）。这意味着「推理结论可信度上界 = 边可信度下界」这一论断，只有 Graphify 能让调用方在输出中真正看见------agent 可在遍历到 AMBIGUOUS 边时主动降级置信。GitNexus 与 CodeGraph 的 MCP 输出不暴露逐边溯源，其影响面结论以「单一置信」呈现，等于把可信度下界藏进了黑箱。因此同一套推理原语，可解释性在三者间并不对等：这正是第 6 章做场景验证时，评判「影响面结论是否可信」必须分别对待三家的关键原因。
架构视图。 Graphify 的 get_community/god_nodes（serve.py 增余项）以预计算方式输出社区结构与枢纽节点，属「开箱即用」的 L6 级架构概览；GitNexus 则以 shape_check/api_impact/route_map/tool_map 等细粒度工具提供模块化与 API 影响视图。
PR 工作流。 Graphify 把 PR 作为一等公民（list_prs/get_pr_impact/triage_prs），推理直接服务于评审；GitNexus 以 explain 与 prompt detect_impact 衔接；CodeGraph 未公开 PR 级推理入口。
4.5 检索范式之争：确定性图遍历 vs 向量混合 vs 词法全文
CKG 的「取数」底层走哪条路，直接决定查询的确定性与语义召回边界。三者呈三态分立，恰好覆盖检索范式光谱的三个锚点。
Graphify：纯确定性图遍历，无向量索引。 其定位明确------「不是向量索引，而是你真正遍历的图」（README 原意）。所有检索基于对属性图的符号级遍历；语义关联（如文档 wikilink、跨语言调用）靠抽取阶段建立的 references/calls 等显式边表达。优势是结果确定、可解释、无嵌入漂移、零外部嵌入服务依赖；劣势是纯靠图边无法召回「语义相近但未显式相连」的节点，对「模糊自然语言提问」的容错最弱。
GitNexus：图 + 向量混合（有 50k 节点上限）。 其底层 LadybugDB（「formerly KuzuDB」，@ladybugdb/core ^0.18.3）具向量支持（见共享事实库 §3.6）；混合检索（BM25 + semantic + RRF）走 query 工具，而非声明式 Cypher。但需注意资源约束：嵌入节点安全上限为 50,000 节点（见共享事实库 §3.6）------对超大型仓库，向量层可能触及该上限而需分片或降级。这是「混合范式」的现实代价：语义召回更强，但受嵌入规模与召回不确定性约束。
CodeGraph：词法全文检索（FTS5），无向量。 其存储为 SQLite + FTS5 虚拟表 nodes_fts，默认 tokenizer 为 unicode61（BM25 排序），仅做词法/符号匹配，无语义嵌入 (SQLite FTS5)。这意味着 CodeGraph 的检索是「确定性词法」而非「语义向量」，召回边界严格受限于名称/签名/文档字符串的字面匹配------既不依赖嵌入服务（部署轻、零外部依赖、单守护进程），也放弃了语义近邻召回。
一个必须点破的技术细节：unicode61 分词器不切分驼峰命名。 依 FTS5 官方文档，unicode61 把所有 Unicode 字符二分为「分隔符」与「token 字符」，默认字母（L*）与数字（N*）属后者，空白与标点属前者 (SQLite FTS5)。这条规则的直接后果是：标识符 authenticateUser 会被整体索引为一个 token ，大小写边界不构成切分点。于是查询 User 无法命中 authenticateUser------尽管前缀查询 auth* 可以（因为 * 标记前缀 token，匹配任何以其开头的文档 token）。同理，snake_case 因下划线属标点而会 被切开，camelCase 与 PascalCase 则不会。共享事实库 §4.2 已核实 CodeGraph 的 nodes_fts 建表语句未显式指定 tokenizer ，即落到 unicode61 默认值。
由此可推出一条具体的能力边界：在 camelCase 主导的代码库（TypeScript、Java、Swift、Kotlin 等）中，CodeGraph 的 FTS5 检索对「词中匹配」是失效的 ------用户搜 Token 找不到 refreshTokenHandler，除非改用前缀式或恰好从词首匹配。CodeGraph 用两个机制部分补偿了这一先天限制：其一是 schema 中的 name_segment_vocab（WITHOUT ROWID 表，字段为 segment 与 name），这正是一张标识符分词后的物化词表 ，把 authenticateUser 预先拆为 authenticate／user 等片段（共享事实库 §4.2）；其二是 codegraph_explore 接受自然语言查询并在内部做多路检索与排序，不把 FTS5 的原始语法直接暴露给调用方。本报告判断：name_segment_vocab 的存在，恰恰是对「FTS5 默认分词器不适配代码标识符」这一问题的工程承认------它是一个绕过而非解决 的方案，因为该词表服务于 prompt-hook 的图驱门控，未必等价地反哺 nodes_fts 的匹配质量。从效果上看，单入口设计使 FTS5 的分词短板可在返回结果层面被多路召回补偿------调用方不会直接感知该短板（name_segment_vocab 已在内部补上标识符切分即为一例）。但本报告不就「CodeGraph 是否因此才采用单入口」作因果归因：单入口同样可服务于上下文经济性、KV 缓存稳定性等目标，动机层面无公开依据，故仅陈述效果、不下因果结论。检索范式的优劣高度依赖仓库规模这一外部变量------实务上 GitNexus 的 50k 节点嵌入上限意味着其语义召回在超大型单体仓库（如千万符号级）上可能被迫退化为仅索引子集，「混合」优势收窄；而 Graphify/CodeGraph 的确定性检索不受该规模约束，反在大仓库上更稳。
部署含义：Graphify 的纯图遍历与 CodeGraph 的 FTS5 都不需要嵌入服务，单机即可运行，适合「零外部依赖、可离线」的场景；GitNexus 的向量混合需嵌入管线，带来额外的模型/算力依赖与 50k 节点上限约束。因此检索范式的选择，往往先于功能对比，就被部署约束所决定。范式取舍的判据因此可归纳为：若任务强调确定性、可审计、可重放 （如安全审计、合规追溯、精确符号定位），纯图/词法范式更稳妥；若强调语义召回、自然语言提问的容错（如「找处理认证的模块」这类模糊意图），向量混合更优，但须接受嵌入上限与召回不确定性的代价。三者分别在「纯图 / 图+向量 / 词法」三端落点，构成检索范式光谱的完整对照，也解释了为何不存在「一种范式通吃」的最优解。
检索范式还与查询表达力耦合：纯图/词法范式的确定性，使 L0--L3 的精确查找结果可解释、可复现，契合审计；而向量混合范式的语义召回，更适配 L3 以上的「意图级」查询（用自然语言描述目标而非精确模式）。因此「选哪种检索」与「需要多高的查询表达力」并非独立决策，二者共同定义了工具在「精确 vs 模糊」需求光谱上的位置。
4.6 查询能力小结与 D5/D6 判据
综合 4.1--4.5，三者在「查询与推理」维度呈现清晰的分层画像（本章不做评分，仅给出判据锚点，供终章统一裁决）：
-
D5 查询表达力（Query Expressiveness）： 以 L0--L6 层级为尺。GitNexus（原生 Cypher，可组合 L6------图库侧已核实、部署侧未核实，实际表达力 L5+）处高位；Graphify（固定视图 L6 已实装 + 模板遍历封顶约 L3+）与 CodeGraph（单入口模板约 L3+，无 L6）处中段。三者差异在「L6 以何种形态可达」：Graphify 为预计算固定视图（已实装、不可自定义组合），GitNexus 为可组合 L6（需调用方写 Cypher、部署侧前件未核实），CodeGraph 二者皆无------后者只有 Cypher 暴露方（GitNexus）具备。判据要点：①是否暴露声明式查询语言；②是否支持变长/传递闭包（L3）；③是否支持聚合管道（L5）；④是否可达图算法（L6，含预计算视图是否开放组合）。
-
D6 集成面（Integration Surface）： 以 MCP 工具数、粒度哲学、上下文占用、选择错误率、多仓能力为尺。CodeGraph（1 工具，上下文极省、选择错误率最低）在「集成经济性」占优；GitNexus（17 工具含 2 个组级多仓工具，表达最全但最重）在「集成覆盖度」占优；Graphify（10 工具，居中）取平衡。判据要点：①工具清单可见性（是否默认全开）；②细粒度 vs 单入口；③是否支持多仓/组级路由（
group_*为 GitNexus 独有）；④是否有预算/只读护栏（maxTokens、只读模式、写操作dry_run默认）------该护栏的存在与否，直接决定多租户场景下的集成安全水位，是 D6 不可略过的子判据。
需要重申：D5/D6 是「能力判据」而非「优劣判语」。表达力高不代表「更好」------GitNexus 的 L6 天花板伴随写风险与上下文重；CodeGraph 的 L3+ 封顶伴随最低错误率与最省上下文。终章将在统一权重下，结合 D1--D4、D7--D10 给出综合判断，本章仅锁定「查询与推理」这一维度的可比锚点。
从终章视角看，D5/D6 与 D1--D4（图模型/存储/抽取/增量）、D7--D10（部署/性能/许可/社区）共同构成十维判据。本章已尽量把「查询与推理」维度内部的可比锚点夯实，使终章在加权时不必回到接口细节。需要提醒：本章所有「天花板」判断均基于接口能力，未混入独立性能实测（第七章范畴），以免把「能查」与「查得快」混为一谈。