企业级多编排 Agent 项目 从文档入库、知识路由、混合检索到证据生成、工具调用和可观测治理的完整闭环

官网文档 · 在线体验 · 快速启动 · 核心架构

开源不易，如果这个项目对你有帮助，欢迎给 Nexus Agent 点一个 Star。

Nexus Agent 是什么？

Nexus Agent 是一个 企业级 的 AI 智能体对话平台，覆盖智能对话、文档知识问答、联网搜索、RAG 检索、MCP 工具协议、Skills 能力扩展、Harness 工程化控制、会话记忆管理、等完整能力。

项目从对话入口开始，到意图分析、检索决策、多路知识召回、证据驱动生成，再到会话记忆管理、MCP 外部工具集成和文档治理，每一个环节都不是简单调个接口就完事的，而是经过深度设计和反复打磨的工程化实现。

快速导航

入口	链接	说明
官网文档	Nexus Agent 项目介绍	完整项目介绍和学习路线
核心架构	查看架构设计	了解对话、检索、工具、文档治理链路
快速启动	准备项目启动条件	本地启动前后端和中间件

项目核心亮点

• ReAct Agent 智能体的完整实现：不只是能聊天，而是支持联网搜索、工具调用、多步推理、Checkpoint 持久化，真正能自主决策和行动的 Agent。
• 三层执行器体系：系统不是把所有问题都交给 Agent，而是先做确定性编排，再按场景选择歧义追问、知识问答或开放式 Agent。
• Neo4j 文档结构图谱：每份文档在索引构建时生成 Document -> Section -> Item 层级图结构，支持章节定位、邻接遍历和结构化导航。
• 知识路由三级漏斗：用户提问后先走 Scope -> Topic -> Document 三级排序漏斗，自动锁定最相关的知识范围，再进入检索链路。
• 影子路由质量观测：用户手动选择文档时，系统在后台静默运行知识路由，对比系统推荐和用户实际选择，用于持续评估和优化路由质量。
• RAG 前置编排引擎：路由判定、问题改写、子问题拆分、知识域收缩、歧义澄清，在模型回答前先把检索计划做好。
• 双通道混合检索：向量检索和关键词检索并行执行，RRF 融合排序，可选外部 Rerank 精排，召回率和精准度兼顾。
• 证据预算控制与无证据短路：多子问题证据需要严格裁剪；没有找到相关证据时直接告知用户，不让模型凭空编造。
• Parent-Child 块聚合：检索粒度用 Child 小块保证命中率，回答阶段聚合到 Parent 大块保证上下文完整性。
• 三种会话记忆策略：无记忆、滑动窗口、摘要压缩，完整展示生产环境下如何平衡 Token 成本和上下文完整性。
• MCP 工具协议集成：Agent 可以动态发现和调用外部工具，不再局限于硬编码 Function Call。
• Skills 能力扩展体系：通过 SKILL.md 声明式定义技能，支持目录化管理、自动加载、引用脚本和参考资料。
• 文档从上传到可检索的完整链路：Tika 多格式解析、组合式切块、向量化、向量数据库 + 倒排索引双引擎构建，每一步都有任务日志。
• 组合式切块引擎：结构切块做主干、递归分块做兜底、语义分块做边界优化、LLM 智能切块处理疑难文档。
• 联网搜索与工具调用保护：集成 Tavily 搜索，支持工具重试、指数退避、异常兜底，模型调用和工具调用都有 Hook 限制。
• 推荐追问问题生成：主回答完成后额外生成最多 3 个可继续追问的问题，引导用户深入探索。
• SSE 流式输出协议：正文分片实时推送，结束时补发引用来源和推荐问题，支持主动停止生成。

前端层负责会话执行和运营控制台，接口与流式层负责请求、SSE、鉴权和中断控制，核心链路串起会话记忆、Query 改写、知识路由、图谱导航、多通道检索和 Prompt 组装。

底层再由 MySQL、PGVector、Elasticsearch、Neo4j、Redis、Kafka、MinIO、Tika 等基础设施共同提供能力。也就是说，项目亮点不是只在某个单独 Agent 里，而是分布在整条 AI 应用链路上。

核心架构

Nexus Agent 不是单点能力堆叠，而是围绕 对话编排中心、三层执行器、知识底座、检索证据、工具扩展、工程化护栏 这几块协同工作的完整体系：

系统整体是怎么跑的

用户在输入框里敲了一句话，点了发送。看起来很简单，但在 Nexus Agent 内部，这条消息要经过一条远比你想象中复杂的链路，才能变成一个靠谱的回答。

先看对话执行链路，后面再逐块拆解每个环节的设计细节：

核心思路是：不是让 Agent 自己决定所有事情，而是先用确定性的编排逻辑做好决策，再把执行交给最合适的引擎。 知识问答走稳定的证据驱动生成，开放式问题才走 Agent 自由探索。

为什么需要这个项目？

大多数人学 AI 的方式是跟着教程调一下 API，往向量库里塞点数据，让模型输出一段话——结束了。这顶多算跑通了一个 Demo，一旦追究细节就露馅了。真正的 AI 应用和调 API 之间，差的不是代码量，是对每个环节的深入理解和工程化设计。

而此项目就是为了解决这个问题：它覆盖了 Agent 智能体、RAG 检索增强生成、MCP 工具协议、Skills 能力扩展、会话记忆管理、Harness 工程化控制、文档生命周期治理 这些 AI 应用层的核心技术，每一块都有完整的设计和代码实现，复杂度对标真实企业级系统。

调个 API 不等于会 RAG

很多教程的套路是：调一下 Embedding 接口，往向量数据库里塞点数据，再用大模型生成答案——完事了。这顶多算跑通了一个 Demo。

真正的 RAG 系统要考虑的问题多得多：文档怎么切分效果最好？检索召回率不够怎么办？多路召回怎么融合排序？幻觉怎么控制？这些才是面试官会追问的点。跑通 Demo 和做出能上线的系统之间，差的不是代码量，是对每个环节的深入理解。

RAG 并不简单

一个能用的 RAG 系统至少涉及问题改写、子问题拆分、知识域收缩、混合检索、父子块聚合、引用来源、无证据短路和会话记忆。每一环都会影响最终效果。

只关注模型，忽略工程能力

RAG 项目的核心竞争力不在于你用了多强的模型，而在于工程化能力。同样的模型，检索策略不同、Prompt 设计不同、分块粒度不同，最终效果可以天差地别。

举个例子：用户问 "打印机墨盒怎么换"，文档里写的是 "墨盒更换步骤"。关键词搜索直接匹配不上，但向量检索能理解它们是一回事。这背后是 Embedding 模型的选型、向量数据库的调优、检索结果的重排序——每一步都是工程决策，不是换个更贵的模型就能解决的。

用框架套一下不等于企业级

执行器路由、前置编排器五步决策链、双通道检索融合、Parent-Child 块聚合、证据预算控制与无证据短路、组合式切块引擎、摘要压缩记忆、集群级租约互斥、全链路观测追踪。这些构成项目核心竞争力的能力，这些框架并不具备的能力，在此项目中全都有实现。

核心设计拆解