Southblock'Blog

✅本地部署Dify做工作流搭建前面介绍过了Workflow，想要搭建工作流其实有很多工具，比较常见的就是Dify。  什么是DifyDify 是一款开源的大语言模型(LLM) 应用开发平台。使开发者可以快速搭建生产级的生成式 AI 应用。 Dify 内置了构建 LLM 应用所需的关键技术栈，包括对数百个模型的支持、 Prompt 编排界面、RAG 引擎、Agent 框架、灵活的流程编排，并同时提供了一套易用的界面和 API。这为开发者节省了许多重复造轮子的时间，使其可以专注在创新和业务需求上。  Dify官网：https://dify.ai/ Dify项目地址：https://github.com/langgenius/dify 官网教程：https://docs.dify.ai/zh-hans/introduction 在线Dify：cloud.dify.ai/apps  本地部署Dify 配置要求： CPU >= 2 Core RAM >= 4 GiB 1、https://github.com/langgenius/dify ...

✅Workflow VS Agent 很多人都会拿Workflow和Agent对比，因为他们的目的是一样的，就是借助AI的能力来实现特定的功能，同时需要赋予AI使用工具、记忆等能力。  那他们有什么区别呢？  这里众说纷纭，我比较认可Anthropic在 《Building Effective Agents》 中给出的说法：  “Agent” can be defined in several ways. Some customers define agents as fully autonomous systems that operate independently over extended periods, using various tools to accomplish complex tasks. Others use the term to describe more prescriptive implementations that follow predefined workflows. At Anthropic, we categorize all th ...

✅使用 LangGraph 构建一个Ai WorkflowLangGraph 是由 LangChain 团队开发的一个用于构建状态驱动、多智能体（multi-agent）或循环式工作流的框架。它基于图（Graph）的概念，将复杂的工作流程建模为状态机，特别适合处理需要记忆、迭代、协作或多轮交互的 AI 应用。  LangGraph是实现工作流，尤其是agentic workflow的最典型的一个框架了。（什么是workflow，后续有单独章节介绍）  以下是 LangGraph 中的核心概念（其实这些概念，在Spring AI Alibaba 1.1版本发布后，其中的graph也沿用了类似的概念）：  LangGraph的核心思想 一切皆状态 LangGraph的整个工作流的状态被封装在一个 共享的、不可变的 State 对象 中。所有节点（Node）只能读取当前 State，并返回对 State 的增量更新。框架负责将更新合并，生成新 State，推动流程前进。  图即程序 在LangGraph中，工作流 = 有向图（Directed Graph）、节点（Node） = 函 ...

✅初识Ai Workflow工作流（workflow）这个概念并不新鲜，也不是AI专有的，这玩意由来已久了，很多开发中也会用到工作流的技术，比如我们常见的审批，就是一个典型的工作流。  以前一提到工作流，大家首先想到的是BPMN，activiti等技术和框架，他们都是是一系列预定义的、结构化的任务或步骤，用于完成某个业务目标。这些步骤通常按特定顺序执行，可能包含条件分支、并行处理、人工审批等逻辑。  他的特点是针对一些相对固定的流程做预定义，然后按照我们规定的步骤来做执行。好处就是流程比较固定，再结合一些可视化的工具，可以做到可视化编排。缺点的话就是因为提前预设好的，灵活性较低、更更没啥自主性。  在AI时代，工作流的概念又火了一把。主要是因为很多时候，我们想要用AI实现一些智能体的话，有一个典型的构建方式就是用工作流。  因为很多时候我们想要完成一个工作的时候，大模型的调用只是其中的一个步骤，而在这个步骤前后还有一些其他的事情要做，那么如果这些步骤的流程是固定的，就可以用工作流实现了。  所以，所谓的AI工作流，无非就是在传统的工作流引入了LLM的能力，把LLM当做其中的一 ...

✅实战四：手搓 Human in the Loop在前面的章节中，我们已经了解了 Spring AI Alibaba 官方提供的 Human-in-the-Loop（HITL）能力，以及它实现 HITL 的整体流程。本章将通过完整手写一个 支持 HITL 的 ReactAgent，带你从工程实现的角度，真正理解 HITL 需要解决哪些问题、关键机制如何设计，以及它是如何落地的。 在动手之前，我们先从整体视角回顾一下 Spring AI Alibaba 中 HITL 的完整执行流程： Agent 启动并进入推理流程 大模型在推理过程中生成 Tool Call 框架识别到 Tool Call，并判断该工具是否被配置为需要人工审批 若需要审批，Agent 执行被中断，返回 InterruptionMetadata 人类用户基于 InterruptionMetadata 做出审批决策（通过 / 修改 / 拒绝） Agent 在同一个 threadId 下携带人工反馈恢复执行 框架根据审批结果决定是否、以及如何真正执行工具调用 Agent 继续后续的推理与执行 ...

✅实战三：手搓 PlanExecuteAgent（下）迭代主流程接下来，我们将前面所划分的规划、执行、批判、压缩和总结串联起来，统一编排在一个迭代的主流程之中。 整个 Agent 从用户问题出发，首先构建全局状态，将用户原始输入作为事实写入其中。随后，Agent 进入一个以轮次为单位的循环，每一轮都基于当前状态依次经历规划、执行与评估，从而不断逼近用户目标。 在每一轮迭代中，Agent 会先尝试生成新的执行计划。如果规划阶段判断当前上下文已经具备作答条件，则直接跳出循环，避免不必要的工具调用；否则，按照规划结果执行相应的工具任务，并将所有执行结果回写到全局状态。随后进入批判阶段，由模型基于事实状态判断目标是否已经满足：若通过，则提前结束循环；若未通过，则将明确的改进反馈写入状态，并在必要时触发上下文压缩，为下一轮迭代腾出稳定的工作记忆空间。 当批判阶段认为始终没有达成目标（可能是工具有问题，或者模型有问题，这种类似的异常情况），会达到最大轮次限制，Agent 会基于已经收敛的全局状态生成最终回答。通过这种显式的“计划 → 执行 → 校验 → 修复 → 收敛”的循环结构，PlanExec ...

✅实战三：手搓 PlanExecuteAgent（上）什么是Plan & Execute ?在前面的 ReactAgent、ReflectionAgent 中，我们已经看到了非常典型的 「一步一决策」 的智能体模式： 模型 → 判断要不要用工具 执行工具 → 观察结果 再判断下一步 这种模式非常适合短链路、即时决策的问题，但一旦任务具备以下特征，就会开始显得吃力： 目标复杂，需要全局观察，执行多步才能完成 中间步骤存在明显的阶段性成果 部分步骤可以并行，部分步骤必须串行 最终结果不是简单的几段话，而是完整的分析报告 这类问题，本质上不是一步步想，而是先想清楚要做哪些事，再一件一件把事做完。这正是 Plan & Execute 架构要解决的问题。 Plan & Execute 是一种将智能体决策过程显式拆分为主要两个阶段的架构模式： Plan（规划）阶段 模型不做任何实际执行，只负责： 判断是否需要使用工具 拆解任务 明确每一步要调用什么工具 定义步骤之间的依赖关系  Execute（执行）阶段 系统按照执行计划： 串行 &# ...

✅实战二：手搓 ReflectionAgent我们在前面的提示词工程的课程中，介绍过反思机制这种智能体工程化结构。通俗来说，它不仅会按照常规流程基于模型决策执行任务，还会在每轮输出后对自己的回答进行反思，判断答案是否完整、逻辑是否清晰、结论是否可靠，如果发现不足，会自动生成反馈并进行修正，从而迭代出更高质量的结果。 到这里我们是不是可以发现，ReflectionAgent 是不是和我们之前的 ReactAgent很像，只是在其基础上增加了自我评估与修正能力。 大家应该还记得之前课程中介绍过的 Spring AI 的 Advisor 机制，也就是在模型调用前后增加一些特殊处理，形成一串责任链，按顺序执行。那么我们的反思机制其实也是可以基于 Advisor 来实现的。那到底是在模型调用前，还是模型调用后，来增加反思机制呢？ 答案就是模型调用后，每次模型生成最终回答后，ReflectionAgent 会先检查结果是否达到预期标准，而不是盲目直接输出。如果回答未达标，Agent 会将反思反馈注入到下一轮推理中，引导模型重新规划任务或调用工具。 当然，增加反思机制后，智能体的响应时间会更长。因此 ...

✅ReAct Agent 流式输出后续问题tool_call出现时机我在后续切换使用其他模型的时候，发现不同模型他的返回的行为方式是有一些差异的。 比如我一开始使用我们公司自己微调量化出来的qwen32b模型，他在进行流式输出的时候，如果需要调用工具，那么第一块chunk确实是直接输出的tool_call，如果没有工具调用那么就是直接输出content。所以我在上文中给大家讲解的 processChunk 方法中的处理也是按照这种方式来处理的，通过对第一块chuck的判断来决定后续的处理模式。 但是当我在切换模型的时候，比如使用百炼平台的qwen模型的时候，他流式输出的方式其实是会受到我的提示词影响的。 后来我发现是因为提示词有这么一段内容的时候，大模型会严格按照ReAct模式来思考问题，所以他的流式输出，就算是需要调用工具，他一开始也会输出那么一段think的过程。  我们直接把这段角色定义的内容copy出来，直接调用qwen的api来看下现象：  我们可以看到他的最后才输出了tool_call，而前面是输出了一段think的过程放置到content之中。 那我们去掉这段角色 ...

✅实战一：手搓 ReactAgent（流式）在前面的章节中，我们已经通过非流式 call 方法完整跑通了一套 ReAct 的核心流程。但一旦把输出方式切换为流式，事情就会明显复杂起来，这也是为什么需要单独用一篇文章来讲 SimpleReactAgent 的流式实现。 流式调用的难点并不在于“如何把内容一点点吐给用户”，而在于 ReAct 在流式场景下的状态如何被正确管理。在非流式模式中，模型一次性返回完整结果：要么是最终答案，要么是完整的 ToolCall；而在流式模式下，模型的输出被拆成了多个 chunk，文本和 ToolCall 都是分段到达的，如果没有额外的状态管理能力，Agent无法判断当前轮次的模式的。  状态管理在流式实现中，SimpleReactAgent 需要引入了一个非常关键的概念：每一轮都有一个独立的执行状态，也就是 RoundState，有点类似于 Alibaba React Agent 的 OverAllState 。这边的设计其实并不复杂，只负责记录三件事情： 当前这一轮到底是“最终答案模式”还是“工具调用模式”。 第一块流式数据是否已经处理过。 已经 ...