文章详细介绍了基于大模型的智能体React框架实现方案，从提示词工程到多智能体协作的演进。作者团队开发了饿了么RAG+角色扮演平台和"小e"机器人，采用层级指挥模式实现React框架，分享了技术选型、系统架构设计和核心代码实现，强调了上下文管理的重要性，为复杂场景提供更灵活的AI解决方案。
背景
基于大模型的领域场景开发，说到底无非是借助基座模型对语义的理解推理能力，将通用AI变为专有AI工具的过程。但仅仅只做模型调用，来实现复杂类需求，对生产力的提升并没有太大帮助。因此在围绕提升研发生产力的过程，从大模型问世到现在，卷出了各种大模型工程规范。从最早的提示词工程到RAG，再到流程编排模式，每个阶段无疑都是对研发生产力的不断提升。
当然我们团队也经历了这些阶段，我们最先基于饿了么钉钉文档，开发了一套完备的RAG+角色扮演平台，此后又并行推出了拥有三十多项大模型指令的饿了么一键办事机器人——小e，和集成流程编排到平台能力中，为适配多端透出和支持丰富渲染，开发了问答助手分身及问答卡片搭建功能。感兴趣可以在文章最后介绍中体验。
至此也基本能满足大多数AI需求场景的低代码搭建。但随着多智能体架构对复杂场景的支持越来越灵活，近期我们也在设计架构升级。
参考了一些主流平台中工具与agent间的分发及调用，针对我们平台当前的用户体量及后续支撑的一些场景，分析层级指挥和自由协作两种模式的利弊，选用层级指挥模式作为React框架。初步实现了单智能体对工具调用的反思规划，后边迭代利用此框架再将智能体抽象为工具调用，实现多智能体间的相互协作。
先上结果：
1.对用户提问自主规划，比流程编排模式更加灵活。
2.单智能体更丰富的工具体系，自主选择工具调用，摆脱传统prompt工程参数解析、意图识别等coding或节点配置过程。
ToolCalls+MCP实现React模式
什么是React
对于React，大家都有自己的理解。本文主要介绍我们是如何实现React框架，关于智能体React模式简单仅做个人简单的一些理解。
1.首先LLM需要不断和环境作出反馈和判断，制定下一步的执行策略。这里的环境即工具列表、对话上下文、一些系统变量。
2.上图可以看出，核心还是接收反馈后采用什么方式决策？以及和环境之间通信的上下文如何管理。
因此关于决策方式和上下文管理大家都卷出了各种玩法：
决策方式
1.类manuas方式，使用PlanningAgent：负责规划；Controller Agent负责监督Planning执行情况；StepAgent负责打标。
2.OpenAI提出的显式引导
3.Planning As Tool——将思考规划作为一个单独的工具，告诉大模型有这样一种工具，且入参定义为思考、行动、规划，借助工具入参来引导大模型思考规划。
上下文管理
这个可能又涉及到一些比较复杂的上下文通信和动态压缩等，本文也不做介绍，后续也是我们重点升级的方向，好的上下文通信带来的核心收益有两方面：
每个agent拥有更丰富的背景内容，产出质量更高 ；
极大节省token，用tooCalls的方式很烧token；
Planning As Tool 方案推演
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框架的方案进行了详细阐述，对核心代码进行了剖析，以及对目前业界多智能体设计方案的进行了调研简单介绍。希望能对相关平台开发者有借鉴意义，对个人开发者其实有更多的方案进行体验，没有必要进行手撸框架。
最后
我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。
我整理出这套 AI 大模型突围资料包：
- ✅AI大模型学习路线图
- ✅Agent行业报告
- ✅100集大模型视频教程
- ✅大模型书籍PDF
- ✅DeepSeek教程
- ✅AI产品经理入门资料
完整的大模型学习和面试资料已经上传带到CSDN的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇
为什么说现在普通人就业/升职加薪的首选是AI大模型？
人工智能技术的爆发式增长，正以不可逆转之势重塑就业市场版图。从DeepSeek等国产大模型引发的科技圈热议，到全国两会关于AI产业发展的政策聚焦，再到招聘会上排起的长队，AI的热度已从技术领域渗透到就业市场的每一个角落。
智联招聘的最新数据给出了最直观的印证：2025年2月，AI领域求职人数同比增幅突破200%，远超其他行业平均水平；整个人工智能行业的求职增速达到33.4%，位居各行业榜首，其中人工智能工程师岗位的求职热度更是飙升69.6%。
AI产业的快速扩张，也让人才供需矛盾愈发突出。麦肯锡报告明确预测，到2030年中国AI专业人才需求将达600万人，人才缺口可能高达400万人，这一缺口不仅存在于核心技术领域，更蔓延至产业应用的各个环节。
资料包有什么？
①从入门到精通的全套视频教程⑤⑥
包含提示词工程、RAG、Agent等技术点
② AI大模型学习路线图（还有视频解说）
全过程AI大模型学习路线
③学习电子书籍和技术文档
市面上的大模型书籍确实太多了，这些是我精选出来的
④各大厂大模型面试题目详解
⑤ 这些资料真的有用吗?
这份资料由我和鲁为民博士共同整理，鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位，在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利，同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。
所有的视频教程由智泊AI老师录制，且资料与智泊AI共享，相互补充。这份学习大礼包应该算是现在最全面的大模型学习资料了。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
智泊AI始终秉持着“让每个人平等享受到优质教育资源”的育人理念，通过动态追踪大模型开发、数据标注伦理等前沿技术趋势，构建起"前沿课程+智能实训+精准就业"的高效培养体系。
课堂上不光教理论，还带着学员做了十多个真实项目。学员要亲自上手搞数据清洗、模型调优这些硬核操作，把课本知识变成真本事！
如果说你是以下人群中的其中一类，都可以来智泊AI学习人工智能，找到高薪工作，一次小小的“投资”换来的是终身受益！
应届毕业生：无工作经验但想要系统学习AI大模型技术，期待通过实战项目掌握核心技术。
零基础转型：非技术背景但关注AI应用场景，计划通过低代码工具实现“AI+行业”跨界。
业务赋能 突破瓶颈：传统开发者（Java/前端等）学习Transformer架构与LangChain框架，向AI全栈工程师转型。
👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓**
