Graphify（Graphify-Labs/graphify）：把代码库编译成可遍历的知识图谱，查询 token 降 71.5 倍而图构建零 LLM 额度

一、导读

编码智能体的隐性成本不是模型调用，而是「把仓库重新读一遍」。Graphify 的判断是：把代码、文档、PDF、图片一次性编译成一张可遍历的知识图谱，之后查询走图遍历而不是 grep 原始文件——在 52 文件的混合语料上，单次查询 token 从约 123,488 降到约 1,726，降低 71.5 倍，而图构建本身零 LLM 额度（代码走本地 tree-sitter AST）。

它的可核验答卷：LOCOMO（n=300）recall@10 0.497（mem0 0.048、BM25 0.362）；LongMemEval-S（n=50）QA 准确率 76%，与 dense RAG 并列；ERPNext（约 100 万行生产仓库）上给编码智能体挂一个 graphify 工具，关键事实覆盖率从 70.8% 升到 82.0%。当日涨星 +906、总星 130,126（2026-10-21 抓取）。

二、项目速览

项目	内容
仓库	`Graphify-Labs/graphify`（官网 graphify.com，文档 docs.graphify.com）
主语言 / 许可	Python ≥3.10 / Apache-2.0（`NOTICE`：2026 Safi Shamsi 与贡献者；relicense 前的 MIT 部分保留在 `LICENSE-MIT`）
Star / Fork	130,126 / 12,533（GitHub API，2026-10-21 抓取）
当日涨星	+906（Trending daily，2026-10-21 抓取）
首次提交	2026-04-03（仓库创建同日）；最近推送 2026-10-20
最新版本	v0.9.93（2026-10-20）；此前 v0.9.92（10-16）、v0.9.91（10-14）、v0.9.90/89（10-13）、v0.9.88/87（10-12）、v0.9.86（10-11）——10 天 8 个 Release
社区规模	约 332 位贡献者；开放 PR 858、开放 Issue 704（合计与 API 的 open_issues 1,562 一致）
代码形态	119 个文件的 Python 包；`extract.py` 98 KB、`export.py` 37 KB、`skill.md` 47 KB
商业主体	YC S26；Graphify Cloud（app.graphify.com）提供 14 天试用

一句话概括：它不是向量索引，也不是文档问答——它把仓库编译成一张带置信度标签的有向图，让智能体沿边走。

三、为什么是它：问题背景与定位

第一，上下文税是复利式的。 编码助手回答一个架构问题，要 grep、开文件、再 grep；成本是 O(k×ℓ)，k 是相关文件数、ℓ 是平均长度。窗口再大也治不了成本与延迟——把 200 个文件喂进去，绝大多数内容对当前问题无关。

第二，向量检索丢掉的恰恰是代码的结构。 「process_payment 调用 validate_card」这个事实不在嵌入空间里，它在调用图里。两个文件可能因为共享词汇而向量相邻，一条真实的调用边却可能因为命名不匹配而相距很远；多跳问题更糟——RAG 必须先把第一跳捞回来，才谈得上第二跳。Graphify 的立场是：相似度适合模糊的散文检索，结构适合代码。

第三，涨星动因是叙事顺风加零成本试用。 项目创建于 2026-04-03，README 明确把 Andrej Karpathy 的 /raw 文件夹工作流（论文、推文、截图、笔记丢进一个目录）当作问题原型，并给出「71.5 倍」这个可复现的数字（worked/ 目录里放了原始输入与真实输出）。同时它的安装成本近乎为零：uv tool install graphifyy 加一条 graphify install，一次安装适配 20+ 宿主。

第四，它踩在「知识库」这条主线上。 2026 年围绕「RAG 之后用什么」的讨论集中在 LLM Wiki、GraphRAG、知识图谱三条路线上，Graphify 是其中唯一把「代码 AST 免费、文档语义付费」这条成本分界线讲清楚并工程化的项目。

四、【重点】架构原理

4.1 整体架构：一条七段流水线

graph LR
    A["detect()<br/>收集文件"] --> B["extract()<br/>三趟提取"]
    B --> C["build_graph()<br/>NetworkX 图"]
    C --> D["cluster()<br/>Leiden 社区"]
    D --> E["analyze()<br/>god nodes / surprises"]
    E --> F["report()<br/>GRAPH_REPORT.md"]
    F --> G["export()<br/>json / html / obsidian / neo4j"]
    B -.SHA256 缓存.-> H[("graphify-out/cache/")]
    C --> I["serve.py<br/>MCP stdio：7 工具"]
    E --> J["reflect.py<br/>LESSONS.md"]

ARCHITECTURE.md 的原文定义得很克制：每个阶段是各自模块里的一个函数，彼此只通过普通 Python dict 与 NetworkX 图通信，没有共享状态、没有 graphify-out/ 之外的副作用。这条纪律让整条流水线可单测、可重跑、可替换——仓库里每个模块都配一个测试文件，共 20+ 个测试模块。

4.2 分层模块拆解

模块	入口函数	输入 → 输出
`detect.py`	`collect_files(root)`	目录 → 过滤后的 `[Path]`
`extract.py`	`extract(path)`	文件 → `{nodes, edges}`
`build.py`	`build_graph(...)`	提取结果列表 → `nx.Graph`
`cluster.py`	`cluster(G)`	图 → 带 `community` 属性的图
`analyze.py`	`analyze(G)`	图 → god nodes / 意外连接 / 建议问题
`report.py`	`render_report()`	图 + 分析 → Markdown 报告
`export.py`	`export(G, out_dir)`	图 → JSON / HTML / Obsidian / Neo4j
`serve.py`	`start_server()`	图文件 → MCP stdio 服务
`cache.py`	`check_semantic_cache()`	文件 → 命中/未命中切分
`security.py`	`validate_url()` 等	URL/路径/标签 → 校验或抛错

提取输出契约被 validate.py 强制：节点是 {id,label,source_file,source_location}，边是 {source,target,relation,confidence}，schema 不合法就不许进 build_graph()。

4.3 核心机制一：三趟提取与「谁付费」的分界线

Graphify 最关键的设计不是图算法，而是按文件类型分账：

Pass 1｜代码——确定性、免费、不出本机。 tree-sitter 解析出类、函数、import、调用图与行内注释；SQL 文件另有专门处理（表、视图、外键、JOIN）。README v8 称覆盖约 40 种语言，how-it-works 文档写 25 种——两处口径不一致，以你安装版本的 --help 为准。纯代码语料会整趟跳过 Pass 3。
Pass 2｜音视频——本地转录。 faster-whisper 在本机转写，且转写提示词会被你当前图谱的 top god nodes 播种，让转录偏向你的领域词汇。
Pass 3｜文档/PDF/图片——付费语义趟。 由宿主的 Claude 子智能体并行读取，产出 nodes/edges/hyperedges 的 JSON 片段后合并。

这条分界线的意义：代码永远不离开机器，只有文档与图片会发给模型；GRAPHIFY_BACKEND=none 可彻底关掉所有 LLM 后端，得到纯代码图。

4.4 核心机制二：置信度三档与离散评分

每条边都带标签：EXTRACTED（源码里显式存在，置信度恒为 1.0）、INFERRED（解析器推导，带 confidence_score）、AMBIGUOUS（不确定，进报告待人工复核）。INFERRED 不是连续打分，而是离散评分表：0.95 近乎确定（显式跨文件引用且只有一个合理目标）、0.85 强证据、0.75 合理、0.65 弱（仅命名相似）、0.55 推测。

这个设计的价值在智能体侧：它可以信任一条 EXTRACTED 的 import，而对一条 INFERRED 的 call 保持怀疑。官方还给出一次可复现的抽查：对 FastAPI 仓库做纯 AST 提取（2026-10-05），两端都在 fastapi/ 下的 12 条 INFERRED 跨文件边全部正确；同时坦承 tests/ 下的同名辅助函数会产生更嘈杂的 INFERRED 调用边。

4.5 核心机制三：无嵌入的社区发现

社区用 Leiden 算法直接跑在图拓扑上，不用任何嵌入模型：语义相似边（semantically_similar_to）本身已经在图里，所以「图结构就是相似度信号」。cluster.py 里有两个工程细节值得抄：

超大社区二次切分：超过全图节点 25%（且至少 10 个节点）的社区，会在子图上再跑一次 Leiden；切不动就原样返回。
社区 ID 稳定：按规模降序重新编号，保证同一仓库两次运行可复现。

代价也很直白：孤点各自成社区。官方在 52 文件基准里得到 53 个社区，其中只有 17 个是真实社区、36 个是孤点，作者在 review.md 里承认可视化因此嘈杂，并说「未来该加个 --min-community-size」。

4.6 核心机制四：SHA256 缓存与实体去重

增量更新的底座是内容哈希：每个文件按 SHA256 落在 graphify-out/cache/{hash}.json，重跑只处理变更文件。缓存带 schema 版本——v0.9.93 把 AST 缓存 schema 升到 20，意味着升级后第一次构建会全量重提取，这是正确性优先于速度的取舍。

实体去重是一条五段流水线（dedup.py，约 78 KB）：精确归一化 → 香农熵门（丢掉 a、get 这类低熵标签，避免模糊匹配爆炸）→ MinHash/LSH 分桶（num_perm=128、3-gram shingles）→ Jaro-Winkler 校验 → 并查集合并。校验层有三个「反误合并」守卫，都是踩过坑才有的：_is_variant_pair 阻断同词干不同后缀的型号对（M1 vs M1 Pro）；_short_label_blocked 对短标签只允许等长单字符替换（真错别字），阻断靠前缀奖励刷高分的插入/删除对；_numeric_tokens_differ 阻断仅数字段不同的长标签（ADR 0011 §D5 vs ADR 0013 D4）。

还有一个很「生产」的细节：仓库自带 _minhash.py 替代 datasketch，原因是 datasketch 会经 scipy 间接加载 numpy.testing，在企业 Windows 的 EDR 环境下会拉起 cmd.exe 并卡住数分钟。为了不被一个测试期依赖拖死，他们用 Mersenne 素数排列重写了等价 API。

4.7 核心机制五：把「用过的答案」变成可衰减的工作记忆

reflect.py 是一条纯确定性、零 LLM 的反思流水线：graphify save-result 把每次问答的结论（useful / dead_end / corrected）与引用节点写进 graphify-out/memory/*.md；graphify reflect 再聚合出 reflections/LESSONS.md，分四类输出——preferred（被多次 useful 佐证的节点）、tentative（只被佐证一次）、contested（正负信号都有，按净衰减分裁决）、known dead ends（别再重新推导）。

两个参数是它的性格：半衰期 30 天（新近的 dead end 能压过几个月前的 useful）、min_corroboration=2（一次保存不能铸就一条可信教训）。产物落在 reflections/ 而非 wiki/，因为 export wiki 每次都会清空 wiki/*.md——写在会被覆盖的目录里的教训等于没写。

4.8 性能优化手段与设计取舍

进程池并行 AST：ProcessPoolExecutor 绕过 GIL，84 个代码文件上比串行快约 1.66 倍；论文口径给出 3.38 倍（并行度与机器相关，待确认）。
hub 抑制：god_nodes 会排除文件级 hub 节点与 AST 方法桩，避免「度数高但没有架构含义」的节点霸榜；--exclude-hubs 可再压一层工具类超级枢纽。
查询侧硬预算：MCP 的 query_graph 带 depth（1–6）与 token_budget（默认 2000），超预算直接截断并标注——宁可截断也不悄悄塞满上下文。
歧义拒绝而非猜测：graphify query 遇到同名多节点会列出候选并拒绝回答，退出码 3 表示歧义、4 表示无匹配，方便脚本判定。
诚实规则写进 skill：skill.md 末尾有「Honesty Rules」——绝不发明边（不确定就用 AMBIGUOUS）、绝不跳过语料检查警告、必须展示 token 成本、不得用符号隐藏内聚度、超过 5,000 节点不得静默渲染 HTML。

4.9 与其他架构路线的差异

路线	代表	检索方式	相对 Graphify 的取舍
向量 RAG	通用 chunk+embedding	相似度 top-k	散文检索更强；但调用/依赖关系从未被存储，多跳易断
文档图谱 RAG	Microsoft GraphRAG	实体关系图 + 分层社区摘要	全局理解更强；但实体抽取全靠 LLM，构建贵、增量难
记忆系统	mem0 / supermemory	事实抽取 + 向量	面向对话记忆；Graphify 的 LOCOMO 召回更高、构建零额度
代码图谱	Graphify	图遍历（BFS/DFS）	代码免费且本地；弱项是「直接问答」与超大规模可视化

一句话：Graphify 把「谁付费」和「谁负责确定性」这两件事分开了——结构由解析器保证，语义由模型补充，且每条边都留了可追溯的标签。

五、【重点】应用场景

场景一：接手一个十万行级的陌生仓库

业务痛点。 新人入职第一周，架构问题要 grep 十几次；问智能体「认证怎么走到数据库」，它会开一堆文件，最后给你一段没有出处的总结。

做法。 建一次图，之后把「读文件」换成「问图」。

uv tool install graphifyy && graphify install
cd /path/to/legacy-repo
graphify . --code-only          # 纯代码、零 API key、不出本机
graphify explain "APIRouter"
graphify path "FastAPI" "ModelField"
graphify query "what connects auth to the database?"

真实输出形态（官方在 FastAPI 仓库上的示例）：explain 给出节点所在文件与行号、社区编号、度数 47 与 47 条连接（每条带 [EXTRACTED] / [INFERRED]）；path 给出三跳链路 FastAPI --uses--> DefaultPlaceholder <--references-- get_request_handler() --references--> ModelField。

收益与量化指标。 52 文件混合语料上单次查询约 1,726 token 对比朴素全量 123,488 token，降 71.5 倍；纯代码子集降 8.8 倍（约 16,997 → 约 1,929）。分问题看：「micrograd 与 nanoGPT 怎么连」降 126.7 倍，「FlashAttention 怎么省显存」降 100.8 倍，「注意力机制怎么工作」降 43.5 倍。

适用边界。 ①纯字符串查找仍该用 grep——「找这行字在哪」不是图问题。②--code-only 会跳过文档与图片，架构动机类问题会缺上下文。③超大仓库（>20 万文件或 >200 万词）skill 会先要求你缩小到子目录再跑。

场景二：把个人 /raw 研究语料变成可查询资产

业务痛点。 论文、推文截图、白板照片、笔记散在一个文件夹里，几周后再问「当时那篇讲注意力的论文和我的实现有什么关系」，只能重读一遍。

做法。 混合语料直接建图，用 add 增量投喂，用 --watch 或 git hook 保持新鲜。

graphify ./raw --mode deep                 # 更激进的 INFERRED 边
graphify add https://arxiv.org/abs/1706.03762
graphify add <youtube-url>                 # 本地转录后入图（需 [video] extra）
graphify ./raw --watch                     # 代码变更即时重建，文档变更提示重跑
graphify hook install                      # post-commit 自动重建

收益与量化指标。 官方 52 文件基准（3 个 Karpathy 仓库 + 5 篇注意力论文 + 4 张图）产出 285 节点 / 340 边 / 53 社区，其中 163 个节点来自 AST、112 个来自语义提取。跨模态边真的被找出来了：FlashAttention 论文簇桥接到 nanoGPT 与 minGPT 的 CausalSelfAttention；gpt2_124M_loss.png 被读成「val_loss=2.905 at step 399」，gout.svg 被识别为 micrograd 计算图。

适用边界。 ①文档/图片走语义趟会发到你的模型 API，敏感语料请用 --backend ollama 或 GRAPHIFY_BACKEND=none。②语料小于约 6 个文件时收益接近 1 倍——图的价值是结构清晰度，不是压缩。③--mode deep 更贵，且会提高 INFERRED 边比例，需要人工复核。

场景三：团队共享一张图，并用它做 PR 影响面分析

业务痛点。 每个工程师的智能体各自建图、各自过期；评审 PR 时没人说得清「这个改动会波及哪些子系统」。

做法。 把 graphify-out/ 提交进仓库共享，用 affected 做爆炸半径、用 prs 做评审队列。

graphify install --project          # 装进当前仓库（可提交）
graphify affected "RateLimiter"     # 反向遍历 calls/imports/inherits 等关系
graphify prs                        # CI 状态 + 评审状态 + worktree 映射
graphify prs --conflicts            # 共享社区的 PR：合并顺序风险
graphify prs --triage               # 由配置的后端给评审队列排序
graphify export callflow-html       # Mermaid 架构/调用流 HTML

affected.py 里那份关系白名单很值得抄：calls、indirect_call、references、imports、imports_from、dynamic_import、re_exports、inherits、extends、implements、uses、mixes_in、embeds、defines、requires。注释解释了为什么漏掉 dynamic_import 是危险的：动态导入恰恰是代码库用来打破 require 循环的手段，这些边就压在承重模块下面。

收益与量化指标。 ERPNext（约 100 万行）上，给固定编码智能体（Claude Opus 4.8、最多 14 轮）挂一个 graphify 工具，关键事实覆盖率从 70.8% → 82.0%，每次查询约 140K token；而「把整个仓库塞进每一轮」这种反模式大约要 20 倍 token 却拿到更低覆盖。

适用边界。 ①图会随代码漂移，必须配 hook 或 CI 重建；git pull 后要手动跑一次 graphify update .。②.graphifyrc 要显式声明歧义扩展名（language.inc=php、language.tpl=.ts），否则 .inc/.h/.m 会被当成错误语言静默解析——图看着有内容，真正的符号却缺失。③prs --triage 会调用模型，注意额度。

场景四：把图谱接进智能体的上下文经济

业务痛点。 智能体默认行为是 grep + 读文件，一次架构问答吃掉几万 token；而且每次会话都从零开始。

做法。 两条接入路径，按你的客户端选：

# 路径 A：MCP stdio 服务（7 个工具）
uv tool install "graphifyy[mcp]"
graphify . --mcp
# 工具：query_graph / get_node / get_neighbors / get_community /
#       god_nodes / graph_stats / shortest_path

# 路径 B：always-on 指令（Hook 型或指令文件型）
graphify claude install      # 写 CLAUDE.md + PreToolUse hook
graphify codex install       # 写 AGENTS.md
graphify cursor install      # 写 .cursor/rules/

Hook 型平台（Claude Code、Gemini CLI）会在搜索类工具调用前自动提醒先看图；指令文件型平台（Codex、OpenCode、Cursor 等）靠常驻指令达到同样效果。Pi 没有 PreToolUse，官方另提供 graphify pi guard install 原生扩展，行为对齐（含 GRAPHIFY_HOOK_STRICT=1 的每会话一次索引读取拒绝），且该 hook 被限制在 2 秒、256 KiB 入 / 64 KiB 出并失败即放行。

收益与量化指标。 查询侧有硬预算：query_graph 的 depth 默认 3（1–6）、token_budget 默认 2,000，超预算截断并显式标注。第三方在 496K token 代码库上报告 79 倍 token 下降（测量者 Steve Scargall / MemVerge，非官方基准）。

适用边界。 ①别同时装 CLI 指令和 MCP 指令——README 明确说两套指引描述的是不同查询路径，同时塞进 AGENTS.md 会互相冲突，应选定一条主路径。②Hook 是「提醒」不是「强制」，模型仍可能去 grep。③graphify install 会修改你的助手配置文件（含 CLAUDE.md、.cursor/rules/），上生产前先看 diff。

场景五：让「踩过的坑」不再被重新推导

业务痛点。 同一个死胡同，三个工程师各踩一次；智能体每次都重新试一遍已证明行不通的方案。

做法。 把问答结论写回图谱，再用确定性反思聚合成教训清单。

graphify save-result --question "为什么不用 X 方案" --answer "..." \
  --nodes SomeNode OtherNode --outcome dead_end
graphify reflect            # 生成 graphify-out/reflections/LESSONS.md

收益与量化指标。 输出分四类且全部可解释：preferred（被 ≥2 次 useful 佐证）、tentative（仅一次）、contested（正负信号并存，按净衰减分裁决）、known dead ends。两个参数决定性格：半衰期 30 天、min_corroboration=2。整条流水线零 LLM、排序稳定、给定 now 后输出字节级可复现；图在手时还会按社区分组，并丢弃已不存在的节点。

适用边界。 ①它是工作记忆不是事实库：信号来自你标注的 outcome，标错就学错。②产物写在 reflections/，因为 export wiki 每次会清空 wiki/*.md。③不要把 LESSONS.md 当成团队规范——它是「哪些来源值得先看」的排序建议。

六、快速上手

# 1) 安装（Python 3.10+；推荐 uv）
uv tool install graphifyy            # 或 pipx install graphifyy（PyPI 包名是双 y）
graphify install                     # 自动识别宿主并注册 skill

# 2) 建图（在 AI 助手里）
/graphify .                          # 产出 graphify-out/{graph.html, GRAPH_REPORT.md, graph.json}

# 3) 查询
/graphify query "what connects auth to the database?"
graphify path "UserService" "DatabasePool"
graphify explain "RateLimiter"

# 4) 保持新鲜
graphify ./docs --update             # 只重提取变更文件
graphify hook install                # post-commit 自动重建

产出目录固定为 graphify-out/：graph.html 交互图、GRAPH_REPORT.md 洞察报告、graph.json 可持久化图、cache/ SHA256 缓存、可选 wiki/、obsidian/、reflections/。graph.json 里带 graph.schema_version 与 graph.graphify_version，方便集成方检测格式不兼容。

七、横向对比

数字均来自各项目官方口径，获取日期 2026-10-21，口径不同不可直接横比。

维度	Graphify	Microsoft GraphRAG	mem0 / supermemory	向量 RAG（dense）
知识表示	有向图（节点+类型化边）	图谱 + 分层社区摘要	事实抽取 + 向量	文本块向量
检索方式	图遍历（BFS/DFS）	全局社区摘要 / 局部邻域	相似度 + 事实	相似度 top-k
构建成本	代码零 LLM 额度；文档走语义趟	实体抽取全靠 LLM，千页级要数小时	每文档 LLM 摄入（mem0 $3.48、supermemory $15.67）	嵌入成本
LOCOMO recall@10	0.497	未在此表	mem0 0.048、supermemory 0.149	0.439
LOCOMO QA 准确率	45.3%	未在此表	mem0 27.3%、supermemory 49.7%	41.3%
LongMemEval-S QA	76%（并列最佳）	未在此表	mem0 70%	76%
增量更新	SHA256 缓存 + `--update`	需重建提取流程	视实现	需重嵌入
可追溯性	每条边 EXTRACTED/INFERRED/AMBIGUOUS + 评分	社区摘要溯源	事实级	相似度分数（不解释为何匹配）
许可 / 形态	Apache-2.0，本地 CLI + 20+ 宿主 skill	MIT，Python 库	开源/商业混合	组件拼装

一句话选型：要「代码结构 + 跨模态关联 + 增量更新」选 Graphify；要「对整个文档库做全局综述」看 GraphRAG；要「对话记忆的事实召回」看专用记忆系统；要「模糊散文检索」保留向量索引——官方自己在对比文章里也说：图不会、也不打算在嵌入索引的主场上赢过它。

八、局限、风险与社区观察

第一，基准是自建 harness，不是独立评测。 BENCHMARKS.md 明确写「graphify's own harness」，mem0 与 supermemory 是跑在它自己的适配器里；作者也公开了裁判验证（与第二裁判一致率 90.6%、Cohen's kappa 0.81）与公平规则（同一模型 Kimi K2.6、共享本地嵌入 BGE-m3、相同预算、--max-spend 账本），这比多数记忆基准诚实，但仍是厂商自测。第三方分析直接指出：80% 的 token 节省没有找到独立验证，属云产品的厂商声明。

第二，数据集本身不是代码任务。 LOCOMO 与 LongMemEval 是对话记忆基准，衡量的是从长历史里捞事实，而不是「帮智能体修好一个 bug」；唯一带代码味道的 ERPNext 结果 n=6，样本极小。官方也承认 supermemory 在原始 QA 上更高（49.7% vs 45.3%），代价是约 11 倍摄入成本；而 recall 一栏里 supermemory 的 0.149 被标注为嵌入器混淆（它自带 768 维英文嵌入器，无法换用共享的 BGE-m3）。

第三，图会「看起来对」但漏掉真符号。 官方自己在 .graphifyrc 文档里点破：.inc 在 pfSense 是 PHP、在 Delphi 树里是 Pascal，.h 是 C 还是 C++，.m 是 Objective-C 还是 MATLAB——选错语言不会报错，文件会被按错误语法解析，产出少量偶然节点，「图看起来是满的，真正的符号却没了」。这是使用前必须配置的一项。

第四，社区规模带来的治理成本。 约 332 位贡献者、开放 PR 858、开放 Issue 704；10 天 8 个 Release、v0.9.93 一个版本合入 22 个社区 PR。活跃是好事，但任何行为细节都应以你安装的版本为准；缓存 schema 升级（v0.9.93 升到 20）会让升级后首次构建全量重提取。

第五，可视化与孤点噪声。 52 文件基准里 53 个社区有 36 个是单节点孤点。作者在 review.md 里逐条列了「图搞对什么 / 图搞错什么」，包括 94 条 stdlib 导入校验警告、配置文件变成孤立社区、论文结论没有深链到具体实现。这种把失败也写进仓库的做法，本身就是该项目最值得学的部分。

第六，安装与许可的坑。 PyPI 官方包名是 graphifyy（双 y），README 明确警告「其他 graphify* 包与官方无关」——这是典型的仿冒包风险区，务必照抄包名。许可为 Apache-2.0，NOTICE 说明 2026 Safi Shamsi 与贡献者持有版权、relicense 前的 MIT 部分保留在 LICENSE-MIT；开源引擎本地运行、无遥测，但 Graphify Cloud 是另一个产品。数据驻留上有一条需要留意：若用 MOONSHOT_API_KEY（Kimi）做语义趟，请求会路由到中国的 Moonshot 服务器；有驻留要求时应用 --backend ollama 或 GRAPHIFY_BACKEND=none。

九、小结与行动建议

Graphify 最值得借鉴的不是图算法，而是三条工程纪律：按文件类型分账（代码用确定性解析器、免费且不出本机；语义才付费）、每条边都必须解释自己（EXTRACTED / INFERRED / AMBIGUOUS + 离散评分）、把「谁付费」和「谁保证确定性」分开。

五条建议：

先用 --code-only 跑一次，零成本验证价值。 纯代码不需要任何 API key，也确认了「代码不出本机」这条边界。
先配 .graphifyrc 再建图。 把 .inc/.h/.m/.tpl 的语义显式声明出来，否则图会静默漏符号——这是最容易被忽略、代价最高的一项。
把图接进工作流，而不是当成一次性报告。 hook install 或 CI 重建 + affected 做影响面 + prs --conflicts 看合并顺序风险，图的复利来自「一直新鲜」。
只选一条查询路径。 CLI 指令与 MCP 指令不要同时塞进 AGENTS.md；Hook 型宿主优先用 hook，指令文件型宿主用常驻指令。
引用数字时带上 harness 与样本量。 71.5 倍来自 52 文件混合语料、LOCOMO/LongMemEval 是对话记忆基准、ERPNext 只有 6 题——厂商自测 + 小样本，写进内部评估时应同时注明「自建 harness」与「n」。

最后一个判断：2026 年「给智能体喂什么上下文」这件事正在从「塞更多」转向「建结构」。Graphify 给出的答案很朴素——别让智能体反复读你的仓库，把它编译成一张带标签的图，然后沿边走。

资料来源（均抓取于 2026-10-21）：GitHub Trending daily 榜单与 GitHub REST API（Graphify-Labs/graphify，默认分支 v8）；仓库 README.md（v8 分支，34 KB）、ARCHITECTURE.md、BENCHMARKS.md、SECURITY.md、NOTICE、LICENSE-MIT、pyproject.toml、graphify/skill.md（47 KB）、graphify/cluster.py、graphify/analyze.py、graphify/cache.py、graphify/dedup.py、graphify/_minhash.py、graphify/reflect.py、graphify/serve.py、graphify/affected.py、graphify/prs.py、graphify/__main__.py；worked/karpathy-repos/{README.md,review.md}；docs/how-it-works.md。第三方参考：explainx.ai 对 Graphify 的独立核查、Zenodo 记录 22160887、以及若干中文技术解读。厂商自测数据已标注来源与样本量；未能独立核实的信息已标注「待确认」或「第三方测量」。