Graphicle 0.1.0：Graphify 的 Rust 移植版，为编码代理添加代码图谱和记忆功能
Graphicle 是一个用 Rust 编写的单一程序，它构建仓库的代码图谱并存储项目记忆——文档、决策和过去的代理会话——然后通过 MCP 向编码代理提供带有引用来源的摘录。它是 Graphify 代码图谱引擎的 Rust 移植版，并在此基础上增加了记忆层、应用和会话捕获，采用 Apache-2.0 许可，由 KarLex AI, Inc. 发布。
该项目以 Show HN 的形式发布到 Hacker News，获得了 32 分和 9 条评论。讨论内容不多：九条评论中有三条被标记，其余实质性的评论质疑这种记忆系统是否优于使用 ripgrep 的普通代理框架。
Graphicle 的功能
Graphicle 结合了通常作为独立工具的两种能力：代码图谱和记忆存储。代码图谱覆盖文件、函数、类、调用和导入，使用 tree-sitter 解析，无需模型。记忆存储覆盖 Markdown、PDF、Office 和 HTML 文档、已审阅的决策和流程，以及过去的 Claude Code 和 Codex 会话。
两者可以一起搜索。graphicle context 和 MCP 工具在 token 预算内返回带有来源的摘录，无需调用模型。每个摘录都标明其文件和行范围。
README 中有一个示例，询问 graphicle ask "where is tax added to prices?"，返回四个带引用的摘录，共 598 个 token（预算为 3,000）。第一个是 shop/pricing.py:1-7，即 price_with_tax() 函数。
安装与设置
安装路径是 Homebrew 或 shell 脚本：
brew install graphicle-ai/tap/graphicle
cd your-repo
graphicle setup
如果没有 Homebrew，README 提供了 curl -fsSL https://github.com/graphicle-ai/graphicle/releases/latest/download/install.sh | sh。目前还没有原生 Windows 构建版本；README 指出 Linux 安装版本在 WSL2 下应该可以工作，但尚未在那里测试，原生 Windows 支持正在计划中。
graphicle setup 索引仓库，构建代码图谱，连接它找到的编码代理，开启会话捕获，将 Claude Code 的搜索首先指向代码图谱，向 AGENTS.md 添加一个简短部分，并安装 Git 钩子以保持项目最新。它会列出每个更改的文件，并首先将每个文件备份为 <file>.graphicle-bak。graphicle disconnect 会撤销 setup 所做的所有更改。
README 中记录的其他命令包括：用于终端提问的 graphicle ask、用于浏览器查看图谱、来源和记忆的 graphicle open、用于健康检查的 graphicle doctor、先执行 graphicle graph extract . --code-only 再执行 graphicle graph affected "retry()" 来列出依赖某个符号的内容，以及 graphicle call graph.doc_links 来列出文档中代码提及与其定义之间的链接。
基准测试：与 Graphify 的速度对比
在包含约 31,000 个文件的 Kubernetes 上，Graphicle 0.1.0 引擎执行纯代码提取耗时 3 分 18 秒，而 Graphify 0.9.88 耗时 26 分 38 秒。两者构建的图谱相同：256,329 个节点和 1,400,392 条边。README 描述这是各自一次探索性运行，在同一台 Linux 主机上，使用相同的 16 个 CPU 和 8 个 worker，并指出 0.1.0 引擎是发布源码的 Linux 测试构建。
在 Django 上的早期比较测量了 Graphicle 预发布构建的纯代码提取耗时 7.5 秒，而 Graphify 0.9.77 耗时 72.8 秒。这些数字是同一台共享 Linux 主机上 8 个 worker 交替运行五次的中位数，两个工具构建的图谱相同。
基准测试：与七个记忆系统的比较
README 报告了与七个记忆系统的比较，这些系统在任何答案评分之前注册，并使用一个开放模型作为所有系统的阅读器和评判者。在该比较中，Graphicle 的预发布构建“在三个开发集上不落后于任何系统”。README 链接了完整分数以及方法和注意事项。
记忆锚定到代码符号
Graphicle 的一个独特设计选择是，已审阅的记忆与其相关的函数绑定。当这些代码发生更改时，记忆会失效，而同文件其他位置的编辑通常不会使其过时。README 链接了 crate 文档中的确切规则。
Hacker News 评论者 dmos62 特别指出这是项目最重要的部分，认为它解决了记忆系统的一个长期问题：
我认为，基于将记忆绑定到代码片段（如函数）的记忆失效机制是这里的重点，尽管我理解为什么它没有被放在首位。我一直觉得记忆系统令人反感，因为很难判断记忆是否仍然有效。此外，可发现性始终是个问题（记忆何时相关）。这既是一个代码图谱系统又是一个记忆系统（看似无关的事物），实际上以一种新颖的方式解决了这个问题。
代理提出的记忆不会自动生效。它们会在应用中等待批准，而 graphicle open 会将你引导到那里。
架构：一个程序，一个 SQLite 文件
Graphicle 将代码图谱、记忆、一个 MCP 服务器、Web 应用和命令行打包在一次安装中，由一个 SQLite 文件支持。README 将这与常见的替代方案（代码图谱工具加记忆服务器）进行了对比，后者通常意味着两个工具运行在不同的运行时上，两个 MCP 服务器在每个代理中单独配置，存储也是分开的。
MCP 服务器通过 graphicle mcp 启动，并在 Graphify 的工具名称下提供代码图谱工具，包括 query_graph、get_neighbors 和 shortest_path，同时还有记忆工具。通过 graphicle context --workspace 或工作区 MCP 端点，可以在工作区中跨多个仓库进行回忆。
源码分为三个 crate：crates/graphicle/ 用于程序（命令行、应用、HTTP 和 MCP 服务器），crates/graphicle-graph/ 用于代码图谱引擎，crates/graphicle-memory/ 用于记忆库。包含 Python 和 TypeScript SDK，以及 deploy/ 中的团队服务器配方。每个 crate 都可以独立构建。
客户端支持
graphicle setup 会通过 MCP 连接它找到的每个客户端。根据 README，连接点如下：
| 客户端 | setup 连接的位置 | 会话捕获 |
|---|---|---|
| Claude Code | 仓库中的 .mcp.json |
.claude/settings.local.json 中的钩子 |
| Codex | ~/.codex/config.toml |
~/.codex/hooks.json 中的钩子（Codex 会要求你信任它们） |
| Cursor | ~/.cursor/mcp.json |
— |
| VS Code | 仓库中的 .vscode/mcp.json |
— |
| Claude Desktop | Claude 设置文件夹中的 claude_desktop_config.json |
— |
| 任何其他 MCP 客户端 | 一个简短的 JSON 条目 | — |
隐私和本地优先行为
Graphicle 不需要帐户，也不发送遥测数据。来源、记忆和代码图谱存储在 macOS 上位于 ~/Library/Application Support/Graphicle、Linux 上位于 ~/.local/share/graphicle 的单个 SQLite 存储中；graphicle graph extract 将图谱文件写入项目中的 .graphicle/。应用及其 HTTP 和 MCP 端点默认监听 127.0.0.1。
README 列出了 Graphicle 需要访问网络的情况：你配置的模型或连接器、完整的 graphicle graph extract（会将文档和图像发送给它找到 API 密钥的 LLM）、用于 graphicle graph add、clone 和图谱服务器拉取请求工具的 GitHub CLI，以及带有你指定订阅源的 graphicle update。从源码构建也会下载一次解析器源码。
同步尊重 .gitignore，跳过 .env 文件、密钥和凭据。会话捕获会丢弃 <private>…</private> 片段并编辑凭据。删除记忆或捕获的会话也会移除从中派生的内容，并生成哈希链删除收据。
哪些需要模型，哪些不需要
使用 --code-only 的代码图谱、同步、context、MCP 服务器、会话捕获或应用都不需要 API 密钥或模型。模型需要用于编写 graphicle ask 的答案、从来源提出记忆，以及在完整的 graphicle graph extract 期间读取文档和图像。
模型使用 graphicle config set model anthropic、openai 或 ollama 配置。支持通过 Ollama 或任何兼容 OpenAI 的服务器使用本地模型。如果没有配置模型，graphicle ask 仍会显示检索到的证据，而不是书面答案。
限制和许可
默认情况下，项目最多可以包含 100,000 个文本文件和 1 GiB 的文本，两个限制都可以提高。非常大的文件会被部分分析或保留为可搜索文本，而不会停止同步。
Graphicle 采用 Apache-2.0 许可，可免费使用、修改和商业分发。代码图谱引擎是 Safi Shamsi 和 Graphify 贡献者的 Graphify 的 Rust 移植版，与 Graphify 的发布保持同步，并在文件头和 NOTICE 文件中注明；一致性检查会标明其跟随的发布版本。记忆、记忆工具、应用和会话捕获不属于 Graphify。支持从 Graphify 迁移：graphicle setup 会提供切换仓库的选项，备份每个文件，并且永远不会删除 graphify-out/。
贡献在 Apache-2.0 下接受，需要开发者原始证书签署（git commit -s），无需贡献者许可协议。面向团队的专业版正在私下预览中。
Hacker News 讨论中提出的问题
帖子中最实质性的反驳来自评论者 theLiminator，他报告说在他的测试中，记忆系统表现不如更简单的基线：
有人真的从这个得到好结果了吗？在我运行的评估中（虽然不太科学），这些记忆系统比使用 ripgrep 的原始框架表现更差。
评论者 pjm331 提出了这一说法背后的方法论问题：
谁在那里评估给代理这类工具，你们是怎么做的？
帖子中没有人回答这两个问题。评论者 blackspacx 询问基准测试如何保持以及该工具是否由 AI 协助编写；可见评论中也没有回答。其余评论，包括提交者账户 KarLexAI 的一条，都被标记了。
从帖子中得到的实际结论是，项目自己的记忆基准——七个系统，一个开放模型作为阅读器和评判者，在评分前注册——是迄今为止提出的唯一评估证据，而针对 ripgrep 加框架基线的独立复制尚未公开演示。