本文深入剖析了AI领域从LLM、Prompt到Function Calling、MCP、Skill及A2A等核心概念的技术演进史旨在为读者梳理清晰的脉络。文章首先介绍了LLM的统计学模型基础随后详细阐述了Prompt、Context、Agent、RAG等概念如何扩展大模型能力并通过Function Calling与MCP协议规范了工具调用。接着文章探讨了Workflow与Skill在任务流编排上的演进最后展望了A2A多智能体协同的未来趋势。整体而言文章旨在帮助读者理解AI技术发展的内在逻辑把握大模型应用的核心要点。最近AI圈造新概念的速度多少让人有点“学不动了”的恐慌每天醒来都有各种英文缩写在神仙打架。为了理清脉络我把从LLM、Prompt到Function Calling、MCP、SKill等这一路的技术演进史彻头彻尾地扒了一遍主打一个给AI概念“脱水”。咱们先用一句话速览这些概念的核心差异• LLM基于海量参数的统计学模型提供核心概率性文本生成与推理能力。• Prompt Context驱动模型执行特定任务的自然语言指令以及提供所需知识或环境设定的背景信息。• Agent结合大模型推理与传统代码逻辑的代理程序赋予大模型主动调度外部工具并执行复杂任务的能力。• RAG 通过外接向量数据库将外部或私有文档作为上下文动态注入突破模型静态参数的知识局限。• Function Calling 建立大模型与代理程序之间的结构化数据规范解决自然语言向底层代码API调用过渡时的意图解析不确定性。• MCP 提供标准化的客户端与服务端架构协议统一并简化代理主程序与各类外部工具服务之间的网络集成。• Workflow(含LangChain) 针对高频且高度结构化的任务通过代码硬编码或可视化节点将动态的工具调用转化为静态、低成本的固定执行流。• Skill通过预设配置与脚本对底层工具进行业务封装在限定的边界内恢复模型的自主决策权缓解复杂业务场景下的工作流分支爆炸问题。• A2A(多智能体) 将复杂任务拆解并分发给多个独立的子智能体通过上下文隔离防止单一模型注意力分散实现AI架构的微服务化协同。一、从LLM到Prompt一切的起点一切的故事都要从“语言模型”说起。在早期它本质上只是一个基于海量参数的统计学模型。当这些参数量级呈现爆炸式增长后就涌现出了我们现在熟知的大语言模型(LLM)。这类模型的核心机制是“生成式”的——它们根据前文的语境以概率计算的方式预测并生成下一个词。单纯的“文本预测”并不足以解决实际问题。要让大模型真正执行特定任务我们需要建立交互也就是通过Prompt来下达指令。随着交互的深入输入的信息结构也进一步细化¢ Prompt作为核心指令明确模型需要完成的任务动作。¢ Context作为背景信息为模型提供执行任务所需的知识库或环境设定。随着多轮对话的展开长文本会给模型的上下文处理能力带来巨大压力。为了在不牺牲连贯性的前提下提升效率一种常见的策略是引入Memory机制——通过让模型主动总结历史上下文信息形成浓缩的记忆节点从而兼顾了对话的深度与运算的轻量化。二、Agent与RAG大模型能力的外部扩展到目前为止大模型虽然聪明但它自身受限于静态的参数缺乏主动联网查阅资料或执行外部逻辑的能力。如果没有任何辅助它所能做的依然只有“词语接龙”。为了打破这个限制人们编写了一段外部程序作为用户和大模型之间的“代理人”——它能替大模型去执行搜索、计算等任务。这个看似神秘、能操纵各种工具的代理程序就是智能体Agent。在外人看来你依然是在对话框里一问一答就拿到了结果但实际上为你服务的已经变成了一个暗中调度工具的系统。所谓的智能体其实就是由“不需要智能的传统代码逻辑” “大模型的聪明大脑”组合而成的。所以回想起早期有一些标榜自己是“智能体”的应用其底层逻辑仅仅是多加了一段复杂的Prompt而已从现在的视角回看当时简直就是一种概念诈骗。既然Agent能代理大模型去联网搜索那自然也能让它去翻阅本地的私有文档或企业数据库。这就引出了 RAG(检索增强生成)技术。它通常需要配合向量数据库将和你的问题语义相近的文档片段“捞”出来当作背景信息Context塞进对话里从而大大提高生成内容的可靠性。总而言之无论是联网搜索(Web Search)还是本地检索(RAG)它们的本质是一样的都是在给大模型装上“外挂”让它拥有获取自身参数之外信息的能力。三、Function Calling与MCP规范工具调用在引入了Agent之后我们面临着一个新的问题 目前的整体架构是用户与大模型之间隔着一层Agent程序由这个程序来帮助大模型调用工具或执行搜索。但如果Agent与大模型之间一直使用自然语言沟通Agent的传统代码很难稳定、准确地解析大模型的真实意图。为了解决这个问题必须约定让大模型按照指定的、结构化的格式来输出回复例如JSON格式。Function Calling(函数调用)正是大模型与Agent之间为了准确触发工具而形成的一种数据格式约定。很多人被这个名字误导了以为大模型能够顺着网线直接去运行本地电脑里的代码。大模型本身绝对不能直接去执行任何一段本地或远端的代码Function Calling在本质上仅仅是一份前端模型和后端代码之间的结构化数据规范。维度PromptFunction Calling输出形式随性的自然语言文本严格约束的结构化JSON执行可靠性低 看模型心情易幻觉高 代码级强约束工程开发成本低 只需编写文本指令较高 需写Schema与接口代码核心应用场景聊天问答、 文本生成与润色触发外部API、 读写私有数据库等Function Calling没有改变模型只能处理文本的本质它只是让模型具备了输出标准化接口参数的能力解决了自然语言向结构化程序调用过渡的问题。为了能更直观地理解我们来看一个真实的业务代码片段。假设我们的Agent需要帮用户查询ES数据库中的新闻舆情第一步定义 Tools# 告诉大模型我这里有一个查新闻舆情的工具你必须给我提取这三个参数 tools [{ type: function, function: { name: search_es_news, description: 查询特定公司在指定时间段内的新闻舆情数据并保存到本地。, parameters: { type: object, properties: { company_name: {type: string, description: 公司名称}, start_time: {type: string, description: 开始时间}, end_time: {type: string, description: 结束时间} }, required: [company_name, start_time, end_time] } } }]在发问之前我们必须用JSON Schema告诉大模型我们手里有什么工具以及必须提取哪些参数。第二步定义本地拦截逻辑def search_es_news(arguments): # 1. 接收大模型结构化好的参数 company arguments.get(company_name) start arguments.get(start_time) end arguments.get(end_time) # 2. 执行本地真实的底层逻辑此处省略数据库连接与查询代码 print(f--- [本地执行] 正在查询 {company} 从 {start} 到 {end} 的数据...) real_data_result 查询成功共找到147条记录并已保存本地。 # 模拟数据库返回结果 # 3. 返回客观执行结果 return real_data_result大模型本身碰不到数据库。当大模型按要求提取好参数后由我们的本地代码拦截请求并执行真实动作。第三步核心调度机制# 第一次向大模型发起带有tools的对话 response get_response(messages) assistant_output response.choices[0].message # 核心循环只要模型判定需要调用工具就进入本地拦截流 while assistant_output.tool_calls: # 【关键1】先将模型的“调用工具请求”存入上下文保证历史连贯否则会报错 messages.append(assistant_output) # 遍历处理大模型发起的工具调用 for tool_call in assistant_output.tool_calls: arguments json.loads(tool_call.function.arguments) # 触发本地工具执行 if tool_call.function.name search_es_news: tool_result search_es_news(arguments) # 【关键2】将本地查到的客观数据以tool角色塞回消息列表 messages.append({ role: tool, tool_call_id: tool_call.id, content: str(tool_result), }) # 带着本地真实数据再次请求大模型由大模型包装成自然语言回复用户 response get_response(messages) assistant_output response.choices[0].message这是 Function Calling的灵魂机制发起请求 - 模型要求调工具 - 本地执行 - 结果塞回上下文 - 再次请求模型总结。第四步当我们在终端运行上述代码时输出结果如下用户问题: 帮我查一下****在2026-03-16 00:00:00到2026-03-21 00:00:00期间的新闻舆情数据并保存下来。 [大模型调度] 正在调用工具 [search_es_news] [大模型调度] 提取到的参数{company_name: ****, end_time: 2026-03-21 00:00:00, start_time: 2026-03-16 00:00:00} --- [本地执行] 开始连接 ES 数据库... --- [本地执行] 动态参数注入: 公司****, 时间2026-03-16 00:00:00 至 2026-03-21 00:00:00 --- [本地执行] 实际写入文件条数: 147 --- [本地执行] 文件已成功保存 助手最终回复已成功查询并保存****在2026-03-16 00:00:00至2026-03-21 00:00:00期间的新闻舆情数据共147条不重复记录。 进程已结束退出代码为 0但随着工具越做越复杂当各种工具被独立封装成外部服务时Agent主程序又该如何统一发现并调用它们呢假设你们公司引入了3种不同的大模型框架它们都需要访问公司的5个内部系统比如代码仓库、关系型数据库、项目管理软件等。如果没有统一标准你需要为每一个模型框架写一套针对每一个内部系统的适配代码。这在软件工程里是一个经典的N乘M网状灾难后续维护起来简直要命。这就需要一套类似于标准接口文档的规范比如定义好如何获取工具列表、如何发起具体调用等。MCP(Model Context Protocol,模型上下文协议)就是Agent与各种外部工具服务之间进行标准对接的通信协议。它强制规定了标准的客户端与服务端架构你只需要把外部数据源包装成一个符合MCP规范的服务端程序。以后不管你接入什么样的大模型框架只要它支持MCP协议作为客户端它连上这个服务端后就能通过标准指令自动枚举出里面包含哪些可用的资源和函数工具。MCP根本没有提升大模型的智商它只是统一了网络层的连接标准。它把N乘M的集成复杂度降到了N加M让开发者不用再天天痛苦地写那些毫无技术含量的接口转换逻辑。这时候很容易让人产生混淆既然 Function Calling 和 MCP 都是关于调用的“规范”它们是不是竞争关系会不会随着技术发展互相取代答案是当然不会因为它们解决的是完全不同层面的问题有着本质的区别¢ Function Calling是“大模型”与“Agent主程序”之间的意图沟通规范。¢ MCP是“Agent主程序”与“外部工具服务”之间的数据对接规范。两者处于系统的不同维度一个负责向内解析大脑的需求一个负责向外连接工具的手脚相辅相成完全不存在谁取代谁的问题。四、从LangChain、Workflow到Skill任务流的演进不论什么形式的智能体在面对高度结构化的任务时都有一个统一的痛点。假设我们有一个日常的流程化任务每天抓取某股票的新闻舆情提取网页内容保存成Word格式最后形成舆情日报。我们完全可以每天把这个需求提给Agent让它自己来策划并执行整体流程。但对于这样一个固定的重复性任务来说每次都让Agent自由发挥不仅输出结果不稳定而且每次都要消耗大量的Token成本极高。在这个场景中我们完全可以把“提取网页内容”和“保存文档”这两部分流程固化下来。为了实现这种代码级的固化编排LangChain等早期的开发框架应运而生。它使用纯编程的形式将流程写死全程硬编码。这种方式极其稳定但缺乏柔性且使用门槛高几乎只适合程序员来操作。为了让非技术人员也能参与定义流程一种低代码的解决方案出现了——也就是我们熟知的Workflow。它通过可视化页面的“傻瓜式”拖拽来连接各个任务节点。Workflow大大降低了修改流程的难度但在面对多分支的复杂逻辑判断时依然显得不够灵活。维度LangChainWorkflow表现形式代码库 (Python / JS)可视化 UI (画布、拖拽节点)使用者软件工程师、AI 开发者产品经理、业务专家、开发者开发效率较慢 需写代码、配环境、部署极快 开箱即用所见即所得逻辑控制动态、隐式 依赖代码控制流静态、显式 严格按照预设路径执行定制化能力无上限完全自由受限于平台提供的节点和功能补充视角面对多分支的复杂情况工程上确实存在另一个极端路线纯Agent模式。即不写死任何流程只提供工具把控制权完全交给大模型去执行“观察-思考-行动”的死循环ReAct。纯 Agent极具韧性遇到报错会自动换参数重试。但它的痛点同样致命极度不可控且成本高昂。在处理复杂逻辑时它极容易陷入死循环。这时候新的问题又出现了。随着业务发展我们要处理的原始内容可能不仅限于“新闻网页文本”还可能是长篇的财报PDF文档、高管电话会议的录音甚至是社交媒体上的舆情截图。 与此同时输出的格式要求也变成了 PDF、HTML、图片或音频。如果继续用 Workflow难道要为这些复杂的输入输出组合排列组合地画出一套庞大的连线图吗在工程上这并非不可能这意味着工作流中会充斥着无数个if-else判断节点后期的维护将是一场灾难。为了优化这种“分支爆炸”的问题Skill诞生了。在工程实现上一个Skill通常是一个静态的配置文件及附属脚本它把底层工具向上做了一层业务封装。一个标准的Skill包里通常包含三样东西SKILL.md核心指令 特定场景的提示词模板用来限定模型在当前任务下的边界、规则以及局部的执行步骤说明。_meta.json元数据与配置 限定范围的工具列表只向大模型暴露完成这个任务绝对必需的几个工具接口严格屏蔽其他无关动作。scripts执行脚本 存放处理该特定业务逻辑的局部代码文件。所以Skill的本质可以说是一个“有限制的Prompt加载器”它把原本由硬编码或工作流死板控制的流程走向重新交还给了智能体自行判断但同时又通过预设的脚本库将Agent的自由度限制在了绝对可控的范围内。五、A2A多智能体协同当你的业务线越来越复杂你会忍不住给单一的Agent加载几十个业务Skill挂载几百个系统级Tools。这时候Agent底层依赖的系统提示词会变得无比臃肿上下文窗口被各种设定塞得满满当当。 随之而来的现象就是模型注意力的严重分散Agent开始遗忘初始指令在不同的任务逻辑之间产生混淆甚至因为超出上下文极限而输出无效内容。此时的最佳策略是拆解任务——将独立的子任务分配给单独的Subagent来完成。这就演进出了A2A(Agent to Agent)架构。这种多Agent协作的本质其实就是做了一层“上下文隔离”确保每个子智能体只需处理与当前任务强相关的背景信息从而有效防止了冗杂的子任务细节污染主Agent的核心上下文。A2A架构的引入使得整个AI系统的流转逻辑变得高度可观测与可扩展它提供了精细化的成本控制手段开发者可以针对简单的路由分发或信息提取节点调用低成本的小参数模型而针对复杂的代码生成或逻辑推理节点则调用能力更强的大模型。从工程视角来看A2A架构本质上就是传统软件开发中的“微服务化”理念在AI时代的必然演进。六、现状与展望回顾从LLM、Prompt、Workflow到MCP与Skill的整个演进史所有底层技术的迭代本质上都是在做同一件事帮助我们自动地向提示词里补充必要的上下文并尽可能减少人类与大模型之间反复沟通的次数。在这个不断演进的架构中一个核心的工程原则已经确立确定的流程和分流逻辑交给传统程序处理而模糊的意图识别和内容生成交给大模型。这一切的目标都是为了节省人类的时间降低使用门槛。目前Agent最大的问题是强大的代理在背后消耗的Token太贵。但随着模型侧的疯狂内卷Token终将变得越来越便宜甚至免费甚至以后可能连生产级模型都可以轻易部署在本地电脑上。这不仅可以彻底解决调用成本问题还可以消除企业和个人对敏感数据泄露的隐私顾虑。当算力和隐私不再是瓶颈智能体正从“底层开发框架”向“开箱即用的超级应用”跃迁未来的核心竞争力不再是调用逻辑而是产品化能力。像近期备受关注的开源项目OpenClaw正是这一趋势的典型代表这类应用通过默认配置或按需添加常用的MCP接口和Skill库彻底打破了网页对话框的限制深度嵌入操作系统能够直接读取本地文件、联动外部软件成为无缝协作的本地助手。随着任务复杂度的急剧提升多智能体协作A2A也将成为必然的常态。为了避免庞大的上下文相互污染未来的系统将不再依赖单体Agent包揽一切。Agent将转变为“项目经理”负责拆解需求再分发给众多垂直领域的子智能体。它们通过统一协议自行沟通、处理数据而普通用户只需用自然语言下达一次指令便能获取最终的完美交付结果。2026年AI行业最大的机会毫无疑问就在应用层字节跳动已有7个团队全速布局Agent大模型岗位暴增69%年薪破百万腾讯、京东、百度开放招聘技术岗80%与AI相关……如今超过60%的企业都在推进AI产品落地而真正能交付项目的大模型应用开发工程师****却极度稀缺落地AI应用绝对不是写几个prompt调几个API就能搞定的企业真正需要的是能搞定这三项核心能力的人✅RAG融入外部信息修正模型输出给模型装靠谱大脑✅Agent智能体让AI自主干活通过工具调用Tools环境交互多步推理完成复杂任务。比如做智能客服等等……✅微调针对特定任务优化让模型适配业务目前脉脉上有超过1000家企业发布大模型相关岗位人工智能岗平均月薪7.8w实习生日薪高达4000远超其他行业收入水平技术的稀缺性才是你「值钱」的关键具备AI能力的程序员比传统开发高出不止一截有的人早就转行AI方向拿到百万年薪AI浪潮正在重构程序员的核心竞争力现在入场仍是最佳时机我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】⭐️从大模型微调到AI Agent智能体搭建剖析AI技术的应用场景用实战经验落地AI技术。从GPT到最火的开源模型让你从容面对AI技术革新大模型微调掌握主流大模型如DeepSeek、Qwen等的微调技术针对特定场景优化模型性能。学习如何利用领域数据如制造、医药、金融等进行模型定制提升任务准确性和效率。RAG应用开发深入理解检索增强生成Retrieval-Augmented Generation, RAG技术构建高效的知识检索与生成系统。应用于垂类场景如法律文档分析、医疗诊断辅助、金融报告生成等实现精准信息提取与内容生成。AI Agent智能体搭建学习如何设计和开发AI Agent实现多任务协同、自主决策和复杂问题解决。构建垂类场景下的智能助手如制造业中的设备故障诊断Agent、金融领域的投资分析Agent等。如果你也有以下诉求快速链接产品/业务团队参与前沿项目构建技术壁垒从竞争者中脱颖而出避开35岁裁员危险期顺利拿下高薪岗迭代技术水平延长未来20年的新职业发展……那这节课你一定要来听因为留给普通程序员的时间真的不多了立即扫码即可免费预约「AI技术原理 实战应用 职业发展」「大模型应用开发实战公开课」还有靠谱的内推机会直聘权益完课后赠送大模型应用案例集、AI商业落地白皮书