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

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

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

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

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

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

这里需要特别说明工具调用（Function Calling）的底层机制。Function Calling是现代大模型的核心能力之一，最早由OpenAI在2023年6月引入。其工作原理是：开发者向大模型描述可用工具的名称、参数和功能，大模型在推理时判断是否需要调用工具，若需要则返回结构化的调用请求（包含函数名和参数JSON），应用层执行实际调用后将结果回传给大模型进行下一步推理。这个过程至少需要两次大模型调用——一次决定调用什么工具，一次理解工具返回结果。如果涉及多工具链式调用，次数还会成倍增长，这正是性能瓶颈的核心来源。值得注意的是，Anthropic的Claude、Google的Gemini等模型随后也支持了类似机制（分别称为Tool Use和Function Calling），说明这已成为行业标准能力，但其多轮调用的性能开销问题是所有大模型API共同面临的挑战。

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

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

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

成本高昂

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

进一步分析成本构成：在Agent场景中，每次调用大模型时传入的上下文（Context）会不断膨胀。系统提示词（System Prompt）通常固定占用500-2000 Token，工具描述（Tools Schema）可能占用1000-3000 Token，加上多轮对话的历史消息，单次调用的输入Token可能高达5000-10000。这意味着即便模型本身的单价在持续下降（如GPT-4o相比GPT-4降价约50%），高频调用带来的累积效应仍然使成本居高不下。对于创业公司或中小型团队，这种量级的API开销可能直接决定产品的商业可行性。

对于高并发的线上业务而言，这几乎是不可承受之重。

响应缓慢

大模型的推理需要等待，且这种同步调用模式并不支持流式输出（Streaming）。流式输出是指大模型在生成响应时，不等待全部内容生成完毕就逐步返回部分结果，用户可以看到文字逐字出现的效果，类似ChatGPT的打字机效果。这种机制依赖Server-Sent Events（SSE）或WebSocket协议。SSE是一种基于HTTP的单向服务端推送协议，服务器可以持续向客户端发送事件流，浏览器通过EventSource API接收。WebSocket则是全双工通信协议，适合需要双向实时通信的场景。在大模型应用中，SSE更为常用，因为模型推理本身是单向输出的过程。

原因在于Agent多步调用返回的并非Spring WebFlux能够理解的响应式类型。Spring WebFlux是Spring框架的响应式编程模块，基于Project Reactor实现非阻塞IO，核心类型为Mono（单值）和Flux（多值流）。Project Reactor遵循Reactive Streams规范，通过背压（Backpressure）机制实现生产者和消费者之间的流量控制。要实现流式输出，大模型客户端需要返回Flux<String>类型的响应流，而在Agent多步调用场景中，中间步骤的同步等待会阻断这一流式管道，导致用户必须等待所有步骤完成后才能看到最终结果。具体来说，当Agent执行「调用大模型→执行工具→再调用大模型」的循环时，每个步骤之间存在数据依赖关系，无法将中间过程包装为连续的响应流推送给前端。

如果要实现流式，你需要手动编写命令式的入口，并将聊天模型切换成流式聊天模型（如将ChatModel替换为StreamingChatModel），改造成本较高。这不仅涉及模型客户端的替换，还需要重新设计Agent的编排逻辑，将同步阻塞的多步调用改造为响应式管道，对现有代码的侵入性极大。

体验割裂

用户在每一步都要等待，累积的延迟让交互体验大打折扣。从人机交互（HCI）研究的角度来看，Jakob Nielsen的响应时间理论指出：0.1秒以下用户感觉系统即时响应，1秒以内用户注意到延迟但思维不会中断，10秒以上用户注意力完全转移。而在Agent多步调用场景中，大模型单次推理延迟通常在1-5秒（取决于模型规模和输入长度），十次调用累积下来可能达到15-30秒的总延迟，远超用户耐受阈值。这种「等待—返回—再等待」的模式，显然不是我们能够容忍的。

破局思路：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+版本中引入的特性，允许开发者创建不依赖大模型的代理节点，体现了框架对工程实践的务实考量。

这一设计思路并非LangChain4j独创。在更广泛的AI Agent框架生态中，类似的理念也有体现：微软的Semantic Kernel通过「Plugin」机制将确定性代码与AI能力解耦；CrewAI允许为Agent指定不同的执行模式。但LangChain4j将其明确抽象为「No AI Agent」这一一等公民概念，在框架层面给予了正式支持，使得混合架构的实现更加优雅和标准化。

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

换句话说，它仍然是一个 Agent，但它不访问大模型、不需要理解自然语言，就可以直接完成工具操作。这里的「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生态的全部能力——如事务管理（@Transactional确保数据库操作的原子性）、AOP切面（通过@Aspect实现日志记录、性能监控等横切关注点）、生命周期回调（@PostConstruct、@PreDestroy）等——同时保持与其他业务组件一致的编程模型，降低了团队的认知负担。

从测试角度来看，这种设计也带来了显著优势：Non-AI Agent作为普通Spring Bean，可以使用标准的单元测试和集成测试框架（如JUnit 5 + Mockito）进行测试，无需Mock大模型API的响应，测试的确定性和执行速度都大幅提升。而依赖大模型的Agent测试往往面临响应不确定性、网络依赖等问题，测试成本高且结果不稳定。

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

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

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

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

从实际运行结果看，响应速度明显加快，请求发送后几乎立即返回，等待时间远远短于之前的纯智能体方案。从定量角度分析，假设单次大模型调用平均耗时2秒，原方案10次调用累计约20秒；改造后仅保留1-2次大模型调用（约2-4秒），中间的本地方法执行耗时在毫秒级，总体延迟降低80%以上。这一提升在用户体感上是质的飞跃——从「明显等待」变为「近乎即时响应」。

在业务验证环节，测试了库存不足的场景：当某本图书没有库存时，系统正确检测到「无法借阅」，数据库中的读者状态和库存数据均未发生错误变更，逻辑判断准确无误。这说明去掉大模型后，业务的正确性依然得到保障。事实上，对于确定性逻辑而言，普通代码的正确性反而优于大模型——大模型存在「幻觉」（Hallucination）风险，可能在边界情况下产生错误判断，而确定性代码的行为完全可预测、可验证。

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

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

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

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

可以将Agent系统中的节点按照「是否需要语义理解」进行分类：需要语义理解的节点（如用户意图识别、多轮对话管理、开放式问答）保留大模型调用；不需要语义理解的节点（如数据CRUD、状态机流转、规则引擎判断、外部API调用编排）退化为Non-AI Agent。这种分类方法为架构师提供了清晰的决策框架。随着大模型推理成本的持续下降和推理速度的提升，这条边界未来可能会移动，但在当前阶段，混合架构是工程实践中的最优解。

合理运用非 AI 代理，能让整个系统在智能与效率之间取得更好的平衡。

核心要点

• 问题本质：Agent系统中大模型的高频调用导致成本高、延迟大、体验差
• 破局思路：识别不需要自然语言理解的Agent节点，将其改造为Non-AI Agent
• 实现方式：去掉ChatModel和Tools配置，将工具方法内联为普通Java方法，作为Spring组件注入
• 架构决策：按「是否需要语义理解」对节点分类，大模型只用在真正需要智能的环节
• 实测收益：响应延迟降低80%以上，API成本大幅下降，业务正确性不受影响