1. 项目概述：Java 开发者的 AI Agent 新战场

最近和几个做 Python 后端的朋友聊天，他们聊起 LangChain、AutoGPT 这些 AI Agent 框架时眉飞色舞，仿佛打开了新世界的大门。作为 Java 技术栈的坚定拥护者，我当时心里就有点不服气：难道构建智能体、玩转大模型，就只能是 Python 的天下？Java 庞大的生态和成熟的企业级架构，在 AI 应用落地上就真的没有用武之地吗？

带着这股“较劲”的心态，我花了近两个月的时间，深入调研和实战了目前市面上主流的、面向 Java 开发者的 AI Agent 框架。我发现，情况远比想象中乐观。一个属于 Java 开发者的 AI Agent 生态正在快速成型，它并非 Python 生态的简单复制，而是结合了 Java 自身在并发、稳定性、工程化方面的优势，走出了另一条务实、高效的路径。这篇文章，就是我这段时间的“探险”总结。我将为你系统梳理四大核心框架，从技术选型、核心概念解读，到一步步的实战搭建，最后分享那些只有踩过坑才知道的调优技巧。无论你是想快速给现有系统增加智能问答能力，还是计划从零构建一个复杂的多智能体协作系统，这篇指南都能给你提供清晰的路线图。

2. 四大框架全景解析与选型决策

面对一个新兴领域，选对工具是成功的一半。Java 的 AI Agent 生态目前呈现出“多点开花”的态势，各有侧重。盲目跟风某个“最火”的项目，很可能导致后期陷入架构不适配的困境。我的选型逻辑是：先看核心设计理念是否与你的业务场景匹配，再看其与现有 Java 技术栈的融合度，最后评估其社区活力和学习成本。

2.1 LangChain4j：生态连接器的首选

如果你对 Python 的 LangChain 有所耳闻，那么 LangChain4j 会让你感到非常亲切。它并非官方移植，而是一个受 LangChain 启发，专为 Java 打造的同类项目。它的核心定位是“胶水”和“组件库”，将大模型、向量数据库、工具调用、记忆管理等能力抽象成标准的接口和组件。

为什么选择它？

• 设计理念熟悉：如果你或你的团队已经理解 LangChain 的 Chains、Agents、Tools 等概念，迁移到 LangChain4j 的学习成本极低。它的 API 设计力求直观。
• 集成度极高：它提供了对主流模型（OpenAI、Azure OpenAI、Ollama 本地模型、通义千问、DeepSeek等）、向量库（Redis、PgVector、Milvus、Chroma）、文档加载器（PDF、Word、HTML）的开箱即用支持。你要做的 often 就是引入一个依赖，配置一个 API Key。
• 轻量灵活：它不强求你使用一整套框架，你可以像搭积木一样，只使用它的“文档加载-分割-向量化-检索”链，或者只使用它的工具调用模块，与你的 Spring Boot 应用无缝集成。

适合场景：快速构建基于文档的 RAG（检索增强生成）问答系统、为现有应用添加一个智能客服入口、需要连接多种异构 AI 服务和数据源的场景。它适合作为你 AI 能力的“基础设施库”来使用。

一个简单的依赖引入示例：

<dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-open-ai</artifactId> <version>0.31.0</version> </dependency> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-spring-boot-starter</artifactId> <!-- 与Spring Boot集成 --> <version>0.31.0</version> </dependency>

2.2 Spring AI：Spring 生态的“亲儿子”

如果说 LangChain4j 是优秀的社区作品，那么 Spring AI 就是 Spring 官方钦定的 AI 集成方案。它的野心更大，旨在将 AI 能力作为一等公民融入整个 Spring 生态系统。它的核心是提供一套统一的AiClient、AiStreamClient、VectorStore等抽象接口，背后通过不同的Connection来实现具体模型或服务的对接。

为什么选择它？

• Spring 原生体验：如果你已经是 Spring/Spring Boot 的重度用户，那么 Spring AI 会让你感觉无比顺畅。它完全遵循 Spring 的配置习惯（application.yml）、依赖注入、自动装配等理念，几乎没有额外的学习负担。
• 声明式编程：通过@PromptTemplate注解、AiClient调用等方式，编写 AI 交互代码就像调用一个普通的 Service 方法一样简单、清晰。
• 强大的生态整合：它能轻松与 Spring Data、Spring Integration、Spring Batch 等现有项目结合。例如，你可以用 Spring Batch 处理海量文档并存入向量库，用 Spring Integration 编排复杂的 AI 工作流。
• 官方背书与长期支持：作为 Spring 官方项目，其版本迭代、安全更新和长期维护性更值得信赖，适合用于对稳定性要求高的企业级项目。

适合场景：所有基于 Spring 技术栈的新老项目。特别是当 AI 功能需要深度融入现有业务逻辑、与数据库事务交互、或者需要利用 Spring 的各类企业级特性（如安全、监控、消息队列）时，Spring AI 是不二之选。

2.3 Haystack：来自深度求索的“重型武器”

Haystack 本身是一个用 Python 编写的、非常强大的端到端 NLP 框架。而其 Java 版本，可以看作是它的一个客户端或部分核心能力的移植。它的强项在于构建复杂、可解释的、生产级的问答、检索和摘要系统。

为什么选择它？

• 流水线（Pipeline）设计：Haystack 的核心是清晰定义的 Pipeline，将文档检索、候选排序、答案生成等步骤模块化。这种设计使得整个流程的调试、监控和替换组件变得非常容易，特别适合对流程可控性要求高的场景。
• 专注于搜索与问答：它在语义搜索、多轮问答、答案证据提取等方面功能深厚，提供了比简单 RAG 更精细的控制能力，比如可以返回检索到的原文片段作为答案依据。
• 可解释性强：由于流程清晰，你可以很容易地追踪到一个答案是由哪篇文档的哪个片段生成的，这对于很多合规、审计要求严格的领域（如金融、法律）至关重要。

适合场景：构建企业级知识库、智能搜索引擎、需要对答案生成过程有完全掌控和可解释性的专业领域问答系统。如果你的需求超越了简单的“一问一答”，涉及多步推理、混合检索（关键词+向量），Haystack 值得深入研究。

2.4 J-Agent：轻量级自主智能体框架

前面三个框架更多侧重于“工具调用”和“流程编排”，而 J-Agent（以及类似项目如 LangChain4j 的自主代理模式）则更贴近“Agent”的本意——自主感知、规划、执行、反思的智能体。它通常包含一个核心的“大脑”（LLM）和一个可扩展的“工具集”，并能根据目标自主规划步骤。

为什么选择它？

• 真正的自主性：你可以给它一个目标，比如“帮我分析一下上周的销售数据，并写一份总结报告”，它会自动分解任务：调用数据库工具查询数据、调用数据分析工具生成图表、调用文本生成工具撰写报告。
• 适用于复杂任务：对于需要多个步骤、条件判断、甚至试错才能完成的任务，自主 Agent 框架比固定的 Chain 更灵活、更强大。
• 研究与实践的前沿：使用这类框架，你能更深入地理解 ReAct（Reasoning + Acting）、Chain of Thought 等 Agent 核心范式，是迈向更高级 AI 应用的关键一步。

适合场景：自动化工作流（如自动处理客服工单、生成个性化营销内容）、复杂数据分析与报告生成、作为多智能体系统（Multi-Agent System）中的单个智能体单元。它适合探索性项目和需要高度自动化的场景。

选型决策速查表：

需求特征	推荐框架	关键理由
快速验证、需要连接多种AI服务	LangChain4j	组件丰富，集成快速，学习曲线平缓
深度集成 Spring 生态的企业级应用	Spring AI	原生 Spring 体验，配置管理强，长期支持好
高可控、可解释的复杂问答与搜索系统	Haystack (Java版)	流水线设计清晰，调试监控方便，答案可溯源
构建能自主规划执行复杂任务的智能体	J-Agent或LangChain4j 自主代理	支持目标分解、工具自动调用，自主性强

3. 核心概念拆解：跨越 Python 到 Java 的思维转换

直接从 Python 的例子照搬到 Java，往往会水土不服。Java 在并发模型、内存管理、工程结构上与 Python 有显著差异，理解这些差异背后的核心概念，才能写出地道、高效的 Java AI 应用。

3.1 提示词工程：从字符串拼接走向模板化与结构化

在 Python 脚本里，你可能习惯用 f-string 来拼接提示词。在 Java 企业级开发中，我们需要更结构化的方式。

1. 模板引擎集成： 不要手动拼接字符串。利用 Thymeleaf、FreeMarker 甚至 Spring AI 自带的@PromptTemplate，将提示词模板化、外部化。例如，将模板放在resources/templates/prompts/目录下，根据不同场景加载。这样做的好处是：

• 维护性：非开发人员（如产品经理）也能在不动代码的情况下调整提示词。
• 复用性：相同的逻辑模板可以应用于不同的数据。
• 版本控制：提示词模板可以和代码一样进行版本管理。

2. 提示词即配置： 在application.yml中定义你的提示词模板，利用 Spring 的配置注入能力。

ai: prompts: customer-service: | 你是一个专业的客服助手。请根据以下用户问题和相关知识库内容，用友好、专业的口吻回答。 用户问题：{question} 知识库内容：{context} 请仅根据知识库内容回答，如果知识库中没有相关信息，请如实告知“我暂时无法回答这个问题，已记录您的需求”。

然后在你的 Service 中通过@Value注入并使用。这种方式让提示词管理变得清晰、集中。

3.2 工具调用：将 Java 方法暴露给 AI

这是 Agent 能力的核心。在 Python 中，可能用一个@tool装饰器就搞定了。在 Java 中，我们需要更明确的定义。

以 Spring AI 为例，定义一个“获取天气”的工具：

1. 定义工具接口和实现：这实际上就是一个普通的 Spring Bean。

   @Component public class WeatherService { @Tool(name = "getWeather", description = "根据城市名称获取当前天气情况") public String getWeather(@Param(“城市名称，例如：北京、上海”) String city) { // 这里调用真实的气象API，例如和风天气、OpenWeatherMap // 模拟返回 return String.format("%s的天气是晴，温度25摄氏度。", city); } }

2. 关键点：
   • @Tool注解标记这是一个可被 AI 调用的工具。
   • name和description至关重要，AI 模型根据这些描述来决定是否以及如何调用该工具。
   • @Param注解用于描述参数，帮助模型理解需要提供什么信息。
   • 这个 Bean 会被 Spring AI 自动扫描并注册到上下文中，供 AI 模型在需要时调用。

工具设计的经验：

• 工具要单一职责：一个工具只做一件事。getUserInfo和updateUserEmail应该分成两个工具。
• 描述要精确：description和@Param的描述语是 AI 理解工具的“说明书”，要清晰、无歧义。可以多花时间打磨这里。
• 做好异常处理：工具方法内部必须有健壮的异常处理，并返回对 AI 友好的错误信息，而不是抛出异常导致整个 Agent 崩溃。

3.3 记忆与上下文管理：超越简单的对话列表

简单的聊天场景，或许只需要一个List<ChatMessage>。但真正的 Agent 往往需要处理更复杂的上下文。

1. 短期记忆（对话记忆）： 通常指当前会话的上下文。Spring AI 和 LangChain4j 都提供了ChatMemory抽象。你需要关注：

• 窗口大小：保存最近多少轮对话？是固定轮数还是基于 Token 数？这直接关系到 API 调用成本和模型的有效上下文长度。
• 记忆存储：默认是内存存储，但在分布式或需要持久化的场景下，你需要将其存储到 Redis 或数据库中。这涉及到序列化问题，确保你的ChatMessage对象能被正确序列化/反序列化。

2. 长期记忆（向量存储）： 这是 RAG 的基石。其核心流程是：文档加载 -> 文本分割 -> 向量化（Embedding）-> 存储 -> 检索。

• 文本分割策略：这是最容易忽视但影响巨大的环节。不要简单按固定字符数分割。
  • 递归字符分割：尝试按段落、句子、甚至单词递归分割，直到达到设定的大小。这能更好地保持语义完整性。
  • 基于标记器的分割：使用与 LLM 相同的标记器（Tokenizer）来分割，能精确控制输入模型的 Token 数量，避免意外截断。
  • 重叠分割：在分割的片段之间保留一部分重叠文本，可以提高检索时召回相关上下文的概率。
• 向量模型的选择：Embedding 模型的质量决定了检索的准确性。除了通用的text-embedding-ada-002，可以针对中文场景测试BGE、M3E等模型。关键点：检索用的 Embedding 模型和生成回答的 LLM 的“理解能力”最好在同一个语义空间，但这通常难以保证，所以选择一个在基准测试中表现好的通用或领域模型是关键。

4. 实战构建：一个基于 Spring AI 的智能客服 Agent

理论说再多，不如动手做一遍。我们以最常见的“智能客服”场景为例，使用Spring AI框架，构建一个具备知识库检索和工具调用能力的 Agent。

4.1 项目初始化与环境配置

首先，使用 Spring Initializr 创建一个新的 Spring Boot 3.x 项目，添加以下依赖：

• Spring Web(用于提供 REST API)
• Spring AI(核心依赖)
• 根据你选择的模型，添加对应的连接器，例如Spring AI OpenAI或Spring AI Ollama。
• Spring Data Redis(如果我们用 Redis 作为向量存储和缓存)

在application.yml中进行关键配置：

spring: ai: openai: api-key: ${OPENAI_API_KEY:你的密钥} # 建议使用环境变量 chat: options: model: gpt-4o-mini # 根据实际情况选择模型 temperature: 0.7 vectorstore: redis: # 配置Redis向量存储 uri: redis://localhost:6379 index: customer-service-index

4.2 知识库构建与向量化存储

假设我们有一系列客服 FAQ 的 Markdown 文档存放在src/main/resources/knowledge/下。

1. 创建文档加载与处理服务：

   @Service public class KnowledgeBaseService { @Autowired private VectorStore vectorStore; @Autowired private EmbeddingModel embeddingModel; // Spring AI 会自动注入 @PostConstruct public void initKnowledgeBase() throws IOException { // 1. 加载文档 List<Document> documents = new ArrayList<>(); Path knowledgePath = Paths.get(ClassLoader.getSystemResource("knowledge").toURI()); Files.walk(knowledgePath) .filter(Files::isRegularFile) .forEach(file -> { try { String content = Files.readString(file); // 简单处理，可替换为更复杂的解析器（如解析Markdown元数据） Document doc = new Document(content, Map.of("source", file.getFileName().toString())); documents.add(doc); } catch (IOException e) { log.error("Failed to load file: {}", file, e); } }); // 2. 文本分割（这里使用简单的递归字符分割） TextSplitter splitter = new RecursiveCharacterTextSplitter(500, 50); // 块大小500，重叠50 List<Document> splitDocuments = splitter.split(documents); // 3. 向量化并存储 vectorStore.add(splitDocuments.stream() .map(doc -> new Embedding(doc.getContent(), embeddingModel.embed(doc.getContent()))) .collect(Collectors.toList())); log.info("Knowledge base initialized with {} document chunks.", splitDocuments.size()); } }

   注意：@PostConstruct初始化只适合小型或启动时加载的知识库。对于大规模或动态更新的知识库，你需要设计增量更新和后台索引任务。

2. 创建检索服务：

   @Service public class RetrievalService { @Autowired private VectorStore vectorStore; @Autowired private EmbeddingModel embeddingModel; public List<Document> retrieveRelevantContext(String query, int topK) { // 将用户查询向量化 Embedding queryEmbedding = embeddingModel.embed(query); // 从向量库中检索最相似的 topK 个片段 List<EmbeddingMatch<Document>> matches = vectorStore.similaritySearch(queryEmbedding, topK); return matches.stream().map(EmbeddingMatch::getEmbedded).collect(Collectors.toList()); } }

4.3 定义客服工具

除了知识库，我们的客服 Agent 还需要能执行具体操作，比如查询订单、提交工单。

@Component public class CustomerSupportTools { @Autowired private OrderRepository orderRepository; // 假设的订单数据访问层 @Autowired private TicketService ticketService; // 假设的工单服务 @Tool(name = “查询订单状态”， description = “根据用户提供的订单号，查询该订单的当前状态、物流信息等”) public String queryOrderStatus(@Param(“订单号，通常是一串数字或字母组合”) String orderId) { Order order = orderRepository.findByOrderId(orderId); if (order == null) { return “未找到订单号：” + orderId; } return String.format(“订单[%s]状态：%s，物流信息：%s”， orderId, order.getStatus(), order.getShippingInfo()); } @Tool(name = “创建客服工单”， description = “当用户遇到无法解决的问题时，创建一个新的客服工单，需要提供问题摘要和联系方式”) public String createSupportTicket(@Param(“问题的简要描述”) String issueSummary, @Param(“用户的联系方式，如邮箱或电话”) String contactInfo) { String ticketId = ticketService.createTicket(issueSummary, contactInfo); return String.format(“已为您创建工单，编号：%s。客服人员将在24小时内通过%s与您联系。”， ticketId, contactInfo); } }

4.4 组装智能客服 Agent

现在，我们将知识库检索和工具调用结合起来，创建最终的 Agent 服务。

@Service public class CustomerSupportAgentService { @Autowired private AiClient aiClient; // Spring AI 的通用客户端 @Autowired private RetrievalService retrievalService; // Spring AI 会自动将所有 @Tool 注解的 Bean 注入到 ToolCalling 相关的功能中 public String handleUserQuery(String sessionId, String userQuery) { // 1. 检索相关知识 List<Document> relevantDocs = retrievalService.retrieveRelevantContext(userQuery, 3); String context = relevantDocs.stream() .map(Document::getContent) .collect(Collectors.joining(“\n\n---\n\n”)); // 2. 构建系统提示词，定义 Agent 的角色和能力 String systemPrompt = “”” 你是一个专业的电商客服助手。你的职责是： 1. 首先，基于提供的“相关知识”来回答用户关于产品、政策、流程的常见问题。 2. 如果“相关知识”不足以回答，或者用户需要执行具体操作（如查订单、创建工单），请果断调用你拥有的工具。 3. 调用工具时，必须严格按照工具描述的要求提供参数。 4. 回答需友好、简洁、专业。 相关知识： %s “””.formatted(context); // 3. 创建消息列表，并调用 AI List<ChatMessage> messages = new ArrayList<>(); messages.add(new SystemChatMessage(systemPrompt)); messages.add(new UserChatMessage(userQuery)); // 4. 发起请求。由于我们配置了工具，AiClient 会自动处理工具调用循环。 ChatResponse response = aiClient.call(new Prompt(messages)); // 注意：这里可能是多轮对话，AiClient 内部会处理模型返回的“要求调用工具”的响应， // 自动执行工具，并将结果再次发送给模型，直到模型给出最终回答。 // Spring AI 0.8+ 版本对此有很好的封装。 return response.getResult().getOutput().getContent(); } }

4.5 提供 REST API 端点

最后，我们通过一个简单的 Controller 将服务暴露出去。

@RestController @RequestMapping(“/api/agent”) public class AgentController { @Autowired private CustomerSupportAgentService agentService; @PostMapping(“/chat”) public ResponseEntity<String> chat(@RequestParam String sessionId, @RequestBody ChatRequest request) { // sessionId 可用于区分不同用户，实现对话记忆的隔离 String response = agentService.handleUserQuery(sessionId, request.getQuery()); return ResponseEntity.ok(response); } // 内部类，用于接收请求体 public static class ChatRequest { private String query; // getters and setters } }

至此，一个具备知识库检索和工具调用能力的 Java AI 客服 Agent 就搭建完成了。你可以通过POST /api/agent/chat?sessionId=user123来与之交互。

5. 性能调优、监控与避坑指南

将 Agent 跑起来只是第一步，让它稳定、高效、可控地运行在生产环境，才是真正的挑战。以下是我在实战中积累的一些关键经验。

5.1 性能优化：控制成本与延迟

AI 应用的成本和延迟主要来自大模型 API 调用。

1. 优化提示词（Prompt Optimization）：

• 精简系统指令：系统提示词不是越长越好。清晰、简洁、无歧义的指令更能让模型理解意图，并减少不必要的 Token 消耗。
• 使用“少样本提示”：在提示词中提供一两个高质量的输入输出示例，能显著提升模型在特定任务上的表现，有时比写长篇大论的指令更有效。
• 结构化输出：要求模型以 JSON、XML 或特定标记格式输出，便于程序解析，也减少了模型“说废话”的可能。

2. 缓存策略：

• 向量检索缓存：对于相同的用户查询，其向量化和相似度检索结果是固定的。可以将(query_embedding, topK)作为 key，检索到的文档 ID 列表作为 value，缓存到 Redis 中，有效期可以设得长一些。
• 最终答案缓存：对于高频、答案相对固定的问题（如“退货政策是什么”），可以将(query, context_hash)作为 key，将模型的最终回答缓存起来。注意，当知识库（context）更新时，需要使相关缓存失效。
• Embedding 缓存：Embedding 模型的调用同样有成本和延迟。可以为所有文档块计算一次向量并存储，对于用户查询的向量化结果也可以进行短期缓存。

3. 异步与流式响应：

• 对于耗时的复杂 Agent 任务（需要多次工具调用），务必采用异步处理（如返回一个任务 ID，通过 WebSocket 或轮询获取结果），避免 HTTP 请求超时。
• 如果模型支持（如 OpenAI 的 GPT-4），使用流式响应（Streaming Response）。这可以让用户更快地看到首个 Token，提升体验感知。

5.2 可观测性与监控

“黑盒”是 AI 应用的大忌。我们必须知道 Agent 内部发生了什么。

1. 结构化日志记录： 不要只打印最终答案。记录下关键步骤的输入输出。

// 在 RetrievalService 中 log.info(“Retrieval triggered”, Map.of( “query”, query, “topK”, topK, “retrieved_doc_ids”, matches.stream().map(m -> m.getEmbedded().getMetadata().get(“id”)).collect(Collectors.toList()) )); // 在工具调用处 log.info(“Tool invoked”, Map.of( “tool_name”, “queryOrderStatus”, “parameters”, Map.of(“orderId”, orderId), “result”, result ));

使用 JSON 或结构化日志格式，方便后续接入 ELK（Elasticsearch, Logstash, Kibana）或 Grafana Loki 进行聚合分析。

2. 链路追踪： 将 Agent 的每次调用视为一个分布式事务。集成 Micrometer Tracing 或 OpenTelemetry，为每次用户请求生成一个唯一的 Trace ID，并在这个 Trace 下记录：

• 向量检索的耗时和结果数量。
• 每次模型 API 调用的耗时、请求 Token 数、响应 Token 数。
• 每次工具调用的耗时和结果状态。 这样，当某个用户查询响应慢时，你可以快速定位瓶颈是在检索、模型生成还是在某个慢速工具上。

3. 关键指标监控： 在 Prometheus 中定义并暴露以下指标：

• agent_requests_total：请求总数。
• agent_request_duration_seconds：请求耗时分布。
• agent_tool_calls_total：按工具名称分类的调用次数。
• agent_retrieval_documents_count：每次检索平均返回的文档数。
• agent_tokens_used：消耗的 Prompt Token 和 Completion Token 数量（估算成本）。 通过 Grafana 仪表盘可视化这些指标，设置告警（如 P99 延迟过高、工具调用失败率上升）。

5.3 常见“坑”与解决方案

坑1：工具描述不清，导致模型乱调用或不调用。

• 现象：模型要么频繁调用错误的工具，要么该调用工具时却选择自己编造答案。
• 解决：花时间精心编写工具的name和description，特别是description，要像给一个新手写说明书一样，明确输入、输出和用途。可以为工具提供更丰富的元数据，比如@Param的required属性。

坑2：上下文窗口爆炸，导致 API 调用失败或成本激增。

• 现象：随着对话轮数增加，携带的历史消息越来越长，最终超过模型上下文限制。
• 解决：
  • 使用摘要记忆：不要原封不动地保存所有历史消息。在对话轮数达到一定阈值后，让模型对之前的对话历史生成一个简短的摘要，然后用这个摘要代替原始历史，作为新的上下文。
  • 设定记忆窗口：严格限制保存在内存中的对话轮数（如最近10轮）。
  • 重要信息持久化：对于对话中产生的关键信息（如用户选择的商品型号、确认的地址），应主动将其存入数据库或特定上下文变量，而不是依赖模型的对话记忆。

坑3：向量检索召回率低，答案不准确。

• 现象：知识库明明有相关内容，但 Agent 却回答“不知道”。
• 解决：
  • 优化分割策略：尝试减小分割块大小、增加重叠区域，或者采用语义分割（尝试识别段落边界）。
  • 尝试重排序：在向量检索出 topK 个结果后，使用一个更小、更快的模型（或交叉编码器）对这些结果进行相关性重排序，只将最相关的1-2个片段送给大模型。
  • 混合检索：结合关键词检索（如 BM25）和向量检索，取并集或对结果进行融合，提高召回率。

坑4：模型“幻觉”，编造不存在的信息。

• 现象：即使提供了准确的上下文，模型仍会捏造细节。
• 解决：
  • 在系统指令中强约束：明确指令“必须严格依据提供的上下文信息回答问题，上下文未提及的内容，一律回答‘我不知道’或‘根据现有信息无法回答’”。可以多次强调。
  • 输出格式约束：要求模型在答案中引用来源片段的编号，例如“根据[文档1]和[文档3]的内容，...”。这既方便用户核实，也“提醒”模型要基于原文。
  • 后处理校验：对于关键事实（如日期、数字、名称），可以设计简单的规则或调用另一个验证工具进行二次校验。

6. 进阶之路：从单智能体到多智能体系统

当单个 Agent 的能力达到瓶颈，或者业务场景需要分工协作时，就该考虑多智能体系统了。想象一个电商场景：一个“导购 Agent”负责推荐和答疑，一个“订单 Agent”负责处理查询和状态变更，一个“售后 Agent”负责处理纠纷和工单，它们之间可以通信和协作。

实现模式：

1. 中心编排式：一个“经理 Agent”接收用户请求，根据意图将其分发给不同的“专家 Agent”，并汇总结果。这可以用一个更强大的模型（如 GPT-4）作为路由器和协调器。
2. 平等协作式：多个 Agent 地位平等，通过共享的工作区或消息队列进行通信。例如，一个 Agent 完成任务后，将结果发布到特定主题，关注该主题的其他 Agent 接手后续工作。

技术挑战：

• 通信协议：Agent 之间如何交换信息？简单的内存对象传递只适用于单机。需要考虑消息队列（RabbitMQ, Kafka）、HTTP API 或专门的 Agent 通信框架。
• 共识与冲突解决：当多个 Agent 对同一问题有不同意见时怎么办？需要设计投票机制、权威仲裁或回滚策略。
• 系统监控：复杂度呈指数上升。必须为每个 Agent 建立独立的监控和日志，并有一个全局视角来观察整个工作流的健康状态。

从简单开始：不要一开始就设计复杂的多 Agent 系统。可以先从“主 Agent + 工具调用”模式开始，然后将一些复杂的工具内部实现，本身改造成一个独立的、功能内聚的“子 Agent”。这样渐进式地演进，风险更可控。

Java 在构建这类复杂、高并发的分布式系统方面，拥有成熟的技术栈和丰富的实践经验。将 AI Agent 视为一种特殊的“微服务”，利用好 Spring Cloud、消息中间件、分布式追踪等现有工具，是 Java 开发者在这场 AI 应用浪潮中的独特优势。这条路并不比 Python 社区的主流玩法简单，但它更坚实、更可控，也更适合承载那些严肃的、有实际价值的商业应用。