写在前面

 项目的起因是，在使用 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) ); }