Java 企业版已为 AI 时代做好准备

Java 企业版现已准备好迎接 AI。Jakarta EE 与 AI 提供商和框架集成，而 Jakarta Agentic AI 和 Jakarta EE 12 则进一步强化了这一点。

人工智能正在改变软件工程，影响着自动化、用户交互、数据分析和应用开发。开发人员正在评估其技术栈如何适应这些变化。对于企业环境中的 Java 开发人员而言，一个核心问题是 Java 企业生态系统是否为 AI 做好了准备。

简短的回答是：是的。您无需放弃 Java，也无需等待新平台即可构建支持 AI 的应用。Java 已经提供了成熟的 AI 库、模型提供商、API 和集成模式生态。Jakarta EE 提供了当下在生产级企业系统中部署这些技术所需的能力。

该生态正在演进，新的举措正在探索将 AI 概念完美集成到 Jakarta EE API 和编程模型之中。本文回顾了现有能力、Jakarta EE 在现代 AI 架构中的角色，以及潜在的未来发展方向。

AI 与软件工程

在软件工程中应用人工智能时，有必要区分 AI 在开发生命周期中的不同使用方式。AI 可以辅助文档编写、测试、代码审查、架构探索和代码生成。从架构上看，这些用途分为两类：使用 AI 开发软件，以及将 AI 集成到软件本身之中。

第一类，即 AI 辅助软件开发，目前最为常见。开发人员使用 AI 工具生成、解释、重构或测试代码。虽然这些工具可以提高生产力，但如果使用不当，缺乏适当的工程纪律，也会引入风险。上下文不足、未审查的代码，或缺乏架构约束的工具，都可能导致缺陷、安全问题、复杂性增加或设计不一致。AI 并不能取代工程团队，团队仍需负责有效使用它。

新的方法论正在涌现，以构建这种交互的结构。诸如”氛围编程”（vibe coding）之类的方法侧重于通过对话式 AI 进行快速开发，而”规范驱动开发”（Spec-Driven Development）则在代码生成前提供明确的需求、约束和上下文。基于智能体的工作流越来越多地使用包含指令、规范和 Markdown 文件的代码仓库，为编码智能体提供所需的上下文。这些方法并不需要放弃 Java；Java 项目已经可以采用这些技术。

第二类是将 AI 集成到应用本身之中，使 AI 成为应用运行时行为的一部分，而不仅仅是辅助开发人员。应用可能使用大语言模型（LLM）来分类信息、生成内容、提取结构化数据、检索知识、执行工具或在业务流程中做出决策。

这种结合带来了根本性的架构变化。传统的企业应用大多是确定性的：开发人员使用方法、条件、规则、工作流和状态变更来定义流程走向。在相同的输入和状态下，执行路径是可预测的。相比之下，支持 AI 的应用可能呈现动态执行模型，其中某些行为在运行时由 LLM 决定。

然而，并非每个支持 AI 的应用都应把控制权交给模型。在实践中，AI 架构存在一个自主性谱系。在一端，模型在严格受控的确定性工作流内运行。随着自主性增加，模型可以选择工具、规划步骤、评估结果，并协调更复杂的操作。

这一演进反映在”核心自主性模式”（Core Autonomy Patterns）中，该模式从确定性的有向无环图（DAG）工作流开始，逐步走向更自主的方法，如检索增强生成（RAG）、反思（reflection）、规划（planning）、ReAct、多智能体系统以及模型上下文协议（MCP）集成。随着灵活性的增加，可观测性、安全性、测试、治理、故障处理和控制等方面的架构责任也随之增加。

认识到这种区别对于评估 Jakarta EE 对 AI 的准备情况至关重要。第一类已经自然地与 Java 开发工具集成。第二类则凸显了企业平台的重要性：AI 应用仍然需要依赖注入、配置、REST API、持久化、消息传递、事务、安全性、可观测性、异步执行以及与外部系统的集成。这些正是 Jakarta EE 设计所要提供的能力。

Jakarta EE 与 AI 的现状

Java 和 Jakarta EE 已为 AI 时代做好准备。集成 AI 并不需要离开企业 Java 生态系统，也不需要等待新的规范。Jakarta EE 应用已经可以使用大语言模型（LLM）、将 AI 嵌入业务流程，并在更广泛的企业平台中运用这些能力。

这在实际应用中已经得到证明。例如，Skillwell Simulate 是一个基于 Jakarta EE 的平台，它与 AWS 服务集成，并使用 Amazon Bedrock 实现 AI 功能。这表明 Jakarta EE 应用可以在保留既有企业架构优势的同时，采用现代 AI 服务。

在最底层的抽象级别，应用可以直接使用 AI 提供商（如 OpenAI、Anthropic、Google 和 Amazon Bedrock）的 API 或 Java SDK 进行集成。这种方法可以完全访问提供商特有的功能，但会增加耦合。每个提供商使用不同的 API 模型、配置、格式、认证和功能。支持多个提供商会增加样板代码和复杂性。

企业开发人员对此类挑战并不陌生。不同的供应商和技术提供不同的能力，因此抽象层可以提供统一的编程模型。AI 集成现在也采用了类似的方法。

OmniHai 是一个面向 Jakarta EE 和 MicroProfile 应用的轻量级 Java AI 库。OmniHai 不要求使用每个供应商的 SDK，而是提供一致的 AIService 抽象，并直接与供应商的 REST API 通信。它目前支持 OpenAI、Anthropic、Google AI、xAI、Mistral、Meta AI、Azure OpenAI、OpenRouter、Hugging Face、Ollama 以及自定义提供商。

借助 CDI，可以直接将 AI 提供商注入 Jakarta EE 组件：

@Inject
@AI(provider = AIProvider.ANTHROPIC, apiKey = "your-anthropic-api-key")
private AIService claude;

应用与 AIService 交互，而非特定于提供商的 API。这使得跨提供商的聊天交互可以使用一致的编程模型：

String response = claude.chat(
   "Explain microservices",
   ChatOptions.newBuilder()
       .systemPrompt("You are a helpful software architect.")
       .temperature(0.5)
       .maxTokens(500)
       .build()
);

OmniHai 还通过相同的抽象支持异步和流式操作。

从概念上讲，这种方法类似于 Jakarta Persistence 中的 EntityManager 等抽象：应用使用通用 API，而实现细节保持隐藏。虽然并非完美的类比，但它说明了 OmniHai 在管理多个 AI 提供商方面的作用。

LangChain4j CDI 提供了更高级的编程模型。开发人员无需直接操作 AIService 对象，而是将 AI 服务定义为 Java 接口。LangChain4j CDI 会检测带有 @RegisterAIService 注解的接口，并将其实现作为 CDI Bean 提供。

例如：

@RegisterAIService
public interface AssistantService {

   @SystemMessage("You are a helpful assistant.")
   String chat(String userMessage);
}

开发人员无需编写实现类。基础设施会生成实现，并将接口连接到已配置的语言模型。生成的服务可以像其他 CDI Bean 一样被注入：

@Path("/assistant")
public class AssistantResource {

   @Inject
   AssistantService assistant;

   @GET
   @Path("/chat")
   public String chat(@QueryParam("message") String message) {
       return assistant.chat(message);
   }
}

这种编程模型对 Jakarta EE 开发人员来说会很熟悉。它类似于 Jakarta Data 中的仓库抽象，开发人员通过接口定义契约，基础设施提供实现。尽管技术解决的是不同需求，但这种模型减少了开发人员需要编写的基础设施代码量。

LangChain4j 的功能不止于基本模型调用。它提供超过 20 个 LLM 提供商的统一 API，并包含对工具、检索增强生成（RAG）、聊天记忆、结构化输出、智能体、嵌入存储及其他 AI 功能的抽象。支持的集成包括 Amazon Bedrock、Anthropic、Azure OpenAI、Google AI Gemini、OpenAI、Mistral、OCI Generative AI 等。

这些选项代表了不同的抽象层次：

• OmniHai 是一种轻量级模板式抽象，允许应用通过通用的 AIService 调用操作。
• LangChain4j CDI 在此基础上更进一步，提供了一种声明式的基于接口的模型，开发人员描述 AI 服务，基础设施提供其实现。

两种方法都能确保应用仍然是 Jakarta EE 应用。一旦 AI 能力以 CDI Bean 的形式可用，它就能与平台完美集成。REST 端点可以暴露它，Jakarta Persistence 或 Jakarta NoSQL 可以提供数据，Jakarta Security 可以保护其操作，Jakarta Messaging 可以触发异步工作流，其他 Jakarta EE API 则继续发挥各自作用。

问题已不再是 Jakarta EE 能否与 AI 集成；它已经能够了。当前关键的架构决策是所需抽象层次：是为最大控制权而直接集成提供商，是使用像 OmniHai 这样的轻量级通用 API，还是采用像 LangChain4j CDI 这样更丰富的 AI 编程模型。

Jakarta EE 与未来

Jakarta EE 已经支持 AI 集成，并且平台仍在继续演进。Jakarta EE 12 的重点是改进数据层，包括对 Jakarta Data、Jakarta Persistence、Jakarta NoSQL 以及新的 Jakarta Query 规范的更新。这些改进对于依赖企业数据、持久化、检索和上下文内容的 AI 应用尤为重要。

主要的 AI 专项举措是 Jakarta Agentic AI，它已经发布了首个里程碑版本。其目的不是取代 LangChain4j 或提供商 SDK，而是为使用 Jakarta EE 构建 AI 智能体提供标准的编程模型。

该规范定义了一小组概念，通过基于注解的方式来构建智能体工作流，从而极大简化开发人员的工作：

API	用途
@Agent	声明一个智能体类
@Trigger	定义工作流入口点
@Decision	决定工作流是否继续以及如何继续
@Action	定义工作流中的一个步骤
@Outcome	标记工作流结束
@HandleException	处理工作流内的异常
@WorkflowScoped	为每次工作流执行提供一个 CDI 上下文
LargeLanguageModel	可与 LLM 交互的可注入外观
Result	表示决策的结果

以下示例展示了一个简化的欺诈检测智能体，并说明了 Jakarta Agentic AI 如何与 Jakarta EE 编程模型集成。该智能体使用 LargeLanguageModel 外观进行 AI 交互，并利用 Jakarta Persistence 和 Jakarta NoSQL 访问企业数据。因此，AI 能力被纳入为应用的一部分，而非独立的编程环境。

@Agent
public class FraudDetectionAgent {

    @Inject
    LargeLanguageModel model;

    @Inject
    EntityManager entityManager;

    @Inject
    Template template;

    @Trigger
    private void handleTransaction(
            @Valid BankTransaction transaction) {
    }

    @Decision
    private Result checkFraud(BankTransaction transaction) {

        CustomerHistory history = template
            .find(CustomerHistory.class, transaction.customerId())
            .orElse(null);

        String output = model.query(
            """
            Analyze this transaction for potential fraud
            using the transaction and customer history.
            """,
            transaction,
            history);

        return new Result(isFraud(output), null);
    }

    @Action
    private void handleFraud(
            Fraud fraud,
            BankTransaction transaction) {

        if (fraud.isSerious()) {
            alertBankSecurity(fraud);
        }
    }

    @Outcome
    private void markTransaction(
            BankTransaction transaction) {

        BankTransaction managed =
            entityManager.merge(transaction);

        managed.markAsSuspect();
    }
}

结论

企业 Java 现在已为 AI 做好准备，Jakarta EE 已经支持这种集成。开发人员可以通过提供商 SDK、OmniHai 或 LangChain4j CDI 添加 AI 功能，同时继续利用 Jakarta EE 的特性进行持久化、安全、消息传递、事务、REST API 和企业数据管理。AI 是对现有平台的增强，是一种集成能力，而非要求替换平台。

该生态系统持续进步。Jakarta EE 12 增强了数据基础，Jakarta Agentic AI 正在引入一种结构化的编程模型，用于构建与平台无缝集成的智能体。Jakarta EE 现已为 AI 做好准备，并且随着平台的演进，其能力将不断提升。

【注】本文译自：Java Enterprise Is Already Ready for the AI Era