大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



71.5 倍 Token 压缩、多模态理解、零服务器依赖——Claude Code 生态中最被低估的知识工程利器

---

Andrej Karpathy 曾在一次分享中提到，他有一个名为 /raw 的文件夹。那里堆积着论文 PDF、推文截图、随手记下的笔记、白板照片——知识的原始形态。问题是：当需要查找某个概念时，他得手动翻阅这一切。

这不是 Karpathy 一个人的问题。每个程序员、每个研究者、每个试图用 AI 处理复杂信息的人，都面临同样的困境：

• 代码库越来越大，模块之间的关系像 spaghetti
• 论文读了一堆，却想不起哪篇提到了那个关键的优化技巧
• 截图里的架构图、白板上的设计草图，成了”数字废墟”

Graphify 的出现，正是为了解决这个困境。它不是又一个向量数据库，不是又一套 RAG 流水线——它是一套将任意信息（代码、文档、论文、图片）转化为可查询知识图谱的完整工程方案。

更重要的是，它是 Claude Code 生态中增长最快的 Skill 之一：发布 5 天，12,400+ Stars，被社区称为”GraphRAG 的实用主义答案”。

---

传统的 RAG（Retrieval-Augmented Generation）工作流程是：

文档 → 分块 → Embedding → 向量数据库 → 相似度检索 → LLM 生成 

这个流程的问题在于：它丢失了文档之间的结构关系。当你问”Attention 机制如何影响优化器设计？”时，向量检索可能分别找到关于 Attention 的段落和关于优化器的段落，但无法理解它们之间的逻辑关联。

知识图谱（Knowledge Graph）的做法完全不同：

文档 → 实体抽取 → 关系抽取 → 图谱构建 → 图遍历检索 → LLM 生成 

关键差异：图谱保留了”概念 A 通过关系 R 影响概念 B”这样的结构化信息。检索不再是”找相似的文本块”，而是”沿着关系路径遍历”。

Graphify 构建的图谱包含三类核心元素：

每条边都有置信度标签：

• EXTRACTED：明确存在于源文件中的关系（如 import 语句）
• INFERRED：合理推断的关系（如调用图的二次传递）
• AMBIGUOUS：不确定的关系，需要人工审核

这种设计体现了 Graphify 的核心价值观：诚实面对不确定性，让用户知道什么是找到的、什么是猜的。

---

Graphify 的处理流程可以概括为 7 个阶段：

detect() → extract() → build_graph() → cluster() → analyze() → report() → export() 

每个阶段都是独立的纯函数，通过 Python dict 和 NetworkX 图对象传递数据——无共享状态、无副作用，这是工程可维护性的基石。

detect.py 负责收集文件，支持以下类型：

代码提取示例（Python）：

# extract.py 中的核心逻辑 def extract_python(path: Path) -> dict:

"""提取 Python 文件的节点和边""" import tree_sitter_python as tspython parser = Parser() parser.set_language(tspython.language()) tree = parser.parse(path.read_bytes()) root = tree.root_node nodes = [] edges = [] # 遍历 AST 提取函数定义、类定义 for node in walk_ast(root): if node.type == "function_definition": func_name = extract_name(node) nodes.append({ "id": f"{path}:{func_name}", "label": func_name, "source_file": str(path), "source_location": f"L{node.start_point[0]}" }) elif node.type == "import_statement": # 创建 IMPORTS 边 imported = extract_import(node) edges.append({ "source": f"{path}:module", "target": imported, "relation": "imports", "confidence": "EXTRACTED" }) # 调用图二次传递：推断 calls 关系 edges.extend(infer_call_relationships(tree)) return {"nodes": nodes, "edges": edges} 

提取完成后，build.py 将所有文件的节点和边合并成一个 NetworkX 图：

import networkx as nx

def build_graph(extractions: list[dict]) -> nx.Graph:

G = nx.Graph() for ext in extractions: for node in ext["nodes"]: G.add_node(node["id"], node) for edge in ext["edges"]: G.add_edge(edge["source"], edge["target"], relation=edge["relation"], confidence=edge["confidence"]) return G 

接下来是关键的社区发现步骤。Graphify 使用 Leiden 算法（通过 graspologic 库）对图进行聚类：

from graspologic.partition import leiden

def cluster(G: nx.Graph) -> nx.Graph:

"""使用 Leiden 算法发现社区结构""" communities = leiden(G, resolution=1.0) for node_id, community_id in communities.items(): G.nodes[node_id]["community"] = community_id return G 

社区发现的价值在于：它揭示了知识的高阶结构。一个社区可能对应一个算法家族、一个业务模块、或一组相关的研究概念。

analyze.py 阶段计算三类洞察：

God Nodes（核心节点）：度数最高的概念，是知识图谱的”枢纽”。

def find_god_nodes(G: nx.Graph, top_k: int = 10) -> list:

"""找到度数最高的节点""" degrees = dict(G.degree()) return sorted(degrees.items(), key=lambda x: x[1], reverse=True)[:top_k] 

Surprising Connections（意外连接）：跨社区的边，尤其是代码与论文之间的连接。

def find_surprising_connections(G: nx.Graph) -> list:

"""发现跨社区的高价值连接""" surprises = [] for u, v, data in G.edges(data=True): u_comm = G.nodes[u].get("community") v_comm = G.nodes[v].get("community") # 跨社区连接更有价值 if u_comm != v_comm: score = calculate_cross_community_score(G, u, v) # 代码-论文连接权重更高 if is_code_node(u) and is_paper_node(v): score *= 2.0 surprises.append() return sorted(surprises, key=lambda x: x["score"], reverse=True) 

Suggested Questions（建议问题）：基于图谱结构生成的探索性问题。

---

Graphify 支持两种安装方式：

方式一：PyPI 安装（推荐）

pip install graphifyy && graphify install 

注意：PyPI 包名为 graphifyy（临时名称，原 graphify 名称正在回收中）

方式二：手动安装

mkdir -p ~/.claude/skills/graphify curl -fsSL https://raw.githubusercontent.com/safishamsi/graphify/v1/skills/graphify/skill.md > /.claude/skills/graphify/SKILL.md 

然后在 /.claude/CLAUDE.md 中添加：

- graphify (~/.claude/skills/graphify/SKILL.md) - any input to knowledge graph. Trigger: /graphify When the user types /graphify, invoke the Skill tool with skill: "graphify" before doing anything else. 

# 进入你的项目目录 cd my-project

启动 Claude Code

claude

在 Claude Code 中执行

/graphify .

输出结构：

graphify-out/
├── graph.html          # 交互式图谱可视化
├── obsidian/           # Obsidian 知识库格式
├── wiki/               # Wikipedia 风格文章（适合 Agent 导航）
├── GRAPH_REPORT.md     # 分析报告：God Nodes、意外连接、建议问题
├── graph.json          # 持久化图谱数据
└── cache/              # SHA256 缓存，增量更新用

# 只处理变更的文件 /graphify ./raw –update

监视模式：代码变更即时重建，文档变更通知更新

/graphify ./raw –watch

安装 Git 提交钩子：每次提交后自动重建

graphify hook install

# 自然语言查询 /graphify query "what connects attention to the optimizer?"

查找两个概念之间的路径

/graphify path "DigestAuth" "Response"

解释特定概念

/graphify explain "SwinTransformer"

# 添加论文 /graphify add https://arxiv.org/abs/1706.03762

添加推文

/graphify add https://x.com/karpathy/status/...

# 导出为 SVG /graphify ./raw –svg

导出为 GraphML（可用 Gephi、yEd 打开）

/graphify ./raw –graphml

生成 Neo4j Cypher 脚本

/graphify ./raw –neo4j

启动 MCP 服务器

/graphify ./raw –mcp

---

Graphify 官方提供了一个令人印象深刻的基准测试结果：

关键洞察：Token 压缩比与语料库规模正相关。6 个文件的小项目本来就能塞进上下文窗口，图谱的价值在于结构清晰；但当文件数达到 50+（尤其是混合代码、论文、图片）时，71 倍+ 的压缩比意味着原本需要 70K tokens 的查询，现在只需要 1K。

Graphify 的 Token 效率来自三个层面：

1. 结构压缩

原始文件包含大量冗余信息：注释、格式化、重复代码。图谱只保留概念和关系的精简表达。

原始代码文件（~500 tokens）:

def forward(self, x): # Apply attention attn_out = self.attention(x) # Add residual return x + attn_out 

图谱节点（~20 tokens）:

Node: "forward()", type: function, relations: [calls: attention, uses: residual_connection] 

2. 关系索引

向量检索需要比较查询与所有文档块的相似度，时间复杂度 O(N)。图谱遍历只需要沿着相关边探索，实际访问的节点数通常只有总数的 5-10%。

3. 语义缓存

Graphify 使用 SHA256 缓存每个文件的提取结果。重复运行时，只有变更的文件需要重新处理：

# cache.py 核心逻辑 def check_semantic_cache(file_path: Path) -> tuple[bool, dict]:

file_hash = sha256(file_path.read_bytes()).hexdigest() cache_entry = CACHE_DIR / f"{file_hash}.json" if cache_entry.exists(): return True, json.loads(cache_entry.read_text()) return False, None 

对于大型代码库：

# 使用深度模式，更激进的边推断 /graphify ./src –mode deep

分模块构建，再合并

/graphify ./src/module-a –output module-a.json /graphify ./src/module-b –output module-b.json graphify merge module-a.json module-b.json –output combined.json

对于多模态语料：

# 图片和 PDF 提取成本高，建议单独缓存 /graphify ./papers –update # 只处理新论文 /graphify ./screenshots –update # 只处理新截图 

---

Graphify 的核心定位是 Claude Code Skill。这意味着：

1. 零配置启动：安装后直接在 Claude Code 中使用 /graphify
2. 上下文感知：自动读取当前工作目录的文件
3. 结果可交互：生成的图谱可以在对话中直接查询

通过 –mcp 参数，Graphify 可以暴露为 Model Context Protocol 服务器：

/graphify ./my-project –mcp 

其他支持 MCP 的 Agent（如 OpenClaw、Codex）可以直接调用：

 }] } 

Graphify 与 MemPalace（另一个热门 Claude Code Skill）形成了有趣的互补：

协同工作流示例：

1. 用 MemPalace 记录研究笔记和对话上下文

1. 用 Graphify 构建论文和代码的知识图谱
2. 当需要回答"这篇论文的算法如何在我的代码中实现"时：
   • MemPalace 提供你的笔记和之前的讨论
   • Graphify 提供论文与代码之间的映射关系

     # 在 CI 中自动更新知识图谱 graphify ./src –update –output graph.json

检查图谱健康度（是否有孤立节点、是否有 AMBIGUOUS 边需要审核）

graphify validate graph.json

将图谱作为构建产物保存

artifacts: paths:

- graphify-out/ 

---

1. 提取质量依赖 Claude

对于文档和图片，概念抽取完全依赖 Claude 的 Vision 能力。虽然准确率很高，但成本不可忽视——处理 100 张截图可能比处理 1000 个代码文件更贵。

2. 关系推断的边界

INFERRED 关系的准确性取决于启发式规则的质量。复杂语义关系（如”论文 A 的方法启发了代码 B 的设计”）仍然难以自动捕捉。

3. 大规模图谱的性能

当节点数超过 10 万时，NetworkX 的内存占用和查询速度会成为瓶颈。虽然 Graphify 提供了 Neo4j 导出选项，但原生不支持分布式图谱存储。

1. 增量 LLM 提取

目前文档和图片的提取是”全量或零”的。未来可以支持增量式提取：只提取变更的段落或新添加的图片区域。

2. 多 Agent 协作图谱

当多个 Agent 同时修改代码库时，Graphify 的 –watch 模式可以实时同步图谱状态。未来可以扩展为多 Agent 共享的分布式知识图谱。

3. 与代码编辑器的深度集成

VS Code 扩展、JetBrains 插件——让图谱可视化成为 IDE 的一等公民。

---

Graphify 代表了 AI Agent 知识工程的一个重要方向：从被动检索到主动结构化。

它的核心价值不在于技术的新颖性（知识图谱是 decades-old 的概念），而在于工程实现的极致简洁：

• 一个命令 (/graphify .) 完成从原始文件到可查询图谱的完整转换
• 零服务器依赖，完全本地运行
• 多模态原生支持，代码、文档、论文、图片统一处理
• 诚实的不确定性标注，每条边都知道自己是 EXTRACTED、INFERRED 还是 AMBIGUOUS

在 Claude Code、OpenClaw、Codex 等 Agent 框架竞争白热化的 2026 年，Graphify 提供了一个被低估但至关重要的能力：让 Agent 真正理解复杂信息的结构，而不只是匹配文本片段。

对于每天与大量代码、论文、笔记打交道的开发者来说，Graphify 可能是那个把 /raw 文件夹从”数字废墟”变成”知识宝库”的关键工具。

---

• GitHub: https://github.com/safishamsi/graphify
• PyPI: https://pypi.org/project/graphifyy/
• Claude Code: https://claude.ai/code
• NetworkX: https://networkx.org/
• Leiden Algorithm: https://arxiv.org/abs/1810.08473

---

本文基于 Graphify v1.0 版本撰写，截至 2026 年 4 月 9 日，项目已获得 12,477 GitHub Stars。