过去我们让编程 Agent 改代码，最常见的问题不是模型不会写，而是它不知道该看哪里。
一个真实项目里，入口、调用链、配置、测试、历史兼容逻辑，经常散在几十个文件里。Agent 如果每次都靠 grep、read、全局搜索现场摸路，工具调用会很多，Token 会涨，结果还不一定稳。
最近火起来的两个项目，正好都在解决这个问题：CodeGraph 和 Understand-Anything。
它们都和“代码知识图谱”有关，但定位并不一样。
一句话概括：
CodeGraph 更像给编程 Agent 用的本地代码索引和结构化查询工具；Understand-Anything 更像给人和 Agent 一起看的交互式项目地图。
先看核心区别
| 对比项 | CodeGraph | Understand-Anything |
|---|---|---|
| 核心目标 | 让 Agent 更快找到相关代码上下文 | 让人更快理解整个项目结构 |
| 主要入口 | CLI、MCP Server、TypeScript API | Claude Code 插件、Dashboard、图谱文件 |
| 典型能力 | query、context、callers、callees、impact、affected | 项目图谱、搜索追问、导览、业务域、diff impact |
| 输出形态 | 本地索引、结构化查询结果、Markdown 上下文 | knowledge-graph.json、可视化 Dashboard |
| 使用者 | Claude Code、Cursor、Codex、OpenCode 等 Agent | 工程师、新人、架构师、Agent |
| 更适合 | 改代码前快速定位影响范围 | 接手项目、看架构、做导览、理解业务流程 |
简单说，CodeGraph 更偏“工具层”，Understand-Anything 更偏“认知层”。
CodeGraph 关心的是：Agent 要做一个任务，应该先拿到哪些代码上下文。
Understand-Anything 关心的是：一个人或团队要理解项目，应该先看到怎样的系统地图。
CodeGraph：提前索引，减少 Agent 现场摸路
CodeGraph 的思路很直接：不要让 Agent 每次都从零开始搜代码。它会预先分析项目，把函数、类、调用关系、导入关系、文件结构等信息建立成本地索引。
之后 Agent 可以直接问：
createOrder 被谁调用？
UserService.login 调用了哪些函数？
修改 paymentCallback 会影响哪些模块？
围绕“修复登录状态刷新”生成相关上下文。
对应命令大概是：
codegraph callers createOrder
codegraph callees createOrder
codegraph impact paymentCallback
codegraph context "修复登录状态刷新问题"
它最适合放在 Claude Code、Cursor、Codex CLI、OpenCode 这类编程 Agent 后面，当成本地代码知识服务。
这类能力的价值很实在：减少无效搜索，减少 Token 消耗，也减少 Agent 只看局部文件就动手的概率。
Understand-Anything：把项目变成能看的系统地图
Understand-Anything 的入口更偏交互式理解。它会扫描代码库，提取文件、函数、类、依赖、调用关系，再用多智能体补充架构层、业务域、导览路线和影响分析，最终生成一个可视化图谱。
典型流程是：
/understand
/understand-dashboard
生成的核心产物是：
.understand-anything/knowledge-graph.json
你可以在 Dashboard 里搜索模块、点击节点、看依赖路径，也可以追问：
支付流程怎么走？
这个模块负责什么？
新人应该先看哪些文件？
当前 diff 会影响哪些业务域？
它的优势不是让 Agent 少调用几次工具，而是让人先看到全局结构。对于新人入职、老项目交接、架构梳理、重构前评估，这种可视化图谱比单纯命令行查询更直观。
一个真实场景：修支付回调问题
假设线上出现一个问题：支付成功后，订单状态偶尔没有更新。
如果只靠 Agent 自己探索，它可能先搜索 payment，再读 controller、service、repository、queue handler、test，来回跳很多次。
更稳的流程应该是这样：
这个流程里，两者分工很清楚。
Understand-Anything 先帮你看“系统怎么走”。它告诉你支付回调、订单状态、消息队列、库存、通知这些模块之间的关系。
CodeGraph 再帮 Agent 查“具体谁调用谁”。它把关键函数、调用方、被调用方和影响半径整理出来，让 Agent 修改时不至于漏掉相关文件。
一个偏宏观，一个偏精确。
什么时候用 CodeGraph
如果你已经知道要改的大致方向，只是需要更快定位相关代码，CodeGraph 更合适。
比如：
- 修一个明确的 bug；
- 查某个函数的调用方；
- 评估改一个 service 的影响面；
- 给 Agent 生成任务上下文；
- 找出某些文件改动会影响哪些测试；
- 希望减少 Claude Code 或 Codex 的工具调用。
它适合嵌在日常开发流程里，作为 Agent 的“代码检索底座”。
尤其是中大型项目，Agent 每次任务都要重新搜索一遍文件时，CodeGraph 的预索引价值会比较明显。
什么时候用 Understand-Anything
如果你还没弄清楚系统结构，或者希望团队共享一张项目地图，Understand-Anything 更合适。
比如：
- 新人第一天接手项目；
- 老项目文档过期；
- 技术负责人想梳理架构；
- 重构前要看模块边界；
- 多语言仓库里依赖关系混乱；
- 想生成 onboarding guide；
- 想用 Dashboard 讲清楚一个业务流程。
它更像“项目理解入口”。先用它把系统看明白，再决定让 Agent 改哪里。
两者不是替代关系
很多人会问：既然 Understand-Anything 也有图谱和影响分析，那还需要 CodeGraph 吗？
需要看使用方式。
如果你想给人看、给团队讲、给新人导览，Understand-Anything 更顺手。
如果你想让 Agent 在执行任务时快速拿到精确上下文，CodeGraph 更像底层工具。
一个完整的 AI 编程工作流，可以把它们放在一起：
这才是更真实的用法：人先用图谱理解系统，Agent 再用索引执行任务。
实践注意事项
第一，不要把图谱当成绝对真相。
不管是 CodeGraph 还是 Understand-Anything，都依赖静态分析和一定程度的语义推断。动态调用、反射、运行时注册、框架魔法，都可能让图谱不完整。关键改动前还是要看源码、跑测试。
第二，先排除噪声目录。
node_modules、dist、build、coverage、生成代码、大型快照文件都不应该进分析范围。图谱越干净，结果越有用。
第三，图谱和索引要跟代码版本绑定。
代码大改后，旧图谱会过期。团队最好约定：主分支大改、重要重构、发布前重新生成图谱或同步索引。
第四，不要一上来追求全量自动化。
更稳的方式是先选一个真实场景，比如“修支付回调问题”或“理解登录流程”，看它们能不能减少搜索时间、缩小影响范围、帮助补测试。
总结
CodeGraph 和 Understand-Anything 都在解决 AI 编程里的同一个大问题：代码上下文太散，Agent 和人都容易迷路。
但它们的切入点不同。
CodeGraph 更像给 Agent 准备的本地代码地图：
快速查符号、调用链、影响范围，并生成任务上下文。
Understand-Anything 更像给团队准备的交互式项目图谱：
看架构、看业务域、看导览、看系统关系。
如果你要让 Agent 更稳地改代码，先看 CodeGraph。
如果你要让人更快理解项目，先看 Understand-Anything。
如果你的团队已经在认真使用 Claude Code、Codex、Cursor 这类工具，最好的答案不是二选一，而是组合：
Understand-Anything 负责让人看清全局，CodeGraph 负责让 Agent 精确动手。
