Ragent AI 系统概述
作者:程序员马丁
Ragent AI —— 从 0 到 1 纯手工打造企业级 Agentic RAG,拒绝 Demo 玩具!AI 时代,助你拿个offer。
Ragent 是一个面向 Agentic RAG 演进的生产级 Java AI 应用平台,覆盖知识入库、问题理解、混合检索、模型调用、MCP 工具与后台运维。
- 混合检索:向量、关键词、知识图谱、联网搜索并行召回,支持去重、RRF 融合与 Rerank。
- 问题理解:支持查询词映射、问题重写与拆分、树形意图识别和多知识库路由。
- 模型与工具:支持模型档位、首包探测、熔断降级,以及 MCP 工具发现、提参与校验。
- 会话记忆:最近 N 轮消息结合持久化摘要,控制 Token 成本并保留关键上下文。
- 流量保护:Redis 公平排队与分布式并发控制,避免突发请求压垮模型服务。
- 知识闭环:提供可编排入库 Pipeline、远程刷新、回答溯源、用户反馈、Trace 和管理后台。

🤝 贡献
Ragent AI 仍在持续迭代中,欢迎参与共建,一起把项目打磨得更好。 感谢各位亦菲、彦祖们对 Ragent AI 的贡献:
为什么学习 AI 项目
AI 这波浪潮,Java 程序员已经躲不过去了。
不管你现在做的是业务系统还是中间件,面试的时候多多少少都会被问到 AI 相关的东西。RAG 是什么?Agent 怎么实现?用过 MCP 吗?这些问题越来越高频。可以说,AI 已经从加分项变成了必答题。
但说实话,对于大多数应用层的开发者来说,去死磕大模型的微调、蒸馏、Transformer 原理,性价比并不高。真正实用的,是掌握 RAG 和 Agent 这些应用层的东西——能落地、能出活、面试也能聊得起来。
1. 校招现状
简历上清一色的 CRUD 项目——商城、外卖、博客,面试官早就审美疲劳了。当别人还在写基于 SpringBoot 的 XX 管理系统时,你简历上有一个完整的 AI 项目,区分度直接拉满。而且大厂校招越来越看重候选人对新技术的敏感度,AI 项目能直接证明你的学习能力和技术视野。
2. 社招现状
2024 年以来,几乎所有技术团队都在往 AI 方向靠。很多公司已经把有 AI 相关经验写进了 JD 里。你可能 Java/Go 写得很溜,但面试官会问:你对 LLM 了解多少?RAG 做过没有?向量检索怎么实现的?答不上来,直接少了一个谈薪的筹码。
说白了,学 AI 项目的核心原因就三个:
- 简历差异化。同样是后端开发,有 AI 项目经验的简历通过率明显更高。不是因为 AI 多 神奇,而是它能证明你不只是在重复造轮子。
- 面试有东西聊。AI 项目涉及的技术栈足够深——Embedding、向量数据库、Prompt 工程、模型调用链路、检索策略……每一个点都能展开聊,比我用了 Redis 做缓存有意思得多。
- 实际工作用得上。AI 不是实验室里的玩具,企业已经在大规模落地了。现在学,是为了接下来三到五年的职业发展铺路。
3. 问题是,怎么学?
很多人跟着 B 站视频或者 GitHub 上的开源项目撸了一遍,以为自己懂了。结果面试一问深的,直接懵了。原因很简单:那些 Demo 级别的项目,和企业真正要用的东西,差距太大了。
还有些同学报了训练营,发现清一色是 Python。语言不熟、生态不通,学完感觉收获有限,回到 Java 这边还是不知道怎么下手。就算用 Spring AI 或者 LangChain4j,版本迭代太快,低版本功能缺,高版本升级约等于重写,也是一肚子苦水。
基于这些问题,我决定做一个 RAG 实战项目,名字叫 Ragent。
这个项目会覆盖市面上主流的 RAG 技术点,也会涉及 MCP、Agent 等场景。更重要的是,它不是我看了几篇文章拼凑出来的玩具——我在公司实际落地过 RAG 系统,解决过信息孤岛、知识检索、效率提升这些真实的业务问题。所以 Ragent 的复杂度,就是企业级项目该有的复杂度。
学完之后,你可以放心大胆地跟面试官讲:企业里就是这么做的。

项目开源地址
之前做拿个 offer 社群时,第一个业务系统 12306 选择了开源,收获了 1.5w+ Star,也得到了很多同学的认可和信任。这次 Ragent 作为社群在 AI 领域的第一个项目,同样选择开源——既然代码质量经得起检验,就没必要藏着掖着。
之所以选择开源,原因很简单:对项目质量足够自信。架构设计、代码实现、工程规范,每一行都经得起审视。不藏着掖着,好不好你 clone 下来自己看——目录结构、提交记录、注释规范,全是明牌。
市面上不少项目只敢放几张截图、讲几个概念,真正敢把代码全部摊开的并不多。Ragent 敢这么做,是因为前面讲的那些能力——多路检索、意图识别、模型容错、全链路追踪——不是 PPT 里的架构图,是你能跑起来、能断点调试、能逐行阅读的真实代码。
开源对你来说意味着什么:
- 源码即文档:想了解某个模块怎么实现的,直接翻代码,比任何教程都准确、都及时。
- 本地可调试:断点打到任意一行,跟着一次请求走完整个 RAG 链路,比看架构图理解得深十倍。
- 可参与贡献:发现 Bug 提 Issue,有优化思路提 PR。参与一个企业级 AI 开源项目,本身就是简历上的亮点。
- 持续迭代更新:项目会持续演进,Star 和 Watch 之后能第一时间获取新特性。
如果你觉得项目还不错,去 GitHub 点个 Star 支持一下,这是对开源作者最好的认可。
RAG 常见误区
市面上打着 RAG 旗号的项目不少,但很多要么是玩具级 Demo,要么是概念包装。在学之前,先把这几个误区理清楚,避免踩坑。

1. 调个 API 就算会 RAG 了
很多教程的套路是:调一下 OpenAI 的 Embedding 接口,往向量数据库里塞点数据,再用 LLM 生成答案——完事了。这顶多算跑通了一个 Demo,离会 RAG 差得远。
真正的 RAG 系统要考虑的问题多得多:文档怎么切分效果最好?检索召回率不够怎么办?多路召回怎么融合排序?幻觉怎么控制?这些才是面试官会追问的点。
跑通 Demo 和做出能上线的系统之间,差的不是代码量,是对每个环节的深入理解。
2. RAG 就是“检索 + 生成”两步走
Retrieval-Augmented Generation 这个名字确实容易让人觉得就是检索加生成。但实际工程中,一个能用的 RAG 系统至少涉及这些环节:
- 数据处理:PDF、Word、PPT、网页,格式五花八门,光是解析成干净文本就是一堆脏活。PDF 里的表格、扫描件、双栏排版,每一个都是坑。
- 分块策略:切太大检索不精准,切太小上下文丢失。按段落切、按固定字数切、按语义切,不同文档可能需要不同策略。
- 问题重写:用户问“报销咋整”,你拿这四个字去检索,效果能好吗?多轮对话里用户说“怎么申请”,不补上下文系统根本不知道在问啥。
- 意图识别:用户是想查知识库,还是要调用业务系统?是闲聊还是正经提问?走错了路,答案肯定不对。
- 检索策略:纯向量检索对精确匹配很弱,用户问一个订单号,向量检索可能完全找不到。混合检索怎么融合、top-k 选多少、要不要重排序,都是取舍。
- 会话记忆:20 轮对话全塞给模型?Token 成本扛不住。只带最近几轮?可能丢关键上下文。记忆的压缩、摘要、持久化,又是一套单独的机制。
每一环都有坑,每一环都值得深挖。面试的时候能把这些讲清楚,比背概念有用得多。
3. 用 OpenAI/LangChain 套一套就是企业级
OpenAI/LangChain 是个好工具,但直接拿来套壳不等于企业级。企业场景下要面对的是:
- 大规模文档的增量更新,不可能每次全量重建索引
- 多租户隔离和权限控制,不同部门看到的知识库不一样
- 高并发下的检索性能,模型调用的成本控制和容错
- 请求风控,防止用户套取敏感信息或恶意攻击
- 模型负载均衡,多供应商切换和降级策略
- 可观测性,效果监控和用户反馈收集
这些问题 OpenAI/LangChain 的 QuickStart 不会告诉你,但面试官和实际业务一定会考你。
4. 只关注模型,忽略工程能力
RAG 项目的核心竞争力不在于你用了多强的模型,而在于工程化能力。同样的模型,检索策略不同、Prompt 设计不同、分块粒度不同,最终效果可以天差地别。
举个例子:用户问“打印机墨盒怎么换”,文档里写的是“墨盒更换步骤”。关键词搜索直接匹配不上,但向量检索能理解它们是一回事。这背后是 Embedding 模型的选型、向量数据库的调优、检索结果的重排序——每一步都是工程决策,不是换个更贵的模型就能解决的。
面试中能把这些工程细节讲清楚的人,远比只会说“我用了 GPT-4”的人有说服力。
Ragent 核心设计
1. 技术架构
Ragent 采用前后端分离的模块化单体架构,后端按职责分为四个 Maven 模块:

| 模块 | 职责 |
|---|---|
framework | 统一响应与异常、认证上下文、幂等、分布式 ID、MQ 适配、Trace 与 SSE 等通用基础能力 |
infra-ai | Chat / Embedding / Rerank / VLM 模型客户端、模型档位、路由、首包探测、健康状态与降级 |
bootstrap | RAG 问答、知识库、入库 Pipeline、意图树、检索、会话、审计及管理端 API |
mcp-server | 基于 MCP Java SDK 的独立工具服务,内置天气、票务、销售与联网搜索示例 |
这个分层不是为了炫技,而是把业务编排、AI 供应商差异和通用基础设施隔离开。切换模型、向量库或对象存储时,核心问答流程不需要跟着重写。
技术栈选型:
| 层面 | 技术选型 |
|---|---|
| 后端框架 | Java 17、Spring Boot 3.5.7、MyBatis Plus |
| 前端框架 | React 18、Vite、TypeScript |
| 关系数据库 | PostgreSQL(当前全量脚本 22 张业务表) |
| 向量检索 | PostgreSQL + pgvector(默认)/ Milvus 2.6 |
| 关键词 / 图谱 | Elasticsearch(可选)/ LightRAG + Neo4j(可选) |
| 缓存与限流 | Redis + Redisson |
| 对象存储 | S3 兼容存储(RustFS / MinIO)或阿里云 OSS |
| 消息队列 | RocketMQ 5.x |
| 文档解析 | Apache Tika 3.2 |
| 模型供应商 | 百炼、SiliconFlow、AIHubMix、Ollama |
| MCP | MCP Java SDK,独立 Streamable HTTP Server |
| 认证与规范 | Sa-Token、Spotless |
2. RAG 核心流程
2.1 Ragent 链路
一次用户提问,在 Ragent 里经过的完整链路如下:

2.2 多路检索架构
检索是 RAG 系统的核心。Ragent 当前提供向量、Elasticsearch 关键词、LightRAG 知识图谱和 You.com 联网搜索四类通道,按配置启用后并行执行:

每个通道独立执行、互不影响,通过专用线程池并行调度。后处理链依次完成去重、加权 RRF 融合、Rerank 和元数据富化;召回预算、Rerank 候选池与最终上下文条数分段配置,并在启动时校验漏斗不变式。
2.3 模型路由与容错
生产环境不可能只依赖一个模型供应商,Ragent 的模型路由机制解决的就是这个问题:
关键设计:三态熔断器,用于保护系统不会持续调用已经故障的模型。
3. 文档入库流水线
文档从上传到可检索,经过一条基于节点编排的 Pipeline:
每个节点的配置存储在数据库中,支持条件执行和输出链式传递。每个任务和节点都有独立的执行日志,出了问题能精确定位到哪一步。
4. 关键设计模式
Ragent 不是为了用设计模式而用,每个模式都对应一个具体的工程问题:
| 设计方式 | 业务场景 | 解决的 问题 |
|---|---|---|
| 策略 | 检索通道、结果后处理、文档来源 | 不同实现可独立替换 |
| 工厂 | 意图树、分块策略、流式回调创建 | 集中复杂对象的创建逻辑 |
| 模板方法 | 并行检索、模型请求 | 固定通用流程,仅开放差异步骤 |
| 注册表 | MCP 工具发现、意图节点管理 | 统一注册、查找和调用组件 |
| 装饰器 | 向量写入时同步关键词和图谱索引 | 在不修改主流程的前提下增强能力 |
| 责任链 | 检索后处理、模型故障降级 | 按顺序组合处理步骤 |
| 事件回调 | 模型流式响应、首包探测、SSE 输出 | 解耦事件生产与消费 |
| AOP | 链路追踪、幂等、审计日志 | 将横切逻辑与业务解耦 |
5. 核心能力
具体来说,Ragent 包含以下核心能力:
- 混合检索引擎:向量、关键词、知识图谱、联网搜索按配置并行执行,经过 ID / 内容摘要去重、加权 RRF、候选池截断、Rerank 与元数据富 化。
- 意图识别与引导:树形多级意图支持关联多个知识库,置信度不足时主动引导用户澄清,而不是硬猜一个答案。
- 问题重写与拆分:多轮对话中自动补全上下文,复杂问题拆分为多个子问题分别检索,解决用户说的不是他想问的这个核心痛点。
- 会话记忆管理:保留最近 N 轮对话,超过阈值自动摘要压缩,既控制 Token 成本,又不丢关键上下文。
- 模型路由与容错:模型档位、多候选路由、首包探测、健康检查、三态熔断与自动降级切换。
- MCP 工具集成:独立 MCP Server,客户端自动发现远程工具;模型提参经过三态校验后调用对应工具。
- 文档入库流水线:文档获取、解析、增强、分块、富化、索引组成数据库驱动的 Pipeline,每一步可配置、可扩展、有日志。
- 全链路追踪与审计:问答各环节记录 Trace;后台配置变更保存前后快照和字段 Diff,便于排障与追责。
- 产品闭环:答案保存来源与 Grounding Chunk,支持原文预览、推荐追问、反馈和完整 React 管理后台。
一句话总结:Ragent 是一套可以直接运行、调试和继续扩展的 Java AI 应用工程参考。
项目质量怎么样?
以下数据按当前仓库统计,代码行数包含注释和空行。
1. 规模与完整度
- 后端:4 个 Maven 模块,约 5.6 万行 Java 主代码、553 个主代码文件。
- 前端:约 2.75 万行代码、27 个页面级 TSX 文件。
- 数据与测试:22 张业务表、30 个 Java 测试文件、84 个
@Test测试点。
2. 工程质量
- 模块边界:通用基础设施、AI 能力、RAG 业务和 MCP 服务相互隔离,替换模型或存储实现不会侵入问答编排。
- 配置防错:模型档位、候选能力和检索漏斗在启动阶段完成一致性校验,错误配置直接失败而不是静默降质。
- 并发治理:10 个专用线程池隔离负载,TTL 保证用户与 Trace 上下文跨线程传递。
- 关键路径测试:30 个测试文件、84 个测试点,覆盖模型路由、检索预算、结果去重、会话摘要、入库 Pipeline 和 MCP。
- 工程约束:统一响应、错误码和异常处理,认证、幂等、线程安全 SSE 与 Spotless 格式化均已落到代码。
项目中大量应用并发线程,建议配合社群里的 oneThread 动态线程池框架 搭配学习收获更多。
3. 可扩展性
核心能力通过接口、注册表和配置隔离,新增实现可以复用现有编排、容错 、日志和管理能力:
| 扩展维度 | 如何接入 | 接入后的效果 |
|---|---|---|
| 模型 | 实现 ChatClient / EmbeddingClient / RerankClient,加入模型候选配置 | 新供应商可进入模型档位与候选路由,复用首包探测、健康检查和熔断降级 |
| 存储 | 实现向量存取或 ObjectStorageClient,通过配置选择实现 | 可替换向量库或对象存储,知识入库与问答主流程保持不变 |
| 检索 | 实现 SearchChannel 或后处理器,注册为 Spring Bean 并设置顺序 | 新通道参与并行召回,新处理器可插入去重、融合、精排与富化链路 |
| 入库 | 实现 IngestionNode 或 DocumentFetcher,补充节点类型和配置 | 新处理步骤或文档来源进入 Pipeline,继续使用任务状态、节点日志和失败定位 |
| MCP | 暴露 MCP 工具规范,或在客户端配置外部 MCP Server | 工具可被远程发现,并复用参数提取、Schema 校验与调用流程 |
扩展的改动主要收敛在新实现和配置中,不必复制一套检索、会话或 Trace 主链路。