09-17 实战一:手搓 ReactAgent(非流式)
✅实战一:手搓 ReactAgent(非流式)本章节将通过从零手搓一套 **SimpleReactAgent**(基于原生Spring AI来实现),带你深入理解 ReAct 在真实工程环境中的工作原理。
相比直接使用现成的 Agent 框架,这种方式能够让你清楚地看到:
模型每一轮是如何做决策的
工具调用是如何被触发和执行的
ReAct 循环究竟是由模型驱动,还是由代码驱动
当你真正走完整个实现过程后,ReAct 将不再是一个“黑盒概念”,而是一套你可以随意拆解和重构的工程模式。
在真正动手写代码之前,有一个非常重要的问题需要先回答清楚:
一个 ReAct Agent,在工程结构上到底由哪些核心模块组成?
为此,我们可以先结合之前的 ReAct Agent 结构图,从整体视角再理解一下完整的执行流程。
构成组件在明确了 ReAct Agent 的整体结构之后,我们可以开始从代码层面定义 SimpleReactAgent 的核心组成。
结合前面结构图中展示的执行逻辑,一个基础且完整的 ReAct Agent 至少需要包含以下几类核心要素:
用户输入(Query)与行为 ...
09-16 多智能体协议——A2A
✅多智能体协议——A2A
前面我们介绍了多智能体,也介绍了几种实现多智能体的方案,包括SubAgent、HandOff以及ChatGrpoup等等。使用langchain/langgraph、autogen、包括spring ai alibaba,我们都可以在一个应用内实现一个multi agent。
如果实在一个应用内部的多智能体,其实是不需要额外的通信的,我们完全可以借助框架给我们提供的比如事件机制、Graph机制等等实现上下文的传递和通信。
但是,有一种多智能体,是多个不同应用间协作,整体组成一个多agent的话,那么就需要有一个通信方式,比如我开发了一个工单问题排查的主Agent,但是需要依赖几个外部团队提供的多个子问题排查的Agent。但是我们不是同一个应用中的,我们之间的通信就是个大问题。
我们之前介绍过,Agent如果想要和工具通信,可以通过MCP协议,那其实google也提出过一个可以让多个agent之间通信的协议,那就是A2A协议——Agent to Agent Protocol
A2A 也是个协议,他是负责多个 Age ...
09-15 Spring AI Alibaba中的多智能体支持
✅Spring AI Alibaba中的多智能体支持除了Python中有很多框架可以实现多智能体以外,Java中的Spring AI Alibaba框架也提供了类似的功能。
前面我们介绍的多智能体的各种模式中,Spring AI主要支持了Agent Tool和Hand off两种实现。
Agent Tool
Agent Tool的思想就是可以把其他的Agent当做工具,SpringAI Alibaba中定义了AgentTool,来表示一个智能体工具。
这个类中提供了一个getFunctionToolCallback方法,可以把一个ReactAgent转成ToolCallback
有了它, 实现多智能体就简单了。
123456ReactAgent writerAgent = ReactAgent.builder() .name("writer_agent") .model(chatModel) .description("专门负责创作文章和内容生成") .ins ...
09-14 使用AutoGen 构建一个代码生成器
✅使用AutoGen 构建一个代码生成器
AutoGen 是由微软(Microsoft)开发的一个开源框架,一般用来简化构建多智能体(Multi-Agent)系统和复杂 LLM(大语言模型)工作流的过程。它通过提供可组合、可对话的智能体(Agent)抽象,使得开发者能够轻松地创建能协作完成任务的 AI 系统。
AutoGen 基于“多智能体对话”模式,认为许多复杂任务可以通过多个具备不同角色和能力的智能体之间的对话与协作高效完成。例如:
一个“程序员”智能体写代码;
一个“代码审查员”智能体检查错误;
一个“产品经理”智能体提出需求;
一个“执行器”智能体运行代码并返回结果。
这种分工协作的方式更接近人类团队的工作模式,也更容易实现模块化、可调试和可扩展的AI系统。
AutoGen 提供了多种预定义的智能体类型,开发者也可以自定义:
AssistantAgent:扮演助手角色,通常基于大语言模型(如 GPT-4、Claude、Llama 等)生成内容。
UserProxyAgent:代表用户,可以自动执行代码、调用函数、请求人类输入等。
UserProxyA ...
09-13 Agent常用架构:Multi Agent
✅Agent常用架构:Multi Agent
多智能体(Multi-Agent)是指由多个Agent组成的系统,这些智能体能够感知环境、做出决策、与其他智能体交互,并协同或竞争以完成特定任务。
前面我们介绍了很多种智能体架构,但是都是单智能体架构,这些单智能体基本能够帮我们解决一些复杂的问题了。但是在实践过程中,仍然会有一些局限:
1、随着任务的复杂度的增加,单智能体会面临上下文窗口不够的问题,会存在经典的”注意力发散”问题,导致效果和性能下降。
注意力发散:在生成长文本或处理复杂输入时,大模型的注意力机制逐渐“偏离”核心主题或关键信息,导致输出内容变得不连贯、重复、无关甚至荒谬。
2、某些场景下,我们需要通过使用不同的模型来解决不同的单一子问题
3、复杂的任务,单智能体运行的效率太慢。
4、因为一个单智能体需要做的事情太多,会存在具体任务不够聚焦,尤其是一些特定专业场景,得到的结果不够好。
5、单个智能体拥有太多工具了,经常会选错工具或者不会用工具
以上这些问题,于是有了多智能体的方案,多智能体通过动态任务分解、专业化分工和协作来解决一个复杂的问题。这 ...
09-12 Agent常用架构:Human in the Loop
✅Agent常用架构:Human in the Loop
Human-in-the-Loop(简称 HITL) 指的是在 AI 系统中的自动决策或执行过程中,引入人类用户作为“必要参与者”,在关键节点对 AI 的行为和结果进行审查、确认或修正,而不是让模型完全自动完成端到端的执行。
在 Agent 场景下,HITL 的核心并不是用户参与推理,而是:
在用户允许的边界内,让 Agent 自动运行;一旦即将执行高风险或高不确定性的动作,必须经过人工确认。
HITL 本质上是一种 流程控制机制。
HITL 的应用场景高风险工具调用当 Agent 需要调用具备一些重要或敏感的工具时,例如:
写文件、删除资源
执行 SQL / 运维指令
调用外部系统接口(下单、转账、封禁用户等)
这类操作一旦执行,往往成本或者影响面较大,因此不适合完全由模型自动决定。
合规与审计要求在金融、安全、企业 IT 等场景中,系统通常要求:
关键操作必须有人类确认
决策过程可回溯、可审计
HITL 可以天然满足“人工审批 + 自动执行”的合规要求。
模型不确定性较高的场景当模型能 ...
09-11 Agent常用架构:Reflection Agent
✅Agent常用架构:Reflection Agent
前面介绍提示词工程的时候也提过这种反思的思路。
它是一种让模型自我批判、自我修正的策略。其核心思想是:让大语言模型(LLM)在完成任务后,对其自身的行为或输出进行批判性反思,并基于反思结果进行改进。
虽然我们有了ReAct或者Plan and Execute等agent架构,但是人们发现还是很多时候在Agent执行后存在一定的问题,因为模型幻觉天然存在,于是有人提出给agent引入反思机制。
LangChain还把Reflection分成了多种不同的实现,包括Basic Reflection、Reflexion以及LATS(https://www.blog.langchain.com/reflection-agents/ ) 。
如以下,使我们用python实现的一个具有反思能力的智能体:
让智能体写一段关于“气候变化对农业的影响”的简短文章,并通过自我反思迭代改进其内容(如逻辑性、完整性、语言流畅度)。
12345678910111213141516171819202122232425262728293 ...
09-10 Agent常用架构:ReWOO&LLMCompiler(选学)
✅Agent常用架构:ReWOO&LLMCompiler(选学)
ReWOO
在Plan And Execute中,Planner 输出的任务列表是彼此独立的(如 [“查天气”, “发邮件”]),无法表达“第二步依赖第一步结果”的关系。这就会导致Executor 无法知道“发邮件”该用哪个天气数据;若强行拼接上下文,又会陷入 ReAct 式的高成本循环。
ReWOO(Reasoning Without Observation) 允许 Planner 在生成计划时定义可引用的中间变量(E#),实现任务间的数据传递,无需在每步调用 LLM 观察结果。
LLMCompiler有了ReWOO 之后,还有个问题并没有解决,那么就是即使任务无依赖(如同时查 5 家公司股价),也必须串行执行,浪费时间。
为了解决这个问题,有人提出了LLMCompiler,将计划表示为有向无环图(DAG),并流式解析+动态调度,实现最大并行度。
09-09 Agent常用架构:Plan and Execute Agent
✅Agent常用架构:Plan and Execute Agent
ReAct 智能体采用“思考 → 行动 → 观察”的循环模式,这利用了思维链提示,每一步只做出一个行动选择。虽然这对于简单任务有效,但是存在以下问题:
低效率:串行决策导致任务执行缓慢,无法并行化。
短视规划:每次仅考虑下一步,缺乏全局视角,容易陷入次优路径。
难以调试与审计:决策逻辑分散在多个 LLM 调用中,缺乏清晰的任务结构。
那为了解决这些问题,有人提出一种新的Agent架构——Plan and Execute Agent,或者叫Plan And Solve。
基于 Plan-and-Solve (https://arxiv.org/abs/2305.04091 )的论文,以及 Yohei Nakajima 的 BabyAGI 项目,Plan And Execute Agent由两个基本组件组成:
Planner:规划器,调用LLM 生成一个多步骤计划来完成一个大型任务。
Executor:执行器,接受用户查询和计划中的一个步骤,并调用 1 个或多个工具来完成该任务。
...
09-08 深入理解 Alibaba-React Agent 原理
✅深入理解 Alibaba-React Agent 原理
前面的课程中,我们学习了 Spring-AI-Alibaba 中的 ReactAgent,知道它能做什么、怎么用。本章节,我会带着大家一起阅读源码,看看 ReactAgent 在 Spring-AI-Alibaba 里到底是怎么实现的,它是如何驱动推理循环迭代的。
流程分析同样我们还是通过一个简单的例子,作为 debug 的入口:
123ToolCallback weatherTool = FunctionToolCallback .builder("weather", new WeatherQueryTool()) .description("查询天气") .inputType(String.class) .build();// 创建 AgentReactAgent agent = ReactAgent.builder() .name("d ...
