现代 Web 应用正加速与大语言模型（LLMs）深度融合，构建超越传统问答场景的智能解决方案。为突破模型知识边界，增强上下文理解能力，开发者普遍采用多源数据集成策略，将 LLM 与搜索引擎、数据库、文件系统等外部资源互联。然而，异构数据源的协议差异与格式壁垒，往往导致集成复杂度激增，成为制约 AI 应用规模化落地的关键瓶颈。因此，Anthropic公司推出了模型上下文协议（Model Context Protocol, MCP），通过标准化接口为 AI 应用与外部数据源建立统一交互通道。这一协议体系不仅实现了数据获取与操作的规范化，更构建起可扩展的智能体开发框架，使开发者能够基于原生 LLM 能力快速构建复杂工作流。
最近DeepSeek开源了对openai-o1的第一代开源推理大模型：deepseek-r1，因其极低的成本和与openai-o1相当的性能引发了国内外的激烈讨论。DD在做独立产品的时候也一直都有用DeepSeek的API来实现一些功能，比如：TransDuck中的字幕翻译、视频翻译，效果也是非常不错的。但是，最近因为收到一些私有化的需求，所以对于API的调用就不可行了，不得不转向本地部署大模型，然后提供API的方式来实现。本文就针对这样的情况，尝试了一下使用 Ollama 在本地运行 DeepSeek-R1 并提供 API 服务，然用再使用Spring Boot + Spring AI 实现对 DeepSeek-R1 的调用，有类似需求或者感兴趣的小伙伴也可以根据下面的内容来实践。
最近把Spring Boot的版本升级到了3.3.5，突然发现一个问题：当使用Spring Data JPA自动生成表的时候，所产生的列顺序与Entity类中的变量顺序不一致了。比如，有一个下面这样的Entity：
@Data
@Entity(name = "t_config")
@EntityListeners(AuditingEntityListener.class)
public class Config {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Column(length = 20)
private String itemKey;
@Column(length = 200)
private String itemValue;
@Column(length = 200)
private String itemDesc;
@CreatedDate
private Date createTime;
@LastModifiedDate
private Date modifyTime;
}
为了构建生成式AI应用，需要完成两个部分：
就在昨晚，Spring AI发了个比较重要的更新。由于最近OpenAI推出了结构化输出的功能，可确保 AI 生成的响应严格遵守预定义的 JSON 模式。此功能显着提高了人工智能生成内容在现实应用中的可靠性和可用性。Spring AI 紧随其后，现在也可以对OpenAI的结构化输出完美支持了。
下图展示了本次扩展的实现结构，如果对于当前实现还不够满意，需要扩展的可以根据此图来着手理解分析进行下一步扩展工作。
JSON是我们编写API时候用于数据传递的常用格式，那么你是否知道JSON Schema呢？
在数据交换领域，JSON Schema 以其强大的标准化能力，为定义和规范 JSON 数据的结构与规则提供了有力支持。通过一系列精心设计的关键字，JSON Schema 能够详尽地描述数据的各项属性。然而，仅凭 JSON Schema 本身，尚不足以验证 JSON 实例是否严格遵循预设的模式。此时，JSON Schema 验证器的角色便显得尤为关键。这些验证器如同严格的检查官，确保每一个 JSON 文档都能忠实地反映出模式的定义。JSON Schema 验证器，作为实现 JSON Schema 规范的技术工具，其灵活的集成能力使得无论项目规模大小，都能轻松地将 JSON Schema 融入开发流程，从而提升数据处理的效率与准确性。
我有一个需求，需要从外部系统获取用户数据。我通过 WebClient 实现的，作为声明性 HTTP 客户端的一部分。
有趣的是，在新的浏览器标签页中打开应用程序后，第一次请求返回了“Connection reset by peer”错误。
这个问题通过禁用对外请求的 keep-alive 解决了。
改造前的代码：
@Configuration
public class HttpProxyConfiguration {
@Value("${tracker.url}")
private String trackerUrl;
@Bean
TrackerClient trackerClient(WebClient.Builder builder) {
var wc = builder.baseUrl(trackerUrl)
.build();
var wca = WebClientAdapter.forClient(wc);
return HttpServiceProxyFactory.builder()
.clientAdapter(wca)
.build()
.createClient(TrackerClient.class);
}
}
使用Spring Boot开发API的时候，读取请求参数是服务端编码中最基本的一项操作，Spring Boot中也提供了多种机制来满足不同的API设计要求。
接下来，就通过本文，为大家总结6种常用的请求参数读取方式。如果你发现自己知道的不到6种，那么赶紧来查漏补缺一下。如果你知道的不止6种，那么告诉大家，一起互相学习一下吧～
这是最最最最最最常用的一个了吧，用来加载URL中?之后的参数。
比如：这个请求/user?name=didispace 就可以如下面这样，使用@RequestParam来加载URL中的name参数
@Value注解相信很多Spring Boot的开发者都已经有接触了，通过使用该注解，我们可以快速的把配置信息加载到Spring的Bean中。
比如下面这样，就可以轻松的把配置文件中key为com.didispace.title配置信息加载到TestService中来使用
@Service
public class TestService {
@Value("${com.didispace.title}")
private String title;
}
当在 Spring Boot 应用程序中使用Spring Data JPA 进行数据库操作时，配置Schema名称是一种常见的做法。然而，在某些情况下，模式名称需要是动态的，可能会在应用程序运行时发生变化。比如：需要做数据隔离的SaaS应用。
所以，这篇博文将帮助您解决了在 Spring Boot 应用程序中如何设置动态 Schema。