能源领域多智能体框架实战：解决单智能体效率低下，实现高效协作系统！

本文介绍了作者团队在能源领域构建多智能体Multi-Agent框架的实践经验。面对单智能体处理复杂任务时因“注意力发散”导致的效率低下问题团队设计了一套集“规划-调度-执行-汇总”于一体的多智能体协作系统。前言项目介绍近年来随着Deepseek和Manus的快速发展激发了大家对AI应用的研发热情各种AI项目层出不穷为我们生活增加了更多智能化能力。我们希望利用AIot可信产业团队在能源领域的专业知识结合大模型AI为我们客户提供24小时专业高效的能源领域专家解决客户在综合能源领域的投前风控、设备运维以及售后运营等问题。在此背景下我们基于多智能体框架研发了集合各种能源专家的综合能源智能体平台。本文旨在介绍我们在多智能体框架实践过程中的一些经验希望能给大家提供一点帮助。为什么需要多智能体根据业内经验大模型在处理长提示词时往往无法有效捕捉关键信息导致推理结果不佳。这使得单智能体在处理复杂任务时效果不如处理简单任务即使是类似ReAct的智能体也会出现步骤缺失或重复的问题其中原因就在于大语言模型的“注意力发散”机制。为了解决长提示词带来的“注意力发散”通常我们会通过将复杂任务分解为简单子任务然后构建包含执行这些子任务节点的工作流智能体(Workflow Agent)来解决。然而在我们的业务场景下单智能体的模式过于僵化很难满足用户多变的任务需求即使这个单智能体是工作流智能体。因此我们希望能有这么一个多智能体框架可以对用户输入的复杂任务拆分成不同的简单子任务并进行任务编排然后将子任务作为最小执行单元交由不同类型的智能体处理最后将处理结果汇总给到用户。举个我们业务中遇到的用例光伏测算报告生成来说正常业务流程会进行进行光伏经济性测算-进行光伏测算的敏感性分析-生成光伏经济性测算报告。用户输入可能是“帮我生成一份光伏经济测算报告”或者是“我已经有测算方案了对已有的测算方案进行敏感性分析并生成测算报告”此时单智能体和多智能体处理流程如下从上图可以看到使用多智能体执行框架既能够根据业务逻辑对复杂任务拆分可以让智能体处理更加高效同时通过合理的规划多智能体协作可以灵活应对不同的客户诉求。多智能体执行框架本章将介绍我们如何去搭建这样一套多智能体框架。目前我们多智能体框架的整体调用流程图如下我们将多智能体执行可以分为三个阶段规划编排调度执行和汇总输出具体执行流程如下1.[规划编排]针对用户输入内容规划器进行意图识别并将复杂任务规划编排分解为不同的简单子任务生成相应执行计划。2.[调度执行]调度执行器解析规划器规划编排的执行计划将子任务分发给到智能体注册中心中对应的智能体调度执行。3.[调度执行]智能体通信总线负责不同智能体之间的相互通信并获取智能体输出结果。在执行过程中通信总线可以将智能体执行中间结果流式输出给前端卡片提高用户体验。4.[调度执行]智能体执行过程中调度执行器会对任务执行状态进行监控确保所有子任务顺利完成。5.[汇总输出]总结器可以获取所有子任务的执行结果并将结果汇总输出给到前端业务。以下是对执行过程中各个组件的介绍。规划器Planner在进行执行之前首先需要对用户输入内容进行规划编排这里有几个问题需要解决如何准确识别客户意图如何对用户复杂意图进行拆分规划规划编排如何被有效执行规划编排规范化这里我可能着重关注规划编排如何被有效执行问题即如何规范化规划编排内容。我们知道多智能体执行逻辑主要在两个模块负责规划编排的规划器和实际执行的多智能体调度执行器。规划器规划编排生成对应计划Plan并交由调度执行器调度执行二者之前交互如下图然而在实践中我们发现若将计划Plan的规范化放在规划编排阶段会存在两个问题由于缺少执行智能体信息规划编排的Plan可能会将子任务关联不存在或过期的执行智能体导致调度执行器无法分配子任务给到相应智能体。就像是甲方给乙方分配任务时说“XXX这个任务你来完成”结果XXX人家已经离职不干了因此这里需要一个上下游沟通机制乙方需要告诉甲方我有哪些资源才行。规划器无法“约束”自己的编排格式或者是随着项目发展规划器新增了一些编排规则导致生成的Plan调度执行器无法识别。就像是日常工作中规定使用中文沟通结果甲方介绍需求时蹦出一些法语、西语、阿拉伯语词汇乙方执行人自然无法理解。因此虽然调度执行器依赖于规划器规划编排产出的计划Plan进行规划调度但为了调度执行器准确识别Plan内容这里将Plan的规范交由调度执行器提供可能更为合适。这里调度执行器主要提供两个工具给到规划器智能体列表查询工具通过查询智能体注册中心获取当前可以执行的所有智能体列表信息以便规划器进行规划。计划创建工具PlanCreator规范化计划执行所需要的基本信息主要是计划名称和计划执行步骤其中计划执行步骤中包含了步骤序号、执行目标已经需要调度执行的智能体名称。这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】调度执行器Executor在调度执行阶段调度执行器将对计划Plan中的规划步骤进行解析并构建执行有向无环图DAG。计划步骤作为执行DAG中的执行节点被分配到对应的智能体执行。鉴于计划步骤之间可能存在依赖关系调度执行器采用串行方式调用智能体执行这些规划步骤。在智能体执行之前会根据计划步骤的内容以及当前计划的整体状态构建当前步骤的智能体执行请求。执行完成后智能体会更新计划步骤和计划的整体状态并将执行结果输出到流式输出总线StreamingWriter。当所有计划步骤执行完毕后调度执行器将输出执行计划ExecutionPlan。调度状态管理由于业务复杂性规划器在进行规划编排时无法确保当前上下文信息是否满足任务执行需要。因此在具体执行到某一计划步骤时可能会出现缺少必要信息导致步骤无法执行完成的情况下。这意味着在业务任务执行过程中可能存在与用户进行多次交互的场景。我们不能让用户每次交互后将在计划任务从头到尾跑一遍这会带来性能和token的巨大浪费。调度执行器需要支持在步骤执行缺少必要信息时中断当前任务步骤待用户补充信息后重新执行中断的调度计划。为了支持执行计划的中断和重跑需要保证调度执行器执行和智能体执行时能否获取上次中断执行的上下文信息。智能体上下文信息管理主要利用了“聊天记忆”机制在后续章节中具体介绍。这里主要介绍如何让调度执行器调度执行时有计划。调度执行器在解析规划编排计划时会构建一个包含状态信息的执行计划(ExecutionPlan)包括用户原始输入、步骤执行状态等信息。当需要中断时调度执行器会将当前执行信息保存到ExecutionPlan中待用户补充信息后调度执行器会根据计划ID查询ExecutionPlan并加载执行上下文信息根据上下文信息重跑执行计划。具体ExecutionPlan数据结构如下{ planId: 计划ID, userQuery: 用户输入内容 steps: [{ seqNo: 0, agentName: 智能体名称, requirement: 步骤目标, status: 步骤状态, result: 执行结果 }], context: { 当前执行内容key:已识别的上下文信息 } }planId 是执行计划的唯一标识符。userQuery 当前执行计划最新的用户输入内容。假如首次用户输入“帮我进行光伏测算”此时userQuery为“帮我进行光伏测算”由于缺少光伏测算参数调度中断用户再次输入补充“地点时杭州余杭区进行工商业光伏测算”此时userQuery为“地点时杭州余杭区进行工商业光伏测算”。steps 是一个包含所有执行步骤的数组每个步骤包含以下字段seqNo 步骤执行序列号而是在执行计划中步骤的唯一标识。agentName 计划步骤对应的执行智能体名称由规划器根据智能体列表规划编排得到。requirement 该步骤中执行的操作内容和需求目标由规划器规划编排得到。status 是步骤的当前状态例如completed, in_progress, not_startedinterrupted, failed。result 是步骤执行的结果包括成功与否的信息以及相关数据。context 执行计划的上下文内容包含用户多次交互中已识别的执行信息确保不会因为多次交互导致之前关键信息丢失。智能体通信根据上面计划步骤执行流程我们知道不同步骤之间存在一定依赖关系意味着当前执行智能体既需要知道上一步智能体的输出结果同时也需要将自己的执行输出告知下一步执行智能体。因此这里需要定义一套智能体通信规范协议确保兼容各执行智能体之间不同的业务逻辑输入输出同时执行智能体依然保持独立解耦。在此之前我们也调研了其他开源框架的做法例如Spring Alibaba的OpenManus框架它的实现方式是将执行步骤之前所有的步骤执行结果汇总为字符串消息作为当前执行上下文输入给到执行智能体由智能体的LLM去解析这个字符串消息提取本次执行所需信息。然而这种方式在我们实践中发现存在几个问题1.信息失真问题由于所有步骤的执行结果都被汇总成一个字符串中间由经过了一道大模型信息提炼的错成可能导致最终结果输出时出现关键信息丢失问题。2.结构化保持与额外token消耗汇总后的字符串无法保持输出结果的结构化这意味着智能体在解析时不得不重新识别和解析数据结构这不仅增加了智能体的负担还导致了额外的token消耗。3.上下文限制问题大型语言模型在处理输入时存在上下文长度的限制。当输出结果过长超过了模型的上下文窗口限制时模型可能无法正确理解或处理这部分信息从而影响执行效果。4.文件输出场景的适用性问题对于需要输出文件如光伏测算报告文件等的场景使字符串输出这种方式显得尤为不适用。基于上述问题我们意识到需要探索更加高效、精确且适应多种数据形式的解决方案以应对更为复杂的业务场景。我们保留了OpenManus框架的智能体通信方式并且对其输出结果进行了结构化规范{ recordId: 记录ID, output: 智能体输出结果, status: 智能体执行状态, context: { //输出上下文 } }output是执行智能体的输出结果依然会汇总等计划当前执行步骤结果中。recordId是执行记录ID。在需要输出文件或输出内容超过LLM prompt限制的场景下可以通过工具调用将输出结果持久化后续智能体执行时根据执行记录ID调用工具获取输出结果。context为智能体输出的上下文信息。对于一些结构化信息为了避免重复解析工作可以将其放至context输出到下游执行智能体。这样调度执行器在拿到智能体执行结果AgentExecResult后会将AgenExecResult作为上下文输入给到下一步执行智能体下游执行智能体根据协议解析避免关键信息丢失以及解析重复开销。结果实时性如何确保流式输出不会因为步骤执行而中断怎么确保流式输出结果有序输出的结构化。工具调用时增加一些流式输出由于涉及LLM推理以及外部工具调用因此智能体执行比较耗时再加上目前调度执行器使用的串行方式调度计划步骤导致一次计划执行的整体响应耗时可能达到几分钟。用户在输入后需要几分钟才能看到结果这在交互体验上无疑是灾难性的。排查了调度执行器调用联路我们发现耗时主要还是集中在大模型调用上而现在几乎所有的大模型调用是具备流式输出能力的那么是否可以将调用执行器调用智能体时整合智能体中所有的大模型输出流实现类似下面效果的调度执行流式响应。这样虽然整体响应耗时长的问题依然不可避免但用户可以实时地看到智能体思考过程以及输出结果对客交互体验更为友好。同时采用流式输出方式也可以避免大量数据一次性返回减少IO压力。在和前端通信的场景下不能只是简单大模型流式输出合并给到前端我们还需要解决以下几个问题1.流式输出的有序性。我们知道步骤的执行是有序的在非流式场景下往往采用类似JSON的结构化输出因此步骤执行结果自然有序。但在流式场景下输出结果都是文本片段输出如果出现像DAG并发执行可能会出现文本片段乱序导致前端客户端无法知道这是哪一个步骤的执行返回。2.结构化结果如何流式输出。对于步骤执行结果前端页面通常需要结构化展示因此即使后端结果流式返回前端依然需要等待全部结果获取后才能进行结构化解析。为此我们在设计智能体通信总线时在其中封装了写入流StreamingWriter同时和前端定义一套DSL流式输出时需要遵循这套DSL协议进行输出具体DSL结构如下{ index: 步骤序号, content: 流式文本内容, agentChatResponse: { content: 流式提示信息, intent: 结构数据类型, data: { //结构化结果 } } }index: 流式结果中新增下标字段与执行步骤序号关联确保输出结果有序。content: 适合流式输出的文本信息例如大模型思考过程抑或是智能体执行过程中间信息。agentChatResponse: 智能体步骤执行结果这个往往是在步骤执行中断或执行完成时才会返回。其中包含content: 执行结果的流式输出信息。intent: 执行结果的结构化数据类型前端可以根据该字段选择对应结构化解析逻辑。data: 结构化执行结果。除了上述操作可能还会遇到工具不支持流式调用同时步骤执行涉及到多个工具调用导致调用耗时增加的情况。此时我们也可以在工具调用的过程中增加一些调用信息避免因为工具调用阻塞流式结果返回。执行智能体执行智能体就像是日常工作中的领域助手专家主要负责解决规划编排拆解后的简单子任务。这里主要介绍下多智能体框架下我们怎么去构建一个高效的业务执行智能体。Workflow or AgenticWorkflow和Agentic是目前构建智能体时需要去考虑的两种模式。二者的定义和区别如下可能有些人不把WorkFlow当作是智能体认为其智能化程度比较低。诚然通过AI自动解决问题是我们的最终目标。但我们在做工程化时还是需要结合目前实际业务场景来看而不是一味追求“fancy”的智能化。回归到实际业务上我们需要的是能否帮助用户进行能源决策的专家助手例如光伏经济性测算、敏感性分析或者是逆向寻优而这些场景实际上已经有一套明确且可以结构化的业务逻辑因此workflow智能体更适合作为业务执行的智能体。实际上在项目探索阶段我们也尝试过ReAct智能体然后实践下无论是成功率、性能乃至最终效果都还是不如workflow智能体。下文中未特别说明的智能体均指workflow工作流智能体。智能体上下文在工作流智能体执行过程中除了执行计划ExecutionPlan中的上下文信息工作流各个执行结点也需要通信以便在上游结点识别解析的关键信息能否传递给到下游结点。实际上不仅仅是工作流智能体ReAct模式的智能体也同样存在这个问题有些工具调用的上下文信息不方便直接作为工具调用结果返回但又可能是下游工具调用需要的信息例如一些授权token类的信息。因此智能体内部也需要有一个执行上下文管理机制。这里我们实现了基于内存的智能体上下文管理类并且工具调用返回时除了工具调用结果同时也会返回工具调用的上下文信息。这样像是大模型调用结果或者是工具调用结果我们可以放到智能体记忆中而工具调用上下文信息则放到智能体内存上下文中传递给到下游执行结点执行。多智能体记忆多智能体之间怎么确保记忆相互独立记忆的持久化为什么不共享记忆关于智能体记忆我们上介绍智能体上下文或者是调度执行器的状态管理都有提到因为在涉及这类上下文相关的机制中记忆能力是个避免不了的话题。通过有效的记忆管理可实现与大模型多轮对话的效果。我们将智能体记忆分为两个模块一个是作为大模型调用切点的MemoryAdvisor,主要负责智能体调用大模型的记忆能力增强。还有一个模块是AgentChatMemory,主要负责智能体调用记忆的管理。在一次实际调用过程中二者在其中的角色和作用如下在调用前MemoryAdvisor将当前用户输入prompt中的UserMessage插入AgentChatMemory之后查询AgentChatMemory中的前N条记忆构建最终调用的prompt给到大模型调用。在调用后MemoryAdvisor会将大模型返回结果作为AssistanMessage插入AgentChatMemory作为最新记忆保存。具体调用流程图如下所示通常在设计智能体记忆时我们往往只关注记忆在用户和会话维度上的隔离。然而在实现多智能体框架下的智能体记忆时我们使用{agentName}_{userId}_{converstaionId}的规则作为记忆检索和存储key确保了即使在同一个用户的同一会话下不同智能体的记忆也可以相互独立。这是因为不同智能体之间业务逻辑相差很大如果不同智能体之间存在记忆共享就会想我们日常处理工作这样出现记忆混乱。此外由于记忆管理通常有Message数量限制多智能体共享记忆的话也会导致智能体记忆的效果不佳。除了执行智能体拥有自己独有记忆外我们也在避免记忆检索key直接与执行计划planId挂钩。这样当用户多轮对话涉及到跨执行计划场景时例如“其他参数不变将地址更换到上海市后重新进行测算”执行智能体也可以正确理解客户意图并执行。虽然不同执行计划的记忆相互独立看起来可以提高智能体执行的专注度但出于功能完备性角度我们还是放弃了执行计划记忆隔离。需要注意的是由于SystemMessage对大模型而言具有限定本轮对话角色限制的其特殊作用。因此在和大模型交互时一次对话最好确保只会存在一个SystemMessage。我们在实现AgentChatMemory的检索和新增记忆消息时可以对历史消息列表做检查过滤掉可能存在的历史SystemMessage消息避免额外的SystemMessage消息被组装到大模型对话中。自主控制的工具调用对于执行智能体而言通过大模型FunctionCall能力进行工具调用决策是一个普遍的需求。在我们业务中就有通过大模型服务决策调用光伏测算工具以及测算报告生成工具等场景。虽然很多大模型框架已经集成了大模型FunctionCall以及自动执行工具调用的能力然而出于工具调用安全以及流程控制(例如ReAct框架)考虑我们还是希望自主控制工具调用与否。1.首先如果我们只用了一些大模型框架需要手动关闭工具自动调用。这些框架一般都有关闭入口以Spring AI为例ChatOptions chatOptions ToolCallingChatOptions.builder() .toolCallbacks(...)//调用工具列表 .internalToolExecutionEnabled(false) //关闭工具自动执行 .build();2.人工解析大模型FunctionCall返回结果如果是兼容OpenAI的协议这部分信息通常在返回结果的toolCalls中包括需要调用的函数名以及入参信息。我们可以根据这些信息进行工具调用。3.在工具调用结束后我们需要根据调用结果手动构建工具调用消息ToolResponseMessage并将其保存到记忆中以便多轮对话场景下大模型的识别回复。需要注意的是大模型FunctionCall返回的AssistanMessage消息与工具调用ToolResponseMessage消息中的toolCalls信息存在关联因此人工构建的toolCalls按照以下规则构建否则可能导致后续大模型调用异常以OpenAI协议为例tool_call_id为工具调用唯一IDAssistanMessage与ToolResponseMessage消息中的tool_call_id必须要保持一一对应。ToolResponseMessage中的role需要为tool。ToolResponseMessage中的content为工具执行结果。总结器Finalizer在调用执行器执行计划完成后在输出阶段总结器Finalizer对执行计划结果进行汇总输出给到用户。智能体执行的一些后置操作也可以放在总结器中例如资源释放以及中间过程信息和执行计划状态的持久化工作。总结个人思考在这次多智能体框架搭建过程中个人的一些心得体会对智能体搭建而言尽量减少对大模型的依赖往往越简单的设计越高效。越简单的设计不仅能够减少开发和维护的复杂度降低出错的风险还能显著提升智能体的响应速度和性能表现。一开始我们也尝试依赖于大模型来做一些业务逻辑的决策然后事实证明如果你本身已经拥有了经过行业证明的明确流程实在没必要本末倒置使用大模型再去进行流程决策。尽量将智能体执行过程透明化。在整个多智能体执行过程中多采用日志打印方式输出执行过程信息尤其是步骤执行前后的执行计划状态智能体每一轮调用前后上下文大模型思考过程和结果输出以及工具调用出入参等关键信息这有助于执行问题排查以及智能体优化工作。不要只是去使用框架多去了解框架底层的细节。我们项目使用了Java Spring技术栈而spring ai封装了ChatModel、ChatClient等大模型调用相关组件避免了很多重复开发工作因此在我们项目中得到广泛使用。这也让我们踩了不少坑除了之前说的工具调用消息构造问题还遇到spring ai流式调用时记忆为空以及使用OpenAIChatModel与Qwen3模型的使用兼容等等问题。有些问题如果你不深入到框架代码细节往往会解决问题时会比较茫然。作为一个技术人当你多去了解一些开源项目的底层代码这对个人的架构设计也很有帮忙。一些可优化点工作流编排框架。目前我们智能体开发时工作流结点编排逻辑还是硬编码在代码中我们希望能进一步将工作流编排逻辑沉淀到更底层的框架中使得执行智能体开发人员可以更专注于其业务逻辑开发工作提高智能体研发效率。在Java Spring生态中也有像是embabel这样的开源项目里面有些关于workflow智能体抽象也值得去调研学习。基于DAG图的规划调度。就像是LangChain到LangGraph的升级一样我们也希望能够将目前串行执行的链式调度升级成并发执行的基于有向无环图调度。当然从项目工程的角度而言这个优化项优先级其实不高因为在目前性能效率未遇到瓶颈的情况下引入并发执行也会带来更高复杂度和不稳定性。基于记忆召回的长期记忆。由于prompt长度限制多轮记忆设置了召回最大数。如果我们希望对话关联历史记忆超过了最大召回轮数此时可以考虑向量化记忆方式进行存储和召回并将召回的记忆消息注入到SystemMessage中为大模型调用提供更多上下文信息。如何学习AI大模型我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】第一阶段从大模型系统设计入手讲解大模型的主要方法第二阶段在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用第三阶段大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统第四阶段大模型知识库应用开发以LangChain框架为例构建物流行业咨询智能问答系统第五阶段大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型第六阶段以SD多模态大模型为主搭建了文生图小程序案例第七阶段以大模型平台应用与开发为主通过星火大模型文心大模型等成熟大模型构建大模型行业应用。学会后的收获• 基于大模型全栈工程实现前端、后端、产品经理、设计、数据分析等通过这门课可获得不同能力• 能够利用大模型解决相关实际项目需求 大数据时代越来越多的企业和机构需要处理海量数据利用大模型技术可以更好地处理这些数据提高数据分析和决策的准确性。因此掌握大模型应用开发技能可以让程序员更好地应对实际项目需求• 基于大模型和企业数据AI应用开发实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能 学会Fine-tuning垂直训练大模型数据准备、数据蒸馏、大模型部署一站式掌握• 能够完成时下热门大模型垂直领域模型训练能力提高程序员的编码能力 大模型应用开发需要掌握机器学习算法、深度学习框架等技术这些技术的掌握可以提高程序员的编码能力和分析能力让程序员更加熟练地编写高质量的代码。1.AI大模型学习路线图2.100套AI大模型商业化落地方案3.100集大模型视频教程4.200本大模型PDF书籍5.LLM面试题合集6.AI产品经理资源合集获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】