核心内容摘要
9.1免费素材高清网站
本文深入探讨AI Agent架构与开发详细解析规划、记忆、工具调度等核心模块分享基于大模型构建智能体的实践经验。
从Agent分类到框架选择从上下文工程到多智能体协作系统讲解开发流程与技术要点并介绍Dola数据分析Agent的实际应用案例为开发者提供全面的Agent开发指南。
Agent介绍
1 什么是AgentAgent智能体或代理是人工智能领域中的核心概念指能够感知环境、自主决策并执行任务以实现特定目标的智能实体。
简单来讲可以理解它是代理你去做一些事情。
Agent具备四大核心能力环境感知通过视觉传感器、语音接口等多模态感官实时获取环境数据智能决策运用深度学习模型和强化学习算法进行复杂决策任务执行可调用API工具库或操控物理设备完成实际工作持续进化具备在线学习和迁移学习能力实现性能的持续提升
2 agent基础框架最早大家所熟悉的AI Agent图如下主要有规划、记忆、工具、执行模块后两者结合可以理解为工具使用。
而完成这些操作的底层控制中枢类比人可以理解为是人的大脑在AI领域则是大模型充当了这一角色。
所以归纳得到AI Agent大脑LLM 记忆 工具使用 规划。
大模型目前的发展历程中聚焦从内容智能到行为智能从而实现通用人工智能。
对话、推理、自主调度Agent、创新、组织是智能化的五大体现。
从最早期的对话机器人形态到如今可借助工具等自主解决问题的Agents形态未来大模型有希望激发创新、组织层面的能力。
3 Agent的分类Agent可以分为四种形态:Reflection【反思模式】通过模型自身反思来改进任务的执行例如react、self-refine、refine属于该类Tool use【工具调用】涉及模型调用外部工具或者库来解决任务Planning【规划模式】提前计划和组织步骤来提升效率和准确率Multi-agent collaboration【多智能体协作】涉及多个智能体进行协作来提升任务执行能力例如A2A协议属于解决该类问题的协议1Reflection【反思模式】通过模型自身反思来改进任务的执行例如react、self-refine、refine属于该类代表技术ReAct框架、Self-Refine算法特点通过任务执行后的自我反思不断优化决策过程应用场景需要持续优化的复杂决策系统2Tool use【工具调用】涉及模型调用外部工具或者库来解决任务。
具体调用什么工具和工具的参数均由模型决定。
核心技术函数调用Function Calling、API集成优势突破大模型固有局限实现现实世界操作典型案例自动订票系统、智能客服工单处理一些相对简单的内容3Planning【规划模式】提前计划和组织步骤来提升效率和准确率
关键技术分层任务网络HTN、蒙特卡洛树搜索价值显著提升复杂任务的执行效率和成功率应用实例物流路径规划、生产排程优化4Multi-agent collaboration【多智能体协作】涉及多个智能体进行协作来提升任务执行能力例如A2A协议属于解决该类问题的协议前沿协议A2A协作框架、联邦学习机制突破实现智能体间的知识共享与协同决策典型应用分布式智能系统、群体机器人控制
4 Agent的开发框架大模型多Agent协作技术的发展可以明显划分为三个主要阶段每个阶段都有其独特的技术特点和代表性成果。
上图展示了从2023年初至2025年该领域的主要发展脉络和
关键技术节点。
下面我们将对每个阶段进行详细分析。
早期探索阶段2023年初-2023年中在大模型多Agent协作的早期探索阶段研究主要集中在概念验证和基础框架构建上。
这一时期的特点是研究者们开始意识到单一大模型在处理复杂任务时的局限性并尝试通过多个Agent的协作来突破这些限制。
早期的研究更多关注于如何让多个LLM驱动的Agent进行基本的信息交换和任务分工协作机制相对简单主要采用顺序执行或简单的并行处理模式。
这一阶段的代表性工作包括对多Agent系统基本架构的定义和初步的协作协议设计。
研究者们开始探索如何将传统多Agent系统的理论与大语言模型的能力相结合但在Agent间的深度协作、知识共享和动态协调方面仍存在较大挑战。
框架成熟阶段2023年中-2024年中随着技术的不断发展2023年中期到2024年中期标志着多Agent框架的成熟阶段。
这一时期最重要的里程碑是微软AutoGen框架的发布它为多Agent协作提供了一个标准化、易用的开发平台。
AutoGen的核心创新在于其**“可对话Agent”**概念使得不同类型的Agent能够通过自然语言进行灵活的交互和协作。
在这一阶段研究重点从基础概念转向实用性和可扩展性。
《Scaling Large Language Model-based Multi-Agent Collaboration》等研究开始关注多Agent系统的规模化问题探讨如何在增加Agent数量的同时保持系统效率。
MacNet模型的提出标志着对Agent协作网络结构优化的深入思考引入了动态协作机制和基于注意力的通信协议。
同时这一阶段也见证了多Agent系统在特定领域的深度应用探索。
研究者们开始将通用的多Agent框架与具体的应用场景相结合如金融交易、软件开发、内容创作等形成了领域特化的Agent协作模式。
应用深化阶段2024年中-2025年进入2024年中期以后大模型多Agent协作技术进入了应用深化阶段。
这一时期的特点是从概念验证转向实际部署从通用框架转向领域专精。
TradingAgents和FinTeam等专门针对金融领域的多Agent系统的出现标志着该技术开始在垂直行业中找到具体的落地场景。
在这一阶段技术发展呈现出几个明显趋势首先是Agent角色的专业化程度不断提高每个Agent都被赋予特定的专业知识和技能其次是协作机制的复杂化从简单的信息传递发展为复杂的工作流编排和决策协商第三是评估体系的完善研究者们开始关注如何科学地评估多Agent系统的协作效果和整体性能。
最新的研究如《Multi-Agent Collaboration Mechanisms: A Survey of LLMs》和《A Survey on LLM-based Multi-Agent System: Recent Advances and Challenges》反映了该领域的理论体系正在趋于成熟同时也指出了未来发展的关键方向。
下面给出主流的一些其他框架对比表除了上述还有qwen-agent OpenAI Swarm等。
在技术发展的浪潮中单智能体系统逐渐难以满足日益复杂的效能需求由此催生了多种多智能体协同解题的架构思路。
以下将介绍当前三个主流智能体框架中如何有效实现多智能体之间的协作与问题求解。
AutoGen适合需要高度定制化和灵活对话的场景其强大的可编程性使其能够处理各种复杂的协作需求但需要开发者具备较强的技术能力。
LangGraph适合需要精确流程控制和状态管理的场景其图结构工作流和状态管理机制使其在处理复杂业务逻辑时具有优势但学习成本相对较高。
Crew AI适合需要快速搭建团队协作系统的场景其高级抽象和简洁接口使其易于上手但在复杂定制需求方面可能存在局限。
目前市场上已有框架各有优劣例langchain这种框架代码太过于笨重在实际开发过程中会遇到无法调控需改底层源码的问题届时可能更加费力不讨好。
为了灵活自主调控我们产品目前是选择自己搭建的Agent框架。
选择合适的框架需要综合考虑项目需求、团队技术能力、开发周期等多个因素。
在实际应用中也可以考虑混合使用多个框架发挥各自的优势。
Agent 的核心演变和核心模块前后跟Agent打交道算起来也有2年半多了我们最早的期望就是打造智能数据分析的一站式服务。
早前大模型的能力受限我们自己给Agent创建手脚更多是以workflow的形态存在的。
最早我们依托workflow的产品框架如下所示核心模块上跟Agent没有太大的区别实际工作中是以规定好的流程进行行动的。
workflow和Agent的区别workflow更多是指开发人员预定好工作的步骤流程系统内按照预定好的步骤进行行动。
而Agent更多是指自主定义和自主探索。
随着大模型能力的增强目前它的自主探索能力已经具备workflow可能是特定时代特定业务下的特定产物长期AGI下更多产品还是会以Agent形态存在。
1 规划模块https://arxiv.org/pdf/
2
02716详细可阅读该文章A Survey of Large Language Models什么是规划Planning可以分为任务分解把大任务划分成小任务进而解决复杂问题代表性的做法是基于CoT技术直接让模型进行任务分解。
反思和提炼基于已有动作做自我批评和自我反思从错误中学习优化接下来的动作。
这里有代表性的做法是ReAct相信熟悉Agent的同学不会陌生。
ReAct的核心点指导AI Agent通过思考、行动、观察的循环来实成任务。
Agent接到任务后的工作流程大致如下
思考(thought)要解决该问题下一步需要采取什么行动。
行动(action)大模型输出行动指令让Agent调用外部工具。
观察(observation)把工具执行的结果给大模型进行观察。
回答(answer)如果工具执行的结果已能得到答案组织语言回答。
如果目前得到的信息仍无法作答进入下一次循环继续思考使用工具ReAct整体其实很像PDCA流程先计划然后做check之后再处理。
规划能让Agent在复杂问题上显得更加聪明类比人类在完成复杂任务的时候可能大多时候也会有个计划大纲。
例如写一本厚厚的书我们需要拟定一个大纲做PPT也是同理大多时候我们需要写一下脉络再具体完成每个小节。
规划的框架如下图所示左边是任务的规划者右边是规划的执行者。
简单来做则计划可以不支持做更新复杂一些则在执行者执行的时候仍可以动态去更新计划refine逻辑。
源自A Survey of Large Language Models目前一些主流产品都使用了规划模式manus、cursor等。
计划模块如何实现决定了系统的效率和性能。
该模块可以通过模型微调或者上下文工程完成前者更适配特定业务但缺乏灵活和快速扩展的能力后者可以快速扩展但缺乏一定的业务适配度具体使用中可以依据业务场景决策。
2 记忆系统记忆系统是什么记忆系统是指通过特定机制存储、管理和检索信息以增强模型在长期交互或复杂任务中的上下文连贯性、个性化响应及知识持久化的技术框架。
其核心目标是解决大模型因固定上下文窗口限制导致的“失忆”问题并模拟人类记忆的分层与动态更新特性。
为什么需要记忆系统大模型本身不存在记忆能力——如果开发Agent应用需要外挂记忆系统进行信息的记忆大模型本身的上下文阈值是有限的——开发过程中没有办法直接给它所有的对话或者文本内容超出后早期对话内容会被丢弃导致多轮对话中出现**“断片”或重复提问**。
记忆系统通过分层存储短期/长期记忆和动态检索如向量数据库将历史信息压缩后注入当前上下文确保对话连贯性。
记忆系统的分层架构记忆系统通常借鉴人类记忆的三层结构分为短期、中期和长期记忆短期记忆STM存储当前对话或任务的即时信息受限于模型的上下文窗口长度如GPT-4的2048 tokens。
实现技术将对话历史直接嵌入提示词中但容量有限。
中期记忆MTM整合短期记忆中的主题信息通过分段分页策略组织如MemoryOS将同一主题的对话归并为“段”并基于热度算法访问频率、时间衰减等动态更新。
长期记忆LPM持久化存储用户偏好、角色特征等个性化数据。
例如MemoryOS的LPM模块包含用户画像和智能体特征通过向量数据库或知识图谱实现长期存储然后通过RAG手段来进行提取。
3 工具/函数调度what——function call是什么LLM通过结构化指令调用外部函数/API将自然语言意图转为可执行指令的能力。
简单说Function Call就是让智能助手能调用外部工具的功能比如查天气、订外卖、算数学题让它从“只会说话”变成“会办实事”的全能帮手why——为什么需要function call 大模型本身的一些缺陷例如
知识有时效性缺陷 比如你问 “2025 年 NBA 总冠军是谁”假设现在是 2025 年模型如果没学过 2025 年的新数据就答不上来。
但用 Function Call 调用体育新闻 API马上能拿到实时结果。
不会做专业操作 模型懂医学知识但不能直接帮你查医院排班懂数学公式但不会用 Excel 算工资表。
而 Function Call 能喊医院系统、办公软件来干活实现 “理论 实操” 结合。
Function call可能的问题错误调用参数、幻觉生成API、依赖关系混乱、隐私问题如乱调用支付软件。
如下面举了一些例子如果“外援”掉链子助手也会变笨 比如天气API突然崩了助手查不到天气只能跟你说“抱歉天气信息没拿到…”隐私问题别让助手乱翻你的东西 如果助手能调用你的支付宝付款万一被坏人骗了可能会乱花钱——所以现在很多Function Call都需要你“授权确认”才能用。
复杂任务容易搞砸 比如你让助手“先订机票再订酒店最后租辆车”如果其中一步出错比如机票卖完了助手可能不知道怎么调整需要你手把手教它。
4 额外话题MCP是什么最简单而言MCP提供了工具资源和prompt用的少的规范化协议。
它的核心组件有以下几点MCP主机Host发起请求的应用程序如AI编程助手、IDE插件MCP客户端Client与服务器保持1:1连接的通信模块MCP服务器Server运行于本地或远程的轻量级程序负责访问数据或执行工具如读取本地文件、调用API提供三种标准类型能力Resources、Tools、Prompts。
资源层包括本地文件、数据库和远程服务如云平台API。
本地资源Local Resources本地计算机中可供MCP服务器安全访问的资源如文件、数据库。
远程资源Remote ResourcesMCP服务器可以连接到的远程资源如通过API提供的数据。
为什么选择MCP标准化集成统一接口降低开发复杂度动态扩展与实时交互能力【可随时增减工具】生态兼容性与开发效率提升【目前已成为主流协议】工具侧具体的实现不公开给HOST应用系统互相独立维护。
MCP协议统一有助于优秀工具的快速集成在实际开发HOST系统的时候就能快速使用到市面上相对较好的工具而不需要自己再调用API维护工具函数或者去找到开源代码重新整合到系统中)。
MCP到底是不是良药MCP技术并不全都是好处能解决部分问题但也带来了其他的问题。
在实际开发下来发现MCP有好有坏目前发现的好坏处如下好处是可以快速上下工具能够快速接入市面上已有的mcp应用不同部门之间可以共建mcp server服务。
【但仍需特别了解MCP工具的内部实现否则不建议接入到自己产品中存在安全问题的同时可能较难调教整体效果】坏处如下坑点1不好查日志排查问题费劲server端的日志较难排查无法通过类似一个trace_id进行串联定位。
目前可以通过访问时间戳找到相关的日志群。
坑点2连接中断问题多了一层服务交互可能出现的问题更多如最常遇到的就是连接中断问题。
sse的方式已经被stream mcp逐渐替代但后者也并不保证百分百稳定。
多了一层服务就多了一层不稳定性。
坑点3性能问题缺乏连接池每次交互都需新建一个连接当流量上来性能会是一个问题。
坑点4出参没有严格标准目前出参就是基础的JSON Schema为保证效果工具最好是需要统一出参的但MCP并没有提供该类的约束需开发者自己建立和遵循。
坑点5效果调教的时候需要同步更新多个服务开发过程中大多时候需同步更新server和host端的代码。
如果产品设计上永不考虑快速接入市面上的MCP应用并且MCP server与Host端是一方开发的情况下其实可以不使用MCP框架。
MCP开发中可能的误区MCP出现之前是不是没有办法调度工具不是的。
它算是一个通用管理协议把一个个工具按照一定的规范装在一个量身定做的箱子里。
之前也可以进行调度调度工具关键的点在于大模型识别出使用什么工具以及工具相对应的参数。
langchain等在MCP之前就已经支持了工具调度的能力。
MCP可以代替function call么不行他们是一起工作的关系。
Function Call是大模型返回调用工具指令的能力MCP是Agent在工程侧的程序具体执行调用工具的手段一个是指挥者一个是执行者。
MCP能减少调用的token数么不行它只是整合了工具但实际还是需要把工具参数都发给大模型。
整体tokens数消耗相比之前的方式是没有本质区别的整体依赖于系统的实现。
是不是有了MCPAgent应用就能轻而易举搭建了不是。
MCP只是把工具管理和获取调用这里规范了但Agent应用关键点还有LLM调用含function call、prompt工程记忆系统RAG上下文管理思考和计划系统等。
如果想要做好一个Agent系统应用还需要仔细打磨前面提到的模块。
怎么基于大模型搭建一个Agent?【开发视角】业务大模型的训练和优化等不是此文重点此处省略。
重点关注怎么基于大模型来搭建Agent系统让整体Agent产品的效果更好。
1 什么影响了Agent的效果从前文介绍可以知道Agent由几个重点的模块组成那么这几个模块的组合方式【Agent框架设计】以及每个模块的效果决定了最终的效果。
Agent框架设计对应Agent分类里面的内容。
是否多Agent设计要依据产品实际场景来考虑并非任何场景都适配多Agent。
多Agent本质还是可以理解为上下文工程的演化让单一Agent单独去处理自己部分的上下文内容其他Agent精简的上下文。
上下文工程曾经大家更熟悉的名词可能是prompt工程但上下文工程含义更广泛包含了记忆系统提取出来内容的处理即简单理解为多轮对话等的处理并非简单写一个提示词。
2 如何构建良好的上下文工程关于上下文工程这一块汇总了manus的经验以及自己开发过程中遇到的一些问题。
核心点
围绕KV-Cache优化设计关键指标KV缓存命中率直接影响延迟和成本如Claude Sonnet缓存token成本降低10倍。
优化策略稳定提示前缀避免动态内容如秒级时间戳破坏缓存。
追加式上下文禁止修改历史动作/观察确保序列化确定性如JSON键顺序稳定。
显式缓存断点对不支持自动缓存的框架手动标记断点位置。
核心点
动态约束行为选择非移除问题工具数量爆炸导致模型动作选择混乱。
解决方案Logits掩码通过屏蔽非法动作token如browser_*前缀工具组约束选择。
状态机管理根据上下文预填充响应模式Auto/Required/Specified不修改工具定义。
具体Auto – 模型可以选择是否调用函数。
实现方式仅预填充回复前缀|im_start|assistantRequired – 模型必须调用函数但具体调用哪个函数不受限制。
实现方式预填充到工具调用标记|im_start|assistanttool_callSpecified – 模型必须从特定子集中调用函数。
实现方式预填充到函数名开头|im_start|assistanttool_call{“name”:「browser\_核心点
文件系统作为扩展上下文挑战128K上下文窗口仍不足且长文本导致性能下降、成本高。
创新设计外化存储文件系统作为无限容量的持久化记忆支持按需读写。
可逆压缩仅保留引用如URL/路径内容可随时还原避免信息丢失。
核心点
注意力操控复述目标现象Manus创建todo.md并动态更新勾选已完成项。
原理抗遗忘将长期目标“背诵”到上下文末尾强化模型近期注意力。
无架构改动通过自然语言重定向模型焦点。
核心点
保留错误以促进学习反模式掩盖错误重试/重置会剥夺模型学习机会。
关键实践失败即证据保留错误动作及环境反馈修正模型内部信念。
智能体标志错误恢复能力是真实智能行为的核心指标。
核心点
警惕Few-Shot陷阱问题过多相似示例导致模型陷入固定模式如重复简历审阅动作。
解法注入多样性通过模板变体、表述扰动打破单调性。
动态调整避免上下文过度同质化。
核心点
提示词内容一致性问题系统专用术语如内部API名称、业务逻辑标签未被模型正确理解导致动作偏差。
关键实践术语对齐在提示词、工具描述、环境反馈中强制统一术语表述如“用户画像”不可同时称“客户画像”。
动态解释对关键术语插入简短定义例数据湖指跨部门原始数据存储库非结构化优先。
错误溯源若模型误用术语在反馈中显式纠正并记录术语表。
核心点
动态提示词问题静态提示词无法适应环境状态变化如任务阶段切换、权限变更导致无效动作。
解法状态感知注入根据实时环境变量如current_step3动态插入提示片段例当前需聚合前两步结果禁止调用数据采集工具。
优先级分层将提示词分为基础规则不变场景规则动态后者通过函数实时生成。
历史敏感度检测到重复失败时自动追加注意此前因忽略时间约束失败本次需校验截止时间。
核心点
工具能力边界显式化反模式模型因工具文档模糊而尝试不可能动作如用PDF解析工具处理图像。
解法能力-限制对仗描述每个工具说明需包含支持输入类型和明确失败条件例仅支持UTF-8文本二进制输入返回ERROR_12。
运行时校验在动作执行前系统先检查参数是否符合工具约束快速拦截无效请求。
核心点
环境反馈的颗粒度控制问题过于简略的反馈如仅返回错误代码导致模型无法定位问题过于冗长的反馈则引入噪声。
解法分层反馈机制 初级反馈即时返回可行动错误类型如参数缺失缺少user_id字段。
深度反馈当模型请求/debug时提供堆栈追踪或数据流快照。
错误分类强化将系统错误映射为模型可理解的类别如权限类/数据格式类并关联修复建议。
核心点
长期记忆与短期上下文的平衡反模式过度依赖当前会话上下文忽略历史经验积累。
关键实践记忆分级 短期保留最近N轮动作-反馈对用于即时纠偏。
长期将高频错误模式存入知识库触发相似场景时主动提醒如历史记录显示该API在时区为UTC8时易超时。
记忆更新策略对已验证的修正知识如X字段需加密传输通过人工审核后固化到系统约束。
核心点
人类干预的黄金分割点问题过早人工介入会抑制自主学习过晚则导致代价高昂的错误。
策略三级熔断机制 自动修复对已知错误如字段格式不符调用预设修正流程。
半自动干预当连续3次相似失败时请求人类确认动作。
强制暂停检测到高风险动作如删除操作且置信度80%时冻结任务。
干预记录分析统计人工介入原因反向优化自动化规则。
尝试点
多智能体竞争验证创新实践影子模式部署双模型并行执行任务对比结果差异并交叉验证如Agent A生成SQL查询 vs Agent B生成NoSQL查询。
对抗辩论当结果不一致时强制双方基于环境反馈进行逻辑辩论系统根据辩论质量选择最优解。
# 动态提示词生成伪代码示例 def generate_dynamic_prompt(base_prompt, state): # 注入状态感知片段 if state[step] 2 and state[last_error] timeout: base_prompt \\\\n[紧急] 上一步因超时失败本次请将timeout参数设为5000ms # 添加长期记忆提醒 if api_fail_history in state: base_prompt f\\\\n[记忆] 该API近7天失败率{state[api_fail_history]}%建议备用方案 return base_prompt
3 记忆系统如何构建我们可以以一个最简对话系统为例结合短期、中期、长期记忆进行分层处理短期记忆聚焦当前对话的最近信息直接将最新消息体输入模型。
这类似大脑对当下信息的清晰即时记录确保模型能响应最新对话内容。
中期记忆由于模型存在阈值容量限制需对当前对话中的关键信息进行摘要处理。
这如同大脑在记忆容量有限时自动将知识压缩为核心要点非逐字记忆而是保留关键内容让模型抓住对话的核心逻辑。
长期记忆通过RAG检索增强生成等技术在用户提问时调用外部知识库提取已沉淀的长期记忆内容。
这一机制类比大脑调用过往经验与知识储备为对话提供更丰富的背景信息支撑。
由于大模型的阈值始终有限消息体在一定的对话回复轮次之后会超出大模型的上下文窗口限制。
最简单的做法直接如基于时间衰减近期对话优先保留或重要性排序关键信息优先避免记忆冗余。
下标给出一些常见的方法更复杂的系统可以研究下memoryOS等架构。
4 如何搭建基于function call的大模型Agent应用核心逻辑大模型负责“理解问题 安排任务”外部工具负责“具体执行”最后模型把结果包装成你能听懂的话。
用户发起请求User→应用系统用户向应用系统提交自然语言问题如查询上海天气。
提示词编排应用系统→LLM应用系统将问题转化为结构化提示词调用大模型并请求决策。
工具调用判断LLM决策分支无需工具LLM直接生成文本回复如回答常识问题。
需工具调用LLM输出工具名称及参数如WeatherAPI: {location: “上海”}。
安全审批应用系统→Host系统工具调用需经权限校验与风险审核通过后触发执行确认。
函数执行Host系统Host系统按参数调用目标工具如天气API获取原始结果如JSON数据。
结果整合逆向传递链工具结果经Host系统→应用系统→LLM逐层返回LLM将数据转化为自然语言如上海今日多云28°C。
最终响应应用系统→User应用系统将LLM生成的友好回复返回给用户流程终止。
怎么实现函数调度的功能整体其实就是提示词来激发模型选择工具的能力目前开发过程中主要有两种实现方式一种是直接使用大模型API提供方提供的利用tools和messages的组织方式其实背后他们自己也是通过prompt来组建的一套能力不过相比自己开发一套提示词工程而言他们更了解底层模型如何做的在通用化场景下的适配效果可能比自己研究要好很多。
引阿里云官网提供的函数调用的流程图解1使用官方提供的服务openai接口访问方式快速使用推荐简版代码如下但提前需准备好tools的定义见下文tools的样式小节和messages数组见下文messages该如何组织部分后续推文会有更详细的介绍。
from openai import OpenAI import os client OpenAI( # 若没有配置环境变量请用提供商提供的api_keysk-xxx, api_keyos.getenv(API_KEY), base_urlBASE_URL, ) def function_calling(): completion client.chat.completions.create( modelqwen-plus, # 此处以qwen-plus为例 messagesmessages, toolstools # 这里tools的结构体可以见下文tools的样式 ) print(返回对象) print(completion.choices[0].message.model_dump_json()) print(\\\\n) return completion print(正在发起function calling...) completion function_calling()2prompt系统自实现**完全小白不建议用这个哈相对自适配能力更强但很考验对底层模型的理解。
上图提供了函数调用流程的图解实际自己用prompt开发流程与上图一致。
用户提问的时候将工具内容和问题组织为一定的提示词给到大模型然后写一段拆解函数拆解大模型返回内容里面携带的工具调用信息和其他文本内容。
5 如何搭建基于MCP协议的大模型Agent应用相比仅基于function call的应用而言其实就是引入了mcp来管理工具资源除此之外其他的都是一样的。
下面给出了工作流程图解。
基于MCP协议的大模型Agent应用的工作流程图解。
流程始于用户发送请求步骤1Host系统将问题及工具列表传递给MCP-Client步骤2随后LLM生成工具调用参数步骤3并经审批确认步骤
。
MCP-Server Tool执行具体操作步骤
后结果通过多级传递步骤
最终由LLM生成响应步骤11返回给用户步骤12。
整个架构突出了MCP协议在协调用户、主机系统、大语言模型和工具服务之间的核心枢纽作用体现了模块化分工与安全审批机制的设计理User→Host系统 用户向HOST系统发送一个需要处理的问题自然语言)Host系统→MCP-Client Host系统将用户原始问题自然语言和可调用工具列表如API、数据库接口等打包发送至MCP-Client触发工具规划流程。
MCP-Client→LLM MCP-Client请求LLM分析用户问题生成结构化工具调用方案包括工具选择、输入参数等例如解析查询北京天气为调用WeatherAPI的参数{location: “北京”}。
4-
MCP-Client→Host系统审批闭环 MCP-Client提交工具调用申请至Host系统触发安全审批如权限校验/风险过滤通过后返回确认执行指令确保操作合规性。
Host系统→MCP-Server Tool Host系统向MCP-Server Tool发送工具执行命令如REST API调用指令携带LLM生成的标准化参数。
MCP-Server Tool执行 工具服务执行具体操作如调用天气API、数据库查询等生成原始执行结果如JSON格式的天气数据。
8-
结果逆向传递链 MCP-Server Tool→Host系统→MCP-Client→LLM逐层返回工具执行结果数据经校验和格式化传递保持上下文一致性。
LLM生成最终响应 LLM将工具返回的原始数据转化为用户友好的自然语言如北京今日晴25°C并补充逻辑推理或多工具结果融合。
Host系统→User Host系统将LLM生成的最终响应返回给用户完成闭环。
流程中MCP协议通过标准化接口和审批机制确保多主体间安全、高效的协同。
Agent如何评估关于这个问题目前就调研来看没有比较完善的评估方式。
调研的bechmark跟大家分享下调研角度上涵盖数据分析场景与多轮对话/工具交互领域的代表性Benchmark数据集复杂的文本图非纯答案场景若追求严格准确性仍需人工介入。
如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。
但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。
这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。
我在一线互联网企业工作十余年里指导过不少同行后辈。
帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。
但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。
2023年人才缺口已超百万凸显培养不足。
随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。
加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。
大模型入门到实战全套学习大礼包
大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。
正确的学习路线可以为你节省时间少走弯路方向不对努力白费。
这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通
大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。
AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。
大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。
大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。
在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。
适用人群第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。
大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-
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 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。
天道酬勤你越努力就会成为越优秀的自己。
如果你能在15天内完成所有的任务那你堪称天才。
然而如果你能完成
% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。
这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】