# Graphify 深度研究报告

更新时间：2026-05-18

## 一句话结论

Graphify 是一个面向 AI 编程助手的“项目记忆层”。它把代码、文档、PDF、图片、视频、SQL schema 等资料转成可查询知识图谱，让 Claude Code、Codex、Cursor、Gemini CLI、Trae、Hermes、Kimi Code 等 Agent 不必每次重新读全仓库。

## 项目定位

Graphify 解决的是 AI 编程里的上下文浪费问题：

> Agent 每次接手复杂项目，都要重新 grep、读文件、猜架构，成本高且容易漏关系。

它的做法是先生成项目图谱，再让 Agent 通过 query、path、explain 等命令查图谱。这样 Agent 查的是“项目地图”，不是每次盲扫文件。

运行 `/graphify .` 会生成 `graph.html`、`GRAPH_REPORT.md` 和 `graph.json`，分别用于浏览器查看、阅读重点摘要、给 Agent 查询完整图谱。

## 核心能力

| 能力 | 价值 |
| --- | --- |
| 代码图谱 | 用 tree-sitter 本地解析多种语言 |
| 多模态资料 | 支持 docs、PDF、Office、图片、视频、YouTube |
| Agent 集成 | 支持 Claude Code、Codex、Cursor、Aider、Trae、Hermes、Kimi 等 |
| 查询工具 | 支持 query、path、explain、wiki、callflow-html |
| 团队共享 | `graphify-out/` 可提交到 Git，让团队共享项目地图 |

它不仅能告诉你“文件在哪”，还能提取 god nodes、surprising connections、设计原因、置信标签和建议问题。

## 技术路线

Graphify 对代码部分尽量本地解析，不依赖 API；对 PDF、图片、视频等非结构化资料则调用模型 API。这个设计比较务实：代码结构用确定性解析，非代码语义用 LLM。

它还支持 MCP、Neo4j、视频 / 音频转写、Office 解析、SQL schema 抽取、OpenAI / Gemini / Bedrock / Ollama 后端，以及 Git hook 自动更新图谱。

这说明它不是单次扫描工具，而是想变成持续维护的项目上下文基础设施。

## 和同类项目对比

| 项目 | 定位 | Graphify 的差异 |
| --- | --- | --- |
| GitNexus | Agent 代码知识图谱 | GitNexus 更重代码影响分析，Graphify 输入类型更广 |
| Understand-Anything | 代码地图和 onboarding | Understand-Anything 更偏 dashboard，Graphify 更偏 Agent 查询记忆层 |
| DeepWiki | 自动生成代码库文档 | Graphify 更强调图谱查询和多平台 Agent 集成 |
| Sourcegraph Cody | 代码搜索 + AI 问答 | Graphify 更轻量，可提交图谱给团队共享 |
| 普通 RAG | 文本召回 | Graphify 保留关系、路径、概念和设计理由 |

一句话：普通 RAG 是“找相关文本”，Graphify 更像“给 Agent 一张项目地图”。

## 风险与边界

第一，图谱不是事实本身。README 里区分 `EXTRACTED`、`INFERRED`、`AMBIGUOUS`，这说明有些关系是推断出来的，必须复核。

第二，图谱会过期。代码频繁变化时，如果不跑 update 或 git hook，Agent 查到的是旧地图。

第三，多模态资料依赖模型质量和成本。图片、视频、PDF 不是纯本地解析，效果会受后端模型影响。

第四，大型仓库的图谱可读性要实测。生成图谱容易，真正让人和 Agent 高效使用才是难点。

## 最终判断

Graphify 是 AI 编程工具生态里很值得关注的“记忆层”项目。它抓住了一个真实痛点：Agent 不缺读文件能力，缺的是可复用、可查询、能跨会话共享的项目上下文。

结论：Graphify 不是代码生成器，而是 Agent 的项目地图和长期记忆。它适合复杂仓库理解、团队 onboarding、架构梳理和减少上下文浪费，但不能替代测试、review 和人工架构判断。

## 信息来源

- GitHub 仓库：https://github.com/safishamsi/graphify
- README：https://github.com/safishamsi/graphify