Jakarta EE已为AI做好准备——但别只信我的话
目录
-
企业级 Java 的过去、现在与未来——Ivar Grimstad（Eclipse 基金会） Jakarta EE 与 AI 的相遇：同一问题的三个视角
-
Jakarta EE 11 与 AI 结合：利用虚拟线程和 Jakarta Data 构建智能微服务——Luqman Saeed（Azul）
-
生产就绪的智能代理 AI：使用 Jakarta EE 和 MicroProfile 构建企业级 Java 系统——Kenji Kazumura（富士通） 打好基础
今年四月，我有幸参加了在布鲁塞尔举行的 Open Community Experience 2026（OCX 2026）——这是 Eclipse 基金会的旗舰级开源会议。与真正关心自己技术的人们同处一室（或几间会议室😉），总是令人愉悦。我的几位同事和朋友也在会上发言——看着他们展示倾注了大量心血的工作成果，是开源社区最美好的体验之一。
本文将五场我认为相得益彰的演讲汇总到一起。它们虽然主题各异，却共同讲述了一个关于企业级 Java 的现状、未来方向，以及在 2026 年用 Java 构建严肃软件意味着什么的故事。
Jakarta EE 的起源与未来
企业级 Java 的过去、现在与未来——Ivar Grimstad（Eclipse 基金会）
如果你想从 OCX26 的一场演讲开始，先了解全局再观看其他演讲，那么这一场不容错过。Ivar 完整追溯了从 J2EE 众所周知的痛苦复杂性，到 Spring 框架的诞生及其对平台本身的影响，直至如今 Jakarta EE 的发展轨迹。
他非常擅长解释为什么 Jakarta EE 会呈现出现在的面貌：每一次简化都有其历史背景，每一项规范都有其设计理由。他逐一讲解了 TCK 流程、平台配置文件（完整版、Web 版和核心版），以及 Jakarta EE 10 和 11 的关键新增内容——包括 Jakarta Data 和虚拟线程支持——随后转向 EE 12 路线图以及朝向 AI 标准化迈出的早期步伐。
Jakarta EE 与 AI 的相遇：同一问题的三个视角
接下来的三场演讲最好作为一个系列来理解。它们都提出了同一个问题的不同版本——如何负责任地将 AI 集成到企业级 Java 系统中？——但从不同角度、以略微不同的侧重进行探讨。
智能单体：用本地 AI 增强 Jakarta EE——Luqman Saeed（Azul）
Luqman 以一个我认为会引起所有关注当前企业 AI 采用方式的人共鸣的观点开场：你的 AI 策略中最大的风险也许不是模型本身——而是依赖关系。
目前大多数 AI 集成都建立在对托管模型的外部 API 调用之上。这意味着你的应用程序的智能……嗯，是租来的。你受制于他人的定价决策、速率限制、延迟、可用性，以及——在受监管行业中至关重要的——数据驻留约束。Luqman 的演讲是一次详细而实用的演示，展示了如何将这种智能“带回家”。
他所演示的技术栈完全是 Java 原生：CDI 用于依赖注入，LangChain4j 用于 AI 编排，PostgreSQL 搭配 pgvector 用于嵌入向量，Ollama 用于本地运行模型。他在应用程序内部构建了一个完整的检索增强生成（RAG）管道——使用你自己的数据、模型和基础设施。
Luqman 逐步介绍了四种递进模式：声明式 RAG 管道、包含决策逻辑的智能代理工作流、多代理编排，以及最后完全进程内推理（使用 Jlama）——在 JVM 内部直接运行模型，无需外部进程。每一步都要在便利性与控制力之间做出取舍，他坦诚地指出了各个阶段需要权衡的因素。
Jakarta EE 11 与 AI 结合：利用虚拟线程和 Jakarta Data 构建智能微服务——Luqman Saeed（Azul）
通过 Luqman 的第二场演讲，我们开始从单体架构转向微服务——并在此过程中突显 Jakarta EE 11 为构建 AI 赋能系统的团队提供了多么丰富的功能。
这里的核心架构举措是使用 Jakarta Data 仓库作为嵌入向量的持久化层。Luqman 并没有去寻求一个专门的向量数据库，而是将嵌入向量以字节数组的形式直接存储在 JPA 实体中，并用纯 Java 实现余弦相似度搜索。对于许多实际用例——数据量适中、且希望保持运维简洁性的场景——这是一种非常实用的方法，可以避免在验证你是否真正需要额外基础设施之前就增加复杂性。
这场演讲还出色地利用了 Jakarta Concurrency 3.1 的虚拟线程支持。嵌入生成和模型推理都是 I/O 密集型操作，结果就是构建了一个高度并发的系统，无需任何手动线程池管理。MicroProfile Config 负责处理运行时模型切换，因此你可以无需重新部署就能在不同模型提供商之间切换。
Luqman 诚实地指出了这种方法何时会达到极限。内存中的向量搜索……在某个节点之前没问题。嵌入式模型……在规模要求超过其承受能力之前也没问题。Luqman 清楚地指出了哪些信号应该促使你去使用专门的向量数据库或基于 GPU 的推理。这种诚实的指导——知道如何做，更知道何时该换一种做法——正是这场演讲既实用又富有价值的原因所在！
生产就绪的智能代理 AI：使用 Jakarta EE 和 MicroProfile 构建企业级 Java 系统——Kenji Kazumura（富士通）
如果说 Luqman 的演讲聚焦于架构和实现，那么 Kenji 的演讲则提出了一个更棘手的问题：将一个 AI 赋能系统真正投入生产，到底需要什么？
答案，事实证明，与分布式系统一直以来的要求相同：安全性、可观测性和事务一致性。Kenji 的观点是，Jakarta EE 和 MicroProfile 已经提供了你所需的大部分能力。
他所展示的参考架构是一个基于代理的系统，其中由一个主管代理协调专门的子代理，这些子代理通过 MCP 服务器与外部工具交互。他使用了 OpenID Connect 和 JWT 传播——标准的 MicroProfile 安全能力——确保即使代理之间层层委托，认证上下文也能在服务边界之间正确流动。
分布式 AI 工作流中的事务处理可能比较棘手：在可行之处使用本地 ACID 事务，而在无法使用的地方则采用补偿模式。可观测性通过 OpenTelemetry 实现，提供了跨整个代理交互链的端到端追踪，否则这个链条可能变得极不透明。
Kenji 介绍了 Jakarta Agentic AI——我之前写过这个项目——旨在标准化企业 Java 生态系统中的代理生命周期和集成模式。
这场演讲对于任何已经构建了 AI 概念验证、现在正在思考如何将其变为一个真正可以信赖的生产级系统的人来说，都极具价值。
打好基础
API = 一些 REST 和 HTTP，对吧？对吧？！——Rustam Mehmandarov（Miles）
前面三场演讲中，每一个 AI 赋能的服务都会暴露 API。每一个与其他服务通信的代理都是通过 API 进行的。Kenji 用 JWT 和 OpenID Connect 保护的每一个系统，都是在 API 边界上加以保护。如果构建在这些 API 之上的系统脆弱、版本不一致且文档不全，那么你的 AI 架构再精妙也无济于事。
Rustam 是我最喜欢的 Java 演讲者之一——他的演讲充满活力且风趣幽默，同时又充满了来自实践经验的实用示例和教训。这场演讲延续了这种风格，很好地提醒了我们在实际开发中 API 经常会出现哪些问题。他涵盖了 REST 理论与 REST 现实之间的差距、HTTP 状态码的广泛误用、版本管理策略常被低估的复杂性，以及废弃和生命周期管理的运维挑战。
如果说前面的 AI 演讲让你对即将构建的东西感到兴奋，那么 Rustam 的演讲则是一个很好的提醒：要把东西做好。
本文原载于 foojay。