Java 框架调用 LLM 可靠性对比：Spring AI 明显优于 LangChain4j
Consistent LLM Call Handling Across Java Frameworks: A Reference Implementation and Benchmark
Java 开发者看过来：论文实测 Spring AI 和 LangChain4j 调 LLM 谁更可靠，还给了套统一拦截方案，延迟只加几十微秒。
arXiv 论文提出六条款可靠性契约，衡量 Java 框架处理 LLM 调用失败、重试、等待与指标记录的表现。在 15 个失败场景测试中，Spring AI 2.0.1 默认配置满足契约 72/77 项，LangChain4j 1.21.0 仅 47/77 项，显式配置后也只达 51/83 项。作者把契约实现下沉到 HTTP 边界，用 725 行依赖 JDK 和 Micrometer 的核心代码分别适配 OkHttp、HttpClient 与 java.net.http，三个客户端统一后满足 90/91 项。该层对本地模型服务器的 700 次调用无误拒，中位延迟仅增加 32-217 微秒。
Consistent LLM Call Handling Across Java Frameworks: A Reference Implementation and Benchmark
Java applications reach large language models (LLMs) through an integration framework, and rely on it to handle a failing provider: to retry what can be retried and nothing else, to wait as long as the provider asks, never to present a truncated answer as complete, and to record each failure in the application's metrics. We state these expectations as a six-clause reliability contract and measure Spring AI 2.0.1 and LangChain4j 1.21.0 against it with a scripted OpenAI-compatible provider: fifteen failure scenarios, synchronous and streaming, three repetitions. LangChain4j meets it in 47 of 77 applicable cases with its defaults and in 51 of 83 when configured explicitly, Spring AI in 72 of 77 and 76 of 83; both deliver a stream that ended without its terminator as a complete answer. We then place one implementation of the contract beneath both frameworks, at the HTTP boundary - an OkHttp interceptor for Spring AI, an HttpClient for LangChain4j, and a java.net.http transport for code without a framework - sharing a 725-line core that depends only on the JDK and the Micrometer Observation API. With it, all three clients behave identically and meet the contract in 90 of 91 cases; the remaining case is a policy trade-off between retrying a hung provider and waiting for a slow first token. Against a local model server the layer rejected none of 700 calls, and it adds a median of 32-217 microseconds to a call.