基于大模型的领域场景开发：从单智能体到多智能体的React框架设计与实现

基于大模型的领域场景开发，说到底无非是借助基座模型对语义的理解推理能力，将通用AI变为专有AI工具的过程。但仅仅只做模型调用，来实现复杂类需求，对生产力的提升并没有太大帮助。因此在围绕提升研发生产力的过程，从大模型问世到现在，卷出了各种大模型工程规范。从最早的提示词工程到RAG，再到流程编排模式，每个阶段无疑都是对研发生产力的不断提升。

当然我们团队也经历了这些阶段，我们最先基于饿了么钉钉文档，开发了一套完备的RAG+角色扮演平台，此后又并行推出了拥有三十多项大模型指令的饿了么一键办事机器人——小e，和集成流程编排到平台能力中，为适配多端透出和支持丰富渲染，开发了问答助手分身及问答卡片搭建功能。感兴趣可以在文章最后介绍中体验。

至此也基本能满足大多数AI需求场景的低代码搭建。但随着多智能体架构对复杂场景的支持越来越灵活，近期我们也在设计架构升级。

参考了一些主流平台中工具与Agent间的分发及调用，针对我们平台当前的用户体量及后续支撑的一些场景，分析层级指挥和自由协作两种模式的利弊，选用层级指挥模式作为React框架。初步实现了单智能体对工具调用的反思规划，后边迭代利用此框架再将智能体抽象为工具调用，实现多智能体间的相互协作。

先上结果：

1.对用户提问自主规划，比流程编排模式更加灵活。

2.单智能体更丰富的工具体系，自主选择工具调用，摆脱传统prompt工程参数解析、意图识别等coding或节点配置过程。

对于React，大家都有自己的理解。本文主要介绍我们是如何实现React框架，关于智能体React模式简单仅做个人简单的一些理解。

1.首先LLM需要不断和环境作出反馈和判断，制定下一步的执行策略。这里的环境即工具列表、对话上下文、一些系统变量。

2.上图可以看出，核心还是接收反馈后采用什么方式决策？以及和环境之间通信的上下文如何管理。

因此关于决策方式和上下文管理大家都卷出了各种玩法：

决策方式

1.类manuas方式，使用PlanningAgent：负责规划；Controller Agent负责监督Planning执行情况；StepAgent负责打标。

2.OpenAI提出的显式引导

3.Planning As Tool——将思考规划作为一个单独的工具，告诉大模型有这样一种工具，且入参定义为思考、行动、规划，借助工具入参来引导大模型思考规划。

上下文管理

这个可能又涉及到一些比较复杂的上下文通信和动态压缩等，本文也不做介绍，后续也是我们重点升级的方向，好的上下文通信带来的核心收益有两方面：

1. 每个agent拥有更丰富的背景内容，产出质量更高 ；

2. 极大节省token，用tooCalls的方式很烧token；

1.调用大模型时注入系统提示词+用户提问+工具列表（包含思考规划工具）。

2.得到大模型回答出，需要的工具是什么，以及入参是什么？

3.第一步回答出需要调用的工具是思考工具，借助思考工具定义的入参，让大模型给到思考内容、规划内容，实际该方法只是一个空壳，然后拼接大模型的回答和工具调用的结果，思考规划工具的调用结果手动mock为success。

4.得到回答，需要调用天气查询工具，入参也给出来了：

5.重复2-4的过程，直至大模型返回的tool_calls为空，content不为空时结束，最终结果如下：

技术选型

技术选型上我最终使用的是elemMcpClient+多平台LLM调用客户端。

那为什么这样选择，不直接使用springAI已经封装好的工具调用，或者使用原生McpSdk，还要自己手撸呢：

1.springAI本身集成了上下文管理、工具调用等能力，理论上直接用来做模型调用是很方便，但是：

a.中间过程交互不够友好，对于个人开发者来说，springAI确实比较方便，绑定一堆工具、配置好模型地址和ak，输入一个提问，直接能返回意图分类后工具的执行结果，但是我们是平台开发者，我们需要将中间过程做封装交互展示。

b.springAI虽然可以设置中断，只返回该调用哪个工具，把工具的执行交给开发者，但这里也有点坑，有些情况不能返回选择了哪个工具，而且，那这样的话，springAi的价值也大打折扣，仅被当成一个LLM调用的客户端......

c.很多国内模型其实springAI的openAiApi支持的不够灵活，可能是我自己原因，没有找到springAi里面qwen3的enableThinking=false在哪配置。

d.springAI集成的原生McpSdk本身也有坑，比如集团内发布的很多TppMcp或者AoneMcp都调不通，原因在下面分析。

2.原生MCPSdk作为工具调用时，不支持后缀带很多参数的MCP服务，如Aone开放平台发布的MCP为了鉴权，带有鉴权参数。

基于上述背景和试错过程，最终选择了ElemeMcpSdk + 包含WhaleSdk在内的主流平台LLM客户端。

规划类agent调度框架如下图所示：

1.agent分类方面，此前我们已经有了流程编排类型、其他平台api接入类型、RAG+角色扮演类型。此次扩展出一种规划类型agent。

2.在环境方面，我们针对长期记忆和短期记忆分别进行持久化。

a.长期记忆主要指多轮对话，补充一次会话过程中的背景信息；

b.短期记忆是每个智能体或工具给出的回答，用于：1.后续实现单agent间的通信 2. 记录思考次数，以便做异常中断；

c.agent绑定的工具列表持久化，其中有一个作用是，gpt4做toolCalls时，仅支持方面名是英文的方法，因此还要利用这块的存储做中文-英文的缓存；

3.规划过程：

a.领域抽象时，设计了五个Node来完成核心流程；

b.startNode，用于组装系统提示词、RAG检索到的片段、用户提示词、历史对话、用户提问、工具列表；

c.startNode节点中调用LLM，收到反馈；

d.ProcessNode节点负责循环过程的执行，需要获取LLM返回的参数，去拼接LLM的message内容、以及循环中发起对工具列表的调用；

e.ToolManagerNode ，负责接收需要调用的方法名及入参，根据方法名，在cache中查找对应的MCP的sseUrl利用mcp客户端调用工具获取结果，添加到LLM的message中；

f.StepNode，负责对每一步结果进行打标，并存储到短期记忆中；

g.SendNode  负责接收来自processNode的数据，并进行封装，如背景中的各个步骤执行效果，需要用和前端约定好的标签封装过程数据。然后对封装好的数据利用Ssemitter进行发送；

4.LLM客户端封装

a.针对LLM调用，主要是根据不同平台对模型的支持程度，封装了三个LLM-ToolCalls的客户端；

b.whaleSdk、Idealab-http调用、springAI框架调用；

c.根据用户配置的模型id，来适配找出一种客户端做模型调用；

整个实现流程图如下，与上述描述基本一致：

这部分主要对实现的相关代码进行介绍。

核心类及属性

流转对象

startNode

发起调用流程

规划运行节点

工具节点：获取工具列表，只在startNode中调用。

工具节点：执行工具

LLM客户端：whale为例

利用工厂模式还扩展了springAI、Idealab类型客户端。

核心类基本如上图所述，还有其他关于前后端约定的展示样式封装的工具类不做展开介绍。

单智能体本身就是为了解决足够复杂的任务，为什么还需要多智能体？

这里给一些个人的看法：

1.烧token，每次中心agent对模型的请求完全是无脑拼接，如果拆分成多智能体，中心agent对模型的发起只用某个agent返回的结果即可。

2.单智能体职责不够清晰，产出的交付物不如  多智能体的“专业的事交给专业的人”

上述方案我们已经实现了单智能体对工具的React框架，但是多智能体的协同还未做升级，参考了一些资料，多智能体框架实现基本分为两类。

一种是类似React的层级调度模式，由中心agent负责调度需要执行的智能体，我们实现也比较简单，只需要在现有实现框架基础上，将agent抽象为工具即可。工具执行时根据工具类型再实现调用方法。

另一种是自由协作模式，针对一个问题，每个agent分别去处理这个问题，然后执行结果发送给下一个agent，继续判断它能否解决这个问题，以及解决了哪些部分，一轮结束后，由中心agent去分发任务开始执行下一轮，这时候每个agent由了上一轮的上下文，产出效果更聚焦于各自职责。直到中心agent判断可以产出时，进行汇总。

两种方案如下图所示：

考虑后续我们承接的业务场景暂时不需要很发散的需求，采用层级指挥模式进行多智能体协作设计。

通过手撸React框架，以及对多智能体协作的调研，发现了一些问题，其实本文上述中在每个章节都有提到上下文管理。

如果无脑做ToolCalls调用，带来的问题有：

1.烧token；

2.无关信息可能会导致每个agent调用时产生幻觉；

如果agent获取到的上下文不够或者确实，带来的问题有：

1.产出质量较低，导致指挥者可能发生多次无用的调用指挥；

2.agent并行执行时，agent之间的上下文通信能力不足，类似于神经网络中陷入局部最优解；

因此，在多智能体升级完以后，我们也会考虑设计上下文动态压缩、合理使用文件系统等工作。

查询了一些资料，发现有些资料中的观点与我提到的基本类似，可以参阅：

本文主要对多平台LLM客户端+MCP 实现智能体React框架的方案进行了详细阐述，对核心代码进行了剖析，以及对目前业界多智能体设计方案的进行了调研简单介绍。希望能对相关平台开发者有借鉴意义，对个人开发者其实有更多的方案进行体验，没有必要进行手撸框架。