写在前面
项目的起因是,在使用 SpringAi 1.0 的时候想要使用 Qwen 作为 ChatModel ,但发现 SpringAi 没有写对应的依赖,而且要用某一个 LLM 还要引用对应的依赖。后面就想自己抽象一层,能让 LLM 无缝接入,就开始看源码和 debug ,这样就有了初版。
后面看来几篇博文,表达的意思大概是现有的几款框架( LangChain 等)能够解决 80%的问题,但是剩下 20%是无法逾越的鸿沟,最终还是要深入底层修改 Prompt 等。所以要使用“搭积木”的方式搭建属于企业自身业务的框架。受此启发在 SpingAi 的基础上,搞了这么个项目。
地址:AgentBrick
✨ 核心亮点
-
LLM 的通用适配能力
-
基于 Spring AI 的 OpenAI 核心代码进行二次抽象,使得框架能够轻松适配不同厂商的 LLM (如 Qwen 、Kimi 、MiniMax 、ZhiPu 等)。
-
提供统一的
ChatModel接口,屏蔽底层实现差异,降低开发复杂度。@Bean(ChatModelConstants.KIMI_K2_CHAT_MODEL) public KimiChatModel kimiK2ChatModel(@Qualifier("kimiApi") AiCommonApi kimiApi){ return (KimiChatModel) LLMEnum.KIMI.genChatModel( KimiOptions.builder() .model(ChatModelEnum.KIMI_K2) .temperature(0.7) .maxTokens(8048) .build(), kimiApi ); }
-
-
积木式 Agent 构建
-
支持模块化搭建 Agent ,用户可以自由组合 Prompt 、Context 和 Tools 。
-
各个环节灵活搭配
- 上下层分离。项目中使用 Dify 的知识库检索,作为底层 RAG 检索能力。上层编写符合业务的 RAG 策略。各个层次可随时更换搭配。
- LLM 分离。可根据不同的 Agent 搭配不同的 LLM ,若出现更加符合 Agent 能力的 LLM 可随时更换,不影响业务代码。
- Prompt 分离。测试不同 Prompt 以寻找最符合 Agent 要求的 Prompt 。
-
编写符合业务逻辑的 Agent 架构
- 项目中使用开源项目OWL为例,使用 Agent 快速搭建。
@Bean(AgentConstants.RAG_AGENT) public RagAgent ragAgent(@Qualifier(ChatModelConstants.QWEN_3_PLUS_CHAT_MODEL) QwenChatModel qwenChatModel, RagTools ragTools){ return RagAgent.builder() .chatModel(qwenChatModel) .prompt(AgentPromptConstants.RAG_AGEMNT_SYSTEM_PROMPT) .tools(ragTools) .build(); } -
-
高效的数据查询与处理
- 基于 MyBatis-Plus 进行二次封装,提供更简洁、高效的数据库查询接口。
@Override public Map<Long,ChatRecordMsgJsonDto> queryMsg(List<Long> ids) { if (CollectionUtils.isEmpty(ids)){ return Map.of(); } return where(aiChatRecordMsgMapper) .in(BaseDO::getId, ids) .hasMap( BaseDO::getId, v-> JSONObject.parseObject(v.getMsgDetail().toString(),ChatRecordMsgJsonDto.class) ); }
🛠️ 技术架构
JDK21+Spring Ai 1.0+Spring Boot 3.4+PostgreSql+Redis7.x