放弃定价计算器后，我们用图数据库给AI编程助手造了个记忆引擎

AI编程助手（如Claude Code、Cursor）在真实项目中反复踩同样的坑：忘记架构决策、打破依赖边界、为理解代码库消耗大量上下文。一个失败的产品原型、一次Gemini配额耗尽的事故，加上一个曾被误认为"套壳Redis"的图数据库，催生了Banana——一个用图结构为编程Agent提供记忆与上下文调度的开源项目。

Banana项目来源

从失败产品到方向转型

Banana最初是一个B2B SaaS定价计算器。作者在Streamlit里折腾了数小时折扣滑块后问了自己一个问题：我会主动使用这个产品吗？答案是否定的。于是UI被整体删除，项目转向了AI编程Agent的上下文问题。

这个转折点值得注意：它不是从技术出发寻找场景，而是从"自己不会用"的直觉出发砍掉方向。新定位很明确——通过MCP协议为编码Agent提供代码关系检索、架构决策记忆和显式规则检查。

FalkorDB：被低估的图引擎

作者最初对FalkorDB持强烈怀疑态度，认为它可能是RedisGraph的换皮产品，或者需要4GB内存才能启动的Neo4j简化版。转折发生在实际阅读文档之后：FalkorDB底层基于GraphBLAS，将节点和关系表示为稀疏线性代数矩阵，用优化的C实现。

这意味着当你请求一次多跳依赖遍历时，引擎执行的是稀疏矩阵乘法，而非传统图引擎的内存指针递归追踪。实测数据：

三跳多边遍历：17.4毫秒
架构决策召回：1.37毫秒
AST边界检查：0.28毫秒

作者的原话是，查询返回速度快于Python序列化响应JSON的速度。这直接支撑了Agent循环对低延迟的要求。

GraphBLAS 是一套用于在图结构上表达线性代数运算的开放标准与 C 语言接口规范（由 IEEE 主导制定）。它的核心思路是把图的邻接结构编码为稀疏矩阵，把遍历、连接、求最短路径等图操作统一表达为矩阵乘法、掩码赋值等线性代数原语。由于稀疏矩阵乘法可以被高度优化（只对非零元素计算），底层实现能够获得极佳的内存局部性与并行度。FalkorDB 正是构建在 GraphBLAS 实现之上的图数据库，因此其多跳遍历本质上是稀疏矩阵乘法链，而非传统图数据库逐指针跳转的递归。这也是它能在毫秒级返回多跳结果的根本原因。

配额熔断反而验证了架构

测试期间Gemini API配额耗尽，但这个事故反而成了架构的验证机会。团队已将代码库索引进图数据库：39个文件、42个类、84个函数、275条导入与调用关系。

Agent可以直接查询图来获取依赖、检查代码结构、召回存储的决策，而不必把这些操作消耗在LLM token上。图成了记忆层，也成了模型不可用时的兜底方案。这提示了一个更普遍的设计原则：把确定性、结构化的检索任务从LLM中剥离出来，既省钱又提可靠性。

用最大流算法分配上下文预算

上下文膨胀的解法分两步。第一步是索引结构而非文本：代码库被建模为AST图（文件、类、函数节点，由IMPORTS和CALLS边连接），Cypher查询以稀疏矩阵乘法方式遍历这些关系。

第二步借用了Edmonds-Karp最大流算法。在这个类比中，"液体"是代码token，"管道"是依赖关系：

源点是正在编辑的文件或函数
管道网络是与之相连的每个类、辅助函数和导入模块，容量由PageRank和架构相关性加权
汇点是严格的LLM上下文预算（如950或2000 token）

Edmonds-Karp通过广度优先搜索寻找增广路径，在依赖图中推送最大体积的关键架构上下文，直到触及预算瓶颈。结果是接口完整、直接依赖不缺失，同时不超token上限、不在函数中间截断代码。目标一句话概括：给Agent它需要的，而不是你拥有的全部。

Edmonds-Karp 算法 是求解最大流问题的经典算法之一：在带容量的有向网络中，从源点向汇点尽可能多地推送流量，每次用广度优先搜索找到一条残余容量大于零的最短增广路径，沿路径推送可增加的流量，直到不存在增广路径为止。它的时间复杂度为 O(VE²)，实现简单、行为可预测。Banana 借用这一模型时，把依赖图当作流网络：边容量由 PageRank 与架构相关性加权决定，源点是当前编辑单元，汇点是 token 预算，算法推送的"流量"即被选入上下文的代码单元。这样选出的子图在预算内最大化了关键架构信息的覆盖。需要说明的是，原文中"架构决策召回 1.37 毫秒"指的是通过图查询检索已存决策的速度，与最大流计算是两回事，后者涉及多次广度优先搜索，更接近数十毫秒量级；不过单次查询、单次遍历仍显著快于 LLM 调用。

临时图：Agent的沙盒推演

当Agent需要推演假设性改动——比如模拟一次重构、测试破坏性依赖、或者问"改这个接口会怎样"——不应让它直接写入持久化代码图。

由于FalkorDB基于内存中的GraphBLAS线性代数，图的创建和销毁以毫秒计。Banana借此实现了临时草稿图：Agent进入推测模拟模式时，系统在5毫秒内启动一个隔离微图（banana_scratch_<session_id>），Agent在其中模拟AST差异、测试场景策略、检查循环依赖，模拟结束后一条命令丢弃。没有磁盘残留，没有持久记忆污染，也没有幻觉产物写入真实代码库的风险。

FalkorDB 之所以能支撑毫秒级创建与销毁临时图，原因在于其稀疏矩阵结构常驻内存，一个只含少量节点与边的新图只是分配若干稀疏块，不需要磁盘文件、目录或事务日志落盘，也没有传统数据库建立 schema 的开销。相比之下，在 Neo4j 等持久化图数据库中为一次假设性推演新建独立图通常涉及磁盘写入和较重的初始化成本，频繁创建删除代价明显。因此 Banana 的 banana_scratch_<session_id> 不必是完整数据库级隔离，也可以是对独立命名空间或稀疏块集合的轻量划分，其所谓"隔离"主要体现在数据不进入持久化层、会话结束后整体丢弃。

不调用LLM的护栏检查

如果一个Agent试图把底层数据库驱动直接导入UI组件，且该依赖违反显式架构规则，Banana可以直接检查相关图关系并标记违规，无需LLM介入。团队还构建了针对硬编码凭证和不安全代码原语的确定性检查。测试中AST安全与边界检查延迟为0.28毫秒。

作者也坦承了边界：并非所有安全问题都能用简单规则捕获，但显式约束不应该每次都消耗一次LLM调用。

MCP（Model Context Protocol） 是 Anthropic 提出并开源的协议，用于让 AI 应用以统一方式接入外部工具与数据源。它采用客户端—服务器模型：宿主应用（如 Claude Code、Cursor）作为客户端，外部能力提供方作为 MCP 服务器，通过 stdio 或 HTTP 传输交换 JSON-RPC 消息。MCP 服务器向模型声明可调用的工具、可读取的资源与可使用的提示模板，模型据此决定何时调用。Banana 将自己实现为 MCP 服务器，编码 Agent 因而能以标准化方式调用代码索引、上下文组装、护栏和记忆工具，而无需为每个宿主单独适配。

整体架构

Banana通过MCP服务器向编码Agent暴露代码索引、上下文组装、护栏和持久记忆工具。后端由FalkorDB管理三层图：

banana_knowledge：代码结构、依赖关系与架构决策
banana_demand：架构规则、不变量与约束
banana_scratch_*：用于隔离推演与策略模拟的临时微图

服务部署在AWS Lambda上，由FalkorDB Cloud支撑。项目已在GitHub开源，并提供在线端点与演示视频。

四条经验

作者总结的收获值得单独拎出来：代码是图而不只是文本，导入、调用和类关系在检索上下文时至关重要；不是每个问题都需要LLM，确定性检查更快更可预测；记忆只有在被检索时才有价值，存下决策有用，在对的时机取回才有意义；临时图释放了安全的Agent推演能力，一个即时、可丢弃的图沙盒能防止真实代码库被污染。

对正在构建AI编程工具的团队来说，Banana的思路提供了一个可借鉴的范式：用图结构承担结构化推理，用算法（最大流）管理上下文预算，用确定性检查兜住显式规则，把LLM留给真正需要语义理解的部分。