2026 年 7 月的 GitHub Trending 榜单上，有两个项目持续吸引开发者的注意力：code-review-graph 和 cognee。前者解决的是 AI Agent 在代码审查场景下的上下文成本问题，后者解决的是 AI Agent 跨会话的长期记忆问题。看似两个不同方向的工具，实际上指向同一个核心挑战——如何让 AI Agent 更高效地管理和利用上下文。

先说 code-review-graph。这个项目在过去一周从 GitHub 第六名跃升到第二名，Star 数接近翻倍。它的核心思路是在本地构建持久化的代码知识图谱，通过 MCP 协议让 Claude Code、Cursor 等 AI 编程工具只读取关键代码片段，而不是把整个代码库塞进上下文窗口。

传统做法是让 AI 读取整个仓库，一个中型项目动辄几十万行代码，Token 消耗惊人且容易超出上下文窗口。code-review-graph 的做法是预先构建代码依赖关系图谱，当 AI 需要审查某个函数时，只加载该函数及其直接依赖的代码片段。实测表明，这种做法能将代码审查的 Token 消耗降低 60% 到 95%，同时审查质量不降反升，因为 AI 聚焦在真正相关的代码上。

这个项目的技术架构值得拆解。它用 Python 实现，通过静态分析提取函数调用关系、类继承关系、模块依赖关系，构建成图数据结构存储在本地。对外通过 MCP 协议暴露查询接口，AI 工具可以按需查询特定函数的依赖链路、影响范围和变更历史。这意味着即使你的项目有十万行代码，AI 每次只需要处理几百行真正相关的代码。

再看 cognee。这个项目目前有 28792 颗星，8882 次提交，开发非常活跃。它定位为开源的 AI Agent 记忆平台，核心目标是让 AI Agent 拥有跨会话的持久化长期记忆。

为什么 AI Agent 需要长期记忆？目前大多数 AI 对话工具都是无状态的——每次新对话从零开始，之前聊了什么完全不知道。对于简单的问答场景这没问题，但如果 Agent 要执行复杂的多步骤任务，比如持续跟踪一个项目的进度、记住用户的偏好和历史决策，没有记忆就成了硬伤。

cognee 的技术方案是双层存储。底层用知识图谱引擎存储结构化信息，支持 Neo4j、PostgreSQL、Kuzu 等多种图数据库后端。上层用向量搜索做语义召回，当 Agent 需要回忆某个信息时，通过双路召回（图查询加向量搜索）找到最相关的记忆片段。这种设计的优势在于既能精确查询关系型信息，又能模糊匹配语义相似的内容。

部署方面，cognee 提供了 Docker 一键部署方案，附带 Jupyter Notebook 示例和入门模板，对开发者比较友好。不过目前只有韩文 README，中文文档缺失，对国内开发者来说入门门槛稍高。

从这两个项目的走红，可以看出 AI Agent 基础设施正在从概念走向工程化。过去一年大家关注的是 Agent 能做什么，现在关注的是 Agent 怎么做得更高效、更持久。上下文管理和记忆管理正是这个方向上最基础也最关键的两块拼图。

对于想要尝试的开发者，code-review-graph 适合正在用 Claude Code 或 Cursor 做大仓库代码审查的团队，能立竿见影地降低 Token 成本。cognee 适合需要构建长期记忆 Agent 的场景，比如个人助手、项目跟踪、知识管理等。两者都是 MIT 或类似宽松协议，可以自由使用和修改。

值得关注的趋势是，MCP（Model Context Protocol）正在成为这类工具的标准接口。code-review-graph 通过 MCP 暴露代码图谱查询，这意味着任何支持 MCP 的 AI 工具都能接入，不局限于单一平台。这种开放性是开源项目获得社区认可的重要因素。

对于企业团队来说，如果考虑自建 AI 开发平台，这类上下文管理工具可以作为基础设施层的重要组成部分。像 MonkeyCode 这样的开源 AI 开发平台，本身就支持通过 MCP 协议扩展工具能力，结合 code-review-graph 做代码审查、结合 cognee 做任务记忆，可以构建出更完整的 AI 编码工作流。开源生态的价值就在于此——不同项目各司其职，通过标准协议串联起来，形成大于个体之和的系统。

GitHub 仓库地址：

code-review-graph: https://github.com/tirth8205/code-review-graph

cognee: https://github.com/topoteretes/cognee