你已经抽取出 LLM Wiki下一步更重要的是先验证多 Agent 在完成真实编码任务时是否确实需要大量关系遍历。什么时候不需要 Neo4j如果当前 Agent 主要问某模块负责什么某个业务概念怎么定义项目的编码规范是什么某个功能大概在哪里实现有没有相似的历史方案那么Wiki 文档 关键词检索 向量检索 repo/path/commit 元数据过滤基本够用。此时引入 Neo4j 会增加图谱构建、增量同步、实体消歧和运维成本但收益可能不明显。什么时候 Neo4j 有价值如果 Agent 高频需要回答以下问题就适合引入修改这个 API 会影响哪些服务、模块和测试某个函数被哪些调用链间接依赖从入口 API 到数据库经过哪些类和函数哪些测试覆盖了这条调用路径两个故障是否共享某个底层依赖跨多个仓库的接口消费者有哪些多个 Agent 当前修改范围是否存在依赖冲突这些本质是实体关系查询 2N 跳遍历 路径查找 影响面分析这正是 Neo4j 擅长的场景。推荐的技术演进第一阶段先把图模型设计出来即使暂时不上 Neo4j也建议把知识抽象成节点和关系节点Repository Module File Symbol API DatabaseTable Test ADR Task Commit关系CONTAINS IMPORTS CALLS IMPLEMENTS EXPOSES DEPENDS_ON READS WRITES COVERED_BY DECIDED_BY CHANGED_IN初期可以先存 PostgreSQL 关系表knowledge_nodes(id, type, properties, commit_sha) knowledge_edges(source_id, relation, target_id, commit_sha)等真实任务证明需要复杂多跳查询再迁移到 Neo4j。这样不会一开始就背上图数据库的复杂度。第二阶段建立可靠的代码关系不要完全依赖大模型生成调用关系。建议AST/LSP抽取 symbol、import、implements、静态调用OpenAPI/Proto抽取服务接口关系数据库 schema/ORM抽取表和数据访问关系测试框架抽取 test → symbol/moduleGit抽取 commit、变更和共同修改关系LLM补充语义解释、业务意图和关系摘要。原则是代码事实由确定性工具抽取LLM 负责解释和补全不负责凭空认定事实。第三阶段采用混合检索即使上 Neo4j也不要让它替代 Wiki 和向量库。比较合理的是任务├─ 关键词/符号检索定位入口├─ 图检索扩展依赖、调用链、测试和影响面├─ 向量检索召回 Wiki、ADR、历史 PR└─ 重排压缩生成角色化 Context Pack例如任务是“修复订单重复扣减”精确找到OrderService.create图查询扩展到库存服务、事务组件和并发测试向量检索召回幂等设计 ADR 和历史故障按 Developer Agent 的 token 预算生成上下文包。我的具体建议你当前可以按下面的顺序推进先不上 Neo4j给 Wiki 增加repo/path/symbol/commit/source用 AST/LSP 抽取节点和边先存关系表或轻量图结构选择 2050 个真实编程任务做评测如果大量任务依赖 2 跳以上影响分析再接 Neo4j将 Neo4j 定位为“代码知识图谱”不要把所有 Wiki 正文都硬塞进图里。一个简单的决策标准如果超过约 30% 的真实任务需要跨符号、跨模块或跨仓库进行两跳以上关系查询Neo4j 大概率值得引入否则先把混合检索和 Context Pack 做好收益更高。所以你现在真正要决定的不是“是否使用 Neo4j”而是现有 Wiki 有没有结构化到 symbol 级别以及 Autopilot 当前最常见的任务是否需要影响面和调用链分析。