本文详细介绍了如何基于大模型进行领域场景开发从提示词工程到RAG、流程编排模式再到最新的React框架逐步提升研发生产力。作者团队通过实战经验展示了如何实现RAG角色扮演平台、一键办事机器人等应用并深入探讨了React框架的技术选型、系统架构设计以及核心代码实现。此外文章还分析了多智能体架构的利弊并选择了层级指挥模式进行多智能体协作设计。最后作者提出了未来迭代重点包括上下文管理、动态压缩等为平台开发者提供了宝贵的参考经验。背景基于大模型的领域场景开发说到底无非是借助基座模型对语义的理解推理能力将通用AI变为专有AI工具的过程。但仅仅只做模型调用来实现复杂类需求对生产力的提升并没有太大帮助。因此在围绕提升研发生产力的过程从大模型问世到现在卷出了各种大模型工程规范。从最早的提示词工程到RAG再到流程编排模式每个阶段无疑都是对研发生产力的不断提升。当然我们团队也经历了这些阶段我们最先基于饿了么钉钉文档开发了一套完备的RAG角色扮演平台此后又并行推出了拥有三十多项大模型指令的饿了么一键办事机器人——小e和集成流程编排到平台能力中为适配多端透出和支持丰富渲染开发了问答助手分身及问答卡片搭建功能。感兴趣可以在文章最后介绍中体验。至此也基本能满足大多数AI需求场景的低代码搭建。但随着多智能体架构对复杂场景的支持越来越灵活近期我们也在设计架构升级。参考了一些主流平台中工具与agent间的分发及调用针对我们平台当前的用户体量及后续支撑的一些场景分析层级指挥和自由协作两种模式的利弊选用层级指挥模式作为React框架。初步实现了单智能体对工具调用的反思规划后边迭代利用此框架再将智能体抽象为工具调用实现多智能体间的相互协作。先上结果1.对用户提问自主规划比流程编排模式更加灵活。2.单智能体更丰富的工具体系自主选择工具调用摆脱传统prompt工程参数解析、意图识别等coding或节点配置过程。ToolCallsMCP实现React模式什么是React对于React大家都有自己的理解。本文主要介绍我们是如何实现React框架关于智能体React模式简单仅做个人简单的一些理解。1.首先LLM需要不断和环境作出反馈和判断制定下一步的执行策略。这里的环境即工具列表、对话上下文、一些系统变量。2.上图可以看出核心还是接收反馈后采用什么方式决策以及和环境之间通信的上下文如何管理。因此关于决策方式和上下文管理大家都卷出了各种玩法决策方式1.类manuas方式使用PlanningAgent负责规划Controller Agent负责监督Planning执行情况StepAgent负责打标。2.OpenAI提出的显式引导3.Planning As Tool——将思考规划作为一个单独的工具告诉大模型有这样一种工具且入参定义为思考、行动、规划借助工具入参来引导大模型思考规划。上下文管理这个可能又涉及到一些比较复杂的上下文通信和动态压缩等本文也不做介绍后续也是我们重点升级的方向好的上下文通信带来的核心收益有两方面每个agent拥有更丰富的背景内容产出质量更高 极大节省token用tooCalls的方式很烧tokenPlanning 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的enableThinkingfalse在哪配置。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.烧token2.无关信息可能会导致每个agent调用时产生幻觉如果agent获取到的上下文不够或者确实带来的问题有1.产出质量较低导致指挥者可能发生多次无用的调用指挥2.agent并行执行时agent之间的上下文通信能力不足类似于神经网络中陷入局部最优解因此在多智能体升级完以后我们也会考虑设计上下文动态压缩、合理使用文件系统等工作。查询了一些资料发现有些资料中的观点与我提到的基本类似可以参阅总结本文主要对多平台LLM客户端MCP 实现智能体React框架的方案进行了详细阐述对核心代码进行了剖析以及对目前业界多智能体设计方案的进行了调研简单介绍。希望能对相关平台开发者有借鉴意义对个人开发者其实有更多的方案进行体验没有必要进行手撸框架。最后对于正在迷茫择业、想转行提升或是刚入门的程序员、编程小白来说有一个问题几乎人人都在问未来10年什么领域的职业发展潜力最大答案只有一个人工智能尤其是大模型方向当下人工智能行业正处于爆发式增长期其中大模型相关岗位更是供不应求薪资待遇直接拉满——字节跳动作为AI领域的头部玩家给硕士毕业的优质AI人才含大模型相关方向开出的月基础工资高达5万—6万元即便是非“人才计划”的普通应聘者月基础工资也能稳定在4万元左右。再看阿里、腾讯两大互联网大厂非“人才计划”的AI相关岗位应聘者月基础工资也约有3万元远超其他行业同资历岗位的薪资水平对于程序员、小白来说无疑是绝佳的转型和提升赛道。对于想入局大模型、抢占未来10年行业红利的程序员和小白来说现在正是最好的学习时机行业缺口大、大厂需求旺、薪资天花板高只要找准学习方向稳步提升技能就能轻松摆脱“低薪困境”抓住AI时代的职业机遇。如果你还不知道从何开始我自己整理一套全网最全最细的大模型零基础教程我也是一路自学走过来的很清楚小白前期学习的痛楚你要是没有方向还没有好的资源根本学不到东西下面是我整理的大模型学习资源希望能帮到你。扫码免费领取全部内容最后1、大模型学习路线2、从0到进阶大模型学习视频教程从入门到进阶这里都有跟着老师学习事半功倍。3、 入门必看大模型学习书籍文档.pdf书面上的技术书籍确实太多了这些是我精选出来的还有很多不在图里4、AI大模型最新行业报告2026最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5、面试试题/经验【大厂 AI 岗位面经分享107 道】【AI 大模型面试真题102 道】【LLMs 面试真题97 道】6、大模型项目实战配套源码适用人群四阶段学习规划共90天可落地执行第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容3、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】