上个月写 Axon 的时候，我其实就在想一个问题：代码知识图谱这个方向，到底有没有可能做出一个"够用"的通用方案？Axon 只支持十来种语言，Context+ 多一点但也没突破 20 种。对于那种 Python 后端 + TypeScript 前端 + Go 微服务的典型项目，你得同时跑两三套工具，Agent 切来切去，体验很割裂。
Gortex 出来的时候我第一反应是不信的——257 种语言？多半又是 regex 大法糊弄。但实际看了之后发现不是那么回事。
它做了什么
简单说，Gortex 把你的代码库变成一张图。函数是节点，调用关系是边，类型引用、import 链、环境变量依赖全部连上去。然后它通过 MCP 把这张图暴露给 Agent，Agent 查代码不用再把整个文件塞进上下文——直接问"这个函数调了谁""改了这个会影响什么"，图谱返回精确的几行结果。
这听起来跟 Axon、Context+ 差不多对吧？差别在细节。
Gortex 把 257 种语言分了三档。前 17 种（Python、TypeScript、Go、Java、Rust、C/C++、Swift、Kotlin 这些）用 tree-sitter 做 AST 解析，精度到函数级，能追踪真实的调用链——不是字符串匹配"看起来像在调 foo()"，而是编译器级别确定"这里调的就是 UserRepository 里的那个 Create"。中间一大档用正则提取函数签名和 import 关系。最后一档是文件级兜底，Jupyter notebook 和一些冷门语言走这条路。
不是所有语言都有 AST 级精度，但 17 种核心语言覆盖了日常开发的 90% 以上场景。这个取舍我觉得是合理的。
真正让我觉得有意思的东西
175 个 MCP 工具。我一开始觉得这是在堆数字，但仔细看了一下，里面的 Blast Radius 分析和跨仓库合约检测确实是刚需。
Blast Radius 的意思是：你改了一个函数的返回值，Gortex 能立刻告诉你整条调用链上哪些地方会受影响。它不是每次实时算的——预计算了一个 depth-3 的 reach index，查询的时候就是 map lookup，基本秒回。我在一个 2000 文件的 Go 项目上试了一下，改了 UserRepository.Update 的签名，它列出了 12 个受影响的位置，包括 3 个 HTTP handler 和 1 个 gRPC service。准确率很高，没有漏的。
跨仓库更有意思。Gortex 支持同时把多个仓库加进同一张图谱，然后它会自动匹配 HTTP 路由的 provider-consumer 关系（支持 gin、Express、FastAPI、Spring）、gRPC proto service 和 client stub、甚至 Kafka 和 RabbitMQ 的 pub/sub 关系。微服务团队改一个服务的 API，不用猜下游哪个服务会炸——Gortex 直接告诉你。
这个功能 Axon 和 Context+ 都没有。不是技术上做不到，而是工程量太大——要解析每种框架的路由注册方式、protobuf 生成代码、消息队列的 topic 命名规则。Gortex 一个一个硬啃了。
实际跑了一下
安装很简单，单二进制：
curl -fsSL https://get.gortex.dev | sh然后 gortex install 检测机器上的 Agent（Claude Code、Cursor、Copilot 这些），自动写入 MCP 配置。gortex daemon start --detach 起后台进程，gortex track ~/projects/myapp 加项目，cd ~/projects/myapp && gortex init 初始化。整个过程不到两分钟。
我拿 Linux 内核源码试了一下索引速度。70333 个文件，169 万个图节点，623 万条边——三分钟出头跑完，峰值内存 5GB 左右。官方数据没吹牛。vscode 源码（10762 文件）一分钟，自己的小项目几秒钟。
索引完之后，Agent 的体验变化是很明显的。以前问"这个函数是干什么的"，Agent 会把整个文件读进来，500 行里 490 行是噪声。现在一个 MCP 查询直接返回函数签名、docstring、调用的子函数列表，十来行搞定。Gortex 内置了 token 计数器，跑了一周显示节省了 93% 的 token——跟它宣传的 50 倍基本吻合。
跟 Axon、Context+ 比
这三个工具做的事情本质一样：给代码库建图谱，通过 MCP 暴露给 Agent。但量级完全不同。
Axon 是 Python 写的，依赖 Neo4j，支持十来种语言，MCP 工具十来个。适合小项目快速体验，但碰到真实的大仓库就力不从心了。Context+ 是 TypeScript，不需要外部数据库，但支持的语言也不多，MCP 工具 17 个，核心差异在 RAG 语义搜索。
Gortex 是 Go 写的，零外部依赖，一个二进制搞定一切。257 种语言、175 个 MCP 工具、多仓库图谱、3D Web UI、SLSA Level 3 供应链安全——每一项都在拉开差距。而且它的工程成熟度明显更高：cosign 签名、18 种 Agent 的自动适配、增量索引更新。这些不是 demo 级的东西，是真正能放进 CI/CD 流水线里的。
但 Context+ 有一个 Gortex 没有的东西：RAG 语义搜索。Gortex 用的是内置的 GloVe-50d 模型（3.8MB），速度快但精度一般。如果你需要语义级别的代码搜索（"找一段处理用户权限的逻辑"这种模糊查询），Context+ 的 RAG 方案更合适。Gortex 可以切换到 MiniLM 或 Ollama 获得更高精度，但需要额外配置。
踩的坑
说几个实际碰到的问题。
175 个工具太多了。Claude Code 的 MCP 工具列表有长度限制，175 个工具全开的话 Agent 根本看不过来。好在可以按需启用，我建议先只开核心的 20-30 个（符号查询、调用链、Blast Radius），其他的按需加。但文档里没有说清楚哪些是"核心"的，得自己摸索。
tree-sitter 的 CGO 依赖。如果你要从源码编译，需要 C 编译器。大部分用户用预编译二进制不会碰到这个问题，但在 CI 环境里如果想自己 build 就比较麻烦。
语义搜索默认开。Gortex 默认启用 GloVe-50d 做语义搜索，3.8MB 的嵌入模型内置在二进制里，不需要额外下载。但如果你不需要语义搜索（大部分人用图谱查询就够了），它白白占了一点资源。可以在配置里关掉。
多仓库的 provider-consumer 匹配不是万能的。它支持 gin、Express、FastAPI、Spring 这些主流框架，但如果你用了比较冷门的框架或者自定义的路由方式，匹配可能不准。我试了一个用 Chi（Go）的项目，HTTP 路由没被识别出来，得手动标注。
谁应该试试
微服务团队是第一优先级。跨仓库的 API 合约检测是 Gortex 最独特的功能，Axon 和 Context+ 都做不到。如果你有 5 个以上的微服务仓库，花一个下午把它们都加进 Gortex 的图谱里，以后改 API 就不用猜了。
大型单体仓库也合适。Linux 内核级别的代码库三分钟索引完，Blast Radius 查询秒回。比让 Agent 暴力读文件高效太多。
Token 预算敏感的团队也值得算一笔账。Gortex 内置的计数器显示，在一个用了 Claude Opus 的团队里，一周省了 $168 的 token 费用。这个数字因项目而异，但量级是对的。
官网：gortex.dev