LangChain4j非AI Agent实战：不访问大模型的智能体架构

从纯智能体到工作流：一个绕不开的性能问题

在构建AI Agent应用时，无论采用纯智能体（Autonomous Agent）还是工作流编排（Workflow）的形式，都存在一个共同的、容易被忽视的痛点：对大模型的高频访问。

纯智能体（Autonomous Agent）是指具备自主决策能力的AI系统，它能够根据目标自行规划步骤、选择工具并执行任务，整个过程由大模型驱动决策链，典型代表如AutoGPT、BabyAGI等。工作流编排（Workflow）则是预先定义好执行路径和条件分支的结构化流程，开发者显式控制每一步的执行顺序。两者的核心区别在于决策权的归属：前者将决策权交给大模型，后者保留在开发者手中。在实际工程中，纯智能体的灵活性更高但可控性较差，工作流编排可控性强但缺乏灵活应变能力，因此业界逐渐倾向于混合架构——而这两种模式都面临着大模型高频调用的共性挑战。

以一个典型的图书借阅场景为例，用户输入「张三借一本《百年孤独》」，系统需要完成一系列操作。我们不妨拆解一下整个流程中究竟访问了多少次大模型：

• 解析用户消息：从自然语言中提取「图书名称」和「读者姓名」，访问大模型 1 次；
• 调度各个子智能体：图书智能体、读者智能体、通知智能体、记录智能体，每个智能体都要访问一次大模型，累计 4 次；
• 工具调用决策：大模型决定调用哪个工具，工具执行完毕后返回结果又需要大模型理解，一到两次不等；
• 循环调用：若涉及多轮工具调用，次数还会成倍增加。

这里需要特别说明工具调用（Function Calling）的底层机制。Function Calling是现代大模型的核心能力之一，最早由OpenAI在2023年6月引入。其工作原理是：开发者向大模型描述可用工具的名称、参数和功能，大模型在推理时判断是否需要调用工具，若需要则返回结构化的调用请求（包含函数名和参数JSON），应用层执行实际调用后将结果回传给大模型进行下一步推理。这个过程至少需要两次大模型调用——一次决定调用什么工具，一次理解工具返回结果。如果涉及多工具链式调用，次数还会成倍增长，这正是性能瓶颈的核心来源。

综合下来，一次简单的业务操作竟然要访问将近十次甚至十次以上的大模型。

高频调用大模型带来的三重代价

这种设计在实际生产环境中会带来三个无法忽视的问题。

成本高昂

每次访问大模型都是要计费的。大模型API的计费通常基于Token数量，Token是文本被分词后的最小单位，中文大约1.5-2个字对应一个Token。以GPT-4o为例，输入Token价格约为$2.5/百万Token，输出约为$10/百万Token。当一个简单流程需要调用十几次时，每次调用都包含系统提示词、历史上下文、工具描述等大量输入Token，加上推理输出的Token，单次用户请求的总Token消耗可能达到数千甚至上万。在高并发场景下（如每秒数百请求），月度API费用可能达到数万美元量级，直接推高运营成本。对于高并发的线上业务而言，这几乎是不可承受之重。

响应缓慢

大模型的推理需要等待，且这种同步调用模式并不支持流式输出（Streaming）。流式输出是指大模型在生成响应时，不等待全部内容生成完毕就逐步返回部分结果，用户可以看到文字逐字出现的效果，类似ChatGPT的打字机效果。这种机制依赖Server-Sent Events（SSE）或WebSocket协议。原因在于Agent多步调用返回的并非Spring WebFlux能够理解的响应式类型。Spring WebFlux是Spring框架的响应式编程模块，基于Project Reactor实现非阻塞IO，核心类型为Mono（单值）和Flux（多值流）。要实现流式输出，大模型客户端需要返回Flux<String>类型的响应流，而在Agent多步调用场景中，中间步骤的同步等待会阻断这一流式管道，导致用户必须等待所有步骤完成后才能看到最终结果。如果要实现流式，你需要手动编写命令式的入口，并将聊天模型切换成流式聊天模型，改造成本较高。

体验割裂

用户在每一步都要等待，累积的延迟让交互体验大打折扣。这种「等待—返回—再等待」的模式，显然不是我们能够容忍的。

破局思路：Agent不访问大模型也能工作

面对上述问题，一个巧妙的思路浮出水面：如果这个 Agent 的任务并不真正需要自然语言理解，为什么还要访问大模型？

LangChain4j 官方文档中恰好有一个专门的章节回应了这个需求——No AI Agent（非AI代理）。LangChain4j是LangChain生态在Java/JVM平台上的官方实现，旨在为Java开发者提供与Python版LangChain对等的AI应用开发能力。它提供了统一的大模型接口抽象（支持OpenAI、Anthropic、本地模型等）、工具调用（Function Calling）、RAG（检索增强生成）、记忆管理、Agent编排等核心能力。其设计哲学强调与Spring Boot生态的深度集成，通过注解驱动的方式降低开发门槛。No AI Agent是其在0.35+版本中引入的特性，允许开发者创建不依赖大模型的代理节点，体现了框架对工程实践的务实考量。

根据官方注释的说明：到目前为止，所有的代理都是 AI 代理，意味着它们都基于大语言模型来执行需要自然语言理解的任务。然而，LangChain4j 同样支持非 AI 代理，这些代理可用于执行「不需要自然语言」的任务。

换句话说，它仍然是一个 Agent，但它不访问大模型、不需要理解自然语言，就可以直接完成工具操作。

LangChain4j非AI Agent的实现方式

既然不访问大模型，那么原本围绕大模型的一整套配置都可以简化掉：

• 不需要提示词（System Message）；
• 不需要 ChatModel；
• 不需要 Tools 工具集。

核心改造：把工具方法内联为普通Java方法

关键改造在于：把原本由大模型决定调用的工具方法，直接内联为 Agent 类中的普通方法。

工具的执行原本是由大模型决策触发的，现在既然不访问大模型，我们就把 Tools 里的方法逻辑搬进 Agent 类，让它成为一个普通的 Java 方法直接执行。

例如在图书智能体中，注入 readerMap，通过 @Autowired 装配依赖，方法直接返回业务对象——这样原来的 readerTool 就可以被彻底替换掉，不再需要独立的工具定义。

简化Agent的创建与注入

在创建这类非 AI Agent 时，无需再传入 chatModel，也无需注入工具。整个 Agent 变成了一个纯粹的 Spring 组件，直接通过 @Autowired 注入即可使用，就像调用普通的 Service 一样。

@Autowired是Spring框架的核心注解之一，用于实现依赖注入（Dependency Injection, DI）。DI是控制反转（IoC）设计模式的具体实现，其核心思想是将对象的创建和依赖关系管理交给容器（Spring IoC Container），而非由开发者手动管理。当一个类被标注为@Component、@Service或@Bean时，Spring容器会自动创建其实例并管理其生命周期。将Non-AI Agent设计为普通Spring组件意味着它可以享受Spring生态的全部能力——如事务管理、AOP切面、生命周期回调等——同时保持与其他业务组件一致的编程模型，降低了团队的认知负担。

代码中依次装配 bookAgent、readerAgent、notificationAgent、recorderAgent 等组件，全部通过 @Autowired 完成，无需手动 new 对象。因为这些 Agent 既不访问大模型也不调用工具，它们在自身内部就完成了全部工作。

实测效果：响应速度显著提升

完成改造后，进行了实测验证。

重新 clean 并编译运行后，可以观察到大模型的访问次数大幅下降——理论上只在必要环节（如最终结果润色）访问一到两次，中间的业务逻辑完全由本地方法处理。

从实际运行结果看，响应速度明显加快，请求发送后几乎立即返回，等待时间远远短于之前的纯智能体方案。

在业务验证环节，测试了库存不足的场景：当某本图书没有库存时，系统正确检测到「无法借阅」，数据库中的读者状态和库存数据均未发生错误变更，逻辑判断准确无误。这说明去掉大模型后，业务的正确性依然得到保障。

总结：按需使用大模型的混合Agent架构

LangChain4j的No AI Agent提供了一个务实的工程视角：并非所有的智能体节点都需要自然语言理解能力。

对于那些逻辑确定、无需语义解析的任务（如库存检查、状态更新、数据记录），完全可以用普通方法替代大模型调用。这种「按需使用大模型」的混合架构，能够在保证功能完整的前提下，显著降低成本、缩短延迟。

在实际的 Agent 系统设计中，识别哪些节点真正需要 LLM、哪些节点可以退化为确定性代码，是一项重要的架构决策。这种决策本质上是在「智能性」与「确定性」之间做权衡：大模型擅长处理模糊输入、语义理解和开放式推理，但对于输入输出明确、逻辑固定的操作，确定性代码不仅更快更便宜，还更加可靠可测试。合理运用非 AI 代理，能让整个系统在智能与效率之间取得更好的平衡。

核心要点