简介这是一套基于Java语言构建的开源LLMOps平台面向AI工程师、企业知识库开发者及RAG应用实践者聚焦大模型工作流编排与检索增强生成RAG场景解决多源知识集成、安全可控推理、高并发服务部署等核心问题适用于智能客服、企业内训知识库、学术研究辅助等中高阶AI工程化需求。资源包共1637个文件主体为616个Java后端模块含Spring Boot服务、向量检索适配器、工作流引擎实现、528个JS前端组件含Chat界面、知识库管理面板、流程可视化编辑器及100个CSS样式文件辅以SVG/woff等静态资源整体95.8MB结构完整、开箱即用。已有82人学习下载。读者可直接获取一套生产就绪的Java版RAG平台源码包含完整的知识库CRUD、LLM调用抽象层、多模型路由策略、权限控制模块及Docker部署配置代码规范、注释清晰便于二次开发与教学演示。1. 项目缘起为什么用Java重写一个LLMOps平台如果你最近在折腾大模型应用尤其是想搞个私有化的知识库问答或者自动化工作流大概率会听说过Dify、FastGPT这些名字。它们确实好用开箱即用让不懂代码的业务人员也能快速搭起一个AI应用。但用久了尤其是在企业级场景里你可能会遇到一些“成长的烦恼”比如当你的知识库文档量级上到百万级或者并发用户数开始爬升时平台的响应速度是不是有点力不从心了再比如你想深度定制一个复杂的审批流或者把AI能力无缝嵌入到已有的Java技术栈里是不是感觉有点隔靴搔痒总差那么点意思这就是我们启动这个项目的初衷。我们团队本身就是一个深度Java技术栈的团队从后端微服务到大数据处理Java是我们的看家本领。在尝试将LLM能力引入内部业务系统时我们评估了市面上几乎所有主流的开源LLMOps平台包括MaxKB、AIFlowy、Dify和FastGPT。它们的设计理念和快速原型能力让我们受益匪浅但在生产落地时我们遇到了几个核心痛点。首先是性能与稳定性。很多现有平台基于Python生态在I/O密集型任务和快速实验上优势明显但在处理高并发、长链路、需要复杂事务管理的企业级工作流时Java在内存管理、线程调度和JVM长期运行稳定性方面的优势就凸显出来了。我们遇到过因为Python的GIL全局解释器锁导致多线程处理向量化任务效率不高也遇到过在复杂DAG有向无环图工作流中状态管理和错误回滚机制不够健壮的情况。其次是安全与可控性。Java生态拥有成熟且经过大量企业级应用验证的安全框架、加密库和审计机制。当你的RAG系统里跑的是公司的核心知识资产或者LLM工作流处理的是敏感业务数据时从代码层面到运行时的安全可控就变得至关重要。Java严格的类型检查、强大的异常处理机制和丰富的监控工具链能让我们在架构设计之初就把安全考量嵌入进去。最后是技术栈的统一与深度集成。我们的后台服务、数据中台、权限体系都是Java系的。引入一个异构的技术栈意味着额外的运维成本、学习成本和潜在的集成风险。用Java重写意味着我们可以复用现有的Spring Cloud/Alibaba微服务架构、MyBatis-Plus数据访问层、Redis缓存、RocketMQ消息队列等一整套基础设施让LLM能力像普通服务一样被治理、被监控、被调度。所以这个项目不是一个从零开始的发明而是一次站在巨人肩膀上的“重构”与“增强”。我们深度借鉴了MaxKB在知识库管理上的简洁设计、AIFlowy在可视化工作流编排上的灵活性、Dify在应用构建上的开箱即用理念以及FastGPT在Prompt工程和模型调度上的实践。然后我们用Java这把“工业级”的锤子重新锻造了整个平台目标是打造一个高性能、高稳定性、安全可靠且能无缝融入Java企业技术体系的LLMOps平台。2. 核心架构设计如何用Java构建LLMOps的“发动机”一个LLMOps平台核心无外乎两件事管理模型LLM和组织知识RAG并在此基础上构建应用Workflow。我们的架构设计也紧紧围绕这三个核心展开并充分利用Java生态的优势。2.1 分层架构与模块解耦我们采用了经典的分层架构但每一层都针对LLM和RAG的特性做了强化。1. 基础设施层这是平台的基石。我们没有重复造轮子而是基于Spring Boot 3.x和Spring Cloud构建微服务骨架。服务注册与发现用Nacos配置中心用Apollo与Nacos二选一网关用Spring Cloud Gateway并集成了深度鉴权。消息队列用RocketMQ来处理异步的文档解析、向量化任务和工作流事件。缓存用Redis Cluster不仅缓存会话更重要的是缓存高频访问的向量索引片段和模型API的令牌。对象存储用MinIO用于存放上传的原始文档、图片等非结构化数据。这一整套对于Java开发者来说再熟悉不过运维团队也无需学习新工具。2. 核心能力层这一层封装了所有AI相关的原子能力。LLM Gateway模型网关这是关键模块。它统一了对接不同大模型厂商OpenAI、Azure OpenAI、 Anthropic、国内各大厂的API。Java的优势在这里体现为强大的HTTP客户端如WebClient配合Reactor实现响应式、连接池管理以及完善的重试、熔断、降级机制通过Resilience4j实现。网关还负责API密钥的轮转、用量统计和成本核算。Embedding Engine嵌入引擎负责将文本转换为向量。我们支持多种Embedding模型OpenAI text-embedding BGE Jina等并通过一个适配器模式统一接口。向量计算本身是CPU密集型我们利用Java的并行流Parallel Stream和Fork/Join池来加速本地模型的批量编码对于远程API调用则用异步非阻塞来提高吞吐。Vector Store向量数据库我们首选了Milvus因为它对云原生和分布式支持友好且有成熟的Java SDK。同时我们也支持PgVector集成在PostgreSQL中这对于已经使用PG且数据量不是特别巨大的团队来说可以简化技术栈。Java的JDBC和连接池如HikariCP让与PgVector的交互非常高效稳定。RAG PipelineRAG流水线这是一个可插拔的管道。文档进来后经过加载器支持PDF、Word、Excel、PPT、Markdown、HTML甚至爬虫分割器支持按字符、按标点、按语义分割这里我们集成了一些高质量的NLP分词库清洗器去无用标签、格式化然后送入Embedding Engine最后索引到Vector Store。每个环节都可以通过SPIService Provider Interface机制扩展。3. 应用编排层这是可视化构建AI应用的地方。我们借鉴了AIFlowy和Dify的思路但底层用Java实现了更强大的工作流引擎。可视化编排器前端基于React但后端暴露的是一系列标准的RESTful API。每个节点Node——比如“读取文件”、“调用LLM”、“条件判断”、“向量检索”——都是一个独立的Spring Bean有明确的输入/输出契约。工作流引擎核心是一个状态机State Machine。我们用Spring StateMachine来管理每个工作流实例的状态流转创建、运行、暂停、完成、失败。工作流的DAG有向无环图结构存储在数据库中引擎负责调度节点执行。Java的并发工具包如CompletableFuture和线程池被用来高效执行可并行的节点。更重要的是我们实现了事务补偿机制对于涉及数据库写操作和外部API调用的复杂工作流如果中途失败可以按照预定策略进行回滚或补偿这是企业级应用非常看重的特性。4. 管理与监控层基于Spring Boot Actuator、Micrometer和PrometheusGrafana我们搭建了完整的可观测性体系。不仅监控CPU、内存、JVM GC还定制了LLM特有的指标每个模型的平均响应延迟、令牌消耗速率、RAG检索的召回率与精度需要人工标注样本、工作流各节点的执行耗时分布等。日志方面用LogbackELK栈确保每个请求、每次检索、每次模型调用的全链路追踪。2.2 关键技术选型背后的思考为什么是这些技术这背后是我们在性能、稳定性和开发者体验之间的权衡。Spring Boot 3 Java 17这是现代Java开发的起点。Spring Boot 3对GraalVM原生镜像的更好支持为我们未来追求极致启动速度和内存占用留下了可能。Java 17的ZGC垃圾回收器对于需要长时间运行、处理大量内存中向量数据的服务来说能提供更低的停顿时间。响应式编程WebFlux在LLM Gateway和部分I/O密集的API中我们采用了Spring WebFlux。模型API调用通常是网络I/O瓶颈响应式非阻塞模型可以用少量线程处理大量并发请求显著提高资源利用率和吞吐量避免线程池被打满。但对于CPU密集的本地Embedding计算或复杂的业务逻辑我们仍然使用传统的命令式编程因为其调试和编写更直观。连接池与资源管理与向量数据库Milvus/PgVector、Redis、对象存储的交互我们都使用了经过优化的连接池。例如通过HikariCP配置合理的连接数和超时时间防止慢查询拖垮整个服务。对于Milvus我们管理gRPC连接的生命周期避免频繁创建销毁的开销。序列化与传输服务间内部通信使用Protobuf因为它比JSON更紧凑序列化/反序列化更快这对于传输可能包含大量向量float数组的消息至关重要。对外API则保持RESTful JSON便于前端和其他系统集成。这个架构设计的目标是让平台像一台精密的“发动机”每个模块各司其职又高效协同既能承受高负载的压力测试也能在出问题时快速定位到具体的“气缸”。3. RAG系统的Java实现从文档到答案的工业化流水线RAG检索增强生成是我们平台的核心能力之一。市面上很多教程和开源项目展示了RAG的基本原理但真正要在生产环境处理成千上万份格式各异的公司文档并保证检索的准、快、稳就需要一套工业级的实现。我们的Java实现可以看作是一条高度自动化的流水线。3.1 文档处理流水线的细节与挑战文档处理是RAG的“原料预处理”环节这里埋着很多坑。1. 文档加载与格式兼容我们基于Apache Tika作为核心解析器它几乎能处理所有常见的文档格式。但Tika本身比较重且在某些复杂格式如带有特殊图表或排版的PDF上解析效果不佳。我们的策略是分层解析对于PDF优先尝试使用PDFBox进行文本提取如果效果差提取出大量乱码或丢失结构则回退到调用外部服务如部署一个Python的pdfplumber或pymupdf微服务进行OCR或高级解析。Java通过HTTP客户端调用这个服务并做好超时和熔断。异步化与队列用户上传一个ZIP压缩包里面可能有几百个文件。同步处理会阻塞请求。我们的做法是文件上传至MinIO后立即向RocketMQ发送一个“文档处理任务”消息。由独立的消费者服务进行异步处理。这样前端可以立即返回“任务已提交”用户体验更好。2. 文本分割的艺术与科学分割策略直接决定检索质量。简单的按固定字符数分割会切断语义。递归分割我们实现了一个递归分割器。先尝试按最大长度如1000字符用标点。\n分割。如果分割后某一段还是太长再按更小的标点、或换行符进行二次分割。确保每个片段在语义上相对完整。语义分割的尝试我们实验性地集成了基于BERT等模型的中文语义分割但计算成本较高。目前作为可选的高级功能用户可以对法律合同、技术论文等对段落完整性要求高的文档启用。重叠窗口这是避免答案被“切碎”的关键技巧。每个文本块chunk尾部会带上下一个块开头的一部分如200字符作为重叠区。这样即使答案恰好落在分割边界检索时也能通过重叠部分关联到上下文。我们在存储时会标记每个块的原始文档ID、起始位置和重叠信息。3. 向量化与索引构建这是CPU/GPU密集型阶段。批量处理绝不一条文本调用一次Embedding API。我们的流水线会积累一定数量如100条或达到一定时间窗口的文本块批量发送给Embedding Engine。对于本地Embedding模型我们使用并行流处理。索引优化向量存入Milvus时索引类型的选择很重要。对于千万级以下的数据量IVF_FLAT倒排文件索引在精度和速度上平衡得很好。我们会根据向量维度如1024和数据集大小自动计算合适的nlist聚类中心数参数。索引构建本身也是异步任务。元数据关联除了向量每个块还存储丰富的元数据文档来源、文档类型、分割块ID、时间戳、甚至经过NER命名实体识别提取的关键实体。这些元数据可以在检索时用于混合搜索Hybrid Search即结合向量相似度和元数据过滤比如“只检索去年财务部门发布的PDF报告中关于‘云计算成本’的部分”。3.2 检索与重排让答案更精准检索不是简单的“最近邻搜索”我们实现了一个多阶段的检索管道。1. 第一轮向量检索与粗筛用户问题Query被向量化后在Milvus中进行相似度搜索如余弦相似度。我们会设置一个较高的初始召回数量top_k例如50。这一步的目标是“宁可错杀不可放过”先把可能相关的文档块都捞出来。2. 第二轮元数据过滤与混合搜索拿到50个候选块后应用元数据过滤器。例如用户可能在前端选择了“仅搜索产品手册”或“时间范围在2023年后”。我们利用Milvus的expr表达式功能在向量检索的同时就完成过滤效率更高。如果过滤器很复杂也可以在检索后于内存中过滤。3. 第三轮重排Re-ranking这是提升精度的杀手锏。粗筛出来的文档块可能只是字面上与问题相关但并非真正能回答问题。我们集成了一些轻量级但有效的重排模型如BGE-Reranker、Cohere Rerank API。重排模型的作用是更精细地判断“问题”和“文档块”之间的相关性并重新打分。Java中的实现调用本地重排模型ONNX Runtime部署或远程API。由于需要计算问题与每个候选块的相关性这是一个计算密集或网络I/O密集的操作。我们使用并行处理并设置超时避免个别慢请求拖累整体响应。重排后我们可能只保留Top 3-5个最相关的块。4. 上下文组装与提示词填充将Top N的文档块连同它们的元数据如来源文件名按照相关性分数排序组装成最终的“上下文”。这里有一个细节需要处理上下文长度限制。我们会累加文本块的长度确保总长度不超过LLM上下文窗口的预留部分为问题和答案留出空间。组装好的上下文被填入预设的Prompt模板中。我们的Prompt模板借鉴了Dify等平台的优秀实践但用Java的模板引擎如FreeMarker进行管理支持变量替换和条件逻辑。一个典型的模板如下你是一个专业的助手请严格根据以下提供的上下文信息来回答问题。如果上下文信息不足以回答问题请直接说“根据已知信息无法回答该问题”不要编造信息。 上下文信息 {{#contexts}} [来源{{metadata.fileName}}] {{content}} {{/contexts}} 问题{{query}} 请根据上下文回答3.3 避坑指南RAG实践中的血泪教训教训一分割长度不是固定的。对于技术文档可能600-800字符一个块效果更好对于会议纪要可能300-500字符更合适。我们在管理后台提供了“分割策略”配置允许用户按文档类型预定义。教训二Embedding模型的一致性。千万不能用模型A做向量化入库用模型B做查询向量化这会完全破坏向量空间的一致性导致检索失效。我们在系统里强制要求一个知识库绑定一个Embedding模型。教训三向量数据库的连接泄漏。Milvus的gRPC连接如果不及时关闭会导致服务端连接数爆满。我们为每个数据源配置了独立的连接池并在Spring Bean的生命周期PreDestroy中确保连接被正确关闭。教训四异步处理的幂等性。用户可能重复上传同一份文档或者处理任务因失败被重新投递。我们的文档处理服务需要是幂等的在开始处理前先计算文档内容的哈希值如MD5检查是否已处理过避免重复向量化消耗资源。4. LLM工作流引擎用Java StateMachine驱动复杂AI应用如果说RAG是“知识库问答”这种标准应用那么可视化工作流引擎就是打造自定义AI智能体Agent和复杂业务自动化的利器。我们的目标是把LLM能力变成一个个可拖拽、可编排的乐高积木。4.1 可视化编排与节点设计前端提供一个画布用户可以从左侧面板拖拽节点到画布上用连线表示数据流。后端的核心是定义好每个节点的“契约”。一个节点本质上是一个函数它有输入槽Input Slots定义这个节点需要哪些参数。可以是用户输入、上一个节点的输出或者是全局变量。输出槽Output Slots定义这个节点执行后会产生什么数据。执行逻辑Execute Logic用Java代码实现的核心功能。配置参数Configuration节点本身的设置比如“LLM调用节点”需要选择模型、设置温度temperature和最大令牌数。我们内置了几大类节点输入输出类文本输入、文件上传、HTTP请求调用外部API、变量设置。逻辑控制类条件判断if/else、循环for/while、并行执行。LLM核心类LLM调用支持聊天、补全、提示词模板内置丰富的模板库、函数调用OpenAI Function Calling。RAG类知识库检索、文档内容提取。数据处理类字符串处理拼接、截取、格式化、JSON路径提取、代码执行沙箱环境执行Python或JavaScript片段。工具类数据库查询通过JDBC、发送邮件、生成图表。每个节点都是一个Spring Bean通过一个统一的NodeExecutor接口来执行。当工作流引擎调度到某个节点时会从上下文中取出该节点需要的输入数据调用其execute方法然后将输出数据写回上下文供下游节点使用。4.2 工作流引擎的执行与状态管理这是最复杂的部分。如何可靠地执行一个可能包含条件分支、循环、并行甚至人工审批节点的DAG1. 工作流定义与实例化用户保存的可视化编排图会被持久化为一个JSON结构描述了节点和边。当用户触发一个工作流时引擎会根据这个JSON定义创建一个工作流实例Instance。这个实例拥有独立的状态、上下文变量和执行日志。2. 状态机驱动我们使用Spring StateMachine来定义工作流实例的生命周期状态CREATED已创建、RUNNING运行中、PAUSED已暂停、COMPLETED已完成、FAILED已失败、TERMINATED已终止。 状态之间的转换由事件触发例如START_EVENT、NODE_COMPLETE_EVENT、ERROR_EVENT。状态机确保了状态转换的合法性和原子性。3. 节点调度与执行引擎的核心是一个调度器。它从工作流实例的“就绪节点”列表初始时是所有没有前置依赖的节点中取出节点提交给一个线程池执行。顺序执行最简单A-B-C。并行执行如果A节点后面同时连向B和C且没有依赖关系调度器会将B和C都加入“就绪列表”它们可以被不同的线程同时执行。条件分支“条件判断”节点会根据其执行结果true/false动态地激活某一条分支下游的节点并禁用另一条分支。引擎需要更新后续节点的依赖关系。循环支持for each遍历一个列表和while条件循环。实现上循环体内部的节点会被“动态复制”多次每次迭代有独立的子上下文。这里需要仔细管理上下文变量的作用域避免污染。4. 上下文与变量作用域工作流上下文是一个分层的Map结构。有全局变量整个工作流实例可见也有节点局部变量。当进入一个循环或条件分支时会创建一个新的作用域scope继承父作用域的变量但本作用域内的修改变量不会影响父作用域。这类似于编程语言中的作用域链我们用栈Stack结构来实现。5. 错误处理与补偿这是企业级流程的必备。任何一个节点执行失败抛出异常工作流实例会进入FAILED状态。但我们提供了更精细的控制重试策略可以为节点配置重试次数和重试间隔指数退避。适合处理网络抖动等临时性错误。失败处理器Fallback当节点最终失败时可以执行一个预定义的“补偿节点”比如发送告警通知、记录错误日志到数据库、或者调用一个兜底的API。事务性补偿对于“更新数据库状态然后调用LLM”这样的组合操作如果LLM调用失败我们可能需要回滚数据库更新。我们通过“Saga模式”的简化版本来实现每个节点可以定义confirm和compensate方法。引擎按顺序执行节点的confirm如果全部成功则流程完成如果某个节点失败则引擎会倒序执行前面所有已成功节点的compensate方法进行回滚。4.3 一个实战案例智能客服工单分类与路由假设我们要构建一个工作流自动处理用户提交的客服工单先理解内容然后分类再根据紧急程度路由给不同的处理小组。节点1文本输入接收用户提交的工单文本。节点2LLM调用使用一个较小的、快速的模型如Qwen2-7B-Instruct进行意图识别和实体提取。Prompt是“请分析以下用户反馈提取关键问题、涉及的产品模块并判断紧急程度高、中、低。以JSON格式输出。”节点3条件判断根据上一步输出的紧急程度字段如果是“高”则走分支A否则走分支B。节点4-AHTTP请求分支A。调用内部告警系统的API发送钉钉/飞书群通知。节点5-A知识库检索同时在技术文档知识库中检索与该工单问题相关的解决方案。节点6-ALLM调用将检索到的解决方案和工单内容结合生成一份初步的处理建议。节点7-A变量设置将处理建议、紧急程度、分配小组设为“核心技术组”设置为全局变量。节点4-B知识库检索分支B。直接在知识库中检索。节点5-B条件判断判断知识库检索结果的相关性分数是否大于阈值比如0.8。节点6-B1LLM调用如果相关性高直接让LLM根据知识库内容生成回复给用户的答案。节点6-B2变量设置如果相关性低将分配小组设为“普通客服组”。节点8数据库操作无论哪个分支最后都将工单信息、分类结果、分配小组和处理建议如果有写入工单数据库状态标记为“待处理”。这个工作流包含了串行、并行、条件分支和外部系统调用展示了引擎的灵活性。全部通过拖拽配置完成无需编写代码。5. 性能、安全与部署让平台扛得住生产流量一个平台光有功能不够必须经得起实战考验。我们从设计之初就考虑了性能、安全和易部署性。5.1 性能优化实战JVM调优这是基础中的基础。我们为LLM服务定制了JVM参数。堆内存-Xmx设置得足够大以容纳向量缓存和模型对象但避免过大导致GC停顿时间长。使用G1或ZGC垃圾回收器并设置合理的预期停顿时间目标-XX:MaxGCPauseMillis。启用Native Memory Tracking监控堆外内存使用防止Netty、gRPC等框架造成的内存泄漏。向量检索优化索引预热服务启动时后台线程异步加载常用知识库的向量索引元数据到内存避免第一次查询时冷启动延迟。查询缓存对于完全相同的用户问题Query其向量化和检索结果是固定的。我们用Redis缓存Query的MD5 - 检索结果的映射并设置合理的TTL。这能极大缓解高频重复问题对向量数据库的压力。分页与限流在RAG检索接口和LLM调用接口上我们基于用户或API密钥实施了严格的限流Rate Limiting防止恶意或意外的流量打垮服务。异步化与非阻塞所有文件上传、文档解析、向量化等耗时操作全部通过消息队列异步处理。LLM API调用、重排模型调用等网络I/O操作使用WebClient或异步HTTP客户端避免阻塞业务线程。工作流中可并行执行的节点调度器会将其分发到不同的线程执行充分利用多核CPU。数据库优化对核心的业务表如工作流定义、执行日志建立了合适的索引。对频繁访问但很少修改的数据如提示词模板、系统配置使用Redis进行缓存。使用连接池并监控慢SQL。5.2 安全加固策略安全是企业的生命线尤其在处理内部数据时。认证与授权集成企业现有的SSO如OAuth 2.0 / OIDC。平台内部实现基于RBAC角色-权限-资源的精细权限控制。例如可以控制某个用户组只能访问特定的知识库只能使用某些成本较低的模型只能创建和运行自己的工作流。数据安全传输加密全站HTTPS。静态加密存储在MinIO中的原始文档、数据库中的敏感配置如API Key都进行加密存储。API Key使用类似Vault的逻辑进行加密使用时在内存中解密。数据隔离通过数据库的租户字段tenant_id实现逻辑上的多租户数据隔离。确保A公司的数据绝不会被B公司看到。Prompt注入防护在将用户输入拼接到Prompt模板前进行基本的清洗和转义防止用户输入破坏Prompt结构或进行恶意指令。对于特别敏感的场景可以设置一个“审查节点”先用一个小模型对用户输入进行安全审查。审计日志所有关键操作——登录、文档上传、知识库查询、模型调用、工作流执行——都记录详细的审计日志包括操作人、时间、IP、具体动作和结果满足合规要求。5.3 部署与运维拥抱云原生我们提供多种部署方式但推荐容器化部署。Docker Compose开发/测试一个docker-compose.yml文件拉起所有依赖服务MySQL、Redis、MinIO、RocketMQ、Milvus单机版以及平台自身的多个微服务。最快5分钟就能在本地看到一个完整可用的环境。Kubernetes Helm Chart生产为生产环境提供了Helm Chart。可以灵活配置资源请求/限制、副本数、亲和性规则等。利用K8s的HPA水平自动扩缩容基于CPU/内存或自定义指标如QPS自动扩容应用实例。监控告警如前所述我们暴露了丰富的Prometheus指标。可以配置告警规则例如LLM API平均响应时间超过5秒、RAG检索错误率超过1%、JVM老年代内存使用率超过80%等及时通知运维人员。持续集成/持续部署项目本身提供了完整的Maven构建脚本和Dockerfile。可以轻松集成到企业的CI/CD流水线中实现自动化测试和发布。从一行代码到一个能扛住生产流量的服务我们通过这套架构和工程实践让基于Java的LLMOps平台不再是设想而是可以落地的现实。它可能没有Python原型开发那么快但在稳定性、性能和安全性的长跑中我们相信这是一个更值得信赖的选择。本文还有配套的精品资源点击获取