Southblock'Blog

✅如何给Agent增加持久化记忆 Spring AI Alibaba中，如果你要直接用chatClient对话的话，就和spring ai用法一样就行了。   ✅Spring AI 记忆管理技术：持久化记忆在Spring AI中，我们最熟悉的就是MessageWindowChatMemory ，它默认是一个基于内存的短期记忆实现，它维护最多指定最大大小（默认值：20 条消息）的消息窗口。 当消息数量超过此限制时，较旧的消息会被逐出。这确保对 LLMentor  如果你要直接用他里面的agent的话，那么持久化记忆的实现方式可以这样用。  我们都知道，想要定义一个ReactAgent，需要传入一个saver用来做记忆： 1ReactAgent reactAgent = ReactAgent.builder() .name("memoryAgent") .model(chatModel) .saver(new new MemorySaver()).build(); 之前我们都是直接用的MemorySaver()，这是 ...

✅Alibaba-React Agent 核心组件 基础组件ModelModel 就是大模型，作为 Agent 的大脑，负责推理、生成文本、决定下一步行动 (是否调用工具／输出答案)。  Spring-AI-Alibaba 的底层核心实现就是基于 Spring AI Apache，可以理解为Alibaba是增强版的 Spring AI。和之前的做法一样，你只需实现了 ChatModel 接口的类来作为模型即可。同时也可以通过配置 ChatOptions 来控制 temperature、maxTokens、topP 等参数。 使用示例： 123DashScopeApi dashScopeApi = DashScopeApi.builder() .apiKey("sk-XXXXXXXXXXXXXXXXXXXX") .build();// 创建 ChatModelChatModel chatModel = DashScopeChatModel.builder() .dashScopeApi(dashScopeApi) ...

✅Alibaba-React Agent 初探目前，Spring AI Alibaba 1.1版本正式发布，它已经提供了生产级 ReactAgent 的实现。ReactAgent 是基于 Graph 运行时（Graph Runtime）的概念构建的。这个 Graph 运行时定义了一个结构化的执行流程，使 Agent 的推理和工具调用过程可控、可追溯。所谓 Graph 也就是图，他是由节点（Node）和边（Edge）构成的。  Agent 的核心执行流程是一个持续的推理和工具调用的循环，直到满足停止条件（例如，模型输出最终答案或达到预设的最大迭代次数）。在执行过程中，Agent 在以下几种核心节点（Node）之间流转： **Model Node (模型节点)**：这是 Agent 的“大脑”。它负责调用大模型，根据当前上下文（包括历史对话、工具描述和最近的观察结果）进行推理和决策，决定下一步是使用哪个工具、使用什么参数，或者直接得出最终结论。 **Tool Node (工具节点)**：这是 Agent 的“手脚”。当大模型决定使用工具时，此节点会执行实际的工具函数调用，并捕获执行结 ...

✅React Agent的实现方式？  想要实现ReAct Agent，有两个关键点：  1、要让LLM按照ReAct的方式运行。 2、我们需要通过代码让Agent的”思考结果”、”行动”等串起来。   ReAct Prompt想要让你的Agent能够按照思考 + 行动 + 观察的思路运行，提示词必须要给出说明，这是至关重要的一步，如果没有这一步，别的做了再多都是白搭。 以下是一个典型的ReAct System Prompt : 123你是一个基于React架构（Reasoning-Act-Observation）的智能助手，你擅长使用工具帮我解决问题。你的工作流程是：思考：基于当前获得的信息进行推理和反思，明确下一步行动的目标。行动：用于表示需要调用的工具，每一步行动必须是以下两种之一： 1、工具调用 [Function Calling]：根据任务需要，确定调用工具。 2、Finish[答案]：得出明确答案后使用此操作，返回答案并终止任务。观察：记录前一步行动的结果。你可以进行多轮推理和检索，但必须严格按照上述格式进行操作，尤其是每一步“行动”只能使用上述两种类型之 ...

✅Agent常用架构：ReAct Agent  在前面介绍提示词工程的时候，我们提到过ReAct这种模式，目的是让 LLM 同时具备推理（Reasoning）与行动（Acting）能力，从而更可靠地解决复杂任务。  而我们在开发Agent的时候，通常也会用到这种模式，使用这种模式开发出来的Agent叫做ReAct Agent 人类解决问题 = 思考 + 行动 + 观察 → 再思考 → 再行动……  ReAct Agent也模仿这一过程，让 LLM 在每一步交替输出： Thought（思考）：分析当前状态、制定下一步计划 Action（行动）：调用工具（如搜索、计算、API） Observation（观察）：接收工具返回的结果  针对用户的提问，LLM会先进行思考（Thought），指定行动计划，行动计划中包括使用哪些工具，接着进行工具执行（Action），在工具执行之后，观察（Observation）工具执行的结果，基于结果继续思考后续的行动计划。如果需要执行工具就继续执行，直到LLM认为所有行动都做完了为止。  我们假设想要通过AI实现这样的功能：帮 ...

✅常用的Agent开发框架 Agent开发不一定需要自己纯手撸（当然，我们后面会有很多章节介绍如何手撸，但是目的是让大家更好的理解），其实有很多成熟的框架可以用的。  Python常用的Agent框架 **LangChain&**LangGraph LangChain是最流行的 LLM 应用开发框架之一，支持 Agent 构建、工具调用、记忆、链式推理等。  LangGraph 是 LangChain 团队推出的一个用于构建 状态化（stateful）、多参与者（multi-actor）、循环式（cyclic）智能体工作流 的库。它基于 有向图（Directed Graph） 模型，允许开发者以声明式方式定义复杂的 Agent 执行流程，特别适合需要规划、反思、协作或人类干预的高级应用场景。  在我们的文档中也有介绍：  ✅LLM应用开发框架：LangChainLangChain 是一个非常知名的开源框架，他的主要作用是简化基于大型语言模型构建应用程序的过程。它提供了一套模块化、可组合的工具和抽象，帮助开发者将 LLM 与外部数据源、记忆机制、工具调用等能力结合起 ...

✅什么是AI Agent？  Agent，翻译成中文叫做智能体，是当前最火的一个词了。举几个大家容易理解的例子。  1、在去年荣耀的发布会上，CEO赵明对手机上的AI助理说了一句“帮我点2000杯奶茶”的指令，便成功通过手机下单2000杯奶茶，送给了现场观众。  2、去年，Manus横空出世，用户可以通过指令描述告诉他帮忙生成一份调查报告，他就能打开浏览器，搜索相关信息，并生成一份报告。  3、我们使用cursor做编码，告知他帮忙实现某个功能，他就能检查文件，找到合适的位置，做代码修改，然后运行验证是否有问题，如果有问题，帮忙解决。  4、最近豆包手机助手很火，可以通过对话让他帮忙操作你的手机。  还有很多很多，这些都是智能体。所以，所谓的AI Agent，其实就是一个可以自主完成工作的AI助手。  其实，现在很多LLM的对话工具，如ChatGPT、千问等，也在从对话助手向Agent转型。  如果一定要给他下个定义的话：Agent是以大语言模型为核心计算引擎，能够自主理解、规划决策、执行负责任务的智能体。  Agent 的四大核心能力：目标驱动（Planning ...

✅MCP与其他协议的区别在前面的课程中，我们已经对 MCP 模型上下文协议的核心机制进行详尽阐述，也明白了它在大模型工具调用时的关键作用。本章节主要介绍一下MCP和其他协议的关系和区别。 MCP与远程过程调用（RPC）远程过程调用（RPC）是软件架构中历史悠久且至关重要的一种通信范式，其设计初衷是让程序能够像调用本地函数一样，透明地调用远程服务器上的服务。RPC的核心在于过程的同步执行和命令式控制，就是****像调本地函数一样，去调远程函数。它要求调用方和被调用方之间拥有严格预定义的接口、函数签名和数据类型，通信语义聚焦于“如何执行”一个特定的操作，并期待一个确定的执行结果。 相比之下，MCP的诞生是为了服务于具有推理能力的大模型。MCP的核心在于提供结构化的上下文和工具使用指引，实现从“执行”到“决策”的转变。 RPC解决的就是执行的问题，它是一个执行引擎；而MCP解决的是“提供哪些信息和工具，让AI决定如何使用”的问题，它是一个上下文与能力的抽象。大模型通过MCP来理解外部世界的各种工具和数据，将用户的自然语言意图（例如：“帮我查询下周的天气”）转换为对MCP工具的调用。这种交互模 ...

✅如何实现 MCP 工具过滤为什么要做工具过滤？在企业级的复杂场景中，MCP Server 往往会包含大量工具，如果不加区分地将所有工具直接交给大模型使用，会带来明显的性能与准确性问题。因此，在 MCP Client 侧引入工具过滤机制是非常有必要的操作。 主要原因包括以下三点： 降低上下文压力与 Token 成本每个工具都带有结构化的 Schema 和详细描述，这些内容会被放入系统提示词中，同样占用大模型的上下文。如果一个 MCP Server 有几十个工具，而当前任务仅需要其中少量，其余工具描述都会成为无意义的上下文负担，不仅浪费 Token，还会减少模型可处理的有效信息空间。 提升模型工具选择的准确性当工具数量过多时，模型在进行工具选择时需要在一个更大的候选集合中进行判断，干扰项越多，选错工具或产生幻觉的概率越高。通过过滤掉无关工具，可以让模型在更干净有用的工具列表中做决策，从而显著提高调用成功率和整体推理质量。 多智能体角色划分在多智能体架构中，不同智能体通常负责不同任务。例如，在网络安全领域，告警分析智能体只需要告警查询的相关工具，而资产分析智能体只需要资产查询的相关工 ...

✅如何跳过 MCP 的模型总结在  ✅Spring AI MCP 调用实现原理这一章节中，我们已经深入了解了 MCP 的内部工作流程，在大模型决策选择工具，框架调用工具结束后，会将工具执行结果再次丢给大模型做迭代总结。这个机制的好处是：模型不仅能决定调用哪个工具、如何调用工具，还能对工具结果进行自然语言的总结，使最终回答更自然、更贴近用户需求。 但这套机制不是在所有场景下都合适，有时候甚至会成为性能瓶颈。 为什么要跳过模型总结？在真实的业务系统中，你往往会遇到如下的场景： 多智能体协作（Multi-Agent） 多个 Agent 持续调用工具、互相传递结果，如果每一步工具执行完都要让模型再总结一遍： 延迟倍增 token 成本增加 智能体的逻辑链路变长、变慢 最终用户等待时间过长 某些时候，Agent 根本不需要模型再去总结。例如： 一个 Agent 专门用于执行计算任务 一个 Agent 专门用于进行数据清洗 调用工具的任务就是中间过程，无需总结 这些都是中间过程，只需要获取到结果就好，在最终总结的时候，将这些中间结果一起抛给最后一个总结智能体中，让总结智 ...